Show HN: Minimal Lisp in ~70 lines of Haskell

"I'm familiar with parser combinators, but not the Attoparsec or other libraries. Furthermore, I have limited Haskel experience, so I'm struggling to read this. In particular, the use of symbols and overall terseness are hard to get through. I'm also really uncomfortable with the order of operations of all these operators."

This is why I've never identified with "code should comment itself".

I'm not afraid to admit it: I am a dumb programmer. As a dumb programmer, the only way for me to be a good programmer is to be effective.

To be effective, I need to minimize the "time spent understanding code" phase of software development. Furthermore, I will likely be working within a team.

The opposite of that is to be writing "prototype" code --- code which is written to explore the problem space and to gain a better understanding of specific patterns to best accomplish a goal.

But once the prototype phase is over, all of that code is deleted, and is replaced with commented code. (If possible, I try to explain each step of the algorithm in English, first, and then write the code. This is slower, but results in far fewer bugs and a more solid foundation.)

I look at it this way: when my life ends, either I will have gone as far as my own brain was able to take me --- or I will have gone as far as my team's brains were able to take us. I'm willing bet my life that teams of "less brilliant" people are more effective than individuals of excessive brilliance. I write my code accordingly.

-------------------

That said, there is no excuse for laziness. Even if I am merely "competent", it's important for me to strive to be brilliant, even if I'll never attain it.

The syntax elements that you struggled with are explained here: http://learnyouahaskell.com/functors-applicative-functors-an...

They are so incredibly general that you can use them in a lot of places, so the investment to learn their meaning pays off quickly. Learn You A Haskell actually explains them _before_ explaining Monads.

When you've worked with Haskell a bit this code is actually very readable. Admittedly some experience is required.

With a two named helper functions and a bit of additional alignment everyone that has ever written a parser before in Haskell immediately recognizes the structure, thanks to use of applicative functor syntax (<|> and <$>):

    value :: Parser Value
    value =  List   <$> parenthesis (sepBy value (takeWhile1 isSpace_w8))
         <|> Number <$> parseNumber
         <|> Symbol <$> takeWhile1 (inClass "A-Za-z\\-")
    
      where parenthesis p = char8 '(' *> p <* char8 ')'
            parseNumber   = fst . fromJust . B.readInteger <$> takeWhile1 isDigit_w8

Can you give the example that breaks car/cdr? They seem to be evaluating their args here:

    fst $ repl "(car (cons 1 (quote ())))"
    Number 1

So it's really 6-12 hours. You're working on the code in the background; you probably couldn't just have written it three hours straight. Or more likely, you were sorting out the details within the 12-hour period but you had been toying around with the idea for days if not weeks.

Just guessing and certainly not trying to look down your work, it's beautiful. It's beautiful even if it had taken a week to write. The time to write it is just interesting because it is exactly this that makes programming hard to measure.

How does any explain his productivity to a boss if you get seemingly nothing done for four days and then write a nearly complete solution on the fifth day? How much is one actually working after all, counting all the time that affects the work? Does it count as work if you go biking on a Saturday but you kind of subconsciously think about your work and then you write great stuff on Monday, thanks to that?

One thing is for sure: you're much better off measuring a programmer's efforts by his accomplishments instead of the time to do them. This is backed up by the fact that an entrepreneur programmer gets rewarded much more fairly than a salaried programmer.