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

91–100 of 119 posts

Re: I still Lisp (2021)

#91

Post by comfypotato »

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…

A portion of it has to be because of Emacs. I read all these front page posts because I love Emacs, and I’m sure I’m not alone. I picked up Clojure because I got familiar with elisp. The gateway has to be Emacs for a lot of people. And it ends up being a very good first impression for the people who stick around so the cycle builds on itself.

The tricks my muscle memory does on its own accord with lisp syntax within Emacs makes programming more fun than any other context.

Re: I still Lisp (2021)

#92

Post by danuker »

butt___hugger wrote: post #88
noloblo wrote: post #83

Earlier quoted context omitted.

Thanks between clojure sbcl racket and scheme which is the fastest language of am lisps?

SBCL, probably. Scheme would be a close second depending on the implementation (Chicken, Gerbil or other compile-to-C impls.) Racket and Clojure are closer in performance to scripting languages like Python.

In the TechEmpower benchmarks, Clojure is about 2.75x slower than Java, while Python is 5.59x slower.

The fastest composite Python "framework" is uvicorn at 17.9% of the fastest run in Java (officefloor). The fastest Clojure run is Aleph at 36.4%.

https://www.techempower.com/benchmarks/#section=data-r21&l=z...

About SBCL, I get conflicting results. The Benchmarks Game shows it roughly as fast as Java for many problems:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

But here it's significantly worse than the Clojure runs, likely due to the slow DB bindings (the other test types show it roughly in line with Clojure; though it uses a "Stripped"/unrealistic HTTP implementation):

https://www.techempower.com/benchmarks/#section=data-r21&l=z...

I am not sure which Lisp implementation is used; is it SBCL? Does this file speak to you?

https://github.com/TechEmpower/FrameworkBenchmarks/blob/73eb...

Re: I still Lisp (2021)

#93

Post by taylodl »

gaze wrote: post #6
weavie wrote: post #4

Earlier quoted context omitted.

Kinda by definition the people you hear about are the people that are talking about it and not the people that are using it.

What? You see tons of rust projects hitting HN advertised as rust projects and a very different ratio of this to “rust is the enlightened choice” articles

That's because Lispers don't waste their time re-writing well-worn tools in Lisp just for the exercise of writing something in Lisp.

All those Rust posts you're talking about on HN? They're annoying.

Re: I still Lisp (2021)

#94

Post by taylodl »

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?

It really depends on what runtime you're targeting. If you're targeting the JVM, CLR or Javascript then you might want to check out Clojure. It'll let you interoperate with libraries in each of those environments, which you'll find useful.

If you're looking to create a stand-alone executable and have C/C++ libraries you'd like to use then SBCL or Racket may be more useful to you.

I started with Common Lisp and PG's online book On Lisp. http://www.paulgraham.com/onlisp.html

Re: I still Lisp (2021)

#95

Post by kazinator »

todd8 wrote: post #82
kazinator wrote: post #57

Earlier quoted context omitted.

The objective test for whether Lisp metaprogramming contributes to or detracts from the readability of a codebase is to take a sample of the code base and expand the macros, to see whether that is more or less readable.

Macros provide abstractions that often make programs easier to understand. I myself have dozens of the usepackage macro in my Emacs configuration, they hide and standardize the boilerplate that I could use instead. Nevertheless, I have serious reservations about macros in programming. Taking a code base and expanding the macros to see whether that is more or less readable is a bit like expanding a C++ class hierarchy…

> The real question is whether or not there are better alternatives than macros or metaprogramming in the first place. Functions, especially as found in modern languages[1], have proven to be very useful abstraction mechanisms and can often mitigate the lack of fancy macros.

The only relevant "better" in this debate is whether that would be more readable in those specific cases. People still make macros over functional solutions; e.g. the trick where a macro expands into just a function call to one or more generated lambdas which hold argument material. All macros expand to nothing but functions and special forms.

TeX macros are just preprocessor cruft that is more closely related to C macros than Lisp macros. TeX and LaTeX are fragile mainly because of the semantically impoverished target language which just has global variables and conditionals. LaTeX macros are leaky; use them in the wrong place and they misbehave.

Re: I still Lisp (2021)

#96

Post by kazinator »

packetlost wrote: post #87
todd8 wrote: post #82

Earlier quoted context omitted.

Macros provide abstractions that often make programs easier to understand. I myself have dozens of the usepackage macro in my Emacs configuration, they hide and standardize the boilerplate that I could use instead. Nevertheless, I have serious reservations about macros in programming. Taking a code base and expanding the macros to see whether that is more or less readable is a bit like expanding a C++ class hierarchy…

Agreed. Metaprogramming does have it's place in languages like Lisp where it removes boilerplate or hides details that other programmers likely don't need/want to think about. However it's easy to go too far , which is really what I'm talking about. I think as long as you have first-class and variadic functions you can probably live without macros for like 98% of cases without compromising on readability (as is the c…

Python acquires new macros in its parser. For instance, it now has pattern-matching macros which weren't there before. A few years ago it got a f'...' reader macro which wasn't there before.

Re: I still Lisp (2021)

#97

Post by justcool393 »

lispnut wrote: post #78
thebigspacefuck wrote: post #38

Earlier quoted context omitted.

They’re switching to golang now for other various reasons

Any links to stories about them switching to golang I can follow?

so as far as i can tell it's not like a full switch per se but reddit has services written in both python and go.

r2 (old reddit, the reddit API, some parts of new reddit, some of their ML stuff), their monolith, is still written in python.

some services they have in go include some real time services (like the reddit talk stuff seems to be primarily written in go)

reddit kinda seems to have a SOA (not microservices). while there are some codepaths that go through r2 (and indeed this seems to be the case in a lot of cases with regards to old reddit), a lot of newer code uses services.

(note: their engineering blog (/r/RedditEng) calls a lot of their stuff microservices and indeed they may be using that for some things but a lot of their stuff have been described as using more of a SOA vs a microservices.)

someone like /u/ketralnis may have more information as well?

Re: I still Lisp (2021)

#98

Post by lycopodiopsida »

danuker wrote: post #92
butt___hugger wrote: post #88

Earlier quoted context omitted.

SBCL, probably. Scheme would be a close second depending on the implementation (Chicken, Gerbil or other compile-to-C impls.) Racket and Clojure are closer in performance to scripting languages like Python.

In the TechEmpower benchmarks, Clojure is about 2.75x slower than Java, while Python is 5.59x slower. The fastest composite Python "framework" is uvicorn at 17.9% of the fastest run in Java (officefloor). The fastest Clojure run is Aleph at 36.4%. https://www.techempower.com/benchmarks/#section=data-r21&l=z... About SBCL, I get conflicting results. The Benchmarks Game shows it roughly as fast as Java for many problem…

There is a fun blog series about comparison and tweaks of the same problem between java, rust and CL. I will link only the last part of the series[1], but the general take is that SBCL performs comparably to a heavily optimized java implementation, and can even hold a candle to rust and java on short runs.

[1] https://renato.athaydes.com/posts/revenge_of_lisp-part-2.htm...

Re: I still Lisp (2021)

#99

Post by aidenn0 »

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…

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.

Re: I still Lisp (2021)

#100

Post by aidenn0 »

winrid wrote: post #65
floren wrote: post #8

I've been digging into Common Lisp again lately. I'm really enjoying some parts: CLIM is weird but interesting, and the fact that I'm basically developing inside a debugger makes testing and iterating on stuff pretty straightforward. On the other hand, library documentation frequently feels more like the programmer was making notes to himself rather than illustrating how the code might actually be used. I was also pr…

Reading an 80mb JSON file in Node wouldn't be an issue either, so that's surprising.

Also there's no problem reading an 80MB JSON file in CL. I suspect gp was using cl:load which is for loading source files. SBCL definitely struggles with very large source files; I never bothered debugging that since I don't need 80mb source files.
Post reply on HN