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

It's 2023, so of course I'm learning Common Lisp

log.schemescape.com

Post reply on HN
Print view View original

291–300 of 346 posts

Re: It's 2023, so of course I'm learning Common Lisp

#291

Post by schemescape »

mathisfun123 wrote: post #126
bbbobbb wrote: post #124

Earlier quoted context omitted.

Not the OP but would somebody be able to summarize HOW are the lisp REPLs different then to me? I've written limited amount of clojure and common lisp just to play around and I don't recall any difference between Clojure REPL and the REPL I get for say Kotlin inside IntelliJ idea. Maybe the ability to send expression from the IDE into the REPL with one keybind but I cannot say it's not possible with the Kotlin one ri…

There's a person above saying that it's about being to able to mutate program state from the repl, which is a thing that's also possible in any repl for a language with managed memory.

Not just from the REPL, but from the REPL in the context where the error occurred, without having to structure the code ahead of time to support this. It’s not always an important distinction, but it’s handy when prototyping or if the error is difficult to reproduce.

There are some other affordances for interactive programming, such as a standard way to update existing instances of classes. I’m sure you could implement this sort of functionality in any language, but this is universal and comes for free in Common Lisp.

CL also has other interesting features such as macros, multiple dispatch, compilation at runtime, and being able to save a memory snapshot of the program. It’s quite unique.

Re: It's 2023, so of course I'm learning Common Lisp

#292

Post by lukego »

opportune wrote: post #92

I see a lot of “coding” talk in the blog and comments from the author here, but few mentions as to what kind of software they’re building or what use cases they’re targeting. My hot take is that the reason functional programming never took off is that, while it certainly is fine for writing programs, most software these days is not “program running locally on my pc/server from the command line until it completes” and…

I'm using Lisp for simulation. It's really wonderful being able to poke and prod long-running computations while they run. I missed this too much when I tried using Julia.

Re: It's 2023, so of course I'm learning Common Lisp

#293

Post by regularfry »

db48x wrote: post #115
lenkite wrote: post #88

Earlier quoted context omitted.

Java supports live debugging and profiling.

But that’s not the same thing at all. If you’re debugging an exception in Java, you cannot continue execution as if the exception had not been thrown at all. With Common Lisp’s condition system you can.

The question was whether you can debug a live service while it's handling live traffic. Not whether you can fix it. Java can definitely do the former, and definitely can't do the latter.

Re: It's 2023, so of course I'm learning Common Lisp

#294

Post by tlavoie »

opportune wrote: post #114
vippy wrote: post #99

Earlier quoted context omitted.

It took me a while to grok monads, and the IO monad, and longer still to figure out how to compose them in safe ways, and manipulate execution order, etc. But: now I can write typesafe applications, and I produce fewer bugs when I work in non-FP languages (I get paid to write Java.) Lisp is a starting point. Haskell is where it's at. I recommend learning the style, even if you never produce production code in it.

Let’s say I want to do something simple but slightly beyond the scope of a traditional toy demonstration: * Read some environment variables and a local file * Start a monitoring thread that consumes from a channel or something similar, then every X s or X events writes to a local temp file and then sends a request batching some metrics to an external system * Configure and start an http server * Said server has a han…

There are bunches of web frameworks and various support libraries for both Haskell and for Common Lisp. They'll range from simple use cases to more complete and/or opinionated in style, depending what your needs are. For Haskell examples, Servant is used for web APIs, where Yesod is a larger all-around framework.

https://www.servant.dev/ https://www.yesodweb.com/

Re: It's 2023, so of course I'm learning Common Lisp

#295

Post by freilanzer »

SanderNL wrote: post #263
eadmund wrote: post #261

Earlier quoted context omitted.

I think that you’re just restating the Blub point of view. You look back on the tech stacks of the past, and can see how they were worse than the ones we have today, but looking at the ones today you think that there are no more improvements to be made — or at least, none that matter. Given that (I assume) you really do appreciate how much better the stacks of today are then the ones of the past, that seems a highly…

Given the myriad other variables that go into a successful software business, the choice of stack and its various modes of expressing whatever transformation on whatever data it is you are mangling is so exceedingly minor a consideration that I'm close to experiencing it as professional negligence to even fuss over it to the degree it is being fussed over by many people. I'm not dissing Lisp by any means by the way.

I understand your point and it's quite true - but hard problems require adequate tools and I wouldn't choose Java, for example, non-crud stuff.

Re: It's 2023, so of course I'm learning Common Lisp

#296

Post by vkazanov »

regularfry wrote: post #275
vkazanov wrote: post #208

Earlier quoted context omitted.

Listen, I've been on many sides: Lisp stuff, Python stuff, C stuff, etc. I don't think that "something has to be learned". Lisp has many good ideas, Python has good ideas. But REPL-driven development is not one of them. But let me explain. You see, it's not about how REPL in Python just does not allow something (even though it is rather primitive). Python makes it superhard to tweak things, even if you can change a c…

I've mentioned this in a sibling thread, but it's interesting to compare this to Ruby. Ruby does support the sort of redefinition you're talking about. And yet REPL-centric development isn't primary there, either. Yes, there are very good REPL implementations, but I don't know of anyone who develops at the Ruby REPL the same way you would in a Lisp REPL. Maybe it's a performance thing? Maybe it's the lack of images?

Lispy expressions are easy to type into a repl? The leaking block reference trouble is still there, btw, just not that bad as in python.

I did explore the problem in python and don't really understand Ruby so no idea.

Re: It's 2023, so of course I'm learning Common Lisp

#297

Post by freilanzer »

mathisfun123 wrote: post #148
vkazanov wrote: post #143

Earlier quoted context omitted.

The answer to all these things should be "just doesn't work in practise", not for real programs anyways. Unlike Lisp, Python doesn't lean itself well to this mode of development. Primitive CLI-like tinkering, figuring out language features, calc-like usage - maybe. But not a single time in 15 years of doing Python across the industry I saw anybody using these features for serious program development, or live coding,…

>Primitive CLI-like tinkering, figuring out language features, calc-like usage - maybe. But not a single time in 15 years of doing Python across the industry I saw anybody using these features for serious program development, or live coding, or REPL-driven development. I swear you people are like ostriches in the sand over this - Django, pytest, fastapi, pytorch, Jax, all use these features and more. I work on DL com…

What a condescending answer.

Re: It's 2023, so of course I'm learning Common Lisp

#298

Post by the-smug-one »

kaveh808 wrote: post #71
bkomarath wrote: post #62

Earlier quoted context omitted.

I think you are replying to him.

My Youtube channel: https://www.youtube.com/channel/UCHNK9EcrAwP7djlwQN4C_tg

Well, did you watch the recommended tutorials? Or are you one of those artists that don't watch their own work :-)?

Re: It's 2023, so of course I'm learning Common Lisp

#299

Post by kazinator »

mathisfun123 wrote: post #155
lispm wrote: post #152

Earlier quoted context omitted.

> I have no clue what you're talking about That's not good. Try again. In Lisp adding two numbers looks like this is source code: (+ 1 2) CL-USER 41 > (+ 1 2) 3 If I quote the expression and evaluate it, the result is (+ 1 2) CL-USER 42 > (quote (+ 1 2)) (+ 1 2) Thus in Lisp the textual representation of code and code as data are the same. Not so in "Wolfram Language": a + b has a FullForm which looks differently. Th…

> FullForm Plus[a, b] How can I make this any more clear? You are able, in Mathematica, to write Plus[a, b] with your own fingers on your own keyboard and it will be interpreted as the same thing as a+b > I'd expect that they can. Clisp is not the only lisp - I can name 10 others that cannot be compiled.

If you have time to research Lisp implementations until you gather ten that don't have compilers, you might want to take a few seconds to visit https://clisp.cons.org to find out what Clisp means.

Re: It's 2023, so of course I'm learning Common Lisp

#300

Post by kazinator »

mathisfun123 wrote: post #161
kazinator wrote: post #158

Earlier quoted context omitted.

> Lol I am 100% sure that the majority of lisps cannot be aot compiled. Ahead-of-time compiling has been the principal method in mainstream Lisps going back to the 1960's. The Lisp 1.5 Programmer's Manual from 1962 describes ahead-of-time compiling. The curious thing is how can you be "100% sure" in making a completely wrong statement, rather than some lower number, like "12% sure".

>The curious thing is how can you be "100% sure" in making a completely wrong statement, rather than some lower number, like "12% sure". The reason is very simple and surprisingly straightforward (but requires some understanding of compilers): dynamically typed languages that are amenable to interpreter implementations are very hard to compile AOT. Now note I have since the beginning emphasized AOT - ahead of time -…

For someone playing with Mathematica, you have a curious intellectual process. To be clear, I'd rather have you doing that than hocking loogies at cars from an overpass.
Post reply on HN