gingerBill

The project is not even 24 hours old...

And I might plan on making this a recorded series of explaining how to make compilers from scratch with this language as a reference.

When I write the backend (this repo isn't even 24 hours old yet), you'll find out why variable declarations are at the top of a procedure. (Hint: it has something to do with the stack).

Oberon is a general-purpose programming language, not a DSL. Even though it is very minimal, you can still do quite a bit in it.

But the point of teaching compiler development is to teach people how to do the basic things from tokenizing, parsing, semantic checking, and code generation (directly to machine code).

I have found this is actually a skill most programmers don't even know how to do, especially just tokenizing and parsing, so I thought I'd use Oberon-07 as a base/inspiration for it.

n.b. at the time of this comment, the repo/project is not even 24 hours old yet.

This repo isn't even 24 hours old yet and it's on HackerNews...

Just wow....

The bugs have nothing to do with the language and exist in C too.

I'll just link to some of the bugs directly that posted as issues to SDL:

https://github.com/libsdl-org/SDL/issues/4789 (not fixed) https://github.com/libsdl-org/SDL/issues/4816 (closed) https://github.com/libsdl-org/SDL/issues/4790 (closed)

And these being the bugs we found ourselves, not other bugs that have already been found, and many marked "as not planned" since SDL2 is now finished.

Again, I am not against third party packages, and manual management of dependencies just slows down your progression to hell. There is no "solution" to this problem, only trade-offs.

I know people are lazy and will automate hell. That's the entire point of the article: not everything that can be automated ought to be automated.

And the argument about multiple package managers to juggle is only the case IFF there are multiple competing ones, which with Odin, I honestly doubt it would happen if we enforced what a package is in the language. I just don't want to officially endorse one ever because I do view them to be evil.

And I don't care many languages started without them, I am not going to give in.

Huh? I am not saying the repositories have (or should have) no responsibility, but you are also responsible for your own actions.

The popularity of such repositories and package managers are due to users of them.

And the concepts are trivially separable in my opinion. A package manager uses a repo of packages to download from. You don't need a package manager to use a repo. And a package manager could be just local to your machine and thus not need an external repo either. I know in practice the two are combined but that doesn't mean they are not distinct concepts.

I wouldn't class it as clickbait myself, but I will stand by the use of the word "evil". I am using evil in the very old fashioned sense: the privation of the good. Is the title provocative? Yes. But that's the point of the article in general. I am trying to argue that they are a net bad with virtually no good upsides to them for the programming world as a whole. They've automated something at scale which should not have been automated. And to be clear, there is no solution to the problems they are trying to solve, rather it's all about trade-offs.

I a little annoyed that HackerNews post renamed it to "A critique of package managers" because that implies very different connotations. I'd view an article written like that as if I have some criticisms that could be addressed, rather than the entire concept being bad from the start.

I've been looking through the repository list and that is not "batteries included", that's "everything, the kitchen sink, and the city".

Unless I am reading this (https://index.ros.org/?search_repos=true) wrong.

What do you consider your set of "Batteries Include"?

Choose your own hell then. I'm not going to stop you.

And no, it's not a tautology, it's an empirical observation.

And as I said, not everything ought to be automated, especially hell.

Completely coincidental. I wrote the article before the situation, AND the article is a transcription of a video recorded in July.

It is a build system in the technical sense but it's hard to explain to people because they expect it to be separate from the language entirely. If I said Odin had a build system, they'd be expecting an external build script. And when you say you don't need that, they usually get really confused.

So how do you explain such a system to someone? This is a genuine question I am not sure how to answer.

> My general view is that package managers (and not the things I made distinctions about) are probably in general a net-negative for the entire programming landscape, and should be avoided if possible.

I am arguing that their "benefits" are only very short-term, if there is actually benefit for them in the first place. The strawman that you present has been repeated already and is not considering that all of those other things are actually useful and good alternatives.

I already know all that, that's why we are being very conservative and slow when it comes to figuring out what is meant to be in 1.0.

Those are library/package collections which contain multiple different packages, not the packages themselves.

And we will take backwards compatibility seriously when we hit 1.0, and only "break" on major versions.

We've effectively written all of this already because of the amount of fixes we've had to do to the SDL2 code. So yes, we know what we are doing.

Use the first two, and not rely on the third at all. That's what the article is saying.

Thank you?

The title of the article comes from the direct words I said in the video, of which the article is effectively a polished transcription of.

Your "more balanced title" isn't even close to what I am saying. I am saying that Package Managers are just bad and should not be used. Not "remember to consider the costs". The net cost is bad for everyone, that's why I said "evil".

Odin is not trying to be a "C successor" rather as the website states: "Odin is the C alternative for the Joy of Programming".

And there doesn't have to be "one winner". This isn't Highlander. It is just wonderful that there is now choice in this domain beyond just the old and obvious.

I'd argue quite the opposite. You can build a lot more than you think, you just need to be encouraged.

You see you just completely missed my replies to that too.

> Let's put it this way, what does a package manager specifically (not the other distinctions I make in the article) do (other than enable bad laziness and lack of proper vetting) that is actually good?

https://old.reddit.com/r/programming/comments/1nbkwzt/packag...

I have? Pray tell.

I know very few people using Hare, especially since it only works on "FOSS platforms". And I will still maintain that V is vapourware. They still have the same false claims on the website that they've had from the beginning for ~6 years.

Odin is "successful enough" so far. Also, you know about it, so that says something.

It is an alternative, just clearly not one you like. And it's not an oversimplification of the problem.

Again, what is wrong with saying you should know the costs of the dependencies you include AND the alternative approaches of not using the dependencies?—e.g. using the standard library, writing it yourself, using another dependency already that might fit, etc.

Nix isn't a solution to the problem of package managers. It just a better way to package management system, which thus makes it easier to go to dependency hell. So I'd argue it puts fuel on the flames.

The solution is just to depend on less and manage them manually.

> Getting rid of npm and doing things manually won't make building SPAs have fewer dependencies, build would be incredibly slow and painful.

Honestly, I don't think this is true in the slightest. Rather, I hypothesize that people want to use such tooling and think the alternatives are slower, which I don't think is true.

If people actually did use fewer dependencies, people would have actually have websites that didn't take ages to load and were responsive.

So the existing ecosystems are just bad.

It makes it worse in my opinion, not better. Because it leads to the problem that other package managers don't agree on what a package is, and it might even lead to the need for an external build system to co-ordinate all of it too. It's a never-ending problem, and is now even worse.

That is my position... again, I am not sure how you got this conclusion from the article.

The "I am not advocating to write things from scratch" is more of a caveat to the people I know will comment NIH nonsense rather than anything productive.

But yes, my position is minimize dependencies and slow and carefully vet them too, and do not automate this process.