9 ms·

While i can see his point, I'm not entirely sure this is the case. A text-book example of a multi-paradigm language is Scala. And yet with Scala, the more I've

by Aqueous 13y ago

While i can see his point, I'm not entirely sure this is the case. A text-book example of a multi-paradigm language is Scala. And yet with Scala, the more I've learned about the functional side of things, the more tempting it is just to avoid any imperative or object-oriented idioms or patterns and just go functional all the way. it's almost as if the designers of scala knew if they could convert java programmers over, the temptation to do bad things would go away if only because functional is so much more elegant that it doesn't make sense not to use it as much as possible.

seanmcdirmid 13y ago
My experience with Scala was the opposite: it has great support for OO and imperative programming. The functional way of doing things often wasn't better, while on the other hand, traits are crazy flexible. I've seen people go crazy with functional code in Scala that is barely readable and impossible to debug; the JVM debugger is still optimize for imperative programs, while no one has really figured out a good debugger for functional programming yet. OO/imperative programming isn't all "bad." Being functional doesn't really ensure that the code is "good."
- justinpombrio 13y ago
  "There is no programming language, no matter how structured, that will prevent programmers from making bad programs." - Larry Flon The same applies to programming paradigms.
  - nightski 13y ago
    There are many programming languages, specifically structured, to prevent programmers from making a certain subset of bad programs. This is incredibly useful.
    - marshray 13y ago
      Yeah, but these languages tend to be not a good fit for inherently complex problems. When one tries to express complex ideas in those languages, you end up code that's either absurdly verbose, or code that experts in that language's idioms would call "bad". One can write simple, structured code for simple problems in any language. But complex problems require languages that don't attempt to babysit programmers. (IMNSHX, YMMV)
      - seanmcdirmid 13y ago
        Some languages like Haskell put you in a purity (chastity?) belt; if you can code your solution there, you can code it anywhere. The problem is knowing your problem well enough to code it in Haskell...while a lot of time we are writing code to understand our problem (prototyping, experimentation). Some people live in a world where they understand their problems before writing code, and all their code is expected to immediately hit production. Scala is quite flexible and can accept good and bad code, which is good. I was only calling out FP abuses and its promotion as some sort of holy grail that is so much better than objects. If you compare Scala FP to Java OOP, ya, Scala FP is better, but if you compare Scala FP to Scala OOP, it's a much fairer battle and I put my faith in the latter (with the caveat that I can always use Scala FP when it makes sense to do so!).
        nightski 13y ago
        So what you are saying is that Haskell forces you to understand the problem for which you are implementing a solution, and this is bad because often that is too hard. Instead one should be able to just hack away until the code kind of does what they want (even though they can't prove anything about that piece of code) because that is the only way to really manage inherently complex problems? The older I get the less I find writing code an attractive method for understanding a problem. I also find utilizing something like a type system to enforce invariants in code liberating - and actually conducive to solving problems.
        SilasX 13y ago
        Well, it helps to be able to inspect your code at various stages to isolate which part of it isn't working right. In the pure functional paradigm, my programs are typically the composition of numerous functions. Now what if my program isn't doing what it should? (Contra FP advocates, it's possible for this to happen even if your program successful compiles.) You could have it output the value after each function is applied, but that would either break purity (by having I/O) or, per the GP's point, be tedious to write. At this point, the Haskell community made the decision that in debugging, "screw purity", and the output is effectively untyped. Certainly, you can use tests of expected invariants (eg QuickCheck), but that just tells you that the whole thing fails. That is, I think, also the GP's point: that the same things that make your final code good in Haskell, also make it hard to write. (No to say I don't like haskell; this is just a peeve,)
    - kaonashi 13y ago
      They can also prevent programmers from making a certain subset of good programs. This is less useful.
- eli_gottlieb 13y ago
  Scala was actually the first language in which I've truly appreciated object-oriented programming. It's really quite simple when you get it: Objects Are Modules. You do not want or need an object for everything (looking at you, Java!), but when you want to abstract away some combination of behavior and data, you do in fact want OOP.

by Aqueous 13y ago

seanmcdirmid 13y ago

My experience with Scala was the opposite: it has great support for OO and imperative programming. The functional way of doing things often wasn't better, while on the other hand, traits are crazy flexible. I've seen people go crazy with functional code in Scala that is barely readable and impossible to debug; the JVM debugger is still optimize for imperative programs, while no one has really figured out a good debugger for functional programming yet. OO/imperative programming isn't all "bad." Being functional doesn't really ensure that the code is "good."

justinpombrio 13y ago
"There is no programming language, no matter how structured, that will prevent programmers from making bad programs." - Larry Flon The same applies to programming paradigms.
- nightski 13y ago
  There are many programming languages, specifically structured, to prevent programmers from making a certain subset of bad programs. This is incredibly useful.
  - marshray 13y ago
    Yeah, but these languages tend to be not a good fit for inherently complex problems. When one tries to express complex ideas in those languages, you end up code that's either absurdly verbose, or code that experts in that language's idioms would call "bad". One can write simple, structured code for simple problems in any language. But complex problems require languages that don't attempt to babysit programmers. (IMNSHX, YMMV)
    - seanmcdirmid 13y ago
      Some languages like Haskell put you in a purity (chastity?) belt; if you can code your solution there, you can code it anywhere. The problem is knowing your problem well enough to code it in Haskell...while a lot of time we are writing code to understand our problem (prototyping, experimentation). Some people live in a world where they understand their problems before writing code, and all their code is expected to immediately hit production. Scala is quite flexible and can accept good and bad code, which is good. I was only calling out FP abuses and its promotion as some sort of holy grail that is so much better than objects. If you compare Scala FP to Java OOP, ya, Scala FP is better, but if you compare Scala FP to Scala OOP, it's a much fairer battle and I put my faith in the latter (with the caveat that I can always use Scala FP when it makes sense to do so!).
      - nightski 13y ago
        So what you are saying is that Haskell forces you to understand the problem for which you are implementing a solution, and this is bad because often that is too hard. Instead one should be able to just hack away until the code kind of does what they want (even though they can't prove anything about that piece of code) because that is the only way to really manage inherently complex problems? The older I get the less I find writing code an attractive method for understanding a problem. I also find utilizing something like a type system to enforce invariants in code liberating - and actually conducive to solving problems.
        SilasX 13y ago
        Well, it helps to be able to inspect your code at various stages to isolate which part of it isn't working right. In the pure functional paradigm, my programs are typically the composition of numerous functions. Now what if my program isn't doing what it should? (Contra FP advocates, it's possible for this to happen even if your program successful compiles.) You could have it output the value after each function is applied, but that would either break purity (by having I/O) or, per the GP's point, be tedious to write. At this point, the Haskell community made the decision that in debugging, "screw purity", and the output is effectively untyped. Certainly, you can use tests of expected invariants (eg QuickCheck), but that just tells you that the whole thing fails. That is, I think, also the GP's point: that the same things that make your final code good in Haskell, also make it hard to write. (No to say I don't like haskell; this is just a peeve,)
  - kaonashi 13y ago
    They can also prevent programmers from making a certain subset of good programs. This is less useful.
eli_gottlieb 13y ago
Scala was actually the first language in which I've truly appreciated object-oriented programming. It's really quite simple when you get it: Objects Are Modules. You do not want or need an object for everything (looking at you, Java!), but when you want to abstract away some combination of behavior and data, you do in fact want OOP.