Live data from Hacker News

The Tragedy of the Common Lisp: Why Large Languages Explode

medium.com

41–50 of 126 posts

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#41
post #22

Earlier quoted context omitted.

Last I checked, Racket literally has sublanguages defined for teaching and learning: "Beginning Student", "Beginning Student with List Abbreviations", etc. https://docs.racket-lang.org/htdp-langs/index.html

Indeed. You can even MAKE your own language with Racket to suite teaching needs.

Or you can rediscover LOGO, which is LISP to the bones:

? show (map [[x y] [output se :x sum :y #]] [a b c] [10 20 30])

[[a 11] [b 22] [c 33]]

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#42
post #11

I kind of wish there was a lisp with the "recompile on error and continue" feature of Common Lisp but without a massive standard library. A standalone SBCL program seems to be around 40MB at minimum. It feels like it would be doable if only CL wasn't designed with the kitchen sink included. Recently I've gotten into Janet[0] and really like the language, although I do miss CL's recompilation magic at times. It feels…

> recompile on error and continue I'm not familiar with this. Anyone care to explain?

https://malisper.me/debugging-lisp-part-1-recompilation/

That's a good example. When an error is signaled you're able to modify the program (via recompilation of functions, changing of values) and restart at a point you select. There are other things you can do, but this is a particularly powerful option.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#43
post #32

After programming for 20 years, I've noticed that programmers are aware of the potential benefits of any abstraction that they have internalized, and blithely unaware of the costs. Because, having climbed that learning curve, it is now free to them. The result is that programmers introduce complexity lightly, and when they walk into a new language/organization/etc are inclined to add random abstractions that they are…

I wouldn't look at it that negatively. Programming is like speaking a language, I don't mean what programming language you "speak" (ie, c++, or java, or whatever), but how you're used to speaking in it.

Like real language, you probably prefer certain idioms, you have your own style and you know certain words better than others. This is similar to how we program, we know certain algorithms, yet are oblivious to others, we have our favorite abstractions and have our etc.

There are downsides to these habits for both spoken language and computer programming languages, no doubt, you can get stuck in a rabbit hole without seeing you're in one. In the end, a similar approach works for both, read and write widely if you want to be great at these, meet different groups, work on uncomfortable projects, you know the drill.

Just like how you expand your language and therefore your world; socially.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#44
post #9

I kind of wish there was a lisp with the "recompile on error and continue" feature of Common Lisp but without a massive standard library. A standalone SBCL program seems to be around 40MB at minimum. It feels like it would be doable if only CL wasn't designed with the kitchen sink included. Recently I've gotten into Janet[0] and really like the language, although I do miss CL's recompilation magic at times. It feels…

Why not just use a smarter compiler/linker that trims out unused library code?

Some CL implementations do this ("tree shaking", as it is called). But some of the more popular open-source implementations (SBCL, Clozure CL) do not.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#45

I feel like this is the real success of Python: the "one and preferably only one obvious way to do it" idea means that new ways of doing something are rarely added, and when new they are added, old ones are likely deprecated. Complain all you want about the 2 to 3 transition, but it's resulted in a simpler, easier-to-use language. If the community really feels a different way is better, they add it in libraries. My o…

I don't think this is really true of python, often the "correct" (pythonic, theoretically best performance) way to do something involves using more complicated language constructs than most people are familiar with. For example, when to use list/dict comprehensions, when to use reduce functions, when to use generators. Most beginner programmers and people coming from C-inspired languages will do things the "obvious" yet incorrect way by doing a for-loop of appends.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#46
post #28
post #7

Lisp isn't a large language, it's a small language with a large library.

Common lisp is large-ish at least.

Common Lisp is small enough that one person could write a reasonably complete test suite for it in his spare time.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#47
post #46
post #28

Earlier quoted context omitted.

Common lisp is large-ish at least.

Common Lisp is small enough that one person could write a reasonably complete test suite for it in his spare time.

maybe medium? Compare to scheme... this is why I said large-ish, not large. There are lot's of corners to get into in CL.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#48
post #40

The Algol, Smalltalk, Pascal, and early Scheme languages were prized for being small and beautiful. Those languages are also not very popular at all today. Perhaps "small and beautiful" are not the right metrics to optimize programming languages for. In many ways, keeping the core JavaScript language small has led to the JavaScript ecosystem being too large and sprawling. For example, look at module importing, someth…

> Those languages are also not very popular at all today.

But yet, C (arguably 'current algol') and Python (arguably 'current scheme') are..

yes: python is verry loosely like scheme, this is meant in the sense of a 'dynamic loosely typed language you can interact with in a repl'

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#49
post #48
post #40

The Algol, Smalltalk, Pascal, and early Scheme languages were prized for being small and beautiful. Those languages are also not very popular at all today. Perhaps "small and beautiful" are not the right metrics to optimize programming languages for. In many ways, keeping the core JavaScript language small has led to the JavaScript ecosystem being too large and sprawling. For example, look at module importing, someth…

> Those languages are also not very popular at all today. But yet, C (arguably 'current algol') and Python (arguably 'current scheme' ) are.. yes: python is verry loosely like scheme, this is meant in the sense of a 'dynamic loosely typed language you can interact with in a repl'

> "dynamic loosely typed"

Both Python and Scheme are dynamic but strongly typed.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#50

Isn't c++ a large language? And yet it's still used.

Sure. But there are a lot of areas where you just shrug and say "here be dragons" and move on.

For example, consider the new for loop syntax

  for (auto item: a().b().c()) ...
Does this make you nervous? It should. In the above, suppose a(), b(), and c() are all returning objects. Which of these objects remains valid until the end of the for loop? And this is a dragon in one of the most helpful parts of new C++.
Post reply on HN