PuercoPop

Given that wookie's author uses vim it is clearly possible. Another prominent lisper that uses vim is Steve Losh, they've even written their own swank equivalent based on nrepl, cl-nrepl https://github.com/sjl/cl-nrepl

Sorry to hijack the thread but congrats on Lem. It's nice to see how far it's progressed. You even have an XCB binding in there!

Lemonodor-fame is but a hack away!

Roswell and Quicklisp are two different things. Quicklisp takes care of downloading systems (what other languages tend to call packages) and makes them available to ASDF. Roswell and takes care of installing Common Lisp Implementations (think chruby + ruby-install). It also allows you to run lisp programs as scripts iirc.

FTW you don't need to install Roswell to try Lem, you can use cl-launch instead

I agree it _sounds_ like an armchair critic, but I prefer to give the benefit of the doubt. Maybe they had a bad experience involving Lisp?

The actively hostile to collaborative programming seems particularly misguided. Even an extreme case like the code from hu.dwim, which is written in practically a new language they built on top of CL and has barely any documentation is still fairly easy to understand.

As others have noted its written in 'rant form' so its bound to happen. The weird thing is that it doesn't seem to bash on Perl at all! The Appendix on Editors bashes Emacs a lot too. Its an OK book _if_ you enjoy reading rants, but if you want to Learn Lisp, Practical Common Lisp or Land of Lisp are way better.

There is StumpWM, a tiling Window Manager.

[0]: https://github.com/stumpwm/stumpwm

Do you say that out of experience? That is certainly not my _experience_. Lisp codebases tend to be easily "appropiable"

> Frameworks are there so you don't have to repeat the work of others

You know what else is there so we don't have to repeat the work? Libraries. And they don't take the control of how my code is called from me.

Frameworks are there because except for Lisps language provide little mechanisms to reduce boiler plate so people want to avoid writing boiler-plate to pipe libraries together. However that doesn't have to be the case, take a look at Hunchentoot.

Ftw I got the same error if I tried to log from the signup page. But when I tried to sign up from the form in the sidebar it worked

Sure. Although the documentation doesnt make it explicit your .authinfo file can have a gpg extension and Emacs will encrypt and decrypt it for you using gpg automatically

Same as Slime. Works across implementations.

They do, the reasoning they already put forth.

On the other hand your explanation is no explanation at all. No possible motivation. Just "people are bad everywhere m'kay".

The author? Most likely

https://twitter.com/stevelosh/status/1034147772440760320?s=1...

I have a similar experience. Started out learning Clojure because it was 'practical', stayed with Common Lisp because I had less tooling setup to deal with. To be fair, that was because the Emacs integration for clojure depended on a specific CVS revision of Swank and I was starting out with Emacs. The situation has greatly improved regarding Clojure tooling. Still not as good as CL.

With time I've found CL to be much more flexible than Clojure and less opinionated so you'll be able to explore different paradigms.

That said if you want to write an SPA, go with ClojureScript. It has a good dev UX story (Figwheel <3) and Webpack will have already lowered your expectations regarding build systems to so setting up a ClojureScript project will seem less of a hassle.

> Unless your data requirements are very specific, mem only, or not adapted to the relational paradigm any SQL engine will provide you with the best and more efficient algorithms to manipulate your data in the most common situations.

Too bad that Michael Stonebraker, Turing Award winner, disagrees with you. SQL are not the best solution for any common use case from the performance perspective.

Nevermind what they do to the design of an application. IMHO less people should default to using a database upfront. At least while protyping the idea.

https://cs.brown.edu/~ugur/fits_all.pdf

> For example, would you want to lose all your customers' orders and billing information if your code crashed?

There are things like WAL and snapshots. Having your dataset in RAM and querying directly doesn't exclude persisting it to disk. Read Stonebraker's "The End of an Architectural Era"[0]. Basically the OP is right in that SQL DBs were designed assuming that RAM was scarce and that asumption is no longer valid. They are innefficient for every common use case. By at least an order of magnitude.

[0]: http://cs-www.cs.yale.edu/homes/dna/papers/vldb07hstore.pdf

The Paracas have nothing to do with the Inca Civilization!

I wouldn't consider a desktop environment that forces one to put up with useless transition animations even a good desktop enviroment.

You are missing the point of the Lisp's type system.

> There has been some confusion about the difference between type checking for the purposes of compiling traditional languages, and type checking for the purposes of ensuring a program's correctness. [0]

Lisp type system is mainly designed for the former. Abstract data types are useful for the later use.

[0]: http://home.pipeline.com/~hbaker1/TInference.html

You don't have to hire for Lisp, or any language for that matter. Picking up a language is way easier than fundamental skills (statistics for AI for example). IIRC Dan Weinreb of ITA fame said they gave their new hires a copy Practical Common Lisp and two weeks. You know, the book that you dissed earlier in the thread w/o an argument.

> less libraries are written.

Given that Sturgeon was an optimist[0], that is hardly a problem. The only reason why most OSS libraries are using is because people don't do the due diligence of vetting their dependencies. There are more than enough libraries of adequate quality for common tasks.

[0]: “And folks, let’s be honest. Sturgeon was an optimist. Way more than 90% of code is crap.” – Al viro

> in general /tmp is not suitable for such inter-process communication.

Yeah, it is not like X11 uses it for precisely that purpose or anything. ^_^

Learn. Which is the whole poiny of education in the first place.

Instead of checking wikipedia for a general definition of idempotency, check the RFC for the definition that applies to HTTP

9.1.2 Idempotent Methods

   Methods can also have the property of "idempotence" in that (aside
   from error or expiration issues) the side-effects of N > 0 identical
   requests is the same as for a single request.

The current vim plugin from VSCode uses neovim under the hood, at least for some operations

It is similar to strings up to some size (I think it was 1024 but I may be way off base). Basically small strings are interned.

> For me anyway, readability isn't about one person actively developing code. It's about communicable code,

If the person who wrote it can't pass the 'readability' test above what are the chances that other people, who are less familiar with the code, will?

Although emerge is written in python, Afaik ebuilds are bash scripts.

Doesn't VSCode embeds neovim already, so you can use neovim plugins from VSCode as well.

> Emacsens

Nitpick. Emacsen refer to an editor in the Emacs family. It wasn't always the case that Emacs was equated with GNU Emacs.

No, he took action to bring pain and suffering to a group of people because of their sexual orientation

And when Norvig made that claim in from of McCarthy, McCarthy disagreed.

> Peter bravely repeated his claim that Python is a Lisp.

> Yes, John?" Peter said.

> I won't pretend to remember Lisp inventor John McCarthy's exact words which is odd because there were only about ten but he simply asked if Python could gracefully manipulate Python code as data.

> "No, John, it can't," said Peter and nothing more, graciously assenting to the professor's critique, and McCarthy said no more though Peter waited a moment to see if he would and in the silence a thousand words were said.

http://smuglispweeny.blogspot.pe/2008/02/ooh-ooh-my-turn-why...