HN user
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-fileTCL
I actually know the answer to that one!
The principal lesson of Emacs is that a language for extensions should not be a mere "extension language". It should be a real programming language, designed for writing and maintaining substantial programs. Because people will want to do that!
Another lesson from Emacs is that the way to make sure an extension facility is really flexible is to use it to write a large portion of the ordinary released system. If you try to do that with Tcl, you will encounter its limitations.
Tcl was not designed to be a serious programming language. It was designed to be a "scripting language", on the assumption that a "scripting language" need not try to be a real programming language. So Tcl doesn't have the capabilities of one. It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow.
From Why you should not use Tcl by Richard Stallman [1].
Hm, I did some searching. Bazel's FAQ mentions multi-language support prominently, but only suggests speed and reliability as the initial motivations. I'll edit my post.
It's not? I recall reading that coping with a variety of languages was one of the main motivations, but do correct me if I'm wrong and you have a citation.
Your veiled implication that Nix and NixOS aren't about "getting things done" is, I think, more than a little unfair. I'm using multiple programming languages at work. Each one of them has its own dependency manager that does basically the same job as the other ones. In Python it's Poetry, in Ruby it's Bundler, in JavaScript it's npm/yarn, in PHP it's Composer, etc. A lot of projects require extra setup steps outside of the dependency manager. It's not a good experience that lets you get up and running quickly. And my situation with scripting languages isn't the worst case: God help you if you have dependencies between projects in AOT compiled languages that use different dependency managers.
Of course, the standard answer is to spin up a ton of Docker containers. Docker works, but it looks to me like a local optimum rather than a truly painless solution. It sucks as a build system, and Dockerfiles not being reproducible is the default outcome that needs significant extra care to avoid (how many times have you seen apt update or some equivalent in one)? Besides, why should I have to worry about a whole another OS inside my main OS, with potentially different tooling and conventions, when what I really want is just specific versions of a couple of tools?
I think we've gotten used to development environments being a shitty experience to the point where it seems part and parcel of programming, but when you take step back, it's apparent that the situation causes a lot of frustration and wastes a lot of time. To me, Nix's combination of package manager and reproducible build system looks like one of the most credible ways out. NixOS' declarative configuration and rollbacks are nice side benefits too, for server admins and newbies respectively. Nix just needs a lot more polish. I'm not about to introduce a tool where the most common workflow is still considered experimental. For now, I'll keep using Docker, but I watch Nix with interest and can't wait until its UX matures.
EDIT: Removed claim that Bazel and Buck's creation was motivated by multi-language support. Looks like the main motivations were speed and reproducibility.
They are being investigated, the Polish government is just slow.
In this case, probably? I'm not a fan of excessive regulation, for this particular problem, I don't see how it could be solved without some kind of "right to repair" law, or at least a "right to be thoroughly informed about repairability before buying" law. Even if copyright was scaled back to 20 years and explicit registration, that still would be long enough to screw customers. In fact, even if copyright didn't exist, the problem would still exist for devices that are hard to reverse-engineer.
Everyone must now pay the mental cost of multithreading for the chance that you might want to optimize something.
I'm assuming that by "everyone" you mean everyone who works on the Python implementation's C code? Because I don't see how that makes sense if you mean Python programmers in general. As far as I know, things will stay the same if your program is single-threaded or uses multiprocessing/asyncio. The changes only affect programs that start threads, in which case you need to take care of synchronization anyway.
It definitely does, but don't you think that it could be worth it if it makes multithreading usable for CPU-heavy tasks?
Sounds like PRQL [1].