4 ms·

"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

"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.
Nitramp 16y ago
> Pascal has a lesser "complexity budget" than C. Well, the point of the "complexity budget" idea is that you just have a fixed budget, and can spend it on things. So everybody gets the same budget - maybe Pascal just didn't spend parts of what'd been available. Regardless, as I said, this is not about good or bad programmers. The shell (i.e., not the horrible abomination called "command line" on Windows) is not a complex tool. The number of different concepts in a shell like bash is actually quite low - commands, functions, environment variables, substitution, globbing, if, for, pipes & streams. Escaping is a bit idiosyncratic, but hey. I'd even argue that using a well designed shell command is actually simpler than using a Windows wizard - the number of concepts and hoops you have to jump through are less, you just have to learn a limited number of concepts once. Same goes for Erlang. That's actually a remarkably simple language. Once you wrap your head around functional programming, to the point where it could use some more complexity IMHO (like better typing/structs). Understood like that, the "complexity budget" is actually a valid concept. Languages have features (concepts), and they tend to interact with each other (e.g. static, initializers, final and constructors in Java). If you have to many of them, the interactions get unpredictable and messy, and the language has too many concepts to keep in mind easily at the same time. I'm not arguing for dumbing things down to the minimum here. Complex features are fine if they give power, but having too many of them, and possibly ill designed ones, will yield an unnecessarily difficult language. The difficulty of language design is IMHO what to take, what to leave out, and how to pick features to give a maximum of power/expressivity with the minimum complexity.

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.

Nitramp 16y ago

> Pascal has a lesser "complexity budget" than C. Well, the point of the "complexity budget" idea is that you just have a fixed budget, and can spend it on things. So everybody gets the same budget - maybe Pascal just didn't spend parts of what'd been available. Regardless, as I said, this is not about good or bad programmers. The shell (i.e., not the horrible abomination called "command line" on Windows) is not a complex tool. The number of different concepts in a shell like bash is actually quite low - commands, functions, environment variables, substitution, globbing, if, for, pipes & streams. Escaping is a bit idiosyncratic, but hey. I'd even argue that using a well designed shell command is actually simpler than using a Windows wizard - the number of concepts and hoops you have to jump through are less, you just have to learn a limited number of concepts once. Same goes for Erlang. That's actually a remarkably simple language. Once you wrap your head around functional programming, to the point where it could use some more complexity IMHO (like better typing/structs). Understood like that, the "complexity budget" is actually a valid concept. Languages have features (concepts), and they tend to interact with each other (e.g. static, initializers, final and constructors in Java). If you have to many of them, the interactions get unpredictable and messy, and the language has too many concepts to keep in mind easily at the same time. I'm not arguing for dumbing things down to the minimum here. Complex features are fine if they give power, but having too many of them, and possibly ill designed ones, will yield an unnecessarily difficult language. The difficulty of language design is IMHO what to take, what to leave out, and how to pick features to give a maximum of power/expressivity with the minimum complexity.