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

131–140 of 313 posts

Re: Common Lisp homepage

#131

Post by AceJohnny2 »

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/

Counterpoint: I think the Common Lisp page does a good job giving good examples of interesting features, leaving me curious for more. The web benchmark is intriguing [1], and i'm really happy they gave an example of a good IDE, which so many language presentations completely overlook. The tooling is what I, as a developer, will interact with daily! I don't care if you language can do fizzwabble if I can't make heads or tails of it!

The Rust page, on the other hand, only effectively demonstrates one feature, which i don't care about. Unicode strings? Woo. Those belong in separate i18n file. It does so in a box that doesn't even properly display the whole snippet without scrolling. It is cool that I'm able to run it, though of course a newbie like me wouldn't know what to do. Its list of features should be links to examples. As is, the bullet points could have been extracted from a powerpoint presentation and are just as mind-numbing.

[1] though I want a link to more information, for example which servers they chose for Ruby and Node. Were those best-in-class for their language? I'm very suspicious of benchmarks given with little context.

Re: Common Lisp homepage

#132

Post by madmax96 »

AnimalMuppet wrote: post #116
susam wrote: 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. 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 handle dependencies and building. CL has quicklisp (as easy as `(ql:quickload :my-system)` for installation) and asdf for "building" and system definition.

When it comes down to solving problems, I feel that interactive development (with SLIME), Quicklisp, and ASDF make me extremely productive, and the easy things are easy.

Re: Common Lisp homepage

#133

Post by dang »

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…

> poisoning the ecosystem

Please don't take HN threads into programming language flamewar; we've all seen what this leads to elsewhere. It's both possible and much preferable to simply make your points flame-free.

https://news.ycombinator.com/newsguidelines.html

Re: Common Lisp homepage

#134

Post by dang »

stassats wrote: post #92
YouAreGreat wrote: post #70

Earlier quoted context omitted.

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…

That's not at all what SBCL is doing. Each type declaration is treated as an assertion, and only then it performs optimization. And there is no undefined behavior at all. And even without type declarations SBCL is actively deriving types and optimizing things that are proved to have a restricted type. Spreading misinformation like this is what's poisoning the ecosystem.

> Spreading misinformation like this is what's poisoning the ecosystem.

Please don't respond to flamebait by upping the ante. We've all seen what programming language flamewars lead to. Your comment would be much better without the last sentence.

https://news.ycombinator.com/newsguidelines.html

Re: Common Lisp homepage

#135

Post by city41 »

joncp wrote: post #124

What's with the full-page splash that just says "Common Lisp" with no indication that you need to scroll to get to the content. This is worse than the 1990's "Click here to enter the site" silliness.

I think this trend really took off with Medium, which encourages large (and useless) banner images at the top of articles. It's an unfortunate trend. It probably also increases bounce rate if I had to guess.

Re: Common Lisp homepage

#136

Post by AceJohnny2 »

joncp wrote: post #124

What's with the full-page splash that just says "Common Lisp" with no indication that you need to scroll to get to the content. This is worse than the 1990's "Click here to enter the site" silliness.

I agree. A small change to show something peeking from the bottom to indicate there's more would go a long way. I liked Windows Phone's way of having stuff from the next "page" peek from the side/bottom to hint that there's more to scroll to.

Re: Common Lisp homepage

#137

Post by lispm »

YouAreGreat wrote: post #107
lispm wrote: post #95

Earlier quoted context omitted.

SBCL checks type declarations at compile time and at runtime. The default fully safe code in SBCL is already fast enough for many cases. You need to check the manual of SBCL sometime. http://sbcl.org/manual/index.html#Handling-of-Types

Thanks. Seems my assessment and SBCL's self-description match perfectly, as they explicitly aim to "reward the use of type declarations throughout development" and exhort users to "always declare the types of function arguments and structure slots as precisely as possible" . They do want their users to use one of Common Lisp's least safe features pervasively. If the point was to mine assertions for type information,…

> They do want their users to use one of Common Lisp's least safe features pervasively

It's not an unsafe Common Lisp feature. The standard does say nothing about its unsafeness. Only implementations may be unsafe. The Common Lisp standard says nothing how the implementation deal with type declarations.

There is a wide range of behavior in Common Lisp implementations dealing with type declarations. Some will do nothing with type declarations - thus its not more or less safe if one define types.

Some will add more runtime checks when types are declare. Thus the code is MORE safe at runtime.

Some compilers may add less runtime checks and will create specialized code -> less safe.

SBCL provides several ways to deal with that depending on compiler settings.

That SBCL advanced features are a disadvantage is nonsense.

Re: Common Lisp homepage

#138

Post by kickopotomus »

dragandj wrote: post #105
lenkite wrote: post #21

Earlier quoted context omitted.

I liked clojure when I dived into it but lack of static typing is a pain especially once you have got used to the wonderful refactoring and code-intelligence abilities you get by adopting the tools of static typed programming languages like Java/Go/C#/F#. Also performance!

Clojure has Java's static typing and you can also typehint things explicitly.

Clojure 1.9 also introduced spec which allows for more aggressive type restrictions among other things.

Re: Common Lisp homepage

#140

Post by kazinator »

AnimalMuppet wrote: post #116
susam wrote: 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. 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 ...

[me and a few of my friends] ...

Post reply on HN