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

181–190 of 313 posts

Re: Common Lisp homepage

#181

Post by dwheeler »

madmax96 wrote: post #132
AnimalMuppet wrote: post #116

Earlier quoted context omitted.

> I sometimes wonder why Lisp has not been more popular in the technology industry. Larry Wall said that a language should make the easy things easy, and the hard things possible. I think the problem is that Lisp doesn't make the easy things easy. Before you tar and feather me, hear me out. There are two different ways in which Lisp doesn't make the easy things easy. First, syntax. "But it's easy! In fact, it's the e…

>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 just a few standard abbreviations to the Lisp reader makes Lisp more acceptable to more developers. See: https://sourceforge.net/projects/readable/

Re: Common Lisp homepage

#182

Post by ssijak »

Any advantage to learning Lisp instead of something like Elixir today? I find Elixir to be modern, a large amount of libraries, larger and active community, BEAM VM, has macros also... Can`t think of a reason to invest time in Lisp at the cost of mastering something Elixir, but maybe I am wrong.

Re: Common Lisp homepage

#183

Post by flavio81 »

YouAreGreat wrote: post #70
lispm wrote: post #44

Earlier quoted context omitted.

From the dynamic languages the SBCL compiler is something you might want to try. The compiler tells you the usual (?) stuff like missing args, wrong named arguments, missing functions, undefined variables, syntax errors, etc. But Common Lisp has also a (relatively primitive, compared to something like Haskell) type system and the SBCL compiler can make use of type declarations (for compile time type checking and for…

Type declarations in Common Lisp are unsafe. Violating a declaration at runtime is UB. What SBCL is doing to Common Lisp is similar to what C compiler vendors did to C. In order to win at benchmarks, C compiler vendors started to use UB as a license to miscompile optimized code, which got them better benchmarks. Common Lisp has very little UB, so the C strategy is harder to execute. SBCL basically first needs to suck…

>Type declarations in Common Lisp are unsafe. Violating a declaration at runtime is UB. What SBCL is doing to Common Lisp is similar to what C compiler vendors did to C. In order to win at benchmarks, C compiler vendors started to use UB as a license to miscompile optimized code, which got them better benchmarks.

Fear, uncertainty and doubt.

Type declarations are part of the ANSI Common Lisp standard.

Lisp implementations can decide what to do with type mismatches (thus the UB), but how can this be a problem? Code will still be standards-compliant.

Re: Common Lisp homepage

#184

Post by kazinator »

YouAreGreat wrote: post #70
lispm wrote: post #44

Earlier quoted context omitted.

From the dynamic languages the SBCL compiler is something you might want to try. The compiler tells you the usual (?) stuff like missing args, wrong named arguments, missing functions, undefined variables, syntax errors, etc. But Common Lisp has also a (relatively primitive, compared to something like Haskell) type system and the SBCL compiler can make use of type declarations (for compile time type checking and for…

Type declarations in Common Lisp are unsafe. Violating a declaration at runtime is UB. What SBCL is doing to Common Lisp is similar to what C compiler vendors did to C. In order to win at benchmarks, C compiler vendors started to use UB as a license to miscompile optimized code, which got them better benchmarks. Common Lisp has very little UB, so the C strategy is harder to execute. SBCL basically first needs to suck…

Type declarations in Common Lisp support (safety ) and (speed ) syntax for configuring, you guessed it, safety and speed.

The undefined behavior kicks in when you explicitly defeat safety. (safety 0) (speed 3) means "throw out the life jackets and assume that these declarations are true, making the code as fast as possible".

If you don't have the confidence for this over some piece of code, then just ... don't do that.

Safety is on by default. If some implementation changes that, that is bad.

The C language lacks any means to specify these preferences over a specific scope of code. Some compilers have certain #pragma directives, and beyond that, there are only module-level compiler flags. Those don't specifically give you safety. Usually there is just an optimization level. If optimization is omitted or perhaps specified as -O0 or whatever, that makes code sort of behave more safely in some handwaving manner in that certain "confusing, optimizy things" don't happen.

Also note that Lisp has a defined-order of evaluation. A function call like (f (inc i) (inc i)) is not comparable to the C f(++i, ++i) because it performs the left increment, obtains its value, then the right increment, and obtains its value.

Also note that C requires declarations everywhere. Lisp declarations are optional. Before Lisp declarations can be used in a wrong way that causes a malfunction, they have to be used, period.

We can use Lisp declarations to cause an integer overflow, like in C. If we don't use them, the integer type automatically prevents them by switching to bignums.

In C, even the function which is called once, main, is stuffed with declarations and compiled for speed, often with optimization on in actual real-world projects.

The SBCL people would have a long way to go before they screw up anything to the level of C.

Re: Common Lisp homepage

#185

Post by sigzero »

kazinator wrote: post #177
osteele wrote: post #163

Earlier quoted context omitted.

> If it doesn't have nil that is also false and the empty list, it is not a Lisp. Scheme is generally considered a Lisp.

{by whom} Not by me. I'm a skilled Lisp programmer, yet Scheme isn't usable to me a the rudimentary coding level using the core language. There are stumbling blocks at every turn against straightforward Lisp coding. How can it be a Lisp? I can't even rely on Scheme to evaluate the function arguments left to right. Many forms have an "undefined" return value; in Lisp, everything returns a defined value, as a fundament…

"Part of the culture of Schemers is to broadly interpret the term "Lisp." It's part of the culture of Common Lispers to wonder what is going on in the culture of Schemers. :-)"

Re: Common Lisp homepage

#186

Post by kazinator »

sigzero wrote: post #185
kazinator wrote: post #177

Earlier quoted context omitted.

{by whom} Not by me. I'm a skilled Lisp programmer, yet Scheme isn't usable to me a the rudimentary coding level using the core language. There are stumbling blocks at every turn against straightforward Lisp coding. How can it be a Lisp? I can't even rely on Scheme to evaluate the function arguments left to right. Many forms have an "undefined" return value; in Lisp, everything returns a defined value, as a fundament…

"Part of the culture of Schemers is to broadly interpret the term "Lisp." It's part of the culture of Common Lispers to wonder what is going on in the culture of Schemers. :-)"

That's right. Since I'm not in the culture of Schemers, I don't care what they consider Lisp. Every Tom, Dick and Harry clamors for his demented, non-Lisp programming language to be considered Lisp in order to create the appearance of a relationship to the associated allure and mystique. Ruby? Why, that's "MatzLisp".

Re: Common Lisp homepage

#187

Post by nextos »

drmeister wrote: post #167
nextos wrote: post #162

Earlier quoted context omitted.

Cando and Clasp are really inspiring. Is it easy to get academic funding for such a non-incremental idea?

No, none, zero, zip, nadda. What you do is you hook it to another really important idea and then you work until 3:00am every night for months and then years writing code. You take all those voices in your head that say you should not be doing this and squeeze them hard until they... go to sleep and stop bothering you. For me it started paying off in the last year and it is starting to look like it was a really good i…

It's sad agencies are not funding this kind of stuff, although I think they are getting slightly less conservative.

In any case, congratulations. It's an amazing piece of work.

Re: Common Lisp homepage

#188

Post by sitkack »

giancarlostoro wrote: post #145
nerpderp83 wrote: post #115

This is not good , the info density for the screen area is too low. This could have been one maybe two screens worth. Is this the credits to Friends? Am I consuming Lisp Content while chillin in my penthouse on my 20k couch using a gold plated IPad X Tablet? Millennials are Killing Common Lisp. one page, https://www.rust-lang.org/en-US/

The Racket-Lang site almost had it perfect: http://racket-lang.org/ The stuff above the language description should be shoved to the bottom (excluding obviously the top menu) and it would be perfect. I miss their old site because it was obvious and to the point and had examples right away.

This is good, https://web.archive.org/web/20150317023049/http://racket-lan...

I didn't get RSI scrolling through expansive material space.

Re: Common Lisp homepage

#190

Post by [deleted] »

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…

[deleted]
Post reply on HN