71–80 of 271 posts
Last year I looked into Common Lisp for a while, but got turned off when I found that there's no distinction between the empty list and boolean false (or nil, in CL-speak).
I found this kinda weird and vaguely off-putting. I don't want to write code to handle the diffence between, say, an empty array and false or null in deserialized JSON data.
Can anyone comment on whether this comes up as an actual issue in practice?
Hi, HN! I made this! Ask me any questions you like. I'll try to respond as the workday progresses and I wait for deploys to complete! paul@nathan.house if you want to email me instead. (or @p_nathan on Twitter, if that's your thing).
While people are directing their attention here: Last year I looked into Common Lisp for a while, but got turned off when I found that there's no distinction between the empty list and boolean false (or nil, in CL-speak). I found this kinda weird and vaguely off-putting. I don't want to write code to handle the diffence between, say, an empty array and false or null in deserialized JSON data. Can anyone comment on wh…
null -> :null [] -> #() and false -> nil
Earlier quoted context omitted.
I'm going through a similar process. My caution is that 'package' has a very technical meaning in Common Lisp that is at odds with how 'package' is used in other languages (and a bit at odds with how the author uses it in their tutorial). A package in Common Lisp is a set of interned symbols. In Common Lisp, systems are more in keeping with an ordinary understanding of packages...but combined with the idea of a build…
Hmmm. I tried to convey the idea, without getting too bogged down in the details that don't per se matter on Day 1. I would be interested in any PRs you have to clarify the matter adequately for people just starting out.
Earlier quoted context omitted.
Given a reasonable choice, I would almost never use a language like Golang that doesn't enforce memory safety (at least, by default). Null pointers, ugh.
Most of the traditional definitions of "memory safety" are not violated by having null pointers, as long as they just crash when used incorrectly. nils in Go don't let you start accessing things you shouldn't or anything. Golang is memory safe by most definitions. (Possibly not by a definition that includes concurrent memory safety. I expect in 20 or 30 years the term "memory safe" will indeed involve that. But at th…
Earlier quoted context omitted.
> Lisp Machine (which was the future when Common Lisp was designed) Common Lisp was actually designed so that you don't need a Lisp Machine. The people working on it were from CMU (Unix workstations), Lucid (Unix workstations), Franz (Unix/Windows), Apple (Mac), Symbolics (Lispm, PC), Xerox (Lispm, Unix), and many others. Users used an editor-based IDE (like Franz ELI with GNU Emacs, ILISP with Gnu Emacs), a special…
Sorry for not being clear. I was not stating that Lisp Machines were an intended requirement, my intent was to point out that Lisp machines were the zeitgeist during the period when Common Lisp was incubated and developed and hypothesize that this is reflected in the design of the language. As a point of contrast, Smalltalk was developed in part with the idea of Dynabooks in the hands of children. Hence its stereotyp…
Common Lisp was originally mostly a simplified and modernised version of Lisp Machine Lisp. It was supposed to be 'cheaper' for users (industry, military, ...), when delivering software. Without the 'hardware dongle' of a Lisp Machine, which would cost a lot - both hardware and software.
One of the main purposes of its existence was to be a standard Lisp able to work on a wide variety of hardware - hardware which was less powerful. Thus the design in the early days was also driven by taking features away from what a Lisp Machine would provide. Less features, easier to implement, able to integrate into different environments.
For example Common Lisp provides type declarations. This was added for non-Lisp-Machines. The Lisp Machine compiler ignored type declarations. It did not use it. The CPU does runtime type checking/dispatching on a Lisp Machine. Always.
Everything fancy, which was difficult to implement on small machines, was removed. The result was CLtL1.
The assumption was that you could develop a Lisp based application (say, an expert system helping with jet turbine maintenance) on some platform of choice and then deliver it to the Airforce on some rugged PC, where it would be used in some airbase. People then thought, why not develop on the PC? Thus various implementations for PCs came up.
NASA was putting it on some embedded computer running million miles away from earth, controlling a spacecraft. There was really no limit to where one would have wanted it to be deployed... thus it ended up controlling your cleaning robot (Roomba)...
Some notes based on my (brief) experience toying with Common Lisp: * Why hasn't anyone made a more eye-frendly version of the Common Lisp Hyper Spec ? Having good, easily-browsable documentation is a core-problem. * The relation between the various native data-types were quite unclear to me. * dealing with the external world was quite a mess. Many project/libraries implementing only half of something and then got aba…
The hyperspec is only distributed under a restrictive license. The TeX sources of actual last draft of the ANSI specification is public domain though. This means that someone would need to retranslate from the TeX sources rather than modifying the hyperspec.
Some notes based on my (brief) experience toying with Common Lisp: * Why hasn't anyone made a more eye-frendly version of the Common Lisp Hyper Spec ? Having good, easily-browsable documentation is a core-problem. * The relation between the various native data-types were quite unclear to me. * dealing with the external world was quite a mess. Many project/libraries implementing only half of something and then got aba…
I'm not sure what was unclear. Perhaps you cuold give a specific example of something that confused you?
Watch YouTube video from Baggers. It's a lot more complicated than your average windows user will want to go through. Than you have to setup EMACS, quicklisp...etc. I never really new what quicklisp was doing and it made me nervous (I trust VS nuget).
Can someone point me at an argument for why I'd want to write CL in 2017, given all the great alternatives available now?
I'll take a stab at this glib comment: 1. You've inherited an application written in Common Lisp 2. Common Lisp has features you find desirable that aren't available in another system 3. You like Common Lisp 4. Common Lisp helps you get the thing you're trying to do, done