Slashdot Mirror


The Next Path for Joy

newdaemon writes "Fortune has a candid interview with Bill Joy about what he plans to do after leaving Sun and his opinions on many other topics, including his strong dislike of the C programming language and how the internet could evolve to take care of the problem of spam and viruses."

361 comments

  1. Uhhh by cscx · · Score: 0, Troll

    Writing everything in Java [a programming language created by Sun] will help, because stuff written in antique programming languages like C [a widely used language created by Bell Labs in the early 1970s] is full of holes. Those languages weren't designed for writing distributed programs to be used over a network. Yet that's what Microsoft still uses. But even Java doesn't prevent people from making stupid mistakes.

    Yeah, whatever...>eyeroll

    1. Re:Uhhh by lokedhs · · Score: 4, Interesting
      Except for the fact that he is correct of course.

      Java is only one of the languages that completely prevent stuff like buffer overrun exploits etc. In fact, pretty much every single language except C and C++ do.

    2. Re:Uhhh by cscx · · Score: 1, Troll

      Maybe he should re-write the Solaris kernel in Jav--- oh wait you can't.

      Java doesn't have the speed to do many things efficiently.

    3. Re:Uhhh by Anonymous Coward · · Score: 0

      yeah, and I suppose the fact that it takes 2 seconds to run "Hello World!" in Java is another example of Java's superiority.

    4. Re:Uhhh by evilviper · · Score: 5, Insightful

      He is correct, but it's really not all the feasable in the real world. For all the people that say programmers should be grossly ineffecient, and let the newer processors take up the slack, there are thousands of companies that can't get their important programs to run fast enough, even after spending millions on computer hardware... Making everything in Java is only going to make the situation a couple orders of magnitude worse.

      If Sun, or someone else, would come along and modify C slightly by removing unsafe functions, and providing alternatives, you could have the best of both, while not having to completely rewrite all the old code.

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    5. Re:Uhhh by WolfWithoutAClause · · Score: 4, Interesting
      Except that's wrong. Running Hello World involves booting up what is, in effect, an entire operating system (the Java VM, with virtual memory, threading, everything, the works).

      Ok, here's an experiment:

      a) run Hello World in Java

      b) run Hello World in C (including booting up Linux)

      Which one is faster? :-)

      --

      -WolfWithoutAClause

      "Gravity is only a theory, not a fact!"
    6. Re:Uhhh by Anonymous Coward · · Score: 0

      Your analogy is flawed.

      My operating system is already booted up. It takes a fraction of a second to execute Hello World in C in my already booted up system.

      On the same machine and OS, it takes 2+ seconds to run the Java program.

      Its not my fault that Java has extra crap it needs to run.

    7. Re:Uhhh by reallocate · · Score: 2, Insightful

      But, then, the Solaris kernel is not a distributed program to be run over networks.

      As long as a language is "faster" than the network, it'll be fast enough for that kind of use. E.g., there's no particular reason to write a browser in assembly because it spends almost all of its time waiting for the netowrk to do something.

      --
      -- Slashdot: When Public Access TV Says "No"
    8. Re:Uhhh by Anonymous Coward · · Score: 0

      Writing everything in Java [a programming language created by Sun] will help, because stuff written in antique programming languages like C [a widely used language created by Bell Labs in the early 1970s] is full of holes. Those languages weren't designed for writing distributed programs to be used over a network. Yet that's what Microsoft still uses.

      Is Solaris written in Java ?

    9. Re:Uhhh by ChrisRijk · · Score: 1

      Except that's wrong. Running Hello World involves booting up what is, in effect, an entire operating system (the Java VM, with virtual memory, threading, everything, the works).

      Not true when you use VM sharing.

      For more info, see Sun's project Barcelona

    10. Re:Uhhh by WolfWithoutAClause · · Score: 1

      Actually, strangely enough, the latest versions of Java tend to roughly the same thing- they load the Java VM once when you run the first program, and then the next Java program loads and runs quickly.

      --

      -WolfWithoutAClause

      "Gravity is only a theory, not a fact!"
    11. Re:Uhhh by Beryllium+Sphere(tm) · · Score: 4, Insightful

      But I'd feel more respect for his comments if he hadn't said

      >so many companies use Microsoft Outlook for reading e-mail. Again, because that program is written in C, it's quite easy to design a virus to go through your e-mail address book and broadcast spam to all the people you know. As soon as your company starts using Outlook, you can see

      Outlook's scriptability has nothing to do with its being written in C++.

      Outlook's UI for attachment handling has nothing to do with its being written in C++.

      Outlook's historical willingness to do dangerous things driven by HTML code in the preview pane has nothing to so with its being written in C++.

      The problems Joy mentioned, of email forwarding itself to everyone in the address book, are not accidental buffer overflows. They're the malicious use of features intentionally designed into the program.

    12. Re:Uhhh by Waffle+Iron · · Score: 2, Interesting
      Java doesn't have the speed to do many things efficiently.

      Optimization is always the last thing that you should do on a project. This means that implementing the software in C/C++ should be the last resort. Most of the time, most of your software will run just fine in a safer, easier to use language. When you run into performance issues, that's when you port pieces of your program to C. Unfortunately, a lot of people just assume that they should always start coding in C or C++ right off the bat.

      I personally don't like Java very much. It's bloated for what it does, static typing is a PITA, it doesn't play well with other languages, and it's heavily biased towards the OO paradigm, ignoring other highly useful programming approaches. (Many languages let you mix in bits from various programming styles.)

      What I prefer to do instead is use a very flexible language like Python, then write C extensions for the performance critical parts if/when they are needed. The extension C code tends to be simple straight-line logic that is harder for bugs to hide in. This approach provides a "dynamic range" of performance vs. ease of use that is well well beyond that offered by pure Java or C.

    13. Re:Uhhh by cscx · · Score: 1

      Python prevents buffer overrun exploits, too. Let's start writing everything in Python now that we're at it...

    14. Re:Uhhh by Anonymous Coward · · Score: 0

      THE N3XT P4TH F0R WH0 GIVES A SHIT

    15. Re:Uhhh by CosmeticLobotamy · · Score: 1

      Writing everything in Java [a programming language created by Sun] will help, because stuff written in antique programming languages like C [a widely used language created by Bell Labs in the early 1970s] is full of holes. Those languages weren't designed for writing distributed programs to be used over a network. Yet that's what Microsoft still uses. But even Java doesn't prevent people from making stupid mistakes.

      Microsoft has to use C. It would be pretty tricky to write an OS without pointers and that runs in a virtual machine. And thank God they don't use Java for their apps. I have to use a crappy computer most of the time, and Office takes a week to start already. Maybe it's possible to make the performance hit negligable, but I don't think Microsoft has the competence to make that happen.

    16. Re:Uhhh by curtoid · · Score: 1

      Java is only one of the languages that completely prevent stuff like buffer overrun exploits etc. In fact, pretty much every single language except C and C++ do.

      He is only correct after the JVM is perfect (or the OS for other langs).

      There are still holes. But they will be platform - and version - specific.

      As long as there is new hardware being developed, there will still be C and ASM and there's no way around it.

    17. Re:Uhhh by Corporal+Dan · · Score: 1
      If Sun, or someone else, would come along and modify C slightly by removing unsafe functions, and providing alternatives, you could have the best of both, while not having to completely rewrite all the old code.

      Cyclone - A Safe Dialect of C
      "Cyclone is a programming language based on C that is safe, meaning that it rules out programs that have buffer overflows, dangling pointers, format string attacks, and so on. High-level, type-safe languages, such as Java, Scheme, or ML also provide safety, but they don't give the same control over data representations and memory management that C does (witness the fact that the run-time systems for these languages are usually written in C.) Furthermore, porting legacy C code to these languages or interfacing with legacy C libraries is a difficult and error-prone process. The goal of Cyclone is to give programmers the same low-level control and performance of C without sacrificing safety, and to make it easy to port or interface with legacy C code."
    18. Re:Uhhh by cscx · · Score: 1

      Not just that but part of the OS kernel is written in assembly.

    19. Re:Uhhh by Rombuu · · Score: 1

      Making everything in Java is only going to make the situation a couple orders of magnitude worse.

      Are you really suggesting java is 100x slower than C/C++. Or do you just not know what "a couple orders of magnitude" is?

      --

      DrLunch.com The site that tells you what's for lunch!
    20. Re:Uhhh by georgeb · · Score: 1

      http://www.trl.ibm.com/projects/security/ssp/

      "GCC extension for protecting applications from stack-smashing attacks"

      Btw, this is not a case of 'unsafe' functions at all.

      May I also point that programming mistakes become vulnerabilities in most of the situations only because of platform limitation. Even for 'insecure' platforms (like x86 :D), selinux and grsecurity implement some nice protection mechanisms.

      Programming errors are supposed to make a program crash. The system should make sure this happens.

    21. Re:Uhhh by koali · · Score: 1
      alex@wintermute alex $ time ./a.out
      hello, world

      real 0m0.001s
      user 0m0.000s
      sys 0m0.001s
      alex@wintermute alex $ time java hello
      Hello, world

      real 0m0.183s
      user 0m0.117s
      sys 0m0.020s

      Sure, if I want to write hello world, I'll write it in C. No, hell, I won't. I can sacrifice 0.2 seconds.

      And the 0.2 seconds become more and more insignificant in more interesting programs...

    22. Re:Uhhh by arkanes · · Score: 1
      Depends on what you're doing, but Java most certainly can be 100x times slower than C. When Java was first introduced, 50-100x slower than C code was in fact the rule of thumb.

      It's alot better now, of course, and it's hard to get clear performance profiles when you include semi-random things like garbage collection overhead, but in terms of "resources consumed for execution of X algorithm", Java can easily meet that 2 orders of magnitude figure. At least 1.

    23. Re:Uhhh by s4ltyd0g · · Score: 1

      So what language is Java written in anyways?

    24. Re:Uhhh by Anonymous Coward · · Score: 0

      You would only have to sacrafice 0.15 seconds if you did not capitalize the h in the Java Hello world code.

    25. Re:Uhhh by Anonymous Coward · · Score: 1, Informative

      Maybe he means that if Outlook were written in Java, it would "probably" run in some security model sandbox that would for instance limit its access to the browser cache, which sobig scans for adresses.

    26. Re:Uhhh by nukeindia.com · · Score: 1
      Java is only one of the languages that completely prevent stuff like buffer overrun exploits etc. In fact, pretty much every single language except C and C++ do.


      Java is only one of the languages where the VM, the run time libraries even the compiler has been written in C or C++ (unless it was all written in assembly). Dropping down to the core level languages shifts more and more responsibilites (like error checking and array bound checking) to the coder from the compiler. That's why all these different programming langagues are here for. Use the correct one in the correct place.


    27. Re:Uhhh by GnuVince · · Score: 1
      Myths stick for longer than facts. For example, are Lisp and Smalltalk slow? The answer is now, in fact some implementation of Lisp can beat C programs in speed contests for certain tasks. But people still like to believe that we live in the 60's when Lisp was only interpreted and was really slow. The same goes for Smalltalk.

      Java is not very slow anymore. Typically a Java application is 3-4x times slower than a C application, which is perfectly accepteable considering all the safety stuff it gives you that C forces you to do.

    28. Re:Uhhh by Dorothy+86 · · Score: 1

      Did anyone else read "Billy Joel" instead of Bill Joy?

    29. Re:Uhhh by lokedhs · · Score: 1
      ale$ time java Foo
      hello world

      real 0m0.088s
      user 0m0.080s
      sys 0m0.010s
      ale$ uname -a
      Linux ale 2.4.20-20.9 #1 Mon Aug 18 11:27:43 EDT 2003 i686 athlon i386 GNU/Linuxale$
      Maybe it's time for you to check your system if it takes 2 seconds to run it.
    30. Re:Uhhh by HFXPro · · Score: 1

      Your complaining about Java being bad because it has static typing? What? Aren't you saying you like safety. Static typing helps to provide safety. It also allows for faster running code and can be just as flexiable as the dynamically typed languages. Go look at SML, Caml, or Haskell for an example.

      --
      Reserved Word.
    31. Re:Uhhh by lokedhs · · Score: 1

      Everything? No, but a lot probably can. Personally I don't like python one bit, but I'd feel much safer if most of my day-to-day apps were written in it.

    32. Re:Uhhh by TheSunborn · · Score: 1

      The key here is for certain task. What do we do with all the other tasks we need to solve?

    33. Re:Uhhh by Waffle+Iron · · Score: 1
      Static typing helps to provide safety.

      How? Dynamically typed languages know the types at runtime. They're not going to core dump just because you feed a string to a function that expects an integer. It will most likely raise an exception that you cleanly handle at an appropriate spot. I find that 99% of the time, this happens the first time you try to run the code; often sooner than your compiler would have finished rebuilding a static implementation. Look at the stack trace, go to that line of code, fix it and move on. No need to spend hours pondering the cryptic type errors that the C++ compiler spits out.

      At any rate, a static language doesn't automatically check that an integer parameter's actual runtime value is within the valid range for the function, so it's not really providing that much safety.

      It also allows for faster running code and can be just as flexiable as the dynamically typed languages. Go look at SML, Caml, or Haskell for an example.

      There's some truth in that. However, very few people relate to writing in the highly recursive functional style that these languages seem to force on you. IMO, I find it kind of constrictive. I'm not sure if it's possible to create a flexible statically typed language that's not heavily functional; there don't seem to be many examples.

      I tried porting a couple of small programs to OCaml a while back; I was all excited that I was going to get C-level performance with a high level language. For some reason, the programs didn't end up running any faster than a Java implementation. I concluded that getting maximum performance out of that kind of language was not the no-brainer that it was cracked up to be. Given that only a small number of people have even heard of these languages, I figured it was better to stick with well-known tools than to become an expert at optimizing OCaml.

    34. Re:Uhhh by Daniel+Dvorkin · · Score: 1
      And the 0.2 seconds become more and more insignificant in more interesting programs...
      That's only true if the 0.2 second delay only happens once (or a few times) in the program. When that delay is inside a loop that executes a few hundred times ... and there are hundreds of such loops in the program ... suddenly you're sitting there wondering if your machine has crashed because it's taking so damn long to do anything.
      --
      The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
    35. Re:Uhhh by koali · · Score: 1

      Let's change the programs to print "hello world" one million times...

      alex@wintermute alex $ time java hello
      [...]
      real 0m2.032s
      user 0m0.161s
      sys 0m0.017s
      alex@wintermute alex $ time ./a.out
      [...]
      real 0m2.914s
      user 0m0.003s
      sys 0m0.004s

      Interesting, isn't it?

    36. Re:Uhhh by koali · · Score: 1

      Huh, sorry, that's one thousand times :-b

    37. Re:Uhhh by hughperkins · · Score: 1

      Yeah, wicked, then as soon as one dodgy app takes down java.exe, you lose everything else you were working on. Oh the joy!

    38. Re:Uhhh by firewood · · Score: 1
      Ok, here's an experiment:

      a) run Hello World in Java

      b) run Hello World in C (including booting up Linux)

      Which one is faster? :-)


      print "Hello World"

      in Basic, on an Apple II (or equivalent), is much faster than either when you include machine boot time. Does this make Basic the better language?

    39. Re:Uhhh by WolfWithoutAClause · · Score: 1

      No, since an Apple II can't load the program itself that fast.

      --

      -WolfWithoutAClause

      "Gravity is only a theory, not a fact!"
    40. Re:Uhhh by Anonymous Coward · · Score: 0

      Yeah, wicked, then you have to have the javavm loaded all the time.

    41. Re:Uhhh by Anonymous Coward · · Score: 0

      While good design is important, don't optimize before you have to.

    42. Re:Uhhh by Anonymous Coward · · Score: 0
      If Sun, or someone else, would come along and modify C slightly by removing unsafe functions, and providing alternatives, you could have the best of both, while not having to completely rewrite all the old code.

      I thought was called Ada?

      Ducks and runs.

    43. Re:Uhhh by pmz · · Score: 1

      print "Hello World"

      in Basic


      Or a UNIX shell.

  2. modular programming by marine_recon · · Score: 0, Interesting

    imagine if solairs was redesigend to be modudular, think of how much work that would save. now i will be the first to admit i dont have much knowledge of solairs, however i have used it, and help my programming buddies use it. we all agree that modular is the way to go.

    --
    Jack the sound barrier. Bring the noise.
    1. Re:modular programming by Anonymous Coward · · Score: 0

      It was called Spring. Look it up.

      God, was that slow. Some cool concepts,though.

    2. Re:modular programming by Nuclear+Elephant · · Score: 0

      Solaris is modular, but has a very different interface for enabling/disabling modules. IPF demonstrates this by loading/unloading itself as a kernel module.

    3. Re:modular programming by elmegil · · Score: 2, Insightful

      The kernel was re-written to be modular 15 years ago, which you'd know if you had read more than the first page of the article. As for the other layers of the OS, much of that is modular too; it's called "packages", quite similar to "rpms" that you might have heard of.

      --
      7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
    4. Re:modular programming by Anonymous Coward · · Score: 0

      This is such a vague idea/request.

      Which parts are not modular? What sense of the word "modular" do you mean?

  3. computer inept? by alienhazard · · Score: 1, Troll

    Yesterday I had my tech guy come to the house and disconnect my Sun network, and tomorrow I'm having them shut down my company e-mail account.

    you would think that a man of his position and career would know how to do such simple things. maybe it's a good thing he's leaving sun after all.

    --
    > "I allege that SCO is full of it" -Linus
    1. Re:computer inept? by arcanumas · · Score: 1

      Maybe it's BECAUSE he is in this position he doesn't want/have to do this. Have you heard of vi? he shure has

      --
      Slashdot Sig. version 0.1alpha. Use at your own risk.
    2. Re:computer inept? by Anonymous Coward · · Score: 0

      Perhaps the Sun network in his home is actually owned by Sun, and is not his property to disconnect.

      Perhaps Sun has a policy on company e-mail accounts that prohibit him from shutting down his own account. I'm sure that scenario wouldn't be too unheard of.

      He left the company.

    3. Re:computer inept? by Zocalo · · Score: 3, Informative
      Actually, this is standard practice, or should be, and not just in the IT industry either. By having a company engineer disconnect the network, collect any company owned kit, etc. there is an audit trail that exonerates the ex-employee from any allegations of misappropriation of those resources.

      Or at least, that's the theory...

      --
      UNIX? They're not even circumcised! Savages!
    4. Re:computer inept? by elmegil · · Score: 1

      Sorry to break your bubble, but most of the time, large corporations have IT people to do stuff like this. It's not like Joy has the root password to the servers to go remove whatever email he wants. He doesn't, I don't (I work for Sun too), and while both of us are quite capable of managing that aspect, since it has nothing to do with what Sun pays us to do, we don't do it.

      --
      7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
    5. Re:computer inept? by Haeleth · · Score: 1

      Nice quote from your link...

      "EMACS is a nice editor too, but because it costs hundreds of dollars, there will always be people who won't buy it."

      How the world has changed since 1984...

    6. Re:computer inept? by Anonymous Coward · · Score: 0

      Going by the rest of the article, I would agree with you. For an experienced programmer, he sounds like a total crank.

    7. Re:computer inept? by Anonymous Coward · · Score: 0

      If that's the case, I feel sorry for the engineer who has to go off site all the time and do these things. He'll get blamed for everything.

  4. Java by cscx · · Score: 1, Funny

    I guess that's why Sun makes those multi-processor sparcs... so you can run their ideal Java utopia on your desktop, right?

  5. How much of Java did Joy design by Anonymous Coward · · Score: 0

    as compared to Gosling? Does he really deserve the credit he is claiming about Java?

  6. Keep the hype going by sammyo · · Score: 1

    Last time I heard him talk Jini would be in every toaster in every house by 2001. A think tank in Aspen sounded pretty cushy but none of it changed my life. Maybe a think tank in Nebraska or South Dakota would inspire the thinkers to think hard enough to build something cool. Er, no.

  7. Bill Joy... by gregh76 · · Score: 0, Troll

    ...is an antique.

  8. Joy may not be with Sun... by Bloodshot · · Score: 3, Insightful

    ...but he's acting like he still is.

    This article is one big "Java can solve all the internet's problems" troll. As if Microsoft's problem is because their code is written in C instead of Java. That's ludicrous.

    A programming language can't change people's behaviour. Only PEOPLE can change people's behaviour. Bill Joy's obviously a smart guy, but his railing against what he calls "antiquated" languages and his lack of understanding on why programming languages have nothing to do with e-mail viruses being able to spread so easily shows why Sun is no longer in such a position of prominence.

    His statement about how he "designed solutions for problems that people didn't yet know they had" either shows a complete lack of understanding of the way NORMAL people use technology or he's started believing his own marketing spin about Java and Sun's other technologies.

    It makes me wonder if Joy is leaving Sun because he's bitter that Sun couldn't take down Microsoft and that Java, while a very powerfull programming language that definitely has it's place in certain types of projects, isn't the language of choice for programmers everywhere.

    1. Re:Joy may not be with Sun... by ZenFu · · Score: 0

      His statement about how he "designed solutions for problems that people didn't yet know they had" either shows a complete lack of understanding of the way NORMAL people use technology or he's started believing his own marketing spin about Java and Sun's other technologies. As an MBA and proud founder of a failed startup, I read this more of a quote that I had memorized, but did not realize until we were packing it in: "they were a solution looking for a problem". Looking back and forward, I would much rather have a mediocre solution to a problem that people are desperate to resolve than a brilliant solution to a problem that nobody really cares about. If the customer is desperate, you only have to meet them half way with a fair price to make a quick sale. If the customer isn't totally convinced that they have a problem then you need to get ready for a long, involved, and financially depressing sales process. A perfect example of a painful problem with a desperate customer that he did talk about: the inability to secure systems from attack. People are in pain and they are actively looking for solutions. Come up with something decent in this area and the world will use your stuff (aka beat a path to your door).

    2. Re:Joy may not be with Sun... by AdamBa · · Score: 3, Insightful

      Indeed. Part of the interview is interesting, but the parts about Java and Windows are just market-speak. vi is a great editor, but Joy seems to have turned into a giant tool.

      - adam

    3. Re:Joy may not be with Sun... by Xabraxas · · Score: 1
      As an MBA and proud founder of a failed startup, I read this more of a quote that I had memorized, but did not realize until we were packing it in: "they were a solution looking for a problem". Looking back and forward, I would much rather have a mediocre solution to a problem that people are desperate to resolve than a brilliant solution to a problem that nobody really cares about. If the customer is desperate, you only have to meet them half way with a fair price to make a quick sale. If the customer isn't totally convinced that they have a problem then you need to get ready for a long, involved, and financially depressing sales process. A perfect example of a painful problem with a desperate customer that he did talk about: the inability to secure systems from attack. People are in pain and they are actively looking for solutions. Come up with something decent in this area and the world will use your stuff (aka beat a path to your door).

      I think you are making his point for him. It's good for business to make a mediocre solution but it's bad for technology. Technology for the general public is so far behind what it could be because people don't even know about its capabilities and don't care. Then when something new finally does come along everyone says "Why didn't we have this earlier?". Because no one cared about technology until it solved a problem for them. It makes perfect business sense but no technological sense.

      --
      Time makes more converts than reason
    4. Re:Joy may not be with Sun... by alext · · Score: 2, Insightful

      That's ludicrous.

      Not really. If one had to describe Windows' vulnerabilities in a few phrases, buffer overflows, untrusted code and uncontrolled access would be a reasonable summary.

      These vulnerabilities are all properly and intrinsically addressed in Java. It is not possible to circumvent the controls by sloppy or malicious programming, therefore Java does enforce secure behaviour.

      Joy's comments might represent an exaggeration or simplification, not unreasonable considering the intended audience, but they clearly demonstrate more "insight" than the superficial blather offered above.

    5. Re:Joy may not be with Sun... by Anonymous Coward · · Score: 0

      Yes indeed. I have done some programming with java (not a lot, maybe a few dozen applications of two hundred or three hundred lines each). S L O W. Narcoticized slug can not describe the low speed. Same algorithm, same result but written in C and you wonder where all the speed came from. Java is good for web apps., and it is secure. It's just the last thing on earth you would want to use for application programming (unless you wanted your quad P4 Xeon server with the 800 MHz bus looking like a first generation 386).

  9. Re:followup by Anonymous Coward · · Score: 0

    There should be a special goat-link mod. Somebody meta-moding this (without following the link) might think the -1 Troll was unfair.

  10. Maybe he has no time.. by Anonymous Coward · · Score: 0

    Do you think you'd waste your time in doing something so menial, if you have better things to do. And maybe, just maybe, it's a corporate policy that you are not to twiddle with the stuff yourself?

    Also, you must learn something before you grow into an adult: position does not imply skills. (Although it does in B. Joy's case, I'm sure)

  11. Insightful? More like ignorant! by Anonymous Coward · · Score: 0

    how is this insightful?

    Its the attitude of 'the language must be able to deal with my stupidity' that results in bloated code and software that requires the latest CPU's to be able to run with any speed

    1. Re:Insightful? More like ignorant! by lokedhs · · Score: 1
      This happens with any programming language. Microsoft Office manages to out-bloat itself on every release, and it's written in C++.

      At the same time I have seen extremely lean effificent programs written in safe languages. And let me emphasise this again: Java is not the only safe language around, it's just the most popular right now, together with Python I guess.

      If it was bad attitude on the programmers part to use development tools and languages to minimise errors and make us more effeient, we'd still be hand-coding everything in machine code.

  12. After sun ... by Rosco+P.+Coltrane · · Score: 5, Funny

    Bill Joy could join Mercury, Venus, Earth, Mars, Jupiter, Saturn, Neptune or Pluto.

    (Oddly enough, there isn't a company that bears the name of the missing planet you're thinking of ...)

    --
    "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
    1. Re:After sun ... by daeley · · Score: 2, Funny

      Ah, but you can go pester one Bret Silberman, who apparently purchased Uranus back in 1993. He is also not willing to sell Uranus, so "...don't bother asking."

      Perhaps the best part of that page is "Uranus Headlines" on the right. ;)

      --
      I watched C-beams glitter in the dark near the Tannhauser gate.
    2. Re:After sun ... by El_Ge_Ex · · Score: 1

      You mean Uranus???[goatse.cx]

      (Don't worry, I would never actually put that link up.)

      -N

    3. Re:After sun ... by Prior+Restraint · · Score: 1

      (Oddly enough, there isn't a company that bears the name of the missing planet you're thinking of ...)

      Sure there is. You just need to get a little creative and go with the Greek version: Ouranos.

    4. Re:After sun ... by boredMDer · · Score: 1

      Uranus Consulting Ltd.

      Finnish, but still a company bearing the name of the missing planet we were all thinking of.

    5. Re:After sun ... by spectecjr · · Score: 1

      Bill Joy could join Mercury, Venus, Earth, Mars, Jupiter, Saturn, Neptune or Pluto.

      (Oddly enough, there isn't a company that bears the name of the missing planet you're thinking of ...)


      Actually though, a friend of mine set up a startup called Planet 7. Took a while for people to get it. :)

      --
      Coming soon - pyrogyra
  13. Idiot or Liar? by Anonymous Coward · · Score: 5, Insightful

    Again, because that program is written in C, it's quite easy to design a virus to go through your e-mail address book and broadcast spam to all the people you know.

    The problem with Outlook isn't "C," the problem with outlook is Javascript, VBScript, and Windows Scripting Host, which are PRECISELY the sorts of high-level languages [and their interpreters] that this little terd is advocating.

    Or is he just a common liar? I dunno - you be the judge.

    1. Re:Idiot or Liar? by MisanthropicProggram · · Score: 2, Interesting
      Someone who wants to increase the value of his Sun stock so he can retire in more luxury.

      Fortune Magazine- Who's the audience: PHBs. Who buys systems: PHBs. His candid interview is nothing but a sales pitch.

      --

      There is no spoon or sig.

    2. Re:Idiot or Liar? by Anonymous Coward · · Score: 0

      Or is he just a common liar? I dunno - you be the judge.

      Also, he forgets to say that a java machine can have bugs too. Each time a layer is added, security drops a little.

      He shows that he knows very well that nearly everything is highly nonlinear and that doesn't keep him from being idealist. I really don't understand this guy and I even wonder if he says there what he thinks.

    3. Re:Idiot or Liar? by theridersofrohan · · Score: 2, Informative

      The problem with Outlook isn't "C," the problem with outlook is Javascript, VBScript, and Windows Scripting Host, which are PRECISELY the sorts of high-level languages [and their interpreters]

      Err no. He's definetly not an idiot (SUN anyone?) and he's not a liar. What he means by this is that as Outook is written in C, buffer over/underruns can happen which is what most viruses exploit (they then proceed to use high level languages such as Javascript etc. to get the email addresses and broadcast spam and viruses). But the primary problem is that oulook has security holes, usually buffer over/underruns. This is not _because_ of C, but what he's saying (and he's mostly right) is that if outlook was written in Java, there would be NO buffer underruns.



      that this little terd is advocating.

      Or is he just a common liar? I dunno - you be the judge.


      Oopps, I have probably been trolled. My bad.

    4. Re:Idiot or Liar? by sir_cello · · Score: 5, Informative

      You're wrong as well.

      The issue isn't with the programming language _per se_. Obviously some programming languages are more dangerous then others. Obviously some programmers are worse than others.

      The issue is with secure and contained execution environments. Properly "jailing" software (whether a process in an operating system, or a thread and window box on a preview pane in Outlook) is the real answer. Engineering has long known that compartmentalisation is key to minimising risk and impact. Operating systems are getting better at doing it. Programming languages are gradually working towards it.

      You can have all of the aforementioned and current problems with buffer overflows, language defects, etc: but if the impact is limited (say, to a display pane in Outlook) then the worst that can happen is psychological damage, nothing more. From one point of view, the preview pane should only be doing that: showing me a preview - it shouldn't be granting access to resources around it.

      I think that one of the key technologies that Java brought to the computing landscape was the concept of a secure machine (JVM) for a programming language (at a lower granuality than for a monolithic operating system). Argue as much as you like about how succesfull this was (I do remember much debate and technical attention given to it in the early days of Java), but the concept is far more important than the incremental language innovations in Java (i.e. a next-generation SmallTalk or C++).

      Give the guy some credit - he's done some very useful technical work - and Java will be one of the technologies in the timeline of the development of computer history. Even if Java itself wasn't succesfull, it's been an interesting experiment and a lot of learning has come out of it.

      I recommend this paper as a good read on the bus, just so you can appreciate the technical innovations surrounding the language.

      http://www.jot.fm/issues/issue_2003_09/column3

      ps. It's obvious he's still pulling the Sun line, but what do you expect ? He put a lot of effort and passion into Sun's technical direction - only a fool would think he's going to drop that overnight.

    5. Re:Idiot or Liar? by Anonymous Coward · · Score: 0

      I think that one of the key technologies that Java brought to the computing landscape was the concept of a secure machine (JVM) for a programming language (at a lower granuality than for a monolithic operating system).

      A computer is no different than a toothbrush or a hammer. If you tell a toothbrush to brush your teeth, it will brush your teeth, but if you tell a toothbrush to poke you in the eye, it will poke you in the eye. If you tell a hammer to hit a nail, it will hit a nail [or at least it will hit the nail about 80% of the time - the other 20% of the time it will either hit your thumb or miss altogether]. If, on the other hand, you tell a hammer to smash the skull of your thesis advisor, the hammer will gladly smash the skull of your thesis adviser.

      If you tell a low level language, like C++, C, Assembler, or, God forbid, your processor's microcode, to delete all the files on your hard drive, then the language will happily delete all the files on your hard drive.

      If you tell a High Level Language, like Java, JavaScript, VBScript, Perl, Python, Smalltalk, or ChooseYourPoison, to delete all the files on your hard drive, then the language will happily delete all the files on your hard drive.

      If a language/interpreter/environment/operating system/milieu is capable of doing something useful, then it is equally capable of doing something deleterious.

      The only perfectly secure computer system is no system at all.

    6. Re:Idiot or Liar? by Raffaello · · Score: 1

      Oh really?

      So If I tell Java to overrun a buffer, will it?

      No, it will throw an exception. Java doesn't allow direct access to memory, so buffers can't be maliciously overrun. Since this exception mechanism is not built into C at the language level, C is inherently more insecure. C opens the door to one of the most common kinds of attack, a buffer overrun, a type of attack to which Java software is immune.

      Some languages actually prevent programmers from leaving certain security holes. C provides very little of this protection. Java provides more.

    7. Re:Idiot or Liar? by Anonymous+Brave+Guy · · Score: 2, Insightful
      So If I tell Java to overrun a buffer, will it?

      No, but you could easily write an e-mail client in Java that interpreted scripts in the body or header fields of an incoming mail by default, and allowed those scripts to do things they shouldn't. This is the single biggest problem with Outlook (Express) and the reason it's responsible for so many virus/spam problems. It has nothing to do with the language used to implement it, and everything to do with the flawed architectural and security policy decisions in its design.

      Using a "more secure" language like Java does zip to address this sort of problem. As the post further up the thread said, the really useful concept in Java is the "sandbox" idea for code that's executing, not the minor improvements to the language itself.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    8. Re:Idiot or Liar? by Anonymous Coward · · Score: 0

      Outhouse may have a flawed security design, but the most common exploit is not design-related. It's a buffer overflow in the date parsing code. That's something that surely could be eliminated with a so-called 'secure' language.

    9. Re:Idiot or Liar? by blane.bramble · · Score: 1

      Outhouse may have a flawed security design, but the most common exploit is not design-related. It's a buffer overflow in the date parsing code. That's something that surely could be eliminated with a so-called 'secure' language.

      It's also a problem that could be eliminated with properly written C programs - irrespective of programming language, all data should be checked before being processed.

    10. Re:Idiot or Liar? by Anonymous Coward · · Score: 0

      Outlook isn't even written in C, it's written in C++ . There are far more "exploits" that don't require any sort of stack or heap attack than do. Java does nothing to avoid these. The others, better practices would prevent them from occuring.

    11. Re:Idiot or Liar? by Prof.Phreak · · Score: 1

      The issue is with secure and contained execution environments.

      I'd just like to point out that you *can* properly secure and isolate native code on modern processors. That's how the Kernel manages to protect itself from userland processes.

      Just because no OS does it, doesn't mean it can't be done (ie: natively executing a process - with certain permissions or none at all).

      The Pentium has quite fine controls on what a processor is or is not allowed to do.

      So in the end, it's not about C/C++, or Java or C#. It's the basic design of the system. If you want to build a secure system, it doesn't really matter what language you use, or what VM, etc.

      --

      "If anything can go wrong, it will." - Murphy

    12. Re:Idiot or Liar? by alext · · Score: 1

      But not generally at the level of granularity of a thread or window, as clearly stated in the parent but omitted in your quote.

    13. Re:Idiot or Liar? by Anonymous Coward · · Score: 0

      Maybe someone should send M$ that memo...

    14. Re:Idiot or Liar? by autopr0n · · Score: 1

      No, but you could easily write an e-mail client in Java that interpreted scripts in the body or header fields of an incoming mail by default, and allowed those scripts to do things they shouldn't.

      True, but with java you can prevent those mail scripts from doing anything they shouldn't do with about 5 or 6 lines of code (simply load the script interpreter into a ProtectionDomain without any rights to the filesystem, and call AccessControler.doPrivilaged() with it)

      --
      autopr0n is like, down and stuff.
    15. Re:Idiot or Liar? by Anonymous+Brave+Guy · · Score: 1
      True, but with java you can prevent those mail scripts from doing anything they shouldn't do [...]

      Of course, you could also prevent them from doing that by not writing thousands of lines of code (in whatever language) to support damaging operations that no legitimate script would ever need to do in the first place. :-)

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    16. Re:Idiot or Liar? by ThisIsFred · · Score: 1
      The issue is with secure and contained execution environments. Properly "jailing" software (whether a process in an operating system, or a thread and window box on a preview pane in Outlook) is the real answer.

      No, in the specific context of Outlook worms, I have to disagree. I also disagree with Bill Joy on this specific point; Buffer overruns aren't necessary to take control of Outlook. In the context of just about any other generic example, I do agree with both of you.

      Outlook requires access to the address-book component to function properly, and because Outlook is part of the MSO suite, it is built with macro functionality using VBS. As far as I know, there aren't any privilege levels in the VB interpreter, so if your macro can use one function, it can use 'em all. Also, Windows opens certain registered types of files without asking about a helper application. It's odd to think of it this way, but Outlook/VBS/Registry aren't doing anything they weren't expected to do. Jailing it isn't going to prevent it from spreading the VBS worms we've seen thus far... Well, not without completely breaking Outlook.

      The solution to Outlook's problem is probably going to be difficult for Microsoft to apply (it will break some stuff), will make things less convenient for users, but is definitely do-able in a reasonable amount of time.

      Some suggestions of mine:

      Messages should be stored in plaintext format with encoded attachments (most likely how they're received). This gives the added bonus that a third-party filter can examine the message before Outlook attempts to decode it, and it would be easier to write an external filter.

      Attachments aren't decoded until the user actually manually initiates the opening of the attachment, (simply viewing the message doesn't trigger decoding of attachments.)

      Related to the above, the default action with an encoded binary which doesn't have an associated helper application is to download to disk, and to present a warning about viruses or trojans when done.

      Outlook maintains its own list of helper applications and file associations, apart from what is in the Windows registry, sort of like how Netscape does it.

      Preview only previews the plaintext body. HTML is not previewed without a warning. Even better would be a configurable HTML filter which disables certain tags, sort of like in PhpBB. Or Slashdot!

      The default action with some sort of out-of-spec text attachment (or deviation from message format) is to display the text in the preview pane, not pass it to Windows' shell execute to decide its fate. Worst case scenario: Garbage on the screen.

      HTML can't be rendered inside of Outlook's interface. It must be passed to an external viewer, with optional tag filtering applied in the process. This viewer can be IE, but an alternate, more secure browser could be used. It's annoying, but IT would then have a choice besides just dumping Outlook.

      I realize that the above would break those one-file HTML glob pages with images that folks like to send out. Good. Those are stupid for two reasons: 1) A remote user can include all manner of weird binary data, and 2) PS and PDF already cover that functionality and do a much better job with presentation.

      --
      Fred

      "A fool and his freedom are soon parted"
      -RMS
    17. Re:Idiot or Liar? by shoeless_barney · · Score: 1

      Did anyone notice that he seems put himself and Bill Gates at the same level. Or somehow, anything he says borders on God-Speak. I heard him speak at JavaOne in 1998, kind of a "keynote" panel of experts. The guy was a first rate whack-bag, everyone started leaving the more he talked. I think he is a nut, and should have continued working on BSD.

    18. Re:Idiot or Liar? by cpeterso · · Score: 1


      I used to work at Microsoft during Windows 2000 product development. There was a project (I never learned the codename) to create a "sandbox" environment for arbitrary native code. Some OSes (like EROS)can do this using "capabilities", where you tell the OS which system calls and features the application is allowed to use.

      The NT team was trying to this but in the typical backwards Microsoft design: using "Discretionary Access Control Lists" (DACLS). DACLs are like ACLs in reverse: you tell the OS which system calls and features the user/group/application is NOT allowed to use. The idea was that some arbitrary native code could be downloaded from the Internet, run in this sandbox, and everything would be safe. The only problem is that a sandbox built using DACLs would have to explicitly list EVERYTHING the application was NOT allowed to do. Needless to say, this is an impossible feat. If some Microsoft engineer forgot some small feature, API side-effect, or unknown interaction with some IE buffer overrun, then the entire sandbox is blown wide open. This sandbox is more like a sieve.

    19. Re:Idiot or Liar? by strobert · · Score: 1

      so why the FSCK don't java programmers use the "security model". I have yet to see one java server application using it, and I don't know of any client applications using it correctly.

      And that assumes that the security code is perfect in Java. if there is a bug in that security code you are screwed. And given the (lack of) quality programming in other core JVM subsystems (like memory management, threading, etc.) in various JVM versions (personal experience in the 1.1,1.2 and 1.3 series) I strongly doubt the security code is something to hold a lot of faith in.

      Shott I seem to recall nasty brokeness in the security isolation of earier netscape JVM's.

      I hear a LOT of talk about oh but with Java you will be secure, but in practice I just haven't seen any results.

      What has worked is having good (including meaning they are smart and technical -- aka can actually understand what a computer does) programmers working on the code.

  14. parent is -1, Retarded by Anonymous Coward · · Score: 0

    but this isn't a goatse link, now is it?

  15. If C had had bounds checking by Anonymous Coward · · Score: 0

    Hardware would have done it efficiently, it is not that huge an overhead.

    C is the number 1 cause of insecurity of computers, period. It is efficient, but that is because it has kept back hardware to a point where only insecure languages can be efficient.

    1. Re:If C had had bounds checking by Anonymous Coward · · Score: 0

      how is it C's fault?

      how about the fact that people don't write their code with security in mind nor do they ever do audits and testing of their code?

    2. Re:If C had had bounds checking by MisanthropicProggram · · Score: 2, Insightful

      You are absolutely correct. Somehow, somewhere, programming langauges have become required to compensate for programmer laziness/productivity/whatever... Just because a programming language allows a programmer to do stupid things doesn't make it inferior. The things that allow you to do stupid things also make extrememly powerful. Write a device driver/embeded system/OS in Java ... I don't think so.

      --

      There is no spoon or sig.

    3. Re:If C had had bounds checking by aschlemm · · Score: 1

      Even Java doesn't save programmers from themselves in all cases. As someone that has written a great deal of Java code since 1996 I see programmers making the same sort of mistakes I saw them make in C++. The biggest problem is that it seems that most programmers going into Java think that because Java does garbage collection that no longer have to worry about memory management. That's total bunk! I can't tell you how often I've seen programs where people add an object to a container and then never bother to remove it. After time the JVM grows to 100s of MB in size bring the system to its knees.

      To make Java programs that reliable that can run for longs periods of time you have to expend allot of extra effort and run them through memory profilers, force garbage collection to occur and then take a heap snapshort and go through and look objects that are left stranded because one or more objects still hold a reference to it.

      At least when working on C++ projects we all understand (or are at least aware) of the fact that we need to worry about allocating/deallocting memory and that we need to worry about bounds checking as well. We tend to use the auto_ptr in C++ in as many places as it makes sense to try to ensure we don't cause any memory leaks with objects that are dymanically allocated.

    4. Re:If C had had bounds checking by evilviper · · Score: 1
      Somehow, somewhere, programming langauges have become required to compensate for programmer laziness/productivity/whatever...

      That "somewhere" just happened to be the point at which programs became so incredibly complex, that it would take a small army of programmers to ensure that it is secure, and free of serious bugs.

      It's one thing if a language lets you do stupid things, it's quite another when a handful of some of the best programmers in the world (and millions of eyeballs), can't keep a single program safe and secure.

      OpenSSH is a good example, because they pride themselves on completely bug-free programming, auditing code for bugs regularly, and including multiple facilities to ensure that a bug does not become a security problem. Yet, even they have had several bugs slip through the cracks.

      If you don't like that example, there are thousands of others. Even the Apache team couldn't keep the program bug-free enough to prevent security problems. They do an admirable job, but even they can't achieve perfection in C.

      It gets to a point where you just have to say, gee, maybe if nobody can make bug-free C code, the language just might be partially to blame.

      I (obviously) don't believe that Java is the answer to all the worlds problem. However, better error-checking, and bug prevention facilities in the language are not just to cover for lazy programmers; they are now an absolute necessity, for even the most skilled programmers in the world.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    5. Re:If C had had bounds checking by Anonymous Coward · · Score: 0
      Just because a programming language allows a programmer to do stupid things doesn't make it inferior. The things that allow you to do stupid things also make extrememly powerful. Write a device driver/embeded system/OS in Java ... I don't think so.

      Hmm. That's exactly what the US Navy intends to do with...you guessed it, Real-Time Java. They are paying handsomely to create a new spec for a safety-critical, real-time, embedable language which they'll call Real-Time Core Java. Checkout this article. (PDF format, sorry)

      Why are they doing this? It's mostly due to the perceived cheapness of Java programmers and a desire to write everything in "ths same language." I think some of it is the "Information Week" syndrome and the view that commercial must be better. As an aspiring Ada guru, I am perplexed, but I understand the motivations a little too.

      The Ada mandate expired, having mostly completed its mission. The DoD no longer had to support thousands of custom programming languages, but C, C++, and Java were still much more popular with commercial programmers. They are wisely skipping C++ (although it's an option) and moving on to what all of the CS undergrads are being taught. They seem to think that they will be able to get more programmers cheaper.

      I think that they're nuts. If a CS graduate can't pick up Ada (or Objective-C, or Oberon, or any other imperative language) and be productive in less than a month, then they are uesless, and their college's accreditation should be revoked for granting a diploma to a bonehead. That said, nobody wants to spend money and time on training, and there are a hell of a lot of commercially available Java libraries in just about every problem domain. *sigh*

    6. Re:If C had had bounds checking by moof1138 · · Score: 1

      You missed the point - drivers, OSes, etc. were not what Joy was talking about. C is a programming languages that make it incredibly hard to write secure code, even for talented experienced programmers with decades of experience. C lacks any automatic way of doing exception handling, bounds checking, memory management etc. Implementing these things in C is a pain - the language leaves you to do work that has nothing to do with what you are trying to achieve (debugging memory errors, and matching your mallocs and frees), and penalizes you for good programming practives since you have to roll your own. C is great for writing a kernel or a driver where you really need the performance, but it simply sucks ass for writing an internet daemon - even the best coders in the world still make errors, even after repeat code reviews. Look at Sendmail (recent versions), look at OpenSSH, Apache, et al. They have been code reviewed over and again, simplified, scrutinized by many many eyeballs, and still stupid security errors come up, and over and over it is due to errors in handling exceptions, bounds checking or other things that occur due to programming in C, but would not be an issue in more modern languages. Security wise, C is simply not suited to writing internet daemons, even if you are a talented coder.

      --

      Hyperbole is the worst thing ever.
  16. Java vs C? by Anonymous Coward · · Score: 0

    Just wondering, what language was built to write Java?

  17. Oh dear lord... by pVoid · · Score: 2, Interesting
    because stuff written in antique programming languages like C [a widely used language created by Bell Labs in the early 1970s] is full of holes. Those languages weren't designed for writing distributed programs to be used over a network. Yet that's what Microsoft still uses.

    The fundamentalism never ends man. I'm almost positive when I assert these three facts:

    NT Kernel is in C but so is SunOS

    SQL Server 2000 is *entirely* C++

    I'm almost positive IE is largely, if not entirely written or at least compiled in C++

    1. Re:Oh dear lord... by gilesjuk · · Score: 1

      And what do you think a JavaVM is written in? C or C++ for sure.

      Whatever it's written in it still compiles down to the instruction set of the CPU or would he rather all CPUs ran Java bytecode?

      OO languages simply aren't suitable for all tasks, neither is C. It might shock people like Joy to know that machine code is still written, you sometimes need to to write it for embedded systems.

    2. Re:Oh dear lord... by Anonymous Coward · · Score: 0

      Don't you understand that C++ is nothing more than a cute object shim on top of C? What Joy is advocating is a computer language that fundamentally doesn't let you make certain classes of mistakes.

      Unfortunately, Bill, it's not that easy. You'll only increase the sophistication of attack... not magically eliminate it. I agree with him to a degree, though. The current state of software tools sucks. While Java isn't the answer, it is a minor incremental step forward.

      Hmm... I have further thoughts on this subject, but you'll need to sign my shiny NDA to get at them.

    3. Re:Oh dear lord... by eap · · Score: 2, Funny
      # I'm almost positive IE is largely, if not entirely written or at least compiled in C++

      Internet Explorer is written in Algol but is compiled in Perl and linked in Smalltalk.

    4. Re:Oh dear lord... by pVoid · · Score: 1
      Don't you understand that C++ is nothing more than a cute object shim on top of C

      No I don't. In fact, I can safely say that you probably haven't understood what C++ is at all. **At all**.

      Also, dude, C++ is not Bill's creation. And so, as stupid as ad-hominem attacks are, misplaced ad-hominem attacks are even more stupid. I'm not going to defend bill to defend C++.

      Are you fucking smoking Crack?

    5. Re:Oh dear lord... by Anonymous Coward · · Score: 0

      I don't think you are fully aware of what you are talking about yourself, my friend.

      C++ is merely an extension to C, and a fairly messy one at that. Any C programmer should know that the differences between C and C++ are miniscule. When I tell someone less informed that I'm coding something in C, and they ask, "you mean C++?", I sort of roll my eyes.

      Compiling a C program in C++ does not make it any more secure, robust, object-oriented or different, as you seem to suggest. It is still a C program.

      The reason Java is advocated over C++ is because it is a high level solution, which C++ is not be able.

      Your C++ compiler is essentially still C. It will still generate code which may make dirty assumptions, if you are not doing things right. With C++, it is possible, for example, to corrupt the virtual pointer table of a class, accidentally or not. And it is possible to do many other things that some people think a "high-level" language should not.

      Java, on the other hand, doesn't allow direct manipulation of pointers at all. It is considered "safe".

      I just recommend that you try to stay informed before you start asking people what they're smoking.

    6. Re:Oh dear lord... by aschlemm · · Score: 1

      The other thing that I didn't see mentioned is that there are some protection features available for C/C++. I saw that the OpenBSD team has integrated IBM's ProPolice into their base system which helps protect systems against stack-smashing attacks.

      Compilation Solutions in C/C++

    7. Re:Oh dear lord... by Anonymous Coward · · Score: 0
      or would he rather all CPUs ran Java bytecode?
      I have absolutely zero knowledge of the Java bytecode language or microprocessor design, but it would be very interesting if a special "low-level" Java were developed.

      Basically, there would be Java bytecodes for doing pointer manipulation and all the "ugly" things that Java programs are not supposed to do, but are required to write a kernel.

      Then, user-space programs would not be allowed to use these bytecodes, similarly to the way an MMU can restrict certain tasks from accessing memory.

      From there, you can have a CPU that runs Java bytecode, a kernel written in Java (or perhaps C, compiled to Java bytecodes), and userspace Java processes that are "safe" and Java-esque. Unless I am wrong about all of this being possible, which I might probably be.
    8. Re:Oh dear lord... by pVoid · · Score: 1
      Ok, I will keep it short because I hate fucking engaging in napalming games on anonymous discussion threads where there are absolutely no scrupules.

      First of all, C++ isn't just an extention of C as you might seem to think. You are probably thinking "C++ is just a set of runtime routines defined to support class construction and destruction".

      The fact of the matter is that C++ has much more rigourous type checking, which is a big problem as a lot of people know. That's the first difference.

      The second difference is that unlike C, where you could actually map any statement, operator or construct to a single piece of ASM code (writing a compiler for C isn't that hard), C++ does some actual work which distinguishes it from a 'low-level' language. This isn't to say C++ is a 4th generation language, it's not. But it *is* a third generation language.

      The issue really, is not about the language semantics, but about the model of the underlying machine you're controling. Java basically is modeled on a system where 'memory doesn't really exist' - ie, you are not allowed to do pointer arithmetic. That's fine if you're writing your little web application, but I'm not convinced it'll perform well when the day comes to render 3D in real-time, or implement a codec. And don't friggin say "we have libraries to do that" you don't... those libraries are in C.

      Now, for my piece de resistence. C++ has templates. You probably think templates are a puny little device implemented at the last minute to save C++'s ass... you can go ahead and think that way, it'll only make me happier one more idiot doesn't know about templates. The even more joyfull part is that Java DOES NOT have templates. And templates my friend, can do things class inheritence CAN NOT.

      By now, you're zit festering little face is probably red with anger... which delights me really... I am NOT going to explain what templates do because a) I don't care if you understand them or not, b) you should get off your lazy ass and read the couple of books I read to understand them.

      My last statement is this: C++ can be *as* safe as Java if say a programmer consistently uses STL. AS SAFE. The moment the language stops being safe is the moment a programmer actually uses a buffer and typecasts away the safety parameters. basic_string<T>::c_str() returns a const T*. You cannot touch consts unless you *explicitly* disable the compilers internal checking by typecasting the const away. In any case, doing such a thing is GLARING in code (if you are a good programmer), and a compiler with a proper setting will complain about it anyways.

      Before I thought you were on crack. I'm sorry, now I know you're just an ignorant ass.

    9. Re:Oh dear lord... by scrytch · · Score: 1

      > SQL Server 2000 is *entirely* C++

      Didn't Slammer exploit a buffer overflow in SQL Server 2000? A mere 376 bytes with a few in the wrong place, all because of buffer overruns...

      --
      I've finally had it: until slashdot gets article moderation, I am not coming back.
    10. Re:Oh dear lord... by whorfin · · Score: 1

      While I overall agree with you, especially with modern C++ compilers, there is some truth to the perception that C++ is a mere extension of C.

      The first (partial) implementations of C++ was, if I recall correctly, the AT&T headers that extended a C compiler.

      And although C++ does have stronger typing than C, it's not exactly bulletproof. If you define classes for all of your types, then you can enforce strict typing, but for the 'basic' types (shared between C and C++), code that looks correct and compiles without warning could have catastrophic errors (reducing size in an assignment), and the fact that an enumerated type is treated by the compiler as a fancy bag of numbers.

      Yes, these (and other) issues can all be avoided with strict discipline, but a common thread of all of the 'modern' language is to eliminate common human errors.

      And re: your last example, that's one of the things that mortifies me about C++. All of this typechecking is really just a suggestion. It can be forced off by typecasting, allowing flagrantly illegal operations.

      --
      Laugh while you can, monkey-boy!
    11. Re:Oh dear lord... by pVoid · · Score: 1
      I agree with you with every point you have said.

      I'm going to venture a bit out of my comfort zone saying this on /. but to me a language, be it computer or natural is a means of expression. The reason why I like C++ so much is because of its dexterity, of the fact that it's actually legal to turn off compiler checks. Although I wouldn't recommend it in a business object, you can come up with some extremely elegant 'hacks'.

      Now that being said, I don't think C++ is the only language capable of doing this (notice, I didn't say C). Lisp and its derivatives have this extremely maleable and expressive syntax to them as well.

      Perl too, to a certain extent (although Perl scares me for any project larger than 200 lines).

      Java on the other hand, to me feels like a microwave instruction booklet. No flexibility whatsoever.

      These are all my opinions of course. But all in all, I will always defend C++ from people that say it's just an extension to C which is itself an extention to assembly.

    12. Re:Oh dear lord... by Anonymous Coward · · Score: 0

      Yes, I know that C++ and C are not the same. I know about templates, I know about overloading, and I have used them all pretty extensively. I think it's foolish of you to assume that I don't. It reminds me of one assumption I saw somebody make randomly in public just last night. An elderly woman assumed that this Hispanic woman didn't speak any English, just by looking at her. In actuality, she did speak English, and I spoke with her briefly.

      I know that C++ is not a runtime environment over C, that there are some pretty heavy changes at the compiler level. I've written C and C++ code both, you know.

      However, C++ is inescapably rooted in C. Ain't no way around that. And it IS possible, for example, to corrupt the vtable in C++ without using any libc calls. I have done it. It took me forever to find the problem and fix it.

      I am not a big fan of Java, personally; I was just playing devil's advocate. I don't care what you have to say that criticizes it. Yes, it would probably benefit from templates. It is also possible to fake template-like features in C with #define macros. It's much harder and more annoying, of course.

      I know G++ implements templates by defining functions with mangled names at runtime. Of course C cannot do this, with its flat namespace and no mangling. I can think of a million and one situations in C coding that I wish it had mangled names, and you could have functions with the same name but different arguments. There you go, a non-strictly-class-related C++ feature I like sometimes. But then, there are also times when I'd prefer not to have mangled names, like if I am getting a function through "dlsym", or if I am calling a function through assembly. That's what extern "C" is for. Great.

      Let me just say one thing to you, my friend. There is so much needless hostility in your writing. Mellow out.

    13. Re:Oh dear lord... by Anonymous Coward · · Score: 0

      With the advent of JITs, some Java interpreters are now written in Java. The compiled native code of the interpeter is dumped to a file, and then loaded up whenever you want to run it.

    14. Re:Oh dear lord... by pVoid · · Score: 1
      I admit the hostility quite readily.

      I won't let you go uncriticized though, you said:

      <quote>I don't think you are fully aware of what you are talking about yourself, my friend.

      C++ is merely an extension to C, and a fairly messy one at that.</quote>

      The situation is that I've come to realize one thing in life in general: being complacenct to ignorance and fud is just as bad as spreading the same fud. What Joy said in that article is, IMO, more or less FUD. It's plain and simple "push yourself up by pulling others down" tactics. It's quite sad really that he gets to broadcast such a shitty message from so high too.

      That being said, here we are on slashdot, and people are talking. I generally tend to avoid posting in inflamed Linux/Windows wars, even though to me it seems quite glaring that it's not about microsoft being wrong or right in general, it's about "the underdog will overcome" mentality. The sad thing is that that same mentality is quite simply being exploited.

      Anyways, I won't go into a whole polemic about that one either, but the few times I post and am faced with what sounds like fud, I react to it. I don't dissimulate it behind a veil of wisdom and calmness that many 'gurus' out there profess to have, when even Linus writes open letters saying "you're on crack", and Verisign responds by figuratively saying "fuck you all to hell".

      The bottom line is that I *do* get irritated, maybe more than I should, but only when I think I'm dealing with someone who is spreading fud. And you for a while sounded like it (posting as anymous doesn't help either).

      On a side note, if vtables get corrupt in libc, then there is a bug in libc and you should notify whoever is in charge of it.

    15. Re:Oh dear lord... by Anonymous Coward · · Score: 0

      Man. I thought it was written entirely in Javascript!

    16. Re:Oh dear lord... by Anonymous Coward · · Score: 0

      The bottom line is that I *do* get irritated, maybe more than I should .. you think !?!

      You really need to get laid it's sure to clear up that ba

    17. Re:Oh dear lord... by pVoid · · Score: 1
      Your revolution is over. The bums lost. I suggest you do what your parents did mister Lebowsky... GET A JOB.

      It's no use arguing man. I'm now going to move on... have a nice life.

    18. Re:Oh dear lord... by autopr0n · · Score: 1

      That's fine if you're writing your little web application, but I'm not convinced it'll perform well when the day comes to render 3D in real-time, or implement a codec.

      Why not? Array access is as fast as pointer arithmetic. Sure, those things are bounds checked in java making them a little slower, but linked lists for things like scene graphs and the like are just as fast. If you're using GL for 3d rendering, it should be plenty fast.

      My last statement is this: C++ can be *as* safe as Java if say a programmer consistently uses STL. AS SAFE.

      That's just not true. In java, I can take an piece of code and in a few lines of code Lock it down and prevent it from accessing the file system, with per-file granularity. I can prevent it from accessing the network, the GUI system or the printer, or anything else I might want to protect (all I have to do is add more permission types). There is absolutely no way to do this in C++. Once code is loaded into your memory space, it can do whatever it wants.

      If outlook had been written in java, The VBscript and other 'high level' vulnerabilities that plagued it could have been avoided simply by locking the script interpreter into it's own little 'sandbox' where it couldn't have done any harm. Sure, people at M$ could have made their own sandbox for the interpreter, but obviously they weren't able to. The STL has nothing like this.

      --
      autopr0n is like, down and stuff.
    19. Re:Oh dear lord... by pVoid · · Score: 1
      That's just not true. In java, I can take an piece of code and in a few lines of code Lock it down and prevent it from accessing the file system, with per-file granularity. I can prevent it from accessing the network, the GUI system or the printer, or anything else I might want to protect (all I have to do is add more permission types). There is absolutely no way to do this in C++. Once code is loaded into your memory space, it can do whatever it wants.

      I don't see how this is a benefit for Java at all. Why would sandbox behaviour make me prefer the language? If I want to implement security, I'll use a modern OS with proper a security configuration. Having a need to control access of a program from within source code is kind of admitting that you're not on top of what your code does, and you want to make sure you don't accidentally delete your system files...

      How is my point (C++ should be allowed to smash through every pointer) any different from the UNIX/linux philosophy of "if a user wants to, they should be able to unlink their kernel"?

      You have a point that had Outlook been written in Java, a sandbox could have been implemented, but that is essentially "Security as an after-thought" kind of programming. After all, the Microsoft bugs were inherent in design (in outlook at least). Once we admit to this, blaming the language is quite futile.

      That being said, STL has nothing like this is also true. But that's because STL wasn't meant to do that. STL was meant to be the most flexible templated library out there. I recommend you buy a book on STL and advanced templates, and you will maybe come to appreciate the enormity of STL. In any case, enough of my eulogising STL, the bottom line is that STL does its task perfectly well, and that is to abstract complexe AI structures such as lists, trees, maps, strings etc. etc. And if used properly, STL will ensure that a program has virtually no memory related bugs in it. STL combined with ATL is even more rock solid.

      And so we come to square one, why is Java better again?

    20. Re:Oh dear lord... by laffer1 · · Score: 1

      The next release of SQL Server is scheduled to be written in .NET. At the very least it will be managed C++ code. The whole point of the next release is to make it .NET native allowing .NET stored procedures. A Kernel should be written in a language like C. Its portable, fairly fast, and our Unix heritage. At this point in the "war", its Unix like vs Microsoft. It doesn't matter what IE is written in. All applications are exploitable in ANY language. Sure, the risk is smaller in java but you can still do some damage. If an app is running as root, does it matter? Half of windows runs as the system account. Don't blame the languages. I think everyone would agree C was designed before many of these ideas were considered important. People were more concerned about speed than buffer overflows. Remember the y2k bug? Its arrogant to think we are not making the same mistakes now. We just don't see them as a group yet. Web Development is an area that is very insecure for example. As I said in another post, Sun needs to get a new CPU under the hood that has some speed on it. What happens to java if sun goes under? No one has answered that question.

  18. Mistakes are a given by Anonymous Coward · · Score: 0

    Bounds checking removes potential bugs and exploits without extra work ... if you combine that with audits and testing you end up with more secure programs than without, it is that simple.

    To write code with security in mind is to remember your fallibility too.

  19. Rant continued... by pVoid · · Score: 3, Insightful
    if you're running a monoculture of software--duh, this is not good. People have studied how to make software systems more reliable by running three distinctly diverse implementations at the same time and then comparing the results. That's what they used to do in the space program, when not only were redundant systems built for, say, guidance, but each of them also ran on different computers with different software.

    Who here runs their hosted sites on two round-robined boxes with distinct kernels and Apache versions?

    Nature deals with breakdowns in a complex system with evolution, and a very important part of evolution is the extinction of particular species. It's a sort of backtracking mechanism that corrects an evolutionary mistake. The Internet is an ecology, so if you build a species on it that is vulnerable to a certain pathogen, it can very well undergo extinction. By the way, the species that go extinct tend to have limited genetic diversity.

    Are you implying that Microsoft Windows is vulnerable to extinction precisely because it is so dominant?

    He, and the article writer, are playing the circle-j*rk game by feeding each other soft-balls...

    But the analogy is poorly 'implemented' at best. If anything, Microsoft's culture could be compared to a termite infestation (revel you little zealots - I've just insulted microsoft), but in no case is it actually on the road to extinction. Extinction right now is a bad looming shadow for *BSD and BeOS and OS/2 etc...

    Why is the analogy broken? Because the oxygen and glucose of software is money. Not electricity and bandwidth as some might believe. These aren't real life forms, as such your model isn't bound by the same rules. Microsoft is actually from a market perspective WAAAAY more genetically diverse (it's spreading its market investment at an incredible rate) than any other software company out there. If anything, the slashdot people have figured it out: they are like the borg right now, assimilating any genetic makeup they can.

    His analogy is fucking broken.

    Fuck this shit, I've flipped the bozo bit on this guy...

    1. Re:Rant continued... by Anonymous Coward · · Score: 0

      I got the feeling he was referring to companies that run nothing but windows. I also got the feeling he was arguing for OSS. Have you noticed there are are two or three OSS implementations of everything?

      But maybe this is just me...

    2. Re:Rant continued... by kurosawdust · · Score: 4, Funny

      Bonus points for using the word "fuck" twice and "shit" once, but being thoughtful enough to ambiguously asterisk out the 'e' in "circle-jerk".

    3. Re:Rant continued... by Anonymous Coward · · Score: 0
      Ha ha =)

      You made me laugh a good one...

      If you notice though, it's because I started out the post with good intents, and by the end I was more or less fuming, and let the fuck shit go out uncensored.

      -pVoid

  20. Imagine that you are an alcoholic... by emil · · Score: 3, Interesting

    ...and that, after some real calamity in your life, you have decided to go cold turkey.

    Now, where would you rather go cold turkey? Locked in a liquor store, or locked somewhere free of alcohol?

    A C compiler is the liquor store of systems programming. It reinforces all the bad habits and rewards none of the good.

    C has no formal definition for exceptions (signals can't really count), it does not force good behavior in allocating memory/objects from the heap, the stdio library is slow because of multiple buffer copies (David Korn replaced it with sfio in ksh93), C is constantly beaten by Fortran in computation-intensive applications, Python has shown that C sylistically leaves much to be desired, and this is only the beginning of the criticism.

    I like C a lot too, but ultimately, there is no future in it beyond low-level applications that need to work at a near-assembler level.

    Can you really imagine C being used for systems work in 50 years?

    1. Re:Imagine that you are an alcoholic... by mekkab · · Score: 1

      Can you really imagine C being used for systems work in 50 years?


      Sadly, yes. And maybe thats only because I'm either ill-informed or unimaginative.

      Barring the low level stuff (Kernel stuff is de facto C, if not de jure), how else can you get performance? Ada is going the way of the Dodo (there are still a few huge legacy apps running around). Java can't take its place until a rock-solid JVM is common (is there one available?). There are far too many stories of applications running out of memory because the garbage collector never got around to working.

      --
      In the future, I would want to not be isolated from my friends in the Space Station.
    2. Re:Imagine that you are an alcoholic... by Halvard · · Score: 1

      Maybe your are ill-informed and maybe you aren't. Cobol and Fortran are still in heavy use. So is Basic. All have been declared dead before. As Bill Joy says in the interview, people don't necessarily recognize the economic value of something new and instead rely on an know, comfortable alternative (paraphrased, of course).

    3. Re:Imagine that you are an alcoholic... by gbjbaanb · · Score: 1

      interesting comment. Of course, Joy doesn;t seem to recognise the economic value of the current stuff that works, rather than the expensive rewrite if it in the current 'new best thing'. (which assumes that the rewrite works, and isn't just an expensive failure).

      Perhaps that's because he's juist talking up Java at the expense of everything else. Hands up if you've ever heard of a system rewritten in Java that failed atrociously.

    4. Re:Imagine that you are an alcoholic... by mekkab · · Score: 1

      From my understanding, Fortran has a heavy hold on scientific computing.

      As for Cobol- I'm UN-informed. I thought the majority of its place in the market was just legacy support? Mind you, legacy support is a multi-billion dollar industry (thats what we do now with ADA). So is there a lot of new development in Cobol?

      --
      In the future, I would want to not be isolated from my friends in the Space Station.
    5. Re:Imagine that you are an alcoholic... by dspeyer · · Score: 3, Informative
      There are intermediate steps between C and garbage collection. One I personally like is Cyclone which delivers almost all the power of C and the ability to link directly to C code. There are plans to write a kernel in it, and they look very credible.

      For user-land software, things like python are becoming very practical. Java is probably acceptable for daemons and such (so long as they're not massively performance critical) but isn't ready to be used for anything with a GUI or where startup time matters.

    6. Re:Imagine that you are an alcoholic... by emil · · Score: 2, Insightful

      Fortran is easier to optimize and vectorize than C, which is why it has a strong hold on scientific computing. Optimizers can assume a great deal about Fortran programs that cannot be assumed about C.

      Cobol is still alive and well in many business-oriented computing environments. There are Cobol programmers working in the office down the hall from me. New systems implementations in Cobol continue today.

    7. Re:Imagine that you are an alcoholic... by Anonymous Coward · · Score: 0

      But is that economic value of the existing stuff enough to counter the economic cost of continueing to add stuff on that is poorly written/designed thanks to the problems of the existing language (C)?

      All around us things either change with the times or get discarded. Buildings get additions / facelifts / new internal layouts, bridges get replaced / rebuilt with new stronger materials, etc. Yet we have this view that not only should old software never change, but that we should continue to develop new software with the old tools. This would be like the building trade ignoring the advances in metal and concrete and glass.

    8. Re:Imagine that you are an alcoholic... by Xabraxas · · Score: 1
      Cobol is still alive and well in many business-oriented computing environments. There are Cobol programmers working in the office down the hall from me. New systems implementations in Cobol continue today.

      Please tell me where. My mother is an out of work Cobol programmer. She can't find a job anywhere anymore.

      Cobol is as good as dead. The jobs left are pretty much legacy support. Maybe your case is a special one but for the most part it's dead. Learning to program Cobol now is like learning sanscrit. There's no use unless you're a historian.

      --
      Time makes more converts than reason
    9. Re:Imagine that you are an alcoholic... by Anonymous Coward · · Score: 0

      If C and C++ is so bad then why isn't Solaris written in Java? Why isn't Java written Java? Maybe Linux should dump C and use Java.


      Java is written in C and C++. That is an oxymoron. They criticize C and C++ but Java is essentially written in C and C++ not Java. There's problems with the Java garbage collector. On Oreilly.com they discuss secure C++ memory management. Java has bugs that are symptomatic of C++ memory mismanagement.


      A lot of open source programs are written in c.
      Java is not a system level programming language. There is no Sun Java native machine code compiler commercially available. Designing one would make the language have a broader audience. If Java is as good as they say it should have buried C and C++ long ago.


      Examples of secure C programs are qmail. So C can be secure with proper design.


      Sun is a disruptive company and doesn't know how to promote cooperation.

    10. Re:Imagine that you are an alcoholic... by ebyrob · · Score: 1

      Run away garbage collection is the problem of Java, just as fandango on core is the problem of C.

      Neither is perfect. They are certainly different.

      Both can be avoided, given painstaking control of memory life-cycles.

    11. Re:Imagine that you are an alcoholic... by Anonymous Coward · · Score: 0

      In a career fair I went to recently, there are more COBOL openings than C, C++, and Java combined. It is not dead, but don't ask me why it is not.

    12. Re:Imagine that you are an alcoholic... by rlowe69 · · Score: 2, Insightful

      Java ... isn't ready to be used for anything with a GUI or where startup time matters.

      This is a myth and it's been debunked so many times I stopped counting. Look at the Eclipse project -- the Win32 UI is native (written using SWT) and just as responsive as apps written in C++.

      --
      ----- rL
    13. Re:Imagine that you are an alcoholic... by alext · · Score: 2, Informative

      [Java] isn't ready to be used for anything with a GUI

      Better warn those C/C++ developers using Borland's C++BuilderX IDE.

      It's written in Java and uses Swing, just as JBuilder has for years.

    14. Re:Imagine that you are an alcoholic... by Anonymous Coward · · Score: 0

      Got any other examples besides that single one?

    15. Re:Imagine that you are an alcoholic... by superNag · · Score: 1

      Well, what about current Java IDEs, like Borland JBuilder 9? Userland software on current machines can be written in java an will run smoothly and Moore's curve will allow even lower level stuff to go to java (or Python, Ruby...)

      --

      no idea.

    16. Re:Imagine that you are an alcoholic... by samael · · Score: 1

      I work for a large financial institution. My brother works for another one. Both take 30-odd graduates on each year and start them off working in COBOL. Both do all of their mainframe work in COBOL.

    17. Re:Imagine that you are an alcoholic... by Darren+Winsper · · Score: 2, Insightful

      Java can't take Ada's place until the Real-Time extensions are mature enough. Currently, implementations are a bit thin on the ground and well enough tested to be entrusted with stuff that Ada is typically used for.

    18. Re:Imagine that you are an alcoholic... by Anonymous Coward · · Score: 0

      Can you really imagine C being used for systems work in 50 years?

      Sure. Can you name a replacement?

    19. Re:Imagine that you are an alcoholic... by Anonymous Coward · · Score: 0

      That's nifty. Now what is Java written in? Anyone? Anyone?

    20. Re:Imagine that you are an alcoholic... by Anonymous Coward · · Score: 0

      Maybe assembly language is the wave of the future, i.e. high level Intel and/or AMD syntax and conventions to such an extent that assembly becomes portable on most of the cpu's out there. Unlikely I suppose, but maybe it's a possibility. What if microprocessors get interchangeable microcode like the mainframes of before? How far away is C from assembly language anyway? Not much, but that's what makes it so powerful. The one thing that makes it more attractive than assembly (besides portability) is its terseness.

    21. Re:Imagine that you are an alcoholic... by alext · · Score: 1

      I'm sure you didn't mean that as a serious comment - it would betray serious misunderstanding of computing fundamentals otherwise.

    22. Re:Imagine that you are an alcoholic... by Nevyn · · Score: 1
      C has no formal definition for exceptions (signals can't really count)

      And exceptions are good, because...? Ahh yes, it's such a joy when I run a random python app. with input it didn't expect and get a screen full of exception traceback.

      No, really. If I'd said to people 10 years ago, ok so there's this great idea that everyone should use called the "invisible return value". Basically what happens is that after you write to an API I can happily add extra return values you have to handle, however they'll be no possible way for you to find out what they are from looking at the code (and with most APIs I won't even declare them, so it'll basically be impossible to find out). Even better, because everyone will do this even changing what my API calls might change what I can return, and even I won't know ... hahahha.

      There are ways to declare side affects of functions in C, so that you can do a group of operations and only check for it in a single place. For string APIs in C SafeStr, Vstr and glib all do this in different ways. However it is often much more readable/secure to not turn explicit return values into invisible ones (or at least to provide both, Vstr does this).

      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
    23. Re:Imagine that you are an alcoholic... by Anonymous Coward · · Score: 1, Interesting

      http://www.intellij.com/idea/
      http://usa.autodesk .com/adsk/servlet/index?siteID= 123112&id=2752581
      http://java.sun.com/products/jf c/tsc/sightings/S17 .html
      http://www.bea.com/framework.jsp?CNT=overvi ew.htm& FP=/content/products/workshop/

    24. Re:Imagine that you are an alcoholic... by Anonymous Coward · · Score: 0

      Python is not even close to comparable with C. This is like comparing a box car with an indy 500 car. C is the only high level programming language in which you can create native executables and therefore is the only modern systems language. If the Java folks would accept that the path forward is write once, compile anywhere, Java would be the #2 systems programming language. Python is just a glue language, and not even a good one considering the crazy tab syntax.

    25. Re:Imagine that you are an alcoholic... by rplacd · · Score: 1
      Both take 30-odd graduates on each year and start them off working in COBOL.

      What's the retention rate? 30+ employees a year for just financial programming seems a bit excessive (but then, I don't know that sector of the industry very well).

    26. Re:Imagine that you are an alcoholic... by forgotmypassword · · Score: 1

      That's only true for F77. F90/95 has pointers, structures, and all kinds of other things that make it just as slow as C.

      The difference in speed between C and Fortran today is due mostly to the highly optimized commercial math libraries that ship with the compilers.

      And Fortran is only used in science because of legacy code and old professors. New students learn C or C++ and then learn Fortran on the side when they have to maintain something. Most new projects are written in C/C++.

    27. Re:Imagine that you are an alcoholic... by Doomdark · · Score: 1
      For user-land software, things like python are becoming very practical. Java is probably acceptable for daemons and such (so long as they're not massively performance critical) but isn't ready to be used for anything with a GUI or where startup time matters.

      For user-land things, scripting languages like Python and TCL/TK (or preferably, Ruby) have been practical for quite a while now. GUIs are really not all that performance sensitive, at least when native GUI system is used by scripting language.

      But as to Java, your blanket statement seems pretty weird. Java is very nice for GUI programs, as well as for server-side programming, and I'm not sure why you'd even claim it is not.
      Startup time on the other hand really depends more on what app itself does when getting started, and only secondarily on how Java app (or rather, JVM it runs on) is deployed and started. But even with default startup, with all JITing, what really matters is how app itself is designed to startup, not so much on implementation language. If app does too much upfront processing, it's dog to start up.

      Biggest performance problem with java apps is that although developers know application development is significantly faster and easier than with "old school" languages like C or C++, they need to pay bit more attention to responsiveness, if they do anything 'advanced' with GUI (ie. do additional rendering, not just default components).

      But perhaps your perception is based on older JVMs, 1.2 for example was the slowest one in existence, with both bad startup and sustainable performance. But even back then it was possible to have Java apps that performance-wise (wrt GUI) weren't noticeable different from native apps (I know, I wrote couple).

      --
      I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
    28. Re:Imagine that you are an alcoholic... by samael · · Score: 1

      The IS department of my company is approximately 1100 people strong.

      Not all of those people are programmers admittedly, and about 20% of them are Java web developers. But there's still a lot of us about.

    29. Re:Imagine that you are an alcoholic... by Anonymous Coward · · Score: 0

      "Sadly, yes. And maybe thats only because I'm either ill-informed or unimaginative."

      Yeah, I only use Java because C isn't slow enough.

    30. Re:Imagine that you are an alcoholic... by Anonymous Coward · · Score: 0

      > Imagine that you are an alcoholic...

      Hey, why imagine? And yeah, Java is great!

      Seriously...

      > C has no formal definition for exceptions (signals > can't really count)

      Signals aren't part of the C standard, so you're right there.

      "the stdio library is slow because of multiple buffer copies"

      That's nothing to do with C - it's a library. You could write it in assembler if you liked.

      "C is constantly beaten by Fortran in computation-intensive applications"

      For a given compiler and source code, perhaps.

      "Python has shown that C sylistically leaves much to be desired, and this is only the beginning of the criticism."

      C can be readable in written in a stylistally pleasing way if you`re up to it.

      "Can you really imagine C being used for systems work in 50 years?"

      Yep. People will always want something fast and low level. If you wanted something safe, you`d just run it in a virtual machine. No, I don't mean JVM, I mean running C code in a virtual machine. Speed and safety.

    31. Re:Imagine that you are an alcoholic... by emil · · Score: 1
      Signals aren't part of the C standard, so you're right there.

      Signals are part of standard C. Check your K&R second edition, or the discussion in Advanced Programming in the UNIX Environment by W. Richard Stevens.

      stdio library is slow... That's nothing to do with C - it's a library. You could write it in assembler if you liked.

      The library is part of the C language specification. If some vendor decided to remove stdio and replace it with sfio, their implementation would no longer be ANSI-C compliant. The design of the standard is no longer appropriate for modern systems - C was built for PDP-11s with severe memory limitations.

      C can be readable in written in a stylistally pleasing way if you`re up to it.

      In Python, you must make use of a uniform style. You will never have to hunt for a bracket in Python.

      People will always want something fast and low level.

      C is an unreasonable trade-off between safe practices and low level access. Eventually, it will be replaced.

    32. Re:Imagine that you are an alcoholic... by Xabraxas · · Score: 1

      I have to call BS. My mother worked for a very large Insurance Company and they didn't have nearly that many people who knew COBOL. 30 a year is excessive for any company.

      --
      Time makes more converts than reason
    33. Re:Imagine that you are an alcoholic... by samael · · Score: 1

      Sigh, call what you like. 2003's graduate intake for IS was around 45 people. The usual spread is 50% mainframe development, 25% mainframe support, 25% Client/Server development.

      All of those people get taught COBOL as a starting point.

      The mainframe development people then get taught a lot more intensive COBOL stuff. The mainframe support people learn more about the mainframe systems. The Client/Server people learn Java.

      But all of us started off with COBOL training, because from time to time all of us need it.

      But the mainframe development people need it all the time.

  21. Java : C :: Emacs : vi by achurch · · Score: 4, Insightful

    Am I the only one getting tired of the "my language is better than your language" holy wars? Yes, Java can do some things by default that C can't, by default--buffer overflow checks, for example--but that doesn't make it necessarily "better". One could argue that Java's way of checking everything for you makes programmers lazy, and more likely to make mistakes that Java can't catch--cross-scripting holes, for example.

    In the end, an experienced C programmer can get the same job done with the same quality in C as an experienced Java program can in Java, and that ought to be good enough for anybody.

    1. Re:Java : C :: Emacs : vi by Corporal+Dan · · Score: 1

      Actually, Java is "better" than C. Java is type-safe while C is not. :-)

    2. Re:Java : C :: Emacs : vi by Anonymous Coward · · Score: 0

      cross-scripting happens in JavaScript, not Java.

      Repeat after me: JavaScript is not Java.

    3. Re:Java : C :: Emacs : vi by cerberusti · · Score: 1

      Any good C compiler will warn you (or force you to make an explicit cast) when you are doing something that may not be safe. The difference is that C ALLOWS the programmer to override this when they wish to. That is one of the reasons it is used for pretty much anything where speed is critical, it lets the programmer make the decisions, and does not attempt to second guess him/her. A bad C programmer can be pretty terrible but, a good one knows what is safe in the situation. Automatic memory management is also not nearly as efficient as a manual decision, the safety Java (and most higher level languages) gives comes at a high cost in system resources, and in many cases this is either not desirable or acceptable.

      --
      I'm a signature virus. Please copy me to your signature so I can replicate.
    4. Re:Java : C :: Emacs : vi by arkanes · · Score: 1
      The difference is (and don't get me wrong here, I'm not a Java fan) is that Java checks the validity of the cast at runtime, where as C just does whatever you tell it to. It's perfectly possible to do things what can cause horrendously bad problems with invalid casts in C. Of course, I haven't seen many Java programs that will explicitly trap and try to recover from a badCast exception, so whatever.

      C++ has both options.

    5. Re:Java : C :: Emacs : vi by Anonymous Coward · · Score: 0

      thats not really better. its only two different approaches. java takes most power/freedom and responsibility away while c leaves it to the programmer.

    6. Re:Java : C :: Emacs : vi by Molt · · Score: 1

      Correct, Javascript is not Java... however cross-site scripting is when the web application allows unchecked injection of Javascript etc. into the output thus allowing one user to run scripts on another users browser, and a whole related host of fun stuff..

      The problem here is with the web application, not with Javascript.

      The solution is to fix the web application so it doesn't trust user input blindly.

      The web application will be written in a language such as Java. The cross-site bug was introduced by a Java programmer.

      With the low-level knowledge a C programmer needs to get C to work it's unlikely they'll be as willing to trust user data blindly and so are less likely to have these issues.

      --
      404 Not Found: No such file or resource as '.sig'
    7. Re:Java : C :: Emacs : vi by jemfinch · · Score: 5, Insightful

      In the end, an experienced C programmer can get the same job done with the same quality in C as an experienced Java program can in Java, and that ought to be good enough for anybody.


      This simply isn't the case.

      Studies have shown (if you're interested, the relevant studies are referenced in "Code Complete" by Steve McConnell) that programmers are capable of writing approximately the same number of lines of code per unit of time in whatever language they program in. Whether it's C, Java, or Sparc Assembler, they'll write pretty much the same number of lines of code in day.

      The catch, however, is the expressivity of the languages used. A thousand lines of C will certainly "do more" than the same number of lines of Sparc assembler. Likewise (though arguably not on the same scale), a thousand lines of Java will certainly "do more" than the same number of lines of C. So disregarding errors for the moment, programmers are more productive in a higher level language like Java than they are in C or Sparc assembler.

      Now, as far as errors go: it's true that experienced programmers (in whatever language) will make fewer mistakes than less experienced programmers. But they're still human, and even if you're Donald Knuth himself, you're still going to make mistakes. The fact is that mistakes in C are far more costly than mistakes in Java. You can have off-by-one errors in both languages. In Java, however, your program will raise an out of bounds exception and, at worst, halt. In C, such a mistake could easily lead to a buffer overflow security flaw that can be exploited for elevated privilege. The same error in C and in Java is far more costly in C than in Java.

      With even higher level languages, entire classes of mistakes cannot even exist, but I don't have time to go into the advantages of such languages like SML or Haskell.

      Programmers no matter how experienced, are going to make mistakes. What matters is how costly those mistakes are. And they cost a whole lot more in C than in Java.

      Jeremy

      (P.S.: I'm a Python and SML fan, myself.)
    8. Re:Java : C :: Emacs : vi by Anonymous Coward · · Score: 0

      Now you're taking a people issue and trying to make it a language issue. Web applications (i.e. applications running on servers that use web browsers as clients) do not allow cross-site scripting bugs. It is the web browser (commonly a C or C++ program) that allows such holes.

      Having said that, I wouldn't accuse C programmers of 'having the problem' -- I would point the finger at bad design.

      If you're speaking of blindly trusting input data from any source, then that's an entirely different issue that also relates to poor design or naive programming, not languages.

    9. Re:Java : C :: Emacs : vi by aschlemm · · Score: 1

      The on thing I've never liked with Java through is that if you know what class implements an interface that is given to you , you can cast the interface back to the implementing class. I guess I'm too much of purist as this allows abstraction to be thrown into the toilet IMHO.

    10. Re:Java : C :: Emacs : vi by Hamhock · · Score: 1

      I think the point that Joy is making, is only helped by your statement. You qualify your statement with 'an experienced C programmer....' Well, not all poplular software is written by experienced programmers. Lots of stuff is written by inexperienced programmers, and always will be. And lots of programmers are lazy as all hell. If a language has a built in way to deal with the programmers inexperience/laziness, then that's a good thing.

      --
      Two Minus Three Equals Negative Fun -Troy McClure
    11. Re:Java : C :: Emacs : vi by Anonymous Coward · · Score: 0

      And fortunately, we appear to be hamstrung with more bad C programmers then good ones. Further, C will often increase the number of lines of code, thereby increasing the complexity of the program text, making it more difficult to judge where problems may be.

      With that said, I strongly prefer C for systems programming, because much of the required complexity seen at the higher level is not there in the lower levels.

    12. Re:Java : C :: Emacs : vi by Mybrid · · Score: 1

      Hi!
      Disclaimer, what follows is my opinion and experience.

      Large scale C - Java projects that I've worked on (240 files, 100,000 lines) for a company I contract for yields 5-20% more lines of code when converting Web apps from scatch from C to Java. Mostly because of the framework stuff they imposed on Java.

      Java is not high level even in design. It is basically C++ stripped down. That makes it less high-level than C++. Some people claim its high level because of all the available libraries. I don't see it in practice.

      PERL on the other hand is high level. A five line PERL script can easily turn into a 100 line C program.

      Again, empirical evidence at a large company shows otherwise with regards to bugs. Our bug tracking system has yielded no report that says the severity or frequency of bugs in Java are more or less than C.

      The number one bug error in Java? Null reference exception. We also have huge memory leaks. In fact, we have more memory leak issues in Java because they are irrelevant in C so we turned off "free" in C. For web programming, C HTTP requests are short lived so we don't bother with freeing any memory. Leaked C memory is around for less than a second, who cares? Web Application Java servlets are long lived and susceptible to memory leaks.

      One could argue that the more lines of Java code should yield more bugs for Java. However, our mission critical apps are written in C so it may be that our Java bugs are not getting reported by customers because they don't care.

      My experience has been that the Java claim of less bugs because of no NULL pointers and no memory leaks is hogwash. Yeah, there are no array bounds errors in Java but if one uses Strings in C++ one can get the same benefit.

      Garbage collection in the JVM is a big disaster costwise. It is really a challenge to tune and benchmark garbabe collection behavior. Performance is not linear, but shows elbows in the curve because the memory allocation failure and swapping starts happening much above 50% sustained CPU utilization.

      Cheers!
      -Mybrid

    13. Re:Java : C :: Emacs : vi by Anonymous Coward · · Score: 0
      a thousand lines of Java will certainly "do more" than the same number of lines of C.
      I think that's a flawed assumption.

      Not every line of C code is going to be some ultra-complex pointer-walking array sort. Not every C function is going to do a malloc, check the return value, do some copies and memmoves()s. You can do object-orientation in C (even without C++) and you can layer on different levels and abstractions just the same way as Java does.

      I think definitely one thing coding in C has allowed me to do is find or create common areas of code and abstract them away to short function calls. With C, it's easy to write redundant code, so it kind of forces you to use such abstractions.
    14. Re:Java : C :: Emacs : vi by TwistedGreen · · Score: 1

      You're definitely not alone. It seems rather childish really, to have a "strong dislike" for something like a programming language. This isn't politics, it's computer science. You can do the same thing in one language that you can in any other.

      Oh well, I guess that's what makes people so interesting. The plethora of personalities. Doesn't mean he's right, though.

    15. Re:Java : C :: Emacs : vi by Darren+Winsper · · Score: 1

      Well, Java has to allow that since it doesn't support generics (at the moment). Otherwise, you'd only be able to get Object instances from the data structures and wouldn't be able to do anything useful with them. There's also the problem that designing software that doesn't cast to the extending/implementing class is very difficult.

    16. Re:Java : C :: Emacs : vi by Anonymous Coward · · Score: 0

      You might want to actually read the references cited before you refer to the argument as a "flawed assumption."

    17. Re:Java : C :: Emacs : vi by Darren+Winsper · · Score: 1

      I feel that the problem is that people try to write inappropriate things in C. Unless you absolutely need to have very high performance and you must keep memory usage down, there's little need to use low level languages for desktop applications. Take Something like an instant messenger client. Since they rarely do anything CPU or IO intensive, they wouldn't feel slow if they were written in Python, C# or Java.

    18. Re:Java : C :: Emacs : vi by Darren+Winsper · · Score: 1

      I'm not sure how you'd have memory leaks in Java, since it's a garbage collected language. You claim it's a joke, but if you find leaving the garbage collector to do its own thing isn't working for you, you can call it explicetly. If you have a place where you drop a lot of objects for whatever reason, you can always tell the garbage collector to run then instead of letting things build up. I was recently writing a .Net library and ran into a similar problem to what you were describing, my solution was to run the garbage collector after processing an arbitrary number of files. It pretty much eliminated swapping and barely affected performance (when swapping's not taken into account) at all.

    19. Re:Java : C :: Emacs : vi by davesag · · Score: 1
      I have never written any C or C++, as I went straight from BASIC and APL (woohoo APL, those little upside down triangles!) in high school to Pascal to ADA to Modula2 at University. I dropped out of uni when they said I had to learn fortran and cobol, and to be honest my knowledge of SQL is pretty damn limited (hooray for Hibernate). But i reallly got hooked on 68000 assembler, having been a 6502 geek for years, and I loved the raw thrill of coding in languages like RDL and then using 4D to do web-fronted CMS on my mac (pre PowerPC btw). And in 1996 I was shown Java. I went to JavaOne. I've been a Java coder ever since. (And Jini reallly is cool, no question about it).

      So tell me, is there an equivalent for JUnit in C? Is there a package like Hibernate? Is there introspection and reflection and casting and interfaces? As a Java programmer I can concentrate more on the design of my code, and working out what not to write. That's why I like it. Cos yes, I am a lazy programmer. If I wanted to work hard I'd still be coding in assembly language.

      --
      I used to have a better sig than this, but I got tired of it
    20. Re:Java : C :: Emacs : vi by Raffaello · · Score: 4, Interesting

      The whole Turing completeness argument is a straw man. If it were really true, we'd all still be coding individual 1s and 0s, since, after all, "You can do the same thing in one language that you can in any other."

      The real issue is which language is more expressive. Since I can accomplish any task with any of the dozens of Turing complete languages, which language lets me accomplish the task at hand in the fewest lines of code?

      The answer may vary from task to task, but if the task includes the requirement that the finished product be secure, then C loses, because it doesn't protect against one of the most common sorts of attack at the language level, buffer overruns. Common Lisp and Java do. To have this same sort of protection in C, I'd have to write all the additional lines necessary to implement my own runtime to prevent direct access to memory. Hey! I've just re-implemented *part* of Common Lisp, or *part* of Java.

      Thus we come to Greenspun's 10th law of programming:

      "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

      You wrote:
      "Oh well, I guess that's what makes people so interesting. The plethora of personalities. Doesn't mean he's right, though."
      Bill Joy's opinion that C is a really dangerous language isn't a quirk of his personality. It's an evaluation based on decades of experience as a pioneer in the computer industry, and a deep understanding of the fact that different languages really are better or worse.

    21. Re:Java : C :: Emacs : vi by SewersOfRivendell · · Score: 2, Insightful
      You are missing the point. It's not a matter of dislike. Preference doesn't enter into it. Buffer overflows are a fact of life in C. Anytime you have unchecked array access, you're going to have that problem.

      That doesn't make C an awful, bad language, necessarily, but to it does imply that too many programs are written in C that would be better written in say, Python, or Ruby. If you're not in the kernel or doing something truly performance-sensitive like A/V work, you really shouldn't be using C. If you want other people to use your programs, it's your responsibility to write them as safely as possible.

      Mind you, the language is only part of the security problem -- and a small part, at that. But programming defensively has to start somewhere, and it might as well start by eliminating an entire class of bugs by using an appropriately safe language.

    22. Re:Java : C :: Emacs : vi by Anonymous Coward · · Score: 0
      Okay, I don't have the time to find "Code Complete", but the post said:
      ... programmers are capable of writing approximately the same number of lines of code per unit of time in whatever language they program in.
      And that was the part that cited "Code Complete".

      Then, independently, he went on to say:
      a thousand lines of Java will certainly "do more" than the same number of lines of C.
      This seems to me like an inferrence, not necessarily made based upon any "supporting" material. Therefore, I call it an assumption.
    23. Re:Java : C :: Emacs : vi by alext · · Score: 1

      Java can do some things by default that C can't, by default--buffer overflow checks, for example--but that doesn't make it necessarily "better".

      Strange as it may seem, it does.

      Of course, I should immediately qualify this assertion by adding "in the context of implementing general-purpose business information systems", but I doubt if that will be too far from the territory of most of the /. audience.

      The reason is simple. While I can build a system that doesn't suffer from buffer overflows in C, the only way I can guarantee this is by looking through the code - a code audit, in security parlance. In Java, I know up front that there are no such vulnerabilities. With lots of lines of code to check, this guarantee is worth a lot of money, and is therefore clearly and demonstrably better for this (very broad) class of applications.

      Similar reasoning can be applied to other intrinsic features of Java as discussed elsewhere, - trusted code, portability guarantees, GC etc.

    24. Re:Java : C :: Emacs : vi by Mybrid · · Score: 1

      Memory leaks in Java:
      1.) Program gets in a long loop accidentally allocating lots of spurious memory. The erroneous loop condition was rare and didn't happen under test conditions but did in production. Yes memory would get garbage collected but the rate of allocation defeated the garbage collection algorithm and thus manifested as a leak. The leak eventually exhausted all memory up to the maximum heap size.
      2.) Debug data appended to a static class variable that grew unbounded. Accidentally made it into production.
      3.) JVM itself grows (memory leak in the JVM).
      4.) Same class in two different jar files was accepted by the JVM and the bug manifested as a huge memory leak.

      Note that none of these are relevant in a C/CGI app the lives less then one second fullfilling a single request. I think a lot of people are mistakenly under the impression that all memory leaks are solely a product of dangling memory references because unused unreferenced-memory is not freed.

      The fastest garbage collector is a disabled one. Wasted memory is never collected. You can simulate this in C by disabling free. Obviously this is only viable if your program is short lived. A garbage collection model always assumes long running processes.

      There are many ways to defeat garbage collection. The easiest is for a A to refence B and B to reference A although I've never actually seen that one yet in production.

    25. Re:Java : C :: Emacs : vi by Nevyn · · Score: 1
      Now, as far as errors go: it's true that experienced programmers (in whatever language) will make fewer mistakes than less experienced programmers. But they're still human, and even if you're Donald Knuth himself, you're still going to make mistakes. The fact is that mistakes in C are far more costly than mistakes in Java. You can have off-by-one errors in both languages. In Java, however, your program will raise an out of bounds exception and, at worst, halt. In C, such a mistake could easily lead to a buffer overflow security flaw that can be exploited for elevated privilege. The same error in C and in Java is far more costly in C than in Java.

      This isn't true, you can pick any of a number of string ADTs in C that make these errors exactly the same cost as in Java ... and there are probably cases where you'd pick different implementations from the above. In fact I'd argue that the mental brain fart that caused Gosling to put threads into Java as a primitive operation is a far bigger problem, and a bigger source of bugs. Good experienced C programmers use a dynamic string API designed for the job and no threads, that combination happens even less often in the Java world that the C one.

      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
    26. Re:Java : C :: Emacs : vi by ggruschow · · Score: 1
      This simply isn't the case.

      Studies have shown [...] programmers are capable of writing approximately the same number of lines of code per unit of time in whatever language they program in.

      I don't think you fully read what you were arguing against.

      The studies you referred to showed the LOC/day is the same independent of language, not the quality of a program. Although you argued that Java requires fewer LOC to do the same task, that's certainly not always the case. Even if it were the case, you didn't establish that fewer LOC in Java equates to higher "quality".

      I believe the gist of what the original poster said is true: A good programmer could probaly write the same quality program in C or Java. How long it takes them, the performance of the program, and the maintainability of the program are different matters altogether.

    27. Re:Java : C :: Emacs : vi by Nevyn · · Score: 1
      I'm not sure how you'd have memory leaks in Java, since it's a garbage collected language.

      GC isn't magic ... or at least no implementation I know of does full lifetime analysis of every object. They just follow the references, and if they can reach an object they assume it's still being used (even if it'd obvious to a human you'll never use it again).

      This basically changes the "free" operation from an explicit "free(ptr);" to "ptr = NULL;". There are times when this helps, but there are also times when it doesn't (for instance when the memory is tied to some other resource like an open file/socket) ... and ignoring that you still have to free things implicitly will produce worse results.

      And that isn't even mentioning languages like perl/pythong/etc. where the GC is just reference counting ... and so reference loops will cuase leaks.

      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
    28. Re:Java : C :: Emacs : vi by Nevyn · · Score: 1
      So tell me, is there an equivalent for JUnit in C?

      JUnit is just a testing framework ... it's writing the tests that's the hard bit. I've found automake's "make check" more than sufficient.

      Is there a package like Hibernate?

      Can you save objects/data to long term storage ... Err Duh! Can you automatically serialize your data, sure ... but not without some extra costs.

      Is there introspection and reflection and casting and interfaces?

      Most of these are "free" with C, however for something more formal Glib's object model provides that ... along with a serialize interface (glib isn't the only thing to do that but it is everywhere and free).

      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
    29. Re:Java : C :: Emacs : vi by Nevyn · · Score: 1
      The reason is simple. While I can build a system that doesn't suffer from buffer overflows in C, the only way I can guarantee this is by looking through the code - a code audit, in security parlance.

      Again, this isn't true. You don't need to audit all of the code ... if all of the code uses a dynamic string API, then you only need to make sure the API can't cuase problems. And as with Java where only need to know that the overflow checks work, a good implementation will come with tests to more or less prove that this is the case.

      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
    30. Re:Java : C :: Emacs : vi by Ambassador+Kosh · · Score: 1

      That is wrong. Python has a cyclic GC system in addition to reference counts. The reference count system is just a lot simpler overall and a good deal faster and more predictable then a lot of other GC systems are. So use the simplest system for the most common case and have another system to have other kinds of cases.

      I have not found any way to create a leak in python so far and have been doing it for years however I have made a mistake that caused it to allocate enough memory that the linux OOM system killed it. I kept increasing the size of a list I was iterating over so it could never stop iterating. However I don't think that is a memory leak and it was trivial to fix.

      --
      Computer modeling for biotech drug manufacturing is HARD! :)
    31. Re:Java : C :: Emacs : vi by axxackall · · Score: 1
      A thousand lines of C will certainly "do more" than the same number of lines of Sparc assembler. Likewise (though arguably not on the same scale), a thousand lines of Java will certainly "do more" than the same number of lines of C.

      Why do you stop? Keep going:

      A thousand lines of Python will certainly "do more" than the same number of lines of Java. Likewise (though arguably not on the same scale), a thousand lines of Lisp will certainly "do more" than the same number of lines of Python.

      With even higher level languages, entire classes of mistakes cannot even exist, but I don't have time to go into the advantages of such languages like SML or Haskell.

      Ok, let's just put ML and Haskell right next to Python and Lisp in the thousand line formula above :)

      Programmers no matter how experienced, are going to make mistakes. What matters is how costly those mistakes are. And they cost a whole lot more in C than in Java.

      The cost in a well orginized process is majorly defined by amount of debugging. Two thing worth to mention:

      1. the amount of low-level mistakes is lower in a higher-level programming language due to... well there is no low-level programming there :)
      2. the refactoryng of a high-level language coded program is faster than of a low-level one;
      But all this logic doesn't work in real life, where most of corporate decisions are based on a marketing bullshit, rather than on real benefits. That's why Java is everywhere, especially in placases where it's not supposed to be from the first place: network server-side applications and GUI.
      --

      Less is more !
    32. Re:Java : C :: Emacs : vi by newbiescum · · Score: 1
      There are many ways to defeat garbage collection. The easiest is for a A to refence B and B to reference A although I've never actually seen that one yet in production.
      The reason you haven't seen it is because if you know anything about the basics of Java's garbage collection algorithms, you have to come up with a much more complex situation than this to "defeat garbage collection". Many programs have circular references, but due to the way that the garbage collector works, this is not a problem.

      I also disagree with your definition of a memory leak for #1 and #2 in your examples. Both are just bugs that also happen to have the side-effect of exhausting memory. I'm not saying that there aren't memory leaks in Java as JVMs leaking memory is a valid example IMO, but if my program got stuck in a while loop and kept appending data to a data structure without terminating, I would consider that to be a bug in the exit conditions, not a memory leak.

    33. Re:Java : C :: Emacs : vi by davesag · · Score: 1

      I'll take your word on "make check".

      Hibernate is much more than just serialisation and persistance of data objects. Is there a C equiv with a rich query language that lets me avoid any use of SQL?

      How does C provide interfaces?

      dave

      --
      I used to have a better sig than this, but I got tired of it
    34. Re:Java : C :: Emacs : vi by Anonymous Coward · · Score: 0

      Am I the only one getting tired of the "my language is better than your language" holy wars?

      Yes, you are.

    35. Re:Java : C :: Emacs : vi by Anonymous Coward · · Score: 0

      Am I the only one getting tired of the "my language is better than your language" holy wars?

      No!!

    36. Re:Java : C :: Emacs : vi by Mybrid · · Score: 1

      Yahoo! Definitions. Database, memory leak. If a bug results in a memory leak its not a memory leak? If a developer forgets to call free on an a pointer is that a bug? Seems like you are being silly. I know this, our business partners share the same opinion that these are memory leaks. Allocating memory in away that trumps garbage collection is something IBM takes serious enough to try and fix. I also disagree with your understanding of Java garbage collection. You are just flat out wrong. A referencing B which references A will defeat a Java's garbage collection. This kind of silliness is why Java needs to be debunked. It's not C vs. Java. It's the miss-understandings of Java. Most of the claims about Java and Web application servers are over-rated and flat out unproven. I see this kind of erroneous thinking all the time with database optimizers where people simply think that deadlock detection is always detectable when in fact it's provably an intractable problem. Garbage collection is analagous to deadlock detection in its intractablity. I suggest you take a theory class or pick up a theory book. No garbage collection algorithm can guarantee 100% detection.

    37. Re:Java : C :: Emacs : vi by Darren+Winsper · · Score: 1

      Tracing algorythms defeat the circular reference problem. Check out http://www.javaworld.com/javaworld/jw-08-1996/jw-0 8-gc.html for information on Java's garbage collection system.

    38. Re:Java : C :: Emacs : vi by Darren+Winsper · · Score: 1

      1) If the allocated memory is still referenced by reachable code, then of course it can't be garbage collected. Of course, this problem is just as likely to occur in C, so using a non-garbage-collected language doesn't have an advantage here.

      2) This is no worse than the same problem using C. Of course, that's a bug in your program and not a bug related to garbage collection. It's also not a memory leak, at least not according to the jargon file, since it's not discarded memory.

      3) That's like saying C is buggy because the m88k backend of GCC doesn't work properly.

      4) That's an obscure bug and not really related to memory leaks, since it's not programatic but runtime based.

    39. Re:Java : C :: Emacs : vi by achurch · · Score: 1

      Studies have shown [...] that programmers are capable of writing approximately the same number of lines of code per unit of time in whatever language they program in.

      I intentionally never said anything about how long it would take. (On reflection, I should have explicitly noted that.) Yes, it takes longer to write a program in assembler than in C, for example, and longer in C than in Python. That in and of itself does not affect the quality of the end product; I've seen some really horrible Perl code, and some really clean C code. For some projects, or parts of projects, the efficiency gained by using C (or even assembler) may be worth the extra time it takes.

      Programmers no matter how experienced, are going to make mistakes. What matters is how costly those mistakes are. And they cost a whole lot more in C than in Java.

      This is true, but smart programmers will be aware of those pitfalls and code around them. Someone (can't recall the URL) put together an entire string library for C that uses dynamic allocation, which would avoid probably 99% of buffer overflow errors.

      In the end, it's a matter of choosing the right language for the task. If you need it done fast, use Python, Perl, or whatnot; if you're doing stuff with lists, use Lisp; if you need efficiency, use C or assembler; and so on. Hell, use all of them together. I'm not advocating that everybody should use their favorite language for everything they write; I'm simply trying to put an end to the language holy wars. (Okay, okay, an impossible task, but...)

    40. Re:Java : C :: Emacs : vi by CharlesEGrant · · Score: 1

      I don't think the argument here is either politics or computer science, I think it is how to turn computer programming into an engineering discipline. Every C/C++ programmer swears they will carefully attend to memory management and buffer bounds, and nearly every one of them will screw it up multiple times. Witness the numerous overflow bugs in OpenSSh and Sendmail, not to mention the Microsoft overflow bugs de jour. It's not that run time checking will prevent such errors, it's that when they occur (and they will), the program will fail in a predictable way and not execute arbitrary code.

      The argument between supporters of "bondage and discipline" and "do what I say" languages has been going on since the birth of the industry. The "do what I say" languages have so far carried the day because they have had legitmate arguments about performance constraints, but isn't it time to devote a least some machine cycles to run time checking of the most common classes of programmer errors?

      A relative of mine works in the aircraft industry. According to stories he has told me, it is required practice that all cables in a cable bundle have incompatible connectors. Obviously this is inefficient, expensive and tedious, but harsh experience has taught them that if a cable can be physically plugged into the wrong socket, it will be. Even the best programmers will occasionialy make mistakes and our software tools should accept this as a given.

    41. Re:Java : C :: Emacs : vi by Stu+Charlton · · Score: 1

      "Java is not high level even in design. It is basically C++ stripped down. That makes it less high-level than C++."

      That's a stunning feat of illogic. Every move to a high level strips out some features of the lower level.

      The number one bug error in Java? Null reference exception.

      That would imply quite a few segmentation faults in C.

      For web programming, C HTTP requests are short lived so we don't bother with freeing any memory. Leaked C memory is around for less than a second, who cares?

      Words fail me. Memory leaks are very important for most systems. How can you suggest an extremely narrow case (forked C processes) is applicable to a general case?

      My experience has been that the Java claim of less bugs because of no NULL pointers and no memory leaks is hogwash. Yeah, there are no array bounds errors in Java but if one uses Strings in C++ one can get the same benefit.

      Memory leaks in Java are a result of improperly letting go of objects.

      In a web-based stateless system written in Java , there is very little chance of memory leaks, just like in your C application, unless you're stuffing a whole ton of useless objects into your ServletContext or HttpSession.

      NULL pointer exceptions in Java are a result of improperly NULLifying your instance variables or by using fields that haven't been initialized yet.

      So, in summary, you're writing code that uses uninitialized variables and simultaneously stuffs every object in sight into a static variable or HttpSession.

      Again, words fail me. You do realize that while Java is a lot easier to manage memory than C, it still requires someone to apply a mild amount of *thought* behind what they're doing?

      Garbage collection in the JVM is a big disaster costwise. It is really a challenge to tune and benchmark garbabe collection behavior. Performance is not linear, but shows elbows in the curve because the memory allocation failure and swapping starts happening much above 50% sustained CPU utilization.

      Optimizing GC is not a very difficult challenge on modern virtual machines (v1.3-v1.4) because manual GC is no longer required. Analyzing GC occurences can be done easily wtih -verbose:gc, and there are many options for tuning thresholds.

      You have much bigger problems than GC optimization if you're swapping memory: you don't even understand how to set a maximum heap size.

      Again, words fail me. In my career, I don't think I've seen so much incompetence packed into a single message. Please consider a different career.

      --
      -Stu
    42. Re:Java : C :: Emacs : vi by Anonymous Coward · · Score: 0
      Even if it were the case, you didn't establish that fewer LOC in Java equates to higher "quality".

      It is the case, just look up the software studies. You'll find that for the same task, Java programs have an average of 3 times less bugs.

      A good programmer could probaly write the same quality program in C or Java.

      This makes no sense. A language in which you have 1000 pitfalls, isn't going to let you have the same amount of bugs as a language in which you have 100 pitfalls. What are the advantages of C over Java when it comes to code quality? None. This translates in bug counts, of course.

    43. Re:Java : C :: Emacs : vi by Molt · · Score: 1

      No, it isn't the browser that allows such holes, it's the web application.

      If Slashdot didn't filter out Javascript in people's comments, and someone appended their post with a quick Javascript fragment to redirect to Goatse then it'd be Slash that was at fault for mindlessly displaying the text another user had entered and not the browser for happily allowing it in a textarea.

      It seems Apache agrees with this view here by pointing out that 'The most serious issue [with regards to CSS attacks] is in all the site specific code that generates dynamic content.'

      --
      404 Not Found: No such file or resource as '.sig'
  22. This sounds sensible... by infydime · · Score: 2, Interesting

    "What is the actual cost of greenhouse gases, for instance? If you create a marketplace mechanism to solve that problem, you will probably end up creating wealth, and people would stop doing the stupid things they do now because it doesn't cost them anything. The Soviet Union collapsed not because of communism or central planning, but because of corrupt accounting. They couldn't organize the means of production because everybody was lying about everything. It was a game of fake numbers, and when you do that, you get crap for answers. " An interesting way of looking at ways to control pollution. Only if the motor companies actually allow it.

  23. Classic Bill Joy by Timesprout · · Score: 4, Insightful

    Some wonderful conceptualisations and insights into technology closely followed by statements that make you wonder if Bill is actually in the same universe as us, nevermind on the same planet.

    Anyway thanks for Java, its a fantastic development language, please stop telling us we are going to have/need JINI in every toaster, lightfitting and piece of cutlery we own and best of luck for the future.

    --
    Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
    What truth?
    There is no dupe
  24. Inefficiency by Detritus · · Score: 2, Interesting
    For decades, "inefficiency" has been the excuse that programmers have used to justify a multitude of sins. Now that computers are thousands of times faster, it is still used to justify unsafe design and implementation decisions. Improvements in compiler technology have reduced the speed penalty for error checking, but that hasn't stopped people from implementing new systems in unsafe languages.

    Don't tell me that leet programmers don't make those stupid mistakes, only idiots. Even if you are God's gift to software engineering, that doesn't change the fact that most programmers are not that good, and time and schedule pressures often make things worse.

    --
    Mea navis aericumbens anguillis abundat
    1. Re:Inefficiency by evilviper · · Score: 1
      Don't tell me that leet programmers don't make those stupid mistakes, only idiots.

      I never said anything that even remotely resmbled that... I don't know who you think you are arguing with here.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    2. Re:Inefficiency by Detritus · · Score: 1

      It wasn't directed at you, it was a preemptive response to the common argument that the problem isn't the tool, it's the craftsman. Don't take it personally.

      --
      Mea navis aericumbens anguillis abundat
  25. vi by eap · · Score: 4, Funny

    One of the other tasks the article metions Joy working on is a long awaited rewrite of vi to include a slick Java Swing GUI interface and the migration away from moded operation to Ctrl key sequences.

    According to Joy, "The Control key wasn't available when I wrote vi in the 70's. Back then it was the cent symbol key (you know, that little "c" with the line through it?). So we had to go with this kludgy insert mode thing that just, well, rather sucks."

    1. Re:vi by Anonymous Coward · · Score: 0

      a new text editor? wow, that'll end hunger and bring about world peace.

      I think he's still living in the 70s.

    2. Re:vi by Anonymous Coward · · Score: 0
      a new text editor? wow, that'll end hunger and bring about world peace. I think he's still living in the 70s.

      Let's see... how did we say it back then? Oh yes:

      *Plonk*

    3. Re:vi by damacer · · Score: 2, Funny

      So...he's going to be writing a Java based version of emacs? Cool!

  26. Bill Joy Outsourced To India by Baldrson · · Score: 4, Funny

    I think they are just side-stepping the real news which is that Sun outsourced Bill Joy. The new Bill Joy is working for 1/10 the rate and lives in Punjab.

    1. Re:Bill Joy Outsourced To India by kurosawdust · · Score: 1

      I wonder if people will describe the outsourcing trend by taking a cue from the allegedly cute US-to-India film industry comparisons and using the phrase "Silicon Bali"...

    2. Re:Bill Joy Outsourced To India by Anonymous Coward · · Score: 0

      Bali is in Indonesia.

      Nice try but no cigar.

    3. Re:Bill Joy Outsourced To India by Anonymous Coward · · Score: 0

      Not only that, he's stopped wearing clothes, grown a long white beard that covers his private parts, and spends his time banging out code and meditating with the Maharishi Mahesh Yogi.

    4. Re:Bill Joy Outsourced To India by Anonymous Coward · · Score: 0

      It was a reference to the Indian film industry being known as "Baliwood", i believe.

    5. Re:Bill Joy Outsourced To India by Anonymous Coward · · Score: 0

      Its Bollywood, dumbass.

    6. Re:Bill Joy Outsourced To India by Anonymous Coward · · Score: 0

      "film industry comparisons and using the phrase "Silicon Bali"... "

      I'd have thought "Shrapnal Bali" would be a better name.

  27. climb aboard by tabby · · Score: 1

    Am I the only one who reads these stories about CEOs and thinks "climb aboard the Spruce Moose"?

    --
    I've experiments to run, there is research to be done on the people who are still alive.
  28. Ya. Right. by Anonymous Coward · · Score: 0

    I don't need automatic garbage collection. I
    don't write garbage code. What Java software
    enabled you to make your post? Your browser
    is written in "C" (C++). Your OS is written in
    "C". Your word processor is written in C. Etc.
    C'mon, the only written in Java is the backend
    to slow webpages.

    Hell, Java's probably written in "C". I haven't
    bothered to look.

    Everyone likes to dis "C" and if you've got
    several billion dollars and a job title like
    "Chief Technology Wazoo" or whatever I guess
    you can implement an alternative.

    Joy's ego is behind Java, pure and simple.
    It *is* an elegrant language, no doubt.
    The replacement for "C". Bzzzzt. Wrong.

    C will live for a long time because it is the
    lingua franca of computers. Even with a few
    warts and buffer overflows.

  29. He does raise some good points, then again... by MoogMan · · Score: 1

    Im going to pick holes, because some of the things mentioned in the interview are frankly ludicrous:

    It may seem like a big effort to write programs several times, but not if you do it in a modular way

    The logic is there, but not the business thinking. Do you really think that many companies will write say three different versions of a piece of software for stability if they can concentrate the resources on one larger version with more functionality? Most users are more concerned with features, and have started to take rebooting as "part of using a computer".

    You can't simply write a new, multimillion-line program in C and expect it to be reliable unless you're willing to work on it for 20 years.

    This problem is NOT fixed to any programming language. ANY large project will have problems with maintanance unless it is held together with a good project management package.

    Another reason spam is so bad is that so many companies use Microsoft Outlook for reading e-mail.

    Arguably so, but this is not where the my rant lies...

    Again, because that program is written in C, it's quite easy to design a virus to go through your e-mail address book and broadcast spam to all the people you know.

    We can see that this bloke has a serious issue with C. Problems like this do NOT originate from the programming language. Is he really saying that if the program was made in Java, an executable attachment would not be able to run and iterate through the address book?

    (As a sidenote, I believe that the majority of viruses are ONLY due to misinformed users. Dont open executable attachments and you're safe. Just like riding a car is potentially dangerous, as long as you know what you're doing you've got a large degree of safety)

    If he is willing to disregard everything that has been done in C then it is him who is the problem. The majority of people *do* use C, and C does have its uses. automatic boundary checking and other niceties of Java is just too slow. Java has its uses, although I dont have that much experience in the language so maybe others can shed light on specific areas where Java excels.

    You cant help but think that this guy's mind has been accustomed to using Java above all else. This is blatantly wrong. Java has its purposes, as do many other languages.

    I hope this is seen as a warning to people who get too attached to one programming language/operating system/whatever rather than random abuse...

    1. Re:He does raise some good points, then again... by Anonymous Coward · · Score: 0

      We can see that this bloke has a serious issue with C. Problems like this do NOT originate from the programming language. Is he really saying that if the program was made in Java, an executable attachment would not be able to run and iterate through the address book?
      no, but untrusted code would not be able to exit the sandbox - and hence connect to a remote server to actually send the emails.

    2. Re:He does raise some good points, then again... by Nekhlyudov · · Score: 1

      This problem is NOT fixed to any programming language. ANY large project will have problems with maintanance unless it is held together with a good project management package.

      The largeness/complexity of a project can be mitigated to a large extent by using tools that are designed to perform the tasks at hand requiring less verbose expression (eg: using RAD tools such as Glade) to develop user interfaces instead of writing C code for them by hand. So, in that sense, the tools make a big difference.

      C does have its uses, developing huge applications is not one of the ones that it is well suited to, however.

    3. Re:He does raise some good points, then again... by jilles · · Score: 1

      > This problem is NOT fixed to any programming language. ANY large project will have problems with maintanance unless it is held together with a good project management package.

      Actually it is. Programming languages like Java allow for scalability of the development. I'd rather maintain 20 million lines of Java than 20 million lines of C. With C you'd be fixing stuff most of the time that is handled by the JVM for you. This allows you to focus on other stuff (e.g. adding features, otimizing stuff). Of course technology doesn't address the more general engineering issues that surface when you put more manpower on a project. That's the terrain of software engineering research.

      C has an enormous legacy, which is why C programmers will be in demand for some decades to come. However if you look at the trends in industry you will see it is moving to higher level languages away from C. C++ is increasingly the language of choice for embedded software stuff for instance. Even Java is making inroads in this once exclusive C domain.

      For people in (some parts of) industry Java is still something new. For people like Bill Joy, Java was something he did 15 years ago. He has moved on. I can understand this guys frustration watching everybody (including his colleagues at SUN) run into the same wall for decades. The technical solution to memoryleaks is decades old. All he is saying is that most of the current security problems are the result of a technical problem he helped fix in the early nineties.

      BTW. your comments on Java performance may be not so accurate. You seem to be blaming features that are not really an issue any more and not blaming other features that are definately still problematic from the point of view performance. This suggests that your experience in this area is 'limited' (to put it politely).

      --

      Jilles
  30. Rilly. by Anonymous Coward · · Score: 0

    Screw this chump. Only good thing he ever did
    was prototype vi in high school or whatever.
    I hope he has fun listening to Springsteen's
    "Glory Days" for the rest of his life.

    Too bad there going to mod you down; but
    Sun was one of the tech companies that shot
    themselves in the foot with the H1-B and
    outsourcing crap.

  31. C moron by AssFace · · Score: 1, Insightful

    He is blaming security holes on the fact that programs are written in C?
    Retarded.

    You can leave gaping holes in things while using Java (what he keeps using as the cure all), and you can write secure things in C.

    It is not the fault of the language, it is the fault of the program design and/or implementation if there is a security hole in it.

    --

    There are some odd things afoot now, in the Villa Straylight.
    1. Re:C moron by GnuVince · · Score: 1
      If the language makes it easy for the good programmer to screw up, there is a problem with the language.

      C is a fine language for computing-intensive tasks and for low-level programming. But why in the name of God is it still used to program IM clients, IRC clients, and other user applications which do not need to be blazingly fast? Please use safer languages for these tasks (Python, Java, O'Caml, SML, whatever) and make sure that you don't expose your users to a myriad of security holes because one night you were a bit tired and you forgot to properly allocate memory.

      Just move along with times, C sucks for most end-user tasks and makes them a whole lot more difficult and that's precisely why higher-level languages are designed for.

      Down with C for computer applications!

    2. Re:C moron by TheSunborn · · Score: 2, Informative

      The problem with writing an im client in Java is
      that an im is something which always is runnig.
      There the heavy memmory requirement/usage of the java vm is a big problem, because you don't want 10-20MB memmory taken away by the im.

      This problem would not be so big if only sun would make a vm which allowed many programs running in the same vm thus sharing the memmory usage.

      Martin

    3. Re:C moron by mabu · · Score: 1

      If the language makes it easy for the good programmer to screw up, there is a problem with the language.

      Someone mod this guy up funny.

    4. Re:C moron by AmericanInKiev · · Score: 1

      Of course you're right. But implementing high level features in low level languages is an organizational approach which allows for maximum flexability at every turn, and that flexability includes low-level susceptabilities.

      Java is not an alternative to C. In all likleyhood the JVM is written in C. Java is an organizational arrangement in which high level features - such as GUI - use a more carefully restricted interface to the hardware. Thus security concerns such as Buffer overflow can be a concern for the few people who design JVM, rather than a continual concern for those who create the software people touch.

      I would suggest that the reason you -can- write holes into Java has more to do with MS embrace and extend than the core assumptions of VM java.

      AIK

    5. Re:C moron by bill_mcgonigle · · Score: 1

      This problem would not be so big if only sun would make a vm which allowed many programs running in the same vm thus sharing the memmory usage.

      If you want this, you should be using Mac OS X. Apple loads all the invariant parts of Java once, and they're shared among the JVM's.

      From that page: Apple's Java Shared Archive implementation in Mac OS X is fully compatible with the Java HotSpot specification and has been presented to Sun for further use within Java.

      This is the real problem - Apple is doing what Sun should have about five years ago. When is IBM going to acquire Sun already?

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    6. Re:C moron by Anonymous Coward · · Score: 0
      • When is IBM going to acquire Sun already?
      Wow. That statement fits nicely into a little hole in my whole 'Sun pissed away a world of promise' wall.

      Thx!

  32. well.... by ShadowRage · · Score: 2, Interesting

    why not fix C and C++ instead of going on about it being buggy, etc..
    fix what we current have, not make new implementations of it that require a mass change to use it, not to mention java is a ram whore.

    anyways, I do like his idea on fixing common internet problems, however, a lot of that would be simple to fix, example, smtp has been a standard for decades, yet, it's one of the most exploitable protocols ever in existance, all is needed to be done is fix the mail protocol so it cant be so easily abused, (inet6 will help with this as well)
    whatever, I'm about to go back to bed.

    1. Re:well.... by aled · · Score: 1

      Good idea! let's call it... er... Java?

      --

      "I think this line is mostly filler"
    2. Re:well.... by Anonymous Coward · · Score: 0

      Maybe. But let's do something else. Let's make the compiler code FREE so that it won't be such a pain in the ass to port to different architectures!

  33. Re:moderation abuse strikes again by Anonymous Coward · · Score: 0

    Yup. There's a crack sale featuring some
    exquisite merchandise going on at
    the Apple/Java/KDE store. Mods loaded
    up yesterday and have been partying
    all night. Dissent and satire
    will not be tolerated.

  34. What he's really going to do ... by Anonymous Coward · · Score: 0

    Rewrite Solaris in Java!

    (as long as it remains closed source)

  35. Java underappreciated? by defile · · Score: 0, Troll

    We did provide people with tools like Java to build more safe and reliable services on the network. But Java has been underappreciated because, once again, it was a solution to a problem people had heard about but had not felt viscerally

    What's he talking about "underappreciated"? Sun refused to let a standards group take it over. Sun refused (and may still refuse, I haven't checked) to even open source it.

    And it's not until I'm sitting in front of a 2,4GHz workstation that Java applets load and run reasonably.

    Way to go about changing the world. What he really means is that they weren't able to take Microsoft's place as monopolist.

    For everyone who whines and blames Microsoft for their failures, you can point to a company that was competing with a shittier product or a greedier mentality.

    1. Re:Java underappreciated? by Anonymous Coward · · Score: 0

      And it's not until I'm sitting in front of a 2,4GHz workstation that Java applets load and run reasonably.

      Sure we believe you ;-) .. I must have some magical PC then because it's a 400 MHz job and Java apps run just fine on it.

      Tip.. try using a JVM that's NOT 3 years old

  36. +3 : Funny by Anonymous Coward · · Score: 0

    C'mon mods.

  37. Oh, yes there is... by Anonymous Coward · · Score: 0

    But they're all movie sites.

  38. Move everything to Java? by djroute66 · · Score: 1

    So he rags on C and C++. Yeah, lets all move to Java.

    The interviewer should ask him what the Java machine was written in.

    1. Re:Move everything to Java? by wilsynet · · Score: 1

      As I understand, there's some unpublicized Sun effort underway to write the VM in compiled Java (eg. GCJ).

  39. Are viruses really a problem with users? by HotButteredHampster · · Score: 1
    As a sidenote, I believe that the majority of viruses are ONLY due to misinformed users. Dont open executable attachments and you're safe. Just like riding a car is potentially dangerous, as long as you know what you're doing you've got a large degree of safety

    I don't agree with your statement about misinformed users. Yes, users are by and large misinformed and/or ignorant. The problem is that the prevention of virus propagation is complex. For years I have said the same thing to users: Don't open email attachments. However, Outlook automatically opens emails and attachments as well in the "Preview Pane".

    So now I can't prescribe virus immunity with four words, I have to either:

    1. say Ok, go to the Tools Menu, select Options. Go to the email tab...
    2. or I have to say Don't use Outlook

    Unfortunately, the first is amazingly complex for the average user (and not memorable either: give a man a fish...). The second is asking the apathetic user to rebel against corporate policy.

    Can you say no-win situation? As long as Outlook is the standard, viruses will happen.

    HBH

    --
    "Smart is sexy." -- D. Scully ("War of the Coprophages")
  40. Better title... by NineNine · · Score: 0

    Stick Around For Joy!

    If you don't know the reference... you're just not a geek.

  41. Say This at @Stake and You Get Canned by ClassicPenguino · · Score: 1, Interesting
    Says Joy in the interview:
    The Internet is an ecology, so if you build a species on it that is vulnerable to a certain pathogen, it can very well undergo extinction. By the way, the species that go extinct tend to have limited genetic diversity.

    Are you implying that Microsoft Windows is vulnerable to extinction precisely because it is so dominant?

    I wasn't thinking of any particular piece of software, but if you're running a monoculture of software--duh, this is not good.
  42. Re:The next path for ROY by Anonymous Coward · · Score: 0
    This is the part I like best:
    "The tiger lunged at Horn during the evening show at the Mirage hotel-casino and grabbed his arm. The tiger then went for Horn's throat. Shaking the illusionist from his mouth like a rag doll, the tiger dragged Horn from the stage."
    My guess is that Roy has only about a 1 chance in 5 of living, and only a 1 chance in 20 of returning to something resembling "normal" (for a fag).
  43. Note to Bill Joy by gkirkend · · Score: 1

    Stupid people write stupid programs. The language is not the issue.

    --
    To a shark, you are just another food choice...
    1. Re:Note to Bill Joy by Anonymous Coward · · Score: 0

      No, some languages are inherently safer than others (Java is inherently safer than C).

    2. Re:Note to Bill Joy by Anonymous Coward · · Score: 0

      Thanks for clearing that up for us genius !!!! ROFLMAO

  44. Ray Kurzweil and Bill Joy About the 21st Century by rpiquepa · · Score: 1

    I wrote about the Fortune's interview of Bill Joy a couple of days ago here. But I focused my summary on his comments about the article he wrote for Wired in April 2000, "Why the future doesn't need us," in which he said that rapid advances in genetic engineering, nanotechnology and robotics (collectively known as GNR) could endanger our lives. And in this long text published by CIO Magazine, Ray Kurzweil also writes about the dangers introduced by new technologies. More specifically, he also gives his views about GNR. In his conclusion, he says that "we need to understand that these technologies are advancing on hundreds of fronts, rendering relinquishment completely ineffectual as a strategy. As uncomfortable as it may be, we have no choice but to prepare the defenses."

  45. Stupid moderator by Anonymous Coward · · Score: 0

    That was actually quite funny. Oh well. Too bad about the karma hit. Java devs are sooo sensitive.

  46. The problem with C... by rmdyer · · Score: 1

    I use C every day. I love it. It's part of my weapons cache for solving daily problems. I also use VB and have some working Java knowledge. I also spend a good bit of time using process level shell scripting. I'm a systems programmer/admin/architect, and I manage a diverse collection of greater than 500 fully managed and secured user PC's.

    I've been programming in C for years. Pointer problems aside, the main problem I've always seen with this little language is that there is no fundamental "string" data type. C++ solves this by creating the big fat bloated "string" object class. But in my opinion, there should have always been an extremely small and efficient fundamental "string" type, as in...

    string my_buffer;

    &my_buffer = a pointer to the memory the string occupies. So what's in that memory?

    Address 0-3 contains a 32 bit unsigned value representing the length of the string (for 32 bit compilers), or 64 bit unsigned for 64 bit compilers. Address 4 and up contains the actual string data.

    The compiler should "know" how to deal with this data type as in...

    strcpy( string1, string2 );
    strlen( string );

    None of this null terminated ASCIIZ string stuff.

    (or, maybe we have several fundamental string types for different max size strings...as in string1, an 8 bit size value, or string2, a 16 bit size value, or string4, a 32 bit size value, etc.)

    The reason the C programmers didn't want to do this I assume is that they didn't want this...

    string *my_string;

    So, what does the my_string pointer...point to? Do you always assume the size of the string will be at my_string - 4? I'm going out on a limb here to suggest that this would just confuse the already baffled C programmer. But even if we didn't use this suggested method to store the string size, certainly some other method could have been used. My point remains that the C compiler should have been able to deal with a fundamental string data type.

    +1.4

    1. Re:The problem with C... by Anonymous Coward · · Score: 0
      string my_buffer;

      &my_buffer = a pointer to the memory the string occupies.
      That would mean a string would have to be statically allocated on the stack. How big would this buffer be? Too arbitrary, and it gives the compiler too much knowledge in an area where it really shouldn't be calling the shots.
      The reason the C programmers didn't want to do this I assume is that they didn't want this...

      string *my_string;
      This would actually fit your "size + buffer" model much better. The string could be allocated on the heap and its size can be right there at the memory it points to. After those bytes would be the string itself, which could be of any arbitrary length since it's allocated on the heap instead of stack.

      But personally, I would prefer a string type like this:

      typedef struct {
      size_t len;
      char *buf;
      } string;

      That way, you can more easily have a string be a substring of another, but their actual characters occupy the same location. Since you code in Basic, I will give you this example:

      struct string Mid( string base, size_t s, size_t len )
      {
      struct string r = {0,NULL};
      /* Return an empty string if the offset's too big */
      if( s >= base.len )
      return r;
      /* Truncate "len" if it's too big */
      if( s+len >= base.len )
      len = base.len - s;
      r.len = len;
      r.buf = base.buf + s;
      return r;
      }

      Currently, there is no way to do a function like BASIC Mid$() in C without allocating a new buffer, copying part of the string, and zero-terminating. If the C libraries were aware of a Pascal-type string (which is actually what we are talking about here), that wouldn't be a problem.

      Another important thing to keep in mind is that most things that apply to strings also apply to arrays. That's why when I code in C, I use a structure like this:

      struct buf {
      void *buf;
      size_t len; /* Bytes in buffer */
      size_t alloc; /* Bytes allocated */
      size_t bs; /* Block size; how many bytes to allocate at a time */
      };

      Then I have code which handles realloc()s in a generic way, as well as macros that allocate bytes and cast them to any type you ask for. The whole thing works out pretty well, except for the fact that realloc() changes the location of the buffer periodically, and so we can never rely on keeping memory addresses too long...
    2. Re:The problem with C... by Nevyn · · Score: 1
      I've been programming in C for years. Pointer problems aside, the main problem I've always seen with this little language is that there is no fundamental "string" data type. C++ solves this by creating the big fat bloated "string" object class. But in my opinion, there should have always been an extremely small and efficient fundamental "string" type, as in...

      What is a "string" ... no really. In C++ you have std::string, std::strstream, std::streambuf and now std::stringstream ... which isn't even couting calling basic_string<> to create a slightly different one or using QString from Qt. I guess it's possible if there was a simple dynamic string API in ISO C people might use it, but it's not like safe dynamic string APIs don't exist. So I wouldn't put a lot of money on people using them more than they do now.

      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
  47. Java GUIs by tpv · · Score: 3, Interesting
    [Java] isn't ready to be used for anything with a GUI

    *shrug*, it works for us.
    We've switched almost entirely from Powerbuilder to Java, including writing fairly rich GUIs in it. (I personally think the Java GUIs look and feel better than the PB ones).

    The big issue with Java GUIs is that it's almost impossible to do them in a "knock-up" way, (something that VB, PB and the like are good at).
    People try it, and then end up with junk and blame it on the tool. It's true that if you want to throw a GUI together as cheaply and easily as possible, then Java isn't the right tool, but if you want to put together a GUI that fits into a well designed system, then swing works just fine.

    As Gosling recently said,

    "One of the design principles behind Java is that I don't care much about how long it takes to slap together something that kind of works. The real measure is how long it takes to write something solid."
    --
    Read more of this story at Slashdot.Read more of this story at Slashdot.Read more of this story at Slashdot.
    1. Re:Java GUIs by Anonymous Coward · · Score: 0

      >>isn't ready to be used for anything with a GUI
      >*shrug*, it works for us.

      Well, it doesn't work for one of the designers of Java, at least according to a book on Java they co-wrote.

      >As Gosling recently said,
      "One of the design principles behind Java is that I don't care much about how long it takes to slap together something that kind of works. The real measure is how long it takes to write something solid."

      That's not the sort of thing my boss says. He wants something which works, and he wants it in the next week. So I use VB.

    2. Re:Java GUIs by 4of12 · · Score: 1

      One of the design principles behind Java is that I don't care much about how long it takes to slap together something that kind of works. The real measure is how long it takes to write something solid.

      How I wish the world would pay for solid code.

      Reality, though, is that expedience rules. Any code solidity that stows away on a released product is more the result of bootleg action by idealistic programmers than anything else.

      --
      "Provided by the management for your protection."
    3. Re:Java GUIs by tpv · · Score: 1
      That's not the sort of thing my boss says. He wants something which works, and he wants it in the next week. So I use VB.

      Well, I never claimed it was for everyone.
      Most of the time my users want 5+ year investments. Having something that is gonig to grow with their business, and reliably solve problems for them in that time is (usually) priority #1.
      They want us to spend the time now so that they get a better solution in the lifetime of the business. For us, that means Java.

      --
      Read more of this story at Slashdot.Read more of this story at Slashdot.Read more of this story at Slashdot.
  48. It was the Spruce Goose by heironymouscoward · · Score: 1

    And it actually flew, once, unlike most of the waffle we hear from people like Bill Joy.

    Languages are just tools, and only an idiot blames tools for the things we make. Windows is (a) the most popular OS on the planet, and (b) written by large teams pushed to compete on features not security. No wonder it's worm heaven. If it was written in Java, it'd just be heaven for another class of parasite.

    But Bill Joy is burnt out, his vision of Java Everywhere only came partly true because of massive hyping for years.

    Blah. Reading this kind of stuff just makes me wonder whether the industry still has any people with true creative genius left. OK, there's always Larry Wall, and Knoppix. Well, I feel better now. Bill, you can go, thanks!

    --
    Ceci n'est pas une signature
    1. Re:It was the Spruce Goose by Anonymous Coward · · Score: 0

      I believe you have just missed a Simpsons reference.

      Better luck next time!

  49. Re:Oh Joy ! Intel release object CPU. by Anonymous Coward · · Score: 0

    Engage brain before selecting mouth ... either that or Joy has an inside run on the release date of Intel's object processor.

    No inside information needed, intel brought out its first OO cpu back in 1981.

  50. Re:Oh Joy ! Intel release object CPU. by Anonymous Coward · · Score: 0

    And who knows, maybe some day I will learn to type. Let's try that again! About the intel 432

  51. Obligatory *rimshot* by Anonymous Coward · · Score: 0

    I've seen Bill Joy's C code. I can understand why he dislikes C. :)

  52. C/C++ is not secure? Setting the record straight. by Mybrid · · Score: 1, Insightful

    Let's investiage:
    1.) Solaris: C/C++
    2.) Linux: C/C++
    3.) Oracle: C/C++
    4.) DB2: C/C++

    The list goes on and on. Just because Microsoft can't get Windows right has nothing to do with C/C++. However, to date NO operating system has been written in Java and NO database has been written in Java. Java is untested in the mission critical apps of OS'es and Databases. A JVM is not an OS.

    Outlook is susceptible to viruses MOSTLY because scripting is enabled. Web Browsers are susceptible to viruses becasue scripting is enabled.

    Cheers!
    -Mybrid

  53. Also with attendant engineering processes by Ars-Fartsica · · Score: 1
    Of course for major commercial systems products you are still going to see C/C++, but those projects also have huge QA budgets. There are still a huge number of smallish projects in the open and closed worlds that used C/C++ but don't do any of the attendent QA. Thats the danger zone and Joy is correct to cite it.

    It will be hard for programmers to let go of C/C++ - the religion of low-level programming has been hammered into a generation of programmers even though there are plenty of high level languages that operate safely and acceptably fast on current hardware for most app spaces.

  54. He should stick to computers by MarkRebuck · · Score: 1

    I love it when computer folks comment on economics/politics/whatever. My favorite comment from the article would have to be:

    The Soviet Union collapsed not because of communism or central planning, but because of corrupt accounting.

    Yeah. Corrupt accounting. That was it.

    1. Re:He should stick to computers by gerardrj · · Score: 1

      I don't know about the accounting portion, but it was corruption in general, and greed specifically that caused the Soviet system to fail. Communism and Socialism in an of themselves are wonderful economic models, they just require a form of government that isn't inherently greedy and/or corrupt.
      Greed will eventually be the undoing of the U.S. government, just as it has been the undoing of every major world power for all of human history.

      --
      Article X: The powers not delegated... by the Constitution...are reserved...to the people
    2. Re:He should stick to computers by Anonymous Coward · · Score: 0

      > they just require a form of government that
      > isn't inherently greedy and/or corrupt.

      Well, there in lies the problem. Governments
      are instruments of men and men are, and always
      will be, greedy and corrupt.

      > Greed will eventually be the undoing of the
      > U.S. government, just as it has been the
      > undoing of every major world power for all of
      > human history

      You are somewhat correct... big (global) business
      will help to end (probably already has) the U.S.
      as we know it. However, and global business is
      driving this, multi-culteralism and immigration
      will be the nail in the coffin for the U.S.

  55. Woefully sadly misdirected on languages by Ars-Fartsica · · Score: 1

    ARGH. This entire thread appears to be populated by people who have perhaps learned everything they know about programming from other slashdot posts. Every working programmer I know and respect doesn't even flinch at the suggestion that you should always use the highest level language you can get away with. I really would like to know the background and amount of working code posters here have on their resumes.

    1. Re:Woefully sadly misdirected on languages by Gwala · · Score: 1

      I have 8 years programming under my belt, and the highest level isnt always the best. Especially when considering speed and dependencies. I'm not going to stick with VB because its the highest level language I can get away with. It's a horrible language, has tons of external references, and generally is clunky.

      Compare to C/C++ with Inline ASM, you will find that the code is clean, efficient, easily portable, and will be scalable to a much larger use than intended. (ie CrummyDatabase 1.0(TM) written in C/ASM could scale to a much larger audience of users than the same thing written in VB)

      -Gwala

      --
      #!/bin/csh cat $0
    2. Re:Woefully sadly misdirected on languages by alext · · Score: 1

      It does look that way, doesn't it?

      In fact, I find that it's the general shallowness of analysis on display here and in similar technical threads that distinguishes /. from other forums.

      This is partly a consequence of an editorial policy that sustains a band of partisans rather than appealing to an audience with problems to solve, and partly a reflection of the conservative and derivative nature of the prominent open source developments. (Of course there's lots of wonderful innovation out there, but it won't get a fraction of the coverage that something like Mono gets).

      This thread alone must have over a dozen examples of vacuous, uninformed, aggressive and semi-literate statements moderated to +5. Do we care? Well, it simply reinforces the impression of those /. "tendencies" that rule it out as a usable source of information about IT: technology for its own sake; a poor grasp of fundamentals; noticeable difficulties in appreciating general qualities and requirements.

      With a little more work, /. could be a whole lot better. Enhance the moderating, archiving, categorizing and searching so that people can share and locate information that is really interesting or insightful (or funny) and you would certainly improve the service, perhaps even to the extent that people would consider paying for it.

  56. Re:path up the arse. by Anonymous Coward · · Score: 0

    Congratulations Fagkore, YOU FAIL IT to the GNAA!

  57. Eric Raymond Wrnog (Again) by Anonymous Coward · · Score: 0

    Well, at least the article proved one thing...
    Eric Raymond (and other Linux pundits) were
    wrong, again. Joy didn't leave Sun because of
    some problem with the busines or technical
    climate of Sun. So, can we put this to rest
    now?

    Beyond that however, I was some what disappointed
    by Joy's thoughts and reasoning on matters. They
    seemed shallow and sophomoric. And contradition?
    He laments that we should be building software
    in diverse environments (different OSes, etc.)
    and then tells everyone we should be using Java
    for everything. His parallels and associations
    between evolution and computing seem incredibly
    silly. And 'C' is to blame for the security
    problems with MS Outlook? Gee, I thought it was
    the architectual approach that Outlook took that
    caused the problems.
    Kent

  58. AMEN by Ars-Fartsica · · Score: 2, Interesting
    I am so tired of the canned responses on slashdot telling me that only dumb programmers produce errors, and that the entire industry of software tools only exists because we clearly aren't smart enough to catch on the the lowest facts grasped by posters.

    I used to think like this too - when I was in college. Back when the coding projects I worked on were the dorky isolated projects assigned by my profs. Oh it was so easy to pontificate when I only had to code the travelling salesman problem.

    Now I respect programmers who patently avoid anything lower on the architecture totem pole than they have to go. Working programmers who actually make use of advances in compilers, languages, methods and tools to produce working code for large projects that matter. In these projects people use an interpreted language if they can get away with it. They use C++ instead of C if they can get away with it.

    Once again, I would kill to see the actual code produced by most posters here. I suspect that 99% of it is for college assignments.

  59. Re:The next path for ROY by boudie · · Score: 0

    Bad puddy-tat.

  60. Wow by ebyrob · · Score: 1

    I really like your analogy. Alcoholism and bad programming practices...

    The problem isn't the C language. The problem is, as always, language bigotry and poor breadth of knowledge.

    Of course, that sword cuts equally in all directions. What language can you imagine as "the" systems language in 50 years? Can the future really hope to hang on to diversity? Where will we attain unity?

    If we teach all the C programmers Java, and all the Java programmers C. Then we'll get world peace! (Oh wait, that's just my own bigotry showing.)

    1. Re:Wow by mobiGeek · · Score: 2
      The problem isn't the C language. The problem is, as always, language bigotry and poor breadth of knowledge.
      ...and laziness, lack of planning, lack of dedication, yada-yada-yada.

      Joy is right that more structured languages reduce programming errors. When it comes to working with Java, you can feel when your code is getting ugly because it starts to deviate from the clean design of (most of) the language's libraries.

      With C (for example), there are few standards upon which to measure the "cleanliness" of your own code. Many libraries/APIs you use aren't consistent, well-designed and/or well-documented.

      At least, that's one way to look at the issue.

      --

      ...Beware the IDEs of Microsoft...

    2. Re:Wow by ebyrob · · Score: 1

      Well... my problem with "java only" developers is that they often seem to forget how to do good old fashioned procedural programming and write extremely tiny functions and classes with really nasty inter-relationships...

      A clean API is a clean API, whether it is object oriented or not. The standard C libraries, and associated documentation also have a certain "cleanliness". The standard C libraries are just way way smaller and less capable than those in Java.

  61. off-topic Re:Woefully sadly misdirected on languag by WolfWithoutAClause · · Score: 1
    Um, actually I've got a solid 15 years C++/C/Smalltalk/Self/Java/sh/bash/TCL/AWK under my belt.

    And you are on-topic how exactly?

    --

    -WolfWithoutAClause

    "Gravity is only a theory, not a fact!"
  62. Re:C/C++ is not secure? Setting the record straigh by ncat2k · · Score: 1

    How can you miss this one?
    5.) JVM: C/C++

  63. Wow... maybe sit back and listen? by Anonymous Coward · · Score: 0

    Amazing how a lot of this becomes a mission for /.r's to pick apart any interview with someone of great significance. Is old Billy Joy right about everything when it comes to computers? No, but his list of accomplishments frankly dwarf 99-100% of the people who read this site. And correct or not the man is a visionary.

    You don't like vi? Fine, its still quite an accomplishment. Same can be said for everything else the man has done. Anyone here written the defacto standard internet networking protocol? Nope I didn't think so. The man is human, his opinions may not always be 100% correct, but they are most certainly worth listening to.

    So shut the hell up and listen to a man who has done a hell of a lot more than just figure out how to run a unix variant and program in a language or two. There are few things worse than watching geeks pick shit apart simply because they can't put their ego and minute accomplishments aside for a brief period of time.

    Those who can do, those who can't sit around trolling and picking shit apart on slashdot.

    1. Re:Wow... maybe sit back and listen? by Gwala · · Score: 1

      I have coughed up better editors in my sleep. vi, while an acomplishment for the time (being it did pioneer the 'horribly obfusticated text editor') is still no justification for being converted from an engineer to a markedroid. Bill joy has no idea what he is talking about when he advocates Java over C.

      Java has bounds checking, garbage collection too! but at what cost? half your cpu cache, and a good chunk of cycles for what a good programmer should do instinctively. The problem isnt the language, its the indervidual programmer's implementation. Period.

      (Note about first paragraph: vi is still my preffered editor, but only due to routine and comfort, not because it's actually intuitive or anything. (That being said, watching a windows/notepad person try get out of 'random beep mode' is amusing))

      --
      #!/bin/csh cat $0
    2. Re:Wow... maybe sit back and listen? by Anonymous Coward · · Score: 0

      vi is the fastest, most efficient editor around. There are some irritating things about it, but the most "obvious" ones aren't the ones I'm talking about.

  64. OMIGOD! by Anonymous Coward · · Score: 0

    There are kooks spewing half-baked gibberish all over the Internet!

  65. The US has central planning of consumer production by Animats · · Score: 3, Interesting
    But it doesn't come from Washington. It comes from Bentonville, Arkansas.

    Wal-Mart, headquartered in Bentonville, Arkansas, runs about 3300 stores. It's the biggest retailer in the world. It's the biggest employer in the the US. It's four times the size of the #2 retailer (Home Depot). Wal-Mart's total revenue is over $200 billion. This is more than most small countries. And they're still growing.

    Wal-Mart controls a bigger economy than Gosplan, the USSR's state planning agency for the civilian sector, ever did. And Wal-Mart's control is far tighter. Wal-Mart has far more computing power than Gosplan ever did. Wal-Mart tracks sales daily; Gosplan seldom did better than obtaining annual numbers. If sales of something go up, manufacturers are told within days to increase production. If sales go down, Wal-Mart pulls the plug on the maker just as quickly. Gosplan could only dream of control like that.

    Wal-Mart's "Corridor of Doom" is famous in retailing. That's where you go to sell to Wal-Mart. There's a long hall with buyer's offices, and a waiting room with a pay-per-use coffee machine. Sales reps, and even CEOs, go there and grovel before a polite Wal-Mart buyer who, by tradition, opens with "And what can your company do for Wal-Mart today". The buyer, equipped with data on all of Wal-Mart's suppliers, then squeezes the sales rep on price. Hard. Companies that sell to Wal-Mart don't make big margins. If they do, Wal-Mart searches for an alternative supplier, and plays the suppliers off against each other. (That's why they push Linux.)

    That's how the American consumer product economy really works today.

  66. LookOuts flaw is a MARKETING thing by HiggsBison · · Score: 1
    The issue is with secure and contained execution environments. Properly "jailing" software (whether a process in an operating system, or a thread and window box on a preview pane in Outlook) is the real answer. Engineering has long known that compartmentalisation is key to minimising risk and impact. Operating systems are getting better at doing it. Programming languages are gradually working towards it.

    The problem with LookOut is not one of sandboxing. The problem is that it started with marketing. Benevelant marketroids sold it as a way for benevelant marketing emailers to keep tabs on their prospects. Send an email with hypertext and you can benignly pass cookies and whatnot. Be polite and no harm will come.

    But that's not the way the real world works. Bill (Gates I mean, not Joy) and company are still trying to make benevelant intrusion work the right way despite anyone elses take on reality. And they still think that people like benevelant marketing scrutiny in the first place.

    --
    My other car is a 1984 Nark Avenger.
  67. Java and monoculture by Anonymous Coward · · Score: 0

    I'm amused that Joy warns against a software monoculture, while advocating that everything be done in Java!

  68. Joy is right about c and microsoft outlook by zymano · · Score: 1

    How can you say he's wrong ? C is fast but is the principle attack on all microsoft exploits using ........ BUFFER OVERFLOW. 50 % of all intrusions use this attack. I like my java on server side only. Another language needs to be created or the C libraries need a large bit of rewriting. Is there any language that is almost as fast as C and has high security ? Compile Python ?

  69. Re:C/C++ is not secure? Setting the record straigh by alext · · Score: 1

    1. An OS is not an application

    2. There are several databases written in Java

    3. All your examples pre-date Java (but three of them find it useful enough to include)

    Nothing in your comment implies that C/C++ is more secure than Java, it is simply flag-waving.

  70. some people are desperately defending C and MS by aeoo · · Score: 1

    It's sad to see. They pose as the beacons of objectivity and are getting highly moderated, but often, their message is either completely wrong or contains grievous errors, as is shown in highly moderated replies underneath.

    Why do people love C and Microsoft so much? Microsoft business practices are some of the worst that a company can practice (and found illegal in USA at least). There is nothing good or magical about C. C is simply an assembler with a better syntax. Why do people cling to things like that for their deal life?

    1. Re:some people are desperately defending C and MS by mattgreen · · Score: 1
      There is nothing good or magical about C. C is simply an assembler with a better syntax. Why do people cling to things like that for their deal life?
      Ignorance and close-mindedness.

      Look up any C++ post on Slashdot and you'll find a plethora of misinformation that only continues to perpetuate itself. Nevermind that several highly regarded UI toolkits such as KDE and Qt are written in C++. Worse, these people clearly don't want to learn that they are wrong.

      That and there's the mistaken concept that if its written in something other than C it will end up being slow. I recall seeing a post on here advocating using Perl instead of C++ for performance reasons.

      I've concluded that this site generates its own massive reality distortion field. Witness the recent response to HL2 as a prime example: "the final game won't be buggy at all because the whole world can debug it for them! HL2 has been freed!"

    2. Re:some people are desperately defending C and MS by Anonymous Coward · · Score: 0

      ACK

  71. your being facetious by zymano · · Score: 1

    Try Python, compiled Python. There are other languages out there with garbage collection. cyclone ADA,scheme,modula or oberon. Too many to list. just google 'computer language garbage collection'

  72. Re:The US has central planning of consumer product by Anonymous Coward · · Score: 0

    Regardless of the fact that Wal-Mart doesn't really control the entire economy (even if it is a huge player with a big impact), you invalidate your own logic about central planning by noting that Wal-Mart searches for an alternative supplier, and plays the suppliers off against each other. This is what is called "competition" and is vital to what we call "free markets" in something we like to think of as "capitalism." Contrast this to the "bidding" process for the Iraq contracts, and you can easily appreciate the difference.

  73. Re:The US has central planning of consumer product by Anonymous Coward · · Score: 0

    Competition requires a degree of balance all round, though. You can't say it's effective competition when an organisation has as much power over its suppliers as Wal-Mart does.

    In a real, balanced, free market, the suppliers would be free to reject Wal-Mart's prices and supply another retailer. That they aren't realistically shows the distorting effect Wal-Mart's massive size has had on the US economy, and graphically illustrates the need for anti-monopoly provisions to keep a market free.

    Remember that the next time you shop at Wal-Mart, or Asda in the UK.

  74. Re:C/C++ is not secure? Setting the record straigh by Anonymous Coward · · Score: 0

    Another point: VMS WASN'T written in C and is just open source now (not sure how good the licensing is, but....). So what happened to it, and if there is such a need to find an OS that's not written in C, then why isn't OpenVMS going anywhere?

  75. Re:C/C++ is not secure? Setting the record straigh by Mybrid · · Score: 1

    1. An OS is not an application

    That is irrelevant to a security argument.
    However, an OS is an application of C and thus talking about it's security based upon C is relevant. Only a small portion of the OS is written in machine or assembly.

    2. There are several databases written in Java

    Having a database background I'm somewhat of a bigot. Some Micorsoft people claim Excel is a database. I do not. I should've stated enterprise, transactional, relational databases directly comparable to Oracle, DB2, SQL Server, Sybase, Informix, etc.

    3. All your examples pre-date Java (but three of them find it useful enough to include)

    This is irrelevant to a security argument.

    Perhaps you are not aware but a database typically supplants the OS and goes straight to disk. In this manner a database is an OS. In fact, any *application* can choose to bypass the OS and thus an OS would be interchangable with application if indeed this were common practice. However, the catch is you need to have device drivers or use existing OS device drivers. Just because applications don't choose to do so doesn't disallow it. Databases mentioned above do bypass the OS altogether for performance reasons.
    Most people don't realize the CPU security model only recognizes two users: kernel and user. Neither the use of Java or C changes that.
    Any application that is given access to kernel mode at the CPU level can do anything and everything the OS is capable of.


    *~smiles*~ Facts are not flag waving, eh? They are examples of secure, sophisticated applications of C/C++.

  76. Look at D by mattgreen · · Score: 1

    The D programming language seems to be what you're looking for.

    No runtime environment. Native string type. Garbage collector that you can suspend. And my favorite, object properties.

  77. Past his expiration date by crucini · · Score: 3, Insightful
    Bill Joy is just a typical old programmer full of whimsical opinions. The only reason he's being interviewed by Fortune is that he was in the right place at the right time and is therefore rich. If you read his "six phases" description you see that he basically stopped working in 1987. After that, he just putzed around. I think it's pretty obvious that with Sun in bad financial shape, McNealy finally kicked him out.

    Joy comes close to saying Solaris should be re-written in Java. He's not very realistic. When I think of secure programs, I think of qmail, postfix and djbdns. All written in C. I can't even name a Java mailserver or DNS server off the top of my head.
    Another reason spam is so bad is that so many companies use Microsoft Outlook for reading e-mail. Again, because that program is written in C, it's quite easy to design a virus to go through your e-mail address book and broadcast spam to all the people you know.
    Outlook's numerous viruses are not caused by the program being written in C or C++. They are caused by Outlook's support for active content. The problem would still exist if Outlook were re-written in Java. I wonder if nobody in Joy's circle dares to correct him on this, or if he's been corrected and just didn't hear.

    Take any random clever programmer over 30 and give him $100 million. He will wander off into the sunset, murmuring about his brilliant new idea for re-architecting the internet or something. He will never again do or say something relevant.
    1. Re:Past his expiration date by Anonymous Coward · · Score: 0
      I can't even name a Java mailserver

      Apache has James, which is a java webserver.

    2. Re:Past his expiration date by Anonymous Coward · · Score: 0

      You are *so* right. Joy is a jerk. He's done nothing since Java, an even that wasn't wholly his idea. Just because someone contributed something at one point in their career doesn't mean they will continue to do so. He became largely irrelevant to Sun, and once he started wittering on about the evils of nanotechnology, he became a downright embarrasment. Good riddance.

    3. Re:Past his expiration date by Anonymous Coward · · Score: 0

      I have to admit that Joy doesn't come off very well in this article. Perhaps he hadn't understood how the author was intending to frame this interview and was addressing the questions more casually than he might otherwise. The result though is that Joy seems beyond his depth when discussing anything but his own work.

      I think that Joy's been a bit stung by experts' reactions to his Wired article. His broadhanded dismissal of the critics of "Why the Future Doesn't Need Us" is not warranted. There has been alot of thoughtful criticism of his analysis, none of which simply dismissed Joy's concerns. Truthfully I don't think that Joy realized how much research has been done surrounding the definition, analysis, and mitigation of future risks. When it turned out that he'd actually have to debate people with informed but conflicting opinions, he was turned off - it was un-fun negative energy. But now he wants to offer a prescriptive program for managing human behavior, geopolitics, science and technology - empiricism is a managed process you know(?). I just hope that he's more thoughtful in developing his arguments, otherwise he could do more harm than good.

    4. Re:Past his expiration date by alext · · Score: 1

      When I think of secure programs, I think of qmail, postfix and djbdns

      Sounds like you are working in a very narrow field - a field, apparently, without any business applications at all (unless we count the mail server).

      Out where I am we have application servers running web services, ERM and CRM systems, telco provisioning, financial trading and settlement systems, military logistics systems etc.

      A very large proportion of these applications both use Java and rely on the Java security framework.

      In fact, it's probably a fair bet that Java is the number one choice for building enterprise applications with non-trivial security requirements.

    5. Re:Past his expiration date by pmz · · Score: 1

      Outlook's numerous viruses are not caused by the program being written in C or C++.

      The ones that exploit buffer overflows are due to C and C++. This is an entire class of bugs removed by Java. This is not something to laugh at.

      The social engineering viruses/worms are due to Microsoft making them so convienient and effortless to write. Of course, there is no silver bullet for this stuff.

  78. Bad example by mattgreen · · Score: 2, Interesting

    Your example simply describes the misuse of exceptions. I can misuse pointers and destroy the stack, so do you think we should be disallowed pointers.

    Whether you like them or not, exceptions greatly simplify application logic. You no longer have to consistantly check every single return value (making return values indicate success was backwards to begin with at the time - we just hadn't realized it. At least errno is somewhat consistent.)

    Exceptions are used very rarely in C++. They do it right - they are thrown when the state of the object is destroyed by some circumstance, or some other catastrophic failure such as the new operator failing. And it is really freakin hard to make C++ throw an exception from the standard library.

    1. Re:Bad example by Nevyn · · Score: 1
      Whether you like them or not, exceptions greatly simplify application logic. You no longer have to consistantly check every single return value

      No, they don't simplify anything and yes, you DO have to check all the return values. You just do it implicitly, and it's much harder to match up the error checks with the error generators.

      Exceptions are used very rarely in C++. They do it right - they are thrown when the state of the object is destroyed by some circumstance, or some other catastrophic failure such as the new operator failing. And it is really freakin hard to make C++ throw an exception from the standard library.

      So you agree with me then, exceptions are bad and shouldn't be used? The problem is that a lot of people working outside of std C++ tend to use exceptions for bits of the design they didn't bother about at the start, which turns into the crapola you have with Java where file not found is an exception. Also almost noone used the "throw ()" declaration in C++, even if they always use explicit declaration in the functions they do throw from.

      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
  79. Reference counting by mongbot · · Score: 1

    Is the slowest form of GC. Every time you reassign a pointer/delete an object you must update the reference counts.

    It makes sense - reference counting is, by definition, the most economical system to use (in terms of memory). So you're trading off speed for memory. Which may or may not be what you want to do - but consider that, usually, memory is cheaper than speed.

    The advantage of mark and sweep is that developers can tune the trade-off by increasing the frequency of garbage collection, (which will trade off speed for more memory). AFAIK, you can't tune reference counting this way (there wouldn't be any point).

    There's an interesting letter by a Microsoft designer about how they found that mark and sweep was much better than reference counting for Visual Basic .NET. And they really didn't want to change from ref counting.

    1. Re:Reference counting by Anonymous Coward · · Score: 0
      It makes sense - reference counting is, by definition, the most economical system to use (in terms of memory). So you're trading off speed for memory. Which may or may not be what you want to do - but consider that, usually, memory is cheaper than speed.

      Reference counting is the simpler - but in terms of implementation complexity and integration with C/C++ code and their libraries.

  80. It looks like he could learn more, really by egork · · Score: 1

    They couldn't organize the means of production because everybody was lying about everything. It was a game of fake numbers, and when you do that, you get crap for answers.

    The real problem here is, there is no real value for anyting in a socialistic economy. Only big "customers" like military have a say on what do they really need and what is relatevely more valuable for them. This fundamental flaw screwes up the whole accounting. Stalin had managed to get out of the industry what he needed for the war, but as soon as the cold war started, where not only the military resources mattered, socialism lost. Lost because it was desorientated by military valuation approach and not by the free market one.

    What is the actual cost of greenhouse gases, for instance? If you create a marketplace mechanism to solve that problem, you will probably end up creating wealth, and people would stop doing the stupid things they do now because it doesn't cost them anything.

    Has he ever heard about the Kioto Protocol and that G.W.Bush has just denonced US signature, done by G.Klinton? :-)

  81. Re:C/C++ is not secure? Setting the record straigh by alext · · Score: 1

    1. The term "mission critical application" does not refer to components like the OS.

    2. I am interested in discussing the security of "business information systems", the proposition being that they would be better written in Java than in C/C++. If your points are intended for some other kind of audience then make that clear.

    3. The reason your non-OS examples aren't convincing is because they predate Java by a long way. They also belong to a restricted class of established infrastructure components which evolve very slowly and are not suceptible to being replaced by newer alternatives, even when better.

    4. Despite such obstacles, Java databases having the qualities you mention do exist - I'm surprised you have not encountered Cloudscape or Pointbase, noticed the number of Java components in Oracle Lite.

    5. I don't see the relevance of your exposition on disk access, and I fear your knowledge of security models may be less advanced than you suppose. The Java security model does augment the kernel security model - from a Java application's point of view its controls are as completely and effectively enforced as those of the OS.

    As I said before, your facts are mostly undisputed but they say little one way or the other regarding how a secure application can best be written. What clues we do have from your examples, where Oracle does not support C stored procedures but does support Java ones, imply that application code should preferably be written in Java.

  82. Re:C/C++ is not secure? Setting the record straigh by chip33550336 · · Score: 1

    Actually, large chucks of Oracle are written in java...

  83. XWindow system?!? by joshsnow · · Score: 1

    From the article;

    That reflects a lack of design discipline, which means that as the system grows, so does the ambiguity of the software itself. The result is a system encrusted with multiple layers of things that weren't really designed in so much as bolted on

    This sounds just like X11 to me..!

  84. History By Joy (or all the bad things done by C ) by HighOrbit · · Score: 1

    1. The Crash of the Hindenburg (the lading routines were in C)
    2. The Stock Market Crash of 1929 (the buy and sell orders were written in C)
    3. Adolph Hitler (Mein Kampf was written in C)
    4. The Soviet Union ( Remember.. its initials in Russian were "CCCp")
    6. New Coke (created engineers using a C program)
    7. Drug Addiction (because you must be smoking crack to program in C)

  85. nonono .VHDL ,.geees by Anonymous Coward · · Score: 0

    To stir up a hornets nest and open a can of worms at the same time with my 2c.
    Whats all this about c and java. They have no parrallelism. Although being a hardware engineer i have this affection for c over java neither has parrellelism in there basic state. Part of the problem of doing things is trying to do everything in a little slot in the ssame time line . Although a little different, in embedded things, i can write VHDL for an FPGA that will do all the necesary functions in a system in *much* less time than i can write c for a dsp to do the same job. Doing the same thing in C can require huge amounts of coding structure. Quiet simply because everything is done at *known* times and in parrallel and thus synchronisation is easily embedded in the design and overflows are easy to take care of etcetc.
    In the case of c or java sychronising parrallel threads has alwfull coding overheads and is hard to track.

    My point is..
    Although obviously people arent going to be writing vhdl for their lil pentum, sometimes what we think are higher level languages can make it more difficult to program. Also doing everything on a processor that can only do one thing at a time makes sychronisation suck. This is the true limit of c and java. A higher level language would take care of sychronisation as part of the design but we would require a new type of processor for that.
    There are much easier ways, its just that todays processors dont suit them and the limit of the programming language abstraction.
    Many simple tasks get extruded into mass complexity by simply having to do everthing serially.
    Taa.

    NB1. ok so Handel C is an attempt at solving this but it would be a truely interesting experiment o extend it to typicall pc applications and see how much simpler coding gets.
    NB2. Ok so writing some huge mathematical function in c is easier than doing it in vhdl and tracking the timing but when its done in vhdl you will get 10000x speed:P but many applications dont require big equations and state machines do them very nicely

  86. Huh? by autopr0n · · Score: 2, Insightful

    Exceptions in java are not "invisible" In fact, you have to check for declared thrown exceptions (but not 'runtime' exceptions). In the API declared thrown exceptions are caused by external problems (like a missing file, closed socket, etc) while Runtime exceptions are usually caused by programmer error (like null pointers), and can be avoided by poor programming.

    If your python app is choaking on invalid input, it's because you can't program for shit, not because exceptions suck. If it was a C app, you'd simply segfault or something equally ridiculous. And you'd never know why. At least with the stack trace you can quickly pinpoint your problem and deal with it.

    --
    autopr0n is like, down and stuff.
    1. Re:Huh? by Nevyn · · Score: 1
      Exceptions in java are not "invisible" In fact, you have to check for declared thrown exceptions (but not 'runtime' exceptions). In the API declared thrown exceptions are caused by external problems (like a missing file, closed socket, etc) while Runtime exceptions are usually caused by programmer error (like null pointers), and can be avoided by poor programming.

      Ok, first of all a "file not being found" is not an exceptional condition. Secondly, yes java is required to tell you about exceptions you need to deal with (and this is a big gain over python/C++ that don't), however that doesn't solve the problem. Consider the Unix code...

      #define WRSTR(fd, x) write(fd, X, strlen(X)) const char *filename = "abcd"; int out = open(filename, O_WRONLY); if (out == -1) err(EXIT_FAILURE, "open(%s)", filename); if (WRSTR(fd, "foo") == -1) warn("write(%s)", filename); if (close(fd) == -1) warn("close(%s)", filename);

      Now, sure that's about as bad as it gets in C ... and normally you'd group a lot more data and do a single write operation. But anyway now compare that with the "wonderful Java exception code" taken from Sun's site on how to use exceptions...

      PrintWriter out = null; String filename = "abcd"; try { out = new PrintWriter(new FileWriter(filename)); out.println("foo"); } catch (IOException e) { System.err.println("Caught IOException: " + e.getMessage()); } finally { if (out != null) { out.close(); } }

      Now pretty much the first thing you see when comparing it to the C version is that an error from println is only checked once, when it's actually used twice. And close isn't checked at all. This "compiles" and seems to work fine ... and as I said, this is directly from Sun's own documentation on how to use exceptions.

      And I've not even mentioned how amazingly ugly it is compared to the C version, has the error checking in a non-obvious place compared to what generates the errors, could easily let someone believe that the IOException is just for the open call and it's twice as long.

      If your python app is choaking on invalid input, it's because you can't program for shit, not because exceptions suck. If it was a C app, you'd simply segfault or something equally ridiculous.

      Or, more likely, the error would have been checked. I assume the people who write the python code don't deliberately not check for "errors", it's just not obvious what is going to cause an error compared to the C code ... and often the error checking is so far from the code that generates the errors you can miss it anyway.

      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
    2. Re:Huh? by autopr0n · · Score: 1

      Now pretty much the first thing you see when comparing it to the C version is that an error from println is only checked once, when it's actually used twice. And close isn't checked at all. This "compiles" and seems to work fine ... and as I said, this is directly from Sun's own documentation on how to use exceptions.

      Actually, you're wrong. The exception is "checked" for each operation that can generate the exception. Once an exception is thrown, control immediately passes to the catch(){} block. So in order for the second op to run, the first needs to succeed.

      --
      autopr0n is like, down and stuff.
    3. Re:Huh? by Nevyn · · Score: 1
      Actually, you're wrong. The exception is "checked" for each operation that can generate the exception. Once an exception is thrown, control immediately passes to the catch(){} block. So in order for the second op to run, the first needs to succeed.

      No, the second op is only run if the first fails and it's run outside of the try, as is the close(). And according to Sun's documentation both calls are allowed to throw exceptions. This was hard to read due to /. eating all the formatting. I've put it here so you can easily see it.

      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
  87. Huh? by autopr0n · · Score: 1

    OO languages simply aren't suitable for all tasks, neither is C.

    I seriously doubt there is a situation where C++ would work and C wouldn't. Sure, there are trivial situations where you wouldn't need more then one object, but C++ works anywhere C would.

    --
    autopr0n is like, down and stuff.
  88. Re:off-topic Re:Woefully sadly misdirected on lang by Ars-Fartsica · · Score: 1
    Um, actually I've got a solid 15 years C++/C/Smalltalk/Self/Java/sh/bash/TCL/AWK under my belt.

    I will dispute "solid" if after 15 years of programming you can only cite the apparent performance gain C provides you in utterly useless micr-programs. Then again, if in 15 years you haven't discovered perl, maybe you should stick to TCL.

  89. Dude by autopr0n · · Score: 1

    It's not a memory leak if you're still "Using" all of the data, meaning that there is a valid reference to it. In C++ you can have allocated memory that is not referenced by any process, and thus cannot ever be deleted. Such a situation can't happen in java.

    A referencing B which references A will defeat a Java's garbage collection.

    No, it will not. Sun's garbage collection is not a reference counting system. It works by looking at what's connected to each Thread object. Typically a thread will have a instance of the Runnable interface, which is your class with all the member variables, vectors, etc which are all connected to their children, etc. The garbage collector does a search of that graph, and marks each node. If a node isn't marked in the end, it's deleted. if any node is not reachable by running code, it will be deleted no matter how many other zombie nodes also are connected to it. Your system would work in Python (but not the Java implementation of python), Visual Basic 6.0 or less and Perl (iirc) but not Java.

    If you don't belive, write the java program yourself. Hell, here's an example.

    class a{
    b myb;
    a(){
    myb = new b(this);
    }
    }

    class b{
    a mya;
    b(a inputA){
    mya = inputA;
    byte[] randomcrap = new byte[1024]; //so we alocate a lot of ram.
    }
    }


    class CircularTest{
    public static void main(String args[]){
    int i = 0;
    while(true){
    a loop = new a();
    i++; if(i%100 == 0){
    System.out.print(" " + i);
    System.gc();
    } } } }

    Put that in a file named CircularTest.java, then type "javac CircularTest.java" then "java CircularTest", watch your memory usage not increase without bound.

    --
    autopr0n is like, down and stuff.
    1. Re:Dude by Mybrid · · Score: 1

      rrrrrrrrr-ing MS: "Microsoft customer service, how can I help you?"

      ME: "Yes, I'd like to report a memory leak."

      MS: "And what memory leak would that be sir?"

      ME: "Well, it seems that if I leave Windows NT 3.5 on for more than one continous weak, I run out of memory. I have to reboot every Sunday."

      MS: "Oh, but how do you know that it's a memory leak."

      ME: "Uh, I run out of memory?"

      MS: "Well, sir, technically if you forget to delete both the reference and the memory its not a memory leak. The strict definition of a memory leak is that you delete the reference but not the memory."

      ME: "Let me get this straight. If I forget to delete the reference and the memory, its not a memory leak, but if I forget the memory it is?"

      MS: "Yes,sir"

      ME: "Well, I'm sorry, that doesn't make sense to me."

      MS: "Sir, you can rest assured that its not just Microsoft that defines a memory leak in this strict fashion."

      ME: "Oh, please, tell me, who else says such things."

      MS: "Java programmers."

      ME: "Oh well, thanks, that clears that up. If there are two sources I trust it's a Java programmer and George Bush. The both just state things and you must believe them without thinking too much. I like that. Ok, I guess I don't know if I have a memory leak even though I run out of memory. And since I don't have the source code I can't be sure it is a memory leak."

      MS: "That's right"

      ME: "So how do I report this bug?"

      MS: "Which application is causing the problem."

      ME: "I don't know, as I said, I thought it was a memory leak"

    2. Re:Dude by Darren+Winsper · · Score: 1

      Do a search for the definition of a memory leak. You'll find the most common one is the one from "The Jargon File", and that requires the memory be discarded. If your program holds on to the information by still having references to it, it cannot be safely reclaimed since it may still be used, thus it's not a memory leak.

  90. Not really true by autopr0n · · Score: 1

    Outlook's numerous viruses are not caused by the program being written in C or C++. They are caused by Outlook's support for active content. The problem would still exist if Outlook were re-written in Java. I wonder if nobody in Joy's circle dares to correct him on this, or if he's been corrected and just didn't hear.

    It only takes a few lines of code in Java to create a 'sandbox' and restrict any code you want to run in that sandbox. If MS had used Java they could have put their VBScript interpreter in side that sandbox. Only 6 or 7 lines of java code could have fixed all their problems.

    --
    autopr0n is like, down and stuff.
  91. Give me an example by autopr0n · · Score: 1

    Show me a C program that you think will run one hundred times faster then Java for more then a couple seconds, and I'll show you that you're wrong.

    --
    autopr0n is like, down and stuff.
    1. Re:Give me an example by t · · Score: 1

      Linux. The Java VM. Shall I go on?

  92. Who gives a fuck? by autopr0n · · Score: 1

    Write a program in Java that prints "hello world" whenever you write to a pipe. Do the same in C. The programs will run in about the same speed. If you only need to run a program once, it doesn't really matter if takes a half second or a hundredth of a second. If you need to run it a lot, leave it memory.

    --
    autopr0n is like, down and stuff.
  93. Holy shit you're stupid by autopr0n · · Score: 1

    We are talking about program loading time here. Program loading time happens once, when the program loads. God damn you are an idiot. Can't you read?

    --
    autopr0n is like, down and stuff.
  94. java sandboxing by crucini · · Score: 1

    That's good, but where do you think Microsoft would have chosen to draw the perimeter of that sandbox? Should an embedded script be allowed to access the addressbook? Modify the Registry? Read files? Contact a remote server? You know that Microsoft's viewpoint is "the more capabilities the merrier."

  95. Re:The US has central planning of consumer product by LardBrattish · · Score: 1

    Remember that the next time you shop at Wal-Mart, or Asda in the UK.

    Why pick on those two - try Tesco. Back in the '70s they got a terrible reputation with suppliers for the following delightful little trick:-

    1) Pick a small-medium sized supplier, place a modest (for you) but huge for them order, say 10-20% of their output on a regular basis and negotiate down on that basis.

    2) Gradually increase the order over time so you now represent 60-80% of their output.

    3) Call them in & tell them what price you'll be paying in the future, take it or leave it. Your choice: take it up the ass from Tesco or go out of business.

    Nice. I'm sure any company in a similar position might consider the same sort of tactic so I'm not picking on them particularly and as far as I know they've stopped.

    Now, do any of you brainwashed capitalist running dogs want to argue that this practice is good for the consumer? Don't say that the savings would be passed on to the customer either because they weren't. Instead lower quality "built to a price" rubbish was sold at the same price to the poor unwitting customer. Monopoly or near monopoly is extremely bad for everyone except the monopolist.

    --
    What are you listening to? (http://megamanic.blogetery.com/)
  96. Re:The US has central planning of consumer product by Anonymous Coward · · Score: 0

    .. bad for everyone except the monopolist.

    and the politicians

  97. retraction by Stu+Charlton · · Score: 1

    That last statement was uncalled for, and I apologize.

    It was a result of my general frustration in listening to your problems which in my opinion are a result of a lack of understanding of the Java virtual machine. Reading your other posts about defeating GC has confirmed this. You have a lot of learning to do, I think. (But I shouldn't have been so condescending.)

    --
    -Stu
  98. Huh? by autopr0n · · Score: 1

    Most of the time, memory leaks are caused by refrences going out of scope before they can be deleted. Obviously if you store the refrence somewhere else (like in a collection) You need to remember to remove it later.

    --
    autopr0n is like, down and stuff.
  99. Re:The US has central planning of consumer product by pmz · · Score: 1

    the need for anti-monopoly provisions to keep a market free.

    Wal-Mart is very unlikely to ever become a monopoly. Wal-Mart clearly excels in certain things, but they still fall short on things like produce (veggies, fruits, etc.), some clothing, gardening, etc. They are certainly fierce competition, but I still go to regular grocery stores, hardware/warehouse stores, etc. I usually buy clothes from places like Marshalls/TJ Max, where I can get better deals than even Wal-Mart.

    Retail sales is one thing I'm confident will never become a monopolist-controlled market. Only extortion would lead to that, and extortion is illegal (unless you are the US Government doing it, of course).