“Stop Designing Languages. Write Libraries Instead” (2016)

Posted by teleforce 3 days ago

“Stop Designing Languages. Write Libraries Instead” (2016)(lbstanza.org)

279 points | 277 commentspage 4

vhantz 3 days ago|

> Stanza provides an optional type system, garbage collection, and a multimethod based object system. But if you don't like Stanza's object system, there is no way to write your own. This is one of the main directions of programming language research. Can we design a language so expressive that library writers can easily write the most appropriate object system, or most appropriate type system, to fit their application? Perhaps one day we'll have such a language.

We already have it. It's an obscure little language called C++. Tise interested in those kinds of extensions to a language should look into Herb Sutter's experiments with cppfront: https://hsutter.github.io/cppfront/welcome/overview/

lelanthran 3 days ago||

C++ is most definitely not it.

Lisp is what you are after if you want to include some object system as a library, or a new type of switch statement as a library or a new kind of if statement as a library.

C++ can do none of that.

AnimalMuppet 3 days ago|||

C++ can do some of that. Let's say I want an if statement that takes an integer and three blocks of code. It executes the first block if the integer is less than zero, the second if it is zero, and the third if it is positive.

OK, if you squint enough that by "block of code" you mean closure, or function object, then I can write that in C++. I can make the if statement a free-standing function (that is, not a member of a class), and add it to any library I wish.

Now, you can say that it's going to be tedious to use that, because you have to set up three closures every time you want to call this "super if". And you'd be right, but that's a different argument.

munificent 3 days ago|||

One problem is that closures don't actually behave like blocks. Consider that you might want to use this three-legged-if inside a loop. If it's a real statement, then those branches can have `break;` and `continue;` statements which affect the surrounding loop. If those branches are just closures being passed to a function, then they can't.

lelanthran 3 days ago||||

> OK, if you squint enough that by "block of code" you mean closure, or function object,

But we aren't squinting here; those closures can't perform a return where your `new-if` function is being used, they can't perform a `return` like a proper `if` can, you can't goto, or break or continue.

It's just a function taking functions, with all the restrictions that that entails.

philipallstar 3 days ago|||

How can you declare new syntax in C++? Wouldn't it just be a function call?

AnimalMuppet 3 days ago||

Yes, a function call. Not new syntax. But as a function, it would be trivial to add to a library.

My point was that you can often get the effect you want with no new syntax. (Cue 10,000 replies that state "but you can't get this effect without new syntax!" Perhaps not. Many of those tend to be rather contrived, though. I'm more sympathetic to the argument that new syntax would make something less clumsy. If it's something you need to do a lot, that matters.)

philipallstar 2 days ago|||

Yes - I see what you mean. There are degrees of ease of use at between - at the extremes - what writing assembly provides, which technically can do it too, and what something like, say, Haskell provides. C++ is of course closer to Haskell than Assembly, but there's still quite a headache in using your solution that is down to absent C++ language features.

DonHopkins 3 days ago|||

You can always use macros! Just look at how beautiful and elegant and easy to learn and transparent to debug the Microsoft C++ MFC COM/OLE/IDispatch/ActiveX object system macrology is. /s

https://learn.microsoft.com/en-us/cpp/mfc/tn038-mfc-ole-iunk...

pjmlp 2 days ago|||

C++26 reflection alongside compile time code execution, and template metaprogramming, can already do a lot.

It is the best way? Probably not, but we seldom get to chose what mainstream languages win out on the field.

hulitu 3 days ago||

> “Stop Designing Languages. Write Libraries Instead” (2016)

It looks that somebody listened. We now have 3 GTK libraries in a system, a lot of graphics libraries (cairo, etc) 3d libraries (Mesa, vulkan). It is a mess.

Arch-TK 3 days ago||

The problem is really that sometimes making something feel ergonomic in a language can be a pain.

Although that in itself might be a hint to change language and write your library there, instead of inventing a new one.

CyberDildonics 3 days ago||

Lots of languages could just be implemented with classes in C++. Every "probabilistic language" could just be types that interact with each other properly.

fithisux 2 days ago||

Julia got it right with its macro system. You can write embedded DSLs easily.

wolvesechoes 2 days ago|

But they are still worse experience that dedicated, separate languages. Compare ModelingToolkit.jl with Modelica (ok, there are some differences in capacilities, but just compare how better is to express models in Modelica).

fithisux 1 day ago||

DSL is always better until you need to grow an ecosystem around it. If you can, go down the DSL path, otherwise use embedded DSL. If you can, go down the embedded DSL path otherwise use a library.

agumonkey 3 days ago||

it's strange cause for some devs (lispers, smalltalkers, forth..ists), the language is the core, and any concept is to become a generic linguistic trait (and everything will be build by composing expressions with these traits).

yet at the same time, clojurists love the idea of doing lots of dsl libraries..

noreplydev 3 days ago||

i think that languages is are for worlds and libraries are for adding ships, planes and cars to that worlds, enabling those worlds itself.

the key is that not all worlds enable the same kinds of libraries.

vivzkestrel 3 days ago||

- i need a language that looks like typed python

- and runs 50 times faster than c, c++, rust and zig

- comes with a standard library covering 50000 use cases

- has direct integrations with drivers to every major database, crm, analytics provider, key value store, queue systems

newsoftheday 3 days ago||

The article seems to vibe railing against Java.

ActorNightly 3 days ago|

Nothing wrong with that. Log4shell should have been the end of everyone using Java.

pjmlp 2 days ago||

There is this little mobile phone platform out there.

ActorNightly 2 days ago||

It has moved to Kotlin, which is what Java should be. With a custom VM. And even now, Google is moving to Fuschia which is Dart based.

pjmlp 2 days ago||

Nope, it is still Java, Kotlin is only the JetPack libraries.

https://source.android.com/docs/core/architecture

Also Koltin is meaningless without Java Virtual Machine, which is used to power most of Koltin existence[0], Gradle, Android Studio, thus the Android team keeps updating the Java support so that they don't lose access to the most used versions in Maven Central.

[0] - Kotlin Native and Kotlin Javascript are quite poor in available libraries

dieggsy 3 days ago|

I think I mostly agree with the thesis here, but I actually liked the point in the title at face value, too. We need both, I think. I guess I'll be another annoying Lisp guy, but:

> At this point, the right question to ask would be, well can you write a static-typing library for Scheme that then automatically checks your code for type errors? And the current answer, for now and for the foreseeable future, is no. No mainstream language today allows you to write a library to extend its type system.

The author seems to provide a counter example themselves(?):

> Racket and Shen provide mechanisms for extending their type systems...

I wonder if this is as clear-cut as the author is making it out to be. Coalton, which is effectively a library (and language) for Common Lisp, seems like it basically does this. Maybe that's not exactly what the author is referring to, because it is essentially a new language on top of Lisp using its meta-programming facilities, as opposed to merely extending the type system. Still, it can be used as a library right alongside Lisp code, so I think it's in the same spirit of of the first question of writing a "static-typing library that automatically checks your code" in a dynamic language.

Standard scheme may or may not be able to do this, but most Scheme implementations have unhygienic macros like CL's too, so I'd assume something similar would be possible. The fact that that these tend to be extensions from implementation designers might align with the article's point though. Also somewhat to the author's point, Coalton does rely strongly on CL's underlying type system, for which there's no real equivalent in Scheme. It also relies on implementation-specific optimizations alongside that.

For what it's worth you can (and indeed people have) written object systems in Scheme, despite the language not having one, though they tend not to be performant, which is likely another point towards using/writing a different language. CL also tends to allow fairly deep extension of its object system through the Meta-object Protocol.

I guess my point is that in my (probably biased) opinion, Lisps, or other languages with very strong meta-programming facilities, are pretty close to the language longed for in "Perhaps one day we'll have such a language." They aren't a silver bullet, of course. CL has no easy way to write performant coroutines/continuations, for example, even given all its extensibility. Scheme has no real type system, etc. etc.

I don't think any of this invalidates the articles points, I'm just not sure I agree with the absolutes.

More comments...