Earlier quoted context omitted.
It's questionable whether it's really much better than just a debugger with a core dump (what I usually work on, it's not any better). It is, however, a pretty snazzy feature.
with a debugger, after you fix the application, you still have to restart and run it again. the big benefit here is that no restart is required. smalltalk can do the same btw. i had been working on a small website where a specific request from the browser would fail. instead of sending a failure message the request would just hang. in the mean time on the server in my pharo smalltalk window an error would pop up. whe…
It's 2023, so of course I'm learning Common Lisp
31–40 of 346 posts
Re: It's 2023, so of course I'm learning Common Lisp
#32Re: It's 2023, so of course I'm learning Common Lisp
#33When I want "this will compile forever," I write it in ANSI C.
When I want "this will live forever," I write it Python 2.7 and make it the backbone of the entire org's infra templating. Bonus points if it's a custom Ansible module.
Re: It's 2023, so of course I'm learning Common Lisp
#34Earlier quoted context omitted.
It's questionable whether it's really much better than just a debugger with a core dump (what I usually work on, it's not any better). It is, however, a pretty snazzy feature.
In my experience, it's definitely better for prototyping because if you hit an error that is difficult to reproduce, you can update your code and try again, without having to try and create reliable steps to reproduce the problem.
Re: It's 2023, so of course I'm learning Common Lisp
#35Earlier quoted context omitted.
This sounds so amazing, why is Common Lisp not the most popular language out there? (asking as someone who almost never writes code)
Eventually you need to work with other people, and using a common time-shared or multi user session is unlikely. Now consider that lisp images generally can't be easily diff'd or merged. And with that the edit-and-continue paradigm loses much of its value. If you have to commit changes to a shared source file anyhow then you'll be not much worse off with debugging a core dump.
Re: It's 2023, so of course I'm learning Common Lisp
#36Wow, 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…
Re: It's 2023, so of course I'm learning Common Lisp
#37Earlier quoted context omitted.
with a debugger, after you fix the application, you still have to restart and run it again. the big benefit here is that no restart is required. smalltalk can do the same btw. i had been working on a small website where a specific request from the browser would fail. instead of sending a failure message the request would just hang. in the mean time on the server in my pharo smalltalk window an error would pop up. whe…
> with a debugger, after you fix the application, you still have to restart and run it again. the big benefit here is that no restart is required. We like to make sure everything running in prod is verifiably built from source in-repo. So that's the thing, while it's a really snazzy feature for sure, the value over the rest of the world is on the questionable side. At least for our use case, but I think it's true for…
Re: It's 2023, so of course I'm learning Common Lisp
#38Let me preface this by saying I used LISP professionally in the '80's for about ten years. It's a great language. It is right up there at the top of my list with Assembler, APL and Forth as languages that taught me so much more than the typical C-like language path most people are exposed to today. And, yes, I used those languages professionally for years. I have always said it is important to learn these non-C langu…
Not just having libraries, but having One Obvious Choice. I don't want to compare and contrast libraries, realize that one has sixty percent of what I need, the other has eighty, and they overlap for about forty percent of it.
More and more, I think in terms of algorithms and data structures over anything else. Being able to express those fluently is my focus.
So to bring it around to your comment, what I like to imagine is that someone designs a programming language where the focus is on the ability of the language to be translated to other languages. Then, libraries will be built out, everything that is in standard Python and more. Once a translator is built and tweaked, we could have functional (not like the paradigm) libraries for any langue you fancy.
Yes, the translator would need to be more constrained to avoid "hallucination" and I am sure the resultant libraries would be slow, inefficient, and so on, but they would be there. As it stands now, I think there's a lot of rebuilding the wheel in scores of languages. I wouldn't say that the effort is wasted, exactly, but I can imagine talented programmers making better use of their time.
Re: It's 2023, so of course I'm learning Common Lisp
#39Earlier quoted context omitted.
Sorry that was unclear. What I meant was: a while back, I was exploring Scheme (motivated by SICP) and then ran out of free time. Now, I’ve got some free time again and want to try Common Lisp because of the REPL-driven workflow. It wasn’t meant to be a comment on Scheme vs. CL.
Thanks for clarifying. I recently went into the lispy rabbit hole for a while. Scheme is so beautiful. CL seems more willing to compromise for pragmatism.
Re: It's 2023, so of course I'm learning Common Lisp
#40The scoop: Scheme and Janet are great, but the author wants a more standalone language. What makes the difference is the breakloop, a full-blown REPL that opens when an error in a program occurs. Not a stacktrace, not a debugger; just build from the point where it's currently broken.
This is standard in Gambit Scheme as well.