Live data from Hacker News

Interactive Common Lisp Development

n16f.net

41–48 of 48 posts

Re: Interactive Common Lisp Development

#41

Earlier quoted context omitted.

> But is there is something inherent to Lisp that makes it "clunky" to work with matrices? s-exps are basically coding at the level of the AST, which for many programming tasks is a powerful level of both abstraction and control. But this interface tends to work much better on tree-like structures (the most simple of which is the list, which in it's simplest case is a cons cell, Lisp's most fundamental particle). Mos…

I think matlab has the most succint language for writing matricies [1 2 3; 4 5 6; 7 8 9] then lisp #2A((1 2 3) (3 4 5) (7 8 9)) then python comma freak show [[1,2,3],[4,5,6],[7,8,9]] python's greatest achievement was bringing open source to matrix calculations and dethroning matlab. python is what it is today because it offered 99% of what matlab offered in open source and for $0 to uni students

What about Octave and R, which are open source and for $0?

Re: Interactive Common Lisp Development

#42
post #6

After getting sbcl up with visual studio code and the alive extension, my mind was totally blown, I'm certain that emacs/slime is the true pure way, but for someone who's not wanting to learn emacs, alive is just pretty amazing and magic, and it fits well with what is described in the article. I wish I could do stuff like recompile functions in-place and just retry the call without exiting the process in every langua…

The IDE situation remains the #1 issue in adoption. Emacs+SLIME+Paredit (or variants) really are the best way to write Common Lisp, but it's also extremely unpalatable to someone who isn't willing to invest in not just a new language, but also an entirely new and extremely intricate editor stack. It's been my hope for well over a decade that the situation would change. Alive is decent, but has a long way to go before…

Honestly this unreasonably scares people off. This apparently very large loo loo of a first step, setting up all this infrastructure just to get started.

The tooling is nice, but it’s not what defines CL. The language has ample benefits just on its own.

A paren matching editor is the minimum tooling necessary for CL. Auto indent is a nice to have. vi has had both for pushing 50 years now.

The REPL is a standout feature of the system. Being able to load your code and poke at it is wonderful. Very powerful feature.

Python has a REPL. I never felt it was very good, but that’s me. I never used it much. Perhaps I was missing something. I wrote a bunch of Python without ever using it. And I’d wager many coders have treated Python like they’d have treated Perl, or most any scripting language. Write code, save code, run script, rinse, repeat.

With no interim step, turn around was fast and work got done.

There is nothing stopping folks from doing the same with CL. I’ve developed 1000s of lines of CL with little more than 2 little defuns. (e) and (l). (e) fired off ‘vi code.lisp’ and (l) wrapped ‘(load “code.lisp”)’. My knowledge of the debugger was knowing how to abort it back to the top level. I mostly did “print” debugging. If I was clever, I’d write a ‘dprint’ function that would take variable arguments. If I was lazy, I’d just “(print ‘(“x=“ x “y=“ y))”. No big deal.

Even when working with LispWorks (which has much to recommend it), I operated much like this. Reload all the code, dabble with the REPL, add print calls, reload, test individual functions. I never took the time to learn the higher level tooling and such. I didn’t feel it was necessary, and I’d rather code than fight tooling.

So, as the Lisp cognoscenti stares on in mouth agape horror as I left much of the Lisp experience on the shelf, I got stuff done anyway.

Which goes back to the fundamental point. CL is a language like any other. It’s a very cool language, very powerful, and worth using just for itself. Its environment does not define it as a language. It augments it, it’s cultural and useful to be sure, but you don’t necessarily need it to be capable and productive and to solve problems.

If all the talk of tooling and what not deters you from trying the language, don’t let it. It’s worth trying all on its own. Try it your way, however you’re comfortable.

But do get a parenthesis matching editor.

Edit: just to highlight the point, if you read PGs “On Lisp” and “Common Lisp” books, you’ll notice they’re pretty much all about the language and its power. He does not talk much as I recall about the environment.

Re: Interactive Common Lisp Development

#43
post #41

Earlier quoted context omitted.

I think matlab has the most succint language for writing matricies [1 2 3; 4 5 6; 7 8 9] then lisp #2A((1 2 3) (3 4 5) (7 8 9)) then python comma freak show [[1,2,3],[4,5,6],[7,8,9]] python's greatest achievement was bringing open source to matrix calculations and dethroning matlab. python is what it is today because it offered 99% of what matlab offered in open source and for $0 to uni students

What about Octave and R, which are open source and for $0?

octave was always seen as subpar version of matlab and r is a statistics programming language. in comparison python was already back then a proper practical programming language that people were using for things other than math

Re: Interactive Common Lisp Development

#44
post #38

Earlier quoted context omitted.

i think it is more correct to say that machine learning saved python https://lwn.net/Articles/843660/

Really ? We are simply going to ignore the entire Python web-app landscape ? Django, Flask, Pyramid, etc. The deployments of those outnumber CL deployments by so many several orders of magnitude. No, ML didn't "save" Python. It only accelerated its usage further above all competitors.

Django and other web apps pale in comparison to Python's dominance in numerical computing. Im not saying they are not important, in fact I believe Python's use in areas other than math drove its adoption in the scientific community, and that one growth fed the other, but without ML there are far too many competitors to Python. However, almost everyone agrees thag py2->py3 was a mess. I like that when I run CL code written 10/20 years ago, and even older!, I dont have to worry too much if it is going to run today

Re: Interactive Common Lisp Development

#45
post #6

After getting sbcl up with visual studio code and the alive extension, my mind was totally blown, I'm certain that emacs/slime is the true pure way, but for someone who's not wanting to learn emacs, alive is just pretty amazing and magic, and it fits well with what is described in the article. I wish I could do stuff like recompile functions in-place and just retry the call without exiting the process in every langua…

The IDE situation remains the #1 issue in adoption. Emacs+SLIME+Paredit (or variants) really are the best way to write Common Lisp, but it's also extremely unpalatable to someone who isn't willing to invest in not just a new language, but also an entirely new and extremely intricate editor stack. It's been my hope for well over a decade that the situation would change. Alive is decent, but has a long way to go before…

> The IDE situation remains the #1 issue in adoption.

Im curious why you think this is the no.1 issue? I think a bigger issue is that so many CL programmers prefer to talk about lisp instead of just getting their hands dirty and making cool original open source things with it that other people would get excited to use. Thats actually a much harder problem. Plenty of people actually use Emacs even if they dont care for elisp and end up learning and writing elisp because they like Emacs. I think CL should market itself to uni or even high school students. Kudos to you though! You are doing great work to promote CL

Re: Interactive Common Lisp Development

#46
post #37
post #24

Earlier quoted context omitted.

They are here: https://cdr.common-lisp.dev/

Last proposal in mid 2013 - which is a proposal to improve the proposal repo! Doesn't really inspire confidence in the language.

And? What has changed so much since 2013 that would require new proposals? Do you need the language to change every month? You keep moving goalposts, and I'm beginning to think that you’re not arguing in good faith here.

Re: Interactive Common Lisp Development

#47

Earlier quoted context omitted.

The IDE situation remains the #1 issue in adoption. Emacs+SLIME+Paredit (or variants) really are the best way to write Common Lisp, but it's also extremely unpalatable to someone who isn't willing to invest in not just a new language, but also an entirely new and extremely intricate editor stack. It's been my hope for well over a decade that the situation would change. Alive is decent, but has a long way to go before…

Honestly this unreasonably scares people off. This apparently very large loo loo of a first step, setting up all this infrastructure just to get started. The tooling is nice, but it’s not what defines CL. The language has ample benefits just on its own. A paren matching editor is the minimum tooling necessary for CL. Auto indent is a nice to have. vi has had both for pushing 50 years now. The REPL is a standout featu…

Nice! I'll note, specially for pythonistas, that even with your simple (edit) and (load) shortcuts, you are doing something more than in Python: while in Python you quit and re-run your program from the terminal, in CL you quit the debugger, you stay in the running Lisp REPL, you edit code while your REPL still around, and you re-load code from the REPL. It's already a faster write-run loop, and you can add advantages like keeping all your test variables around.

Re: Interactive Common Lisp Development

#48
post #46
post #37

Earlier quoted context omitted.

Last proposal in mid 2013 - which is a proposal to improve the proposal repo! Doesn't really inspire confidence in the language.

And? What has changed so much since 2013 that would require new proposals? Do you need the language to change every month? You keep moving goalposts, and I'm beginning to think that you’re not arguing in good faith here.

Not sure what you mean by arguing in good faith as its a straightforward argument.

So much stuff has changed since 2013. Containerization, massive increase in concurrency, mobile platform explosion, etc. Where is the concurrency standard ? Are these 14 CDR's even implemented by CL implementations ? Can't find which CL implementation implements priority queue. Several of those CDR's don't even appear active.

Post reply on HN