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!)."
Or just dump the server side all together, seriously with the maturity of the JavaScript frameworks, there is no reason to build on restrictive server side technologies, just build your UI with HTML/CSS/Javascript and communicate back to RESTful services implemented in whatever language the back end team chooses. This fixes a lot of things that where broken in web development not to mention that it is a far faster development style and is more maintainable to boot.
These kids today who act like there's some art to programming that's instinctual, that they should be comfortable programming when they don't know shit about the language they're using. Guess what, C is the most comfortable language ever invented. Perl is one of the fastest to write.
Of course, perl is designed for text. HTML, while a subset of "text", is a pretty complex markup language. To generate such code using another language is not trivial. Then you're dealing with networking, web servers, the internet, unknowns like browser type and user screen resolution. Then you have various databases on the back end. It's a very complicated problem yet kids think somehow the computer (or someone else) should just solve it.
The problem is that frameworks are generic and your app is specific. Yeah, the basic types are always there, CRUD, forms, lists and datagrids. But the amount of variance between two "lists" can be huge. A styled list that may work great for a list of books might be horrible for a list of people.
There's no way a framework is going to define base types for every possible thing you could have in a list. The frameworks and object-relational mapping engines are just tools to assist you. You still have to classify everything and their interactions. You still have to define a logical flow for every feature. You still have to test everything. That's what a programmer's job is! So, kids, you're never going to have something that will abstract away the programming. As much as you'd just like to point at the computer and magically create an "app" like you paint a picture, it's not possible, has never been and never will be. "Fustiness and lack of expressivity"--shut the fuck up and get off my lawn.
Cool! Amazing Toys.
Rails? Been there. Grails? Done that. Both are decent. Rails is very good, but the abuse of open classes gets old quickly. Grails is ok, but it's really just a thin veneer over a complex mix of Java projects, and God help you if you run into any problems, because you'll be dealing with a stack trace that's 1000s of lines long, and you be troubleshooting these underlying complex java libs. For me, the play framework (http://www.playframework.org) is the best Rails-like approach on a Java platform. It stays very close to rails, so if you know rails learning it is easy. It's very pragmatic and very fast. It doesn't require a compile step to see your changes. It just works. Best of all, the code is clean and easy to troubleshoot. I suggest you check it out.
You do not think OO enough. The problem is that you think about, "how can I modify an object" instead of "what services that class should provide". You rarely need inc, mult, etc, they are very primitive operations, and indicate a poorly designed interface -- as you noted, too. The class here is a Vector (or Point, which is the same), so instead of inc, mult, you can simply use add(Vector delta), and scale(int lambda) -- which are the natural operations for a Vector. You can also have rotate, mirror, etc.