pkkm

This reads like a marketing stunt for Noma. The cute name, the logo, the clickbait title, the dramatic tone in an article that seems targeted at a non-technical audience... And the actual vulnerability is what, that if you give an LLM private data and let random people interact with it, it may leak the data? Well, duh.

Similar feelings here. Ruby's philosophy of providing a ton of different ways to do the same thing can lead to some pretty sweet-looking code, almost like poetry... but I'd rather have Python's stylistic consistency and better-integrated type hints. Now that Python has Poetry and uv, Ruby's main remaining advantage has evaporated and it's hard for me to justify using the language.

Another thing I don't like about Ruby is how much the community has embraced the Clean Code brand of readability snake oil. It's easy to come by the opinion that any function over 5 lines is a code smell and over 10 lines it's outright bad. I've even heard the view that if-else statements are a code smell and I should always try to replace them with different classes that have the same interface. To be fair, that only happened twice, but that's two more times than I've heard it from users of any other language. I think that the Python community usually strikes a better balance between avoiding excessive function/class length and avoiding excessive indirection.

PHP has its significant flaws, but superficial syntactic differences aren't among them. In my experience, it takes two weeks to get used to pretty much any syntax.

Thanks!

Is that different from what is happening already? A lot of people won't adopt a language/technology unless it has a huge repository of answers on StackOverflow, mature tooling, and a decent hiring pool.

I'm not saying you're definitely wrong, but if you think that LLMs are going to bring qualitative change rather than just another thing to consider, then I'm interested in why.

> the inefficacy of the popular forms of 'brainstorming' compared to the more painful forms that work

Interesting, what's your recommended resource for learning more about this?

I'm not the creator, the credit for that goes to Arie Bovenberg. I just wanted to show this to people.

I think wesselbindt meant that datetimes should not inherit from dates.

> My theory: what matters isn't "best practices", it's have a coherent conceptual design and code that reflects that design.

I think so too; that said, the language could definitely be better. It suffers from a lot of primitive obsession. Instead of structs, you often find either vectors or lists with predefined element positions; instead of map, ordered map, and multimap types, it's just various kinds of lists everywhere. They're not even used consistently: for the same thing, one package may use an alist and another a plist.

Programming with string templates, in a highly complex and footgun-rich markup language, is one of the things I find most offputting about the DevOps ecosystem.

I'm not seeing any empirical data in the article.

Both JS and PHP are rather footgun-rich languages; have you tried Python, Java, Kotlin, or C#?

Could someone who's more familiar with this project explain the advantages? To me, the main advantages of systemd are

1) It enables better separation of concerns, Twelve-Factor App style. For example, user-installed programs no longer need to connect to a logging daemon or execute a complex daemonization dance [1]. They can just run like a normal command-line program and dump logs to stderr.

2) It cuts down on integration problems, shell script glue, and the amount of different config syntaxes you have to know. Its architecture is modular with over 100 different binaries, so you can still pick-and-choose components and do privilege separation, but because these components are all coming from the same vendor, you know they're going to work well together.

3) It can do certain things far more reliably because it's willing to use Linux-specific APIs. For example, thanks to cgroups v2, it can supervise a process correctly no matter what kind of weird forking strategy the process is using.

Since this project is intended to be compatible across Unix-like systems, it won't be able to use Linux-specific APIs, so advantage 3 is gone. It looks like it dropped many components of systemd, so advantage 2 is partially gone too. Is this project just about getting some cross-cutting concerns into the init system and having better scheduling of service startup?

[1] https://www.freedesktop.org/software/systemd/man/latest/daem...

I'm a lot less experienced than you, but since you're collecting ideas, I'll give my opinion.

For me personally, the biggest improvements that could be made to C aren't about advanced type system stuff. They're things that are technically simple but backwards compatibility makes them difficult in practice. In order of importance:

1) Get rid of null-terminated strings; introduce native slice and buffer types. A slice would be basically struct { T *ptr, size_t count } and a buffer would be struct { T *ptr, size_t count, size_t capacity }, though with dedicated syntax to make them ergonomic - perhaps T ^slice and T @buffer. We'd also want buffer -> slice -> pointer decay, beginof/endof/countof/capacityof operators, and of course good handling of type qualifiers.

2) Get rid of errno in favor of consistent out-of-band error handling that would be used in the standard library and recommended for user code too. That would probably involve using the return value for a status code and writing the actual result via a pointer: int do_stuff(T *result, ...).

3) Get rid of the strict aliasing rule.

4) Get rid of various tiny sources of UB. For example, standardize realloc to be equivalent to free when called with a length of 0.

Metaprogramming-wise, my biggest wish would be for a way to enrich programs and libraries with custom compile-time checks, written in plain procedural code rather than some convoluted meta-language. These checks would be very useful for libraries that accept custom (non-printf) format strings, for example. An opt-in linear type system would be nice too.

Tool-wise, I wish there was something that could tell me definitively whether a particular run of my program executed any UB or not. The simpler types of UB, like null pointer dereferences and integer overflows, can be detected now, but I'd also like to know about any violations of aliasing and pointer provenance rules.

You don't need to make up your own for this experiment. There's already a pretty old protocol that's far superior to TCP, but failed to get adoption because of network hardware dropping everything other than TCP and UDP. It's called SCTP.

Looks fixed to me, thanks! Now the die doesn't roll when I select an objective that has moved. That works, though I would prefer if these objectives were simply unselectable and the game had some kind of visual indication of which objectives you can select. Kind of like desktop GUIs, which grey out buttons you can't click rather than letting you click them but making them do nothing. I think that would make the game UI a bit "smoother" and more pleasant to use.

EDIT: This would combine very well with my suggestion from the previous comment: make the cards glow in the card selection stage, make the selectable objectives glow in the objective selection stage, and make the die glow when it should be rolled. That would let you get rid of two microfrustrations at once: the hints that cover the UI and the die that can be clicked but doesn't roll. If you also replaced the modal tutorial popup at the start with a top or side button, that would drop the UI microfrustrations to zero.

Also, I've just noticed that the cards are a bit blurry when zoomed in on hover.

I hope the feedback was helpful!

> I was able to select an objective that had moved as a result of a card at the start of the day, could infinitely roll the dice with nothing happening.

Same bug here, in Firefox 128.

Also, while we're making suggestions, would it be possible to replace the tutorial balloon boxes with something that's less in the way? I like built-in hints and don't want to turn them off, but sometimes they can be a bit annoying when they cover up parts of the game UI. I would prefer some kind of animated glow behind the parts of the game I'm supposed to click on (cards, bars, or the die) plus a statically positioned explanation box to the side or on the bottom. That would make the hints unobtrusive enough that there would be no need to provide an option to turn them off.

1.8 MB standalone executable! That's cool to see in an era of huge apps.

Interesting choice of window manager. Has anyone here used PaperWM and can comment on how its "scrollable" interface compares to more traditional tiling WMs like i3?

Sure, it's different from the old way, but I don't think "unintuitive" is the right word for that. systemd forced people to change their habits so that it could be more intuitive. Of course, people are going to disagree about whether it was worth it - it's the age-old question about breaking backwards compatibility for the sake of minor improvement. Personally, I got used to it pretty quickly and I like it more than the old commands now.

> I have to look up the very fiddly and unintuitive systemd commands all the time. service start? service.foo start? start foo.service? Oh right, sudo systemctl start service.foo

I don't get this complaint. It's the same order as almost every other command-line utility that has subcommands: <command> <subcommand> <thing to operate on>. To me, that kind of consistency is very intuitive.

    systemctl stop my-service
    systemctl status my-service
    git add my-file
    git remote remove upstream
    apt install my-package
    docker run my-container
    adb push local-file remote-file