Slashdot Mirror


What Makes a Powerful Programming Language?

A not-so Anonymous Coward queries: "My company is about to start development on a new project, and I have to decide on a language and development environment. My boss gave me a set of criteria which needs to be filled: intuitive and easy to use IDE; simplified GUI design and event handling; advanced error handling; advanced object oriented design including multiple inheritance, abstract classes, and garbage collection; full support for operator and function overloading; and portable (at compile-time) across various platforms. I have already looked at C++, Java, C++, C#, Eiffel, and even VB.net; I may be missing something but as far as I can tell all of these languages are missing something from this list. Is there a language available that has all of these features? I thought that someone from Slashdot would be able to point me in the right direction?" If you were to design a language from the ground up, what features would you include and why?

5 of 1,098 comments (clear)

  1. Who cares? Language wars are over by Ars-Fartsica · · Score: 5, Interesting
    The powers that be have decided - statically typed, object-oriented languages are what you are going to work with, not because they are better or more productive but for two reasons:

    1. Its what "everyone else" is perceived to be using,

    2. Programming cannot be suitably be turned into a MacJob until the variance in the toolset is reduced.

    Microsoft's .Net and Java are going to occupy 70% of the brainspace for programming in the next ten years, and these languages conform to my description above.

    Sure, Lisp is cool - its also dead in the market, so stop trying to resurrect it based on its coolness. No one cares.

  2. Common Lisp by entrox · · Score: 5, Interesting

    You can have all those features and many more if you use a commercial Lisp implementation (the free ones have no decent IDE or GUI yet).
    If you have a serious budget, take a look at Allegro Common Lisp. The other choice would be LispWorks, which is a little cheaper and without run-time fees.
    They both have an excellent IDE and come with Interface Builders using CLIM, meaning your apps run under Windows, Macintosh and Unix (Motif) without a big hassle using native widgets.

    --
    -- The plural of 'anecdote' is not 'data'.
  3. really stupid requirements by slag187 · · Score: 5, Interesting

    These requirements are terrible. Requirements should not specify implementation details. While abstractly saying things like Object Oriented Design with good GUI tools that supports event handling and good error or exception handling is fine, saying we HAVE to be able to have ths syntax: object1 + object2 is ridiculous.

    1) Advanced OO design.
    Ok, I can understand wanting OOD/OO Programming constructs explicitly supported. Abstract classes (and/or) interfaces and inheritance, etc. are all good OO constructs. But REQUIRING multiple-inheritance? Why? There are many good OO languages that don't do multiple inheritence. And GC has nothing to do with OO - while it might be a good criterion on its own.

    2) Operator overloading.
    This is such a crock. Is there anything that can not be accomplished without Operator Overloading? There are many arguments against using operator overloading in fact even in languages that support it. (Non-intuitive nature of it sometimes, the failure to implement all operators including comparisons, etc.)

    If you take out the 2 dumb requirements above, you open the door to all kinds of languages:
    Java, Python, Smalltalk, etc.

    Then you can truly evaluate them on the availble RADs for the language, performance and suitability to the end project requirements.

    Fire your boss!

  4. Objective C / OpenStep/Cocoa by tbien · · Score: 5, Interesting

    Hi,

    do yourself a favour and take a look at
    Objective C and the typical Frameworks
    like Openstep or even more recent Cocoa.

    As a converted Linux, now Mac User I recently
    discovered those goodies and I really don't
    understand why they didn't take off in the past
    (NextStep has been around since the 80ies).

    Objective C is such a powerful dynamic language
    and it is real fun to write programs with it.
    You have a clean and lean Smalltalk-in-C object
    oriented syntax and are able to use all those
    low-level C APIs... I don't know any better.

    PS: For the use with Windows try to get one
    of the OpenStep 4.2 packages one often find
    at ebay. Besides the native Next/Sun/i386
    OpenStep OSes it includes a devkit for
    the use under WinNT... If use ever had to
    use COM and alike, you will really, really love
    OpenStep....

    PS: There is even a GNU implementation of the
    OpenStep API... -> GNUStep

    Pointers:

    http://www.stepwise.com
    http://www.gnustep.org

  5. A hot topic. Java. Versus ... Perl??? by PhotoGuy · · Score: 5, Interesting
    Wow. Obviously a hot topic. I read slashdot religiously, and it's seldom I get to a post before a hundred or so posts have been made. But 600 got in ahead of me this time. (No FP! for me!)

    And a good sign of it being an emotional topic is that almost all of the posts are below my viewing threshold. Far more than normal.

    Here's my take: I used to be one of the biggest Java advocates around. (In fact, I was one of the winner's of Sun's Java Cup programming contest.) I fought off learning Perl for years, but today, my language of preference is now Perl. Here's why:
    • Portability - Where Sun brags about "write one, run everywhere", Perl actually delivers. Java's available on a few platforms (and even fewer, supported by Sun). But Perl has *much* wider availability. As one example of many, FreeBSD didn't have a reliable, supported Java implementation until very recently (if even now), whereas Perl has been there for ages. And somewhat disturbing is that the most reliable Java implmentation is on Sparc Solaris. Even I386 Solaris has serious issues. I guess making sure you fix problems on your own platform is a natural tendency, but it does go against the reliable portability that Java promised. (As compared to MS's anti-competitive behaviour, this is small stuff, but an issue nonetheless.)
    • Reliability - I've had JVM's cransh on me, run out of memory inappropriately, and have other ugly problems. I haven't seen this with perl, yet. I've looked to IBM, Sun, Symantec, TowerJ, and others, for a solid, fast JVM, and they all seem to have fatal weaknesses.
    • Consistency - I've found far greater consistentcy in the behaviour, performance, and reliability of Perl across platforms, than Java. I've seen Java seriously choke under pressure, and run out of memory. It might be fine for lightweight, run-once applications. But for heavy-duty stuff, it's repeatedly disappointed me.
    • String Manipulation - In the majority of applications I've come across, *especially* web application, most of the work you end up doing is string parsing and manipulation. Perl's regular expression functions far outshine Java in this aspect. A one liner replaces a fifty-liner. Yes, the person maintaining the code has to know Perl regular expressions inside out, but I don't have a problem with that requirement.
    • API's - CPAN seems to have far more exhaustive support for standard API's, well in advance of Sun's. They are usually more fragmented initially, and I would prefer the centralized approach of Sun, if it could just keep up. But it can't (or at least doesn't).
    • Open Source - While Sun talks a lot about being open source advocates, Java's source is far more restrictive and harder to get or legally use, than Perl's. (Although I am against the non-commercial restriction of GPL. Hmmm, Perl is GPL, isn't it? Have to check that, as I'm not 100% sure, but it's a good guess.)
    • GUI - AWT was efficient, but hard to use. Swing is very cool looking, with great features, but *slow*. Perl/TK is fast, efficient, portable, easy to use. It's by far my preferred rapid GUI environment. (A bit of foreshadowing perhaps: On my winning JavaOne entry, I used PackerLayout [I think], which was a port of the Tk layout mechanism to Java. Okay, okay, packer actually originated with Tk, not Perl, but since Perl/Tk is more or less the defacto Perl GUI, it's not complete out of context :-)
    • Multithreading - This is actually one point where Java shines over Perl. Perl has no standard multithreading, which truly, truly, sucks.
    • Elegance - This is another area where Perl fails, but another area where it doesn't matter :-) Perl is ugly, Java is elegant and beautiful to look at. But I can do more with perl, more quickly. And super-efficient hashes as a core part of the langauge allow passing arguments as key-value types, as is encouraged in their object programming model. This, I find more elegant. So at the surface, Java is prettier. But one layer down, where it really counts, Pelr is more elegant.
    So in short, I've "been there, done that" with Java. Perl is liberating me from a lot of the problems I had with Java.

    (And on a rather irrelevant, but rather appropriate bit of symbolism: I happened to be wearing a JavaOne Long Sleeved T-Shirt tonight as I wrote this. The wrists were a bit tight, shrunk from washing, I guess, so I tugged on them to loosen them a bit. The whole sleeve ripped. Kind of symbolizes my experiences with java. Shoddy merchandise, all around :-)

    -me
    --
    Love many, trust a few, do harm to none.