5 ms·

> Some problems are complex and require complex solutions. And yet some very complex solutions were solved with very simple languages, before Java was conceive

> Some problems are complex and require complex solutions. And yet some very complex solutions were solved with very simple languages, before Java was conceived.

jfb 13y ago
Java is not a complicated language. Something about its affordances pushes developers into these giant labyrinthine swamps of abstraction violation, but the language isn't that complicated, either syntactically or semantically.
- casual_slacker 13y ago
  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.
- mpyne 13y ago
  As a mainly C++ developer, I agree with you 1000%
  - jfb 13y ago
    Exactly: C++ (or Scala, to pick a JVM example) is a complicated language. There are a lot of rules, and they interact in subtle ways, and therefore that's a real opportunity for spooky action-at-a-distance stuff. For better or worse, Java has much simpler semantics.
- Retric 13y ago
  Java is one of the most complex computor languages in existence, so unless your comparing it to English I really don't see where your comming from. Don't believe me try an make a compiler some time. PS: THE Java® SE 7 Edition of The Java Language Specification describes all the features that have been added to the Java programming language in Java SE 7. It also integrates changes made to the Java programming language under maintenance since the Third Edition in 2005. http://docs.oracle.com/javase/specs/jls/se7/jls7.pdf http://docs.oracle.com/javase/specs/jls/se7/jls7.pdf. It's 670 pages long.
  - Silhouette 13y ago
    THE Java® SE 7 Edition of The Java Language Specification [is] 670 pages long. Unfortunately, among the major industrial programming languages, that is far from the longest specification out there. Moreover, some of the major industrial programming languages don't even have a standard reference specification. Notwithstanding its length, the Java spec is actually fairly efficient and well-organised in comparison.
    - Retric 13y ago
      Ok, if your going to ignore 98% of all programming languages out there and focus on say the most popular 20 it's not that bad. However, there is a long tail to programming languages and some of them are actually simple, strait forward, and still useful for large progects even if not the 'Enerprise CRUD' variety.
      - Silhouette 13y ago
        I'm not disagreeing with your point about the long tail. I'm just saying that there are other languages that, by this metric, are significantly more complicated than Java, yet which don't get drowned under the weight of design pattern abstraction idiom pattern architectures. It seems whatever causes that effect in Java is not (only) how complicated the language is.
        Retric 13y ago
- Silhouette 13y ago
  Java is not a complicated language. Unfortunately, Java is also not a very powerful language. Many of those OO gymnastics are only relevant because the language isn't expressive enough to achieve the same results in a simpler, more direct way. Java is the language where design patterns in the Gang of Four sense first became popular, and it's often been suggested that design patterns indicate missing language features.
  - jlgreco 13y ago
    > it's often been suggested that design patterns indicate missing language features. Exactly right. In previous decades, had they been using modern terminology, calling conventions would no doubt be covered by plenty of "design patterns". We don't speak of calling conventions that way now because languages provide that for us.
redthrowaway 13y ago
Well, yes and no. I make no claims as to the validity of your arguments, but having spent the last two weeks writing a static bytecode verifier for the JVM, I'm prepared to say that it is, at minimum, more complex than I'd like it to be. Paradoxically, this assignment has given me a great deal of respect for the idiots who conceived of the damned thing in the first place.
- twelve40 13y ago
  If you decide to bump up the intensity with a strong statement or two, you'll need to be more clear on who exactly it applies to. The idiots who conceived the damned assignment? Or the ones who conceived the damned JVM?
prodigal_erik 13y ago
Except they weren't solved. After fifty years of trying, the number of programs we've produced that work correctly (no bugs and certainly no "undefined behavior") is damn close to zero. So far the best any known language can do is statically rule out just a few classes of low-level mistakes.
- Silhouette 13y ago
  So far the best any known language can do is statically rule out just a few classes of low-level mistakes. And if we actually used those languages, we would probably be seeing much lower bug rates in production software already and we could start looking into what else could be improved next. Unfortunately, most of the popular industrial languages don't even get that far. :-(

> Some problems are complex and require complex solutions. And yet some very complex solutions were solved with very simple languages, before Java was conceived.

jfb 13y ago

Java is not a complicated language. Something about its affordances pushes developers into these giant labyrinthine swamps of abstraction violation, but the language isn't that complicated, either syntactically or semantically.

casual_slacker 13y ago
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.
mpyne 13y ago
As a mainly C++ developer, I agree with you 1000%
- jfb 13y ago
  Exactly: C++ (or Scala, to pick a JVM example) is a complicated language. There are a lot of rules, and they interact in subtle ways, and therefore that's a real opportunity for spooky action-at-a-distance stuff. For better or worse, Java has much simpler semantics.
Retric 13y ago
Java is one of the most complex computor languages in existence, so unless your comparing it to English I really don't see where your comming from. Don't believe me try an make a compiler some time. PS: THE Java® SE 7 Edition of The Java Language Specification describes all the features that have been added to the Java programming language in Java SE 7. It also integrates changes made to the Java programming language under maintenance since the Third Edition in 2005. http://docs.oracle.com/javase/specs/jls/se7/jls7.pdf http://docs.oracle.com/javase/specs/jls/se7/jls7.pdf. It's 670 pages long.
- Silhouette 13y ago
  THE Java® SE 7 Edition of The Java Language Specification [is] 670 pages long. Unfortunately, among the major industrial programming languages, that is far from the longest specification out there. Moreover, some of the major industrial programming languages don't even have a standard reference specification. Notwithstanding its length, the Java spec is actually fairly efficient and well-organised in comparison.
  - Retric 13y ago
    Ok, if your going to ignore 98% of all programming languages out there and focus on say the most popular 20 it's not that bad. However, there is a long tail to programming languages and some of them are actually simple, strait forward, and still useful for large progects even if not the 'Enerprise CRUD' variety.
    - Silhouette 13y ago
      I'm not disagreeing with your point about the long tail. I'm just saying that there are other languages that, by this metric, are significantly more complicated than Java, yet which don't get drowned under the weight of design pattern abstraction idiom pattern architectures. It seems whatever causes that effect in Java is not (only) how complicated the language is.
      - Retric 13y ago
Silhouette 13y ago
Java is not a complicated language. Unfortunately, Java is also not a very powerful language. Many of those OO gymnastics are only relevant because the language isn't expressive enough to achieve the same results in a simpler, more direct way. Java is the language where design patterns in the Gang of Four sense first became popular, and it's often been suggested that design patterns indicate missing language features.
- jlgreco 13y ago
  > it's often been suggested that design patterns indicate missing language features. Exactly right. In previous decades, had they been using modern terminology, calling conventions would no doubt be covered by plenty of "design patterns". We don't speak of calling conventions that way now because languages provide that for us.

redthrowaway 13y ago

Well, yes and no. I make no claims as to the validity of your arguments, but having spent the last two weeks writing a static bytecode verifier for the JVM, I'm prepared to say that it is, at minimum, more complex than I'd like it to be. Paradoxically, this assignment has given me a great deal of respect for the idiots who conceived of the damned thing in the first place.

twelve40 13y ago
If you decide to bump up the intensity with a strong statement or two, you'll need to be more clear on who exactly it applies to. The idiots who conceived the damned assignment? Or the ones who conceived the damned JVM?

prodigal_erik 13y ago

Except they weren't solved. After fifty years of trying, the number of programs we've produced that work correctly (no bugs and certainly no "undefined behavior") is damn close to zero. So far the best any known language can do is statically rule out just a few classes of low-level mistakes.

Silhouette 13y ago
So far the best any known language can do is statically rule out just a few classes of low-level mistakes. And if we actually used those languages, we would probably be seeing much lower bug rates in production software already and we could start looking into what else could be improved next. Unfortunately, most of the popular industrial languages don't even get that far. :-(