Elektrine lite

← Feed

@TomF@mastodon.gamedev.place

Post #2716193

2026-04-24 19:23 UTC

Fabian talked some about how languages are fundamentally tools, and they're all flawed, and no one language will solve all problems. And I absolutely agree. Some people spend a lot of time creating new languages, and I'm just not sure it's productive.

Replies (4)

  • @TomF@mastodon.gamedev.place 2026-04-24 19:24

    I can't find it in the video, but there was a question about how far down the stack you need to know. I mean Fabian and I like to know all the way down to the metal. But that's because we're strange. Most people do not - it's absolutely not necessary to get stuff done.

    Open ##2716194

  • @grwster@mastodon.social 2026-04-24 19:54

    @TomF@mastodon.gamedev.place Yes! I actively use multiple languages, selecting the one with the best “impedance match” to the particular problem I’m trying to solve, and knowing what’s going on under the covers is a huge part of that analysis. I’m also a hybrid EE/CS and there is no doubt that understanding hardware architecture has helped me in my software career.

    Open ##2716244

  • @meltedcheese@c.im 2026-04-24 20:16

    @TomF@mastodon.gamedev.place There is a balance. I often used both compile-time and run-time macros to provide higher level constructs — a mini-language — that matched my problem domain and let me control some optimizations. My colleague did something similar with an optimizing compiler that basically rewrote the source code (joke was it turned other people’s code into something he would have written). Bottom line: there are good technical and creative reasons to work with customized programming languages.

    Open ##2716245

  • @TomF@mastodon.gamedev.place I think there are a few different schools of PL design that sometimes have little to no intersection: the researchers (we want to test this one cool concept, but it requires the rest of the language to exist, so here it is, i guess)the pragmatists (doing these few things is going to be really painful in our platform/environment/system, so let's make something that isn't)the reframers (approaching these tasks in this manner is usually a source of problems later, so let's make it painful in exchange for less pain elsewhere)probably more personally, i'm partial to all three (i like rust because it does all of those things! and because i'm tired of writing embedded C) but the third one is my home domain. i want to build towards better ways of thinking, which coincidentally involves a lot of programming language development. but i also do this with libraries, it's not really essential that it's a language

    Open ##2716248