It's 2023, so of course I'm learning Common Lisp • Hacker News Board

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

#271

Post by regularfry » Thu, Jul 27, 2023, 1:56 PM UTC

tsimionescu wrote: post #214

mathisfun123 wrote: post #198

Earlier quoted context omitted.

At no point in time did I claim to know lisp well. I stated my familiarity at the outset. But what you all did was claim to know a lot about every other interpreted runtime without a grain of salt. >Next you can find out what optimizing compilers do to avoid it, where possible or where wanted. But compilers I am an expert in and what you're implying is impossible - either you have dynamic linkage, which means symbol…

What you're missing is that, unlike any other commonly used language runtime, compilation in CL is not all-or-nothing, nor is it left solely to the runtime to decide which to use. A CL program can very well have a mix of interpreted functions and compiled functions, and use late or eager binding based on that. This is mostly up to the programmer to decide, by using declarations to control how, when, and if compilatio…

To be fair, any dynamic language with a JIT will mix interpreted and compiled functions, and will probably claim as a strength not leaving to the programmer the problem of which to compile.

Opinions may vary on that point.

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

#272

Post by Tcepsa » Thu, Jul 27, 2023, 1:57 PM UTC

TheOtherHobbes wrote: post #224

schemescape wrote: post #21

Wow, wasn't expecting to see my post on here! Eventually, I want to write a follow-up, but I'm still a beginner. Here's what I've liked about Common Lisp so far: * The condition system is neat and I've never used anything like it -- you can easily control code from afar with restarts * REPL-driven programming is handy in situations where you don't quite know what will happen and don't want to lose context -- for exam…

LISP continues to be a very interesting language. But REPL development is a mixed blessing. There are many situations where you want to start from a blank slate with no previous state. LISP would be a more practical language if it included a trivial option to make that possible.

I usually add one or more reset functions, and then I can customize whatever state I want to return to.

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

#273

Post by Thiez » Thu, Jul 27, 2023, 2:05 PM UTC

anonzzzies wrote: post #205

I love CL and I really miss it when i'm doing something else. I mean, many things are such a pain in 'modern' languages that it's not even funny, when you compare it to the Lisp experience of even decades ago. There are many cons, but those are simply not as bad as most of the pure technical language/dev env cons in almost everything else. Sure Python & JS have more uptake, more libraries etc, but the experience of d…

Why is Typescript unsuitable for the product?

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

#274

Post by regularfry » Thu, Jul 27, 2023, 2:07 PM UTC

eadmund wrote: post #269

mathisfun123 wrote: post #148

Earlier quoted context omitted.

>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…

> Really what this convo is doing is underscoring for me how there really is nothing more to be learned from lisp - I had a lingering doubt that I'd missed some aspect but you guys are all repeating the same thing over and over. No, you keep on misunderstanding what people are trying to tell you. It’s a communication failure. The thing that you think you are doing in Python is not the thing that people are doing in L…

Python is the wrong example here. Ruby did inherit Lisp-style class reopening. But then Ruby always was explicitly very lispy.

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

#275

Post by regularfry » Thu, Jul 27, 2023, 2:10 PM UTC

vkazanov wrote: post #208

mathisfun123 wrote: post #148

Earlier quoted context omitted.

>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…

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?

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

#276

Post by schemescape » Thu, Jul 27, 2023, 2:34 PM UTC

opportune wrote: post #127

schemescape wrote: post #119

Earlier quoted context omitted.

> 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. Good point! This is all currently just a hobby. For Common Lisp specifically, the only things I've produced are a (mediocre) Battlesnake client and a (now defunct, as of yesterday) multiplayer word scramble game. Neither of these really derive…

Thanks for the answer! Your word scramble game in particular seems like something that approximates my “maybe not a good fit for FP” bucket. Do you plan on sharing it on GitHub or describing the challenges you ran into? Completely agree code generation is where I expect Lisp to perform the best. Though, I looked it up and apparently Markdown is not context-free so.. curious as to the challenges that introduces as I f…

Note that Common Lisp doesn’t require functional programming. Mutation, side effects, etc. are fine. I just write imperative code for the most part.

My code was quick and dirty, so I don’t think anyone will learn anything from it, but it’s here: https://github.com/jaredkrinke/thirteen-letters

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

#277

Post by pfdietz » Thu, Jul 27, 2023, 2:35 PM UTC

aidenn0 wrote: post #257

realharo wrote: post #242

Earlier quoted context omitted.

Won't you also be more likely to write code based on data that you happen to have in the current situation, but not for data that covers every situation? E.g. code that accesses an optional property as if it was always present, because it happens to be present when you're writng the code, etc. That seems like a possible pitfall when relying on a REPL heavily, but I haven't used such a language myself, so can't speak…

And with TDD, aren't you ore likely to write code based on the current tests you have, but not code that covers every situation? Any time writing code, you (should) aim for the general situation and then test it with whatever edge-cases you think of at the time. The REPL lets you live-test. I know many people who dump their REPL history to a file and turn them into tests.

My attitude with tests is not to write individual tests when I can write property-based tests. The payoff from the latter is considerable. Let the computer do the work of generating and running tests; its time is worth a whole lot less than mine.

For individual tests, say for coverage, these should also be generated automatically if possible, say by looking for inputs that kill mutants. I've backburned a Common Lisp system for doing this, generating mutants from Common Lisp source forms and automatically searching for and minimizing inputs that kill new mutants. Maybe one day I'll finish this and put it out there for general use.

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

#278

Post by schemescape » Thu, Jul 27, 2023, 2:38 PM UTC

Roark66 wrote: post #134

I'd be interested in if you considered Guile first and what made you decide in favor of common lisp. Few years ago when I decided its finally time to learn lisp I looked at few variants and Guile seemed to have the benefit of: fairly vibrant(but somewhat hermetic) online community, a sizable manual that describes most frequently used APIs (you can learn the language itself very quickly, but it's the knowledge of the…

When I looked, I got the impression that Guile didn’t run on Windows, and that’s a platform I needed to support.

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

#279

Post by [deleted] » Thu, Jul 27, 2023, 2:45 PM UTC

mathisfun123 wrote: post #175

_19qg wrote: post #168

Earlier quoted context omitted.

Common Lisp programs run by default in a way that calls to undefined functions are detected. Here the Lisp simply tries to look up the function object from the symbol. There is no function, so it signals a condition (aka exception). The default exception handler gets called (without unwinding the stack). This handler prints the restarts and calls another REPL. I define the function -> the symbol now has a function de…

>Common Lisp programs run by default in a way that calls to undefined functions are detected. Cool so what you're telling me is that by default every single function call incurs the unavoidable overhead of indirecting through some lookup for a function bound to a symbol. And you're proud of this?

[deleted]

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

#280

Post by bbbobbb » Thu, Jul 27, 2023, 2:46 PM UTC

svetlyak40wt wrote: post #220

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…

Watch this video on Lisp interactive development approach. I've recorded it especially to answer the question: https://www.youtube.com/watch?v=JklkKkqSg4c

Thanks, I forgot about this aspect of live program editing. Whether or not it's possible (or how close just quick live reload) is to this it' definitely not a first class citizen like you presented. It also reminds me of Pharo (or maybe just smalltalk, I've only played with Pharo) where you build the program incrementally "inside out".

It does make me wonder how aplicable this way of programming is to what I do at work but that is more because of the technologies and architectural choices where most of the work is plumbing stuff that is not local to the program itself together. And maybe even for that with the edges mocked out it would make sense to work like this.

Again, interesting video that made me think. Thanks.