HN user

Profpatsch

45 karma
Posts8
Comments20
View on HN
NixOS Linux 11 years ago

I have been writing a guide on how to set up a desktop system with NixOS, but I’m not quite finished yet.

I wonder how high the interest in something like that would be? I can throw up an unfinished beta version of it if people are interested.

Exactly. It’s what I commented about super after 8.

You spread your (probably stateful, imperative) logic over several files and classes.

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

Introducing Swift 12 years ago

Hijacking another programming language name for your own cheap JS-syntax clone? Nice move, jerks!

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 …