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

I still Lisp (2021)

betterprogramming.pub

Post reply on HN
Print view View original

111–119 of 119 posts

Re: I still Lisp (2021)

#111

Post by fiddlerwoaroof »

askonomm wrote: post #106
jimbokun wrote: post #56

Earlier quoted context omitted.

“The tools for Lisp aren’t very good because I don’t use those tools.”

Are you suggesting that one has to forgo their favourite code editors, and learn what is arguably the most complex editor, in order to use Clojure? That's the kind of attitude that makes all beginners run away.

A beginner can use anything but if you’re using Clojure professionally, you should aspire to using the good tools.

Also, emacs isn’t really more complex to use than IntelliJ or Eclipse

Re: I still Lisp (2021)

#112

Post by aidenn0 »

tmtvl wrote: post #104
aidenn0 wrote: post #99

Earlier quoted context omitted.

Type checkers make it harder to modify code in a way that changes types. While you are discovering the correct way to solve a problem, you may desire to make such changes. Therefore types can make it harder to discover the correct solution.

That is indeed an argument against static typing and in favour of dynamic typing, although the demerits can be mitigated through some extent through a combination of organisation and tooling. For example, if our customer IDs used to simply be increasing integers but then we decide to change to a UUID variant it would be a pain if I had something like: (declaim (ftype (function (integer) (option customer)) get-custome…

> the demerits can be mitigated through some extent through a combination of organisation and tooling.

Which is what pro-dynamic-typing say about correctness, so we have come full circle.

Re: I still Lisp (2021)

#113

Post by jhhh »

butterisgood wrote: post #76
tmtvl wrote: post #69

I vehemently disagree with dynamically typed being a winning point of Lisp. SBCL's strong support for type checking is the main reason I was drawn from Scheme to CL, and Coalton ( https://github.com/coalton-lang/coalton ) is one of the most interesting Lisp projects I have encountered. Type checking can remove an entire class of bugs from even being a consideration. Yes, it could be argued that type mismatches are a…

I think it would help the conversation along a bit if those who are against static type checking could articulate exactly how type checking gets in the way of writing correct programs. Isn't making sure the types flowing in and out of your functions match, at some point, something you will eventually need to do anyway? Or are we trying to say the type system doesn't allow for perfectly safe things that should be allo…

In almost every instance I see a function in a statically typed language that should return a sum type the developers inevitably collapse that into a single type eg. we're going to return the number of results and -1 is a sentinel value that means something special. This is a fundamental type error. In a dynamic language you tend to not need to embed a concept or value in a domain it doesn't exist. If later I'm adding results together I'm going to get an error when I try to add the Clojure keyword :something-special to a number, while in the static language you may have just folded the special -1 into a sum because you forgot it was unique.

Re: I still Lisp (2021)

#114

Post by signa11 »

Hermitian909 wrote: post #61
signa11 wrote: post #47

Earlier quoted context omitted.

Clojure often leads the Stack Overflow survey in terms of salary. wouldn't that also imply the classic demand and supply thingy ? the one that is alluded too in pg's articles...

My impression is that the high salary is because Clojure it is primarily used for small-ish, fairly senior, highly technical teams writing high impact standalone services e.g. it's my understanding that a Walmart's route planning teams writes their service in Clojure. This actually meshes well with what you'd expect from a lisp being used well. Lisp's power and its downfall is that it lets you express abstraction at…

> This works really well for small teams of high powered developers.

this is exactly right. i guess, a large part of the puzzle is to build one, and then leave them be...

Re: I still Lisp (2021)

#115

Post by tmtvl »

jhhh wrote: post #113
butterisgood wrote: post #76

Earlier quoted context omitted.

I think it would help the conversation along a bit if those who are against static type checking could articulate exactly how type checking gets in the way of writing correct programs. Isn't making sure the types flowing in and out of your functions match, at some point, something you will eventually need to do anyway? Or are we trying to say the type system doesn't allow for perfectly safe things that should be allo…

In almost every instance I see a function in a statically typed language that should return a sum type the developers inevitably collapse that into a single type eg. we're going to return the number of results and -1 is a sentinel value that means something special . This is a fundamental type error. In a dynamic language you tend to not need to embed a concept or value in a domain it doesn't exist. If later I'm addi…

Yeah, I've encountered real-life code that had such issues (was even running in production without anyone noticing). Type checking won't prevent every type of bug, but that kind of problem (returning a special value and forgetting that it should be handled differently) can occur in a dynamic language as well.

Just because keywords and symbols exist doesn't mean the hypothetical programmer who would return -1 as a special value in a static language will not do so in a dynamic language. But in the statical language when the sum type is used it will prevent people from passing the result into an arithmetic function when more code is added in the future (in an ideal world tests would catch it, but in an ideal world the sum type would have been used from the very beginning).

There are trade-offs between static and dynamic typing, and while dynamic typing allows us to write code more quickly, things balance out when we include the time lost by type matching errors that static type would protect us from.

It's like the C vs Rust discussion but with less potential for leaking important customer data all over the web.

Re: I still Lisp (2021)

#116

Post by kettunen »

sshine wrote: post #5
gaze wrote: post #2

I have a suspicion that outside of the 10 people writing lisp seriously—shirakumo, stylewarning, lispm, and some others— there’s more characters of prose praising lisp being written than lisp being written. It’s a great language. I really like it and am using it for some projects. I just want people to actually use it rather than talking about using it. Edit: I’m wrong in the present case! Author has some cool projec…

Where would you recommend one starts? With Racket?

Personally I feel that Scheme (Racket or some other implementation) is in many ways better language compared to e.g. Common Lisp. Simpler and more intuitive (at least IMO) compared to Common Lisp which is in scale of Java or C++ when it comes to the size of the standard/language. This can be of course explained due to the nature of Common Lisp and how its, according to its standard's author, more about politics than art, since when Common Lisp was being planned they needed to accomodate many features from many different Lisps before it. But despite that, when it comes to real-world code, in my own experience, Common Lisp and especially SBCL takes the cake.

Re: I still Lisp (2021)

#117

Post by KingMob »

School-Cotton wrote: post #75
User23 wrote: post #41

Earlier quoted context omitted.

Racket has more didactic origins but I’m given to understand its a good albeit slow general purpose Lisp. Common Lisp is basically the kitchen sink programming language and with a good compiling implementation like SBCL it’s possible to write high performance code. Clojure is the Lisp that you’re most likely to get paid to write. It’s as performant as any JVM hosted language.

> It’s as performant as any JVM hosted language. Surely not true if you write it idiomatically using the standard “purely functional” collections.

No, but it offers a lot of escape hatches to get closer to Java-level performance: transients, mutable fields with deftype, atoms, transducers to minimize intermediate sequences, type-hinting, Java interop, etc.

I've seen Clojure sped up to within 20% of Java's speed, at the cost of very un-Clojure-y code.

Re: I still Lisp (2021)

#118

Post by lispm »

kettunen wrote: post #116
sshine wrote: post #5

Earlier quoted context omitted.

Where would you recommend one starts? With Racket?

Personally I feel that Scheme (Racket or some other implementation) is in many ways better language compared to e.g. Common Lisp. Simpler and more intuitive (at least IMO) compared to Common Lisp which is in scale of Java or C++ when it comes to the size of the standard/language. This can be of course explained due to the nature of Common Lisp and how its, according to its standard's author, more about politics than…

Racket has easily the size & complexity of Common Lisp.

https://docs.racket-lang.org/reference/index.html

I would think that it has roughly 4000 identifiers in the Racket language.

See the index: https://docs.racket-lang.org/reference/doc-index.html

Common Lisp has > when Common Lisp was being planned they needed to accomodate many features from many different Lisps before it

Common Lisp is mainly a slightly modernized & portable version of Lisp Machine Lisp, the feature influence of other Lisp dialects is not that big. The main difference is that Common Lisp provides lexical bindings and lacks a few features.

Re: I still Lisp (2021)

#119

Post by gaze »

throw009 wrote: post #33
grugagag wrote: post #22

Earlier quoted context omitted.

> I use it all the time to help me think through a problem and then implement it in something brain dead like rust so the average programmer can follow along. Is Rust brain dead language anyone can follow along? Did you mean python? > From the outside my code bases look 0% lisp, from the inside they are 100% lisp with build artifacts in other languages. Can you expand on that? You generate code of other language than…

No Rust, warmed over ideas form 40 years ago are just hard enough to make mediocrsties think they are cutting edge. >Can you expand on that? You generate code of other language than lisp in lisp? I write the real program in lisp in two weeks then translate it to a brain dead language over a few months so the average developer contribute to the code base. It's rather impossible to get people used to algol descendants…

you come off like a tremendous jerk
Post reply on HN