robert young
Posts: 361
Nickname: funbunny
Registered: Sep, 2003
|
|
Re: The Next Big JVM Language
|
Posted: Sep 27, 2010 10:19 AM
|
|
> This isn't to say that there are not tools (or processes)
> that both increase productivity and simplify work. These
> kinds of tools are what cause revolutionary change. But
> these tend to be the exception, not the rule. As a rule
> of thumb, if you want to maximize productivity, you will
> usually have to give up on some simplicity.
I argue that the Great Leap Forward is paradigm shift. Some, not all, think that OO was such. Others, not so much; particularly if one looks underneath the covers of major java web frameworks. Not much OO there; in the classic sense of data/method seamlessly embroidered together. See: Graham.
Two shifts: the graphics rendering engine and the relational database. No game developer would not use an engine, but many coders ignore the RDBMS in favor of continuing to write file based approaches. The difference: the rendering engine doesn't replace coding with something else (rather it swaps low level syntax with something "higher"), while the RDBMS does.
It can also be argued (I sure do) that there was such a revolution in the 80's-90's, and it had a name: 4GL languages (yeah, I know what L stands for). Didn't work out so well. All but a couple (if that many) went away. Coders decided they didn't want to be constrained to the semantic choices of the 4GL authors, by and large.
Just look at java web development. I wrote servlets as shown in Hunter's first edition, as did many others. No one does that any longer. Are the web apps any better? Who knows? They aren't written in java, they're written in "Struts" or whatever. You're beholden on the choices made by them. Same for RoR. Same for web frameworks in all other languages. The number of them grows like bedbugs, because some group doesn't like the choices made.
These are all code generators, to a first approximation. That level of tool goes back to the 1960's; COBOL (already assumed to be very high level language) code generation was au courant for a long time; still is some places. There's always more boilerplate than meat, it seems.
Shouldn't we all be writing assembler or C (the portable assembler)? Where does boilerplate stop and meat start?
Yet, the suggestion that code can and should be generated from the data it's supposed to interact with is still heretical (well, unless the input to the generator is some mammoth xml file :) ) most places. This still baffles me. In the end, it's the data which is important to the (human) client, not the code. Moreover, the data will outlast the code; moving mainframe applications (in COBOL or PL/1 mostly) to java on "servers" is a thriving sub-industry. If these applications had been built from the start on a standardized (sql) database engine, swapping the client code from ABC to XYZ is a matter of running the catalog through a different generator.
If the goal of "increasing productivity" is eliminating "busy work", "boilerplate code", and such, then why not embrace UML and build our systems from diagrams? And so on. The line between increasing productivity of all developers and job killing for me and mine is ever present. If I had a nickel for every time I argued with my java brethren over whether to put a constraint once in the catalog, or strewn throughout their source files; I'd be rich.
And if I'd won, the codebase would be a fraction the size, and agnostic about the language/style/framework/team which built the client. Oops.
|
|
Previous Topic
