Slashdot Mirror

The key word in the summary is "legacy". This indicates that there is a large code base that the current developers are not too familiar with (deep knowledge, staff turnover causes this). This causes an organization to fear change due to the related complexity of changes and potential regression bugs. I'm going to guess that there aren't large, mature suites of unit and regression tests.

So I believe you have:
1. Complex code base without a lot of deep developer knowledge of the innards.
2. Fear to change things too much due to complexity and the possibility of introducing bugs.
3. Do not have effective, wide coverage testing implemented.

But, you also have good knowledge of Perl and the architectural elements that compose the system (server software, external libraries, etc.). That knowledge is very valuable and shouldn't be dismissed just for the sake of changing the base language of a system. And you have a working system. How many person years of development have been put into it? Are you willing to spend that much time on the replacement (do you think a replacement could be built in less time, and if so, why?)?

As well, rewriting large admin systems is very risky. I've personally seen two such efforts fail, a 100% failure rate from my personal experience (both had budgets over $5 million, one was over $40 million). Here's an article on this topic:
http://hbr.org/2011/09/why-you...

Consider keeping the existing system, but embarking on a long term (years) modernization/re-design/improvement effort to make the system more modern (ie. easier to work with). Focus on small, non-breaking changes that can go out with regular enhancement promotions (the modernization effort should be able to stop at any point, with any improvements to the system staying in place - this allows for tight budget control and financial risk mitigation). Hire a good application DBA to perform analysis and recommend changes to the data model. Hire a good software architect or bring in architectural consultants that can bring a different perspective to the understanding of the application, its goals, and how it could be improved.

Here's an article on approaching IT projects in a "Small and Simple" manner:
http://w.objectwatch.com/white...

and how is building a large software product, or installing a new piece of software for use in the enterprise not the same animal?

It's a different animal to other project management because software is complex and always changing. When you start the project and make the plans you have to take into account that things will change like for example in the previous analogy I used "If you move the railway tracks too much you may have build a whole new train station." - It is not realising that by changing something that you may have to "build a new train station" that is the real killer.

In other projects you may do step 1 , step 2, step 3 then you come back and change a few things at but each step generally follows the other in I.T. you may do step 1, step 2, step 3 then find the client now wants step 1 changed and that means step 2 and step 3 will change with it. Software is totally changeable and a very complex beast. One change may mean a 100 hours of re-work.

It is very easy to make mistakes and if these mistakes are not caught early expensive to fix. There have been some incredibly expensive mistakes made with multi-million dollar projects having to be abandoned.

http://www.objectwatch.com/whitepapers/ITComplexityWhitePaper.pdf

IT project failures lose over $6e12/year worldwide.

This, of course, has little to do with the quality of programmers and if you think it does, then you're most likely an unemployed, childless white programmer suffering from age-related cognitive decline who has lived a life of sexual frustration.

Just die now and stop sharing your misery with the rest of the world in your psycho suicide attacks on the government.

I'm 100% behind what's being said on this thread; the question has troubled me, as I'm sure it's troubled others, for a while.

Everytime I read something by one of the Gartner's of the world, I typically hear at best poor or obvious speculation about what might happen.

Now, taking a step back for a minute I have to ask myself about this incongruence; bad data with good authority; it seems like I must be faulty in (at least) one of my ideas.

First, is Gartner's data faulty? What else should I take it to mean when other people consider Gartner's research as outdated and superficial? Fairly well debunked and answered. Perhaps you shared my amusement when I saw this . Now while I accept Gartner's point as being clearly true (an iPod, could indeed be a security risk, true), I think that on my reading I thought of it in the much the same way as a pencil becoming a stabbing weapon; that is, plausible, but much better and more dangerous tools exist. It sounds like hyperbole. (Although I'm probably overly cynical).

As far as authority goes, Gartner gets significant press attention, and I suppose you could be forgiven for thinking that this makes them correct.

So, where's the gap? Is it an important gap, or is it just a group of slashdotters getting their geek hurt by a group that approaches things from a business perspective?

-cje-

DISCLAIMER: I'm young and naive.

... can be found here

Rogers Sessions took the time to investigate every single one of the projects on the JVM languages page. He posted his results to the ObjectWatch site. After long research, he found only 8 that were actual implementations of a non-Java programming language for the JVM. Of those 8, in his opinion not one was available or suitable for professional development.

In his conclusion he states "I believe that Simon Phipps and other Sun luminaries have greatly exaggerated the degree of language neutrality supported by the Java platform".

The vast majority of those languages only target the VM, or are simply interpreters, and do not provide API-level compatibility. ObjectWatch wrote an article examining the very list you linked to. It can be found here..

at least compared to windows. Just read this article.

"Windows NT was redesigned from the ground up to have reliability, scalability, and security. Windows 2000 builds on the Windows NT base, not the Windows 95/98/ME base. It should be no surprise, then, that Windows 2000 has proven itself to be much more reliable than either Unix or Windows 95/98/ME."

"In short, the Windows 9X [95/98/ME] operating system was not designed for today's networking environments... Unix, which was developed by and for scientific researchers and computer scientists, was not designed with security in mind either..."

No, I don't believe this FUD, I just can't believe some of the crap that people say...

If this poster had read the original article more closely, he would have noticed a link to this page, which is the work of someone who actually took the time to closely analyze everything on the list at the site that the poster provided a link to.

A closer inspection of this list at tu-berlin.de reveals that the vast majority of the items listed are not actually claiming to be compilers that produce Java byte-code. They are merely tools or compilers or interpreters written in Java. Of the few which claim to produce Java byte-code, even fewer are actually available for use (some were abandoned before completion) or have any additional information available about them.

A handful of items in the list translate source code from language subsets into Java source code first, which you can then run JAVAC on to build actual byte-code. (For example, Canterbury claims to have such a thing for Pascal, Oberon-2, and Modula-2. There is also one for translating C code to Java code, and Fortran code to Java code. Perhaps the most promising and truly byte-code producing tools on the entire page are the assemblers at the bottom.

It is worth pointing out that this still doesn't make the JVM a language-neutral platform. (Again, see the discussion at http://www.objectwatch.com/issue_33.htm.) While there are ways of producing Java byte-code from other languages, you've still got to write all of your code in whatever single language you choose. For example, there's no good way on the JVM to implement a class in Modula-2 code and derive from it in Pascal code, or throw an exception in C code and catch it in Fortran code. i.e. You've still got to have language affinity on the JVM. Not so on the CLR.

D

If this poster had read the original article more closely, he would have noticed a link to this page, which is the work of someone who actually took the time to closely analyze everything on the list at the site that the poster provided a link to.

A closer inspection of this list at tu-berlin.de reveals that the vast majority of the items listed are not actually claiming to be compilers that produce Java byte-code. They are merely tools or compilers or interpreters written in Java. Of the few which claim to produce Java byte-code, even fewer are actually available for use (some were abandoned before completion) or have any additional information available about them.

A handful of items in the list translate source code from language subsets into Java source code first, which you can then run JAVAC on to build actual byte-code. (For example, Canterbury claims to have such a thing for Pascal, Oberon-2, and Modula-2. There is also one for translating C code to Java code, and Fortran code to Java code. Perhaps the most promising and truly byte-code producing tools on the entire page are the assemblers at the bottom.

It is worth pointing out that this still doesn't make the JVM a language-neutral platform. (Again, see the discussion at http://www.objectwatch.com/issue_33.htm.) While there are ways of producing Java byte-code from other languages, you've still got to write all of your code in whatever single language you choose. For example, there's no good way on the JVM to implement a class in Modula-2 code and derive from it in Pascal code, or throw an exception in C code and catch it in Fortran code. i.e. You've still got to have language affinity on the JVM. Not so on the CLR.

D

>> As it turns out, MS Security is not as bad as Sun's or IBM's [objectwatch.com]

I think that's not a very good example you're giving to support your argument. From the website you're linking to:

"Roger Sessions is highly respected within Microsoft. He has given many keynote talks at Microsoft sponsored conferences. Thousands of copies of his book have been given away by Microsoft."

That alone is of course not sufficient to question Mr. Session's bias or professional qualifications, but let's just say I got a little bit leery after reading this.

Furthermore, your logic seems fundamentally flawed to me. According to your chain of reasoning:

1. Microsoft has security problems
2. Other's have security problems, too
therefore
3. Microsoft is not so bad as everybody says.

This looks to me like a classical "tu quoque" fallacy. I see it again and again on /., and when I have modpoints I always mod those posts down as trolls - not because they're contrarian to /. groupthink but because they're using faulty logic and are either trolls or just clueless.

>> I'll probably be modded down as troll or flaimbait, but then it just shows the /. mentality.

Moderators, whenever you see a sentence similar to the above ("C'mon, mod me down, I have karma to burn..."), please think hard if the poster really made a soundproof argument or is just doing some social engineering on you by doing an appeal to pity in order to gather/avoid losing some karma.

Raymond

As it turns out, MS Security is not as bad as Sun's or IBM's The article is toward the bottom of the page. It's mostly about exploits via buffer overflow. But, as a Linux Zealot may not know, MS actually writes some of the more solid code.

I'll probably be modded down as troll or flaimbait, but then it just shows the /. mentality.