Java Is A Dead-End For Enterprise App Development
-
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.”
-
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.”
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 -
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:
this is ALWAYS a problem with Northrop-Grumman
It's somehow comforting to know that nothing has changed since I left the company in 1986 (Northrop,only, that is).
Will Rogers never met me.
-
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.”
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
-
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.”
[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
-
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, 2001Sounds to me like the problem is not the technology but the people. ;) Marc
-
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.”
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
-
Sounds to me like the problem is not the technology but the people. ;) Marc
The problem will be solved when SkyNet come online.
I know the language. I've read a book. - _Madmatt
-
Sounds to me like the problem is not the technology but the people. ;) Marc
It's both.
.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 -
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. :)