Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Tragedy of the Common Lisp: Why Large Languages Explode

medium.com

Post reply on HN
Print view View original

101–110 of 126 posts

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

#101

Post by pjmlp »

microtherion wrote: post #67
lacker wrote: 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…

Pascal also cheated on size, by omitting some facilities that were almost indispensable for practical programs, leading pretty much all implementations do add them in incompatible ways.

The first version yes, ISO Extended Pascal fixed that, however by then everyone was mostly focused on being compatible with Turbo Pascal.

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

#102

Post by pjmlp »

klez wrote: post #94
em-bee wrote: post #90

Earlier quoted context omitted.

the significant difference between python and scheme here is that python is not small. but then, scheme is heading in the same direction if you look at the latest standards development

Depends on what you mean by "latest". R6RS is arguably huge. That's why they decided to split R7RS in two, a small core which is done and a huge version which, ironically, is still in the making.

R7RS is still in the making, not because it is bigger, rather due to politics that many don't agree with it ever happening.

The small core exists, because that was the only subset their were willing to agree on.

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

#103

Post by [deleted] »

a1369209993 wrote: post #77
zephyrfalcon wrote: post #64

Earlier quoted context omitted.

Apparently yes. A quick inspection suggests that this is the same in Ruby, Haskell, SWI-Prolog, Gauche Scheme, SBCL and D. (I might not have the latest version of everything, so maybe this has been fixed in some of them... assuming it needs fixing. Maybe there's a reason for the answer to be 2 if so many language implementations insist on it. Or, they all use the same faulty algorithm. I don't know.)

> they all use the same faulty algorithm Well, yes. To be fair, it's not like any of them make a secret of the fact that they're mistakenly counting unicode code points instead of characters.

[deleted]

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

#104

Post by the_why_of_y »

bluGill wrote: post #54
mateuszf wrote: post #38

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

C++ is only slightly larger than any other language if you subtract the standard libraries that make a language useful. If you add standard libraries C++ is a tiny language. C++ does have a lot of weird, inconsistent warts that make it tricky to learn/use everything. Which is why most people who advocate to use C++ talk about modern C++ which is C++ where you stay away from those warts.

"C++ a tiny language" - just in case anybody is missing the obvious sarcasm, people who have done it say that implementing a C++ front end takes a decade of effort: https://news.ycombinator.com/item?id=17130870

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

#105

Post by pfdietz »

zimpenfish wrote: post #99
pfdietz wrote: post #58

Earlier quoted context omitted.

https://github.com/pfdietz/ansi-test >.>

> in his spare time I don't wanna be -that guy- but ... github lists 5 contributors on that repo. "his" is doing a lot of work in your claim there.

I stopped working on that for a number of years, and others maintained it, but the original test suite was just mine. Look at the ILC 2005 paper in the doc/ directory there.

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

#106

Post by mateuszf »

cjensen wrote: post #50
mateuszf wrote: post #38

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++.

Yeah, I'm not a big fan of the language, I'm only saying it's used a lot. Seems that in this case there was not a lot of portable fast alternatives for system / device / high performance programming.

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

#107

Post by em-bee »

pjmlp wrote: post #102
klez wrote: post #94

Earlier quoted context omitted.

Depends on what you mean by "latest". R6RS is arguably huge. That's why they decided to split R7RS in two, a small core which is done and a huge version which, ironically, is still in the making.

R7RS is still in the making, not because it is bigger, rather due to politics that many don't agree with it ever happening. The small core exists, because that was the only subset their were willing to agree on.

right, it may not happen, but at least some people want to add stuff to scheme that will make it larger, to eventually reach the point where it no longer can be called a small language.

i don't know if/when that point will be reached. my comment was hinting at the potential for scheme to become larger.

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

#108

Post by pjmlp »

btilly wrote: post #68
GorgeRonde wrote: post #60

Earlier quoted context omitted.

The absence of abstraction being what exactly ? Also beware of that kind of pseudo-wise thinking. Is there a point in climbing up a learning curve anymore ? Maybe you have a constant and massive stream of fresh bodies to throw at your "simple" solutions before laying them aside once those abstractions have clogged up their heads ... And maybe if you can unskilled workers at such a scale, it's because you have massive…

Before dismissing it out of hand, take a look at the Go language. It was designed to make specific kinds of common abstractions hard exactly because, when working at scale, programmers routinely create disasters by layering abstractions in a way that nobody can understand the consequences of.

Go is Java 1.0 all over again.

If it's enterprise adoption ever goes beyond Kubernetes and Docker, expect GoEE and Go Design Patterns to make their appearance.

Worse, since its plugin support is really cramped down, expect any enterprise grade CMS to be built on hundreds of processes.

This happens all the time with simple languages, tons of library boilerplate code.

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

#109

Post by e40 »

nonbirithm wrote: post #3

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…

I just tested this in Allegro CL 10.1: with and w/o the compiler: 15MB and 11MB.

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

#110

Post by pjmlp »

F-0X wrote: post #56
lacker wrote: 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…

I quite strongly disagree. My favourite languages, Scheme, C, Go, share precisely the "small and focused" philosophy, and its a big reason why I like them so much. Your point about javascript is not very strong either, I imagine the real reason is its origins as a browser-embedded language meant that the same style of imports in Node.js were not feasible. Even if this is not true, I would then shift the blame to the…

C appears small.

I doubt even veteran C developers know by heart its 200 UB documented use cases on ISO C, or the specificalities of any C compiler other than the one they daily use, and which features of it are actually part of ISO C.

Unless they happen to do ISO work all day long.

Post reply on HN