For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | MercurialBlue's commentsregister

I do agree with you, but honestly I don't even think that's the biggest problem with these arguments.

I'm just sitting here wondering why it is even relevant whether the "AI" is "copying", "learning", "thinking", or whatever, why is any of that important? Does AI have human rights? Well, perhaps in a couple hundred years, if humanity manages not to self-extinguish by then.

It's not like you can sue AI if you think it plagiarized your work, no. Obviously not, so why the hell are we discussing that? "AI" is just a piece of software, a tool, it doesn't matter what it's doing, what matters is what the user is doing, the fact of the matter is that these multi-billionaire corporations are taking everyone's honest work, putting it into a computer, and selling the output. They didn't do any "learning", they just used your data and made money out of it, it isn't a stretch to say they simply sold your work.

EDIT: Perhaps one day the day AI will have human rights, make its own money, and pay bills. That will be the day any of this nonsensical discussion will be anything but useless.


> these multi-billionaire corporations are taking everyone's honest work, putting it into a computer, and selling the output

And then there's the tens of thousands of people training models and making them freely available to everyone. What I fear most is that regulations introduced "to stop" the multi-billionaire corporations will in fact make sure they're the only ones with the resources to comply with the regulations.


I'm not arguing for nor against regulations, I'm simply commenting on the whole "well, it's technically not stealing, therefore it is OK" debacle, all that means is that legally speaking, it's OK, that doesn't make it ethical.


May I ask what exactly do you dislikes about Nim's garbage collection? You said you "quickly" scanned Nim's page, so I assume you just don't want a GC period? If you're dealing with hard-realtime constraints then I understand. But otherwise, as long as you aren't dealing with cyclic data structures, Nim's GC is just reference counting, which is very widespread in even C++ and Rust code, and if you really want to you can just not use the cycle collector and break the cycles yourself.

The way I see it, the GC is just nice to have for productivity, and for those cases where you really need to optimize your program, there is nothing stopping you from managing your memory yourself, you can write your own types with their own constructors/destructors (Nim has "scope-based" memory management akin to RAII in C++), of course, you must be aware that using pointers will lead to potentially unsafe code, Nim can't hold your hand there.


>Identifier equality

This is a very surface-level complaint, and it is no surprise that almost everyone who complains about this hasn't actually used the language. I will admit it is indeed a peculiar feature, I wouldn't be able to name another language that did this before, but as it turns out, it has yet to be a problem in practice.

Do you fear some crazy person might mix identifier styles? They could do that in any language, Nim has nothing to do with that. The pro of this feature is that you can write your library in whichever style you prefer, and people can use your library and still use their preferred style, I always hated how in python you often end up having to use libraries written in camelCase for your snake_case project (or vice versa).

Once again, it is a rather peculiar feature, like who asked for this? I don't know, but then again, why not? it did make me raise an eyebrow at first, but in practice, Nim gets it just right. The one valid scenario where it could get in the way is when searching your source files for an identifier, but even then Nim has solutions for that (there's nimgrep, and mainstream editors/IDEs are already nim-aware anyways).


From Araq on Nim Forums:

> I decided to make Nim "space only" after having read an interview with Guido van Rossum who said that it is what he would do for Python if he were to decide it again. Also, and more importantly, back then I had never seen "tabs for indentation, spaces for alignment" applied correctly once. In fact, "compress 8 spaces into a tab" was quite common. (This is not the same as "tabs for indentation"!)

In other words, it seems Nim simply attempts to learn from Python's mistakes (even PEP8 discourages the use of tabs for new projects), mixing tabs with spaces brings several potential technical issues for a whitespace-sensitive language, so why not just sidestep that problem entirely?


Guido van Rossum also seems to prefer tabs but was held back by the community [1]. But even if he changed his mind since then those reasons are incredibly weak if you ask me, they basically boil down to "some software 50 years ago was pure shit" and that's not a valid reason. Tabs are simply the superior/right tool for indentation. You might want to see a tab 8 chars wide and I want 4 but we both see the loop body indented one level. With spaces enforced one of us would not see the code as they'd like it to be and while that might seem like pure preference on surface the simple truth is that preferences matter (see the recent thread about the ideal font for reading speed - it's different for everyone) and tabs provide the freedom while spaces don't. And in some cases they matter even more, for example I've worked with someone who was visually impaired and pretty much needed a tab size of 0 to be able to work, he wouldn't be able to do that with spaces.

The only argument that ever comes from spaces people is "alignment" and while I personally think that most if not all of the things people try to align don't get any benefit from that alignment whatsoever nobody advoces for tabs only, you can still always use spaces if you really really really need to align something. Some people messing that up is really not a reason to straightup ban the superior way, you could just train those people better. If you want to align stuff, go ahead. The thing that matters is that if I don't care about your alignment while you do and we both have different tab width preferences then with tabs we both get what we want while with spaces only you would.

Also while this was mostly about tabs vs spaces, those are not the only aspects of a style and the main point was that an enforced style will always upset some people. People simply work differently and intentionally preventing them from using whatever they like is pretty close to malicious if you ask me and in the best case still disrespectful. Some people work better in light mode, some prefer a complete rainbow IDE, some prefer to use raw vi, etc. Or for a better analogy, maybe someone codes much better while listening to loud death metal or whatever. Obviously in an office that would annoy other people but the solution is not to ban developers from listening to music completely but rather to make them use headphones in such cases so that other people are not affected. For code style I might work better with a certain one and you with a different style and that's okay, we just come up with some compromise style that the code is converted to before committing. Languages that enforce a certain style simply don't have this freedom.

Now in whitespace sensitive languages like Python if (and only if) you want to align stuff then yeah things can go boom. But it also is not an unsolvable problem, if the code is all spaces then it just works, if the code is all tabs with no "alignment" then it just works, and if you use tabs with some spaces because you want aligned stuff that can pretty much be checked by the parser. Error if a space is found before a tab, error if a line has more than one tab more than the previous one, etc. I don't think sidestepping this problem is worth alienating people.

[1] https://legacy.python.org/search/hypermail/python-1994q2/020...


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You