Live data from Hacker News

Common Lisp homepage

lisp-lang.org

221–230 of 313 posts

Re: Common Lisp homepage

#221
post #144

Earlier quoted context omitted.

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…

Common Lisp has: generic functions, homo-iconic macros written in Common Lisp, reflection, multiple dispatch, closures, optional typing, correct implementation of lexical scope, dynamically scoped variables, a metaobject protocol, conditions & restarts, and a compiler that is available for customization. One or a few of these have made it into other languages in some form or another - but not all together. Common Lis…

At least optional typing and macros are not considered to be universal benefits for programming.

Having a ton of features has been proven in many occasions to be counterproductive. Paradox of choice, higher learning curve, etc.

Re: Common Lisp homepage

#222

Earlier quoted context omitted.

Me (GP): Scheme is generally considered a Lisp. Me (now, after reading P and other responses): I was wrong (or at least half-wrong) about this being generally accepted. I was not aware that I've been in a "Scheme is a Lisp" bubble. EDIT: When I was working in Lisp (early to mid nineties), ANSI Common Lisp was relatively recent, and many of my co-workers[1] — a couple of whom in fact were members of the X3J13 committe…

Regarding that C2 page. My view isn't that Lisp is a coveted brand name, but that it should have a reasonably precise meaning. Abusing "Lisp" has created confusion. Here is one problem: people come across some language which are called some kind of Lisp. They have some sort of experience that didn't sit well with them. Then, because of a human reasoning process called "guilt by association", they attribute the bad ex…

> What is the take-away message for that person? How can it possibly be anything other than: "Lisp is fragmented! […]”

When I last worked in Lisp (in the 90s), "Lisp" wasn't just fragmented. The word described a family of languages, that weren't even unified around LISP1 versus LISP2, let alone Flavors vs CLOS, etc. If you wanted to be clear about which one you meant, you'd say MacLISP, or InterLISP, or Common Lisp, or Emacs Lisp, or something.

Hence my question in a sibling comment: does Lisp now mean, in general or in your community, Common Lisp?

Re: Common Lisp homepage

#223
post #221

Earlier quoted context omitted.

Common Lisp has: generic functions, homo-iconic macros written in Common Lisp, reflection, multiple dispatch, closures, optional typing, correct implementation of lexical scope, dynamically scoped variables, a metaobject protocol, conditions & restarts, and a compiler that is available for customization. One or a few of these have made it into other languages in some form or another - but not all together. Common Lis…

At least optional typing and macros are not considered to be universal benefits for programming. Having a ton of features has been proven in many occasions to be counterproductive. Paradox of choice, higher learning curve, etc.

>At least optional typing and macros are not considered to be universal benefits for programming.

That's just your opinion.

>Having a ton of features has been proven in many occasions to be counterproductive. Paradox of choice, higher learning curve, etc.

Ok, let's see you need to get the numerical value of several big integrals. You have two choices:

a. Pen and paper plus calculator.

b. Computer with sophisticated computer algebra system

Learning curve in (b) is way higher. Alternative (b) is also way more productive.

Helicopters have also a steeper learning curve than cars.

>At least optional typing and macros are not considered to be universal benefits for programming.

So perhaps you don't know the benefits. Lisp Metaprogramming benefits become obvious after taking the time to learn them.

Optional typing dramatically increases execution speed, something that is very relevant and important in 2018.

Re: Common Lisp homepage

#224

Earlier quoted context omitted.

Violation of a type declaration is UB in safe code. SBCL obviously makes use of that fact when inserting assertions.

Undefined behavior gives the implementation the freedom to insert any behavior whatsoever (like the proverbial demons flying out of the nose). An assertion isn't any behavior, it is a form of run-time error checking. Run-time error checking is what the "safety" optimization option means! From CLHS: Name Meaning compilation-speed speed of the compilation process debug ease of debugging safety run-time error checking s…

> An assertion isn't any behavior

It is. For example, a failed assertion inhibits effects that should have occurred before the "actual" type error happens.

The only reason SBCL is able to insert assertions into safe code without giving up conforming implementation status is that, as you say, UB allows anything, and violating a declaration is UB even in safe code.

Re: Common Lisp homepage

#225
post #220

Earlier quoted context omitted.

>Also, languages are a lot more similar to each other than they used to be, in terms of expressiveness and power. Lisp was a “lightsaber” to the “stones” of the 80’s, now it’s at most a slightly more powerful “machine-gun”, at best. Please elaborate more and explain.

How many features coming from Lisp, ML, Haskell and academic languages have made it into mainstream languages now? Many. How many were in mainstream languages in the 80’s? A few. Memory management, generics, etc.

Allright, let's take some list of what can be understood for "mainstream" languages (because, according to other criteria, Lisp is mainstream too.)

TIOBE index top 10:

Java, C, C++, Python, C#, Visual Basic.NET, PHP, Javascript, SQL, Ruby.

let's compare to Lisp and Haskell:

- NONE of those langs have the hindley-milner type system, type inference and typeclasses of Haskell.

- even Common Lisp's type system is more sophisticated than almost all langs on the list, allowing for union types.

- all of those langs only allow you to write the code that will execute at runtime. CL allows you to specify if a function is to be executed at read time, compile time, and run time.

- NONE has an object oriented system with multiple dispatch nor a meta-object system. Unlike Common Lisp.

- None have metaprogramming based on homoiconicity (like Common Lisp), so the only way of macros is to use a cumbersome AST->AST library, and even then, it can only be done at compile time nor runtime.

- Only a very few allow changing the definiton of a class or function at runtime, without stopping the running program, and then it's often a difficult proposition because the language wasn't designed to do this on the first place. Unlike in Common Lisp.

- For the garbage collected languages there, NONE allows you to circumvent or disable the garbage collector, unlike CL.

- For the garbage collected languages there, NONE is faster than CL, and only CL allows the programmer to write Lisp code that reaches C speed, if he/she wishes so.

- only a few have built-in support for all of these: integers, arbitrary precision numbers, rationals, floats with IEEE compliance, complex numbers, and bit vectors. All which CL brings you by default.

Now, you can suggest more languages and I can go on.

There are very few languages that can compete with Coq, Agda, Haskell, Ada/Spark, Common Lisp, Julia and Racket today.

No, there are many features missing. Features that are very relevant. Do you know that many of the design patterns often used in Java are unnecessary in Common Lisp simply because many of them are workarounds for things that the Java OOP system lacks but Lisp's OOP system implements?

Re: Common Lisp homepage

#226
post #144

Earlier quoted context omitted.

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…

"And a programmer in your average mainstream language in 2018 could reasonably expect to be working in the same language in 2018." Pretty radical claim there, are you sure about that? :)

I didn't want to call out an obvious typo - but then I thought "maybe they are talking about Javascript frameworks" and then I thought "yeah - one can always hope". :-)

Re: Common Lisp homepage

#227

Earlier quoted context omitted.

Regarding that C2 page. My view isn't that Lisp is a coveted brand name, but that it should have a reasonably precise meaning. Abusing "Lisp" has created confusion. Here is one problem: people come across some language which are called some kind of Lisp. They have some sort of experience that didn't sit well with them. Then, because of a human reasoning process called "guilt by association", they attribute the bad ex…

> What is the take-away message for that person? How can it possibly be anything other than: "Lisp is fragmented! […]” When I last worked in Lisp (in the 90s), "Lisp" wasn't just fragmented. The word described a family of languages, that weren't even unified around LISP1 versus LISP2, let alone Flavors vs CLOS, etc. If you wanted to be clear about which one you meant, you'd say MacLISP, or InterLISP, or Common Lisp,…

Look, you need a CS degree or two to even understand what "family of languages means", first of all. It's not helpful when facing toward non-users of Lisp, who are relatively new programmers.

Less "family" nonsense, and more solid definitions. Problem with family is that drunken Uncle Al who comes over and sleeps on your sofa for three weeks is also "family". Al doesn't even understand that empty list is false, like everyone in this household was raised to; kick the lamer out!

But if Lisp means only "Common Lisp", that is very unhelpful and stifling.

That would be like "C" only meaning "ISO C 2011", excluding concepts such as "GNU C" or "Microsoft Visual C", or "C90" (a superseded ISO language, no longer C now).

There has to be some flexibility: a sweet spot between useless rigidity and scatter-brained dilution of meaning.

Re: Common Lisp homepage

#228
post #206

Earlier quoted context omitted.

> To be pedantic, those aren't type declarations. They are values of optimization qualities and guide the compiler strategy. > More importantly, the (un)safety of type declaration isn't predicated on any specific safety/speed settings. The mere use of a type declaration implies that the programmer certifies their accuracy inside its scope; With an optimize quality 3 for SAFETY a compiler will not reduce safety, even…

Violation of a type declaration is UB in safe code. SBCL obviously makes use of that fact when inserting assertions.

Exactly. Most implementation will ignore type declarations in safe code. Adding or removing those has no effect.

SBCL honors type declarations. Thus it is defined behavior. SBCL defines it.

I propose to give up the irrational fear of added services provided by SBCL and actually use it as an additional tool.

Re: Common Lisp homepage

#229

Earlier quoted context omitted.

Undefined behavior gives the implementation the freedom to insert any behavior whatsoever (like the proverbial demons flying out of the nose). An assertion isn't any behavior, it is a form of run-time error checking. Run-time error checking is what the "safety" optimization option means! From CLHS: Name Meaning compilation-speed speed of the compilation process debug ease of debugging safety run-time error checking s…

> An assertion isn't any behavior It is. For example, a failed assertion inhibits effects that should have occurred before the "actual" type error happens. The only reason SBCL is able to insert assertions into safe code without giving up conforming implementation status is that, as you say, UB allows anything, and violating a declaration is UB even in safe code.

There isn't necessarily an actual type error! Remember, the declaration provided by the user can be an inaccurate estimate of what the real type constraint is at that program node. The program might in fact require a string there, but the programmer's declaration says integer. So the assertion goes off when a string value occurs, when that would in fact correct in the absence of the declaration.

This alteration of behavior by the assertion is not an arbitrary choice of behavior; it is a diagnostic behavior, in line with the diagnostic meaning of safety.

ANSI CL does literally say under "Declarations" that "The consequences are undefined if a program violates a declaration or a proclamation". Yet, it's not reasonable to allow any behavior whatsoever if a type declaration is violated by a run-time situation, in safe code. It just makes no sense at all to allow a crash, or random bits being silently flipped, etc. Given that safe code, in the absence of declarations, catches type errors; why would declarations regress from that, in safe code.

Re: Common Lisp homepage

#230
post #7

Lisp is quite popular at my current workplace. A few popular open source projects published by our organization have been written in Clojure (a dialect of Lisp that runs on JVM and CLR). A few domain specific languages used internally in our organization are also inspired by Lisp. On a more personal front, I find Lisp to be simple, elegant, and expressive. I use Common Lisp (SBCL) for personal use. Working with Lisp…

>I sometimes wonder why Lisp has not been more popular in the technology industry. Is it the lack of sufficient marketing? In the late 70s, cheap computers (IMSAI, Altair) were almost unable to run Lisp for useful purposes. Too little memory. Minicomputers (DEC PDP /etc) were able to run full Lisp implementations but it worked slower than using other languages. Lisp Machines (MIT CONS, etc) were able to run Lisp fast…

> but it worked slower than using other languages

minus Maclisp

> Enter the late 80s; Lisp ran great on personal computers but implementations AFAIK were mostly commercial, so reserved to big budgets.

CLISP, CMUCL, AKCL, XLisp, ... all were no cost.

> SBCL and CCL

SBCL is a fork of CMUCL which was started in 1981 as Spice Lisp. That was always no cost and several other projects took code and documentation from CMUCL.

CCL is a free version of MCL - which was an affordable commercial Lisp for Macs in the end 80s.

Post reply on HN