> The people writing libraries have no idea how their library will be used.
Unless you're paying them, the people writing the libraries have no obligation to care. The real issue is Big Tech built itself on the backs of volunteer labor and expects that labor to provide enterprise-grade security guarantees. That's entitled and wholly unreasonable.
> Take libxml2 as an example.
libxml2 is an excellent example. I recommend you read what its maintainer has to say [1].
That's part of my point. As Nick says, libxml2 was not designed with security in mind and he has no control over how people use it. Yet in the "security only in the critical components" mindset, he's responsible for bearing the costs of security-critical development entirely on his own since daniel left. That sucks.
But this isn't a conversation limited to the big tech parasitism Nick is talking about. A quick check on my FOSS system implicates the text editor, the system monitor, the office suite, the windowing system, the photo editor, flatpak, the IDEs, the internationalization, a few daemons, etc as all depending on libxml2 and its nonexistent security.
Copyleft isn't about the software authors freedom, it's about the end-users freedom. Copyleft grants the end-user the freedom to study and modify the code, i.e. the right to repair. Contrast this with closed-source software which may incorporate permissively licensed code: the end-user has no right to study, no right to modify, and no right to repair. Ergo less freedom.
> I feel that prototypes are harder to wrap one’s head around compared to classes.
This is sad to read because prototypes are conceptually easier to understand than classes. It’s unfortunate that most developers experience with them is JavaScript, because its implementation is extremely poor. I recommend trying Io which is very Self inspired as well as Lua.
This perplexes me. Lua was conceived as a configuration language and the whole point of a configuration language is you edit a config file. Trying to abstract this away behind a CLI seems like it misses the ethos of Lua.
It’s also a tad strange that a package manager designed for Lua isn’t written in Lua. Presumably Lua developers already have Lua installed, know Lua, and would more likely contribute to a project written in Lua.
> Trying to abstract this away behind a CLI seems like it misses the ethos of Lua.
With `lx add <package>`, you can install the package and add it to und config file in one step. And do things like fail if the package or version doesn't exist or isn't compatible with your system.
You can provide editor plugins or use LSP to give users hints if there's an update available, and use code actions to update them, etc.
> It’s also a tad strange that a package manager designed for Lua isn’t written in Lua.
Again, the fact that Lux relates to Lua is a pretty weak argument for choosing Lua as a language to write or configure it in.
Lots of Lua libraries and packages aren't written in Lua, but are built with Lua bindings.
Lua (which as you yourself just mentioned was conceived as a configuration language) is a pretty poor choice for something with the scope of Lux.
In fact, luarocks was recently rewritten in Teal.
Lux has a Lua API (lux-lua) which means it can be embedded or used as a Lua library.
> Presumably Lua developers already have Lua installed, know Lua, and would more likely contribute to a project written in Lua.
We're not worried about finding contributors. If anything, what we need are high quality contributions. Lua developers who only know Lua are not what we're looking for.
> It would be much more interesting to see a language which experiments with what is fundamentally representable
You might checkout my project, Confetti [1]. I conceived of it as Unix configuration files with the flexibility of S-expressions. I think the examples page on the website shows interesting use cases. It doesn't have a formal execution model, however, for that you might checkout Tcl or Lua.
In practice, there are still types, they are just validated by your application. I didn’t want Confetti itself to make assumptions. I wanted to give you the freedom to define your own custom types and keywords, like “on” and “off”, or even tri-states like “yes”, “no”, “maybe”.
The problem with mandatory keywords, like “true” and “false”, is they box you into the English language. And which data types should be intrinsic is arbitrary, for example, TOML has data types for date and time, but JSON does not [1]. Where do you draw the line? Confetti let’s you decide.
You might enjoy reading this take on the subject [2].
The code is very readable and well organized. My only major critique is that there's very little error checking, e.g. there are many calls to snprintf and malloc without checking the result. There is also an unused loop here [1].
As an aside, I don't see any support for parallelization. That's fine for an initial implementation, but web servers do benefit from threading off requests. If you go that route (pun intended) you might consider using something like libuv [2].
So to be clear, I love all of those languages and wish the design space of prototype-based inheritance was explored more.
Having said that: why would he though? In this particular talk he's trying to argue to people who program in C++ why the historical C++ architectures are limiting it, he's not trying to convince anyone to switch languages. So those languages aren't his audience.
I'm curious what a hashmap looks like with this approach. It's one thing to pass through or hold onto a generic value, but another to perform operations on it. Think computing the hash value or comparing equality of generic keys in a generic hashmap.
I first would question what a user wants to do with a hashmap that uses polymorphic key-values of unknowable type at compile-time.
As a thought experiment, you could certainly have users define their own hash and equality functions and attach them to the table-entries themselves. On first thought, that sounds like it would be rife with memory safety issues.
At the end of the day, it is all just bytes. You could simply say that you will only key based on raw memory sequences.
> I first would question what a user wants to do with a hashmap that uses polymorphic key-values of unknowable type at compile-time.
All of Apple's modern platforms use this concept pervasively, because the Objective-C Foundation framework has a common primitive data structure for it (NSDictionary).
Unless you're paying them, the people writing the libraries have no obligation to care. The real issue is Big Tech built itself on the backs of volunteer labor and expects that labor to provide enterprise-grade security guarantees. That's entitled and wholly unreasonable.
> Take libxml2 as an example.
libxml2 is an excellent example. I recommend you read what its maintainer has to say [1].
[1] https://gitlab.gnome.org/GNOME/libxml2/-/issues/913#note_243...
reply