Hacker News Reader

Comment by PaulHoule | Hacker News Reader

I’d argue modern languages have taken many of the attributes of LISP, not least the garbage collector, development tools, higher-order functions, etc. The difference is that other languages use parsing technology based on Chomsky’s grammar whereas blub languages like Lisp can’t see the value in it. But I’d say if you are programming in Java or Python you are most of the way to LISP from Pascal or C.

For that matter, Common Lisp had what was probably the first modern language specification, that, as much as it pretended to be machine independent, was carefully designed to be implementable on the 32-bit microprocessors that were then coming online. There was a time when I thought Java was the first programming language to be specified by adults but know I know they were following in the footsteps of Common Lisp.

View on HN

> I’d argue modern languages have taken many of the attributes of LISP, not least the garbage collector, development tools, higher-order functions, etc.

Having features of a given language don't make something a full or even partial replacement for that language.

"It's not what languages do, it's what they shepherd you to" - https://nibblestew.blogspot.com/2020/03/its-not-what-program...

Raku has metaprogramming and an almost unprecedented amount of syntax... and an insanely slow implementation. Although they're chipping away at the speed thing.

Metaprogramming will struggle to go mainstream. It's the way you shrink a 50,000 line program down to 1,500 lines that nobody can understand but the author. I absolutely love doing it and I think I could hand the code off to somebody and have them make small changes in the DSL code but if they have to change something in the implementation to extend the DSL all bets are off.

After all these years we still don't have macro assemblers as good as what the IBM 360 had even though we now have architectures that have enough registers that it would be reasonable to pass a register name as an argument to a macro like you could do in IBM Macro Assembler.

When was the last time you checked performance? :-)

I actually did make a quick search to see if I was blowing hot air, and found this blog post that shows a bunch of benchmarks over time with a fairly typical Raku/Perl flavored text processing task, and it was taking 0.23s for the July 2022 release vs. 0.59s in Jan 2016 [1].

So that's a pretty impressive improvement--3x over 6 years--but I remember Raku being numbers like 4x or 5x slower than Python on benchmarks from the last few years, so by my very sloppy math it's still got to speed up by at least 2x or 3x to go to match Python.

It's also possible that there has been a ton of speedup in the last year-and-a-half since that benchmark, or it's not representative, but that's where I got the idea from.

[1] https://blogs.perl.org/users/sylvain_colinet/2023/01/benchma...

Like most scripting languages (e.g. Python), execution speed was not the top priority - in fact, like Python, most heavy lifting can be / is done by modules that are written in native C code, or Rust or similar via the C FFI / Inline::Perl interfaces.

To your point, I recently measured the compile time of this raku module...

# speed (2020)

# use Physics::Measure :ALL; ...13s first-, 2.8s pre- compiled

# speed (2024)

# use Physics::Measure :ALL; ...4.4s first-, 0.9s pre- compiled

... so about a 3x speed up in the last 4 years.

Also raku has no GIL and has good support for hyper / race so can get a lot out of your 32 cores (if you want speed).

Another raku module to mention (Dan::Polars) connects to the Rust Polars library via FFI (thus getting Rust level execution speed since Polars a lot faster than Python Pandas via the underling Apache Arrow data structures) ... this takes about 2s for the raku to compile and about 15s for the rust cargo stack to compile ...

> blub languages like Lisp

I see what you did[0] here.

0: https://wiki.c2.com/?BlubParadox

And to me the parsing aspect of lisp is key. It means the language won't resort to external tooling to improve. Most of the programming world defaults to increasing the number of things you need in order to do more, while lispers seemed to like absorption of concepts as the main strategy (see Steele: growing a language talk IIRC).

And you wind up overloading a small number of syntax constructions for an endlessly expanding number of uses and soon you're in a twisty maze of parenthesis that all look alike. Look at how HP calculators got trashed by TI.

I'd grant that parser generators still suck, people still act like you're crazy when you say you want to be able to write one grammar and automatically generate not just a parser but an unparser. (I could do amazing stuff with Sphinx if only it supported RST output as well as schemaless RST.)

CASE tools in the 1990 could parse code, let you edit it in a GUI, and make a clean edit to the code (not mess up comments, whitespace, and the ordering of things which is only significant to your version control tools) like a professional programmer would. That's still like something that fell off a UFO.

You should totally be able to compose two grammars. I ought to be able to stick a SQL query right into the middle of program in Java or any other language and have it parsed to an AST. If parser generators were sane I could add

  unless(X) { Y }

to a language like Java and add a method that rewrites it to

  if(!X) { Y }

and it shouldn't be more than 50 lines of code including imports and ceremony, just a patch to the grammar (AST objects ought to be code generated from the grammar) a simple rewriting function and telling the system where to find the grammar patch and the new function.

Parsing Expression Grammars are a step in the right direction but for a PEG parser to be really revolutionary it needs a few features I've yet to see in one, in particular there has to be some easy way to specify operator precedence either numerically or with a set of statements like

   Closer(*,+)

I am mostly disappointed w/ the PEG parser in Python because it falls short of revolutionary promises but you always get "fooled again" with parsing because people care about how fast their compilers are to the exclusion of almost everything else.

The twisty maze of parens I never understand. (And the fact that TI won is probably, imho, only vaguely to syntax, kids barely use calcs anyway, and I'd argue that if you'd show them RPL immense programming surface, lists, vectors, lambdas, they'd use it more than the usual fix function graphing calc)

I never had a chance to see proper CASE tools, my education started in 2000.. java/uml took the light and the few environments I saw were very very subpar (post IBM, eclipse based, rational suite).

The grammar composition is still a big open problem, I think Lawrence Tratt tried to attack it (maybe this https://soft-dev.org/pubs/pdf/diekmann_tratt__parsing_compos... ?) but concluded it was still fragile/difficult.

> Look at how HP calculators got trashed by TI.

That had almost nothing to do with syntax and almost everything due to lobbying.

HP was not an "approved" calculator for all manner of standardized tests while really shitty TI ones were.

HP calculators were everywhere in my engineering department from 1988 to 1992 (the HP-28S and then the HP-48SX went through them like wildfire).

And they're still both amazing piece of hardware and software and very much prized by people today. It falls in a totally different space of immense possibilities.

My point is that they were objectively better than anything TI was producing in the calculator space for a very long time--the evidence is that engineering students at a state school were forking over what were non-trivial amounts of money at the time for them.

The problem was that places like the College Board allowed calculators in 1994. That meant that an "approved" list of calculators appeared and for a long time the HP programmable calculators were considered "too powerful" and disallowed. That "approved" list propagated to other things that used calculators in official capacities.

That absolutely killed HP as the volume all went to TI since everybody bought TI calculators and nobody was going to then spend on an HP calculator that might not be allowed on your test.

By contrast, look at business and finance majors where lobbying didn't create an "approved" list--you will pry an HP-12B from their cold, dead hands.

Yeah I understand, I wonder what would have been if school had 50/50 blend of both brands. Educationally speaking it would have propelled a lot of things forward... but I guess education institution weren't able to foresee that much of a leap.

Reply on news.ycombinator.com