Hacker News Reader

Come on now, this is a silly take with more than a little elitism.

An IDE (for a sufficiently static language) eliminates so much unnecessary mental load that is otherwise wasted on avoiding inevitable human errors—typos, type mismatches, forgotten cases.

I don’t want what is essentially trivia swimming around in my head any more than I want to find out about the inevitable errors I’ve made when I come to compile or run my program.

I want to know that no such issues exist well before then, so I can focus on making sure my program actually behaves correctly.

I'm sorry, I know it can come out that way, but I am a developer that uses both statically typed languages and happily use powerful IDEs with them, and I also develop in a Lisp (Clojure more specifically), almost to a perfect 50/50 split.

And I don't mean to say that you're a bad developer or not smart enough if you use an IDE. Of course you should use an IDE with Java or C# or C++. Those languages are all very good, and when paired with a good IDE can be quite productive. And even with a Lisp, you should and will want to use a powerful editor or IDE with good auto-complete, linting, jump to definitions, etc.

What I'm trying to say is that to be productive in a Lisp, it's a different learning curve.

You just can't come and say: "well I tried it a little bit, and I couldn't figure out how to do anything and I was really slow, so I just don't get the point of a REPL and I don't get why people claim it's a hugely productive tool."

I'm telling you why, it's like complaining that you type slower on a keyboard than you can write by hand for the first year of you using a keyboard. There's a learning curve.

You can't just say: "well I can't figure this out. Where is the IDE to help me with it? Where are the type definitions? Where is the compiler to guide me? I guess the Lispers are just full of it."

No, you didn't do what Lispers do. Lispers learn the language until those things are no longer a problem, and then they unlock a new found productivity combined with the ability to work inside a running program, quick iteration, being able to extend and mold the language to what is most efficient for you and your problem, etc.

It's 100% ok if you say that you don't feel it's necessary for you to go the extra mile to learn a Lisp properly. That's fine, if you find you're sufficiently successful and productive already with your language, that's totally cool. But you can't not properly learn it, and then claim that the claims of those who have are invalid.

It's like if you started to doubt a touch typist that's telling you that learning to touch type makes you a more productive typist, because when you tried it was hard to learn and you were slower at typing.

Is there a good standard reference or bible about the language?

Something like C's K&R or Lua ones?? Its sooo handy to have a clear picture from the creators themselves.

Yes.

https://en.m.wikipedia.org/wiki/Common_Lisp_HyperSpec

What would really help to persuade people that they'd be more productive in Lisp would be examples of software written in Lisp.

I was a teenage Lisp enthusiast and have seen these sorts of Lisp discussions go round and round in circles on online forums for the past couple of decades. Ultimately, the corpus of publicly available software written in Lisp just isn't that compelling.

It's often said (and may be true, for all I know) that there are lots of companies quietly using Lisp behind the scenes and reaping the benefits without shouting about it. But to be persuaded, people need to see results of the claimed productivity gains in the form of actually existing software.

It's also worth bearing in mind that there are lots of people (like me) who did give Lisp a serious try (Common Lisp in my case) and then moved on for various quite sensible reasons. Lisp enthusiasts sometimes speak as if anyone who doesn't love Lisp can't possibly have given it a thorough trying out, but I would question that assumption.

Sure, here’s our personal example: https://github.com/atlas-engineer/nyxt

If you've tried it properly and didn't personally found it compelling that's ok. I've seen people for who their mental model of how they think and approach computer tasks doesn't land to it, or people who just have other personal preferences.

As for example of software made with a Lisp, I feel people are never happy with them, like a constantly moving goal post, but there's a certain chicken and egg to it.

Some examples:

    - HackerNews
    - Emacs
    - LispMachines (the entire OS)
    - AutoCad (uses Lips as a scripting language)
    - Jak and Daxter (the first game)
    - Yahoo Stores (pre-sale)
    - Reddit (pre-IPO)
    - Datomic (no-sql tuple DB)
    - The flight system in the Boeing 747 Next (their latest 747 as of this writing)
    - Apache Storm (the distributed stream processor)
    - Walmart (they use it for backend stuff)
    - CircleCI (build automation)
    - Riemann (a high scale distributed event stream publisher)
    - worldsingles network (bunch of dating websites)
    - NuBank (a Brazilian bank)
    - ConsumerReports (all their backend)
    - The Climate Corp (agriculture software)
    - Roam Research (note taking app)
    - Kevel (ad server as a service)
    - HighSpot (sales rep software)
    - Reify Health (health related software)

Now those aren't all Common Lisp per-say, but Lisp languages so Arc, Common Lips, Scheme, Clojure, EmacsLisp, etc.

There's also a lot of use of Lisp that's not like a closed software, a lot of times it'll be a backend service or parts of a system is using Lisp, I know Amazon, Microsoft and Netflix have some such use, it's not wide scale, but you'll find some teams there using some kind of Lisp, as you'll sometimes see job offers that mention it.

A typical standard lib may have thousands upon thousands of functions with many less commonly used arguments and options. If you are saying "memorise the lot" is the only route to productivity on lisp then I'm out, because that's unrealistic. And let's not get into libraries outside of the standard lib, am I expected to memorise XML parsers, graphics APIs, and so on as well?

If you are saying "memorise what you commonly use" then that's fine, except that any typical program usually involves a lot of "lesser used" stuff as well.

You don't have to. Lisp development environments remember all what one loads into them: the definitions, their source location, their arguments, their documentation, who calls whom, the data types, ... One can ask Lisp about all that then.

> One can ask Lisp about all that then

How? As in what commands/functions/macros?

Say I define a function and compile with slime, how do I get the repl to print it back to me? And with a function I loaded from an external library? Is there something like macroexpand-1 for functions which will print it out?

M-. on a symbol brings you to the source code.

Common Lisp also has built in the function FUNCTION-LAMBDA-EXPRESSION, which returns the source for a function -> when Lisp has recorded its definition.

Try (DESCRIBE #'some-function) in SBCL to get information about the arglist, the types, the source file.

In a SLIME editor buffer try c-h m . This will display the buffer commands. There are a zillion of commands to get information about the symbols, code references, etc.

On my Lisp Machine:

    Command: Show Source Code (a defined function spec) mts::init-facts
    Source code for MTS::INIT-FACTS:

    (defun init-facts ()
      (setf *init-facts*
            '((world  (loc (actor joe)    (val cave)))
              (joe    (loc (actor joe)    (val cave)))
              (world  (loc (actor irving) (val oak-tree)))
              (irving (loc (actor irving) (val oak-tree)))
              (joe    (loc (actor irving) (val oak-tree)))
              (world  (loc (actor water)  (val river)))
              (joe    (loc (actor water)  (val river)))
              (world  (loc (actor honey)  (val elm-tree)))
              (irving (loc (actor honey)  (val elm-tree)))
              (world  (loc (actor worm)   (val ground)))
              (joe    (loc (actor worm)   (val ground)))
              (irving (loc (actor joe)    (val cave)))
              (world  (loc (actor fish)   (val river)))
              (irving (loc (actor fish)   (val river))))))

    Command: Show Callers (a symbol [default MTS::INIT-FACTS]) MTS::INIT-FACTS
    MTS::MICRO-TALESPIN calls MTS::INIT-FACTS as a function.
    MTS::MICRO-TALESPIN-DEMO calls MTS::INIT-FACTS as a function.
    Done.
    Command:

I'm referring to what you commonly use, but also I'm talking about the part of the standard library that involves more basic operations like creating collections, iterating them, defining and requiring modules, creating objects, looping, destructuring, literals, conditionals, data types, polymorphism, error handling, etc.

As opposed to say learning the standard library relating to MIDI access, or file IO, or other specialized things that in theory could be a library and aren't really core.

It might sound a little like syntax, but because Lisps have such a lean syntax, there's a lot of the fundamental constructs that are part of the standard library and they are more what I'm referring too.

For example you'll have things like: car, cdr, append, mapcar, some, every, symbols, keywords, loop, intern, quote, format, butlast, intersection, union, multiple-value-bind, apply, funcall, =, eq, eql, if, unless, typecase, cond, dolist, iterate, etc.

What often happens in Lisps is that each core function is very powerful and becomes almost a mini-DSL. So it takes a while to really learn about all those and have them memorized by heart so you don't constantly need to refer to the documentation about what they do and how they work and how to use them. And often their power comes when they are combined together as well, and that also takes some time to learn all the valid ways of combining them.

Before you are familiar with all that and it's second nature, almost instinctive, you'll be a lot slower to read and write code.

This was unnecessary, mate