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

Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps

fullstacklisp.com

Post reply on HN
Print view View original

91–100 of 110 posts

Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps

#91

Post by lispm »

dang wrote: post #90
lispm wrote: post #68

Earlier quoted context omitted.

Why not remove that obviously trolling comment?! It has no value and the list of stuff does not need to be preserved. The Lisp community has already good pointers to resources. This is another troll who calls others 'retarded' to stir up controversy and have fun with it. Please remove it.

We don't do that as moderators, short of banning the account. I'm not banning that account because its other comments are fine, and it's better to assume that people are willing to improve. HN's mechanism for dealing with individually bad comments is user flags, and the two bad comments in question have indeed been flagkilled.

great

Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps

#92

Post by aidenn0 »

kazinator wrote: post #85
EuAndreh wrote: post #69

Earlier quoted context omitted.

Yep, named-readtables do a pretty good job on packaging read-macros. You've probably missed it.

Packaging means "better than just loading something and having it pee in the global readtable ". It doesn't solve the problem that read macros compete for the same characters and clash. Documentation for merge-readtables-into: "If a macro character appears in more than one of the readtables, i.e. if a conflict is discovered during the merge, an error of type READER-MACRO-CONFLICT is signaled."

Exactly, and this is awesome. If there is a conflict, I get an error and can decide what to do.

At their core, reader-macros are abbreviations. Obviously there are a finite number of abbreviations one can use, so any time you want to add concise syntax from more than one source, there is a chance of conflict.

Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps

#93

Post by mikelevins »

pavelludiq wrote: post #84
haspok wrote: post #79

Earlier quoted context omitted.

Let me try to rephrase my question: I know what I can use Clojure or LFE/Erlang for and what their strengths/weaknesses are. I don't really know anything about Common LISP other than it is a LISP, so I would love to hear some factors that led some people to prefer Common LISP to anything else out there (other than personal preference, which is always a factor). Is it good at number crunching (which is not Clojure's a…

That's a very complicated question. Common Lisp has many implementations, with different strengths and weaknesses. For example SBCL and CCL are good general purpose implementations. They're fairly performant, especially SBCL, properly optimized code can compete for C-like performance. ABCL gives you Java integration, not as nice as clojures for example, but perfectly usable IMO. ECL has a fairly small footprint and i…

Speaking as a longtime (nearly 30 years) Common Lisp programmer, I agree with what you've said here, but I would add one thing more. Common Lisp is one of a small number of languages that represent an approach to programming that is so out of fashion nowadays that it seems to be in danger of becoming extinct. The approach is one that treats programming as an exercise in interactively shaping a living thing in real time, rather than building an artifact from a blueprint. Programming-as-construction is the mainstream; Common Lisp and a small handful of other languages represent a different approach that we might characterize as programming-as-teaching.

Common Lisp and some older Lisps, along with Smalltalk and FORTH, treat programming as an ongoing interaction in which your main program is already running before you ever write any code. It's running, but it doesn't yet know how to be your application. You have to teach it. This you do incrementally, one small change at a time, gradually guiding and shaping the running program until, eventually, it becomes your application. It continues to run throughout the entire process; it just changes its behavior as you teach it new capabilities.

Common Lisp (and a few other languages) are designed with this approach to programming squarely in mind. Consider, for example, the standard Common Lisp functions CHANGE-CLASS and UPDATE-INSTANCE-FOR-REDEFINED-CLASS. In most languages these functions make very little sense. Once you understand how Common Lisp is designed to be used, it's obvious that they are necessary. They're necessary because obviously you're going to redefine classes as you progress, and obviously you don't want your running application to fail simply because you've redefined its types out from under it. So the language is designed to support that way of working. It provides facilities for gracefully handling the situation that arises when you redefine types out from under your code, and it gives you ways to ensure that the program keeps running as you make those changes.

This way of working is now sufficiently out of fashion that even new Lisps don't necessarily support it. Clojure isn't great in this area. Neither are some Schemes. Common Lisp and Smalltalk are the strongest remaining bastions of programming-as-teaching, as far as I can see.

Almost everywhere else in programming today, tools and languages uncritically assume the programming-as-construction model. Maybe that's okay. There's certainly good work being done in that mode. Programming-as-teaching is my native idiom, though. I'd guess that I'm somewhere around ten times more productive when working that way. That doesn't mean it's a better way, of course; it just means it's better for me. Nevertheless, I can't help but mourn when I think that maybe programming-as-teaching is disappearing from the world.

Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps

#94

Post by PuercoPop »

nilkn wrote: post #54
deckard1 wrote: post #47

or you realize Perl, Ruby, Python give you everything good from Lisp anyway with an environment and packages that can talk to the real world, and that macros and metaprogramming are massively overrated and a danger in almost any hands that touch those features. Ask me how long I spent banging my head against the wall trying to get OpenGL working in CMUCL with Alien. Jesus jumping-jack Christ. I can only hope things h…

I don't think that's true. For instance, Python has traditionally been really bad for concurrency but Lisp can be best-in-class (see Clojure's STM). Python is good for single-threaded concurrency now with coroutines and libraries like asyncio, but it still can't compete with something like STM for multithreaded concurrency.

Why look at clojure's STM and not CL? https://github.com/cosmos72/stmx

Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps

#95

Post by collyw »

mark_l_watson wrote: post #87
Elrac wrote: post #76

Earlier quoted context omitted.

Disclaimer: Amateur's blundering travelog. I've been dabbling in Clojure for about 4 years now, off and on, and it works very well for small-ish projects. The integration, as others have mentioned, with the JVM is superbly seamless (it leaves Scala in the dust in this respect) and this opens up most of the Java ecosystem. Also, the STM model of concurrency management is super cool. So far so great! But every time I t…

Some advice for Clojure that applies to all lisps: write code bottom up in small pieces making heavy use of the repl for development. Really understand what your small piece of code does, clean it up, put it in a separate small file, and once you have confidence in it think of it as a library that just works.

Isn't that the same as many other languages is you take a tdd approach?

Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps

#96

Post by collyw »

zelcon wrote: post #72
TheMagicHorsey wrote: post #3

Is it full stack Lisp in the sense that Lisp is running on both the server and in the client (browser/mobile)? If it is the latter, that would be quite compelling. Clojure/Clojurescript is quite compelling from a developer point of view, since you don't have to switch mental context to develop your server and client code (as you would have to do if you develop Go on the server and JS in the browser).

Lisp is a better language than Clojure. People only use Clojure out of force.

Yet a lot more stuff seems to be getting built in Clojure these days.

Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps

#97

Post by kazinator »

aidenn0 wrote: post #92
kazinator wrote: post #85

Earlier quoted context omitted.

Packaging means "better than just loading something and having it pee in the global readtable ". It doesn't solve the problem that read macros compete for the same characters and clash. Documentation for merge-readtables-into: "If a macro character appears in more than one of the readtables, i.e. if a conflict is discovered during the merge, an error of type READER-MACRO-CONFLICT is signaled."

Exactly, and this is awesome. If there is a conflict, I get an error and can decide what to do. At their core, reader-macros are abbreviations. Obviously there are a finite number of abbreviations one can use, so any time you want to add concise syntax from more than one source, there is a chance of conflict.

I can see how this would have value if your idea of Lisp programming is to bring half a dozen new read syntaxes, and use them all in the same source file. Plus keep up with upstream enhancements in all of them, so you have to guard against new clashes popping up.

Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps

#99

Post by vram22 »

mikelevins wrote: post #93
pavelludiq wrote: post #84

Earlier quoted context omitted.

That's a very complicated question. Common Lisp has many implementations, with different strengths and weaknesses. For example SBCL and CCL are good general purpose implementations. They're fairly performant, especially SBCL, properly optimized code can compete for C-like performance. ABCL gives you Java integration, not as nice as clojures for example, but perfectly usable IMO. ECL has a fairly small footprint and i…

Speaking as a longtime (nearly 30 years) Common Lisp programmer, I agree with what you've said here, but I would add one thing more. Common Lisp is one of a small number of languages that represent an approach to programming that is so out of fashion nowadays that it seems to be in danger of becoming extinct. The approach is one that treats programming as an exercise in interactively shaping a living thing in real ti…

Interesting comment. I suppose it is along roughly the same lines as Paul Graham's essay about top down vs. bottom up programming (?) Read it a while ago, not handy on mobile right now.

What is it about CL / Lisp that makes people think it more suitable than other languages for using in such a style? It cannot be only the REPL, since others have them too. Or are CL REPLs more powerful? I've only explored one a bit, Franz, IIRC, some time ago. Edit: Okay, you gave two examples above, CHANGE-CLASS and another. Any other good ones?

Also can you elaborate with some examples on how the condition system is more powerful than other error handling approaches? I saw that mentioned here on HN recently, IIRC.

Re: Show HN: Full Stack Lisp – A book in progress about writing Common Lisp apps

#100

Post by deckard1 »

pjmlp wrote: post #67
deckard1 wrote: post #47

or you realize Perl, Ruby, Python give you everything good from Lisp anyway with an environment and packages that can talk to the real world, and that macros and metaprogramming are massively overrated and a danger in almost any hands that touch those features. Ask me how long I spent banging my head against the wall trying to get OpenGL working in CMUCL with Alien. Jesus jumping-jack Christ. I can only hope things h…

> Perl, Ruby, Python give you everything good from Lisp So where are the: - AOT compilers to native code - REPL environments with GUI debuggers, with fix-and-continue? - Ability to do systems programming without having to use an external language? - Macros

> Macros

You obviously didn't read my post before listing your pet list of things that are irrelevant. Macros are bad. They are only a benefit to those that are delusional enough to think they are a rockstar.

> Ability to do systems programming without having to use an external language?

I have no idea what this even means today. "systems programming". Are you from 1980? Perl is vastly more connected to *ix than any Lisp ever developed. There is nothing you can't do in Perl. Ruby and Python aren't that far behind, either.

> AOT compilers to native code

Totally unnecessary. I can't even think of a reason you'd want this in 2016. Maybe in 1989. But anyway, "native" is disingenuous when talking about Lisp. Unless you just like being an asshole. Lisp requires a GC, and due to the dynamic nature you're constantly jumping through dynamic/static hoops to get exactly what you want. The resulting executable is massive. Perl and I think Python can also compile to "native code".

> REPL environments with GUI debuggers, with fix-and-continue?

Uhm. Yes? The REPL GUI debugger everyone uses today is called Chrome. You seem to be stuck in the stone age. Web and mobile development are where it's at.

Post reply on HN