Worst ideas/features in programming languages?
sarn
sarn at theartofmachinery.com
Tue Oct 12 23:13:52 UTC 2021
On Monday, 11 October 2021 at 15:59:10 UTC, Atila Neves wrote:
> I'm brainstorming about what I'll talk about at DConf, and
> during a conversation with Walter I thought it might be cool to
> talk about:
>
> * Worst features implemented in a non-toy language
Go's implicit duck-typing of structs to interfaces. Things don't
accidentally match a non-trivial interface, and hardly anyone
wants to make an interface for a struct that some third party
manages (just wrapping the struct would more idiomatic for Go).
For the sake of saving a one-line inheritance specifier, this
magic makes it so much harder to figure out which structs are
intended to match an interface in a large codebase written by
multiple people.
Supporting error detection without helping with error handling.
Python is good because exceptions inherit from standard types
that can be handled consistently (e.g., KeyError). Most other
languages (including D) aren't much help here. Go misses the
point by acting like "if err != nil { return err }" is actually
handling errors.
I agree with others that C's type declaration syntax is a
non-feature. It's pointlessly "clever" and not even consistent.
I've blogged about this problem here:
https://theartofmachinery.com/2020/08/18/d_declarations_for_c_programmers.html
I'm sure you can think of more C++ problems than me, but let me
pick three that epitomise why I don't like C++ any more:
SFINAE. It's powerful, but makes template metaprogramming slow
at compile time, terrible to debug and hard to read. D shows
that explicit constraints are better all around.
Member function pointers. They're hard to use correctly and
"feel" low level, but are actually very high level. D's
delegates are easier to use and reason about, yet are lower level
(NB: closures are higher level, but that's a different story).
Sensible operator overloading for a simple number-like type takes
a lot of boring boilerplate, which encourages developers to do
"interesting" things with operator overloading instead. D makes
the sensible things easy, so there's less of a culture of
"interesting" metaprogramming hacks.
> * Worst features (in your opinion) in D
* The multiple (confusing) ways to write anonymous lambdas.
* opDispatch's (lack of) error handling semantics.
* Autodecoding.
* Overuse of attributes. (It fills the type system with things
that could be better done with separate notation for static
checking tooling.)
* Overloaded semantics of . that makes namespacing hard in
practice.
* The hacky non-virtual destructor implementation.
> * Features you'd like to see in D
Overall, I don't think D needs many more features. But because
you asked:
* Better value analysis to make integer promotion issues less
annoying.
* Better error handling for opDispatch.
* Native tuple support (with destructuring, etc.).
>
> Ideas? Examples?
>
> Thanks!
More information about the Digitalmars-d
mailing list