> It's feature usage - or rather misusing it - that leads to "bad code".
I still don’t agree with this. There are features that invite misusing them, or pose a greater risk of being misused. For example, with operator overloading developers often leave out some cases, causing possible dangerous behaviour afterwards. Or goto, which has a very big risk of being misused (compare the possible useful cases against the many, many cases where it’s not).
> Also, thanks for assuming so much about my mentality from a simple comment
Indeed, that’s what happens when such a comment is first impression.
> is that there is no such thing as "bad feature" or "feature that results in bad design". No, even straight "goto" is not such a feature.
Yet, there are features that lead (with a high probability) to bad program code (see goto)
Of course it’s always basically the same once a language is turing-complete, so we have to rate languages by how they do certain things.
There is the widely-known term of “code smell” or even “antipattern“, I’m pretty certain such a thing exists for language design, too.
I did list those features I found lead to “design smell”.
By the way, comparing penises by writing out numbers w/o any reference is silly at most.
Here are my thoughts after quickly glancing over the „features“:
1. No formatting rules and verbose „end“
I thought that by now it was universally accepted that having clear rules is a good idea, see Python and golang)
2. OO with inheritance
3. multiple at that
4. Dynamic classes/objects
5. Methods inside the classes
All of these make reasoning about effects very hard/impossible; Interfaces in golang, Multimethods in Clojure, Typeclasses in Haskell, CLOS in CL all provide a better solution to that.
6. Imperative
7. No functional elements (no functions, only methods)
Both mean inherently stateful, which in turn complicates reasoning
8. redef & super
It’s dangerous to have behaviour of single methods spread all over your codebase.
9. nullable
Looks like an interesting idea to eliminate the class of NPE runtime errors, yet it’s a special language (and syntax!) construct. It therefore does not arise out of the type system, but is explicitely built into the type system, so it doesn’t scale. See Haskell’s Maybe type on how to eleminate NPE’s with a small, trivial type that is no more special than any other.
Take it or leave it, these are the things I learned in my study of programming languages. I might be wrong, I might be right, but these are the things that came up as bad design most often in different languages. /me out
That was quite amazing.
I’m thrilled to check out Light Table now. But I’m at a loss, since I just got Clojure running in Emacs pretty well, complete with Vim keybindings.
Yet, I can’t get the Cljs connection working in an acceptable manner, so if LT makes that trivial I might just switch instantly. Hrmpf, why can’t there be an easy solution …
Maybe you are confusing state mutations with fixed points, which are used extensively (thankfully).