Live data from Hacker News

Basics of Haskell – Code and exercises

github.com

41–47 of 47 posts

Re: Basics of Haskell – Code and exercises

#41

Earlier quoted context omitted.

It's interesting to have intense negative reactions to a language. Could you give details what annoyed you with scheme ? I hope it goes beside the syntax.

Many people who like scheme and functional languages have an averse reaction to more procedural or OOP languages. It's interesting that people don't grok it can go the other way. But this is HN so I guess I'll explain. A few things (and for context this was 1996). With the class I disliked they were trying to teach me a language and a complex concept at the same time. In a 4 month semester, half of it was spent just…

I think some points are unfair. I have physical anger when I use java prior 8, but I do appreciate smalltalk a lot more, it tickles my sense of curiosity, joy.

While I do admit that lisp/scheme/fp seek beauty.. it's also one thing I want in coding. Beautiful code. Not at the expense of practicality.. but still, look at how easy it is to be confused and make a mess trying to write a flatmap like procedure, while in lisp it's so trivial you never even think about it.

Thanks for the honesty and good job on making things fast.

Re: Basics of Haskell – Code and exercises

#42
Haskell is actually very easy.

This is just my heuristic but Haskell has just 25 keywords. For comparison: C 32, Java 53, C++ 83 and C# 102. What makes Haskell confusing are the 115 GHC language extensions. Each is basically a new concept to learn. Every time i join a new and sufficiently large project, I stumble across an extension that I am not familiar with.

https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

Re: Basics of Haskell – Code and exercises

#43

Haskell is actually very easy. This is just my heuristic but Haskell has just 25 keywords. For comparison: C 32, Java 53, C++ 83 and C# 102. What makes Haskell confusing are the 115 GHC language extensions. Each is basically a new concept to learn. Every time i join a new and sufficiently large project, I stumble across an extension that I am not familiar with. https://downloads.haskell.org/~ghc/latest/docs/html/user…

Often extensions make the language easier to understand, by removing arbitrary restrictions that you wouldn't have expected to be there in the first place.

Re: Basics of Haskell – Code and exercises

#44
post #36

Earlier quoted context omitted.

You’re not alone. My brain works in steps, not proofs. If all code looked like Haskell and friends I doubt I’d ever have gotten into it in the first place. [edit] algos, over proofs, would probably be a better way to put it.

Proofs work in steps too. I can never tell what an index-juggling loop is doing, in whatever language (including Scheme). But when you follow the data type case by case, each step is simple and logical, easy to comprehend so the whole solution is easy too.

proofs to me, are 'typed' steps. you explicitely state the domains

Re: Basics of Haskell – Code and exercises

#45

Earlier quoted context omitted.

Many people who like scheme and functional languages have an averse reaction to more procedural or OOP languages. It's interesting that people don't grok it can go the other way. But this is HN so I guess I'll explain. A few things (and for context this was 1996). With the class I disliked they were trying to teach me a language and a complex concept at the same time. In a 4 month semester, half of it was spent just…

I think some points are unfair. I have physical anger when I use java prior 8, but I do appreciate smalltalk a lot more, it tickles my sense of curiosity, joy. While I do admit that lisp/scheme/fp seek beauty.. it's also one thing I want in coding. Beautiful code. Not at the expense of practicality.. but still, look at how easy it is to be confused and make a mess trying to write a flatmap like procedure, while in li…

Oh I never said it's fair, just laying it out there for you to take however you wish. It's pretty obvious to me I've got an inherent bias towards functional programming. I see people who love it and are successful with it so it obviously works. I've never had cause to work it out though. Just like I never owned a Sega Saturn nor a X-Box One. It's my personal opinion and thoughts on a language. You don't have to agree with it! In fact I'm very sure you don't. But for every preferential opinion you have, someone else will have a different one.

For flatmap, looked up https://rosettacode.org/wiki/Flatten_a_list#Common_Lisp, this is just gibberish to me currently. Is this simple, or am I missing something?

I once had an discussion with someone who was a huge relational guy who could not understand dynamo (many have this issue). I asked him how to do a global postal address in a relational db. He proceeded to put out a ~5 table layout on the whiteboard from memory. Finished by saying of course there are other situations and you can handle them with X or Y. We went and grabbed a drink and I had him grab get a sde1 and explain that layout to the SDE1. I cut it off after 15 minutes. While it was OBVIOUS to him in his experience, it was in no way simple and the SDE1 (who was just starting multi-table joins) was taking a while to catch up. The sr eng was just used to relational. The model he had on the board was at least 30 years of iteration and best practices, practically it's own microservice. I drew it in dynamo where it's just PK:UserId, and then a bunch of optional columns. SDE1 grokked this right away.

I would love to know what types of apps / code / work you do that you really appreciate in lisp. As I said I'm always looking for a language to solve a problem. What class of applications do you use it for?

For instance I use C++ when I need to be near the metal (game engines, shaders, arduino). We use go at work but Scheme or Clojure might be better for the business logic we do (tho it'd be slower). Always wanted to use Erlang but I never got on the distributed chat program projects (I killed 2 acutally).

Re: Basics of Haskell – Code and exercises

#46

Earlier quoted context omitted.

I think some points are unfair. I have physical anger when I use java prior 8, but I do appreciate smalltalk a lot more, it tickles my sense of curiosity, joy. While I do admit that lisp/scheme/fp seek beauty.. it's also one thing I want in coding. Beautiful code. Not at the expense of practicality.. but still, look at how easy it is to be confused and make a mess trying to write a flatmap like procedure, while in li…

Oh I never said it's fair, just laying it out there for you to take however you wish. It's pretty obvious to me I've got an inherent bias towards functional programming. I see people who love it and are successful with it so it obviously works. I've never had cause to work it out though. Just like I never owned a Sega Saturn nor a X-Box One. It's my personal opinion and thoughts on a language. You don't have to agree…

The flatten code is very simple. You can probably guess what defun is, but you have to know what is cond, atom, and the symbol nil (and its relation to lists), as well as the mapcan function, not to mention the #' notation that appears on the self-reference to flatten.

cond is a multi-branch conditional test: it has the syntax

   (cond (test0 code ...)
         (test1 code ...)
         (test2 code ...)
         ...)
The tests are evaluated in sequence. When the first one is encountered that yields true, then the associated code is evaluated. cond then terminates, and yields the value of the last expression that was evaluated.

A catch-all clause, if necessary, is put at the end, where the test expression is just the symbol t. This symbol is Lisp's canonical representation of Boolean true. Though, any object other than nil is true, it is good form to use the t symbol as a Boolean true constant. Such a catch-all clause appears in the flatten implementation's cond.

atom tests whether a value is an atom, which means "not a cons cell". All objects that are not conses are atoms. Non-empty lists are made of conses: a three element list has three conses. The empty list is made of no conses; it is represented by the symbol nil, which is an atom.

null tests whether a value is the nil object: (null X) is the same thing as (eq nil X).

list is a constructor that makes a list of its argument values.

mapcan projects a each element of a list through a function. The values returned by the function must be lists, and those lists are catenated together. The catenated list is returned by mapcan (destructively, not functionally!) Obviously, mapcan is relevant to implementing flatten.

The #'X notation is a shorhand for (function X). It's a special operator which obtains a function as a value, given its name. It is necessary due to the two-namespace nature of Common Lisp: function bindings are in a separate namespace from variable bindings. If there is a function called X, the (X ...) expression calls the function well enough, but the expression X doesn't retrieve the X function; it refers to an X variable. (function X) refers to the function as a value, and because that is verbose, it has a #'X shorthand.

Note that the flatcan expression recurses on the list elements without regard for whether they are lists or not. For instance, if we flatten (1 2 3), then flatten will get recursively called for 1, 2, and 3. These 1, 2, 3 cases will be detected by the (atom structure) branch of the cond. (1), (2) and (3) will be returned, which get catenated by mapcan to (1 2 3) again.

Re: Basics of Haskell – Code and exercises

#47

Earlier quoted context omitted.

I think some points are unfair. I have physical anger when I use java prior 8, but I do appreciate smalltalk a lot more, it tickles my sense of curiosity, joy. While I do admit that lisp/scheme/fp seek beauty.. it's also one thing I want in coding. Beautiful code. Not at the expense of practicality.. but still, look at how easy it is to be confused and make a mess trying to write a flatmap like procedure, while in li…

Oh I never said it's fair, just laying it out there for you to take however you wish. It's pretty obvious to me I've got an inherent bias towards functional programming. I see people who love it and are successful with it so it obviously works. I've never had cause to work it out though. Just like I never owned a Sega Saturn nor a X-Box One. It's my personal opinion and thoughts on a language. You don't have to agree…

Wow if you consider flatten gibberish I have nothing to say to you that can convince you..

Talking about bare metal and video games, take a peek at https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

Mind you this guys are far above average, but you can't get more perf + low level than this.

I think in time you'll realize how nice other paradigms can be, even if they look alien for quite some time.

Post reply on HN