@newt

Never trust non-GPL code... 🤣

You are technically right, but i think they SHOULD be rings (and named accordingly). So that programmers would learn from the beginning to live with the clear semantics of rings, always aware of the risk of overflow.

@Shamar I'm not technically right. I'm just right. And no, both signed and unsigned integer overflow should throw an exception. Rust does this right since one of the recent versions.

If you want rings, make them as separate types with different semantics.

Also also, if you deliberately write code assuming signed overflow is well defined, I'll personally find you and kick you in the nuts

@newt

Uhm... no. You are not "right".

You are technically right because you narrowed the discourse on standard C. Then, speaking of one specific language (standard C), you are right that int64_t is not a ring.
(And I do the worst possible things with computers... things you can't even imagine... so start looking if you dare to know... 😉).

But I'd argue that the Rust choice is... arguable.

I mean, it's a choice, legitimate for its authors. BUT calling the same time Ring64 AND giving it ring semantics would be an equivalent design choice.

The point: is it better as a bade type in a language, a limited integer that throw an exception in some conditions, or a ring that consistently works as a ring and let people build on top of its clear and predictable semantics?

I'd say the second.

It's a simpler solution, faster to learn and predictable.

(It's worth noticing that I'm wondering about an hypothetical language that is as simple and consistent as possible)

@Shamar you know that you can have both, right? This is not a choice. If you want your rings, go have your rings. Just don't call them ints.

@newt

Uhm.. I'm arguing that calling a bounded type as "int" is a design error.

Take Wirth's Oberon: it uses INTEGER. At compile time you can specify the actual size.

Yet, it's NOT really an integer because it's bounded.

So if it's not a integer why calling it so?

@Shamar it is an integer. Ask any programmer. It's not an integer in the strict mathematical sense, but then again, nobody is arguing that it is.

Monads in Haskell aren't Monads in the categorical meaning of this word, but so far the only people who are pissed off by this are a bunch of nitpicking nerds.

@newt

I'm a programmer. 😉

It's not an integer.
It's NOT a theoretical argument, indeed overflows happen.

There are three possible solutions to this: force people to rationalize that "it's not an integer, but... who cares?", making it an actual integer (whatever it costs computationally... but you know.. halting problem) or to name such in another way.

The first increase cognitive load for no reason: it's accidental complexity or, if you prefer, a global technical debt.

Another example: division should not be defined on types that include zero. You shouldn't be able to construct a type for which division is defined, with a zero.

Now in a world with JavaScript and C++, we know programmers can rationalize basically anything.

But still... I think it's worth to imagine better worlds.

@Shamar the problem is, in the vast majority of cases integer overflow is an undesired behaviour. I only can name a handful of cases where integer overflow is ok.

@newt

Exactly.
So why should we adopt such self-deception by calling something that is not an integer "integer" instead of building something that actually work as an integer?

Early optimization?

Or maybe we think that programmers cannot properly handle rings (as they cannot handle overflow errors)?

I'd argue that such belief is a little "paternalist" and well... wrong.

So we know that people cannot properly handle such corner case... why not make their management mandatory from the start?

@newt

Too late... too many typo... sorry.
s/bade/base

@Shamar @newt > hypothetical language that is as simple and consistent as possible
That would be Rust in C syntax for me

@Shamar also also, GPL is cancer.

@newt @Shamar long live to BSD

@duponin @Shamar BSD is a dumpster fire at this point. LLVM is an awesome piece of software tho. I wish it was implemented in another language, because they basically have poor man's pattern matching for C++ there. It's just painful to look at.

@newt

Actually the problem with #GPL and #AGPL is that they are not strong enough to protect and reserve the knowledge that free software expresses to the commons.

Full access to software sources and full right to hack it, just like writings and any other human expression, is the most fundamental human right.

Preventing such right to any human is preventing them to be human, a specie that defines itself as *homo sapiens sapiens*.

@duponin

@Shamar @duponin you are free to come up with your very own more restrictive license and publish your intellectual property under its terms.

The problem with GPL is that it hugely benefits bigger players, who can earn money from consulting and support, while leaving smaller software companies at a huge disadvantage. The latter are a lot better from using BSD or MIT licenses for their published works and some form of EULA with closed source code for end products.

@newt @Shamar personally I release my open-source projects under BSD 3 clause
(And nobody cares about)

@duponin @Shamar I personally prefer WTFPL, but my employer prefers MIT for open source code.

@newt @Shamar I should consider it

@duponin @Shamar here's a short comic explaining the benefits of WTFPL

@newt @duponin @Shamar this comic has a special place in my heart

@Ted

It's somewhat funny, but very incorrect.
Even MIT and BSD impose obligations on people builing on licensed code, just fewer than a #copyleft.

Actually, such swallow depiction of free software licenses is quite similar to calling int64_t as "integer". 😅

As for an even stronger copyleft, I wrote the #HackingLicense: http://www.tesio.it/documents/HACK.txt

I must admit that I'm not yet happy with its formulation, but it can give an idea of what I hate in weaker copylefts like the #AGPLv3.
I'm going to remove the "organizations" thing. Making it shorter would be nice but apparently I can't without opening to corporate abuse one way or another.

In any case, if you want to give it a read and show me a way it could advantage big corps, I'll promise I'll study a fix for that.

@newt @duponin

@Shamar @Ted @duponin big vendors have an advantage of possessing sheer manpower. Chrom{e,ium} is wholly controlled by google even though it is open source. But good luck contributing things google doesn't want there! If Chrome was GPL, nothing would've changed in this case.

On the other hand, a smaller company is at a huge disadvantage when using GPL, because this way a bigger entity can just buy the product and take over. Again, utilizing sheer manpower. Having your source code closed or under a restrictive license is a huge benefit in this case.

@newt

BUT Google does not use or extend AGPL software. Why?

I'd argue that a strong copyleft is better than a permissive license against steer manpower.

And that against such big corporations not even keeping the software closed source provide an effective protection.

The Hacking License, instead, gives the original authors full (non exclusive) copyright and patent grants on any derived work.

@Ted @duponin

@Shamar @Ted @duponin because AGPL is only good for server-side software, developed either by an open source community or a small vendor. In the latter case, AGPL code is usually only a part of the whole product, with the rest being under a commercial license.

>The Hacking License, instead, gives the original authors full (non exclusive) copyright and patent grants on any derived work.

Thanks. I'll stay away from this cancer as much as possible.

@newt

Fine... but why?

I mean, is this a philosophical hate against common good and the commons or something you consider pragmatic, apolitical... such as profit in a capitalist world or something like that?

Even if we do not agree on this matter (mostly because we do not agree), I'd really like to learn your perspective.

@Ted @duponin

@Shamar @Ted @duponin there is no such thing as common good. Somebody somewhere has to do the job. If it's me, I might as well profit from it.

@newt

Mozart's music is common good.
So is Bethoven's or Vivaldi.

Shakespeare poems are common goods. And Montale's too.

Actually most of human knowledge is common good.

A huge amount of software is common good. I'd argue that most global cpu cycles at any given time this year are running free software that IS common good.

This does not means, in any way, that you shouldn't be paid for creating it if you want to.

So I deduce your is a fundamental mistrust in society, in the communities around you that could benefit from your work if it was available.

To be fair, you might be right on this. There is a huge risk we evolve back to egocentric apes unable to collaborate if not under the rule of few... owners.

As for me, I choose to still hope for the better from our specie.

Anyway... thank for sharing!

@Ted @duponin