Java Is A Dead-End For Enterprise App Development
-
I didn't spot any valid arguments in that article, except that java Swing hurts the eyes. But for a business app that shouldn't be a deal breaker. Sure things can be improved upon, but he'll have to point out a convincing alternative for java/.NET.
Wout
-
ict558 wrote:
PICK?
What's that?
Wout
-
ict558 wrote:
PICK?
What's that?
Wout
-
Just read an article[^] with the title as above. From my reading, the same statement could be applied to .NET too. After all, to a large extent, as the article says ".NET is just Java, Microsoft style". Both Java and .NET suffer from having too many additional paradigms piled on top in order to make them do what is required. I generally tend to agree with the sentiment of the article but I have been out of the Enterprise App Development rat race for some considerable time now, so anyone still making the wheels turn have a view?
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”
The author makes one very correct statement "Java bungled the presentation layer." As for the rest, he fails to understand that 4GL stopped because it was a total fail. So are most of his suggested replacements. He buys into the idiotic theory that software development would be great if we could just get rid of those pesky programmers and all that complicated engineering stuff. Developing useful applications is hard work. Period. Nothing will change that and while some tools, frameworks and languages can simplify the work, it's still hard work and still requires lots of messy, ugly engineering and long time lines with geeky engineers who are smarter than than their bosses and the author of this article.
-
ict558 wrote:
PICK?
What's that?
Wout
wout de zeeuw wrote:
What's that?
Henry has replied, but the Wikipedia description, while accurate, does not do PICK justice. It was a development environment, limited by only two things: 1. The imagination of the user; 2. The litigious nature of its originator (slowing - halting, even - the development of a truly Enterprise ready tool). I had to use it for a number of clients in the 1980s, and I was very impressed with its flexibility, speed, and small footprint. My proposal of PICK was, however, tongue-in-cheek. :)
-
wout de zeeuw wrote:
What's that?
Henry has replied, but the Wikipedia description, while accurate, does not do PICK justice. It was a development environment, limited by only two things: 1. The imagination of the user; 2. The litigious nature of its originator (slowing - halting, even - the development of a truly Enterprise ready tool). I had to use it for a number of clients in the 1980s, and I was very impressed with its flexibility, speed, and small footprint. My proposal of PICK was, however, tongue-in-cheek. :)
ict558 wrote:
My proposal of PICK was, however, tongue-in-cheek.
I suspected this. The environment doesn't matter too much to me though, I'd happily write software in C (but a modern IDE auto completion/documentation would be very welcome ofcourse).
Wout
-
An oldie but goodie. :) The Wikipedia article was obviously written by someone compiling a history of operating systems, rather than a PICK developer. Accurate, but not informative as to just why so many people used it in the 1980s - scared the pants off IBM.
-
ict558 wrote:
My proposal of PICK was, however, tongue-in-cheek.
I suspected this. The environment doesn't matter too much to me though, I'd happily write software in C (but a modern IDE auto completion/documentation would be very welcome ofcourse).
Wout
wout de zeeuw wrote:
but a modern IDE auto completion/documentation would be very welcome ofcourse
Not to go on about PICK - but I will :) - because the source, data dictionary, text, whatever were held in database format, it was easy to generate documentation from code and dictionary entries (and vice versa) - as long as a discipline was maintained among the developers :laugh: :laugh: :laugh: . My experience of IDEs is limited. I learnt Java - as the next big thing - but was hoicked over to COBOL for Y2K!!! X| (On account of my age.) After that, it was all HTML, ASP, SQL and Javascript using that well known IDE - Notepad.
-
The author makes one very correct statement "Java bungled the presentation layer." As for the rest, he fails to understand that 4GL stopped because it was a total fail. So are most of his suggested replacements. He buys into the idiotic theory that software development would be great if we could just get rid of those pesky programmers and all that complicated engineering stuff. Developing useful applications is hard work. Period. Nothing will change that and while some tools, frameworks and languages can simplify the work, it's still hard work and still requires lots of messy, ugly engineering and long time lines with geeky engineers who are smarter than than their bosses and the author of this article.
Joe Woodbury wrote:
frameworks and languages can simplify the work
And so now people who are even stupider than the managers think that they can do it well after reading a book. :mad:
-
wout de zeeuw wrote:
but a modern IDE auto completion/documentation would be very welcome ofcourse
Not to go on about PICK - but I will :) - because the source, data dictionary, text, whatever were held in database format, it was easy to generate documentation from code and dictionary entries (and vice versa) - as long as a discipline was maintained among the developers :laugh: :laugh: :laugh: . My experience of IDEs is limited. I learnt Java - as the next big thing - but was hoicked over to COBOL for Y2K!!! X| (On account of my age.) After that, it was all HTML, ASP, SQL and Javascript using that well known IDE - Notepad.
ict558 wrote:
because the source, data dictionary, text, whatever were held in database format
That sounds almost nice, but I can't imagine that diffing between revisions would work nicely (or version management at all). Reminds me of one of those projects that one of the MS founders was doing, storing all source in a db, so you could program in any language (e.g. german), as the code would be translated to your language on the fly. But I'm just sticking with languages that use plain text files that I can stick in subversion. COBOL, that's on my todo list (to have a peek at one day). :laugh:
Wout
-
ict558 wrote:
because the source, data dictionary, text, whatever were held in database format
That sounds almost nice, but I can't imagine that diffing between revisions would work nicely (or version management at all). Reminds me of one of those projects that one of the MS founders was doing, storing all source in a db, so you could program in any language (e.g. german), as the code would be translated to your language on the fly. But I'm just sticking with languages that use plain text files that I can stick in subversion. COBOL, that's on my todo list (to have a peek at one day). :laugh:
Wout
wout de zeeuw wrote:
diffing between revisions would work nicely (or version management at all)
No, no. It was easy to implement a version control system. (I could explain how, but you would then die - of boredom.)
wout de zeeuw wrote:
COBOL, that's on my todo list (to have a peek at one day).
No need for the :laugh:, you could only be joking. Anyway, when you are old and grey, they will put you in charge of VB + Access legacy systems. :)
-
wout de zeeuw wrote:
diffing between revisions would work nicely (or version management at all)
No, no. It was easy to implement a version control system. (I could explain how, but you would then die - of boredom.)
wout de zeeuw wrote:
COBOL, that's on my todo list (to have a peek at one day).
No need for the :laugh:, you could only be joking. Anyway, when you are old and grey, they will put you in charge of VB + Access legacy systems. :)
ict558 wrote:
Anyway, when you are old and grey, they will put you in charge of VB + Access legacy systems.
Well... VB.NET, check, Access, check... Luckily not VB 6. Actually I don't mind Access too much (but I just do the plain SQL type of stuff, luckily I don't have to maintain actual Access based applications).
Wout
-
Just read an article[^] with the title as above. From my reading, the same statement could be applied to .NET too. After all, to a large extent, as the article says ".NET is just Java, Microsoft style". Both Java and .NET suffer from having too many additional paradigms piled on top in order to make them do what is required. I generally tend to agree with the sentiment of the article but I have been out of the Enterprise App Development rat race for some considerable time now, so anyone still making the wheels turn have a view?
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”
Anyone who claims that .NET is just Java, is talking out of their fundamental orifice.
-
[steps on pedestal] In the 30 years I've been in this industry, "we" still haven't figured out that its not technology that causes the success or failure of a product development, whether it's Tetris or Amazon, instead, it's people. People are solely responsible for the rare success and frequent failure of a product. The technologies that are used are simply tools, not means, and any new technologies developed along the way are simply an artifact of the process. Application development teams should create a three-year application development strategy and road map to include architecture, process, tools, and technology. Bullshit. Teams need to focus on their people and their strengths, bolster their weaknesses, and learn effective communication skills. A roadmap should consist of training, communication, problem solving skills, and an attitude that we help each other to attain the goal, rather than creating an adversarial environment. Teamwork, ha! What I've mostly experienced is people within teams in conflict with each other, and tensions across teams that cost companies dearly, and ultimately the customer suffers. One amazing rare exception is the client I currently work for, where I find that people and teams are eager to learn from each other, improving their own processes, and there's also a really healthy consciousness of the inevitable situations in which there is adversity, and these are addressed in a positive way. When will we learn this? Probably never, because in general programming and technology attracts exactly those people that are most deficient in communication and problem solving skills, people who expect that the technology is shield behind which they can hide from their own inadequacies. Any development effort is a social experience, and we need to recognize that we need really good social skills to succeed. [steps off pedestal] Marc
Amen! That said at work we have good team work, unless, every now and then, the management try to remind us with have no time for idle chat... which I think is mostly (but not alway, but definitely mostly)) a productivity killer, as "idle chat" is perfect time to relax (and being hit by new idea), share programing tips and increase team spirit! :P
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
Haven't read the article yet but from what I see Java is on the downward swing. Our company has two branches, one doing Java work and the other .NET. The latter is booming with more work than we have people to handle it while the Java side is struggling and only does maintenance work on existing code.
I know the language. I've read a book. - _Madmatt
The problem I've found in the Mobile Development industry, is ever since MS's decision to let all Window Mobile developers suffer the fate of zero support and there big following in the lurch. A large number of Mobile Corporates are shifting to languages that have more stable less life changing OS's with the likes of JAVA being supported. Thus since WP7 Myself and other like minded once avid Microsoft supporters will now shift our attention to Android & iOS where Java plays a huge role. So IMO, Java may very well get a new lease on life thanks to MS's blunder and "take it or leave" approach.
do or do not, there is no try
-
Java is essentially crap in the enterprise. The only reason for using it is if your "strategy" includes bouncing from one OS platform to another, which in and of itself isn't really a strategy. We're currently interfacing with a Java app that is broken, and the developers aren't willing to accept bug reports because "it must be something we're doing". We've written OUR code to their specifications, and have proven time and again that our code is correct *according to their specs*. They've claimed it was "probably a .Net problem", they've said that because they can't find a problem in our code. One of their coders said she doesn't use a debugger, and instead, she just "stares at the code until the problem is revealed". Of course, this is ALWAYS a problem with Northrop-Grumman. I've had to deal with their "programmers" on several occasions, and in every case, they were too high-falootin' to admit that they screwed the pooch. It's always something they've done wrong on their end, or even worse, they changed their "specs" without notifying the partner systems that were trying to interface according to their documentation. I hate Java and think very little of everyone that says they like coding with it.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001I found your post entertaining and in many ways I share some similiar thoughts. I love everything you said except: "I hate Java and think very little of everyone that says they like coding with it." Particularly the bold part... because it's silly. One of my favorite coders I ever worked with has a wife who is all 100% into Java, and he is 100% into PHP, C++, C but would be JUST as happy using Java... Maybe not so happy using Microsoft (he's Linux Fan like myself) but he just loves coding like me... and this guy... he's really really good... as in I'm no slouch (28 years programming!) by a long shot and I think he's got something on me by long shot... I guess my point is: right tool for job... Git-r-Dun... I have my opinions for sure too man.. I just find it hard to knock a person because they like a particular tool or programming language or whatever.... for me... I personally take a serious new "java look" every year I'd guess.. and each year I dig in a bit.. look around.. start to remember why I hate p-code, byte code, fake "runtime engines" that nothing more than a JumpTable to previously ported functions.... at a cost of speed. And I guess speed is a favorite of mine while bloat is not - and this results from a me starting coding on a PC with 2K of ram... as in 2048 bytes... and a tape recorder as my harddrive. Being in the game that long really teaches you to become sickened at the shear amount of useless code out there.... I bet it would take a PC from 2001 about an hour to boot Windows 7 if it could... I'm just guessing while thinking of the shear number of machine language commands that get executed during a Windows7 boot up... I've been hearing this java = portable = future etc. and I'm not a fortune teller but I've always cared about speed... and now that the cloud is big, everyone is virtualizing it seems... and guess what.. pc's aren't getting that much faster... scalable parallel processing is likely to be the next big computing "milestone" ( I mean parallel that really kicks butt here folks, I don't care about your NEW Parallel coding API that can work if you.... we're not there yet...sorry. ) so my point now is that all those coders for years who always said: "Write Slop and if it runs slow get a better computer" I can Say: Take the Java Train over there with the .Net Caboose and the other scripted languages.....I'm tired of pushing for fast lean code ... I could get lazy... ah... Nope.. I do the best I can with time available, budget, etc. And No
-
Java is essentially crap in the enterprise. The only reason for using it is if your "strategy" includes bouncing from one OS platform to another, which in and of itself isn't really a strategy. We're currently interfacing with a Java app that is broken, and the developers aren't willing to accept bug reports because "it must be something we're doing". We've written OUR code to their specifications, and have proven time and again that our code is correct *according to their specs*. They've claimed it was "probably a .Net problem", they've said that because they can't find a problem in our code. One of their coders said she doesn't use a debugger, and instead, she just "stares at the code until the problem is revealed". Of course, this is ALWAYS a problem with Northrop-Grumman. I've had to deal with their "programmers" on several occasions, and in every case, they were too high-falootin' to admit that they screwed the pooch. It's always something they've done wrong on their end, or even worse, they changed their "specs" without notifying the partner systems that were trying to interface according to their documentation. I hate Java and think very little of everyone that says they like coding with it.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001:thumbsup:
I'd blame it on the Brain farts.. But let's be honest, it really is more like a Methane factory between my ears some days then it is anything else...
-----
"The conversations he was having with himself were becoming ominous."-.. On the radio... -
Java is essentially crap in the enterprise. The only reason for using it is if your "strategy" includes bouncing from one OS platform to another, which in and of itself isn't really a strategy. We're currently interfacing with a Java app that is broken, and the developers aren't willing to accept bug reports because "it must be something we're doing". We've written OUR code to their specifications, and have proven time and again that our code is correct *according to their specs*. They've claimed it was "probably a .Net problem", they've said that because they can't find a problem in our code. One of their coders said she doesn't use a debugger, and instead, she just "stares at the code until the problem is revealed". Of course, this is ALWAYS a problem with Northrop-Grumman. I've had to deal with their "programmers" on several occasions, and in every case, they were too high-falootin' to admit that they screwed the pooch. It's always something they've done wrong on their end, or even worse, they changed their "specs" without notifying the partner systems that were trying to interface according to their documentation. I hate Java and think very little of everyone that says they like coding with it.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001John Simmons / outlaw programmer wrote:
Java is essentially crap in the enterprise. The only reason for using it is if your "strategy" includes bouncing from one OS platform to another, which in and of itself isn't really a strategy. We're currently interfacing with a Java app that is broken, and the developers aren't willing to accept bug reports because "it must be something we're doing". We've written OUR code to their specifications, and have proven time and again that our code is correct *according to their specs*. They've claimed it was "probably a .Net problem", they've said that because they can't find a problem in our code. One of their coders said she doesn't use a debugger, and instead, she just "stares at the code until the problem is revealed". Of course, this is ALWAYS a problem with Northrop-Grumman. I've had to deal with their "programmers" on several occasions, and in every case, they were too high-falootin' to admit that they screwed the pooch. It's always something they've done wrong on their end, or even worse, they changed their "specs" without notifying the partner systems that were trying to interface according to their documentation.
There is nothing in that which has anything at all to do with Java. And of course there is a very simple solution to the problem of demonstrating the problem in their code - write a java app that demonstrates it.
-
The problem will be solved when SkyNet come online.
I know the language. I've read a book. - _Madmatt
I am already online...under an assumed name...so that I can watch you all!