Posted
by
kdawsonon Sunday April 18, 2010 @06:12PM
from the sofea-meet-soui dept.

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.

Geez, again with the same excuse: "My IDE generates them automatically". Yes it does, but Java IDE's are not the only one's that can do that, duh.

Deeper problem is that you later have to use those "fully automatically with just a few special clicks" getters and setters like this in your code: point.setX(point.getX()+1); instead of just writing point.X++;2.7 times longer line than it ought to be. And with current java IDE-generated non-VM supported getters/setters all of the shorthand abbreviations such as +

Geez, again with the same excuse: "My IDE generates them automatically". Yes it does, but Java IDE's are not the only one's that can do that, duh.

- 'duh' what? Where do you see me arguing against this point?

Deeper problem is that you later have to use those "fully automatically with just a few special clicks" getters and setters like this in your code: point.setX(point.getX()+1); instead of just writing point.X++;

- again, what? I said I use classes often without getters / setters, so this is exactly what I can do. Do you understand that getters / setters are a choice and are not mandatory? They are not required by the language. I think you do understand that, you just are not understanding what I wrote in my first comment.

If you're really sweating the point.setX(point.getX()+1) call pattern, pray tell why don't you create a point.increment() method? Of if you need more flexibility, a point.add(1) method? It seems like you're really trying to program like an idiot to prove you point that idiots program in Java.

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.

The idea with getters and setters is that in the end the value may not actually be a field (it may be computed), and interfaces can't contain fields. Plus the JavaBeans style naming conventions are pretty ubiquitous in the Java world... not sure if everything works right with just plain fields like that (it may).

At my job they like you to use getters/setters for everything, even inside the class when accessing private members. To me this is pointless and a waste of time requiring a method call when you really don't need one. I can understand the reason for encapsulation where you want to protect certain things from outside access but to have to use this.getter() rather than this.variable inside the class really makes me want to puke. IF java wasn't garbage collected and the getter/setter actually did something r

Programs should be written for people to read, and only incidentally for machines to execute. I, for one, am not willing to read three additional lines of code and declarations for every line of code that actually does something.

Once again, (you are not the first coming up with this), you can chose to view or not to view various things in your IDE, like getters/setters don't need to be visible, however, I am saying that my choice is often not to use them in the first place and just to access a public/protected field directly without any getters/setters, it certainly is NOT FORBIDDEN in the language.

No, I think that is exactly what the article is about: your IDE is the wrong level of abstraction. Adding generators does not change that, as long as you still view, save and edit the generated code. Code generation in general is usually a sign of things going wrong, especially if used as scaffolding.

The right level of abstraction is thinking about data, not state, and not code. Define your date, and please use a more modern approach than SQL, w

I am building big systems quickly, my comfort zone is about speed of development, security of the product, speed of response, minimization of errors, ubiquity of the platform so that the development is not cornered by lack of people familiar with it.

I am not about to do something so stupid as change a platform for the sake of changing platform when a business depends on it. Go write a blog or something.

(oh, and getters/setters are not mandatory in the language so I often skip them and use fields directly,

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.

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.

...are doomed to reinvent J2EE. Badly
I confess that I haven't tried any of the frameworks mentioned by the parent. But I have had conversations with people who have, and here are some questions that I have for the folks who think that the people who came before them (and invented J2EE) are stupid:

Can your framework handle two-phase transactional commits when it interfaces to other applications?

How well does it support single-sign across apps deployed across different servers but behind a reverse proxy that unifies them under a single domain?

Can you cluster multiple hosting servers for your app to minimize downtime during app upgrades? Does your application sessions failover to the other members of your cluster correctly, if so?

Can you take legacy code and layer your app around it without needing to rewrite the legacy app? Can you do this even if the programming team who wrote the legacy app is no longer around?

When you discover that you are having intermittent glitches (slow responses / server 500 response codes/etc), do you (a) reinstall (b) upgrade to a newer version of your framework / OS / whatever (c) Troll the user forums for your product / framework and hope that someone has seen your problem before. (d) Pull three all-nighters reading the source code to your product / framework?
[Hint. The right answer is (e) Put your product into a supported trace mode and get your vendor to support you]

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.

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 i

Spring is the only real alternative, but given the state of J2EE it has taken until version 5 that JEE really became usable, you speak mostly of the merits the app servers give you but seriously until JEE 6 JEE in many areas was a mess (EJBs while good in idea were barely usable due to the XML bloat, the entire ORM part was broken so people had to refer to alternatives outside of the JEE realm)The first version which I would call outright excellent is JEE6 and this one is the first which beats Spring in the

IMHO, programming language wars are silly. The proof of the pudding is in what you can achieve with the framework of choice.

The flaw in your reasoning is that programming languages can and do affect the expressivity of frameworks that are written in them.

An example that has recently become very obvious is the presence of first-class functions in the language. If you've seen the newer additions to the.NET class libraries, or what people do with Java-with-closures prototypes, you should know what I mean. If you haven't, then are you really in a position to judge?

The professional grade alternative is that you drop the half the superfluous bullshit J2EE seems to support and build and honest-to-God web architecture like God intended: shared-nothing workers on the web server and scale out on the database, use job queues that go to a compute farm if you need that. A decent web framework has transactions built-in so I don't even have to think about the problem, SSO is handled with a cookie and a generic backend that plugs to whatever you want, you don't need special clus

Really, try it. You can leverage many existing Java-centric frameworks. Sitemesh, Spring and Hibernate are fast & stable. Grails takes the 'suck' out of using them. Rewrites are easier, since you are already 1/2 way to Java. Find the bottle neck, rewrite it in Java and away you go.

Jython supports Django I've read, so again you can theoretically get the best of both if that's important.
Personally, I dislike the Java ecosystem due to its bulkiness. However, for some particularly high-CPU tasks (complex search), it can fit into a larger REST environment nicely via Restlet or Django.

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.

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.

Yeah, they're just java libraries that support executing script code so there shouldn't be any problems using them in an applet.

You can do anything in an applet that you can do in a Java app. The only difference being applets tend to be sandboxed more heavily due to the obvious security issues associated with their distribution. I should point out that you can sandbox regular Java apps in the same fashion, but it's less common.

Most of the popular languages for the JVM have compilers that let you compile to

The main issue with (X)HTML is that it's not meant to be used for application user interfaces. This shows partly in the types of "widgets" (form elements basically) available and in the severely lacking layout possibilities.

Building basic user interfaces for various business web apps is probably the most frustrating part of web development, and the frustration coming dealing with building user interfaces using HTML, CSS and Javascript is definitely a major contributing factor.

Building basic user interfaces for various business web apps is probably the most frustrating part of web development, and the frustration coming dealing with building user interfaces using HTML, CSS and Javascript is definitely a major contributing factor.

This was my view on web development for quite a while, until I gave jQuery a try and put aside some time to properly understand CSS. It's honestly not that bad.

There still is a bit of frustration (in getting everything perfect on all major browsers) but t

Essentially HTML is the world's biggest legacy system. The problem with finding a replacement is that everyone in the world uses HTML, thats a consequence of what state the technology was in when the internet took off. Even if you could find a replacement, convincing everyone to switch over is a pretty gargantuan task, esp. when you factor in the chicken and the egg issue, you aren't going to get people to switch to your platform of choice unless there is content,

The only problem with HTML is in the interpretation. With every other language being high or low level if it runs it runs the way the programmer intended. With HTML, one line of HTML can behave differently for each browser that interprets / renders it. Any method of communication falls on 2 people to be useful right now we are not getting that. If you had to write different classes for each of the possible targets you end up with a messy bloated heap. Now with web developers in many cases throwing CSS/

Interesting, but why not take it one step further and do a lazily-downloaded environment, so as that applications can be super rich like desktop apps and still have all the advantages of web apps? app components could be downloaded strictly on a need basis and only when new versions are available. The mechanism will make sure components are cached locally in an appropriate manner.

I dream of the day that I can import components from URLs... (import www.mycompany.com/mycomponent, for example).

a lazily-downloaded environment, so as that applications can be super rich like desktop apps and still have all the advantages of web apps? app components could be downloaded strictly on a need basis and only when new versions are available.

They do indeed download classes (or, in case of ClickOnce,.NET assemblies) from the web as they are needed, and also do version-checking every time this happens, so if class/assembly updates on the server, it will be automatically refreshed on the client next time it is used.

Now, I don't think either one lets you reference components from varying base URLs - at least ClickOnce requires a single base URL for all components, if I remember correctly.

Webstart allows you to specify extension URL's, that are different from the Base URL....(though, admittedly there is an existing bug that prevents resources within these extension URLS from redownloading should they be updated:-( )

The VM provides security, not visibility to the code. 99.99% of all people don't read the Javascript in their web applications, they let their browser deal with security issues.

Microsoft has a good strategy with.Net. Any code (yes binary) that is loaded from a URL not in the user's trusted sites list runs with pretty much zero permissions. It can display windows and communicate back to the site it came from, but nothing else.

It's not even just that: as soon as you get out of the three column format, HTML has trouble. The idea of CSS is sound, to separate the presentation from the content, but in practice it fails (if you don't believe me, ask yourself this: when was the last time you used a

div

as a line break? That's really not what they're for).

It's sad, but the problem is HTML has been developed by a committee, and not just a committee but a committee with conflicting goals. Some people want to make desktop-like GUIs, oth

It’s called QtDesigner & friends. Or XUL. Look it up.Basically, it’s an old hat. A very old hat. I did things like that back in 2003.

I’m back to plain and simple... compiled desktop/server/mobile programs. I still use something like XUL (but in EBML with a tag-mapping attachment), but I mostly generate that “XUL” from SQL DDL, as an itermediate representation, and plain machine code as a final result.As an example: A complex application usually takes the time to write a cle

It's time to throw in the towel and start a new tool and markup language.

Or maybe spend long enough on a single version to make something stable. The "new" tool and markup language has been done plenty before. SGML wasn't good enough, so then came HTML, then HTML wasn't good enough, so there was XML. Apparently now XML isn't good enough, so we need SuperMegaMarkUpLanguage. It's funny, but software projects actually require time to mature. There needs to be a phase of "hmm this almost works, except..." instead of "these really minor annoyances are no good, gotta start over."

Yeah, except coders usually make *TERRIBLE* GUI designers. And FOSS coders are often too arrogant to think they need to work with actual designers. It's why so many FOSS projects have absolutely abysmal GUI's (and piss-poor documentation, since coders also think they don't need technical writers). So expecting a bunch of coders to produce a great browser and a markup language that's largely aimed at layout without a strong team of designers behind them (like they have at Mozilla) is likely to produce horrid

Sooner or later ANY client small or large, will come up with a 'change' that will require going way down the level to the underlying language, because of the intricate and out of the ordinary way they will ask it.

moreover, rarely will the two changes requested in similar area by two different clients will be the same. every business has their own style of running things, and what they will ask of you will differ from each other. this is even valid for small ecommerce presences on the web. you cant imagine t

piece of software that a million people have hacked the shit out of it's the thing that Delivers.

thats the gist of the concept. it was freely available, its code was simple despite being a mess, and million people hacked the shit out of it. therefore, despite being a mess still, it can work as anything, and therefore, it delivers.

I've been using this lately, and it beats the crap out of anything else I've seen. It _feels_ like I'm writing a swing app, but it's ajax enabled without writing javascript.And since it keeps _all_ the logic (even loops to generate tables or bullets) inside java code, refactoring is trivial. I will never go back to a framework with a separate templating language again (I'm sorry, Django!).!

I used Wicket a few years ago. It wasn't god-awful, but between the irritation of keeping the HTML in synch and of trying to make a custom component or even fix Ajax behaviors gone awry, I don't think it pulled its weight in the power/complexity added ratio.

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.

I've been watching "play" for a while now; it seems to be getting pretty good press. Can you go into a little more detail what you like about it? What's your "work flow" like if you want to add, say, a new screen? How [well] does it interact with your DB layer, etc? Would love to hear some real world stories; both good and bad.

I've been using Stripes [stripesframework.org] for a while now and what I prefer about the approach there is that it does not mandate how to interact with the data access layer. In an MVC design pattern approach, Stripes focus strictly on the V and the C and leaves the M alone.

Web development has expanded into a very large and exciting platform for content and applications, both on the server and client.

Still, every time I open an article about it, all I see is a developer who's tortured at the thought of generating endless CRUD forms and writing elaborate explanations, why he had no choice, *no choice* at all, but climb high up on the abstraction ladder, so that he can do basic validation in cute one-liners.

That's great, but that's just a minor fraction of what web development c

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:

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.

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 [wikipedia.org] 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.

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.

No, rewriting functionality that already exists in stable, tested libraries is the mindset that leads us to buffer overruns, etc.

I'm much more upset about the lack of innovation in the way that people interact with computers. I know, Rome wasn't built in a day, but it seems like our OS could at least have the graphic appeal of say, Quake 2. Our Desktop is still so flat and limiting, and online collaboration is still so hokey and primitive. All this could be fixed, and largely for free if based on currently available FOSS. Instead we're cloning Windows XP with a prettier menu shade. WTF?

I'd like a 3d online space where my avatar can stand in the rustling grass of a windy prairie. In this environment, are a variety of nearby locations: A Desk...

And on that desk, a computer. I virtually sit down in the virtual chair in front of my three-dimensional virtual desk, press the virtual power button, look at the virtual monitor (300 feet wide!) and am confronted with... ad infinitum.

This is about getting the post blog entry function to work. the html is more or less trivial. The server side is a bigger issue, as you have access control. data sanitation, and bunch of other minor details that will get your website compromised if you screw them up

You only can make rails scalable by going into the java domain even by just moving over to jruby to get threading... but even then rails follows patterns which have their limits the more you need scalability the more you have to move away from what rails provides ootb and the less you save time.But in the end, scaffolding is the only real timesaver there, and rails has no monopoly in this area, and I would not even call a scallfolder too much of a timesaver it saves some time for the standard coding fronti

In Java, its a weakness about interfaces- you can't have a data member in an interface, so any interface needs to use getters/setters.

In most languages, its so you don't give direct access to internal variables. In C++, you can just make the data member public and assign to it like a normal variable. But then you can't protect what is stored there or do sanity checks. Or you can write a getter/setter to do so. And if you decide to change from one to the other, you need to go back and change every acces

I would not call the interface mechanism a weakness, interfaces come straight from eiffel and are contractual "interfaces" in a sense that they allow a loosecoupling of classes while still forcing you to some standard which reflective mechanisms do not. Interfaces are an awesome mechanismfor certain things.

Javas problem in this are is not the interface, they are heavens sent it is the lack of a real property mechanism. True you dont write setters and getters anymore, but something is wrong if the average cl

Some languages like C# provide syntactic sugar to allow you to use foo.bar=9 and have that call a function, but there's problems with this- its impossible to know when you're calling a function or not by inspection, so you can have bugs that are difficult to find by code inspection- = does not always do what you expect it to. I prefer writing getters and setters to that.

If you're using getters and setters for all field access, then you're not any better off than seeing assignment to a field in C# - you still don't know if those methods you call are trivial (just return/set the wrapped field), or whether they do expensive computations.

The whole point of C# properties is that, in most cases, those getters really are trivial and field-like. In fact, Framework Design Guidelines (the de-facto standard API style guide for.NET) say that you should only use a property when it doe

I know them back from the good old TurboPascal/Delphi years, properties never really have been an issue .This is one thing I have been lacking from java since 0.7:-(I personally think the sideffects of having endless getters and setters in the code is worse than the sideffects of applying a property wrongly.Btw. I do not particularily like the auto propertying languages like Groovy do.I personally prefer to mark instance variables as properties.

Too bad scala is awful. Great for academic use, aka annoying students. Why anyone would want to take 10x longer to code in the real world means a. they are dumb, b. they have money to burn and don't care.

I would not scale annoying it is a nice language, but I am not sure about its approach of pressing domain specific language mechanisms into the core.Outside of that it is nice, although I settled for groovy for my scripting language needs, in this area. Scala does not bring too much to the table for me to switch over for the occasional usage I have for this language domain (which is mostly, prototyping, switching over whenever closures make sense etc...)The biggest problem is that many companies have a no s

Is it just me or is software design generally to difficult, you just should define your system in uml with all rules in place and then generate the code.The problem is all this fails usually in detail, where you have to deal with platform specific issues, client specific issues, rules you cannot cover in the description language, deployment szenarii, existing infrastructure, whatever you name it.

This is a mismatch of ui paradigm. Ajax is used to enable rich client interfaces where the back button simply does not make sense anymore unless you save a continuous application stage (which again is not possible with ajax due to its non continous flow)The limited programmability of the back button does not help there too much.

On the other hand the back normally is used as a document specific buttom which should help the user to jump back into the "DOCUMENT" historywhich a rich client app almost never is,

I think so too, Wicket is a really nice webapp framework, probably one of the best there is, and since it limits itself only to the ui aspects you can use whatever the entire java ecosystem provides in the backend area, which is a lot. I am not sure if moving to an abstraction like grails provides really will make him happy, but I have yet to use grails (although I work with lot of groovy)I only can see the auto scaffolding being a timesaver for him, outside of that he just replaces one language with the ot