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

Common Lisp homepage

lisp-lang.org

Post reply on HN
Print view View original

301–310 of 313 posts

Re: Common Lisp homepage

#301

Post by FractalLP »

lispm wrote: post #297
FractalLP wrote: post #295

Earlier quoted context omitted.

Yea, I was talking about GNU Emacs + Slime. I'm with y'all that Lisp is an extremely powerful and frankly astonishing piece of engineering. It just seems to cater more to those on the fringes and those willing to put in the work to achieve enlightenment. I've read a few Lisp books and have written a bit of Lisp code and understand code is data is code, but haven't put in enough time to really reap the rewards. I thin…

No, I think such observations are valid. I mainly tried to add that even for me, a long time Lisp user, GNU Emacs / SLIME is not the primary tool. There are a few groups and a large and visible group is using SBCL + GNU Emacs + SLIME. But there are other groups.

Ah thanks! I recall you work for one of the commercial lisp vendors. I assume you use their IDE environment that is similar to emacs? How do you describe using it?

Re: Common Lisp homepage

#302

Post by FractalLP »

mtreis86 wrote: post #63
FractalLP wrote: post #53

Earlier quoted context omitted.

I'd say several reasons: 1.) a lot of folks have trouble with the abstactness 2.) a lot of folks think C syntax is how all languages should be 3.) the lisp ecosystem is fractured into too many lisps like SBCL, Clojure, Racket, Allegro, Franz, Picolisp, ABCL, Shen...etc, so some confusion amongst those that are new 4.) poor windows support for SBCL...it literally tells you it is experimental if I recall correctly. Set…

6 - what about https://common-lisp.net/project/bordeaux-threads/

These things all exist, but a lot of them seem like a library from one author as opposed to what is built-in to Java or .NET and had lots of people and money thrown at it. I'm sure the author is a wizard, but how good can the quality be? I don't have any proof here, but my suspicion is bugs and sparse documentation.

Re: Common Lisp homepage

#303

Post by lispm »

FractalLP wrote: post #301
lispm wrote: post #297

Earlier quoted context omitted.

No, I think such observations are valid. I mainly tried to add that even for me, a long time Lisp user, GNU Emacs / SLIME is not the primary tool. There are a few groups and a large and visible group is using SBCL + GNU Emacs + SLIME. But there are other groups.

Ah thanks! I recall you work for one of the commercial lisp vendors. I assume you use their IDE environment that is similar to emacs? How do you describe using it?

I don't work for a vendor, but I use commercial and non-commercial Lisps with other editors.

Typically they are simpler to use, better integrated into the platform, have less features (no games, no latex modes, no org mode, ...), have simpler key commands, are multi-threaded, are directly integrated into the running Common Lisp, don't implement all tools as editor buffers, ...

Re: Common Lisp homepage

#304

Post by FractalLP »

lispm wrote: post #303
FractalLP wrote: post #301

Earlier quoted context omitted.

Ah thanks! I recall you work for one of the commercial lisp vendors. I assume you use their IDE environment that is similar to emacs? How do you describe using it?

I don't work for a vendor, but I use commercial and non-commercial Lisps with other editors. Typically they are simpler to use, better integrated into the platform, have less features (no games, no latex modes, no org mode, ...), have simpler key commands, are multi-threaded, are directly integrated into the running Common Lisp, don't implement all tools as editor buffers, ...

Thanks for the synopsis as I don't see a lot of information on the Lispworks and Allegro sites.

Re: Common Lisp homepage

#305

Post by lispm »

FractalLP wrote: post #304
lispm wrote: post #303

Earlier quoted context omitted.

I don't work for a vendor, but I use commercial and non-commercial Lisps with other editors. Typically they are simpler to use, better integrated into the platform, have less features (no games, no latex modes, no org mode, ...), have simpler key commands, are multi-threaded, are directly integrated into the running Common Lisp, don't implement all tools as editor buffers, ...

Thanks for the synopsis as I don't see a lot of information on the Lispworks and Allegro sites.

They have tryout versions.

Editor User Guide of LispWorks:

http://www.lispworks.com/documentation/lw71/EDUG-M/html/edus...

IDE User Guide for LispWorks:

http://www.lispworks.com/documentation/lw71/IDE-M/html/ide-m...

Re: Common Lisp homepage

#306

Post by madmax96 »

dwheeler wrote: post #181
madmax96 wrote: post #132

Earlier quoted context omitted.

>for the vast majority of programmers, Lisp syntax is not easy I suggest that learning Lisp's syntax is easier than learning C-like syntax. There is learning involved, however, and that undoubtedly keeps people from lisp. But s-expressions are the secret sauce; there is no modern lisp without them. >installation and package management This is basically a solved problem at this point. Clojure has both Lein and Boot to…

Lisp's syntax is indeed easier to learn, but the vast majority of programmers have made it clear that they DO NOT want to READ code in S-expression format. And you typically have to read more code than you write. I created 3 layered notations to keep Lisp's capabilities (including macros and homoiconicity) while making it easier for normal programmers to read. Instead of "getting rid" of S-expressions, I think adding…

>the vast majority of programmers have made it clear that they DO NOT want to READ code in S-expression format

I don't think this is true. I don't know of many people (who actually use Lisp -- meaning they took the time to read a book and build a smallish, mostly complete project) who are actually bothered by reading s-expressions. They do take some getting used to, but I really don't see the problem. s-expressions scare newcomers, but eventually it isn't an issue. It's just different.

Re: Common Lisp homepage

#307

Post by kazinator »

madmax96 wrote: post #306
dwheeler wrote: post #181

Earlier quoted context omitted.

Lisp's syntax is indeed easier to learn, but the vast majority of programmers have made it clear that they DO NOT want to READ code in S-expression format. And you typically have to read more code than you write. I created 3 layered notations to keep Lisp's capabilities (including macros and homoiconicity) while making it easier for normal programmers to read. Instead of "getting rid" of S-expressions, I think adding…

>the vast majority of programmers have made it clear that they DO NOT want to READ code in S-expression format I don't think this is true. I don't know of many people (who actually use Lisp -- meaning they took the time to read a book and build a smallish, mostly complete project) who are actually bothered by reading s-expressions. They do take some getting used to, but I really don't see the problem. s-expressions s…

The vast majority of programmers make it clear that they don't want to use anything but the one of the several popular languages du jour, regardless of what that language looks like, and of what any other language looks like.

There is hardly anything familiar to complete neophytes in any programming language. Beyond simple arithmetic expressions like a * b + c (where the use of asterisk for multiplication is already unfamiliar) and function notation f(x, y), everything else is new.

Some languages with awful syntax have enjoyed popularity.

If you clone the salient features of a popular language to make a new language, you will not automatically end up with a popular language. "Off brand" versions of popular languages largely languish in unpopularity.

Re: Common Lisp homepage

#308

Post by pfdietz »

oblio wrote: post #144
drmeister wrote: post #110

Earlier quoted context omitted.

I say this with a perspective of watching it happen over forty years. I'll get all kinds of heck if I start saying this or that language has faded. But many languages have changed over time, sometimes in breaking ways, as their developers work to make them more expressive and add features. Code that is written one year often doesn't work a few years later - that's a kind of fading as specific reference implementation…

Thing is, except for CS theory evolving, the programming language environment from 30 years ago is in my opinion irrelevant from a maturity perspective. The number of practitioners was probably 1 million or so worldwide, now there’s probably 20-40+ million programmers worldwide. We didn’t have widespread internet access, barely a handful of Open Source communities, compilers were generally commercial and extremely ex…

"Or did Common Lisp programmers generally write unit tests, have integration test harnesses, use package repos, etc. back in 1995? I somehow doubt that :)"

Richard Waters wrote and made available a nice pair of utilities that I've long used.

http://www.cs.cmu.edu/Groups/AI/util/lang/lisp/code/testing/...

http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/l...

The first is the RT package, which allows definition and execution of unit tests. Many elaborations of this have been written over the years.

The second, COVER, is more impressive: it uses Common Lisp macrology to implement a code coverage tool. Combined with RT you can not only unit test your code, you can confirm the level of branch coverage your unit tests achieve.

(I've since hacked up COVER to enable various extensions, including saving of coverage information for aggregation from different executions, and rollback to enable automated search for minimal coverage-improving inputs. Not available publicly right now, unfortunately.)

Re: Common Lisp homepage

#309

Post by venuur »

reikonomusha wrote: post #180
venuur wrote: post #156

Earlier quoted context omitted.

Fortran is still going strong with Fortran 2008. And even better, it’s backwards compatible still with Fortran 77.

Critically, though, it's not the same Fortran. Fortran 2008 is VERY different from FORTRAN 77.

Very good point! I find the structure of modern Fortran very clear (although somewhat verbose compared to same python).

Re: Common Lisp homepage

#310

Post by lispm »

oblio wrote: post #144
drmeister wrote: post #110

Earlier quoted context omitted.

I say this with a perspective of watching it happen over forty years. I'll get all kinds of heck if I start saying this or that language has faded. But many languages have changed over time, sometimes in breaking ways, as their developers work to make them more expressive and add features. Code that is written one year often doesn't work a few years later - that's a kind of fading as specific reference implementation…

Thing is, except for CS theory evolving, the programming language environment from 30 years ago is in my opinion irrelevant from a maturity perspective. The number of practitioners was probably 1 million or so worldwide, now there’s probably 20-40+ million programmers worldwide. We didn’t have widespread internet access, barely a handful of Open Source communities, compilers were generally commercial and extremely ex…

> use package repos ...?

If one used a Lisp system at MIT in the 80s, probably.

The typical Lisp Machine at MIT was networked and shared file servers (also from other types of machines). When one uses a Lisp Machine on the network, one uses a name server (not DNS or NIS, which did not exist at that time) which define one or more sites. The site information in the name server provides information about machines, services, users, printers etc. In the 80s the MIT network was already vast with hundreds of machines. It was basically similar to what Unix system did with mounted NFS volumes, but here built into the Lisp system. This was before TCP/IP, when Lisp Machines used the CHAOS protocol for networking.

Now when one wanted to load some software into a Lisp Machine, one uses a command like 'Load System FOO', where FOO is the name of the system. The Lisp Machine shares with other machines a central registry for system names, which then point to a location in the file system. So this would find the system definition, load it and then load the system components. One could also ask it to load a specific version or load a specific patch level - or just the newest version. A system could also have other files like documentation, C files, etc.. There was also a way to write those to tape or an archive format and transfer it that way.

Thus that was a networked repository for libraries and applications. Some of those libraries were shared across different machine types and Lisp dialects. For example the LOOP feature was a library sharing source code with Maclisp, Zetalisp, NIL, etc. So you could load this from a central location into different Lisp systems - not just Lisp Machines.

Post reply on HN