Hacker News new | ask | show | jobs
by sirclueless 5169 days ago
I can honestly say that the ability to write your own control structures is one of the quickest ways to make me hate developing in a particular language. Any time you use them, your code becomes significantly less readable, and significantly less portable.

It all just becomes a giant clusterfuck way too quickly. Small set of well-defined semantics, please.

1 comments

Any time you use them, your code becomes significantly less readable, and significantly less portable.

Specific examples?

I've actually often found the opposite to be true, given a good (meta) syntax for handling this.

I've often seen patterns in Smalltalk like:

    myTransaction 
        commit: [
            "Stuff happens here"
        ]
        onRollback: [   
            "handles rollback"
        ].
Semaphores are used for critical sections like so:

    (mySemaphore)
        critical: [
            "critical section code goes here"
        ].
I think these examples show how such a thing can increase readability.

As far as the portability thing goes, I've never heard of that being a terrible problem in Smalltalk. If code from one environment has some custom method like "isNilOrFalse:" or something like "ifNotNilDo:" then it's a simple matter to port that code over another environment, or have it syntactically rewritten by the browser to make a portable library. The sorts of patterns I list above are generally for DSLs that are only used internally in a given library or for code that uses the particular library, so portability isn't a problem. The structures are carried where needed by the library.

It all just becomes a giant clusterfuck way too quickly. Small set of well-defined semantics, please.

Smalltalk does have a small set of well-defined semantics, just not at the level you're used to. I have never heard of modifications that break the control flow standard library. My experience is that good programmers don't change how the "standard" behaviors work, because those changes tend to break the rest of the code base.