Imagining the Ideal Language for Writing free Software (my talk from #fosdem 2021) just got posted: http://bofh.nikhef.nl/events/FOSDEM/2021/D.perl/programming_lang_for_free_software.webm
In that presentation, I ague that #typescript, #golang, and #rust aren't great fits for Free Software (even though they're all well-designed languages and I still <3 rust!). And I think about what we _do_ want in a language aiming at Free Software.
Slides are available on my site (but truly are a visual aid, so may not make that much sense alone) https://codesections.com/presentations/fosdem-2021/#/intro
Oh, I guess that https://video.fosdem.org/2021/D.perl/programming_lang_for_free_software.webm might be the better link for my _Imagining the Ideal Language for Writing Free Software_ talk.
I guess #fosdem must be doing something fancy with redirects and load balancing, so we might as well play along.
There's also an mp4 version, if you happen to prefer that to webm: https://video.fosdem.org/2021/D.perl/programming_lang_for_free_software.mp4
@wyatwerp OpenSmalltalk, the optimising JIT runtime usually used for Smalltalk is a few million lines of C, but I guess you can just interpret bytecode, and some day we'll see a metacircular Smalltalk system. The actual Squeak, Pharo et al images are much smaller.
@wyatwerp https://github.com/OpenSmalltalk/opensmalltalk-vm/search?l=c has a metric fuckton of C, but you could still be right and they just condensed the Slang code down :)
> thank you, really nice talk! Its the first time I heard software development likened to authoring as a technical point, even though it has been a primary philosophical point in free/libre philosophy all along.
Thanks, I'm really glad you liked it :D
> How complex is Raku's implementation?
Medium-ish? I certainly wouldn't put in anywhere close to Squeak. But a small team has implemented it 3–5 times so far (depending on how you count, and the focus now is on ~1).
One interesting wrinkle for multiple implementations is that Raku has a spectest (https://github.com/Raku/roast) rather than a written spec. The pitch is that this makes multiple implementations dramatically easier (and reduces debates about what the spec "really means").
The counter-argument is that it means Raku doesn't *have* a real/traditional specification
@codesections Ah, nice. I missed that one.
A lot of your points reflect the things that make me like ruby more than go.
Sure, I can do many of the same things in go (and even more), but it always feels like I have to write extra code to do what I want. And when I'm done I'm always left wondering if it's optimal because I had to "re"-implement functionality.
@codesections (Random thoughts)
Slides are available on my site (but truly are a visual aid, so may not make that much sense alone)
Honestly, that's they way I see slides: They shouldn't contain the text you're presenting, they should have small clues that will link to what you're saying; people will remember those small clues and recall what you said.
Also, even without seeing the presentation, I really got that "Cathedral, Bazaar, Nuclear Meltdown" reference :D
> that's they way I see slides: They shouldn't contain the text you're presenting, they should have small clues that will link to what you're saying
I agree (er, I guess that's obvious, given that we're talking about a set of slides that I wrote…)
But people have gotten so used to slides that can basically be read as a blog post that I thought it was worth setting expectations :)
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.