Loading ...
Sorry, an error occurred while loading the content.

Re: Java [was Re: [hackers-il] In need of Guidens]

Expand Messages
  • Shlomi Fish
    First of all Tzahi - a general note. Your message is very hard to read. You have many grammatical errors, wrong capitalization, improper spelling, missing or
    Message 1 of 44 , Dec 17, 2004
      First of all Tzahi - a general note. Your message is very hard to read. You
      have many grammatical errors, wrong capitalization, improper spelling, missing
      or extra apostrophes, etc. Furthremore, your mailer places the last word of a
      line in a separate line, which is confusing to the eye.

      Please either configure your mailer (Lookout, IIRC) to behave, or use a
      different mailer for correspondence with Hackers-IL. You can get an E-mail
      account at Yahoo/Hotmail/etc. and I can give you a gmail invite.

      On Monday 13 December 2004 02:40, Tzahi Fadida wrote:
      > > Hmmm... well I know both Java and Perl and I love Perl so
      > > much more. Java is
      > > something I can tolerate, but not really love. ("OutputStream = new
      > > FileOutputStream(...)" anyone? "public static void main()")
      > its no like its so simple in other lang including perl.

      Yes, it is. I don't need to define a main function or an Applet/Application
      class in Perl just for getting the program to do something. And for the
      simple task of writing to a file, I can use open/print/close. Much more
      succint than Java. Much more cognitively sound. Much more environmentally

      Larry Wall said that in Perl easy tasks should be easy, and hard tasks
      possible. Writing System.out.println("Hello World") to print a damn string to
      stdout, is not what I call a sane thing to do. Neither is calling
      CreateFile() with 7 arguments just to open a file (well it's Win32 API and
      not Java, but you get the idea).

      > The shortcuts only
      > works
      > because you say in advance what output device you mean.
      > I.e. declare a short variable and find out they are all the same on that
      > level.
      > Good programming, especially in real world programs which will require
      > future
      > maitainance should include meaningful variables and not "_" or all kinds of
      > weird
      > mumbo jumbo which requires hrs to decipher.

      1. I completely lost you here.

      2. Short variables sometimes make sense. Often I use $i or $j as indices
      instead of $index_to_array_element. That's because everyone knowledgable
      enough knows that $i can serve as an index. Shorter variable names make the
      code flow more and less time to read.

      > > > I personally after many many years with different languages
      > > > sees
      > > > java as a blessing. I can tell you that in IE faculty where complex
      > > > projects that runs over many
      > > > teams and years could never hold without java's design, debugs, and
      > > > countless
      > > > other factors.
      > >
      > > People have run complex projects that run over many teams and
      > > years a long
      > > time before Java, and are still running them now in different
      > > langauges. Why
      > > is Java necessary?
      > And you know what, maybe they won't require an army of men if they'll use
      > the advancements in Software Engineering.

      "Army of Men"? Beg your pardon? But some complex projects that ran over many
      teams and years did not require an army of men. Furthermore, an army of men
      may not necessarily be an advantage, unless you forgot Brooks' Law:


      > I mean, come on, C is long due an
      > overhaul.

      Why? What's wrong with C? It is perfectly acceptable as a language for some

      > An you know what, many programmers and engineers understand that and make
      > use
      > of it. The only reason to use a low level lang like C is for performance
      > which nowadays
      > is not very important for most applications besides OS and related progs.

      There are other reasons to use C besides performance:

      1. Portability - ANSI C is portable for every architecture there's a gcc
      backend or any other compiler for. With Java you rely on Sun's whims.

      2. FOSSness - gcc is a full-featured and robust compiler for ANSI C, and it's
      open-source. Java has a very problematic license. It's not distributed as
      part of most Linux distributions due to this.

      3. Low-levelness - you cannot effectively duplicate a struct containing other
      structs in Java (or Perl for that matter) as you can in C. (due to the fact
      that in Java every struct is a refernence) You cannot work with interrupts,
      DMAs, and other hardware elements. It's much harder to write your own custom
      fine-grained memory-management routines.

      Believe it or not, but many problem domains call for ANSI C. I myself have
      written a program in ANSI C, which when trying to think how I would implement
      it in Java, I encountered a lot of techniques I used that were almost
      impossible to translate effectively.

      4. Self-contained-ness : you can compile a C library and distribute it as is.
      With Java/Perl/whatever you need a huge run-time as well.

      5. Making use of UNIXisms: there's no fork() in Java, and not many other UNIX
      system calls. You need to create bindings for them (which require JNI) or
      work around them. Perl, BTW, usually doesn't have this limitation.

      6. Integrability - A C library can be used by Perl code, Python code, Tcl
      code, Ruby code, to a lesser extent Java code, etc. Java code is mostly
      usable only for Java.

      > Perl is not a team language and you know it. There is no need to argue
      > about it since
      > you know the answer.

      I realize why some people can think that Perl is not a team language, but I
      don't agree with it. So let's argue about it.

      You have made a dogmatic claim that "Perl is not a team language". Care to
      explain why? I, for once, can give some counter-evidence to this
      generalization. I know of some software shops in which teams of programmers
      successfully work on the same Perl code. And that's without taking into
      account all the Perl projects and CPAN modules, for which a
      geographically-dispersed team worked and contributed to the same code.
      Arguably, working on the same codebase with a geographically-dispersed team
      is harder than with a team in which everyone are located in one place.

      > There is no need to be nostalgic.

      Nostalgic? I wrote in Perl a few days ago.

      > > > They are tools to do my job or
      > > > my algorithms,
      > > > etc... for example, Its been years since I programmed in C
      > >
      > > and now I am
      > >
      > > > about to do a major
      > > > coding project for my thesis inside postgreSQL. I would
      > >
      > > have been glad if
      > >
      > > > it was written
      > > > in java because of the debugging and the ease of coding but
      > >
      > > obviously if it
      > >
      > > > was written
      > > > in java you would get poor performance. As I always say,
      > >
      > > use the best tool
      > >
      > > > for the job.
      > >
      > > For once, the development of
      > > Ingress->Postgres->Postgres95->PostgreSQL was
      > > started a long time before Java. Regardless, the performance
      > > loss with Java
      > > in this case would have probably been incredibly significant.
      > > Plus, I believe
      > > I/O, multi-processing/multi-tasking and other UNIXisms is
      > > much better done in
      > > C.
      > No argument there. C was designed with an OS in mind.
      > Performance is mainly the reason to use C.

      Like I said it's not.

      [Other ramblings about performance snipped...]

      > > > As for java for jobs, it's the same. If an organisation
      > >
      > > tells you "we
      > >
      > > > use java, do you know java?". I won't tell them, "java is bad, lets
      > > > rewrite your software" because they would just not hier me.
      > >
      > > Neither would I. But many times people use Java in the
      > > industry for things
      > > that Perl/Python/etc. would have been much more adequate. Or
      > > that are better
      > > done in C. Java is the new hype language like C++ was a few
      > > years ago, and
      > > that is what Paul Graham points out to, among else.
      > No complaints here. Perl and python have many uses like triger handling in
      > dbs,
      > scripts, small programs, prototyping, etc...

      They have many other uses besides that. By all means they can be used for
      serious large scale applications, often replacing things that are now written
      in C, C++ or Java.

      > > > > <<<
      > > > > People are forced to use it. A lot of the people I know
      > >
      > > using Java
      > >
      > > > > are using it because they feel they have to. Either it's
      > >
      > > something
      > >
      > > > > they felt they had
      > > > > to do to get funded, or something they thought customers
      > > > > would want, or
      > > > > something they were told to do by management. These are smart
      > > > > people; if the
      > > > > technology was good, they'd have used it voluntarily.
      > > > >
      > > > > > C/C++ are important too because they are also used
      > > > >
      > > > > intesively in the
      > > > >
      > > > > > industry especially when performance is important.
      > > > >
      > > > > That's not why C/C++ are important. ANSI C is important
      > >
      > > because it's
      > >
      > > > > a low-level language that works close to the machine level.
      > > > > Understanding it is
      > > > > important to understand how a computer works. I was also told
      > > > > C programmers
      > > > > who become Assembly programmers are better Assembly
      > > > > programmers than people
      > > > > who started with Assembly.
      > > >
      > > > Important to learn not important as in performance which
      > >
      > > IIRC was the
      > >
      > > > whole question. Obviously C was written for Oss and being close to
      > > > Assembly without the problems
      > > > of assembly.
      > >
      > > Sometimes C makes more sense than Java even if performance is
      > > not so relevant.
      > Yes, I agree. There are other factors that sometimes should be considered
      > like
      > portability to new hardwares, time to market on new microcontrolers or cpus
      > like the
      > arm, dragonball s ,etc..

      These are not the only factors - see above.

      > But know something else, C and also java are not defined well. That's
      > something not
      > many undestands. I.E. different compilers gives different results.

      Care to explain what you mean exactly and give examples? I realize about
      byte-sex (little-endian vs. big-endian), field padding, and other hardware
      differences. Furthermore, if I only use gcc (just with different back-ends),
      will it also hold?

      > Militairy grade
      > programms uses languages which are well defined and will always give the
      > same
      > results on different compilers.
      > > > > As for C++, well, it supports Object-Oriented Programming
      > >
      > > roughly as
      > >
      > > > > much as COBOL supports Functional Programming. It used to
      > >
      > > be hyped
      > >
      > > > > as Java is today.
      > > > > I tend to dislike it for most purposes, and prefer either
      > > > > ANSI C or Perl.
      > > >
      > > > I know C++, COBOL, etc... and I can tell you that java is
      > >
      > > superior to
      > >
      > > > C++ design wise. I was trying to debug and add an algorithm to a
      > > > fairly C++ standard-everyday-program
      > > > just a few months ago and it took me too much time to
      > >
      > > understand what was
      > >
      > > > going on there.
      > > > Java is higher level then C and C++ and lacks many problems
      > >
      > > with both,
      > >
      > > > of course at the expense of performance and features.
      > >
      > > Trying to understand complex C++ programs is a nightmare. I
      > > recall having a
      > > lot of fun trying to understand what was going on in OpenJade
      > > (http://openjade.sourceforge.net/). My main problem was that
      > > I did not know
      > > where each function was defined or what it did. Or in which
      > > class a variable
      > > was defined in.
      > Yes, C++ is a nightmare since it has multiple inheritance and many things
      > which
      > are half done.

      Actually, the reasons why I found C++ to be problematic did not involve
      multiple inheritance.

      > You CANNOT take a low level lang like C and add to it OO and
      > tell
      > everyone to start write user programs.

      Well, ANSI C by itself supports OO pretty well. (look at Gtk+, void
      *-polymorphism, etc.) And as Joel Spolsky identified in:


      OO is not a big productivity-enhancement as managed programming and garbage
      collection. (i.e: doing $a = $b . $c to concatenate two strings).

      I tend to agree with him, because when writing C, I spend a lot of time on
      malloc()/free() and other stuff like that.

      > JAVA fixed that by removing the
      > usuall
      > fallacies like multiple inheritance and range checking and garbage
      > collection and numerous
      > others.


      > I don't know if its true but I was once told java was first
      > designed to be put in
      > microwaves.

      Microwave ovens?

      > > > > > Object Oriented major contribution is to help you write
      > > > >
      > > > > large programs,
      > > > >
      > > > > > however,
      > > > > > for smaller programs I suggest learning perl and possibly
      > > > >
      > > > > python but I
      > > > >
      > > > > > cannot recommend
      > > > > > it since I did not go into it much but a lot of people
      > >
      > > recommend
      > >
      > > > > > it.
      > > > >
      > > > > I totally disagree that Perl, Python and friends are
      > >
      > > suitable only
      > >
      > > > > for smaller programs. In fact, they can easily scale to large
      > > > > codebases. Much better than
      > > > > Java or C++.
      > > >
      > > > Just because you can do any program with most languages its not a
      > > > reason to do it.
      > >
      > > Right. However, you can write large-scale programs in Perl,
      > > Python anbd
      > > friends, and often you should write them in these languages.
      > Not in perl that's for sure. Readability, Writability, etc... are concepts
      > learned in blood
      > like they say in the army. Why take a risk.

      "You cannot write large-scale programs in Perl". Yet, another statement that
      many people feel is true, but I believe the opposite.

      Let me give some counter-evidence:

      1. The Mail::Box module alone consists of 22,093 Perl Lines of Code (according
      to SLOCCount by David A. Wheeler). That's certainly a lot. Furthermore it
      depends on several other Perl modules (which I did not take into account) and
      has some other optional dependendencies. Together, it's probably about
      50K-100K if not more.

      2. Bricolage alone consists of 61,673 Lines of Code. And it is dependant on 44
      required and 17 optional CPAN modules. Together, it's well above 100,000
      Lines of code, probably even above 200,000 Lines of code.

      3. Some Perl modules such as Maypole or XUL::Node require a lot of Perl
      modules. If we make a LOC count of them along with all of their dependencies,
      it will be a substantial amount of LOCs.

      4. The U.S. Federal District Court calendaring system is a 1.6 million line
      perl5 package. This is pretty much a large-scale program by any means:


      5. Amazon.com has a ~100 million LOCs codebase, a lot of it in Perl:


      Now if this isn't large-scale, I don't know what is.

      > > > suitability is a concept that must be learnt as I am sure you did
      > > > shlomi.
      > >
      > > Right.
      > >
      > > > I bet you won't suggest to me to write the kernel using perl or
      > > > python. C is much better. although I bet, with some tweaking and a
      > > > suitable compiler both can do it.
      > >
      > > Well, Perl does not have any built-in way to access hardware,
      > > and cannot deal
      > > with hardware within the time/memory constraints that a
      > > kernel requires. If
      > > you are goingn to write the kernel in Perl, you'll still need
      > > a lot of ANSI C
      > > glue.
      > Probably right, but I don't think its the main reason to dismiss it since
      > you could in
      > theory make it to do this things.

      In theory yes. However, the kernel problem domain maps much better to C than
      to Perl or Python. As is the case for a different program I wrote.

      > > > > > Programming isn't enough though, I suggest learning xml,
      > > > >
      > > > > xpath, xquery, SQL
      > > > >
      > > > > > (very important).
      > > > > > Regular expressions, etc... I.e. complementary material
      > > > >
      > > > > that you can't do
      > > > >
      > > > > > without.
      > > > >
      > > > > You are right about SQL, regexps and XML. There are many other
      > > > > technologies that are important.
      > > > >
      > > > > > If you really want to get into the theoretical/historical
      > > > >
      > > > > programming you
      > > > >
      > > > > > might want to glimpse:
      > > > > > "Concepts of Programming Languages", SEBESTA.
      > > > >
      > > > > All in all, your message smells of "money-oriented learning".
      > > > > I.e: you should
      > > > > learn what's hyped in the industry.
      > > >
      > > > Yes, pragmatism in today's market will help you. When I do
      > >
      > > community
      > >
      > > > coding, only then I cosiders other factors and yes I sometimes even
      > > > code with perl
      > >
      > > Pragmatism may help you. However, you may also eventually get
      > > to learn the
      > > fine details of hyped technologies that will be replaced by other
      > > technologies in a few years, and you'll then have to re-learn
      > > everything you
      > > learned now. I'd rather avoid it. If I get a job in which I
      > > have to write
      > > something in a certain technology I'll learn it for the job.
      > > Else, I'll just
      > > use what I like to use to get my job done as efficiently as
      > > possible, and
      > > learn what interests me.
      > >
      > > Up to now, I found out that Java was hardly ever the right
      > > tool for the job
      > > for me. Many workplaces like it, but I'd rather not have
      > > "3/5/10 years of
      > > Java Experience" now, if it means that I'll have to spend the
      > > next 3/5/10
      > > years programming in Java.
      > Well, I appreciate the easy life with java. Using C all the time, is like
      > IIRC the
      > philosophers guild when they built big blue(I think it was called)? in
      > douglas adams book.

      It was called "Deep Thought". "Big Blue" is a nickname for IBM that predates
      Douglas Adams' Books. The reason you are probably confused is that initially
      IBM named their chess-playing computer "Deep Thought" after the computer in
      "The Hitchhiker's Guide to the Galaxy". Then they renamed it to "Deep Blue".

      > What will they do if there was a computer who could do what they do in a
      > fraction of
      > the time. So they decided to destroy it. :)

      That's not how I recall the "Hitchhiker's Guide to the Galaxy". And I don't
      understand the analogy, anyhow.


      Shlomi Fish

      Shlomi Fish shlomif@...
      Homepage: http://www.shlomifish.org/

      Knuth is not God! It took him two days to build the Roman Empire.
    • guy keren
      ... i only had the pleasure of programming in java for about half a year, but i can say the following: 1. it is indeed faster to develope working code in java
      Message 44 of 44 , Dec 25, 2004
        On Fri, 24 Dec 2004, Nadav Har'El wrote:

        > Java, on the other hand, usually fits look a boot to the hand :) I mean,
        > many of its supposed reasons for being used are mere illusions. Java isn't
        > much more portable than other languages, it doesn't really make code easier to
        > reuse (than in other modern languages), and worse of all (and this, in my
        > opinion, is the single thing that makes Java worse than C++) - it too often
        > generates codethat is completely impossible to use, let alone reuse,
        > because of an uncontrollable memory appetite.

        i only had the pleasure of programming in java for about half a year, but
        i can say the following:

        1. it is indeed faster to develope working code in java then in C or C++.
        2. due to the nature of the language (mostly the dynamic class-loading
        eature), it has errupted an open-source environment that did things i
        did not saw done with C or C++. some of these things are now being
        ported back to C and C++. the very fact that the open-source community
        around java developed things that weren't done (or were done not as
        good as) for C/C++, suggests that there is someting to learn from java.

        true, for someone like me, who'se used to having control on the
        environment, it is hard to let go and give java the power - that's why i
        originally ruled out any job offerings that had to do with java. however,
        after the fact, i don't think it was a mistake using java.

        do note that not everyone developes CPU-intensive applications. and in
        those situations, it's easier to get the coding done in java, then in C++.

        and i'm not talking about the scripted languages here - as much as i find
        it even more fun to program with them - i don't want to touch large
        code-bases created with them. and i'll ignore any attempts to argue about
        this point with certain people....

        > Moreover, Java is a very big language, perhaps even bigger than Perl (if you
        > don't use any CPAN stuff), so most people I know cannot program Java on paper,
        > and need a special editor (namely "eclipse") to help them edit. This is what
        > I think Shlomi referred to in his "Hello world" complaint.

        judging a language by 'hello world' is naive. it shows how people tend to
        do all of their "evaluations" of new tools - they try to write something
        trivial, find the tool too complicated for something trivial, and conclude
        its no good.

        by the way, i looked at eclipse and at IntelliJ (a commercial product
        that's quite stronger then eclipse) - and i resorted to coding in Java
        with vi, and compiling the code with the command-line ant interface.
        indeed, i needed to use an html reference in order to work with various
        classes - but the language itself is not more complex then C++ - it's
        the standard library that is very large. you'll have the same problem if
        you work in C++ - for collections you need to remember STL, the same for
        strings, for files you need the standard I/O, for threads you need a
        3rd-party library, and so on. the fact that this is not considered part of
        the language does not mean that the actualy material you need in order to
        write _real_ code, isn't as large as in java. it just _looks_ smaller.

        and i'll admit this - it was quite a relief not to need to use valgrind or
        a similar tool in order to find where all my memory leaks to, or how i
        managed to smear a pointer. it wasn't 100% the case, ofcorse - you can
        still have segmentation faults in java (i saw one such nasty thing, which
        was due to a bug in the java virtual machine implemnentation) - but still
        a relief on day-to-day programming.


        "For world domination - press 1,
        or dial 0, and please hold, for the creator." -- nob o. dy
      Your message has been successfully submitted and would be delivered to recipients shortly.