If emacs is an obstacle to Common Lisp in 2017, maybe what's needed is a Lisp-interaction plugin for vi(m) (or whatever it is that vim uses in lieu of emacs modes). I don't get the hype for modal editing but you can't argue with the data clearly showing emacs users are in the minority.
How to write Common Lisp in 2017 – an initiation manual
31–40 of 271 posts
Re: How to write Common Lisp in 2017 – an initiation manual
#32Earlier quoted context omitted.
Nope, it has new problems that are (IMO) worse.
I have dabbled in Common Lisp over the years and am quite comfortable with it. I know nothing about Clojure. What are the problems with Clojure? I am just curious. Thanks!
In addition to the other problems described, Clojure just breaks the value of Lisp's syntax. Common Lisp does have its irregularities but code littered with Java imports and square brackets might as well just use C formatting and be done with it.
Re: How to write Common Lisp in 2017 – an initiation manual
#33I wish an experienced LISPer would explain why should one use Common Lisp over a language like Golang. Golang now has https://github.com/glycerine/zygomys for scripting. For that matter, why would one choose Common Lisp over GNU guile ? (guile now supports fibers). What does Common Lisp offer for the working programmer that is an advantage over other languages ?
"I wish an experienced LISPer would explain why should one use Common Lisp over a language like Golang."
Those are two very languages. Very few people would find themselves ever staring at a choice of what language to use, having narrowed it down to just those two.
Lisp is notorious for its mind-expanding freedom. I think perhaps this attribute of it is less unique than it used to be, but it is still present. While I have hard time recommending it for production usage, you can still learn a lot about programming from using it for a while. It is still one of the most programmer-empowering languages there is.
(Indeed, I think the vast bulk of the reason why it's not really all that great of a language and why it has never taken off is that it is too programmer empowering; it grants power the vast, vast bulk of programmers are not actually capable of handling well at scale. It makes it so that two programmers separated by some communication gap rapidly find it challenging to write code that works together. That said, deliberately spending some time in such an environment is an important step for the budding systems developer, I think.)
Re: How to write Common Lisp in 2017 – an initiation manual
#34I wish an experienced LISPer would explain why should one use Common Lisp over a language like Golang. Golang now has https://github.com/glycerine/zygomys for scripting. For that matter, why would one choose Common Lisp over GNU guile ? (guile now supports fibers). What does Common Lisp offer for the working programmer that is an advantage over other languages ?
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 the moment, it doesn't, because almost no language has that right now.)
This doesn't invalidate your underlying point that you want to use a language without implicit nulls... it's just the wrong terminology.
Re: How to write Common Lisp in 2017 – an initiation manual
#35Can 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
Re: How to write Common Lisp in 2017 – an initiation manual
#36If somebody is not comfortable to use emacs (I am), there is a atom plugin for use with CL: https://atom.io/packages/atom-slime
It doesn't replace emacs, but it works as a first Lisp ide.
Re: How to write Common Lisp in 2017 – an initiation manual
#37Can 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
1. Because I was forced to? That's not why I'd want to.
2. Examples?
3. Fair enough. Though AlexCoventry's question probably shows that he does not (currently) like Common Lisp, so this answer doesn't give him a reason.
4. Sure, that's true for every language and tool. Choose it when it helps you, don't when it doesn't. But why would CL help me more than another language?
Re: How to write Common Lisp in 2017 – an initiation manual
#38I'm used to languages like Python, that have a number of files that are modules, and to start a program you run one of them as an entry point. C programs consist of a lot of files that are compiled and linked into a binary executable. Whenever I've tried to learn CL, I couldn't really wrap my head around what the eventual program would be. You build an in-memory state by adding things to it, later dump it to a binary…
I mentioned elsewhere I'm learning Common Lisp. I'm also learning Python by translating some Common Lisp code into Python and part of that is to make sure I understand what the Common Lisp is doing. As an understatement, that's meant building some very unPythonic abstractions (yay, me).
Anyway, I think there is a fundamental design difference between Common Lisp and other 'first class' programming languages: Common Lisp was designed as a way to use computers because a computer user would sit down at a Lisp Machine (which was the future when Common Lisp was designed) and use Common Lisp to do ordinary computer stuff like store their recipes and manage appointments and copy files between directories. It's reflected in the :cl-user package not being called :cl-programmer and the logic of typing (in-package :tps-report) on Saturday at the usual time.
Most other languages don't have this idea...In Unix users don't fool around with stdio.h. In Python, there's no clean way of switching between applications at the REPL -- or rather interpreter -- because of how Python handles the hard job of naming things (like most languages, there's a bit of punting on third down with the catchall epithet 'unpythonic').
This makes it hard to get one's head around Common Lisp, but it explains why a person might leave a REPL running for a week and make better progress because of it.
Re: How to write Common Lisp in 2017 – an initiation manual
#39If emacs is an obstacle to Common Lisp in 2017, maybe what's needed is a Lisp-interaction plugin for vi(m) (or whatever it is that vim uses in lieu of emacs modes). I don't get the hype for modal editing but you can't argue with the data clearly showing emacs users are in the minority.
slimv is a swank client for using Common Lisp inside vim. http://www.vim.org/scripts/script.php?script_id=2531
Re: How to write Common Lisp in 2017 – an initiation manual
#40I wish an experienced LISPer would explain why should one use Common Lisp over a language like Golang. Golang now has https://github.com/glycerine/zygomys for scripting. For that matter, why would one choose Common Lisp over GNU guile ? (guile now supports fibers). What does Common Lisp offer for the working programmer that is an advantage over other languages ?
"I wish an experienced LISPer would explain why should one use Common Lisp over a language like Golang." Those are two very languages. Very few people would find themselves ever staring at a choice of what language to use, having narrowed it down to just those two. Lisp is notorious for its mind-expanding freedom. I think perhaps this attribute of it is less unique than it used to be, but it is still present. While I…
> It makes it so that two programmers separated by some communication gap rapidly find it challenging to write code that works together.
The problem is not within a team, distributed or not. That will work, even for larger teams with some guidance. It's more the application and libraries which the team produces over time. 'Syncing' them with the outside can be hard. But you'll experience that in Java applications which use large frameworks, too. Same in Javascript.
This made it important to use a common Lisp standard and was the reason DARPA called for the creation of Common Lisp. Every DoD contractor brought their own Lisp dialect with their application, which made maintenance and sharing difficult and costly.
The standard could have been about more, concurrency/graphics/..., but much of that was rapidly evolving technology and it made little sense at that time to create a real standard for graphics - later Lisp didn't have enough commercial backing for these things and people were moving on to simpler / more conventional languages like Java with lots of industry support.