Can a language be abused?

K. Scott Allen has a great post showing an “abuse” of the lambda syntax in C#.

But I’m wondering, can any use of programming language really be called abuse? The language designers and creators put the ability to create the hack described above into the language. If they didn’t want you to do things like that, why put the ability in there at all? Using undocumented calls within the language to do strange things is one thing, but simply using calls within the language itself?

What are some of the best “abuses” you’ve seen of a language?

  • Pingback: Tweets that mention Can a language be abused? | Lazycoder --

  • A game has rules, hopefully pretty well specified rules. Taking full advantages of those rules to win can make one seem like a dick when playing in social settings, but is crucial to “winning the game.”

    Take Scrabble. Playing a new word alongside an existing one to create multiple 2 letter words is a good way to rack up the points. Placing new words in a way that makes it much harder for another player to take advantage of a triple-word-score bonus is a great defensive move.

    These sorts of moves, again, are seen as “dick moves” in social play, but are old hat to advanced players.

    Writing software is not a game. Typically it is social, in the sense that you and others will need to at least be able to read and understand the code later, and mostly likely fix and maintain it.

    In software, dick moves really are dick moves. Taking clever advantage of all a language has to offer is, indeed, clever, but easily veers in to the realm of being anti-social.

  • Pingback: » [blogged]: Can a language be a… Twitteresque()

  • Pingback: uberVU - social comments()

  • Been to in a while? 🙂

    I’d say it is pretty easy to abuse a language feature, especially anything that degrades readability (ternary, coalescing operators)…

    But that is, if it is abused… you can use these features without abuse.

  • Pingback: » Can a language be abused? - ht… Twitteresque()

  • I think it depends on the expected maintenance lifetime of the project. Is this something that’s going to be maintained by the same team for a short while? Then sure, load it up with as many project-specific hacks as you can. Is it something that’s going to be maintained by an evolving team over several years? Then you should find someone who doesn’t know about the “cleverness” to evaluate how hard it is to grok. If it adds time to how long a new developer can start writing code, it’s wrong.

  • Pingback: abused -