Are these programming language features underrated or overrated?
Basic
62
9.8k
resolved Jul 1
Resolved
YES
Inheritance
Resolved
YES
Null pointer/reference
Resolved
NO
Goto
Resolved
NO
Predicate dispatch
Resolved
NO
Optionals
Resolved
NO
Pattern matching
Resolved
NO
Garbage collection
Resolved
NO
Macros
Resolved
NO
Borrow checking
Resolved
NO
Static types
Resolved
NO
Lambdas

Overrated = YES, Underrated = NO

Resolves based on the number of users (non-bot) that hold the position at market close. The higher number wins or else it resolves 50%.

I reserve the right to N/A answers that don't make sense.

Get Ṁ600 play money

🏅 Top traders

#NameTotal profit
1Ṁ274
2Ṁ193
3Ṁ144
4Ṁ115
5Ṁ85
Sort by:
bought Ṁ60 Inheritance NO

I believe inheritance is rather underrated, or more over-hated, because it is implemented very poorly in Java, C# (I think it suffers same issues as Java's?), JavaScript, Python, and probably C++ though I don't know C++ very well. A lot of the negative associations with Inheritance are not actually about inheritance itself but the baggage that accommodates it in how these languages do inheritance.

Inheritance is done well in Kotlin, and can be useful over composition when you have a large number of interfaces (traits) that are implemented in 1 encapsulated lifecycle, and you want to make another encapsulated lifecycle with a similar but largely the same implementation. Delegation is useful in these cases too, but can be less ergonomic in cases where the implementation you want to modify involves many members

Null pointer/reference

overrated and bad are not the same thing, when's the last time you heard someone say null pointers are awesome and more languages should have them

bought Ṁ50 Garbage collection NO

@jacksonpolack languages and communities with null safety have considered just not having nulls. I believe Kotlin could have went that direction. Nulls are useful! The problem is a lack of null safety.

With nullable and non-nullable types, nulls are like making optionals without wrapping, which can be more ergonomic

bought Ṁ10 Null pointer/reference NO

I've worked with languages with both null and Optional and I would prefer to have only null at that point because what's the point of having two checks for empty? I think it's not as as bad as people think especially when the language has support such as getting a field without null pointer exception by getting only when the value exists or else null..

Probably people developing new programming languages in 2007 who decided to use unsafe nil.

Goto
bought Ṁ50 Goto NO

Who's overrating goto statements? I've never heard of someone suggesting them, except for very low level FSM programming.

@singer yeah, goto seems like an obvious "underrated". It has to be either under or over, and it's hard to claim "over" for something that automatically triggers a "let's discuss" in most code reviews.

@singer All I know is you aren’t supposed to use them, but they are super convienient.

@ConnorDolan I can't remember ever using one before, maybe because I've been indoctrinated against them. Do you remember any illustrative examples of where you've used them successfully?

@singer a typical use for goto is in C. In modern languages, you can throw an exception, then catch it in the same function so as to do some logging or cleanup. C doesn't have built-in exceptions, but goto can fill a similar role. You goto a logging / error handling section of your function, then return an error value.

Even in C++, there is a runtime cost to using exceptions, so code written for high-performance may eschew using them.

Gotos which only jump a small distance in your code base and which don't break encapsulation aren't really a problem. It's when you use goto as your main flow control that your program gets difficult to maintain.

@singer My very first program I ever wrote was a connect four game in C, and I didn’t know how to make functions yet so I just used it in place of those to execute different blocks of code when needed.

I happen to quite like spaghetti, though perhaps programmers have different aesthetic preferences.