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!)."

Comments

getters setter :)

[roman_mir]

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.

Re:getters setter :)

[Anonymous Coward]

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 ++ -- += -= *= etc are unusable. Good luck writing any complex formulas on one line with such getter/setter syntax :P

Re:getters setter :)

[Anonymous Coward]

If you are using Java 1.6, look into project lombok:

http://projectlombok.org

You annotate your class with @Data and the getters and setters are generated as you add/remove private fields.

Re:getters setter :)

[hpoul]

i still don't get why people think auto-generated code is easier to maintain than hand-written one.. (i think there was some saying that code should be optimized for reading?)

if things can be auto-generated by an IDE, why not auto-generate it during run-time? (obviously only the first time to avoid performance impact). don't get me wrong.. i like java.. but compared to the web frameworks available in other languages (e.g. python with django) all java frameworks are just a pain (struts 2, wicket, JSF, ...) which are barely bearable with the right IDE.. (yes, if you are developing your next online banking application or million hits per second online store it might be necessary..) -- that beeing said, i still prefer the next best java project over some php kiddie-project.. at least i can find my way around getters and setters, there is no way i stay sane trying to figure out where some weird global variable come from... (speaking from experience.. which means i've probably already lost my sanity anyway, so feel free to ignore me ;) )

Re:getters setter :)

[CptPicard]

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).

Re:getters setter :)

[binarylarry]

all of the shorthand abbreviations such as ++ -- += -= *= etc are unusable

So you're saying we can't implement Brainfuck for Java? OH NOES

Re:getters setter :)

[Anonymous Coward]

Jokes on you, necro-boy!
She was a vampire who died of leprosy and now you're gonna have to pay for your blood at the Wal-Mart pharmacy and drink it through a straw after your teeth fall out!
And guess which part of your anatomy is gonna fall off first!
Fuckin' dumbass necrophiliacs can't even read warning signs at gravesites.....

Re:getters setter :)

[Anonymous Coward]

The problem is that the implementation sucks. How about rather than making everyone call functions to get or set variables, making the access to the variable automatically call the appropriate getter or setter if it exists? You could even add a "controlled" member type (to public, private and protected) to indicate that the variable should only be accessed via getter/setter (read-only variables would then have no public setter, as opposed to being written to directly)

Re:getters setter :)

[roman_mir]

As long as this is my project, everything will work without getters/setters where I choose not to use them.

Re:getters setter :)

[roman_mir]

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.

Re:getters setter :)

[yabos]

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 rather than just setting a pointer then I could understand using the setter/getter inside the class.

Re:getters setter :)

[ebuck]

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.

Re:getters setter :)

[binarylarry]

ooh tough guy, name calling as Anonymous Coward.

You seem to be the guy. I want to be the guy too, Anoncow. How can I be the guy?

Re:getters setter :)

[Bill Dog]

What if later on you need to add logging to the accesses of a member variable for debugging, or protect it with a lock to support a new multi-threaded requirement, as examples. Multiple points of access to a variable is bad, period, not just when it's "external" access, for arbitrary definitions of "external".

Re:getters setter :)

[drewhk]

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.

Re:getters setter :)

[Daishiman]

The fact that you even NEED an add() or increment() method shows the idiocy of the programming language.

Re:getters setter :)

[daveime]

Writing a METHOD to do basic arithmetic options such as incrementing a variable by 1 ?

Look, objects and have their place ... that doesn't mean you have to use the fuckers everywhere !

Methods encapsulate a commonly used piece of code, and are very useful if that code changes in future. How exactly could "increment a variable by 1" EVER need modification at a later date ?

If you use that as your guideline, you'll never find yourself making dumbass statements like "point.incrementX(1) is just as clear as point.X++", and looking like some OCD maniac coder.

Re:getters setter :)

[roman_mir]

point.moveLeft(1) is as valid as point.x-1

Re:getters setter :)

[canistel]

Sometimes methods also need to do things behind the scene... so in your example, incrementing a value by 1, well there might be a number of listeners that are interested in the fact that that variable's value was adjusted.

Re:getters setter :)

[K. S. Kyosuke]

First, getters/setters are generated by your IDE of-course

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.

Re:getters setter :)

[roman_mir]

I guess I will have to leave the same comment over and over again. What in the language (Java in this case) makes you do any of that?

This is a dumb point.

x++ works
point.x++ works
point.moveRight(1) works

choose your poison but don't blame a language of the choice of a programmer

Re:getters setter :)

[roman_mir]

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.

Re:getters setter :)

[roman_mir]

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, it's not a crime, you know.)

Re:getters setter :)

[roman_mir]

Uncle Fester?

Re:getters setter :)

[thsths]

> First, getters/setters are generated by your IDE of-course

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, which is 90% focused on representation, and only 10% on meaning. Once you define your date, the relationships, the restrictions, one part is done. The next part is to define how to view it and how to edit it. It is classical MVC, actually, except that V and C can be specified together if you have a clever basis. Xopus does most of that, for example.

Whether you like it or not, the goal is to do simple business forms completely without programming. And I agree: the best code is code you don't need to write. SharePoint is doing quite a good job there, in that you get basic functionality without any code, you have quite a flexible data model, automatic or GUI design MVC, and the option to extend where necessary. It is the right level of abstraction (although not necessarily the best implementation).

Re:getters setter :)

[roman_mir]

Did you mean

This is Madness?

This is JAVA!!!!

Re:getters setter :)

[roman_mir]

And by the way, what's with the 1 being used without a proper constant? There should be a JNDI call for the shared environment constant there.

Re:getters setter :)

[sjames]

No wonder people are saying Java is the new COBOL if you think those are even remotely close to Brainfuck!

Re:getters setter :)

[sjames]

The problem is when someone with no taste chooses them and then goes skipping off into the sunset leaving the steaming pile behind for others to maintain.

Re:getters setter :)

[roman_mir]

how is that different for any other language and people without taste working with them?

Re:getters setter :)

[sjames]

The number of people calling it a "feature" and actually implementing a "produce crappy code" button on the IDE. At least in other languages the culture expects you to have to WORK at producing crappy code so you tend to produce less of it.

Re:getters setter :)

[roman_mir]

And yet, the code produced in the world of Java, though maybe crappy and verbose will be much safer than if it was created in many other languages that were used prior for the same work due to at the very minimum the VM doing garbage collection, server containers, limiting any kind of damage and most importantly the number of available libraries and solutions, which, you have to admit, limit the scope of development done for a project. Those people who create 'crappy' code in Java would create code just as crappy in anything else and if this other thing they could be working in did not have quite as many libraries, as many artificial limiting factors - VM, containers, various code generators, the code produced would have been worse and the errors would have been worse.

I know it was a run-on sentence, but hey, I said I use Java in my projects :)

Re:getters setter :)

[abulafia]

Code generation in general is usually a sign of things going wrong, especially if used as scaffolding.

Exactly.

More generally, this applies quite well to other things other than "simple business forms". Writing software to write code to enable the writing of software against other code is a sign that you're doing it wrong.

Completely aside from being trapped by tools, crappy syntax, trapdoor edits that bite you in the ass a point release later, etc., it is a sign that whoever thought up the interface that requires a code generator was solving the wrong problem.

And no, @synthesize and friends are not reasonable solution. (I realize I'm not talking about Java anymore.)

Re:getters setter :)

[sjames]

Urm, so java is for people who probably shouldn't be coding but since they are, it at least limits the damage?

The problem is that once a shop gets geared that way, it can never again attract people who SHOULD be coding.

Re:getters setter :)

[roman_mir]

I remember I was working for a company called Symcor around 10 years ago, it was my first contract (never looked back at permanent jobs) and there was this thing by the marketing, they were awarding these 'blue balls' or 'green balls' - little balls people squeeze for stress relief with the company logo on it. The marketroids were talking about how they have the best development teams etc. I talked to one of them, the truth was then and for that company, but I am sure it is true now and for many more places: they hire permanent people in the 51 percentile of the pay scale.

That is it. If you hire people in 51% of pay scale you cannot have the best people, you will end up with the novices, with people who don't really care etc., and it was obvious.

Still, they were building systems and they are still doing so for the banks. What can I say, maybe most people should not be allowed to do what they are doing and probably this is true in all professions, not only software development. In this world it is then better to have tools that will limit the damage, because sure as hell, the best people will not be working on most projects.

Re:getters setter :)

[sjames]

I think the problem is much much worse in IT than in many professions. Even the doctors who graduate last in their class can probably handle a cold without killing the patient. I'm not that optimistic about the bottom of the barrel programmer.

I certainly don't expect more than half to be above average :-) but I'd like to think that 51st percentile should be at least decent.

Re:getters setter :)

[JSlope]

You can try http://www.playframework.org/ it doesn't require getters and setters, and for a Java framework it's quite cool.

Re:getters setter :)

[roman_mir]

Thanks, but I already wrote my own web-project generator, CRUD generator tools for DBs and a few generators for the web-app front end functions.

Re:getters setter :)

[binarylarry]

Dumbass,

If you look at brainfuck syntax and the operator example I quoted, you'll see a slight resemblance.

Re:getters setter :)

[JSlope]

Me too:


FormPers
and some examples how it works

Re:getters setter :)

[sjames]

Sure, However simply having those operators is not the same as being brainfuck.

Otherwise, all programmers program in English, even LISP programmers. They must, they have English words in their programming languages you stupid little shit.

java centric

[thetoadwarrior]

This isn't really about web development in general but Java web development and writing getters / setters is the IDE's job.

Re:java centric

[CarpetShark]

No, writing getters/setters is the language's job. For example, in python, you don't need to write them at all. You simply write code that accesses variables directly, and if you need to override that variable access with a method wrapper after the fact, you can. Easy natural expression, AND future proof design, without worrying about all that getter/setter crap. Java did a lot of things well (at least compared to C++), but not everything java promoted was optimal.

Using Java for web development

[Banacek]

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.

Re:Using Java for web development

[Anonymous Coward]

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.

Re:Using Java for web development

[Lennie]

I think the only reason this even made the frontpage is because the editors like a good discussion.

The subject pretty much doesn't interrest anyone, right ?

Re:Using Java for web development

[Daengbo]

TFA (Shock! I read it) says that this is his new preferred method. Separate all the server and client-side logic. Push almost all the logic into the client.

Re:Using Java for web development

[Tumbleweed]

Using Java for web development is like using a wrecking ball to hammer in a nail.

Actually, *that* sounds pretty effing cool, almost Mythbuster-like! I'd like to try that some time. But using Java for web development? *That's* just crazy-talk.

Re:Using Java for web development

[SQLz]

He didn't use Java, he used Groovy.

Re:Using Java for web development

[phaggood]

I still have a love/hate relationship with javascript; have tried to appreciate its power but still when I open a .js to me it looks like browser vomit.

Re:Using Java for web development

[zzyzyx]

The language is not the issue here, it's the framework. There are plenty of lightweight, easy to use frameworks in Java as well (wicket, scooter, play! ...).
No need to wait to run into performance issues to use a scalable JVM language.

Re:Using Java for web development

[Whispers_in_the_dark]

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.

Re:Using Java for web development

[thetoadwarrior]

Why use Zend? Even that can be a performance hog for what it's doing. Writing your own framework. PHP is dead easy to learn anyway. There's no need to rely on someone else. That's why there are a bazillion PHP CMS systems. Anyone can do it. I'm doing it and not because I think I'm better but I can build something for what I need fast enough and how I want it exactly.

Re:Using Java for web development

[LukeWebber]

While I agree that Java is a little over-engineered for some purposes, I'm frankly getting a wee bit tired of all these weakly-typed languages that people are using for Web development. I'll take C# or Java any time rather than all this duck-typing crud. You can take Ruby, Python, PHP and all their ilk and stick them where the sun don't shine.
People tend to excuse using these scripting toys by saying "it's only a little website", but these things tend to grow and, growing, to become unmanageable messes. You might be able to get things done, but there are a lot of risks in that approach. I'll take a more rigorous approach any day, and I speak as one who has spent decades working with ill-disciplined languages.

Re:Using Java for web development

[zuperduperman]

You can't compare a language to a framework. There are lots of nice light weight frameworks for Java that make web development quite pleasant. (Stripes is one, for example). The Java language is a bit cumbersome, but given the options for running other languages on the JVM this should not steer anyone away from the Java ecosystem which is awesome for everything server side.

Need a New UI Tool

[Tablizer]

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.
   

Re:Need a New UI Tool

[Animats]

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.

Right. Java applets!

Re:Need a New UI Tool

[mikael_j]

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.

Re:Need a New UI Tool

[Anonymous Coward]

haven't they been trying this with flash, silverlight, javafx?

Re:Need a New UI Tool

[antifoidulus]

Welcome to the world of legacy software.

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, but content producers aren't eager to port everything over to a system with very few consumers.

Re:Need a New UI Tool

[thoughtsatthemoment]

The cost of developing a new browser is high. Just take a look at the code bases of firefox, or webkit/chromium. They are huge. Where are the developers for starting a new one? If you are asking Mozilla to abandon firefox/gecko, it's not gonna happen anytime soon.

Re:Need a New UI Tool

[AlXtreme]

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 the advantages of having a cross-platform interface easily accessible via a browser outweigh the drawbacks. Besides, with HTML5 picking up steam the future of web development looks bright.

Re:Need a New UI Tool

[master_p]

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).

Re:Need a New UI Tool

[Tablizer]

The biggest problem with Java applets is that they pretty much force you to use Java as your programming language. Many of us want language choice.

The second is that it often required downloading a mini-OS-like blob to the client for each session.

A lot of this can be eliminated by create a good "GUI Markup Language" native to the browser such that the common 95% of typical GUI/CRUD behavior can be handled by the markup language, reducing the need for client- and server-side imperative code. (XUL tried this, but they didn't seem to understand the CRUD world.)

I've kicked around ideas for such a markup language, and one idea that seems useful is to allow the developer and/or user to switch between an MDI, tabbed, and "stacked" view of multiple windows/forms via a simple option switch. Most existing interfaces hard-wire you with one choice, or make it difficult to switch. If one can do this in a nested manner within "frames", then it's easy to create things like "ribbon" menus etc. using existing GUI idioms instead of reinventing the wheel. The combo of the tri-type-window switch and frames can build almost anything you see in typical GUI's (assuming you have the common widgets such as editable data grids, tree/outline widgets, combo boxes, etc.)

Re:Need a New UI Tool

[Tablizer]

and most are proprietary. I tried to like XUL, but it seemed how it interacts with server-side and client-side programming/scripting, and it's update approach, were poorly thought out.

Here you can read about draft concepts that I personally think would work well:

http://www.c2.com/cgi/wiki?GuiMarkupProposal

Re:Need a New UI Tool

[icebraining]

The biggest problem with Java applets is that they pretty much force you to use Java as your programming language. Many of us want language choice.

Well, there's at least proofs of concepts for Ruby (JRuby), Python (Jython) and Groovy.

Re:Need a New UI Tool

[icebraining]

You mean like Javascript?

Any interpreted language can easily do it. Just download the file with the code, check it against some hash/public signature and import it.

You could do a proof of concept in Python in 30 minutes, using nothing but the standard library.

Re:Need a New UI Tool

[thoughtsatthemoment]

Security risk if you allow downloading binary. Otherwise it wouldn't be much different from Javascript architecturally.

Re:Need a New UI Tool

[shutdown -p now]

You have just described Sun's Java Web Start, and Microsoft's ClickOnce.

Re:Need a New UI Tool

[binarylarry]

Those aren't really proofs of concept, they're used in many production environments.

The JVM is basically king of multilanguage "common runtimes." There are tons of languages targeting it.

Re:Need a New UI Tool

[Jaime2]

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.

Re:Need a New UI Tool

[phantomfive]

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, others want to make it impossible to define precisely what your page will look like in a given browser (this makes it more portable, in theory). Some people on the committee are thinking in terms of page layout, and some are trying to manipulate it in any way possible to give their browser a competitive advantage.

With all this in mind, HTML makes a lot more sense.

Re:Need a New UI Tool

[jamesswift]

My personal favourite being Clojure
http://clojure.org/

It has excellent Java interop.

Re:Need a New UI Tool

[Jaime2]

Both of those are whole applications, not components. It's more like anything that implements SOAP, or Microsoft's WCF.

Re:Need a New UI Tool

[Hurricane78]

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 clean SQL with the appropriate interfaces (30-60 min), a run of my generator (3 seconds?), then I add a bit of non-standard business-logic (duration depends. Between 20 minutes and a whole week.), use a small tool to generate a color palette and fonts for the design (15 min), edit a tiny text file of annotations, and run the final compilation (<5 min).

Done.
That thing now has a an optional server part, a AJAX browser client, a real full application for Windows, Linux and Mac, and a small but full-featured (no compromises!) phone and PDA client. Done, done, and done.

So with a big of luck, I can churn out a $2000 tool in a day, and a $10000 tool in a week.
But I do not really like doing stupid apps for stupid business clients. So I do as little as possible.
Which explains why I can hang out here all day long, posting lengthy comments. :)

(My main business is game design, but since the money is not coming in as much as planned, I haven’t stopped doing stuff like this yet. Maybe I should hire someone to do it for me, and just become Leisure Suit Larry. ;)

Re:Need a New UI Tool

[icebraining]

Those aren't really proofs of concept, they're used in many production environments.

Proofs of concept using those languages in applets, not in any kind of app.

Or are they used for applets already? I couldn't find much info about it.

Re:Need a New UI Tool

[Tablizer]

The cost of developing a new browser is high. Just take a look at the code bases of firefox, or webkit/chromium. They are huge.

A lot of it is due to backward compatibility. A new GUI standard won't have that problem. And the cost to the industry of doing GUI's wrong is also high.

Further, there are already open-source GUI engines out there, such as the TK family. They just need some taming for WWW use.
         

Re:Need a New UI Tool

[Tablizer]

Essentially HTML is the world's biggest legacy system. The problem with finding a replacement is that everyone in the world uses HTML

First, many would be happy to leave the HTML world if they could develop rich GUI's much easier. Yes, it does require a certain amount of momentum to make a product or tool become widespread and mature enough for use, but the hunger is there. After all, many develop in Flash, ActionScript, and Flex to get richer GUI's in a proprietary way.

Second, this proposed "GUI Markup Language" can borrow many idioms from HTML so as to not be too foreign.

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

I expect intranets is where most the initial momentum would be. There, you have a bit more control of browsers. Complex GUI's are more necessary for internal and biz-to-biz work-related projects than internet services, in my observation because the total usage time per user of internet apps is relatively short.

If you make external apps too complicated, you lose customers, but internal apps can be more complex because they are related to specific jobs that need to be done in which some training and a learning curve is expected.

For example, HTML is generally fine for on-line bill paying. Rich-GUI's wouldn't add much to that experience. But if you have lots of screens, lots of forms, lots of inter-related data grids, and lots of data-entry, such as an internal customer management system, then desktop-like GUI features become quite helpful.

HTML-based techniques are okay for a "Wizard view" where the user is kept in a fairly narrow corridor and sees only a few things at a time. This reduces the necessary training. However, for complex work tasks, you often need several items readily available at the same time and it should be easy to see and access them simultaneously, or at least switch context rabidly.
     

Re:Need a New UI Tool

[Tablizer]

But I do not really like doing stupid apps for stupid business clients. So I do as little as possible.....My main business is game design, but since the money is not coming in...

I generally do like doing biz apps, but I don't like spending long hours trying to get the UI to work right. I've been spoiled by desktop tools that let one build and maintain complex GUI's in about 1/5 the time as a similar web app, which break on browser version n + 1 anyhow.

As far as XUL, I've been disappointed with XUL, per other messages. Maybe they've fixed the ugly or undefined spots since I've last explored it? It seems it's mostly used for FireFox pluggins, not biz apps.

Also note that maintenance is often a bigger part of software effort than original creation of software. It seems you do a lot of "hit and run" contract work where you don't have to fix your creations, or actually want to have to fix them for the money, and so don't care about making them maintenance-friendly. If one is an internal app developer, then maintenance effort needs to be given more attention.
   

Re:Need a New UI Tool

[double07]

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

Hmmm... I know, how about Flash!

Re:Need a New UI Tool

[unother]

Not to take away from your answer, but OP was j/k. He was saying "it's 1996". :)

As for XUL... well, there's another semantically-bloated language.

Oh, and in XUL's case: "it's 1999". :D

Re:Need a New UI Tool

[FlyingGuy]

It is already happening. Look for the AppWeb project towards the end of the year.

Re:Need a New UI Tool

[mandelbr0t]

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."

Of course, when "almost works" ecomes "barely works", or "minor annoyance" becomes "we need someone on-call to deal with this", I can see the need for a rewrite. Maybe I'm not much with XML, but it seems to be in the "almost works" category. Certainly, I would rather see XML reworked than wait for SMMLUL, and Microsoft's fucked-up interpretation of it.

Re:Need a New UI Tool

[Nikker]

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/JS/HTML at the client computer with coding and kludges for IE, FF and others it's insane enough for a person to read it and it sure doesn't make it any easier for the machine to parse it.

If HTML/CSS/JS was parsed and rendered exactly the same way across the board then you could make some elegant contributions and the language set would evolve. Scrapping HTML/CSS/JS is now just an unfortunate act of desperation because of the stupid (not enough of an understatement) browser "wars". Ultimately we need the ultimate sandbox, from there we can write anything we want and the client will be able to make their easy going clicks that the web mentality thrives on. HTML/XML will always be needed in one form or another because it is, 1) good for keeping the description of the appearance concise and 2) the data transmitted can easily be compressed and bad data due to transmission can easily be detected. As always if you had to code any web site in pure Java, C or any other binary compiled language just think about how much you would have to do just to get your banner up. You would have to deal with graphics drivers / OS interfaces, render fonts, deal with screen dimensions dynamically just to show a GIF, all that work for a fraction of a project is a waste. Once we get either cross the board browser/client support we can start moving forward until then complaining about HTML is going to take us no where.

Re:Need a New UI Tool

[shutdown -p now]

No, actually, they work just as GP described:

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.

Re:Need a New UI Tool

[binarylarry]

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 bytecode ahead of time (I've personally used Rhino, Jython and Groovy in this way). This works okay but it still requires a lot of wrapper instructions for handling the various dynamic aspects of scripting languages. This is what Java's Da Vinci and .NET's DLR attempt to simplify and optimize.

Re:Need a New UI Tool

[tonywestonuk]

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 :-( )

Re:Need a New UI Tool

[nstlgc]

Sounds like Silverlight to me. Or WebStart. Or ClickOnce. Or ...

Re:Need a New UI Tool

[elrous0]

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 (if amusing) results.

Re:Need a New UI Tool

[Tablizer]

They don't have to be good UI designers, at least as far as making the end-user-facing part of it, but merely provide the base tool set on which to build UI's. The coders of such a tool don't have to paint a Mona Lisa, but at least provide decent canvases, brushes, paint, etc.

Find actual existing apps that are popular with end-users and practice cloning their interface in the new tool to verify it can provide the necessary GUI and interaction features to re-create most of it. Don't publish it and risk lawsuits, just use it for internal testing. And I don't necessarily mean gimmicky app GUI's with shiny translucent spheres, but practical, time-tested ones. (Add the shiny translucent spheres after the basics are working.)
   

Re:Need a New UI Tool

[Tablizer]

Well, there's at least proofs of concepts for Ruby (JRuby), Python (Jython) and Groovy.

Can you recommend some good runnable online demos that show what they are capable of, especially stuff that's difficult to do with DHTML+JavaScript+CSS?

Re:Need a New UI Tool

[thePowerOfGrayskull]

A lot of this can be eliminated by create a good "GUI Markup Language" native to the browser such that the common 95% of typical GUI/CRUD behavior can be handled by the markup language, reducing the need for client- and server-side imperative code. (XUL tried this, but they didn't seem to understand the CRUD world.)

While this is true, it's also not able to succeed for some of the same reasons that javascript is such a mess: if it's native to the browser, you automatically need to have a standard, and 100% compliance to that standard. And that is something rarely achieved by any browser, never mind in a single release. This would give you the same version problems you're trying to get away from in the first place.

I think the idea is a good one - a cross-platform means of implementing a consistent GUI. But that's currently filled by Java, Flash, Silverlight, AIR, JavaFX and a host of others I"m probably not thinking of. You'd need something more than putting a markup language on top of it to make it standard enough to be useful.

Re:Need a New UI Tool

[thePowerOfGrayskull]

Assuming you mean jquery UI in this context?

The problem here is that writing a UI as code is simply not intuitive. It's not too bad if you can have that code generated and managed for you -- though that significantly increases the complexity of the tools you must use.

Nonetheless - what's missing from extjs, jqueryUI et al is a means to make it "drag and drop". This is 2010. I *really* shouldn't have to do any variation on ".add(new DropDownList())", in ANY language. There's no benefit to it, and it makes coding GUIs painfully slow - no matter how complete the library that's handling the actual behavior of the components behind the scene.

(On the flip side - for very simple UIs, code-based is faster. I'm largely talking about complex UIs)

Re:Need a New UI Tool

[Tablizer]

You don't need "compliance" if the new browser is the only implementation out there. Although Mosaic and Netscape were free, they were not open-source at the start. If they had been, then maybe Microsoft Internet Explorer would never had taken off. Microsoft bought their browser from a commercial company. Such a company wouldn't have likely formed if Mosaic was open-source and MS would have to start from scratch.

Maybe down the road there will forks and copycats such that "compliance" becomes an issue. But it's premature to worry about that, let's just get the ball rolling so that real GUI's are not a pain the arse.
     

Re:Need a New UI Tool

[Tablizer]

The advantage of a "GUI Markup Language" is that the market for it would be wider than a app-language-specific GUI library. This means that vendors and tool-makers are more likely to create visual editors for the markup language, like DreamWeaver, but for fuller GUI's. If we go with a language-specific library and matching visual editor, then the exercise of creating the editor has to be repeated for each application language, dividing up the effort by reinventing the wheels. (App-language-specific could still share some code, but only the display side.)

Thus, I don't propose a GUI markup language as an alternative to visual design, but rather to facilitate it by making GUI layout creation standard and common enough to justify a visual editor, and it could be used regardless of your app language.

Re:Need a New UI Tool

[Tablizer]

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.

These are sort of apples and oranges. HTML is mostly a "display" language, whereas XML has a more generic goal and is designed to represent just about anything you want. XML is almost a "language builder" language.
   

Re:Need a New UI Tool

[Tablizer]

Extra "pretend" mod points for anyone who knows why this doesn't count :-)

Re:Need a New UI Tool

[thetoadwarrior]

Or you can use Scala.

Re:Need a New UI Tool

[thePowerOfGrayskull]

As soon as a corporate entity see potential in it, you're going to get a copycat when the second corporate entity says "me too, but better!" And if a corporate entity doesn't see potential, the unfortunate truth is that there would be user base beyond enthusiasts.

It could be built without corporate help. But without major movers behind it, it's going to catch on just about as well as VRML did. And with major movers, you'll automatically get competition.

Re:Need a New UI Tool

[Tablizer]

VRML didn't satisfy any existing need. Serious corporate competition would mean that the potential to enter a post-HTML era (at least for biz GUI's) would be having a very good start. It would be a welcome problem over what we have now.

Re:Need a New UI Tool

[MemoryDragon]

Actually you can use any jvm based language with applets, applets are just an API sitting within the JVM and all the JVM wants is compiled class files.

Author should look into Scala

[Anonymous Coward]

Scala gives you most of the same benefits of groovy with the addition to being statically typed. The lift web framework is very nice (albeit poorly documented), especially with its ability to generate pain-free AJAX/Comet for you.

ps I would hardly call this article "the state of web developement." Maybe "the state of Java ecosystem web development", but even that seems a bit of a stretch.

Re:Author should look into Scala

[SQLz]

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.

Re:Author should look into Scala

[MemoryDragon]

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 scripting language policy which often stupiditly ties into the compiled domain, so even if the language is compiled you still cannot use it.

Re:Author should look into Scala

[TheNarrator]

Scala isn't that bad. One can program it like Java, and then use language features to compress the code down to 1/10th the size it would be in Java. However, if you use all the language features, you have to comment every line because the logic gets really really dense. I am getting up to speed in it and it's fun, really. It's just that there's a big big learning curve. Lift is a pretty bizarre web framework too, especially coming from traditional Java web development. Overall, I'm undecided if the feature density is worth it. Sometimes it's nice that Java is so verbose because it's really hard to be clever in a bad way. This mainly serves to keep clever programmers, at least the bad kind of clever, from wrecking a project.

Re:Author should look into Scala

[Laz10]

I second the recommodation of Scala.

Java has payed my bills for the last 10 years. But as the time has passed I have gotten more and more annoyed by things I can't express and limitations in the language.

Scala fixes each and every issue I have with java and I feel I could jump right in and be more productive within a few days of using scala.

Scala does have a lot of clever features, but I think that you should view them as optional rather than mandatory.
Yes you CAN write code that is 1/10 of java code and make it so terse that it can be hard to follow (though still not as obscure as some perl or ruby code that I have seen).

It is better to "just" write code that is about half the size and get better readability than java.

And unlike groovy you keep java's performance.

I am not so sure that Lift will get to be the #1 framework, but
I really think that the Scala language will take off as the sole heir to the java throne in 2010.

Traditionalist here

[hessian]

Only Perl is true!

Re:Traditionalist here

[Hurricane78]

You mean: Only machine code is true!
Kids these days...

Re:Traditionalist here

[lordmetroid]

You mean: Only manipulating the current by hand is true! Adults these days...

Re:Traditionalist here

[mandelbr0t]

Learning Perl today is gunning for a job as a maintenance programmer.

Or a Unix SysAdmin. Assuming the breed doesn't die out :-S

Re:Traditionalist here

[chromatic]

Learning Perl today is gunning for a job as a maintenance programmer.

Since Feburary, I've had three unsolicited requests to work on new Perl projects.

Re:Traditionalist here

[Lord Ender]

Uh huh. Because you're Mr. Chromatic from Reddit. You're the guy writing a book on Perl 5. That makes you one of the most high-profile of a an endangered species. It's no surprise that *you* are contacted. For everyone else? That would be a surprise.

Re:Traditionalist here

[chromatic]

I hear from other people that Perl recruiting is up dramatically over last year. I'm also not actively seeking consulting work; I took my CV offline last year.

Re:Traditionalist here

[Lord Ender]

Wouldn't surprise me. Perl is big and will have a long half-life. All I'm saying is that I don't see new projects being done in Perl. I don't see new start-ups building their businesses on Perl. I don't see big software companies using it as their go-to language. And I don't see college kids saying "I love this Perl syntax and want to specialize in this language."

It is certainly possible to make a career in Perl, and it will be for quite a while. Still, the language has peaked, while languages with identical functionality are growing quite rapidly.

Title of summary is wrong

[paziek]

Title of summary is wrong, its not about web development.
What is the purpose of this? Don't we want to go away from Java in web? It was slow back in the days, now its just yet another security risk that can compromise ALL browsers at once if Oracle/Sun screws up. And now some spin-off or whatever? No thanks.
What we really need is some kind of consistency between output of HTML/JS engines, as well as CSS, so that GUI "just works". There is nothing wrong with those languages/markups, just with the implementation. While I'm all for competition and browsers trying to be better at something from others, it seems to me that in this area they just should cooperate more. It was IE6 back in the days, now its all over the place with vendor-specific extensions, that instead of going first thru W3C, they just are added to the browser with -moz/-webkit/-whatever thats supposed to make it okay to do this? Or perhaps they want to take approach "Hey, we implemented X and its popular, can we force this into W3C now?", with I hope won't work very well for them.

Re:Title of summary is wrong

[micheas]

Um,

This is not about java on the client it is about java on the server via tomcat, jetty, or some other java app server.

All of the sites listed at http://www.opencms.org/en/support/references/index.html are java based, as is opencms.org itself.

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.

This is about grails vs rails vs django vs drupal vs zope vs web app framework du jour.

Personally, I wish there was a way of including php code in python, so I could extend existing php with django, and slowly convert the legacy code.

Re:Title of summary is wrong

[shutdown -p now]

Java is not a security risk for browsers in the context of server-side web development (which is what TFA is about).

People who do not learn from history....

[Kenneth Stephen]

...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:

1. Can your framework handle two-phase transactional commits when it interfaces to other applications?
2. 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?
3. 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?
4. 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?
5. 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.

Re:People who do not learn from history....

[inKubus]

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.

Re:People who do not learn from history....

[MemoryDragon]

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 core areas it covers so that I consider switching over for the parts JEE covers.
The biggest problem JEE has still is the massiv loading time from the servers, the turnaround times are frustrating, but the language is to blame for it and there are solutions but still this has to be fixed one way or the other.

Re:People who do not learn from history....

[shutdown -p now]

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?

Re:People who do not learn from history....

[Kent Recal]

are doomed to reinvent J2EE.

Nonsense.

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

Sure. Most apps don't need that, mind you, but if there's a need then 2PC is fairly trivial to implement *where it's needed*.

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?

What does that even have to do with anything?

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?

Sure. No java needed to use a loadbalancer and build stateless and/or SOA apps.

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?

WTF?

When you discover that you are having intermittent glitches ... Put your product into a supported trace mode and get your vendor to support you

Bullshit. NewRelic works pretty fine for rails. All platforms come with debugging machinery of various kinds, many of which are heads and shoulders above what you're probably using in your java-shop.

I have yet to see a professional grade alternative to it.

Meanwhile over here in the real world, many people build apps using those "unprofessional" alternatives just fine. Sometimes very quick, too.

Re:People who do not learn from history....

[Daishiman]

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 clustering techniques because there are no hard dependencies between nodes.

Sorry, but J2EE has absolutely nothing a modern Perl/Python/Ruby framework doesn't have today, except mechanism for managing the inherent complexity of a crappy language with a shitty object model that needs overly complex architecture to make up for its fundamental lack of programming constructs.

You're not going to find equivalents to @Stateless beans, Message-driven beans or any of that bullshit because decent frameworks make managing state something absolutely trivial, not an exercise in frustration that requires configuring 5 XML files and implementing two interfaces just to save an object to a database. Nobody cares about RMI or "messages" because you can make a restful web service with 2 regular expressions and a 15-line Ruby file. Nobody cares about monstrous ORMs that can barely handle programmatic queries when SQLAlchemy does that and with a 20-minute tutorial you're already up and running.

Oh, and just for the record, most people dn't even need to check for memory leaks because they use a language VM that consumes at most 20% of your runtime's resources and does the hard work with C plugins.

Let the scourge of J2EE and "entrerprise" frameworks burn in the underworld.

Re:People who do not learn from history....

[thetoadwarrior]

Perl hasn't gone away. They've improved it and call it Python now.

Re:People who do not learn from history....

[Bazouel]

If you expect to program in other frameworks the way you do in Java, then yes you are right, it will be painful as it should be. You need to do a mind shift and see the problems through different glasses. Functional programming is really another universe and if you have never done anything beside pure OO, it will take time for you to really see what you missed all those years. And yes, you can do everything you asked and much more.

1- 2pc is easily done with a specialized server (which should use a platform agnostic protocol)
2- single-sign-on solutions are not exclusive to Java (nor should they!)
3- session failover can easily be done by storing state in a db or specialized switches for example
4- as long as there exist an interop layer between both platform, you can do that. If JVM is the only choice, there are other languages than Java that can be used.
5- debugging/tracing is dependent on ide/tools, not the platform. Again it is not exclusive to JVM nor Java.

One framework you can try is Lift (http://www.liftweb.net) made with Scala on the JVM. You will still be able to use your frameworks of choice while learning to master Scala and its libraries. If nothing else, learning functional programming will make you a better programmer/architect.

Re:Rails is Awesome

[binarylarry]

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.

Re:getters and setters

[AuMatar]

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 access everywhere- a pain. 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.

Frameworks do not work. Quit it.

[unity100]

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 the number and variety of different stuff they may ask.

there has been a lot of framework talk and numerous frameworks put out up til this date, yet the biggest and strongest ecommerce software and community remains oscommerce, despite its aging code (no templating, html mingled with php and so on). clients who start with even different software (leave aside frameworks) eventually move on to oscommerce due to unequaled community support. (innumerable modules, modifications available for free, all the service providers - any payment, shipping provider - know and support it and have modules for it, very cheap development fees and so on).

the disparage in between the success of software like oscommerce and any such hyped framework that has been put out so far shows that, as developers and programmers, we shouldnt close in on ourselves and go about being above all, and programming for ourselves instead of end users. it just ends up in elitism, detached from the reality.

Re:Frameworks do not work. Quit it.

[thoughtsatthemoment]

You are talking like a scientist as if frameworks have to work for eternity. Frameworks are layers over the language or other libraries. How many layers are needed is something dynamic but that doesn't mean the layered approach is wrong.

Re:Frameworks do not work. Quit it.

[unity100]

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.

Re:Frameworks do not work. Quit it.

[unity100]

what i think is, 3 layers is more than enough. ie, machine code, c, php and it should stop there, in case of web apps for example.

any application made on the 3rd layer, when they grow sufficiently big, become as complex and wide as a framework itself. so, its not necessary to limit things by putting a 4th layer on top of this.

I'm asking because I don't know

[ClosedSource]

Are the client-side data validations declarative or do you still have to use Javascript to make them happen?

I guess it's human nature but ..

[ClosedSource]

It didn't take that many years to go from 0 users of HTML to where we are today despite the fact that most people didn't understand the potential at the time.

Or perhaps there could be two protocols available - one to support legacy sites and a new one specifically designed to facilitate web applications.

It would be great if you could have the most common AJAX-style transactions be available declaratively so that you could use them with little or no client-side scripting

Re:I guess it's human nature but ..

[turbidostato]

"It didn't take that many years to go from 0 users of HTML to where we are today despite the fact that most people didn't understand the potential at the time."

But HTML came first. Niche oportunity is already lost.

But Grails is like Rails

[shis-ka-bob]

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.

Re:We've had it for years. It's called Qt.

[Tablizer]

It seems heavily tied to C++ as your app development language. Scripting fans won't like that. Also, how it would work over HTTP is not clear. And, a GUI-Markup-Language would be the more popular and practical route, with imperative programming only around the edges for the custom stuff not handled by the markup language. If somebody put a markup wrapper around QT and worked out how it functions over HTTP, then you may have something.

Web Development?

[Orion Blastar]

They took our jobs!

Almost most IT and Web Development jobs have been outsourced to third world nations.

They took our jobs! Duurkee duuuurr!

Re:Rails is Awesome

[symbolic]

It was documented at http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster that a language change would have provided a 10%-20% speed increase, while architectural changes that Ruby on Rails could easily accommodate would provide with them with increases of 10,000%.

Apache Wicket

[dokebi]

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!).
!

Re:Apache Wicket

[shutdown -p now]

I find it ironic how, in the end, the Java camp has came to the same "stateful Web" model for frameworks for which ASP.NET was originally ridiculed (and which is being departed with in ASP.NET MVC).

I haven't used Wicket, but from what I've read about it, it sure sounds a lot like ASP.NET, except that it's actually done right (and in Java).

Re:Apache Wicket

[kisrael]

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.

Re:Rails is Awesome

[TheSunborn]

Except that it was not documentet at all. It was just stated as a fact with absolute nothing to back it up. Aka an analysis pulled out of his a**

Play framework is the way...

[jbwiv]

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.

Re:Play framework is the way...

[MoeDrippins]

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.

Re:Play framework is the way...

[cbowland]

I've been using Stripes 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.

Ah. The J2EE mating call

[MillerHighLife21]

1. If the app needs that, it can be built without a whole lot of complexity. Abstracting it so that it can just be applied is a lot more complicated and bravo to Java for having that. 2. Single Sign On is not a complicated process. I worked as a J2EE architect and PHP developer for a telcom company a few years back. The java only team implemented their "standards based" single sign on system that was marketed by the J2EE vendor as doing all that and a bag of chips. Took forever to get setup, constantly had issues and was nowhere close to as good as advertised. Eventually the VP came to our little web team of PHP + a specialty guys (J2EE, .NET, and Perl) because our stuff actually worked when we wrote it. We replaced the ENTIRE system with a from scratch SSO solution across 18 different internal and external sites/applications in under 2 weeks. You know why? Because J2EE talks a big game and has a whole lot of giant books but when it comes time to deliver it comes up short OVER and OVER and OVER again. It's going to be behind schedule, over budget, and under-functional 9/10. 3. Yes. You can. Do you have any idea how much money corporations throw away on J2EE Application Servers to get that functionality built in? 6 figure numbers minimum. Do you have any idea how much you need to pay for the annual salary of a good server admin? Usually less than that. Do you have any idea how much time it will take for a good server admin to set that up for you? 2 weeks to a month so you can use it forever. Session failover? Really? If you've got a multi-server app running it better darn well failover or you've written a POS app. Again, not that complicated to implement in less than a day. 4. Ah, the dream. It always sounds so good and yet, never really works that way. Great marketing pitch though. 5. Again, sounds good. J2EE app servers are very good for that, however, paid app servers for a lot of other languages will give you detailed trace modes for exactly that reason. Getting a vendor to support you is a great idea too. It's actually more of a testament to out-sourcing than anything else though. By depending on a vendor to support their application, you're basically just paying to depend on their programming team, documentation, and training processes instead of yours. If you're trying to figure out if it's a server issue or an issue with the application that you've written in house, I hope you've already got the tools available to trace those down. Finally, all this aside, I was a java guy before. Completely bought into all of the talk about ideal architecture, standards, "enterpriseyness", etc. I literally had the "I can't believe anybody would try to use anything but Java...it solves everything" mindset. Then I saw it in practice and reality is far from what's spec'd on paper. For one thing, J2EE is serious overkill for 99% of applications and that is very important. When people get into java, they want to do EVERYTHING in Java. This is where most of the "standardize on a language" people come from. If you try to do everything a company needs in java, the company is going to simply hemorrhage money. Additionally, the beauty of the web is that through web services, REST, and API's everywhere it's easier than ever to use the right tool for the job. J2EE is a swiss army knife. You can hammer a nail with it, but it will take forever and your fingers will get bloody. Use it for heavy lifting backend work if you need to and then just let everything else talk to it via a web service. It's one of the most effective ways to take advantage of Java where it's needed and to not use it where it's inefficient to develop and not cost effective - aka, web apps. One of Java's biggest flaws in the world of more and more client-side web apps is the save + build + war + deploy to app server + refresh + compile JSP at first runtime that takes absolutely forever. In other languages that are more suited to the web (PHP, Python, Ruby, Perl) you can simply hit save + refresh. When you're

Web Development or CRUD Development?

[Stan Vassilev]

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 constitutes today. The vast majority of those prefabbed CRUD frameworks do horribly at handling load, scaling across servers, hand-tuning the details to the customer's preference... and well, they do horribly at anything but CRUD. The web is more than CRUD and I do feel bad for the developers who do it for such lengths of time, they get accustomed to the false idea that this is the entirety of what web development is all about.

Re:getters and setters

[MemoryDragon]

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 loose
coupling of classes while still forcing you to some standard which reflective mechanisms do not. Interfaces are an awesome mechanism
for 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 class has about 1/3rd of its code dedicated to setters and getters. Given that javas goal was to enable readable code the setters and getters are clear contradictory to this goal. I hope now that Oracle is at the helm this is finally recognized as a problem.
(Btw. I have been programming with java since version 0.7)

Re:getters and setters

[MemoryDragon]

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.

Re:Is it just me

[MemoryDragon]

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.

Re:AJAX "more stories" functionality

[MemoryDragon]

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" history
which a rich client app almost never is, because you leave the document level.
As long as your application is document centric there is a way you can enable back even in ajax, but as soon as you leave the domain it does not work anymore usabilitywise.

The problem starts when people get a rich client application in a browser and suddenly expect that the back button still has to work the way they think it should (which they do not really know how to also, but it should work because it is there)
No one expects a back button in word or photoshop, but if they would be in the browser they suddenly would scream for it.

And no back is not undo in this case although it comes close.

Re:Author is "excited" about software tools? Sad.

[MemoryDragon]

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 other (you also can do wicket in groovy)
and maybe a proven work environment with another one.

And seriously auto scaffolding can be done with a handful of templates and a few hours of code yourself. I did that years before Rails hyped it into oblivion for an application where I generated about 60% of it with the scaffolder. But that does not releave you of the rest of the gruntwork and that you have to deal with the nasty web layouting.

what???

[tonywestonuk]

As a Java/C/RPG programmer, with 10 years experiance... I have to say, I don't have the foggiest what you're wittering on about!

Re:what???

[roman_mir]

you've been had, it's a troll you are replying to. He takes the parent's sentences, reiterates and adds pointless blubbering to make the comment really long, so you'd spend some time deciphering it.

Re:getters and setters

[MemoryDragon]

Btw. interfaces do not prevent not to have real properties, you could use a special property keyword to push them into interfaces without having to revert to endless setters and getters.

Re:Rails is Awesome

[MemoryDragon]

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 frontiers, but in the end, you still need to layout every page there is (although you can cover a lot of common ground with CSS) and the special cases have to be hardcoded and there you are locked into the boundaries of rails.

Re:getters and setters

[shutdown -p now]

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 doesn't perform any extensive computation, and when the getter is a pure function, and Get.../Set... methods otherwise, so in .NET this very distinction is actually used to communicate intent from API designer to developer.

We're going the wrong direction

[Rival]

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 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.

Re:We're going the wrong direction

[Anonymous Coward]

I'm a software engineer that understands the importance of good documentation and understanding of the code, along with what tests are applicable for each code module.

Generally the older the language the more difficult it was to code in. My dad had to write code in binary - simple commands required pages of code! I first programmed in Basic and then Fortran77 and compared to binary, this was relatively easy, especially when things didn't work first time and you need to check for errors. Error checking has really improved over time and now you can easily set watches and breakpoints to see what is happening.

Now I use C+ or .NET to plug things together and can do what my dad did in one or two lines of code. This is exactly becasue of the level of abstraction that allows me to ignore what's actually happening on a binary level. So as things progress, we loose the knowledge of exactly how things work and use increasingly simple analogies.

We rely on the platform and best practices to be secure, but this is relative to the cost benefits and risks. From my experience managers are less interested in testing and security and more interested in functionality and processing time (how quick it is).

With any programming, the real issue seems to be getting a library of good code, that is tested and open and understood. So any new code can be plugged together, like lego. Why redesign the wheel if you can modify it to whatever you want and create as many instances as you need? Why bother with memory management if the programing enviroment (Java) was designed to automatically release memory allocation when the code stopped running? It is also able to run in a virtual machine that means it can be supported on virtually any OS.

Personally you look at WEB vunerabilities and it seems that you can block flash and java and you are actually quite safe, except from social engineering of course!

Re:We're going the wrong direction

[thermal_7]

I think you are missing an element. Black boxes as you say should be more reliable and have less bugs and security issues than code written by a random programmer. Take for example Hibernate. It is used by probably more than a 100,000 apps/websites. Only really obscure bugs are going to go unnoticed. Writing all your SQL by hand however is only used by one application and there is a greater potential for bugs/security issues to exist.

Re:We're going the wrong direction

[wurp]

I haven't read your whole post in depth, but this stood out:

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.

Re:We're going the wrong direction

[zzyzyx]

So are you saying that we should code everything from the bottom up since frameworks aka "black boxes" cannot be trusted?
Unless you have infinite resources building more and more complex software requires to abstract more and more. You need to free your mind from the repetitive, low-level tasks to allow focusing only on what gives value to your software.
And yes, writing stuff that as already done by hundreds of developers is a waste of time, and that should not be redone.

About this "Farbrausch" thing, do you really think this kind of software can be compared to a webapp ? How easy would it be for a new developer do dive into the code? How does it scale? How easy would it be to fix a bug, of add a new feature? I bet it wouldn't be easy. These are often the main issues of "large" applications.

Re:We're going the wrong direction

[Zilog]

(with the help of an electronic translator, hope this is readable)

I'm just fully agree with you.

they are probably working at the wrong level of abstraction

Abstraction is a smart way of programming, but coding that way must not preclude a developer to take into account the management of the "mechanics", such as resource management (memory, disk space, etc..). The next generation of developers (<30 years) studied with Java, Python and other high level languages that discharge them of many tedious tasks. The downside to this approach is that it "disconnects" the developer of the system's internal functionning, which drives developers to lose the habit, among other, of monitoring the consumption of resources.

The object of all software development is mainly to manage resources to achieve a goal. Low skills in terms of mutlithread programming and design for today's developers in an era of multi-core processor aptly illustrates this fact.

Re:We're going the wrong direction

[Rival]

I think you are missing an element. Black boxes as you say should be more reliable and have less bugs and security issues than code written by a random programmer. Take for example Hibernate. It is used by probably more than a 100,000 apps/websites. Only really obscure bugs are going to go unnoticed. Writing all your SQL by hand however is only used by one application and there is a greater potential for bugs/security issues to exist.

But this illustrates my point exactly. Of those 100,000 apps/websites that use Hibernate, how many of the developers have looked at or understood the code at all? Are you familiar with the Unresolved Major bugs with the currently released versions of just the Hibernate Core? I doubt it, given that there are presently 792 of them. (You'll have to configure the search yourself.)

My concern is that developers are blindly using such platforms because everyone else is, or they look cool, or they are fun, or they are told to, and they are either too lazy, too busy, or too trusting in the developers who wrote them to expend the effort to understand the tools that they use.

The intent of my post was not to say that we should all go about reinventing the wheel. You're right; if you do that, you end up with alot of square wheels. But we need to understand how our tools work, when we are building things that our society increasingly relies on for daily functionality. "Me bang keyboard and mouse together, make program!" is not an appropriate development strategy.

Re:We're going the wrong direction

[lennier]

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.

I agree strongly with your 'old man' grump about sedimentary layers of abstraction being a very bad thing (Chuck Moore of Forth and Alan Kay of Smalltalk are saying similar things) but disagree with this specific diagnosis of what the problem is.

Writing code - or in fact creating ANYTHING - to solve a problem which has already been solved is IMO a mistake and is the cause of errors. Humans should not be doing any tasks which computers can do.

My problem with today's software ecosystems is rather the opposite: that we've accumulated all these crufty layers precisely because they DON'T solve our problems correctly, so we have to add more layers on top. We have lots of libraries and frameworks and class abstractions but they all do 'sorta, somewhat, kinda' the right thing, but not exactly the right thing. All those not-quites add up to leaky abstractions and failure.

And our libraries don't quite do the right thing because our languages still aren't powerful enough to let them express clearly and precisely our problems - rather than expressing procedures to solve our problems, which are not the same thing. 'Powerful' doesn't mean more features, it means the reverse: less 'built-in' features, but more reflection.

In my opinion, what we need is a new focus on languages which allow declarative programming - 'what' rather than 'how'. 'How' is what the compiler should generate. 'What', however - data and transformations - is the actual truth of the system, and that's what our current C-based languages are very poor at representing. So we settle for telling the computer 'how to do it' because we can't conceive of how to express 'what', and we don't even realise that we're settling; we approximate in 'coding' as a matter of course, and then all these approximations add up to built-in layers of failure.

Sapir-Whorf is biting us badly.

By way of example, a bare _minimum_ language I'd consider suitable for declarative programming (and it's still enormously sucky) is Prolog. Lisp for preference since you could reimplement Prolog done right in it, but we need at least logic programming rather than even functional programming.

spaguetti eater

[kikito]

"I still have the problem I complained about a few years ago: the problems that arise from mixing client side and server side markup in the same artifact"

Someone needs to start using haml.

Been living under a rock?

[Kent Recal]

I'm a bit confused.
It's 2010 and we discuss a java framework as if it represented "the state of web development"?

You have heard about rails and django, right?

Re:Been living under a rock?

[melmut]

Is this a troll? In 2010, Java is still state of the art. Rails and Django are not universal, certainly aren't standardized, have their weak points. I'm still a Java Developper, and won't switch to the new overhyped framework, even if I used and know Ruby quite well (and aborted any use of it). And yes, I like strong typing.

Re:Been living under a rock?

[josepha48]

yes he is a troll. I have used grails and guess what? It is in many ways like rails. In fact grails was modelled after rails, but also gives you the power of the java language. Grails is also not that old. It is a really cool language. It is not java either it is based on groovy which is a scripting language that looks in may ways like ruby, but because it runs under the jvm you can access your java api's by writing java like code. So you get all the OOP stuff from java, but in a scripting language. It is really very interesting but as with any scripting language there is a cost in performance vs writing something in java. Function calls have a huge overhead even if they are in the same class.

Re:Been living under a rock?

[melmut]

So you get all the OOP stuff from java, but in a scripting language.

I don't see that as an advantage. Some people do.

Function calls have a huge overhead even if they are in the same class.

Calling getters/setters hasn't any performance impact on modern jdk's. I remember benchmarking just that on various sun jvm versions. Can't find the article I wrote on Google Knol, but the result was that there was few performance impact on 1.4, almost none on 1.5 and none at all on 1.6. Anyway, it was barely noticeable on millions of method calls. So, this hasn't been an acceptable excuse for years ;-)

Re:Ah. The J2EE mating call

[MillerHighLife21]

Thanks! Didn't know about that.

I've since updated it, but it doesn't seem like there's any way for me to edit the original comment.

Ah. The J2EE mating call (with spacing)

[MillerHighLife21]

1. If the app needs that, it can be built without a whole lot of complexity. Abstracting it so that it can just be applied is a lot more complicated and bravo to Java for having that.

2. Single Sign On is not a complicated process. I worked as a J2EE architect and PHP developer for a telcom company a few years back. The java only team implemented their "standards based" single sign on system that was marketed by the J2EE vendor as doing all that and a bag of chips. Took forever to get setup, constantly had issues and was nowhere close to as good as advertised.

Eventually the VP came to our little web team of PHP + a specialty guys (J2EE, .NET, and Perl) because our stuff actually worked when we wrote it. We replaced the ENTIRE system with a from scratch SSO solution across 18 different internal and external sites/applications in under 2 weeks. You know why? Because J2EE talks a big game and has a whole lot of giant books but when it comes time to deliver it comes up short OVER and OVER and OVER again. It's going to be behind schedule, over budget, and under-functional 9/10 times.

3. Yes. You can.

Do you have any idea how much money corporations throw away on J2EE Application Servers to get that functionality built in? 6 figure numbers minimum.

Do you have any idea how much you need to pay for the annual salary of a good server admin? Usually less than that.

Do you have any idea how much time it will take for a good server admin to set that up for you? 2 weeks to a month so you can use it forever.

Session failover? Really? If you've got a multi-server app running it better darn well failover or you've written a POS app. Again, not that complicated to implement in less than a day.

4. Ah, the dream. It always sounds so good and yet, never really works that way. Great marketing pitch though.

5. Again, sounds good. J2EE app servers are very good for that, however, paid app servers for a lot of other languages will give you detailed trace modes for exactly that reason.

Getting a vendor to support you is a great idea too. It's actually more of a testament to out-sourcing than anything else though. By depending on a vendor to support their application, you're basically just paying to depend on their programming team, documentation, and training processes instead of yours. If you're trying to figure out if it's a server issue or an issue with the application that you've written in house, I hope you've already got the tools available to trace those down.

Finally, all this aside, I was a java guy before. Completely bought into all of the talk about ideal architecture, standards, "enterpriseyness", etc. I literally had the "I can't believe anybody would try to use anything but Java...it solves everything" mindset.

Then I saw it in practice and reality is far from what's spec'd on paper. For one thing, J2EE is serious overkill for 99% of applications and that is very important. When people get into java, they want to do EVERYTHING in Java. This is where most of the "standardize on a language" people come from. If you try to do everything a company needs in java, the company is going to simply hemorrhage money.

Additionally, the beauty of the web is that through web services, REST, and API's everywhere it's easier than ever to use the right tool for the job. J2EE is a swiss army knife. You can hammer a nail with it, but it will take forever and your fingers will get bloody. Use it for heavy lifting backend work if you need to and then just let everything else talk to it via a web service. It's one of the most effective ways to take advantage of Java where it's needed and to not use it where it's inefficient to develop and not cost effective - aka, web apps.

One of Java's biggest flaws in the world of more and more client-side web apps is the save + build + war + deploy to app server + refresh + compile JSP at first runtime that takes absolutely forever. In other languages that are more suited to the web (PHP, Python, Ruby, Perl) yo

Re:Ah. The J2EE mating call (with spacing)

[thetoadwarrior]

I think part of the problem with Java is there is this sense of over complicating everything. Maybe because Java has a library for everything no one wants to do it without some big ass collection of jars.

Off Topic.

[crhylove]

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, a Chess board, a poker table, a coffee table, a doorway, and a Super Nintendo. This environment could then be populated real time with the avatar of anyone else online at that time, with instant VOIP in 3d positional audio. In addition, the face of their avatar could be exactly modeled real time from a webcam image of the actual user's face. In this environment, either avatar can then interact with any of the aforementioned locations. Choosing to interact with the Desk would bring up an Windows XP clone, or a Windows XP Virtual Machine. Both Avatar's could use the desktop at the same time (by password invite, for avatar's from a separate IP as the host), real time, and continue their VOIP, and also have an optional skype cam pic up real time, directly from the 3d world. A simple key press would then exit back into the 3d environment and leave the other options (ESC). The Chess Board would work as a regular chess game, online, and with your opponent either being their webcam image, or their avatar with webcam mimicked facial expressions and jaw movement. The Poker Table would act much the same way, and any card game would be possible, complete with rules, and chips, etc.. The Coffee Table would have Digital Publications, Blogs, and other News and Information sources, directly updated real time from the Internet. The Super Nintendo would open an emulator locally and remotely, so both avatar's could play a multiplayer Super Nintendo game online, again, possibly with webcam images up simultaneously. The doorway would open an FPS as preferred by the local host, and I would have mine set to a customized Urban Terror, complete with 3d positional VOIP with whatever Avatar I walked into the doorway with.

This "Dream OS" would also optionally backup it's user files and information on several different computers real time over the internet, maintaining a backup of all your files and information on a distant machine, like your brother's, or cousin's. This would ensure that no matter you logged in, in the world, provided one of the machines was online with your backup information, you could get online and use your computer as normal from any computer in the world, including newer cell phones.

While we're at it, my dream cell phone would run this OS, and have an android mode for on the go travel, but when plugged into a USB charger, it would automatically work with a USB mouse, keyboard, speakers and Monitor, and then act as a regular computer. This cell phone would also have a front facing camera, for Skype like chat on the go, provided there's nearby wifi, or enough bandwidth. While on the road, this cell phone would act pretty much line a Droid, or a MyTouch, or a Nexus One.

Somebody build a few of these and send me one.

Re:Off Topic.

[Che_FM]

Because, remember, no matter where you go, there you aren't.

Re:Off Topic.

[Civil_Disobedient]

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.

Re:Rails is Awesome

[MoeDrippins]

I have no citation here, but I suspect twitter was well beyond "a dozen" users before they started feeling whatever pain they said Rails was behind.

Re:getters and setters

[Civil_Disobedient]

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.

Not true if the field is declared static.

Most can't

[Anonymous Coward]

Most people can't be an expert at all things, it is usually poor practice to attempt to implement all things yourself as most often those that wrote the library know better what they are doing. Sure if you are perfect and have infinite time doing what you propose makes sense, but it is almost always faster and usually safer to trust that the writers of a library know what they are doing.

Do you wish to write your own sort algorithm? Your own SQL interface? Your own filtering implementations? If so that I would hate to be your employer as you will be spending much more time writing less efficient code that probably has more exploits than some mouth-breather that just used the default libraries.

I understand your point, but abstraction is really important, an electrical engineer could never design a computer if he had to worry about what every transistor in his circuit did, he trusts that the amplifier provided works more or less as specified the same with the same with the phase detector and the variable oscillator. If he were to try to build it from transistors, (or worse from dopings in silicon) he would never get anywhere, the abstractions allow him to function, building something off the shoulders of those that created the various parts and trusting that they did their job well. It isn't perfect, but it is better than everyone starting from square one.

Re:We've had it for years. It's called Qt.

[Tablizer]

I'm commenting on developers in general, not just my preferences. And the use of markup languages is not just about making things "easy", but largely about making it easier to use other languages to generate and control GUI's. If your shop already specializes in language X, you don't want to have to switch to language Y to start using or converting to a new tool.

Re:getters and setters

[thePowerOfGrayskull]

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.

Worse, it gives people the "feeling" that they're not doing anything except copying or compariing a value, leading to code like "for (Obj in ObjArray) { if Obj.X = 1 || Obj.X = 2 || (Obj.X > 10 && Obj.X 100)". People tend to assume that because it's so transparent, they're just accessing in data member. In reality, you have *no* idea of what that lookup is doing in the background - it could be refreshing from a remote server, or performing a complex calculation. At least with get/set* you are given some notion that there may be functionality attached, and you tend to be a little less careless.

Re:getters and setters

[AuMatar]

When you're debugging code and you see

foo.bar=7;

You assume that you know what = does. It sets the value. With C# style properties, you cannot assume this. It *should* be what it does, with the possibility of throwing an exception on a bad value, but it isn't assured. It can be very hard to find this kind of bug by inspection, because you'll never think "Does = really mean ="? The only way you'll find it is by luck or by stepping through in a deugger, which isn't always possible/convenient. And I don't know about you, but I fix more fo my bugs via inspection than by debuggers.

Now you can argue that any code which does that is bad code and abusing the feature. I'd probably agree. But there's an awful lot of bad code out there in the world, I'd rather have it clearly showing that this is not a normal equals but instead is calling a function. Its more verbose but it's also clearer as to what it's actually doing. I really don't care about extra verboseness when it leads to clarity- more words/lines but clearer code is better than terseness.

(Side note: you can get into similar situations using C++ with overloaded operators. But its less likely to occur, since you can't overload individual fields but only entire types.)

Re:getters and setters

[AuMatar]

The idea of interfaces in general doesn't prevent data members (and C++ does this- just make a pure abstract class). Java however doesn't allow data members in interfaces as a language design decision. Thus if you need data in an interface, you need getters/setters.

I've looked at web code, but...

[gestalt_n_pepper]

I washed my brains afterward. Ick.

Re:Thoughts from another experienced developer...

[Hurricane78]

Man, what happened to the moderators? Are they supplied by 4chan idiots?
I can’t even imagine what could possible make anyone mod that as flamebait... it boggles the mind.

Envy? Or just plain retarded dickishness? Whatever. Those people just make themselves look like idiots.

By the way: How about showing the names of whoever moderated your comment? You know, so people have to look their victims in the virtual eyes.

What about sofea and soui?

[captnbli]

This original post was talking about SOFEA and SOUI as if they are living things. But a little research shows they are dead as acronyms, anyway. I think really these concepts have become mainstream, at least in relation to SOA. And so they become anonymous concepts. But we do need a way to talk about these details and advance the status quo. So, how about it? Point us to discussions/acronyms/sites that talk about what the state of the art is in building clients for services. At the moment that would be some in depth way to use JSON and JavaScript to render a UI on top of business services, I think. But it's all up for debate! Cheers! The Captn...

Re:AJAX "more stories" functionality

[MemoryDragon]

The advantage probably was on slashdots side, since using ajax saves a load of traffic because only partial document contents are updated.
But using Ajax not necessarily means you have to avoid the back button, you can program it to behave correctly, at least for most modern browsers. Although the approaches are somewhat hackish they normally work well enough.