Hacker News Reader

I think you should learn C to learn how computers work and learn Haskell to learn how languages work. Those two are remarkably different ball games despite the supposed identification of the two that persists today.

I'm tempted to say you should learn C to learn how computers work, and Haskell to learn how computing works.

I'd say that for one of the terminating languages (Agda, Coq) perhaps?

It helps a lot to be exposed to a variety of approaches, exactly as you say, and to be exposed early while you're still forming ideas about how things work.

Simply saying C is the "best" way also misses that point that different people are motivated to learn in different ways. For many, ramping up quickly in Python and plugging something into a Twitter library would show them that they can actually do something interesting right now, which is enough to keep them coming back for more. Others are driven by understanding how things work, and would be happy to crack open a core dump to figure out what happened.

I agree that C is not the "best"; just, vital (I buy that Rust might supplant it.)

But there's nothing you engage with in Python that you can't get by learning C, or Lisp.

Like I said: Python is just a bad example.

At the risk of being perceived to move the goalposts, I think there is a real lesson to engage with: empirically, for large classes of programmers, syntax, uniformity, and absence of boilerplate actually make a larger difference in out-the-gate productivity than many would like to admit. I understand that this isn't a lesson about programming per se, but I think it's a lesson about the practice of programming.

I see this repeatedly in our internship program, where people often ask after we "promote" them to other language work "Why can't XYZ look as clean and simple as Python?". I do think that's a lesson worth learning, and it's a little hard to learn except by osmosis. If I just tell someone "empirically, syntax matters a lot more than you might think in doing real work" it's easy to dismiss as understood-but-not-important. Jonathan Blow has a bit in one of his videos about "understanding" vs "really viscerally understanding", and I think this is one area where the latter simply can't be achieved without direct experience.

Productivity, yes! Understanding, no.

I should have been more clear: I agree with you on this and think C should be one of the batch of first languages students are exposed to (as the best choice in its class at the moment). The OP seems far too biased towards C, though.

What worked for me was early exposure each of: a specific teaching language (somewhat like Eiffel, within a simplified environment), C/C++ and Scheme. They each taught me very different things and I'm glad they were all offered in my undergrad, although I think they should offer Scheme earlier (IIRC it was part of an optional third year course, which also touched on e.g. Prolog).

I agree. The only problem I have is context switching between languages. I write in C, PHP and Javascript (I know not the best three options, but I have yet to have a problem I can't solve using one of these three). I find it takes me a couple of hours to get back into the full swing of each language and these three are easy to context switch between. I worry that if I had a true high level language to my tool kit that I will grind to halt.

I find switching between Algol family based languages easy (Basic, Pascal, C, C++, Javascript, Java, C#, Go, PHP, Lua, Rust). But switching between Algol and various Lisp dialects takes some minutes.

That is impressive. I find that it is the little things that I end up messing up on and spend more time using my delete key than any other key until I get back into the swing of things.

I think object-oriented programming counts as something you can learn from Python, Java, Ruby, or PHP5 -- something you wouldn't learn writing Lisp, ML, or Haskell. Sure, Lisp optionally has CLOS and Haskell has typeclasses (which are somewhat different from traditional OOP). But if you program in Java you will be forced to think in an object-oriented way.

You could make the argument that OOP is not a fundamental concept of programming, but you could say the same for monads. Even if it's just a productivity tool or, as pg argues, a substitute for genuinely intelligent programmers, it's still something. It's certainly something that employers expect you to know.

It's not about what they're useful for; it's about how they make you think about the whole. It is a more complete understanding.

Knowledge does not need to be directly applicable to be immensely valuable.

For me, Lisp and Haskell exercise two different conceptual muscles. And neither of them, nor C in general exercise the increasingly important concurrency muscle. Maybe Clojure is a good way to get both the Lisp and concurrency fixes, but something on the Erlang VM, or perhaps Go or Node, are more fundamentally designed around concurrency, and many people build those chops using threads in C++ or Java. Interestingly, this is another area where the usual suspects of Python, Ruby, and PHP are quite poor.

What about Go or Node make it more designed around concurrency than Haskell? It sounds like you are trying to say Erlang, Go, and Node have "first class concurrency". I'd agree that Erlang does, but I'd say that Node and Go do not. I'm almost tempted to wager the same is true for Lisp, but don't have enough experience with concurrency in Lisp.

Furthermore I'd wager that Go and Node have nothing in the realm of concurrency that Haskell doesn't have. If I'm wrong, I look forward to finding out ;)

"Languages aren't defined by what they make possible, but by what they make easy", to which I would add "and idiomatic". Go and Node make their (very different) concurrency features easy and idiomatic. Maybe Haskell does too, though, and I just don't know it well enough!

Here's 2 Examples (Warning: Didn't run them and could have missed imports).

One parallelizing a sudoku solver and the other making a reminder program concurrent. Both are from Parallel and Concurrent Programming In Haskell[0].

Sequential version[1]:

    import Sudoku
    import Control.Exception
    import System.Environment
    import Data.Maybe
    
    main :: IO ()
    main = do
      [f] <- getArgs
      file <- readFile f
    
      let puzzles   = lines file
          solutions = map solve puzzles
    
      print (length (filter isJust solutions))

Parallel version[2]:

    import Sudoku
    import Control.Exception
    import System.Environment
    import Data.Maybe
    import Control.Parallel.Strategies (parMap) -- line that changed
    
    main :: IO ()
    main = do
      [f] <- getArgs
      file <- readFile f
    
      let puzzles   = lines file
          solutions = runEval (parMap solve puzzles) -- line that changed
    
      print (length (filter isJust solutions))

Here's an example making a small reminder program concurrent:

Sequential[3]:

    import Control.Concurrent
    import Text.Printf
    import Control.Monad
    
    main =
      forever $ do
        s <- getLine
        forkIO $ setReminder s
    
    setReminder :: String -> IO ()
    setReminder s  = do
      let t = read s :: Int
      printf "Ok, I'll remind you in %d seconds\n" t
      threadDelay (10^6 * t)                  
      printf "%d seconds is up! BING!\BEL\n" t

Concurrent[4]:

    import Control.Concurrent
    import Text.Printf
    import Control.Monad
    
    main = loop
     where
      loop = do
        s <- getLine
        if s == "exit"
           then return ()
           else do forkIO $ setReminder s
                   loop

    setReminder :: String -> IO ()
    setReminder s  = do
      let t = read s :: Int
      printf "Ok, I'll remind you in %d seconds\n" t
      threadDelay (10^6 * t)
      printf "%d seconds is up! BING!\BEL\n" t

0: http://chimera.labs.oreilly.com/books/1230000000929/index.ht...

1: http://chimera.labs.oreilly.com/books/1230000000929/ch02.htm...

2: http://chimera.labs.oreilly.com/books/1230000000929/ch02.htm...

3: http://chimera.labs.oreilly.com/books/1230000000929/ch07.htm...

4: http://chimera.labs.oreilly.com/books/1230000000929/ch07.htm...

Thanks!

When you say "concepts that a language is uniquely good at engaging", they might get in the way for a novice learner. Python and such are pretty good at the very basics of programming.

I have the same problems with haskell. My actual level of ignorance is: (anyone having traveled the path between imperative and functional, please correct me)

- 1st problem: Functional Programming is not "programming", since in "pure" functions you do not have algorithms and "programming" seems to be defined as making "algorithms".

- I believe it should be called "functional composition" instead of "functional programming".

- 2nd: Monads. "Monads" seems to be the way to introduce "impurity" into Haskell, so, if you need an algorithm, you enter the "monad" space.

I feel like you're conflating "purity" with algorithms.

Just to clarify, in Haskell there is no issue with algorithms being contained inside functions.

Here's a naive implementation of quicksort:

  qsort [] = []
  qsort (x:xs) = qsort smaller ++ [x] ++ qsort larger
                 where
                 smaller = [a | a <- xs, a <= x]
                 larger = [b | b <- xs, b > x]

Nothing about this algorithm requires side-effects, it doesn't mutate any state, it doesn't make use of counters. You can implement it anywhere inside of a Haskell program.

People may charitably point out that this is a pretty bad naive implementation, because it doesn't just mutate values in the list up and down, which is inefficient. People uncharitably will take issue with even calling it quicksort, as some people believe that the property of just mutating values in the list is an integral part of it being quicksort. I'm not smart enough to have an opinion about whether or not it's a "true" quicksort.

But the point is that you can absolutely have algorithms in Haskell that are not restricted to only run in a Monad.

Monads exist in Haskell as a way to reason about side-effects. Whether or not an algorithm (or any function) needs to be executed inside a monad is a function of its use of side-effects, it's not fundamental.

Thanks. As I said in my comment I know my ignorance and I'm looking for enlightenment (my confession didn't stop the downvotes though)

I do not "see" any clear algorithm in the code (no step-by-step procedure). I see recursion only.

¿Can you explain in words what this code is doing?

¿Can you implement this without using recursion?

Ok, here let's step through what this function is doing with a simple example (sort a list that looks like this: [3, 5, 1, 4, 2]:

  qsort [] = []

This means that if you hand the qsort function an empty list, you get an empty list ([] is the empty list in Haskell).

    qsort (x:xs) = qsort smaller ++ [x] ++ qsort larger

Ok, so this means that we are making a list out of three parts: (qsort smaller, x, and qsort larger). The '++' operator is just concatenation.

                  where
                  smaller = [a | a <- xs, a <= x]
                  larger = [b | b <- xs, b > x]

Here we're defining what "smaller" and "larger" are. They're list comprehensions. "Smaller" returns a list that is made up of pulling out all the numbers that are less than or equal to x. "Larger" pulls out all the numbers that are greater than x. Then it does it again.

Using that example list above ([3, 5, 1, 4, 2]), here's if we did it by hand:

  qsort [3, 5, 1, 4, 2]
   = {applying qsort}
  qsort [1, 2] ++ [3] ++ [5, 4]
   = {applying qsort}
  (qsort [] ++ [1] ++ qsort [2]) ++ [3] ++ (qsort [4] ++ [5] ++ qsort[])
   = {applying qsort}
  ([] ++ [1] ++ [2]) ++ [3] ++ ([4] ++ [5] ++ [])
   = {applying ++}
  [1,2] ++ [3] ++ [4,5]
   = {applying ++}
  [1,2,3,4,5]

That "step-by-step procedure" is an algorithm.

Is it that there are no loops that you don't see how it's an algorithm? It is definitely true that some algorithms are very obvious to implement using loops (quicksort is actually one such algorithm), and can in fact be a pain in the neck to implement in some functional languages.

Thank you very much m0nastic, it's a great explanation.

Now I can see the mathematical elegance of the haskell code.

An explicit algorithm of the same (pseudo)code (using a mutable list) could be:

   function qsort(list)
     if list is [], return []
     let x = extract_first_element(list) // car 
     let smaller = [a | a <- list, a <= x]
     let larger = [b | b <- list, b > x]  
     return qsort(smaller) ++ x ++ qsort(larger)

And by writing this pseudo-code, I can see that in the haskell code, "smaller" and "larger" are clearly parallelizable, while in the "imperative"-"explicit algorithm" pseudo-code, the compiler cannot do such optimization...

And then, I'm enlightened. Thank you.

(You made a small mistake qsort [1, 2] ++ [3] ++ [5, 4] should be qsort [1, 2] ++ [3] ++ qsort [5, 4])

Also, quicksort is a pretty bad example of an pure algorithm, since it loses a lot of its performance benefits when not done in place.

Ah, you're correct. (It's too late for me to fix my comment).

I went over the issues with this version of quicksort in the original comment, but I still think it was a good example because most people are familiar with quicksort, and I was trying to address the original posters claim that algorithms in Haskell could only be used in Monads.

Also, quicksort is one of the few I can do from memory.

Pure functions can very much be algorithms. Functional programming is just that and can include algorithms. Monads are not intrinsically related in any way to impurity, they are an instrument of control/data flow. They can be used to apparently cause side effects but do not actually introduce impurity.