i mean, then we get into defining multi-paradigm :P
does it have objects that could, theoretically, be used in a java-like object oriented system? yes!
does anybody do that? not really!
it's far more functional than any other paradigm, and that's what counts.
Couldn't the zero value be nil? I get that some types like int are not nil-able, but the language allows you to assign both nil and int to a value of type any (interface{}), so I wonder why it couldn't work the same for sum types. i.e. they would be a subset of the `any` type.
Said "requirement" is only a human construct. The computer doesn't care.
If the humans choose to make an exception for that, it can be done. Granted, the planning that has taken place thus far has rejected such an exception, but there is nothing about Go that fundamentally prevents carving out an exception.
Why do dependent types require universe levels to be consistent? I mostly see that in the context of the type of all types and similar, which doesn't seem especially necessary to express. A variable that denotes a type could have type 'any' or 'unspecified', as opposed to a type T^1 or similar.
You would have to not use a type-based proof system. I think those are not going to be the "as simple as possible" ones. Consider metamath for example.
If you're thinking of C/C++ switch statements and everyone that blindly copied them (looking at you Java, JS and PHP), you're right, but Go's switch is much more flexible (https://gobyexample.com/switch).
PHP tried to correct the mistake of not giving some more thought to the switch statement at the beginning by including a new "match" expression in PHP 8 - fun times for everyone who used classes called "Match"...
A switch or case statement is a restricted form of pattern matching for simple values. It fits those use cases, which are frequent.
I use a language that has both pattern matching and case constructs. I use both.
If you're doing complex pattern matching all over the place (especially matching the same sets of cases repeatedly in multiple locations in the code), maybe your design sucks. It's not making effective use of OOP or some other applicable organizational principle.
What's your workflow for adding a new feature to something? In OCaml, with it's "high-tech language features like algebraic data types and ultra-strict typing", my entire workflow is:
- Modify the types to add the new thing.
- Fill in all the pattern matching cases that the compiler tells me I need to fill in.
- Maybe write a little bit extra logic.
And then i'm done, with a solution I know is type safe, will never crash unless i've explicitly let it, etc.
How does this help with moving data? Well, wouldn't it be handy if the compiler could stop your program from crashing when something goes wrong, or you could have the compiler track where you've safely and unsafely done operations, or a million other things.
Maybe this is too strong a statement, but if you can't see the advantage of that, I don't want to work with code you've written, because you're not doing everything you can to make it as safe as possible.
Yeah, in any modern language with pattern matching stuff like this is absolutely the compiler's job, and can be done pretty well[1] - of course, there are plenty of legacy languages that don't have pattern matching, but seeing as it can be compiled straight to switches and whatnot, even the lowest level languages don't have /that/ much of an excuse.
"Bragging" seems unnecessarily pejorative. Reading the information about his patents didn't sway me one way or the other the first time I visited his site, but I can see it being relevant data for some of his audience. The (superior) content of his books did sway me, as did Mark's willingness to make many of them available for free. I've since had occasion to interact personally with Mark, and I've unfailingly found him to be gracious and personable; "braggart" does not apply, in my experience.
It's just a basic resume credentials, the same as job experience.
There is another HN thread talking having personal projects online.
Whatever increases your changes to put the leg in the door, do it.
The point of this website isn't to mock software that has bugs - it's to show pitfalls that have been fallen into before, and could be fallen into again. If popular languages have encountered them in the past, and fixed them, why not document it? Helps people in the future. Sure, actual examples of pure unsoundness are more interesting, but creating unsoundness in what should be a sound system is also useful to implementers of these sorts of systems.
