Having to mark a class `final` makes no sense. Things should be immutable by default. Imagine if we had to add `safe` all over the place instead of declaring them as `unsafe` something something

@RosaCtrl programming language designers often seem to underestimate the impact of defaults like this, e.g. also languages where omitting a visibility keyword means `public`

@entailment @RosaCtrl I actually think that one is ok, in the specific context of languages that are immutable by default. Take Scala, for example: fields are public but immutable by default, which I think is the right call. Any other combination is bad though - private and immutable means you have to write accessors by hand, public and mutable is just not healthy.

@NicolasRinaudo @RosaCtrl hmm, fields may be a separate case to consider. i was mostly thinking of top-level items like types and functions here, or e.g. in Haskell where visibility is controlled by module headers, and when an export list is omitted there, the default is to export everything

@charlotte @RosaCtrl @entailment the way I code, this is mostly ok. The data *is* the API, and changing the data means changing the API.

@NicolasRinaudo @charlotte @entailment I would like to see an example because I think this is how people often do it and it’s exactly what I’m contesting. The way I see it: sure, the data is the API, but often the implementation gets exposed unintentionally. Which is the actual point that Barbara Liskov made, and not what reached OO

@RosaCtrl @charlotte @entailment well mastodon is not necessary the best place for this, but take JSON for example. I much prefer a tight sum of products:
```
enum Json:
case Text(content: String)
case Num(content: Int)
case Null
case Obj(properties: Map[String, Json])
case Array(content: List[Json])
// ...
```

What then happens to it - encoding and decoding - is exposed as functions, and *those* hide the implementation details of turning an `Int` into a `Json.Num`, for example.

This allows me to cleanly separate data and behaviours, without coupling them in a way that's going to come back and bite me 9 times out of 10.

@NicolasRinaudo @charlotte @entailment oh, I would do the same in this case 🧐 and public here is fine as default, no strong opinions. But let’s say each of them have some properties, those I wish where private unless stated explicitly

@NicolasRinaudo @RosaCtrl @charlotte for me this depends on the type. some types are plain^1 data, other types are more like handles or objects (even in non-OOP languages). it's very context-depend which role a type should play.

^1: putting this in as an escape hatch for types which _are_ data, but more like _data structures_, where their representation should often be internal. e.g. if you're implementing a hashmap.

@entailment @RosaCtrl @charlotte that's perfectly fair.

In my work, I write more types like Json than types like HashMap, which is why I think public by default makes sense: it's the right decision the majority of the time *in my case*.

I can absolutely imagine people working on cases where the reverse is true.

@NicolasRinaudo @entailment @charlotte OK, what if resolve this by removing the default 😈

@RosaCtrl @entailment @charlotte then we're not even having a conversation, because you must be explicit about public or private every time and the problem doesn't exist?

@NicolasRinaudo @entailment @charlotte yes 🤩

I know it may be annoying, and this may be due to just different experiences by working with more or less disciplined people. I come from cleaning up big amounts of code, sometimes written by myself, sometimes written by someone else. I often think that if the programming language demanded things to be explicit, I wouldn’t be in those situations. Or said in a different way: I prefer languages optimised for reading several months after the code was written than for writing

@RosaCtrl @entailment @charlotte I only partly agree with that. The accumulation of keywords can be bad for reading, hiding the intent of the code in the noise of keywords that could have been omitted entirely.

I'd argue that knowing the semantics of the language you're using should be a requirement when maintaining code in that language - and so, knowing the difference between `public a: Int`, `private a: Int` and `a: Int`. Or, I don't know, `a = 1` and `mutable a = 1`. Or, see what I did there? elided the types because they can be infered? I think type inference is nice when used with moderation, and it's kind of the same argument as having defaults for common patterns.

@NicolasRinaudo @entailment @charlotte so type inference was made me shoot myself on the foot too! I wish it was there only for simple expressions, and anything complex required a signature

@RosaCtrl @entailment @charlotte I agree, it's too easy to abuse type inference and get hurt. But I don't think the answer is to ban type inference - I've made mistakes with if statements as well, and I don't think these should be removed from my languages of choice!

As everything, it's important to learn how to learn these features, and, importantly, when not to learn them. But removing any feature that might be abused will leave you with a very, very tiny language.

@NicolasRinaudo @entailment @charlotte the thing is that very very tiny languages are my thing now 🙂

@RosaCtrl @entailment @charlotte right. But if you remove every feature that can be abused, you're left with a language so tiny that it can do nothing. Even addition can be abused if you're not careful and haven't learned about overflow.

Now there's a simple beauty to a language that can do nothing at all, and a thing doesn't need to be useful to be beautiful, but sometimes I do actually want to automate stuff with my programs, and for that I need my language to, well.. do stuff.

@NicolasRinaudo @entailment @charlotte yeah, it’s a matter of balance and trade off. I still think that when it comes to be explicit or implicit readability is better and verbosity when reading is better than having to reconstruct assumptions

@RosaCtrl @entailment @charlotte and here we enter a discussion of taste, there's no right or wrong. I *prefer* it one way, which is probably not explicit for you, but that doesn't mean I'm arguing I'm *right*.

It's like point-free notation. I don't like it most of the time, some people will ban it altogether from their code-base, others will go to incredible lengths to write everything point-free... it's a matter of taste and conventions.

@NicolasRinaudo @entailment @charlotte oh yeah, I agree on that. Not saying I’m right here, just discussing because that’s what I do 😂