James Gosling, the father of Java and a fellow at Sun Microsystems Inc., graced the Software Development Conference and Expo East 2002 with his presence this week, addressing a wide range of issues from Sun’s software strategy to Web services to embedded Java to open-source software.
Father of Java Sounds Off
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I’m not a big fan of Java, but I must say that this guy is very level-headed for somebody in his line of work (creating programming languages tend to attract some fundamentalists
For example, instead of criticising C#’s memory model for being “unsafe” or “unclean” as a lot of Java-heads are wont to do, he criticises it because it makes security harder, which is perfectly true. All in all, quite a nice interview. I especially like the part about the healt-care system running on Java, and how they plan to Open Source the code.
However, the article does get one thing wrong that many CS people would froth at the mouth over: Gosling did not invent Emacs. Rather, he wrote the first UNIX version of it. You can find out more at:
http://vh213601.truman.edu/~jay/Brief_History_Emacs.html
Gosling _created_ emacs 20 years ago??? I never heard of this, I thought it should be RMS!
Did no not even read the one and only comment that was there at the time before posting?
from Hashem’s link
http://vh213601.truman.edu/~jay/Brief_History_Emacs.html
first ever version of Emacs (as extension of TECO editor runs on ITS os on PDP-10 machine) — by someone
first version of Emacs on UNIX — by Gosling
GNU Emacs — by RMS
it’s pretty clear
—-
btw,
i like Gosling’s current project — Jackpot IDE
http://research.sun.com/projects/jackpot/
(does it the same with year-ago Ace project?)
Actually, the bulk of the extensions to TECO (and the choice of the name Emacs) were made by RMS.
I hear Mr. Gosling saying the same lie again and again: “C# is not safe because of unsafe code, Java is”. The only difference between C# and Java regarding unsafe code is that C# has the support built in directly into the language and Java loads DLLs. So you can screw yourself exactly the same way in Java and actually it is more easier in Java thanks to its cumbersome JNI interface. And, using one language to write your program is much better than using Java and then some C/C++ for attached DLLs.
Some variant of “unsafe code” is always needed in a language if you want to access low-level libraries like win32 api, posix etc., and it is much better to support it directly in the language, like C# does.
Look again at the C# an CLI specs. C# allows you to write unmagaged code inline via the unsafe keyword. Additionally if you look at the CLI bytecode spec, you’ll see that all the runtime boands checking that the JavaVM has, doesn’t exist. This makes it impossible to have the equivelent of the Java bytecode verifier, that can look at code at load time, and verify that they cannot do any non sactioned memory manipulation.
From the article:
C and C++ enable developers to exploit system weaknesses, he said. “You can get around any interface that is intrinsic in C and C++.” However, “in Java I took the position that the integrity of interfaces had to be respected,” Gosling said. “And that translated to be a big deal in security and reliability.”
I have spent years tracking down bugs in C/C++ and so I really appreciate Java’s safety features. However, I can’t help but feel the glory days of programming out in the open are coming to an end, with all these restrictions and protections and what not. All for the sake of productivity. What percentage of programmers today use assembly language even occasionally?
> Look again at the C# an CLI specs. C# allows you to write
> unmagaged code inline via the unsafe keyword.
And whats the diff between ability to write inline unsafe code (which is clearly marked!) and ability of loading DLLs ? I dont get it.
> Additionally if you look at the CLI bytecode spec, you’ll
> see that all the runtime boands checking that the JavaVM
> has, doesn’t exist. This makes it impossible to have the
> equivelent of the Java bytecode verifier,
This is just not true AT ALL. DotNet _HAS_ verifier, and the standard way is to write verifiable code. You just dont have to.