5 ms·

"There is no programming language, no matter how structured, that will prevent programmers from making bad programs." - Larry Flon The same applies to programm

• 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,)
          • fulafel 13y ago
            you can't sprinkle debug prints in Haskell? really? (honest question)
            • argv_empty 13y ago
              Short answer: No, you can't. Long answer: You can, but Haskell is very serious about keeping pure code separate from impure code. Any function which performs I/O is impure, so its output must be an IO Thing instead of just a Thing. This means anything that uses its output must accept an IO Thing instead of an ordinary Thing, and so on. Of course, the way I/O works means that a 'Type1 -> Type2' function into can be transformed into an 'IO Type1 -> IO Type2' or a 'Type1 -> IO Type2' function (this applies to many things other than I/O -- consult one of the many monad tutorials for more on that). Haskell even includes some special syntax for invoking these transformations that makes things look rather like an imperative language, but adding in a debug print still requires you to rewrite a lot more code than you would have to in another language. Alternatively, you could use unsafePerformIO (whose type is 'IO a -> a') to hide from the type system the fact that you've done some I/O, but you may run into trouble with the printing not behaving as you expect (due to Haskell's lazy evaluation).
  • kaonashi 13y ago
    They can also prevent programmers from making a certain subset of good programs. This is less useful.