Secession
Just an idea for a game I'm musing about. Basically, it'd be a kind of sim-city/civilizations type game, but with an interface like football manager. Instead of "building an empire" your goal would be to secede from one. In a US scenario, you'd have "easy" and "hard" states to pick from (eg. easy = California; hard = Nevada). Foster dissatisfaction with your national government! Encourage local state rivalries! Leverage governors into voting for things that make secession possible! Finally, build up local militias, grab the local military bases, ensure you have the nuke launch codes and hold out for your own country!! In multi-player, everyone plays a state and is trying to achieve the same thing - the winner is the one to get there first. Note: I'm a Brit, so don't flame me with secessionist US politics ideas - I'm not really bothered, I just think it would make for an interesting game. And it doesn't have to be US either - soviet-era Russia would do just fine too; Roman-era Europe works just as well (though you'd have to do a decent amount of historical research).
Saturday 14 February 2009
Friday 13 February 2009
Why we need a new programming language
We need a new programming language to better handle databases. Or perhaps, a new paradigm.
Structural Programming is crap for working with databases.
Object Orientated Programming is equally crap for working with databases.
With your perl type-languages (mostly procedural), database handling tends to be: here's the SQL, fire it at the database, do something with the result. This is messy because it leaves SQL trailing all over the place, possibly referencing the same database tables in lots of different files.
With your object orientated languages (say, Java), database handling is hidden to the point that it's difficult to optimise, the SQLs (or whatever the hidden equivalent is - say Hibernate criteria) are still scattered around, and again, difficult to change.
What I want is a SET-orientated language. Databases are based on set theory. Give me a language that's based on that. Not one that simply manages sets - the whole language should be based on the fact that you use and abuse sets of data constantly with SQL. Sure, build in database independence - force me to write ANSI-SQLs in this language, that would ensure far better compatibility than Hibernate or its ilk.
Let's say I have a table called 'customers'. Now, let's say, someone wants a new piece of data. I want to quickly find all the references to the customers table, and check if anything needs changing.
Structural programming, I have to basically grep for all occurrences and then read the code involved.
OO is, in theory, a little better, assuming everything has been done correctly - just search for references to the customers object. Except that you don't just have to search for the customers object, you have to search for everything that extends it. And in most complex projects, you'll probably find someone has mangled a bit of SQL and just like structural, you'd end up grepping for something.
In a set based programming language, you'd have customers and everything else springs off of that set. So much simpler to find everything.
SQL and table structures are probably the most important part of your application. Consider: If someone took your current project away and started rewriting it in another language, what bits would they take? The clever multi-layered model/view/controller architecture that someone spent hours working on? The error handling? Your table-widget with a billion possible combinations? Or the data and ways of accessing that data? If the answer's not obvious, you need to get out of any programming that involves databases.
Structural Programming is crap for working with databases.
Object Orientated Programming is equally crap for working with databases.
With your perl type-languages (mostly procedural), database handling tends to be: here's the SQL, fire it at the database, do something with the result. This is messy because it leaves SQL trailing all over the place, possibly referencing the same database tables in lots of different files.
With your object orientated languages (say, Java), database handling is hidden to the point that it's difficult to optimise, the SQLs (or whatever the hidden equivalent is - say Hibernate criteria) are still scattered around, and again, difficult to change.
What I want is a SET-orientated language. Databases are based on set theory. Give me a language that's based on that. Not one that simply manages sets - the whole language should be based on the fact that you use and abuse sets of data constantly with SQL. Sure, build in database independence - force me to write ANSI-SQLs in this language, that would ensure far better compatibility than Hibernate or its ilk.
Let's say I have a table called 'customers'. Now, let's say, someone wants a new piece of data. I want to quickly find all the references to the customers table, and check if anything needs changing.
Structural programming, I have to basically grep for all occurrences and then read the code involved.
OO is, in theory, a little better, assuming everything has been done correctly - just search for references to the customers object. Except that you don't just have to search for the customers object, you have to search for everything that extends it. And in most complex projects, you'll probably find someone has mangled a bit of SQL and just like structural, you'd end up grepping for something.
In a set based programming language, you'd have customers and everything else springs off of that set. So much simpler to find everything.
SQL and table structures are probably the most important part of your application. Consider: If someone took your current project away and started rewriting it in another language, what bits would they take? The clever multi-layered model/view/controller architecture that someone spent hours working on? The error handling? Your table-widget with a billion possible combinations? Or the data and ways of accessing that data? If the answer's not obvious, you need to get out of any programming that involves databases.
Subscribe to:
Posts (Atom)