lieks

I'm currently working on a programming language that will probably be very boring in practice (Algol/Pascal structure, C-ish syntax, traits/typeclasses but only modules can be generic, not sure if GC or borrow checking but probably a hybrid).

The idea is to have something efficient enough, with the least amount of implementation complexity (including codegen), and still being nice to use, which is a really interesting balancing act.

For example, instead of implementing loop optimizations I could add APL-style broadcasting; I could make a complicated but efficient GC runtime or a complicated but efficient borrow checker, but I could also make both a dumb GC and a dumb borrow checker that somehow complement each other.

It's kind of a researchy language, but not trying to be new or interesting. Just "globally simple".

Most features are in an theoretical design phase, but I'm currently working on a new backend (LLVM is too fancy to count, QBE is too basic).

In Brazil, which has never used imperial, the Quarter Pounder is called "Quarteirão", a literal translation would be "big quarter". Most people probably parse it as a "city block", though.

Also, a regular burger here is 130-180g. A Quarter Pounder is smaller than I thought.

It's not modern. Jesus recommends it in one of his sermons. It's just unfortunately rare, like most good things about christianity tend to be.

I used to work at a company where running the full test suite took about 10min on my local machine. I would often run

    ./test.py; beep

where beep is a script I made that plays the Macintosh boot beep[1]. It was pretty useful.

I also did something similar that one time I had to compile LLVM (~4h on my laptop) and that other time I had to compile Firefox (~6h on same laptop).

[1]: https://ieks.cc/articles/mac-beep.html

You... don't. You have to rely on compiler optimizations to get good performance.

Monads are more-or-less syntax sugar. They give you a structure that allows these optimizations more easily, and also make the code more readable sometimes.

But in your example, update returns a new copy of the state, and you map it over a list for each step. The compiler tries to optimize that into in-place mutation.

IMO, having to rely so much on optimization is one of the weak points of the language.

For context: the author (see his other posts) is exploring the possibilities of writing C with no C runtime to avoid having to deal with it on Windows. He began to kind of treat it as a new language, with the string type, arenas and such, which help avoid memory bugs (and from my experience, are very useful).

This is a pretty cool hack. Makes me want to write a regex library again.

I remember reading, a long, long time ago, a paper where the authors suggested if the universe was slightly hyperbolic, it would also cause a redshift effect. I can't seem to find it (and as far as I remember it was purely theoretical), but at the time I thought it was an neat idea.

Not that I have the background to know what else they might not have accounted for to reach this conclusion.

Also applies to: Lisp, Haskell, Smalltalk, APL, Forth, even C. Maybe you can write Kotlin like C#, or Lua like JS, but style is not portable in general.

It just occurred to me that a crab would be much easier to keep upright (due to six legs, no need for fancy leg AI) and also much more on theme.

They had the dog already working, though.

...huh. As a non-native speaker, that was... easy to read? Where did I learn this vocabulary again? I haven't read Shakespeare's works yet (though they are on my reading list).

What makes it hard to read for some people and not others (as with any translation problem) is unfamiliarity.

It's easier to learn just japanese honorifics and then read a partial translation than to learn all of japanese and read the original. But a full translation loses that dimension of meaning.

But it's not as difficult to learn some Early Modern English vocabulary, and this way you can avoid losing any meaning. I hear there are a lot of puns that wouldn't work with modern vocabulary.

If it wasn't required reading in English-speaking countries, "translating" it probably wouldn't be even in consideration.

As an introvert, it's really annoying when I'm talking to someone else and tell them something, only to be told I'm wrong, with no arguments or data whatsoever.

If I wasn't certain, I wouldn't be talking about it in the first place.

Yes! That's the one.

The Rust/memory safety crowd does exaggerate its importance somewhat. Arrays aren't actually that common in some types of applications, especially kernels, which is what C was designed to implement.

Null-terminated strings are bad, but there's nothing about the language (other than the standard library and literals) that forces you to use them. There are several alternative implementations[a][b].

1 is true, but the modern interpretation of UB is against the spririt of the original standard, even though it's according to the letter of it. It was meant to mean exactly what you're talking about, but got optimized into oblivion later.

2 is what I'd say is the main problem with C. The library is truly awful, to the point where I treat all of it except the mem* functions and maybe exit deprecated.

3 is not true; look up how the BSS segment works (it might be true on Windows, I don't know, but that's not really a very good C implementation, since it's for C++ primarily).

4 is true for a reason; pre-standard C didn't have function prototypes. This was invented by the standard, to much rejoicing. But they needed compatibility, so that's where it comes from. Switch cases are really labels, and that's why they fall through. If C was more actively developed (read: less stable) these would have already been fixed, by deprecating them and creating replacements.

5 is not something I usually care about much. Write one header file per module, don't include headers from other headers (declare anything you need in the header itself, the compiler allows it) and just prefix each exported function with foo_ or something like that. It's not that much trouble, and you get multiple .c-files pre module, which some languages don't allow.

The thing is that, in order to fix most of those issues, you'd either break backward-compatibility (and fork the laguage) or break most existing implementations (and lose all support). Making a new language is much easier.

As for tracking lengths, I mostly agree. If the length is statically known, that's perfectly fine. But dynamic lengths shouldn't have hidden tracking. Still, the C99 solution isn't that great, and I can't see how else to do it.

[a] https://nullprogram.com/blog/2023/10/08/ [b] there was a fat-pointer string library, but I can't find it now

TCC doesn't do any optimization at all, so it shouldn't be that perplexing.

But any compiler that does constant propagation, inlining and (ideally) integer range analysis can optimize away most run-time bounds-checks already. If GCC or clang did it, it would probably be fast enough.

C99 did that.

    void f(int len, char s[len]);
    void g(float m[static 16]);

The first one is for variable-length arrays, the second one for fixed-length. TCC even implements array bounds-checking.

But because a lot of people were stuck using C89 for several decades (due to old compilers), and the syntax isn't that great, nobody even knows they exist.

Personally, I think Dennis Ritchie's[a] proposed syntax[b] was much better:

    void f(char s[?]);

[a] The creator of C.

[b] https://www.bell-labs.com/usr/dmr/www/vararray.html

Hmm... Let's see...

Oh, functions can't return arrays in C. That would be a pointer. Well, that makes it easier.

    double **(**(*)(char *))(int)

It did take a couple minutes, but I just woke up. Also, idiomatically there would be a typedef:

    typedef double **A(int);
    typedef A **B(char *);
    B *

That took a few seconds to write.

I'm guessing, but it should be possible to pass anything remotely as a proxy with an ID: calls to a closure or the resolution of a promise cause further RPC, and sending it back recovers the original value.

> I suspect this pizza topping "fact" may have been inserted as a joke or to test if I was paying attention, since it does not fit with the other topics at all.

It's cool that it could notice that, but the phrasing is likely idiomatic. It does not necessarily imply consciousness.

In any case, "self-awareness" and "sentience" are such poorly-defined concepts: it's the same we humans have, but we don't even understand what it is that we have. How could we evaluate if something else has it?

I can attest to this. Once, a college teacher gave us a programming exercise, and then went on to suggest how we might go about solving it.

While he was talking, I started outlining a solution on a piece of paper. At school, I couldn't use a computer during class, so I'd gotten used to programming (and debugging!) on paper.

When I arrived at home, I typed it in and tried it out. Could I possibly reproduce that Multics story I'd read about?

It didn't compile the first time, but after correcting a variable name, it worked perfectly.

Note that Multics had a particularly good work environment: https://multicians.org/devproc.html

In particular, management was tech-savvy and everyone liked and respected each other. Most were also talented.

It starts by teaching the basics of programming logic, and by the end you know how to build and test a larger system.

It starts by explaining what is a stack, and by the end you could implement your own Forth.

And it shows how those two tasks can be one and the same.

(is this what you meant by "example pitch"? I'm not familiar with that term)

I started with the osdev wiki's Barebones Tutorial: https://wiki.osdev.org/Bare_Bones

It teaches how to do a hello world, with proper setup.

It's a bit more than a single C file, with some assembly/linker script/custom GCC toolchain required.

From there, that wiki is probably the most helpful resource you can find, along with the CPU manuals.

1024 instructions? At that point I'd probably just use assembly. At that size, it would still be manageable.

Hmm, maybe that's the fundamental difference in thinking; the people I'm thinking of would reach for the simplest tool that can feasibly handle the job, even if it's somewhat harder to use.

Yes, we do, in some contexts.

Because despite its complexity, slow compile times, lack of a specification or more than one viable implementation and bloated binary size, people still tout it as a C replacement.

For application programming, Rust is fine, but for embedded and systems programming, nearly any of those on its own can be enough to eliminate Rust as an option, depending on the situation.

Except for complexity, they are all solvable and being worked on, for this very reason. But Rust can never replace C completely, because it's not simple, and there is a sizeable portion of primarily C programmers who are minimalists.