Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisp and Haskell (2015)

markkarpov.com

Post reply on HN
Print view View original

151–160 of 173 posts

Re: Lisp and Haskell (2015)

#151

Post by vindarel »

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.

Re: Lisp and Haskell (2015)

#152

Post by vindarel »

andi999 wrote: post #16
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…

how would an idiomatic loop statement look like?

Recipes here: https://lispcookbook.github.io/cl-cookbook/iteration.html

Re: Lisp and Haskell (2015)

#153

Post by guenthert »

phoe-krk wrote: post #44
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…

Note that this is on SBCL 1.5.6 which is a little bit over a year old at this point; the article is from 2015 so we should pick a properly dated version from https://sourceforge.net/projects/sbcl/files/sbcl/ and check there. The Common Lisp implementations and compilers keep on getting better with time and they produce more and more compile-time warnings (especially SBCL).

I haven't tried with a five year old version of SBCL, but even early on (from the beginning of the project?) SBCL treated type declarations (using DECLARE) as assertions (as opposed to mere hints for optimization), making it what some might call a gradual-typed system. So with properly declared type, SBCL could have found it then too.

Now, some discourage the use of type declarations in Common Lisp (for a variety of reasons, one being the limited portability as less clever compilers don't warn against mismatch, but might produce broken code) and suggest the (run-time type testing) CHECK-TYPE (standard) macro instead. SBCL's type inference (at least in recent versions) is sufficiently clever to detect mismatches at compile time, when the type is (implicitly) announced using CHECK-TYPE.

Re: Lisp and Haskell (2015)

#154

Post by vindarel »

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…

Old and recent companies using Lisp: https://common-lisp.net/lisp-companies Includes Google (ITA Software, still powering airfare search engines), Boeing, Nasa (remember that Lisp was sent to space), Grammarly, OpusModus, Rigetti (Quantum computing), SISCOG (running metropilatan in european capitals), Ravenpack (big data analysis for financial services), PostgreSQL (pgloader), the ACL2 internationally-used theorem prover, etc

Re: Lisp and Haskell (2015)

#155

Post by vindarel »

A short add-padding (missing the `newline` parameter):

    ;; (ql:quickload "str")
    (defun add-padding (txt &key padding)
      (with-output-to-string (s)
        (loop for line in (str:lines txt)
            do (format s "~a~a~&" (str:repeat padding " ") line))))

Re: Lisp and Haskell (2015)

#156

Post by guenthert »

boloust wrote: post #72
rxhernandez wrote: post #66

Earlier quoted context omitted.

Is null even a type though? If not, then it would seem it's not a static type system that's solving it; it's something else entirely solving it (whether or not that something is contained in that specific type system).

The issue with null, as commonly implemented, is that null is a value that inhabits all types. So in that sense it is a defect of the type system.

In Common Lisp, T is the "any" type (which makes sense there, as type specifiers can be formed using unions using (or type-A type-B ...) lists), the value NIL is the sole instance of the type NULL.

Re: Lisp and Haskell (2015)

#157

Post by guenthert »

mst wrote: post #91
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…

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 author chose to write into a string in an imperative programming style. I don't think it would raise eyebrows in the Common Lisp community. There's more than one way to do it.

Re: Lisp and Haskell (2015)

#158

Post by stassats »

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.

Re: Lisp and Haskell (2015)

#159

Post by timonoko »

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…

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 (

Re: Lisp and Haskell (2015)

#160

Post by pyrale »

jstimpfle wrote: post #105
garethrowlands wrote: post #80

Earlier quoted context omitted.

The fact that code and types don't diverge can make types useful as documentation, albeit limited documentation. Ideally the compiler figures out the types so you don't have to. Haskellers often find this useful when they refactor a month later.

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 from falling out of sync like doc does, and because experience shows that haskell users typically find it useful to write types despite it not being necessary to compile. It would be surprising to skip types but invest in writing more complicated means of documenting and testing the software.

Post reply on HN