(This is an excerpt from an email, but I felt that rant wasn't in a public enough forum)...
*** Starting Rant ***
"Why do we continue to re-invent the (broken) wheel?"
The talking heads continue to keep themselves popular on the conference circuit by declaring "new" languages sexy. Where was Martin Fowler when I was playing around with Ruby in the late 90's? Declaring Java the next sexy language.
Do I like Ruby / Groovy / ${insert cool language here} ?
Sure, they're all cool.
I like Lua myself, and have had fun the perl, python, smalltalk, ADA, and a score of other languages in the past. But how about we stop trying to fix the symptoms of our programmatic issues by creating new languages and instead focus on the REAL problems behind them.
Why does web development suck compared to the days of desktop development? First and foremost is the transport, and not far behind is the statelessness. Statelessness has been solved somewhat, but why is it that web development has been going on solid since the 90's and we still have to be concerned with this paradigm of request-response? Why hasn't this communication layer been abstracted away so that development can focus on the important aspects of the project.
JSF and other overly complicated frameworks may help with that issue but introduce plenty of problems of their own. We're absolutely destroying the KISS principle every time we adopt the next flashy framework or language that promises easy set up and next to nothing maintenance - these always have a cost and rarely fix the problem.
How do we fix this? Not with a language or a framework, but a tool. A new browser. One that is actually INTENDED to serve applications and be more than a terminal (and no, Flex, OpenLazlo, etc. won't suffice - those are shoehorn patches). At least that would be a great start and the best first step. Then follow that up with some other improvements to ease data access, configuration, etc...
*** Rant Wind Down ***
Above all I'm beginning to tire of the declarations, musings, and "The Thinker" posings of the Fowler's, Eckel's, and Cockburn's of the world. Look closely (or not so closely) and it's apparent they have their own agendas. They are paid extremely well to pontificate and then talk about their pontifications on the circuit. They are paid just as well the next year on said circuit when they refute what they had spewed just 12 months before...
Not that these guys don't have valuable insight and a vast amount of experience, but they make mistakes - consistently. That's why every other year they are touting the next greatest technology... A good example was the panel of last year's NFJS downright berating Struts - a framework they were in love with only a year or two before.
So my advice is take what they preach, decide on your own if it makes sense, and then either disregard it or tuck it away for use later. Some of the ideas bandied about simply aren't practical (pair-programming being one of them) while others are just goofy (writing a test for a class that doesn't exist just to watch the test (amazingly) fail).
*** End Rant ***
I apologize for this rant but I'm mired in writing documentation and I have reached my boiling point and have had my fill of Magic Cure All Languages (MCAL for short)...
Also, feel free to take my advice above and disregard any and / or all of my musings :)
*** Starting Rant ***
"Why do we continue to re-invent the (broken) wheel?"
The talking heads continue to keep themselves popular on the conference circuit by declaring "new" languages sexy. Where was Martin Fowler when I was playing around with Ruby in the late 90's? Declaring Java the next sexy language.
Do I like Ruby / Groovy / ${insert cool language here} ?
Sure, they're all cool.
I like Lua myself, and have had fun the perl, python, smalltalk, ADA, and a score of other languages in the past. But how about we stop trying to fix the symptoms of our programmatic issues by creating new languages and instead focus on the REAL problems behind them.
Why does web development suck compared to the days of desktop development? First and foremost is the transport, and not far behind is the statelessness. Statelessness has been solved somewhat, but why is it that web development has been going on solid since the 90's and we still have to be concerned with this paradigm of request-response? Why hasn't this communication layer been abstracted away so that development can focus on the important aspects of the project.
JSF and other overly complicated frameworks may help with that issue but introduce plenty of problems of their own. We're absolutely destroying the KISS principle every time we adopt the next flashy framework or language that promises easy set up and next to nothing maintenance - these always have a cost and rarely fix the problem.
How do we fix this? Not with a language or a framework, but a tool. A new browser. One that is actually INTENDED to serve applications and be more than a terminal (and no, Flex, OpenLazlo, etc. won't suffice - those are shoehorn patches). At least that would be a great start and the best first step. Then follow that up with some other improvements to ease data access, configuration, etc...
*** Rant Wind Down ***
Above all I'm beginning to tire of the declarations, musings, and "The Thinker" posings of the Fowler's, Eckel's, and Cockburn's of the world. Look closely (or not so closely) and it's apparent they have their own agendas. They are paid extremely well to pontificate and then talk about their pontifications on the circuit. They are paid just as well the next year on said circuit when they refute what they had spewed just 12 months before...
Not that these guys don't have valuable insight and a vast amount of experience, but they make mistakes - consistently. That's why every other year they are touting the next greatest technology... A good example was the panel of last year's NFJS downright berating Struts - a framework they were in love with only a year or two before.
So my advice is take what they preach, decide on your own if it makes sense, and then either disregard it or tuck it away for use later. Some of the ideas bandied about simply aren't practical (pair-programming being one of them) while others are just goofy (writing a test for a class that doesn't exist just to watch the test (amazingly) fail).
*** End Rant ***
I apologize for this rant but I'm mired in writing documentation and I have reached my boiling point and have had my fill of Magic Cure All Languages (MCAL for short)...
Also, feel free to take my advice above and disregard any and / or all of my musings :)
No comments:
Post a Comment