4 ms·

I think the "subsetting the language" approach is a red herring. Yes, you can decide you'll only use feature X, Y, and Z. Many people do that in similarly compl

by Nitramp 16y ago

I think the "subsetting the language" approach is a red herring. Yes, you can decide you'll only use feature X, Y, and Z. Many people do that in similarly complex languages like C++. But the programmers will, one way or the other, get exposed to the features you considered esoteric. Be it through libraries, or sample code, or whatever. And then they have a piece of code in the language they use for daily work that they don't understand, can't debug, and are alienated by strange compiler errors - not good. It's IMHO also quite hard to come up with the subset you like. I mean, programmers like to have endless discussions about completely irrelevant topics, like brace placement; wait and see the discussions about actual language features to (not) use! Like I said in the other comment, most features are in themselves completely reasonable, so it's hard to make a cut here. I also think the 'mediocre programmer' is a red herring. Not that there aren't mediocre programmers that will have trouble to understand certain language features at all - there certainly are. But I'd wager that even for very good programmers, having many complex language features (that interact!) in a code base will be problematic. Of course you can understand what's going on with some effort on your side, but the problem is with the effort. Programming languages are IMHO a bit like user interfaces in this regard - "don't make me think". Having code in a code base that's complex and/or hard to understand is a really, really bad thing. People will shy away from reading and modifying it, and over time it'll grow into an unmaintained monstrosity. Again, this is about the complexity budget. Original Java code was dead easy to understand, now with generics it's a bit harder (but overall I think generics are less bad than you hear all the time). That was and still is one of the really killer Java features. Not only for mediocre programmers, but for general readability, and thus usability of the language.

plinkplonk 16y ago
"Of course you can understand what's going on with some effort on your side, but the problem is with the effort. Programming languages are IMHO a bit like user interfaces in this regard - "don't make me think"." By this logic no one would use the command line and Windows click thru wizards blow Unix away. I agree that guis are good for non programmers. Java is better than Scala for some subset of programmers. So is VB. The problem arises when that statement is modified to use the Universal Quantifier. The thing about a "powerful" programming language though (or for that matter a command line) is that it is a power tool. No one forces you to use it and you shouldn't if you feel it is too complex, but using some mythical "complexity budget" as if it were some kind of inviolable scientific fact is (imo) bogus. The "complexity budget" of anything is a function of the context of its use. As cemerick points out in another post here, Scala or Clojure (or Haskell or Erlang) will always have a "complexity" higher than VB or Java and that is fine. "Again, this is about the complexity budget." There is no such thing independent of the intent of the language designer and the context of the use of the tool. Scala and Erlang and Haskell are not intended to occupy the same "complexity point" as Java 1.4. So what? Pascal has a lesser "complexity budget" than C. That doesn't make the former uncontestably "better" independent of context. And anyway my original point was only that once you choose a language which you can't grasp all at once, for whatever reason, you should start programming with the subset you do understand rather than wait till you completely grok it. You can always choose to work with "low complexity" languages if that is what you want.
- jimbokun 16y ago
  "As cemerick points out in another post here, Scala or Clojure (or Haskell or Erlang) will always have a "complexity" higher than VB or Java and that is fine." I find the complexity budget of Clojure much lower than Java, and maybe VB, too (haven't programmed VB in a long time). In many ways, immutability by default, first class functions, and a library of higher order functions in the standard API make code much less complex with fewer concepts to understand than the corresponding Java code would be. The problem for many coming to Clojure is having to "unlearn" the "object oriented" Java concepts they already know (true for other functional languages, too, of course). Clojure leaves type declarations completely optional. It does not try to assemble disparate programming paradigms and integrate them into a coherent whole. The built in data structures all implement the seq interface, so you can use the same functions on all of them. Rich Hickey spent his complexity budget very well. I would rank Clojure with Scheme and Smalltalk in that regard.
  - plinkplonk 16y ago
    "I find the complexity budget of Clojure much lower than Java, and maybe VB, too (haven't programmed VB in a long time)." I am not disputing that you find Clojure easier than Java but if you include complete mastery of macros and laziness and functional programming idioms into the "complexity budget" it is very arguable that some Joe Blow developer would find Java easier to learn and read and consider Clojure "too complex". I am just pointing out that they are bogus reasons to reject a language. The OP is claiming that the deep type theory constructs of Scala are too difficult for him. Of course they are, just as deep macro fu would be hard for a Clojure beginner. Please don't mistake me. I prefer Clojure to Java any day. I am reacting to the idea that "too many parantheses" or "but macros are too complex" or "laziness is too hard to wrap my head around" or "Scala has a more powerful type system than I am used to" or "Erlang has too weird a syntax" etc are sufficient reasons to reject them. Back to Clojure. My (original) point is that you don't need to understand macros (say) in all their glory before you build something in Clojure. Use a macro-less or macro-lite subset and grow into macros as you gain experience. Yes you will write less than the best Clojure for a while. (Imho) that is fine (and unavoidable). Rejecting Clojure because you couldn't completely understand macros (or read "complex" code with lots of macros) is (imo) not an optimal strategy.
Raphael_Amiard 16y ago
I think you're missing the point. Of course ultimately a programmer has to master (to a point) the language he uses, even if he doesn't use all the features. I think GP's point was more "don't wait until you understood everything to start coding", and i must say i agree wholeheartedly
bpyne 16y ago
Java was not considered easy to understand back in 1997. There were cries about it being "too object-oriented". Developers were mostly used to procedural coding at the time. Thanks to hundreds of OO and Java books, along with the internet, developers came to see OO as a standard way of developing - Java benefited from that paradigm shift. (Good marketing helped as well.) We are entering another paradigm shift into functional programming. People are complaining about Scala's complexity but they are really more mystified by FP. Given time and lots of code sharing, FP and its representative languages will seem absolutely normal.
- kaffiene 16y ago
  That's absolutely not true. I was a C/C++ programmer at the time that Java came out and I remember all the hype being about Java being easy / quick to develop with. There were a tonne of studies out about how much more productive Java projects were compared to C/C++ projects. BTW I do not believe that we are seeing a paradigm shift to functional programming. Only inside HN's echo-chamber could you believe that. I do think that some ideas from FP are becoming more mainstream, such as closures, but what we are going to see is a cherry picking of the better features. I don't believe concepts like currying or monads are going to become popular any time soon.
crux_ 16y ago
> But the programmers will, one way or the other, get exposed to the features you considered esoteric. Be it through libraries, or sample code, or whatever. And then they have a piece of code in the language they use for daily work that they don't understand, can't debug, and are alienated by strange compiler errors - not good. Alternatively, this is a learning opportunity. Not automatically bad, either, especially if the resources are in place (especially mentoring) to really exploit it. And, (opinion warning!) unlike C++, in Scala the techniques & principles of the more pointy-headed stuff can often be reused in other settings.
abp 16y ago
First on Java generics: I don't understand all the complaints about generics anyway. They're very useful and not really hard to understand, basically. Besides the readability gain, you get compile time errors, or even hints in an ide for types that don't fit compared to casting from object to the type you expect to get. Also APIs are a lot more readable and expressive when you don't have a bunch of methods taking objects as parameters. I think the "subsetting the language" approach is a red herring. I don't think that the compatibility in syntax is meant for subsetting, but merely for approaching a language one step at a time. When you learn programming in a new language that has this advantage, you can start right away, using familiar concepts and learn more features as you need them. You can grow into the language. At least that was my approach in learning languages like VB.Net(oh yeah..), C# and Java for example. The specific advantages of each language come in when i try to simplify things or do something in a better way. Making the wall merely a ramp you can go up slowly instead of climbing right uphill. Also I'm interested in the way some programmer could/should be able to learn a whole language in depth before getting his hands dirty on a real project, working in a company.
- quicksilver03 16y ago
  I think that you lose readability with Java generics, rather than gain it, because of the ugly angle brackets which stand out far too much visually with respect to the other glyphs. By the way, I think the same about the "enhancements" proposed for Java 7 and 8, regardless of their technical merit.

by Nitramp 16y ago

plinkplonk 16y ago

"Of course you can understand what's going on with some effort on your side, but the problem is with the effort. Programming languages are IMHO a bit like user interfaces in this regard - "don't make me think"." By this logic no one would use the command line and Windows click thru wizards blow Unix away. I agree that guis are good for non programmers. Java is better than Scala for some subset of programmers. So is VB. The problem arises when that statement is modified to use the Universal Quantifier. The thing about a "powerful" programming language though (or for that matter a command line) is that it is a power tool. No one forces you to use it and you shouldn't if you feel it is too complex, but using some mythical "complexity budget" as if it were some kind of inviolable scientific fact is (imo) bogus. The "complexity budget" of anything is a function of the context of its use. As cemerick points out in another post here, Scala or Clojure (or Haskell or Erlang) will always have a "complexity" higher than VB or Java and that is fine. "Again, this is about the complexity budget." There is no such thing independent of the intent of the language designer and the context of the use of the tool. Scala and Erlang and Haskell are not intended to occupy the same "complexity point" as Java 1.4. So what? Pascal has a lesser "complexity budget" than C. That doesn't make the former uncontestably "better" independent of context. And anyway my original point was only that once you choose a language which you can't grasp all at once, for whatever reason, you should start programming with the subset you do understand rather than wait till you completely grok it. You can always choose to work with "low complexity" languages if that is what you want.

jimbokun 16y ago
"As cemerick points out in another post here, Scala or Clojure (or Haskell or Erlang) will always have a "complexity" higher than VB or Java and that is fine." I find the complexity budget of Clojure much lower than Java, and maybe VB, too (haven't programmed VB in a long time). In many ways, immutability by default, first class functions, and a library of higher order functions in the standard API make code much less complex with fewer concepts to understand than the corresponding Java code would be. The problem for many coming to Clojure is having to "unlearn" the "object oriented" Java concepts they already know (true for other functional languages, too, of course). Clojure leaves type declarations completely optional. It does not try to assemble disparate programming paradigms and integrate them into a coherent whole. The built in data structures all implement the seq interface, so you can use the same functions on all of them. Rich Hickey spent his complexity budget very well. I would rank Clojure with Scheme and Smalltalk in that regard.
- plinkplonk 16y ago
  "I find the complexity budget of Clojure much lower than Java, and maybe VB, too (haven't programmed VB in a long time)." I am not disputing that you find Clojure easier than Java but if you include complete mastery of macros and laziness and functional programming idioms into the "complexity budget" it is very arguable that some Joe Blow developer would find Java easier to learn and read and consider Clojure "too complex". I am just pointing out that they are bogus reasons to reject a language. The OP is claiming that the deep type theory constructs of Scala are too difficult for him. Of course they are, just as deep macro fu would be hard for a Clojure beginner. Please don't mistake me. I prefer Clojure to Java any day. I am reacting to the idea that "too many parantheses" or "but macros are too complex" or "laziness is too hard to wrap my head around" or "Scala has a more powerful type system than I am used to" or "Erlang has too weird a syntax" etc are sufficient reasons to reject them. Back to Clojure. My (original) point is that you don't need to understand macros (say) in all their glory before you build something in Clojure. Use a macro-less or macro-lite subset and grow into macros as you gain experience. Yes you will write less than the best Clojure for a while. (Imho) that is fine (and unavoidable). Rejecting Clojure because you couldn't completely understand macros (or read "complex" code with lots of macros) is (imo) not an optimal strategy.

Raphael_Amiard 16y ago

I think you're missing the point. Of course ultimately a programmer has to master (to a point) the language he uses, even if he doesn't use all the features. I think GP's point was more "don't wait until you understood everything to start coding", and i must say i agree wholeheartedly

bpyne 16y ago

Java was not considered easy to understand back in 1997. There were cries about it being "too object-oriented". Developers were mostly used to procedural coding at the time. Thanks to hundreds of OO and Java books, along with the internet, developers came to see OO as a standard way of developing - Java benefited from that paradigm shift. (Good marketing helped as well.) We are entering another paradigm shift into functional programming. People are complaining about Scala's complexity but they are really more mystified by FP. Given time and lots of code sharing, FP and its representative languages will seem absolutely normal.

kaffiene 16y ago
That's absolutely not true. I was a C/C++ programmer at the time that Java came out and I remember all the hype being about Java being easy / quick to develop with. There were a tonne of studies out about how much more productive Java projects were compared to C/C++ projects. BTW I do not believe that we are seeing a paradigm shift to functional programming. Only inside HN's echo-chamber could you believe that. I do think that some ideas from FP are becoming more mainstream, such as closures, but what we are going to see is a cherry picking of the better features. I don't believe concepts like currying or monads are going to become popular any time soon.

crux_ 16y ago

> But the programmers will, one way or the other, get exposed to the features you considered esoteric. Be it through libraries, or sample code, or whatever. And then they have a piece of code in the language they use for daily work that they don't understand, can't debug, and are alienated by strange compiler errors - not good. Alternatively, this is a learning opportunity. Not automatically bad, either, especially if the resources are in place (especially mentoring) to really exploit it. And, (opinion warning!) unlike C++, in Scala the techniques & principles of the more pointy-headed stuff can often be reused in other settings.

abp 16y ago

First on Java generics: I don't understand all the complaints about generics anyway. They're very useful and not really hard to understand, basically. Besides the readability gain, you get compile time errors, or even hints in an ide for types that don't fit compared to casting from object to the type you expect to get. Also APIs are a lot more readable and expressive when you don't have a bunch of methods taking objects as parameters. I think the "subsetting the language" approach is a red herring. I don't think that the compatibility in syntax is meant for subsetting, but merely for approaching a language one step at a time. When you learn programming in a new language that has this advantage, you can start right away, using familiar concepts and learn more features as you need them. You can grow into the language. At least that was my approach in learning languages like VB.Net(oh yeah..), C# and Java for example. The specific advantages of each language come in when i try to simplify things or do something in a better way. Making the wall merely a ramp you can go up slowly instead of climbing right uphill. Also I'm interested in the way some programmer could/should be able to learn a whole language in depth before getting his hands dirty on a real project, working in a company.

quicksilver03 16y ago
I think that you lose readability with Java generics, rather than gain it, because of the ugly angle brackets which stand out far too much visually with respect to the other glyphs. By the way, I think the same about the "enhancements" proposed for Java 7 and 8, regardless of their technical merit.