(1) Gosling did a good job designing a new language from scratch.
(2) Sun, IBM, and a whole lot of other contributors managed to turn Java into a successful enterprise platform that was better than other commercially viable platforms at the time.
(1) is false, (2) is true.
Is that too cerebral or intellectual for you to understand?
Yeah, Java is Gosling's Emacs all over again. It started with a poor imitation (Mocklisp) of a real programming language. He initially distributed it "free" under uncertain licensing terms, then he turned around and made the source code proprietary and caused trouble for free software.
At the time Java was up against C, C++, VB and Delphi as the key development languages off mainframe.
Neither the popular alternatives at the time, nor the success of the language, say anything about Gosling's competency as a language designer. And those other languages were saddled by backwards compatibility; Gosling had the luxury of starting from scratch and he screwed up.
I'd say that by v1.1 and definitely by v1.2 it was more usable with better features
Yeah, after a lot of other people helped patch up some of the worst problems with the language design.
Why don't you come up with benchmarks support your claim? Oh, I see, there are none. The question is not decidable based on benchmarks.
Statistics are all around us, rest my case.
You want statistics? Look at C# vs C++: C# is about to overtake C++ in its popularity. Why? Because C++'s popularity was largely based on its adoption by Microsoft.
Shall not argue anymore -- as you ruin yourself with those other languages (some of which I am also very fond of), I'll bring myself to a shining shine of a shine.
Spoken like the kind of geek who writes software only for himself. Try managing larger projects in C++, try hiring experienced C++ programmers, try fixing bugs in other people's convoluted C++ pointer code for a change.
You can get rollup keyboards today and the keys are not flat. However, they're rubber and they compress when you roll the thing up. They are not as nice as rigid full size keyboards, but I find them nicer than rigid smaller keyboards. In this case (and only in this case:-), size matters more than rigidity.
Java's design had a whole bunch of problems that a competent language designer in the 1990's should have been able to avoid (in the object system, number system, error handling, etc.), given that there was almost nothing new in Java. So, in that sense, Gosling did a piss poor job. Java itself still ended up being a significant improvement over C/C++ for most people, simply because C/C++ set the bar so low.
(Many of these problems with Java then got fixed by an army of language lawyers and specialists. Unfortunately, they introduced new problems into Java, as did decisions due to Sun's proprietary interests.)
Are you really such a novice to think that this sort of thing can be benchmarked?
Tell you what: you program in whatever braindead language you want; just don't expect that other people stand by quietly when you make such ridiculous claims.
After all, why would anyone ever want the compiler to do this work for them when they can just separately maintain a set of tests which do the same thing?
You rarely need to write separate unit tests to check type correctness; other unit tests give you that for free, so there is essentially no extra work involved.
And why would you want to use a dynamically typed language and rely on unit test for type checking? While static type checking for 1970's style Pascal-like languages is simple, but static type checking for modern programming languages comes at a high cost: complex type systems, odd restrictions on language constructs and programs, bad compiler error messages, etc.
Reality says you're full of shit. I've personally worked on a project which was C++. Three small teams created over 450k lines of code with roughly 100k of that being unit tests. Integration was less than 30-days. We identified two leaks. Both turned out to be in the platform's OS and standard library. And to be absolutely clear, these results are hardly unique.
So you think that because your code passed 100k of unit tests it doesn't contain serious errors? You really are naive.
There is no way of ascertaining the correctness of C++ code through testing because there is no guarantee that runtime errors will have any effect. In fact, many serious errors don't even show up until you change optimization flags, a new version of the compiler comes out, or you start porting. Your code can work perfectly today and stop working tomorrow for no apparent reason.
When you're entire point of posting is to either prove to the world you're an idiot or worse, simply desire to troll, just don't post as it makes the world a better place.
You have the Dunning-Kruger problem: you know so little that you don't even realize how poor your understanding is.
Gosling going to Google is an obvious choice. However, I seriously doubt he has anything to contribute other than name recognition. Gosling did a piss poor job on the design and evolution of Java to begin with.
Static typing is nice but not essential if you have decent unit tests. Much more important are type safety, fault detection, and fault isolation, and C++ lacks those. There is no way you can reliably recover from a runtime error in C++. That makes C++ an extremely poor choice for any application where the results are important.
Ideally, you want a statically typed language with type safety, fault detection, and fault isolation. Java and C# give you that, albeit they have practical problems.
The next best practical thing are dynamically typed languages with type safety, fault detection, and fault isolation, and there are a bunch of those around.
C/C++ are only reasonable choices if (1) performance is more important than correctness and reliability, and (2) you have a large supply of extremely smart, patient, and experienced programmers and no deadlines.
Actually, people like you write crappy code, create buffer overflows, fill up memory, and bring everybody's computers to a crawl, and you are so inexperienced, you don't even realize it.
If we start to turn C++ into one of those languages that are better for some particular situations, it'll lose its speed and its reliability
C++ has never had "speed and reliability". Nobody can realistically write a C++ program of substantial size that doesn't have serious errors. And C++ code only runs fast if you invest a shitload of time trying to get rid of all the high-overhead crap that its standard libraries do.
If you don't like C++ then don't you use, just don't appeal to dumbing it down from its purpose -- to fit every purpose!
What concerns me is that there are a lot of people like you who live with the delusion that C++ is actually "fast and reliable", and you people write software.
I don't think the methodology is necessarily bad: concepts like hierarchies, is-a relationships, abstract interfaces, encapsulation, patterns, binding, classes, inheritance, etc. are useful and they are something that beginning developers need a couple of semesters to learn and understand. There's nothing "ivory tower" about them, it's just software craftsmanship and terminology, but even craftsmanship needs to be taught, and it needs to be taught in college as part of a CS curriculum.
What's bad is the mistake of identifying objects in your system with objects in the real world; that is often the wrong approach. But just because many people (and professors) make that mistake doesn't invalidate the rest of object oriented design or methodology.
Also, you have to compare this to the alternatives. There is even less coherent methodology or design in functional programming. Most real-world functional programs that I have seen are incomprehensible spaghetti code. Look at the code for darcs or unison, two useful real-world tools written in functional languages, with lots of comments and documentation: the code itself still looks like crap, with lists and tuples of uncertain meaning used and passed around all over the place.
Non-US engine designers are always amazed at how little horsepower the USA engineers get per unit of engine capacity.
Non-US designers have traditionally been taxed by volume, so they had an incentive to keep it small. From an engineering point of view, smaller volume doesn't necessarily translate into good engine design.
All his diatribe says is that the Expensify CEO is a pointy haired boss who reasons by McDonalds analogies. Given Expensify's dull and obvious product (useful though it is), perhaps that shouldn't be surprising.
Many cultures have inequality and hereditary entitlements, but those are quite different from the Indian caste system. Point is: India's "beautiful culture" has a dark side as well.
Nowhere did I claim that the British fixed anything. Maybe you should learn to read properly.
The Java/C++ model of O-O pretty much forces side effects and object mutation on you.
No, they don't. You can merrily code away using very little state or mutation: don't provide mutators, use binding instead of assignment, etc. Same, actually, as in Scheme or even SML (which also has mutation). Experienced programmers will do just that.
There's a whole lot wrong with the OOP concept and methodologies. Modeling business entities as classes, encapsulating behavior in those entities, and so on.
Well, yeah, that's wrong. But just because you abstracted your problem badly doesn't mean that the abstraction mechanism itself is bad.
In most cases, there are natural abstractions in business apps: "server", "database", "dictionary", "list of results", "window", etc. These abstractions have little to do with the ontology or objects that are being modeled, but they have everything to do with how the application works. And those abstractions are good ones.
Class hierarchies are supposed to reflect a natural ontology, whereas modules are supposed to organize the source code into independent libraries
There is no reason why one mechanism can't be used for both purposes. There is no rule that says you need a separate language construct for each separate concept; if there were, Java, C++, and other languages would be even more complicated than they are.
OO languages are definitely also anti-parallel, because object systems are based on mutation. At least in all OO languages I'm aware of (plenty) objects are mutable structures. Mutation and concurrency really don't fare well.
Yeah, that's the party line, but it's bullshit. Most parallel code in the world is written in imperative languages. People have no trouble doing that.
What you can't do easily is transform sequential imperative code into parallel code. But you know what? Despite decades of trying, people haven't been able to do that in any practically useful way for functional programming languages either.
These people have been drinking too much magic cool aid. Verification of software has never and will always be an obscure, special-purpose technique; it will never go mainstream, not just because it doesn't actually work, but because few people are capable of doing it. And ML-style functional programming has been around for ages and has never amounted to much either.
And to say that "object-oriented programming is anti-modular and anti-parallel by its very nature" is idiotic; whether it is modular and parallel depends on the abstractions you implement in it. Of course, you can't automatically parallelize arbitrary messy object-oriented code. But, you know what? You can't even parallelize arbitrary functional code well in the real world (even though theoretically it looks like you ought to be able to).
If people want to teach functional programming as part of an introductory class, they should go back to the tried-and-true: Scheme and SIPC.
Competition is healthy. But for competition to work, you need a rational and informed consumer. Smartphone buyers are obviously not rational, otherwise the iPhone would not sell given how overpriced and limited it is.
Smartphone and tablet success right now is determined by marketing, brand, reputation, carriers, and app stores. And to improve those, having a large number of ultra low price tablets is not so good. Among other things, Motorola and HTC would be much less inclined to advertise Android 3.0 if that kind of advertising also helps their competition.
I think it's fine for Google to give Motorola a six month head start.
You really need to stop with the "one size fits all, what's right for one thing is right for everything" mentality. It's a fallacy.
I am all for reducing or eliminating regulation in most areas. But for cell phones in particular, the current US system isn't working, and regulation is needed.
The rest of your post is not worth a response...
Well, that's probably because you didn't understand a word of it. Before you go off talking about markets and regulations, read up a bit about basic economics. Someone who confuses "inefficient" with "ineffective" really has no business arguing about economics at all.
Slashdot Mirror
Two separate concepts:
(1) Gosling did a good job designing a new language from scratch.
(2) Sun, IBM, and a whole lot of other contributors managed to turn Java into a successful enterprise platform that was better than other commercially viable platforms at the time.
(1) is false, (2) is true.
Is that too cerebral or intellectual for you to understand?
Yeah, Java is Gosling's Emacs all over again. It started with a poor imitation (Mocklisp) of a real programming language. He initially distributed it "free" under uncertain licensing terms, then he turned around and made the source code proprietary and caused trouble for free software.
Neither the popular alternatives at the time, nor the success of the language, say anything about Gosling's competency as a language designer. And those other languages were saddled by backwards compatibility; Gosling had the luxury of starting from scratch and he screwed up.
Yeah, after a lot of other people helped patch up some of the worst problems with the language design.
Yeah, because we all know: what's popular is obviously well designed! Just look at Windows, or McDonalds for that matter.
No wonder you signed your post "Moron".
Why don't you come up with benchmarks support your claim? Oh, I see, there are none. The question is not decidable based on benchmarks.
You want statistics? Look at C# vs C++: C# is about to overtake C++ in its popularity. Why? Because C++'s popularity was largely based on its adoption by Microsoft.
Spoken like the kind of geek who writes software only for himself. Try managing larger projects in C++, try hiring experienced C++ programmers, try fixing bugs in other people's convoluted C++ pointer code for a change.
You can get rollup keyboards today and the keys are not flat. However, they're rubber and they compress when you roll the thing up. They are not as nice as rigid full size keyboards, but I find them nicer than rigid smaller keyboards. In this case (and only in this case :-), size matters more than rigidity.
Named parameters and type inference were widely considered good ideas long before C# adopted them and are part of most modern programming languages.
The fact that you dislike them suggests that Java's limitations have really warped your mind.
Java's design had a whole bunch of problems that a competent language designer in the 1990's should have been able to avoid (in the object system, number system, error handling, etc.), given that there was almost nothing new in Java. So, in that sense, Gosling did a piss poor job. Java itself still ended up being a significant improvement over C/C++ for most people, simply because C/C++ set the bar so low.
(Many of these problems with Java then got fixed by an army of language lawyers and specialists. Unfortunately, they introduced new problems into Java, as did decisions due to Sun's proprietary interests.)
Are you really such a novice to think that this sort of thing can be benchmarked?
Tell you what: you program in whatever braindead language you want; just don't expect that other people stand by quietly when you make such ridiculous claims.
You rarely need to write separate unit tests to check type correctness; other unit tests give you that for free, so there is essentially no extra work involved.
And why would you want to use a dynamically typed language and rely on unit test for type checking? While static type checking for 1970's style Pascal-like languages is simple, but static type checking for modern programming languages comes at a high cost: complex type systems, odd restrictions on language constructs and programs, bad compiler error messages, etc.
So you think that because your code passed 100k of unit tests it doesn't contain serious errors? You really are naive.
There is no way of ascertaining the correctness of C++ code through testing because there is no guarantee that runtime errors will have any effect. In fact, many serious errors don't even show up until you change optimization flags, a new version of the compiler comes out, or you start porting. Your code can work perfectly today and stop working tomorrow for no apparent reason.
You have the Dunning-Kruger problem: you know so little that you don't even realize how poor your understanding is.
Gosling going to Google is an obvious choice. However, I seriously doubt he has anything to contribute other than name recognition. Gosling did a piss poor job on the design and evolution of Java to begin with.
Static typing is nice but not essential if you have decent unit tests. Much more important are type safety, fault detection, and fault isolation, and C++ lacks those. There is no way you can reliably recover from a runtime error in C++. That makes C++ an extremely poor choice for any application where the results are important.
Ideally, you want a statically typed language with type safety, fault detection, and fault isolation. Java and C# give you that, albeit they have practical problems.
The next best practical thing are dynamically typed languages with type safety, fault detection, and fault isolation, and there are a bunch of those around.
C/C++ are only reasonable choices if (1) performance is more important than correctness and reliability, and (2) you have a large supply of extremely smart, patient, and experienced programmers and no deadlines.
Actually, people like you write crappy code, create buffer overflows, fill up memory, and bring everybody's computers to a crawl, and you are so inexperienced, you don't even realize it.
C++ has never had "speed and reliability". Nobody can realistically write a C++ program of substantial size that doesn't have serious errors. And C++ code only runs fast if you invest a shitload of time trying to get rid of all the high-overhead crap that its standard libraries do.
What concerns me is that there are a lot of people like you who live with the delusion that C++ is actually "fast and reliable", and you people write software.
I don't think the methodology is necessarily bad: concepts like hierarchies, is-a relationships, abstract interfaces, encapsulation, patterns, binding, classes, inheritance, etc. are useful and they are something that beginning developers need a couple of semesters to learn and understand. There's nothing "ivory tower" about them, it's just software craftsmanship and terminology, but even craftsmanship needs to be taught, and it needs to be taught in college as part of a CS curriculum.
What's bad is the mistake of identifying objects in your system with objects in the real world; that is often the wrong approach. But just because many people (and professors) make that mistake doesn't invalidate the rest of object oriented design or methodology.
Also, you have to compare this to the alternatives. There is even less coherent methodology or design in functional programming. Most real-world functional programs that I have seen are incomprehensible spaghetti code. Look at the code for darcs or unison, two useful real-world tools written in functional languages, with lots of comments and documentation: the code itself still looks like crap, with lists and tuples of uncertain meaning used and passed around all over the place.
Non-US designers have traditionally been taxed by volume, so they had an incentive to keep it small. From an engineering point of view, smaller volume doesn't necessarily translate into good engine design.
All his diatribe says is that the Expensify CEO is a pointy haired boss who reasons by McDonalds analogies. Given Expensify's dull and obvious product (useful though it is), perhaps that shouldn't be surprising.
Many cultures have inequality and hereditary entitlements, but those are quite different from the Indian caste system. Point is: India's "beautiful culture" has a dark side as well.
Nowhere did I claim that the British fixed anything. Maybe you should learn to read properly.
No, they don't. You can merrily code away using very little state or mutation: don't provide mutators, use binding instead of assignment, etc. Same, actually, as in Scheme or even SML (which also has mutation). Experienced programmers will do just that.
Well, yeah, that's wrong. But just because you abstracted your problem badly doesn't mean that the abstraction mechanism itself is bad.
In most cases, there are natural abstractions in business apps: "server", "database", "dictionary", "list of results", "window", etc. These abstractions have little to do with the ontology or objects that are being modeled, but they have everything to do with how the application works. And those abstractions are good ones.
There is no reason why one mechanism can't be used for both purposes. There is no rule that says you need a separate language construct for each separate concept; if there were, Java, C++, and other languages would be even more complicated than they are.
Yeah, that's the party line, but it's bullshit. Most parallel code in the world is written in imperative languages. People have no trouble doing that.
What you can't do easily is transform sequential imperative code into parallel code. But you know what? Despite decades of trying, people haven't been able to do that in any practically useful way for functional programming languages either.
These people have been drinking too much magic cool aid. Verification of software has never and will always be an obscure, special-purpose technique; it will never go mainstream, not just because it doesn't actually work, but because few people are capable of doing it. And ML-style functional programming has been around for ages and has never amounted to much either.
And to say that "object-oriented programming is anti-modular and anti-parallel by its very nature" is idiotic; whether it is modular and parallel depends on the abstractions you implement in it. Of course, you can't automatically parallelize arbitrary messy object-oriented code. But, you know what? You can't even parallelize arbitrary functional code well in the real world (even though theoretically it looks like you ought to be able to).
If people want to teach functional programming as part of an introductory class, they should go back to the tried-and-true: Scheme and SIPC.
Competition is healthy. But for competition to work, you need a rational and informed consumer. Smartphone buyers are obviously not rational, otherwise the iPhone would not sell given how overpriced and limited it is.
Smartphone and tablet success right now is determined by marketing, brand, reputation, carriers, and app stores. And to improve those, having a large number of ultra low price tablets is not so good. Among other things, Motorola and HTC would be much less inclined to advertise Android 3.0 if that kind of advertising also helps their competition.
I think it's fine for Google to give Motorola a six month head start.
I am all for reducing or eliminating regulation in most areas. But for cell phones in particular, the current US system isn't working, and regulation is needed.
Well, that's probably because you didn't understand a word of it. Before you go off talking about markets and regulations, read up a bit about basic economics. Someone who confuses "inefficient" with "ineffective" really has no business arguing about economics at all.