Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

How would you fix Java?

by Anonymous Monk
on Apr 21, 2003 at 06:33 UTC ( [id://251948]=perlmeditation: print w/replies, xml ) Need Help??

....

....

....

....

....

....

....

....

Okay, now that you have had a chance to reflect on your predisposition towards this post based on its title, I have a question. I seem to be unable to read a thread anywhere on this site (let alone the poetry section) without someone implying something negative about Java's quality. Why is this?

Even in posts completely unrelated to the subject, I come across little barbs like the following:

I am a native English speaker (and unfortunately a native Java speaker)

Since when does stating you know a language require a disclaimer? I occasionally wonder about the effects of such comments. The vast majority of anti-Java zealots I've spoken to seem to have very limited knowledge of programming languages. They first learned a different language (often Perl), and following that heard about Java. These people have rarely heard of inheritance, polymorphism, or even garbage collection. Yet, they offer very strong opinions on Java's merits as a language.

Maybe I'm naive to think technical fora are exempt from this type of widespread ignorance that plagues so many other sectors of society.

I should also note, yes, I have read the "How does Perl compare to ..." perlfaq that states:

Favorably in some areas, unfavorably in others. Precisely which areas are good and bad is often a personal choice, so asking this question on Usenet runs a strong risk of starting an unproductive Holy War.

This seems like a real cop-out to me. Why should we be unable to discuss the merits of languages for fear of a few trolls who are biased or ignorant of the subject? Downvote this post if you will, but please don't bother disregarding it as flamebait, my sole reason for posting this is to solicit your input, not start a "unproductive discussion." If it helps, simply think of all the other issues out there that are currently suffering from adequate debate (religion, evolution, philosophy). Okay, mentioning those probably didn't help me ;-).

On with the discussion, I'll start with a couple of the more common arguments I've heard against Java, though neither of them especially technical:

  1. Java is owned by Sun.

    This is probably the best argument out there against Java. From annoyances like having to add disclaimers when publishing anything referring to Java to more sever problems like possible exploitation of the situation by Sun, there are many concerns. However, I'd like to focus on the actual Java design, so for the purpose of my question, please disregard this problem. Oh, and, ahem Java™ and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U. S. and other countries. ;)
  2. It takes too many lines just to write a simple program

    I don't really view this as a negative point. All code, up to and maybe even including one-liners, should be stored in a reusable, maintainable form. Also consider what percentage of your code is written in such a short form. Is adding a few extra straightforward lines of code really a huge inconvenience?

Please add your comments as to what you think about Java could be improved. Thank you for your input :)

Replies are listed 'Best First'.
Re: How would you fix Java?
by IlyaM (Parson) on Apr 21, 2003 at 07:25 UTC
    It takes too many lines just to write a simple program

    I don't really view this as a negative point. All code, up to and maybe even including one-liners, should be stored in a reusable, maintainable form. Also consider what percentage of your code is written in such a short form. Is adding a few extra straightforward lines of code really a huge inconvenience?

    The thing is that in Perl it can be both less lines for same thing and it can still be a maintainable code. I recall I read a study that in average number of bugs in programs is proportional to a number of lines and the coefficient doesn't depend too much on language. So less lines means easier to maintain.

    Please add your comments as to what you think about Java could be improved.

    1. Obviously a library of reusable compontents like CPAN (this is one of reasons why in Perl you can write less code).
    2. Ability to mix easily procedural, OO and functional styles of programming (though I doubt it will ever happen).
    3. Make it more dynamic language (think runtime generation of code, symbol tables manipulations, very flexiable OO without artficial restrictions like single inheritance, remove static typing - again I doubt it will ever happen as it will be completly different language :).

    --
    Ilya Martynov, ilya@iponweb.net
    CTO IPonWEB (UK) Ltd
    Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
    Personal website - http://martynov.org

      Excellent comments, thank you for your reply :)

      A couple questions:

      Ability to mix easily procedural, OO and functional styles of programming

      How important is this to you and are you looking for something like Python's approach to this? Do you think it offers that much more usability than just throwing everything in a class?

      Obviously a library of reusable compontents like CPAN

      Is it just the more specialized modules you find lacking from Java (the Finance::Quote type modules), or is it problems with included libraries (including lack of api choices)?

        Ability to mix easily procedural, OO and functional styles of programming.

        How important is this to you and are you looking for something like Python's approach to this? Do you think it offers that much more usability than just throwing everything in a class?

        Frankly I'm Python ignorant (I have only walked through Python tutorial once and it was very long time ago so I forgot everything anyway :( ). Can you tell how it compares with Perl in this aspect?

        Obviously a library of reusable compontents like CPAN.

        Is it just the more specialized modules you find lacking from Java (the Finance::Quote type modules), or is it problems with included libraries (including lack of api choices)?

        I like that fact that there is central repository of reusable tested Perl components which are easy to install. In other languages you are either stuck with core libraries or you have to hunt for other libraries over all Internet. This discourages code reuse (how many times have you heard "I don't want to use this library but rather reinvent it myself so my users are not forced to deal with many external dependanices"). One negative side is that I think in other language communities programmers contribute less in reusable libraries. Another is that you see a lot of code going in core (think PHP, think Java) making it bloated.

        --
        Ilya Martynov, ilya@iponweb.net
        CTO IPonWEB (UK) Ltd
        Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
        Personal website - http://martynov.org

        I think the point about CPAN is that there is no single place where you can load up on Java packages. I'm sure with enough time on Google, you could probably find Java equivilents to many popular CPAN modules. In some cases, CPAN modules were even directly inspired by Java packages (Log::Log4perl, for instance). But it's spread all over the Internet instead of one easy-to-search place. And there is no Java equivilent for saying "perl -MCPAN -e 'install Foo::Bar'".

        ----
        I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
        -- Schemer

        Note: All code is untested, unless otherwise stated

      I forgot one question, how do you feel about optional static typing? Thanks.

        Both thumps up. It is very perlish to support many styles of programming :) I just don't like when I'm forced to program in one specific style. BTW I think we've been promised to have optional static typing in Perl 6.

        --
        Ilya Martynov, ilya@iponweb.net
        CTO IPonWEB (UK) Ltd
        Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
        Personal website - http://martynov.org

•Re: How would you fix Java?
by merlyn (Sage) on Apr 21, 2003 at 14:19 UTC
    Not to fan the flames too much, but if you want to prefer Java over Perl, you must buy into the following paradigms:
    • Early binding for objects is better than late binding
    • Objects are universally better than non-objects
    • Explicit is better than implicit
    • Corporate-control cathedral is better than open-source bazaar (bizarre? {grin})
    I believe these are the main axes along which Java differs from Perl. I might have missed one or two.

    Any one of these points is a religious argument. Yes, I happen to think the opposite of every one of these. But if you think differently, feel free to use Java in its current form. I won't mind. (I'll still get more done at the end of the day than you do, but that's another story. {grin})

    It's not a matter of "fixing" Java, as the thread implies. I think "to each his own". Java is optimized to support the paradigms listed above. And that's perfectly within the right of the developers.

    I've shared a panel with James Gosling a few years back, and got to have lunch with him mid-day. He's a nice, well-intentioned guy. (Well, I think writing an Emacs program messed him up for life, but that's another story.) He's created a language that meets his goals, and apparently also strikes a chord in a lot of others. Sound familiar?

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

      but if you want to prefer Java over Perl, you must buy into the following paradigms:
      ...
      Objects are universally better than non-objects

      I'll disagree with this one. I'd say that in Java you're required to use objects, but that does not mean you're required to like them better. For some the requirement is completely acceptable, others it's a small tradeoff, and others it's a major annoyance. However, you do not have to agree with every design issue to use a language. What you're saying is tantamount to saying that anyone who uses python has to like whitespace restrictions, which I know is false :)

      Well, I think writing an Emacs program messed him up for life

      Wouldn't you be? I know I would ;-)

        I don't know where you read "like". I didn't say you had to like these preferences, just that you buy into them. I don't like the notion of paying taxes, but I understand its purpose, and buy into it.

        -- Randal L. Schwartz, Perl hacker
        Be sure to read my standard disclaimer if this is a reply.

(jeffa) Re: How would you fix Java?
by jeffa (Bishop) on Apr 21, 2003 at 14:37 UTC

    I learned Java before i learned Perl. I even got one of those fancy certifications. I thought Java was quite fun and exciting. Then i discovered Perl ...

    Even after i discovered Perl, i still liked Java. So i joined JavaJunkies, only to discover that my "Java Personality" had been replaced. Now, mind you that there are other 'cross-over' monks who happily code in both languages. But i myself am so disgusted with Java at this point that i don't think i will ever touch it again. Not when languages like Perl, Python, and Ruby exist.

    For the record, i am OO programmer. I was very fortunate to take an OOP class in college which use the GoF book as the textbook. I am not the best OO programmer, but i know me some OO! One of the first projects i bestowed on myself was to port Design Patterns over to Perl. Not only did i find that other folks shared the same idea ... i also found out that Perl doesn't really need them ... and maybe even Design Patterns Aren't!

    Hey ... you know what? It does take too many lines to code something simple in Java. That's why you really need an expressive IDE to go along with Java. Those Java programmers who claim they need only vi/emacs probably either type at 90+ wpm or love to waste their time typing. (and for those who hate having to write all of that code just to get some objects up and running ... check out Class::MethodMaker.)

    At this point, i really don't think Java can be improved - it's too late. The designers of Java made the choice for the language to flexible rather than making the language easy to use. Bad mistake, because i really think the language isn't even that flexible. Not as flexible as Perl, Python, or Ruby. Heh, i am starting to think C++ is a better choice than Java. :)

    Listen ... Java vs. Perl ... whatever. It's all about mindsets, and unless you learn both, you can't make up your mind which kind of programmer you are. If folks don't like you for chosing one, so be it. And like i said before, noboby says you can't do both ... i tried ... what can i say? Perl spoiled me! :)

    besides ... aren't we comparing oranges and apples?

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
    -R--R-RR-R--R-RR-R--R-RR
    B--B--B--B--B--B--B--B--
    H---H---H---H---H---H---
    (the triplet paradiddle with high-hat)
    

      Thanks for the reply :)

      At this point, i really don't think Java can be improved - it's too late

      I don't work for Sun, and I doubt they would be interested in what I'd have to say anyways. This isn't really about improving Java. This is an attempt on my behalf to learn more about what are some major complaints about the Java language, and what people feel would be adequate solutions to these perceived problems. I'm not asking this so I can send a few patches to Sun with a get well soon card. I'm asking so I can learn more about the topic. Hope I cleared that up.

      besides ... aren't we comparing oranges and apples?

      Ah, but the only things I'm trying to compare here are Java, as it exists today, and Java, as it could theoretically exist tomorrow with the improvements people suggest.

        You are most welcome. I wouldn't mind Java so much if there were some kind of CJAN. My biggest beef with Java is that programmers end up reinventing wheels that they shouldn't have to. The existing Java classes are only 50% complete - you have to come up with the other half. A good CPAN module, on the other hand, is 90% of your work already written. Java needs a comprehensive archive, but i think that the red tape of bureaucracy is Java/Sun's biggest hurdle.

        For example, consider this post from JavaJunkies. Java has a class called StringTokenizer that does a durn good job of tokenizing strings. But why should i have to reinvent a wheel to use that class to parse a CSV file? Why should i have to search the web for a solution that someone else has coded for themselves? Java needs a CJAN. Bad. Either that or they need to hook up with Parrot - then (hopefully) one could simply utilize the power of Perl's CPAN within their Java programs.

        jeffa

        L-LL-L--L-LL-L--L-LL-L--
        -R--R-RR-R--R-RR-R--R-RR
        B--B--B--B--B--B--B--B--
        H---H---H---H---H---H---
        (the triplet paradiddle with high-hat)
        
Re: How would you fix Java?
by Aristotle (Chancellor) on Apr 21, 2003 at 13:56 UTC

    I don't know if it's been pointed out already (too many links to check), but if you haven't seen this post, Re: Re: Perl falls victim to shifting trends(Opinions/Comments From The Other Side) is beyond well worth a read. You will probably also enjoy Perl Functionality in Java.


    "It takes too many lines just to write a simple program."

    I don't really view this as a negative point.

    Yes, it is, though the real issue isn't "too many lines for a simple program".

    If I had a nickel for every time I've written "for (i = 0; i < N; i++)" in C I'd be a millionaire.

    — Mike Vanier

    The real problem is when a considerable portion of your code consists of red tape. Why muddy the clarity of an algorithm with things that the machine can keep track of for itself? Sure, efficiency is occasionally a valid concern to do that - but far less frequently than most people (probably) think.

    Verbosity doesn't equate to maintainability. Actually, I find that brevity does far more so; the sad truth is that most people simply can't express themselves both briefly and concisely, so the typical snippet of brief code is much less clear than it could be. This is what the quote Make it possible for programmers to write in English and you will find the programmers cannot write in English refers to.

    I guess verbose languages give folks a sense of productivity - "I'm writing a lot of code, so I must be getting a lot of work done, right?". Well, I go to great pains to make my code brief, concise, readable, and maintainable, all at the same time, and in terms of LoC (lines of code) per hour, I'm pretty slow as a result. But I've also found that the resultant code is usually very flexible, without arbitrary limitations (simply because Perl itself does not place any of them - memory size is the limit, is just the most obvious example), and most of the time can be extended in crazy ways very easily.

    Esp if you figure in the killer application that is CPAN, the latter point can grow to aweing dimensions.

    Personally, I would like to have had first hand experience with Java - both to know what I'm talking about, but also because it's such a highly markettable skill. Well, I got deep into Perl first, which sealed the fate of Java with me. I attacked several Java books trying to get with the swing of things, but I simply never get further than halfway through because it's so boring and longwinded to do even the simplest things. I just can't be bothered dealing with the red tape. It's mindless drone work; I want to concentrate on my algorithm, or generally speaking the task at hand - not the logistics required to make it happen.

    Makeshifts last the longest.

      I guess verbose languages give folks a sense of productivity - "I'm writing a lot of code, so I must be getting a lot of work done, right?"

      I remember a friend telling me about his dismay when learning about the definition of 'work' in physics. I forget the formula he used but it's a measure of how much is accomplished and not the effort expended to accomplish it. If you bring effort into the equations, you're measuring efficiency.

      90% of every Perl application is already written.
      dragonchild
        It's W = F * d, force multiplied by distance. (Actually, that should be x, a vectorial multiplication, because force has a direction, but whether that is necessary depends on what you are trying to calculate.) You have a point, strictly speaking, but I'm using the term as it's used colloquially.

        Makeshifts last the longest.

Re: How would you fix Java?
by Ovid (Cardinal) on Apr 21, 2003 at 17:59 UTC

    Asking how one would fix Java is akin to asking how one would fix Perl: you're going to get a lot of opinion, much of it based on personal beliefs (rather than realities) and personal circumstances.

    To me, the major difference between the two is scaling of productivity vis-a-vis programmer performance. In Java, it can be easier to get a large team of mid-level programmers to build large systems due to a variety of language features that many in Perl object to:

    • Compile-time enforcement of exceptions (which are sometimes stubbed out, negating that benefit)
    • Strong typing which alleviates certain classes of errors (adding apples and oranges, for example).
    • Cleaner separation of class and instance data and methods
    • Signature-based method overloading
    • Easy to enforce data encapsulation
    • Easy to enforce private methods

    All of the above can be handled in Perl, but not as cleanly or easily. Since Perl allows one to play fast and loose with terser code, you can have a smaller team enjoy much greater productivity, but you have to have a higher caliber of programmer who has a more ingrained understanding of why the above might be beneficial.

    One problem with Java really is the length of programs. To build those larger systems, you have a need for a larger group of programmers. This means more management, more communication, more strain on resources, etc. As a result, you hit the problem of diminishing marginal productivity much faster.

    That's not a clean win for Perl, though. Theoretically, having a smaller number of programmers with the same level of productivity means fewer opportunities for miscommunication, lower strain on resources and rapid development. While this can dramatically reduce costs, how do you identify a Perl programmer who has the necessary ability to be productive in a large team? Simply knowing everything about the language isn't enough. You have to know how to design systems and how to play well with others. These are not trivial tasks and many managers, while great at managing technical people, may not be great at evaluating technical people. One bad Perl programmer can churn out a lot of awful code which can be very expensive to fix, thus negating the benefits of going with Perl.

    Many of these issues may be dealt with when Perl 6 is widespread, but we still need to build products now. This means that for a management team investigating alternatives, Java may not be a bad choice. Personally, I don't care for the language, but that's because I work differently.

    And some gripes about Java (feel free to correct me as it's been a long time since I used Java):

    • Immutable strings limits its suitability for intensive text munging due to the need to repeatedly copy strings and eat up memory.
    • Give me print formats, or give me Perl!
    • Primitive types were poorly designed and shouldn't have been put into the language in their current incarnations.
    • Libraries keep getting moved into the core which are not always fully backwards-compatible.
    • I don't need a nine-megabyte "hello world" executable.
    • Arrays are too simplistic and force awkward work-arounds (and collections cannot contain primitives!).

    Mind you, I can easily come up with a similar list for Perl, but I know Perl's limitations, so they don't bug me as much. Naturally, that should not be taken as a "Perl is better than Java" statement :)

    Cheers,
    Ovid

    New address of my CGI Course.
    Silence is Evil (feel free to copy and distribute widely - note copyright text)

      Thanks for the reply.

      In Java, it can be easier to get a large team of mid-level programmers to build large systems due to a variety of language features that many in Perl object to:

      I've noticed this often stated as a positive and as a negative. Does anyone know of a practical application of some sort of middle-ground? What I'm thinking of is basically expanding the choice in areas such as optional typing to a language-wide basis. Maybe throwing a 'use enterpriseDev' (or lemmingDev depending on your opinion) which would enforce some of the points in your first list.

      Mind you, I think the lack of oxygen means I've just gone in over my head. Time for a little more research. Thanks for all the excellent responses :)

Re: How would you fix Java?
by hardburn (Abbot) on Apr 21, 2003 at 14:17 UTC

    Java's biggest strength is that its object system is probably the best of any commonly used language (i.e., one that is actually used, not just an academic oddity). The worst thing about Java is that it had better have a great object system, because you're going to be forced to use it no matter what.

    Perl5's beggest weakness (IMHO), is that its object system is probably the worst of any commonly used language. It ain't pretty, but it gets the job done. It's not so bad for the applications programmers to use (what difference does it make if you say "$obj->foo()" instead of "obj.foo()"?), but it is an effort in kludginess for anyone developing new classes. Fortunatly, Perl doesn't force you to use its object system. You can write your program in a purely functional or procedural manner, too.

    In fact, thanks to CPAN (probably the largest and best example of code reuse ever), many programs can rely on existing classes and therefore are so simple that anything but procedural just gets in the way.

    For instance, I wrote CGI::Search for my current employer (who then graciously allowed it to be publically released) in order to simplify the many seperate search scripts on our web site. The example script shown in the synopsis for CGI::Search is a little over 100 lines and contains everything my employer needs for the vast majority of our searches. Most of those lines are just filling in data structures, and the exact size will depend on the complexity of the flat-file database that you're searching and the number of input parameters. Doing these scripts as anything but procedural is just taking up extra space without adding anything. In other words, the script itself is just a little glue to tie user input into an object.

    I doubt Java will ever go the route where you can use it without declaring at least one class. It would be too much of a change from where it is now.

    Keep in mind that although Java might be great for those really big problems, little problems tend to outnumber the big problems. Perl fills that space quite nicely.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    Note: All code is untested, unless otherwise stated

Re: How would you fix Java?
by PodMaster (Abbot) on Apr 21, 2003 at 07:06 UTC
    Kindly stop making assumptions (too many assumptions).

    There have been plenty of fruitful discussions about Java on this site and in other places.

    The only issues Java may be suffering from are performance(flaky implementation accross the board), and lack of shrinkwrap products (or so some perlmonger things).

    Okay, now that you have had a chance to reflect on your predisposition towards this post based on its title

    That sentance epitomizes your own bias/ignorance -- why do you throw out disclaimers? huh Anynymous Coward?

    You can't start a fruitful discussion by being obnoxious.


    MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
    I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests.
    ** The Third rule of perl club is a statement of fact: pod is sexy.

      There have been plenty of fruitful discussions about Java on this site

      I searched and didn't find any. Could you please point me to them? Note, I'm looking for posts that specifically address perceived problems people have with Java. Thanks.

      The only issue Java is suffering from are maybe performance, flaky implementation accross the board, and lack of shrinkwrap products (or so some perlmonger things) .

      Seeing as the complaints I was referring to are coming from Perl people, performance and lack of shrinkwrap products are probably of limited concern to them. They are valid when comparing to C/C++ and others though, so thanks for mentioning it. As for flaky implmentation, that isn't really the language specification, but does affect overall impression and, as such, is again a valid point.

      why do you throw out disclaimers? huh Anynymous Coward?

      Obviously you have a problem with the tone of my post. It was written rather hastily and I didn't carefully analyze how every sentence contributed to the overall impression. My apologies for this, but please try and stick to discussing the main points I brought up if at allpossible, thanks.

      As for the disclaimers, I was trying to avoid projecting a bias as to which language I think is better and trying to get others to set aside their biases. I commonly use Perl, Java, Ruby, Python, C, and C++ interchangeably, and enjoy programming in all of them. What I'm trying to do here is get a feel for people's major complaints about Java, as I see a lot of complaints about it on this site.

      Thank you, and sorry for any misunderstanding :)

Re: How would you fix Java?
by perrin (Chancellor) on Apr 21, 2003 at 19:40 UTC
    I seem to be unable to read a thread anywhere on this site (let alone the poetry section) without someone implying something negative about Java's quality. Why is this?

    Many of the threads about Java on this site are started with trollish negative statements about Perl in comparison to Java (often quotes from managers or co-workers). These are bound to draw angry responses. However, if you look at threads along the lines of "what other languages should I learn?" you will find many people recommending Java.

    I think most serious programmers should learn Java these days, because there are a lot of interesting ideas being published in articles and books about Java. For example, Martin Fowler's book Patterns of Enterprise Application Architecture has examples in Java.

Re: How would you fix Java?
by tall_man (Parson) on Apr 21, 2003 at 15:15 UTC
    Object-oriented programming requires good generic containers for objects. But strong compile-time type checking destroys the ability to create such containers. The work-around in C++ is templates, which are ugly but safe. The work-around in Java is unsafe casting using type Object, which eliminates the compile-time checking it was supposed to support.

    "You could define your own type-safe wrapper around the container" they say. Right, using cut-and-paste programming. IMHO, until Java gets true support for generic programming it is inferior to both C++ and perl..

      Object-oriented programming requires good generic containers for objects. But strong compile-time type checking destroys the ability to create such containers

      I disagree. While many popular static type checking languages have poor mechanisms for handling generic containers, some have rather nice ones.

      For example I find Eiffel's generic classes elegant and powerful.

      It also looks likely that Java will be getting generic types in the nearish future - although I've not spent the time to see whether its a nice implementation (although pretty much anything would be better than the current ghastly casting nonsense).

      This isn't to say Java is one of my favourite languages (its not my most hated either :-)

      Good point. The best explanation of this I've found is here.

Re: How would you fix Java?
by adrianh (Chancellor) on Apr 22, 2003 at 22:10 UTC

    As others have mentioned you can't really "fix" Java. Many "fixes" would involve changing the language so fundamentally it would no longer be Java. You can't "fix" Java if you prefer Perl in the same way you can't "fix" C++ if you prefer Common Lisp. You pick the language that best suits your needs and experience.

    That said... if I could change Java I'd want :-)

    • Better portability. Yes portability. I still have fewer cross-platform issues with Perl than I do with Java (to be fair Java is a lot better than it was, and improving all the time.)
    • Allow multiple inheritance of implementation. There are problems with some implementations of multiple inheritance. I don't think Java's solution (only allow multiple inheritance of interface) is the right one. This won't change since it's a philosophical difference.
    • Allow runtime access to the compiler. I miss eval. This won't change.
    • Allow overloading of operators. I find this clarifies more than it obscures. Other people disagree. This won't change.
    • Addition of closures. Anonymous inner classes are of some use, but I miss the power and conciseness of proper closures.
    • Addition of generic classes. The Java Collections framework can be a major pain. Any language that forces me to use a cast to tell it what kind of object is being referenced is broken. Fortunately generic types are being added to the next version of Java.
    • Addition of data tainting to the core language. Perl's "don't trust the data" security model is more useful to me than Java's "don't trust the code" model the vast majority of the time.
    • Remove primitive types. The whole boolean/Boolean thing is a confusing mess and the language would be better without them. In my opinion of course :-) This won't change.
    • Remove compile time checking of exceptions. I find this gets in the way more than it helps. You pay too heavily if you change the exceptions a class throws. Other people disagree. This won't change.
    • Some sort of CPAN. 'Nuff said :-)
    • A less verbose and more flexible syntax. Java borrows to much from C++ for my tastes. I find it unnecessarily verbose to write. Things that take a few lines of Lisp or Perl take many more lines of Java. Not fixable without creating a new language.
    • "Standard" APIs that stay the same for more than a point release. You have to spend so much time figuring out what's core and what's not core for what version of Java, and which minor non-upward compatible API change needs to be dealt with.
Re: How would you fix Java?
by TVSET (Chaplain) on Apr 21, 2003 at 15:59 UTC
    Once, there was a link from Slashdot to a memo from Sun describing why they don't want to use Java. :) Here is a link. Sounds interesting, doesn't it? :)

    Leonid Mamtchenkov

Re: How would you fix Java?
by cciulla (Friar) on Apr 21, 2003 at 23:26 UTC

    FWIW, for the past three or so years, all of my salary-based programming has been Java. All my productivity-based programming is perl. :)

    Here's how I would improve Java...

    • Get rid of primatives or ease the conversion to/from wrapper objects. Naw, just get rid of primatives.
    • Operator overloading
    • Wrapper objects should be mutable

    WARNING

    The following are semi-lighthearted changes I'd make if I ran the zoo:

    • Embed electrial correction devices into all "hammer-weilding" developers. You know, the ones that think, "my language is the One True Language -- other so-called languages are beneath my contempt," and remove their capacity to spread their genes into future generations.
    • Brand, scar, or otherwise mutiliate all "paper" certified "developers," and remove their capacity to spread their genes into future generations.
    • Outlaw the use of integrated development environments for anyone with less than five years of experience in a given language...
      to make someone program in Smalltalk for 5 years without an IDE.
Re: How would you fix Java?
by cciulla (Friar) on Apr 29, 2003 at 12:14 UTC

    FWIW, for those monks interested, there is a CPAN-esque Java site in the works (and will be done RSN (real soon now)) at www.cjan.org. Although it's currently vapor, it should be interesting to see how it turns out.

      I recall I've seen this site in in the works state about year ago. It definetely looks vapor. Good luck to them anyway.

      --
      Ilya Martynov, ilya@iponweb.net
      CTO IPonWEB (UK) Ltd
      Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
      Personal website - http://martynov.org

Why would I fix Java?
by hding (Chaplain) on Apr 21, 2003 at 15:38 UTC
    This would be the first question to answer, I would think. One would have to suppose some other language X where each of language X and Java does some things better and some worse, and moreover one would have to think that it would be easier and more useful to overcome Java's shortcomings than language X's. I think that is where people start to doubt; it doesn't seem to many that Java provides enough advantages over (insert whatever here) to make it worth fixing.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://251948]
Approved by Louis_Wu
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (1)
As of 2024-07-22 04:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?
    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.