3 ms·

The heavy emphasis on classes is what is strange about it. Many programmers don't realize the strangeness since they've used classes their entire careers. A cla

The heavy emphasis on classes is what is strange about it. Many programmers don't realize the strangeness since they've used classes their entire careers. A class isn't really a procedural concept. Nothing in a processor knows what a class is. It's more of a modeling language with an assumption that you'll architect your program to group similar methods into abstract trees of domain concepts, with your data at the leaves (instances). So we're stuck with these complicated compile-time rules for defining everything in terms of a procedural language. We come up with complicated templates and generics for getting one set of methods to work with two types of data. Objects are needlessly serialized and deserialized to pass between systems, and programmers are needlessly spending time writing such methods. I'm surprised that scala's paradigm of having actors work on data hasn't caught on more. When you separate them from the start, new modules are way easier to right, and integration time drops to near zero.

jrochkind1 13y ago
I'm not sure that's it -- ruby also has a heavy evidence on classes, but encourages entirely different sorts of solutions. Sometimes for better, occasionally for worse, but rather than argue about that, my point is just _different_ -- if emphasis on classes was what led to designs like Java, ruby would lead to em too, but it doens't, so it much be something else. I do like the way jfb suggests using the concept of 'affordances' with languages/environments, to analyze what sorts of code they encourage. But to really do that, we'd have to actually identify these specific affordances, which i'm not sure how to either. (And as far as your particular line of argument -- does anything in a processor know what an 'actor' is either? If not, I believe you that you find 'actor' a better abstraction than 'class', but it must not have anything to with either one being something the lower-level computer architectural abstractions 'know about')
- jfb 13y ago
  I think software as a discipline (design, implementation, analysis) has a lot to learn from more traditional areas of UI research -- by which I mean design in the Donald Norman sense. Living off in the universe of Platonic forms of e.g. patterns for organizing patterns for organizing data is fascinating, but eventually we have to pause our theorizing and start inspecting the way humans come to grips with theory. There's a saying that one can write COBOL in any language, but nobody is born itching to POST INCREMENT C BY ONE. A given technology has a spirit; that spirit guides the usage of the technology; and people who use that technology, and share a sufficiency of that spirit, will find a welcoming home. That spirit is intrinsic to the technology; changing Java to not rely on Simula style classes for code namespacing would destroy Java -- it'd be something very different, and the usage of this new language would mean entirely new styles of conceptual organization. I'm not taking a stance in this post on the aesthetics of the various ways to organize programs; but I do think that the forensic exercise of determining the -- I dunno, zeitgeist? -- of a technology is an interesting, rich one.
jlgreco 13y ago
If I had to pin down Java's problem on one thing, I would say that its problem is really C. Or more accurately, the problem is that Java was a new language shoehorned into being "like" a language that was never meant to hold the concepts that Java demands. In some cases this manifests itself in more syntactical ways; C's pragmatic but unsophisticated approach typing works well for C, but starts to become a real burden when you start adding more sophisticated concepts onto the language. (Were generics really a concept that were ever appropriate for something like C? Generics deserve a more considered treatment; a language with structure and syntax designed with them in mind.) In other cases the impact is more clear but inexplicable; "In Java Everything is an Object"(tm)... except for the things that are not. The end result is a language that is ugly and clumsy to work with without some pretty advanced tooling, all for reasons that really have no business being real problems. Shameful (primarily cosmetic) flaws forced upon Java by the business decision: "make it reminiscent of C". I have the same complaint about C++. Had Java and C++ not burdened themselves with the design requirement of looking like C, they would be much better languages. Languages that stray further from the mold, like Scala or Go (I am thinking particularly of their abandonment of C inspired defines, in favor of a more Pascal approach), are more pleasant to work with for it. Perhaps this damages adoption.. but that is another matter I think.
- DougWebb 13y ago
  I don't think I agree with your analysis. C# was originally designed to look a lot more like Java than Java ever looked like C, but it hasn't been hampered by that and has evolved to be a much more advanced language than Java has. It also doesn't have the over-engineering culture that Java has (aside from a number of "Enterprise-Class" add-on libraries Microsoft has tried to push out.) The same could be said about Ruby and it's relationship to Perl and Python. It has cultural roots in those languages, but is often regarded to be better rather than worse. (As a die-hard Perl developer I disagree, but I don't hold a grudge.) All three are also considered to be C-like languages too, and they don't suffer the problems Java has. One could argue that Java's problem was that it was designed for programming VCRs, DVD players, and Cable-TV boxes, and similar equipment, but the got stretched and pulled into environments it just wasn't ready for. That, plus Sun's hyper-aggressive marketing machine to turn Java into the language-for-everything, created the beast that it has become. My personal view is that Sun turned Java into a programming language for charge-by-the-hour consultants. The culture of over-engineering exists because it takes a lot more time to design software that way, more time and larger teams to implement software that way, and specialized hard-to-transfer knowledge to maintain that kind of software. This all benefits the consultants and hurts the companies paying for the software to be built, which only makes sense if Sun was intentionally pushing Java that way.

jrochkind1 13y ago

I'm not sure that's it -- ruby also has a heavy evidence on classes, but encourages entirely different sorts of solutions. Sometimes for better, occasionally for worse, but rather than argue about that, my point is just _different_ -- if emphasis on classes was what led to designs like Java, ruby would lead to em too, but it doens't, so it much be something else. I do like the way jfb suggests using the concept of 'affordances' with languages/environments, to analyze what sorts of code they encourage. But to really do that, we'd have to actually identify these specific affordances, which i'm not sure how to either. (And as far as your particular line of argument -- does anything in a processor know what an 'actor' is either? If not, I believe you that you find 'actor' a better abstraction than 'class', but it must not have anything to with either one being something the lower-level computer architectural abstractions 'know about')

jfb 13y ago
I think software as a discipline (design, implementation, analysis) has a lot to learn from more traditional areas of UI research -- by which I mean design in the Donald Norman sense. Living off in the universe of Platonic forms of e.g. patterns for organizing patterns for organizing data is fascinating, but eventually we have to pause our theorizing and start inspecting the way humans come to grips with theory. There's a saying that one can write COBOL in any language, but nobody is born itching to POST INCREMENT C BY ONE. A given technology has a spirit; that spirit guides the usage of the technology; and people who use that technology, and share a sufficiency of that spirit, will find a welcoming home. That spirit is intrinsic to the technology; changing Java to not rely on Simula style classes for code namespacing would destroy Java -- it'd be something very different, and the usage of this new language would mean entirely new styles of conceptual organization. I'm not taking a stance in this post on the aesthetics of the various ways to organize programs; but I do think that the forensic exercise of determining the -- I dunno, zeitgeist? -- of a technology is an interesting, rich one.

jlgreco 13y ago

If I had to pin down Java's problem on one thing, I would say that its problem is really C. Or more accurately, the problem is that Java was a new language shoehorned into being "like" a language that was never meant to hold the concepts that Java demands. In some cases this manifests itself in more syntactical ways; C's pragmatic but unsophisticated approach typing works well for C, but starts to become a real burden when you start adding more sophisticated concepts onto the language. (Were generics really a concept that were ever appropriate for something like C? Generics deserve a more considered treatment; a language with structure and syntax designed with them in mind.) In other cases the impact is more clear but inexplicable; "In Java Everything is an Object"(tm)... except for the things that are not. The end result is a language that is ugly and clumsy to work with without some pretty advanced tooling, all for reasons that really have no business being real problems. Shameful (primarily cosmetic) flaws forced upon Java by the business decision: "make it reminiscent of C". I have the same complaint about C++. Had Java and C++ not burdened themselves with the design requirement of looking like C, they would be much better languages. Languages that stray further from the mold, like Scala or Go (I am thinking particularly of their abandonment of C inspired defines, in favor of a more Pascal approach), are more pleasant to work with for it. Perhaps this damages adoption.. but that is another matter I think.

DougWebb 13y ago
I don't think I agree with your analysis. C# was originally designed to look a lot more like Java than Java ever looked like C, but it hasn't been hampered by that and has evolved to be a much more advanced language than Java has. It also doesn't have the over-engineering culture that Java has (aside from a number of "Enterprise-Class" add-on libraries Microsoft has tried to push out.) The same could be said about Ruby and it's relationship to Perl and Python. It has cultural roots in those languages, but is often regarded to be better rather than worse. (As a die-hard Perl developer I disagree, but I don't hold a grudge.) All three are also considered to be C-like languages too, and they don't suffer the problems Java has. One could argue that Java's problem was that it was designed for programming VCRs, DVD players, and Cable-TV boxes, and similar equipment, but the got stretched and pulled into environments it just wasn't ready for. That, plus Sun's hyper-aggressive marketing machine to turn Java into the language-for-everything, created the beast that it has become. My personal view is that Sun turned Java into a programming language for charge-by-the-hour consultants. The culture of over-engineering exists because it takes a lot more time to design software that way, more time and larger teams to implement software that way, and specialized hard-to-transfer knowledge to maintain that kind of software. This all benefits the consultants and hurts the companies paying for the software to be built, which only makes sense if Sun was intentionally pushing Java that way.