CIO.com article on Perl's strong and weak points; what about Java's?

Discussions

News: CIO.com article on Perl's strong and weak points; what about Java's?

  1. Slashdot pointed out a post on CIO.com called "You used Perl to write WHAT?!," highlighting five strengths of Perl and four weaknesses. The strengths:
    1. Pattern Matching
    2. In-place editing
    3. A replacement for shell scripts
    4. Database manipulation tool
    5. Cross-platform
    The weaknesses:
    1. Real-time or high performance
    2. Replacement for shell scripts (yes, a direct contradiction to a matching "strength")
    3. Web scripting
    4. Obfuscation in any way
    CIO.com also has matching titles for PHP and JavaScript - although the articles aren't quite as direct. That said, what do TSS readers think Java's strengths and weaknesses are? How would you fill out the same kind of "good/bad" list for Java technologies?
  2. However, I would argue that more modern Web scripting languages, such as PHP and Ruby on Rails, offer more out-of-the-box Web support and a cleaner integration into the webpage experience. You should especially avoid using perl for traditional CGI-style form processing; this code tends to be hard to read and maintain because the HTML ends up inlined inside the perl code.
    /facepalm - One can use CGI.pm w/ say, TT and yield the same results. CGI is a communication protocol between the server (that maintains an HTTP connection) and an executable. The same is true of servlets. One can put HTML w/i code etc.. etc.. etc..
    In an obfuscated fashion: Larry Wall, creator of perl, famously stated, "Perl is designed to give you several ways to do anything." As a result, some developers have adopted the style of writing their code as compact and "elegantly" as they can. The results can sometimes be programs that look more like dialup line noise than supportable code.
    Yes, people who can read perl, will write perl. Ruby and Haskell looked like mumbo-jumbo before I sat down and learned how to write some code in each. The equivalent of obfuscation in perl is creating an OOP mess in java and chaining all the methods in that mess, together. If you want something to complain about, complain about maybe support, or perhaps the amount of people using it so it's easy to find other people using a technology. Picking on perl for those reasons is just silly. Do we really need language flames on TSS?
  3. Whoa, whoa - not a language flame at all! Heck, I have no interest in flaming Perl of all languages - it holds a special place in me 'eart. I always compare languages like Ruby and Python to Perl, because I learned Perl first. I don't care about running Perl down, or Ruby, or Python, or PHP, or JavaScript. I was interested in specifically what people thought Java's strengths and weaknesses were - not in disagreeing or agreeing with the original CIO.com article.
  4. Java problems and advantages[ Go to top ]

    Problems: 1. Realy arcane syntax - from C when compilers where hard to write and one rightfully had to create the syntax for the compiler, not for human readability, extended with C++ claiming programmers couldn't learn a new syntax, Java simply used this and fixed some minor problems. Have you ever read Eifel code or other languages with better syntax. Of corse we can't change the syntax now, but... 2. Bussiness type processing a secondary issue at best - BigDecimal anyone without operator support, different types of formatting ++ 3. Refused to implement JVM support for functional programming early on. 4. Little regard for database (relational) support. Only lately have it even become usefull. Advantages: 1. Libraries - very well built out library support and significant effort from the very beginning to extend these. 2. Frameworks many and well made (some of them). This may now become a problem instead because there are too many programmers arround with "me too" attitudes, but still a significant pro. 3. Tools very well built out. A problem in the very beginning, but they came fast. (Anyone still remember the stupidity of the IDE versus ... debates. Please remember them for the purpose of not repeating them.) These where only a few pointers.
  5. Re: Java problems and advantages[ Go to top ]

    Problems:
    1. Realy arcane syntax
    Once there was Cobol who though that you should write programming code like normal english. move a to b. add 3 to b. Well, that didn't work. You're writing computer code, not literature. Then the C based syntax came and that syntax kinda stuck: Objective-C, C++, Java, C#. Personally I have totally no problems with the syntax, in fact I like it. And since it has become a defacto standard, more people seem to think it is ok. Thing is, every language has certain constructs; blocks, conditions, loops, lists, etc. Take "blocks" for example, why is any other symbol better than { ... }? No symbols at all, but indentation? I rather have clear block-borders instead where the formating also has functional implications. Should the tabs space be set to 2 or 4 to distinguish between a loop and a condition? ;-) So I think that the C alike syntax has proven itself when writing computer code, so I'm really curcious what a not-arcane syntax would look like and how it is better.
  6. COBOL "didn't work?"[ Go to top ]

    COBOL didn't work? I... respectfully disagree. COBOL worked marvelously. Still does, fifty years later. COBOL just doesn't work for the same things most people want and need - COBOL sucks for systems programming, for example. Awesome for business programming, because it's easy to take an algorithm that's written in English, show it to a business owner, and say "Is this right?" Show the same owner your C code, and his eyes will spin and he'll fall down dead. Joseph Ottinger, with a good ... 6 years of employment doing COBOL
  7. Re: COBOL "didn't work?"[ Go to top ]

    COBOL didn't work? I... respectfully disagree.
    Please bear in mind that I'm talking about syntax only, not Cobol as a language or even platform. I've done more than enough Cobol to know better. :-) It is not without reason that "modern" Cobol syntax is sliding towards more common syntax; instead of 'NOT EQUAL TO', no strict regulation of the indentation anymore with special meaning of characters in certain columns.
  8. Re: Java problems and advantages[ Go to top ]

    Why you even mention one of the other languages with realy arcane syntax I have no clue. Why not, as I suggested, take a look at Eiffel. Se: http://en.wikipedia.org/wiki/Eiffel_(programming_language) or http://smarteiffel.loria.fr/ or perhaps http://www.eiffel.com/ Look at the syntax and some of the other facilities. It first came out something like 1985. Java came in 1995. The Java gurus at the time could have taken a look at Eiffel. They didn't (or wouldn't?) and looked to C and C++ instead. They had apparently heard from the C++ designer the all overriding idea that programmers couldn't be expected to learn a new syntax. When a language was first popular enough the syntax of that language should forever doom all programmers. Eiffel is simply a leap forward at the syntax level (and some other areas) that seemed to be completely without any redeeming value 10 years later when Java was introduced. And the only reason I have ever seen for this strange idea is that programmers can't be expected to learn a new syntax - even if it's clearly better. How strange.
  9. Re: Java problems and advantages[ Go to top ]

    Eiffel is simply a leap forward at the syntax level
    Again: why is the syntax a leap forward? Is do ... end better then { ... }? Why is this below better (from a syntax perspective) than the Java equivalent? class HELLO_WORLD create make feature make do print ("Hello, world!%N") end end vs class HelloWorld { static public void main(String[] args) { System.out.println("Hello, world"); } } I'm not talking about functionality (otherwise let's drag in Smalltalk as well), I just want to know why this syntax is not arcane and Java's is.
  10. Re: Java problems and advantages[ Go to top ]

    Eiffel is simply a leap forward at the syntax level


    Again: why is the syntax a leap forward?

    Is do ... end better then { ... }?

    Why even ask? To show a lack of understanding?

    Why is this below better (from a syntax perspective) than the Java equivalent?

    class
    HELLO_WORLD
    create
    make
    feature
    make
    do
    print ("Hello, world!%N")
    end
    end

    vs

    class HelloWorld
    {
    static public void main(String[] args)
    {
    System.out.println("Hello, world");
    }
    }

    I'm not talking about functionality (otherwise let's drag in Smalltalk as well), I just want to know why this syntax is not arcane and Java's is.
    What about: class HelloWorld feature main is do println(Hello, world!") end end Of course in stead of do/end the Eiffel could perhaps have had { and } from C. However this example of yours (fixed above) doesn't tell the real story either. One issue is that Eiffel has done away with getters. The syntax for accessing a class variable and the syntax for calling a zero parameter method is the same! That's a good thing removing pure redundancy from a lot of classes - and often a lot of reduncancy - retaining better cold quality! class Point feature x: REAL y: REAL rho: TEAL is do Result := sqrt(x ^ 2 + y ^ 2) end theta: REAL is do .... end .... end Code something like this works fine: xvalue: REAL xvalue := somepoint.x Then for some reason you want to redefine your Point class as follows: class Point feature rho: REAL theta: REAL x: REAL is do Result := some math here end y: REAL is do .... end .... end Although both x and y are now methods the usage code still works: xvalue: REAL xvalue := somepoint.x although now the x method is called and above it was a direct reference to a class variable. This is very good! It's just one small element of several other things that are good about Eiffel and Java could have picked up on 10 years later if the Java designers had bothered. Some other elementary things that are good: Type stated after name x: REAL, not real x increases general readability as the variables are the important thing, type is secondary. Access modifiers (public, private...) similarly doesn't clutter up as much by beeng placed after class and method declarations, not before them. Multiple inheritance with elegant solutions to problems others have had (mind you again: 10 years before Java tried but failed). And several others - also beyond the syntax. The only strange thing is wy the programming world is so incredibly slow to learn from good ideas. Amazing.
  11. The bad: 1. No mixins 2. TGI Friday's of generics - either half-baked or over-done depending on your perspective 3. Extremely verbose syntax 4. No operator overloading The good: 1. Mixins look at lot like multiple inheritance and therefore confuse the heck of out people 2. Fuller generics are very hard to grok (see Type-constructor polymorphism in Scala), lack of generics leads to either lack of type safety or code duplication 3. Simple, consistent, straight forward syntax 4. No operator overloading 5. Highly portable 6. Decent performance Java is the language of compromise. It also goes with the assumption that if a feature is there, many people will use it, so if most people shouldn't use a feature, it should not be there. Scala is much, much more expressive than Java, and a bit more type safe. But achieving that level of expression and type safety can be extremely complicated. Sure, you can say "only framework and library writers should use those features," but who is going to listen? Dynamic languages feel much more expressive than Java, but you give up type safety and usually performance as well. So everyone thinks Java is missing something, or doesn't go far enough, but they all have different directions. The problem is if Java tries to go in all those directions at once, we'll be left with something on par with C++.
  12. Scala: for frameworks?[ Go to top ]

    Hi Erik, I don't know much about Scala -- I should learn it! Anyway, you suggest that Scala's features are more appropriate for framework and library writers. I was wondering, can a developer create a framework or library in Scala that can be called naturally from Java? I guess I'm asking, is the type system compatible enough? Regards John Hurst
  13. Re: Scala: for frameworks?[ Go to top ]

    Hi Erik,

    I don't know much about Scala -- I should learn it!

    Anyway, you suggest that Scala's features are more appropriate for framework and library writers. I was wondering, can a developer create a framework or library in Scala that can be called naturally from Java? I guess I'm asking, is the type system compatible enough?

    Regards

    John Hurst
    Yes, no, and it will be better in the future. As a rule of thumb, if you want to use Scala code from Java, it's a good idea to write Java interfaces, implement them in Scala, and then code to those interfaces in Java. Right now Scala does not have good support for Java generics. That is going to change in the next version. Also, the Java coder would also lose the benefits of many Scala features. So a Java class code use a Scala class that was composed using mixins, but it could not mixin a Scala trait. Or if you wanted to use a method that takes a function as a parameter from Java, you would have to use an anonymous inner class rather than a closure. So, YMMV. I would say it could work well if the surface areas of the framework's interface was small and Java-esque, and the internal implementation was very complex. I suggest you checkout Lift: http://liftweb.net It's not designed to be used from Java, but it's a good example of a framework done in Scala.
  14. Dynamic languages feel much more expressive than Java, but you give up type safety and usually performance as well.
    Java is not type safe by the formal definition of type safe: http://www.cis.upenn.edu/~bcpierce/courses/629/papers/Saraswat-javabug.html The method for violating type safety is obscure and unlikely to be hit by accident, though. For at least some dynamic languages (Ruby), the type safety is only violated through particular interfaces that type control (instance_eval, instance_variable*, and method modifiers), so I believe you really have type safety inside the language (assuming no C extensions are used.) What you DO give up is static type checks; this may be a relevant loss in cases where you have a large codebase, though I think the benefits of easier development outweight the cost of not having typechecks until you reach a fairly large scale. (Many manyears and a fair amount of programmers.) Eivind.
  15. Java is not type safe by the formal definition of type safe:
    Eiffel is not cool by the formal definition of cool: Isn't it great when you get to make up your own definitions so that everything you like is, by definition, "cool" and everything you don't like is, by definition, "not cool."
  16. lack of [...] Obfuscation in any way
    Well, as a longterm Perl user, I can assure that Perl has obfuscation built-in into the language. By design :). regards Artur
  17. CIO.com[ Go to top ]

    Come on guys, You can get better technical information articles from Playboy magazine. cio.com... jeez...
  18. Re: CIO.com[ Go to top ]

    I only read CIO.com for the artciles.