Lisp and Haskell (2015) • Hacker News Board

Re: Lisp and Haskell (2015)

#161

Post by veddox » Fri, Oct 09, 2020, 8:15 AM UTC

vindarel wrote: post #151

veddox wrote: post #92

The state of the Common Lisp library ecosystem is probably the saddest thing about the language. As the author says, the inbuilt standard library is hopelessly too small for modern requirements - even basics like string manipulation are only cursorily covered. And most of the third-party libraries out there are single-person projects, out of date, undocumented, or all three... The language itself is still fantastic a…

Have another look at https://github.com/CodyReichert/awesome-cl maybe? There might be more than you think. I know I have regularly discovered great libraries the last years.

Oh, hey Vincent :D

I was thinking about mentioning that list, actually. Yes, there are libraries around for most common tasks. However, there are three things I'm not satisfied with:

1) I expect common tasks to be covered by the standard library. Third-party libraries are for specialised tasks.

2) There's often three or four mediocre libraries for the a given task instead of one really good one. Of course there are some "default libraries" (alexandria, bordeaux-threads, etc.) but too often you basically need to pick one at random and hope for the best. Best example: GUI libraries.

3) Most libraries are side-projects by individual developers or only have small teams. Which means: poor documentation and (in some cases) frequent breaking changes or random interruptions in development. The lack of documentation is not quite as bad as it sounds, because the source code tends to be highly readable. But still, the lack of polish and especially stability is not exactly trust-inspiring.

The CL ANSI standard really needs an overhaul to significantly expand the number of inbuilt functions. The fact that my 1990 edition of CLtL2 still adequately describes any modern CL implementation is a testament to the thoroughness of its language design, but also to the lack of change and expansion in the 30 years since.

Alternately, the CL community should develop its own semi-official stdlib - like the R community did with the tidyverse. A single package that you can install via Quicklisp that pulls in a curated list of high-quality libraries, ready for use. The CL standard might not come "batteries included" any time soon, but a "battery expansion pack" would still be a major improvement over "bring your own batteries" ;-)

Re: Lisp and Haskell (2015)

#162

Post by veddox » Fri, Oct 09, 2020, 8:31 AM UTC

behnamoh wrote: post #10

Every once in a while, there's a post on front page HN about Haskell and/or Lisp. Sometimes these posts get a lot of traction, but what confuses me is despite the apparent popularity of these languages among developers, still they are seldom used in serious software. I know there are exceptions (esp. with regards to Lisp), but still these languages never come close to other languages such as Java, JS, C, or even Scal…

You have to remember that HN users aren't a representative subset of software developers world-wide.

Part of that may be the continuing influence of PG: I both learnt Lisp and found HN because of his essays, and I suspect I'm not the only one.

But also, the HN community generally has an academic fondness for new and niche languages, so a language's popularity on HN is a poor proxy for its popularity in the business world.

(A last point: I think the diminished importance of Lisp in the last decades is less due to an inherent flaw of the language and more to what you might call "accidents of history" - particularly its close association with early attempts at AI.)

Re: Lisp and Haskell (2015)

#163

Post by veddox » Fri, Oct 09, 2020, 8:51 AM UTC

veddox wrote: post #161

vindarel wrote: post #151

Earlier quoted context omitted.

Have another look at https://github.com/CodyReichert/awesome-cl maybe? There might be more than you think. I know I have regularly discovered great libraries the last years.

Oh, hey Vincent :D I was thinking about mentioning that list, actually. Yes, there are libraries around for most common tasks. However, there are three things I'm not satisfied with: 1) I expect common tasks to be covered by the standard library. Third-party libraries are for specialised tasks. 2) There's often three or four mediocre libraries for the a given task instead of one really good one. Of course there are s…

> Alternately, the CL community should develop its own semi-official stdlib

That's an idea I would actually like to develop further :D Not sure HN is the right place though, so I moved it to r/Common_Lisp: https://www.reddit.com/r/Common_Lisp/comments/j7vd25/a_curat...

Re: Lisp and Haskell (2015)

#164

Post by jstimpfle » Fri, Oct 09, 2020, 9:22 AM UTC

pyrale wrote: post #160

jstimpfle wrote: post #105

Earlier quoted context omitted.

Code and types can very much diverge if the types aren't checked by the compiler, as my parent poster indicated. Case in point: type aliases instead of (Haskell) newtypes. Type aliases (which are unchecked, unlike newtypes) can lead to exactly the kind of diverging that I alluded to. Look at the mess that is all the typedefs and defines in the Win32 API for example. It's extremely hard not to pass in the wrong typede…

Curious to know what led you to interpret this: > which happens to be checked against the compiler as: > the types aren't checked by the compiler, as my parent poster indicated. (also type aliases are still checked. The check is less useful, but it's still a check) > Why would any experienced programmer make such a blanket statement? Because type annotations are less work than tests or documentation, don't suffer fro…

maybe I misread. I went with

> 95% of annotations in the average haskell codebase are unneeded for compilation

Like type aliases. They are not distinct types, so the compiler doesn't (can't) check that you're using the "right" name.

Re: Lisp and Haskell (2015)

#165

Post by dunefox » Fri, Oct 09, 2020, 11:05 AM UTC

stassats wrote: post #158

dunefox wrote: post #35

Just tried the code in SBCL and it definitely gives a compiler warning even without executing the function: This is SBCL 1.5.6, an implementation of ANSI Common Lisp. More information about SBCL is available at . SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distributi…

I guess that's because I added this in 2016 and the article is from 2015.

What do you mean?

Re: Lisp and Haskell (2015)

#166

Post by mst » Fri, Oct 09, 2020, 4:08 PM UTC

guenthert wrote: post #157

mst wrote: post #91

Earlier quoted context omitted.

Plus, the whole ... style ... seems bizarre to me. Common Lisp isn't my usual dialect but I'd've expected something more like: (defun add-text-padding (str padding) (let ((lines (split-string "\n" str)) ( cond ((nil? lines) "") (#t (join-string "\n" (cons (car lines) (mapcar (lambda (x) (concat-string (repeat-string " " padding) x)) (cdr lines) ) ) )) ) ) Note: pseudocode typed straight into the comment box, and I dr…

Well, you asked for it, so: the #t gives away that you're more comfortable with Scheme than with Lisp, I suppose those string functions are present in some Scheme dialect as well, but they sure aren't in Common Lisp (not with that syntax at least). Scheme is quite dogmatically a functional programming language, Common Lisp is decidedly a multi-paradigm language. With that it shouldn't surprise that the article's auth…

The string functions were basically invented to allow me to express the algorithm, though a friend of mine who writes clojure looked at the original problem and produced an implementation that was logically similar to mine that used actual clojure functions that behave basically like that.

I tend to do single assignment and minimal mutations in any language though, and try and push my side effects (I'm aware the string write is encapsulated therefore not a side effect) as far out to the edge as possible.

As an example, in perl (which is probably my most-used language, so I'm 100% on board with "more than one way to do it" ;) I'd've written:

    sub add_text_padding ($str, $padlevel) {
      my ($first, @rest) = split /\n/, $str;
      my $pad = ' ' x $padlevel;
      join "\n", $first, map $pad.$_, @rest;
    }

(my lisping has indeed been significantly in scheme, plus dabbling in other dialects and a tendency to prototype things in operative lisps derived from Shutt's kernel ... which is why I did, indeed, ask for it, so thank you for the reply)

Re: Lisp and Haskell (2015)

#167

Post by [deleted] » Fri, Oct 09, 2020, 10:18 PM UTC

Rerarom wrote: post #28

ashtonkem wrote: post #7

Earlier quoted context omitted.

It was originally supposed to, s-expressions (parenthesis) were supposed to be eventually replaced with m-expressions which were influenced by Algol and FORTRAN (the irony), but reviewers of the paper and the initial implementors of lisp preferred s-expressions, which stuck. That being said, having worked professionally in Lisp, the “un-lispy” macros like Loop are some of the worst parts of that language. They comple…

"Haskell is Lisp's missing M-Expression implementation."

[deleted]

Re: Lisp and Haskell (2015)

#168

Post by ashtonkem » Fri, Oct 09, 2020, 10:20 PM UTC

guenthert wrote: post #142

timonoko wrote: post #21

Earlier quoted context omitted.

Just a jumble of random words. They are especially difficult to non-english speakers, because they are not grammatically correct sentences, but rely on some unknown word-order logic in indo-european languages. Same aplies to list comprehension sentences in Python too.

Is that truly a stumbling block? I ask because English is not my native language. Around the time I learned English in high school I also became interested in computers, which to me then meant programming in BASIC. It took an embarrassingly long time for me to realize that e.g. GOTO was actually formed from 'go to' -- to me, "GOTO " just meant that program flow would continue at line , nothing more, nothing less. "IF…

The problem with the Loop macro isn’t the English, it’s that it doesn’t look anything like the rest of the language. It’s like finding some embedded Python in your Java; even if you’re fine with using Python, it’s going to be pretty hard to work with when you’re in Java mode.

Also, macros are much harder to debug, especially when the macro expansion code itself crashes. The loop macro does a lot of work, which makes it a particularly annoying macro to fix when things go wrong.

Re: Lisp and Haskell (2015)

#169

Post by guenthert » Sat, Oct 10, 2020, 2:49 AM UTC

timonoko wrote: post #159

guenthert wrote: post #142

Earlier quoted context omitted.

Is that truly a stumbling block? I ask because English is not my native language. Around the time I learned English in high school I also became interested in computers, which to me then meant programming in BASIC. It took an embarrassingly long time for me to realize that e.g. GOTO was actually formed from 'go to' -- to me, "GOTO " just meant that program flow would continue at line , nothing more, nothing less. "IF…

LOOP is just a little bit more complex than BASIC: (LOOP FOR I FROM 0 BELOW (LENGTH S) THEREIS FOR CH = (CHAR S I) WHEN (

That might be the case, the same approach would work here though I think. There is even less a pretention of proper English grammar and why should there be? I can't remember the exact syntax of all the LOOP terms for the life of me and generally try to keep it simple.

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node240.html#... states that "The thereis construct takes one form" so that will be your error. Not quite sure, as I don't know what you intend to express. when (http://www.gigamonkeys.com/book/loop-for-black-belts.html might be of help.

Re: Lisp and Haskell (2015)

#170

Post by guenthert » Sat, Oct 10, 2020, 2:59 AM UTC

ashtonkem wrote: post #168

guenthert wrote: post #142

Earlier quoted context omitted.

Is that truly a stumbling block? I ask because English is not my native language. Around the time I learned English in high school I also became interested in computers, which to me then meant programming in BASIC. It took an embarrassingly long time for me to realize that e.g. GOTO was actually formed from 'go to' -- to me, "GOTO " just meant that program flow would continue at line , nothing more, nothing less. "IF…

The problem with the Loop macro isn’t the English, it’s that it doesn’t look anything like the rest of the language. It’s like finding some embedded Python in your Java; even if you’re fine with using Python, it’s going to be pretty hard to work with when you’re in Java mode. Also, macros are much harder to debug, especially when the macro expansion code itself crashes. The loop macro does a lot of work, which makes…

I wasn't defending the LOOP macro, but I think your critique comes 30 years too late ;-}