Slashdot Mirror
Thoughts On the State of Web Development
rmoskal recommends his blog post up at Most Media on finding the right level of abstraction, Grails, and SOFEA. "[Three years ago] I was very excited about Apache Wicket as the way to develop line of business applications with a domain model, CRUD [create-read-update-delete] screens for maintaining the model, and in the most interesting cases, doing something else useful besides. I still like Wicket. It has, as its website says, a small conceptual surface area.' It reminds me of Python in that 'You try something it usually just works.' In many respects, though, Wicket seems to be at the wrong level of abstraction for the for the sorts of line-of-business applications described above. If your team is spending any time at all writing code to produce listing, filtering, and sorting behavior, not to mention creating CRUD screens and the back-end logic for these operations, they are probably working at the wrong level of abstraction. ... Recently I did a small project using Grails and was quite pleased. Grails uses groovy, a dynamic language compatible with Java, and is based on the proven technologies that I know and love well: Spring, Hibernate, SiteMesh, Maven, etc. ... I get all the power of the Java ecosystem without the fustiness and lack of expressivity of the core language (no more getters and setters, ever!)."
First, getters/setters are generated by your IDE of-course, so you never have to write them by hand, however, more to the point, I have avoided many various parts of the 'Java ecosystem', while still using that language to do all sorts of development and really, you don't have to use getters/setters. I use many Java classes as simple data structures, just like C-Gods intended, no getters or setters there, just public or protected fields.
You can't handle the truth.
Using Java for web development is like using a wrecking ball to hammer in a nail. Use something that fits the job better, like Zend Framework, Django or Ruby on Rails. In web development, time to market is everything. Build your application and hopefully you get a large user base. Then when performance is an issue, you should already be working on a rewrite that can incorporate something like Java on the backend.
As I've said before on slashdot, the open-source movement should look at creating a new GUI browser that does desktop-like and CRUD GUI's well. Forcing the e-brochure-like HTML-based browsers to act like desktop/CRUD GUI's is like trying to roll Pluto up Mt. Everest: people have kept trying to pull it off with AJAX and whatnot for more than a decade, but it's still kludgy, bloated, buggy, security-challenged, and version-sensitive.
It's time to throw in the towel and start a new tool and markup language.
Table-ized A.I.
IMHO, programming language wars are silly. The proof of the pudding is in what you can achieve with the framework of choice. After many years of observing the competitors to J2EE, I have yet to see a professional grade alternative to it.
There is no such thing as luck. Luck is nothing but an absence of bad luck.
It rocks until you need to support more than a dozen users. Then you need something like Java, which as proven to scale to meet any demand.
Just ask the folks at Twitter.
Mod me down, my New Earth Global Warmingist friends!
With the amount of abstraction in software development these days, very few people seem to really know what they're doing anymore. This should concern you -- if it doesn't, you haven't thought about it enough yet.
We regularly see new exploits that affect systems that have been live for years, oft-times spanning multiple major versions and platforms. In retrospect these flaws are often usually painfully obvious, but because they have been buried in the layers of sediment of "best practices", "boilerplate" code and underlying platforms, they aren't seen. At least, not until a curious or malicious mind starts poking around.
While this is in part a problem with QA, the deception of abstraction is that it provides a Black Box that is very easy to trust. This affects developers as much as QA.
Are we really wise to keep building on these layers of abstraction? Toolkits on top of frameworks on top of virtual machines on top of operating systems on top of hardware -- even device manufacturers can't keep their locked-down devices from being rooted in a matter of days, sometimes even before release. While many of the Slashdot crowd laugh because there is a sense of social justice in seeing DRM broken, the same exploits may some day be used against systems we rely on. I don't consider myself a fearmonger, but I wouldn't be surprised to see significant digital infrastructure fail at some point, either due to malicious intent or simply instability, at some point in my lifetime. Poor software quality hurts us all.
I realize that I sound like an old man yearning for the better days, but I learned to program in assembly on 8088s, and I knew exactly what my programs were doing. I'm not saying I want to go back to that, but the idea that most developers these days don't even understand memory management or garbage collection blows my mind. Asking for a new language because getters and setters are too much of a hassle? Somebody get this kid a lollipop, please.
I read the article (no, I'm not new here) and the author's main point, emphasis original, is this:
Where does he draw the line at "wasting time writing code"? This is exactly the mindset that leads us to buffer overruns, SQL injections, and many other problems which should not make it into production software. He wants his developers to abstract as much as possible, but code reuse all too easily leads to blind acceptance and a failure to understand what is being imported. If he trusts that all those acronyms on the blog post he wrote are bug-free, then I would hate to be one of his customers. Not that there seems to be many categorically better options available.
In the end, I think we need to abandon the cycle of "software bloat to more powerful hardware to software bloat..." and figure out what we can do with what we have. Good grief -- look at CUDA! We have orders of magnitude more processing power in a single video game console than all the world's computers before World War II, and available memory is simply insane. Take a look at what Farbrausch has done, and you will see what dedicated focus on efficiency can do.
Stop being lazy, understand what you are doing, understand what you have available, and use it well.