Frustrations with development languages

Frustrations with development languages

Summary: When it comes to development environments today there just aren't any good choices at the enterprise scale - Java is a recipe for maintenance failure, low level stuff like C is inappropriate, .net is just BASIC in expensive clothing, and PHP is immature.

TOPICS: Open Source

Last week's discussions of Java suggested to me that most of the response people have to programming language choices is driven first by the lack of real choices and secondly by issues of scale and perception.

Setting aside embedded uses of Java, I get the clear impression that if the stuff you do is what I'd consider fairly mickey mouse than you're likely to like Java because in that context it's fairly simple, somewhat safer, and far more politically acceptable than C or C++. If, however, you work with large scale business systems the Java you see is quite different: a horrendous mashup of this that and the other two things with little consistency, many, many dark corners, and roughly the efficiency of using a highway tractor trailer combination for your daily commute.

The reason for that is, I think, simple: when downloadable Java failed and people moved the code back to the servers, they extended its use into business application development when they should have abandoned it. Then, because it really is the wrong tool for that job, they tried to extend the object idea to avoid having to re-invent the wheel for each new deployment - specifically by building frameworks, libraries, and methodologies on or through which the business applications were to be constructed and run.

It almost makes sense: given Java, given object re-use, given the Windows IDE idea - but in practice what it produced was applications that require multiple generations of Sun's J2EE stuff on the same server, require multiple configuration files on idiosyncratic paths, and make debugging such a nightmare that you'll dream of doing simple things - like picking bits of smashed eggs out an anthill without disturbing the ants.

In a real sense this isn't Java: it's a compilation built on Java that masquerades as Java -but if working with it is a consequence of trying to force a Windows client run-time onto Unix, then what's the better alternative?

It isn't C/C++ - that's the right toolset for building Solaris, Apache, and the gnutools but it's absurdly wrong for something like a distributed customer support system.

So, .net? that's just BASIC with the Microsoft's proprietary version of Java's encrustation thrown in, so you might as well use Java and avoid both the risk of brain damage and the Microsoft lock-in.

COBOL? Somebody suggested that - and I hope he was joking: COBOL was an absurd codification of tabulating machine practice when it evolved in the late 40s and early 50s and hasn't gotten any more relevant to the digital age since.

So what's the alternative? I think frequent contributor fr0thy2's comment headline last week hits the nail on the head: C is fast, Ruby is beautiful, and Erlang is WTF? - and the last part of that goes for lots of unpopular choices because popularity has a lot to do with acceptability at the corporate level.

And that's the practical bottom line: there aren't many choices that are both acceptable and any good. Frequent contributor Mark Miller mentions, for example, a web development framework called Seaside - and on quick review it looks interesting enough to warrant exploration, but products like these are just too immature and too little known for enterprise scale use. Basically the problem is that no matter how well it works, the average IT manager won't buy it until its blessed by massive publicity and/or supported by IBM.

So what's left? Progress is pretty good - it's cheaper, easier to use, and both more portable and more scalable than .net - but it's still just BASIC in drag. The other 4Gls are either gone or on lifesupport -my own long time favorite: Unify Accell/Vision is barely alive and Oracle Forms, although nominally supported, is nearly unrecognizable - and new stuff is either very cool but useless at scale (like Access) or WTF - like trying to sell the TcL/Tk/Perl combination today.

So what other options exist? I think PHP sucks - but works for "risk contained" browser based applications. So, while I've never done a payroll or any other traditional business application that way, I think it could be done - and probably quite well too. More importantly, I think that the SAMP/LAMP toolset is getting better all the time -so if I were forced to bet on something right now, that's probably what I'd bet on.

And that's just awful.

Topic: Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • What's left?

    It seems that you don't like any programming language....

    Seriously the "failure" of Java EE you refer to isn't necessarily a failure of Java, it is likely a failure of software management by the IT department concerned. Many companies tend towards highly complex solutions and "smart" ways of doing things when what they need is to simplify their solutions and avoid "smart" programming techniques.

    Java, like all others, is just a programming language and, like nuclear power, can be used for either good or evil.
    • No language is suitable for all tasks

      I think the problem that Java has, is that with is "Write Once, Run Anywhere" slogan, it promoted the idea that it was one language that could do it all.

      It might be able to do it all, but it cant do it all well, and the Java eco-system has become a somewhat chaotic place in an attempt to fix the problems.

      Each problem domain needs to be addressed with a development tool well suited to that domain. Many projects encompass several problem domains, and so many projects should probably use a multi-language approach to provide the most elegant solution.

      This doesnt happen, for at least these reasons:

      1) No one wants to admit the "chosen" language doesn't not cover the entire project.

      2) Too many people cant see beyond Java, .Net, 4GLs anyway.

      3) Management react badly to the idea that they need programmers with a range of skills. Commodity Java and C# programmers are easy to find. Try finding someone with rounded skills in (for example) Java, Yacc-style parser generators and OCAML.

      4) If you're a programmer, if you put too many skills on you CV, good luck even getting that interview.
      • Rounded programmers...

        ...other than the rounding caused by too much pizza and beer, I don't think it's possible to find well-rounded programmers.

        I think you tend to find people that either know what they have found to be the "commercially viable" set of languages, and then people who know tons of them.
        Erik Engbrecht
        • Well rounded programmers ...

          ... ok jokes aside ...

          The more a nation is addicted to brand names, the less efficient that nation will be in the knowledge economy.

          Nimbleness is the key ...
          • Not necessarily

            Brand names act as a kind of tagging mechanism to quickly identify other attributes. Evaluating lots of options is expensive, time consuming, and often yields a poor return on investment.

            In other words, in order to be efficient in the knowledge economy you need to be able to build on the knowledge and experience of others. Brand names allow that to be done easily, even if the knowledge they represent is often tainted by other interests.
            Erik Engbrecht
          • Hmmmm

            "even if the knowledge they represent is often tainted by other interests" that'll be it right there ...
        • Interesting -

          From what I have seen here, if you understand business and business processes and are a programmer (the dark room days of coding are gone...) then (where possible) you should find the best tool for the job. C/C++ (my personal favorites), Java, etc. Too many programmers (a good sign they are not good) will try to rail road thier comfort language to a solution rather than try to understand the problem.

          As you a good rounded programmer with a good communcation/interpersonal/business skills can work with any tool.
      • Agreed (NT)

      • Too Many Skills?

        I think "If you're a programmer, if you put too many skills on you CV, good luck even getting that interview" needs clarification. If "too many skills" means you learned a lot of languages but never learned HOW to program, then yes. But if you understand algorithms and data structures and efficiency and speed vs. size, etc., then lots of skills can be proof of a good foundation and ability to adapt. It's all in how you write that resume and cover letter. Emphasize what they need, use everything else as backup.
    • Sure I do - but what's left isn't much

      I think about programming in terms of APL, I like Perl and C, and think Unify's Accell/Vision stuff is about as good as business application development tools ever got.

      Unfortunately none of that stuff is popular today - and the choices that are actually available today are far more limited than they were in ther 80s and early 90s.

      It's the lack of good choices that I consider the biggest problem - as you say, java can be used for good or bad - and, sadly, I think in business apps its been mostly bad.
    • Murph is a genius

      *and* he's got a grip on the good old day to day realities that the rest of us do/am/are.

      Don't necessarily take apart what Murph says at the basic level - that's what keeps everybody stupid.

      Language X, Lamguage Y, Open X, Closed Y - In terms of what the blogs say, he's there with Mary Jo and Dana (and arguably a couple of the chubby guys xx).

      Don't argue to keep your jobs, argue because you can and will compete with the best of the rest of the world ;-)
  • You know my rant by now

    Why not use a CL that was designed for million line programs? One that was designed for data encapsulation, information hiding, overloading operators, and PROVABILITY. A CL that abandons pointers. A CL that was paid for by your OWN tax dollars, and then returned to you for your own use. This language is Ada.

    Is Ada right for all programming? Right now Ada is MOST popular for real-time applications (embedded?), but was designed for massive applications. That seems to run the whole gammut to me. From smallest to largest, Ada is the choice today.

    Ada was designed in the 80's, so I'm sure the "web-aware" parts MAY be lacking - but any code can generate HTML and feed a web server . . .

    If you don't use Ada - then you are throwing away your own money, and ignoring one of the best CLs out there.
    Roger Ramjet
    • provability

      If you want provability then you should look to Haskell, or weaken that a bit and look languages like Scala, OCaml, and F#.
      Erik Engbrecht
      • Sets, Stacks and Queues - Oh My!

        The 2 major culprits in making CLs impossible to prove are pointers and array indicies. It is possible to replace ALL data structures with Sets,Stacks, and Queues - which would make provability much easier. Teaching programmers to ONLY use SSQ could prove to be a daunting task . . .

        Side note: I need to plug my organization PAPPL - People Against the Proliferation of Programming Languages. PAPPL believes that there are already too many PLs out there, and works to discourage any more - tongue in cheek of course . . .
        Roger Ramjet
    • ada - about which i know nothing

      and that's the problem: it may be great, it may be another pl1 - I haven't a clue and the reason I don't is that its not used in business.. and that's because guys like me don't know about it..

      In other words: perhaps the right answer for ada is a new name and an open source compiler project?
      • Since Ada is basically Pascal on steroids....

        ... then if you lack Ada experience take lots of steroids and do Pascal instead. It'll [i]look[/i] similar enough and you won't care about the results!

    • Why I ignore Ada.

      Chances of using it so as to keep the wife in the manner to which she is accostomed is negligible.
      • Why?

        Of course I don't know the lifestyle to which your wife a accustomed, but there is certainly a strong market for Ada programmers and Ada programming jobs tend to be much more resilient to offshoring.
        Erik Engbrecht
        • Very litte Ada around here.

          Mrs Truth and the Factoids aren't up for moving when there's plently of work around here anyway - just not Ada.
          • Welcome to : Chase the greenback for someone else

            Introducing the one and only Mr Money-Chaser himself ..... Steeevvveee Gates!!!!!!!

            Oh yeah, about these computer things ... shall we do something useful with them ???