10

Code Complete states that you should aways code into a language as opposed to code in it. By that, they mean

Don't limit your programming thinking only to the concepts that are supported automatically by your language. The best programmers think of what they want to do, and then they assess how to accomplish their objectives with the programming tools at their disposal. (chapter 34.4)

Doesn't this lead to using one style of programming in every language out there, regardless of the particular strengths and weaknesses of the language at hand?

Or, to put the question in a more answerable format:

Would you propose that one should try to encode one's problem as neatly as possible with the particulars of one's language, or should you rather search the most elegant solution overall, even if that means that you need to implement possibly awkward constructs that do not exist natively in one's language?

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
bastibe
  • 1,359
  • 2
  • 12
  • 17
  • 5
    +1 good question. I can write in Perl in half a dozen different languages, at this point. – Dan Ray Feb 27 '12 at 13:18
  • @Dan Ray -- weird! I always write C in Perl. – James Anderson Aug 21 '13 at 03:47
  • See also: [Programming "in" a language vs programming "into" a language](http://msmvps.com/blogs/jon_skeet/archive/2008/04/23/programming-quot-in-quot-a-language-vs-programming-quot-into-quot-a-language.aspx) by Jon Skeet – Arseni Mourzenko Aug 21 '13 at 06:11

3 Answers3

7

There is an even better approach: forget about your pathetic fixed programming language at all. Encode your problem in a language you've just invented, derived from the very terms of the relevant problem domain, encode it as naturally as possible, and only then think of implementing this new programming language or dumbing your code down to the limitations of the existing language.

This approach is called Language-oriented programming. There are many techniques of implementing the domain-specific languages efficiently, and it is an especially hot topic for the Ruby community.

SK-logic
  • 8,497
  • 4
  • 25
  • 37
  • 1
    The Haskell community also embraces domain-specific languages, and the Haskell programming language is particularly suitable for implementing them. – tdammers Feb 27 '12 at 09:26
  • Is implementing a tailor made scripting system based on an embedded language like Lua or Tkl considered a writing a DSL? If so, how do you deal with the deficiencies of e.g. Lua? – bastibe Feb 27 '12 at 09:31
  • @Paperflyer, in some cases it makes sense implementing languages on top of something like Lua (especially if it is Metalua), but it is easier to write a proper compiler for the most of the typical DSLs. – SK-logic Feb 27 '12 at 12:53
  • @tdammers, yes, Haskell and Scala are all about DSLs. But I'm from the darker side of the Force: my preferred approach is metaprogramming. I believe that ad hoc interpreters are almost always inferior to the compilers. – SK-logic Feb 27 '12 at 12:54
  • @SK-logic: The Haskell approach is not really to write an interpreter, but rather to extend Haskell syntax to support the DSL natively. Usually, people invent data types and operators to form the DSL; implementing a full-blown parser and interpreter is seldom necessary (although the Haskell community has produced some excellent libraries to help do this). – tdammers Feb 27 '12 at 14:29
  • 2
    @tdammers, a DSL implemented on top of high order functions is, practically, an ad hoc interpreter. You can't extend Haskell syntax same way you'll extend, say, Lisp. Even with Template Haskell. It's a totally different (and, I'd say, a limited one) way of implementing DSLs. It's ok in many cases, but for anything really complex it leads to the totally unreadable implementations, whereas a multi-stage metaprogramming is just trivial, no matter how big and alien your DSL is. – SK-logic Feb 27 '12 at 14:36
  • I disagree with this answer. A DSL is not always the best way to go, especially because this means that every developer needs to learn this new DSL. Writing idiomatic code (with whichever feature of the language) is often a better idea. – Florian Margaine Aug 21 '13 at 06:15
  • @FlorianMargaine, learning a well-designed eDSL is *always* much easier then learning the problem domain itself. Getting through the code in an unfit language that represents that problem domain is *always* more complicated then reading a well-designed eDSL code. There are no exceptions. And, any given language is *always* unfit for all the specific tasks besides the single one it was made for. – SK-logic Aug 21 '13 at 07:00
  • @Florian: a DSL increases the on-boarding time for new programmers, but greatly increases productivity after it has been learned. – kevin cline Aug 21 '13 at 14:39
3

I believe the correct answer, and the one intended by the book is:

one should try to encode one's problem as neatly as possible with the particulars of one's language

By programming into a language, I always assumed it was to use techniques outside of the normal style of the language where it would lead to a benefit. This is a key difference to writing in one style in all languages.

For example, learning Haskell greatly improved my skill at using higher order functions. Now when programming in c#, I use the various IEnumerable methods such as Select more often, as using these methods leads to cleaner code than writing in for loops. I also tend to use pass and use functions (ie Func<int, int>) more often due to my haskell experience. My use of inheritance has dropped due to this, and most of the time the result is simpler code.

However, I don't use concepts like monads, or algebraic data types in c#. This is because neither are clearly representable in c#, and lead to little benefit in exchange for a lot of obscurity.

So I use the tools of the language to use the skills I have to the best effect. I believe that is programming into the language.

David Miani
  • 228
  • 1
  • 5
0

Would you propose that one should try to encode one's problem as neatly as possible with the particulars of one's language, or should you rather search the most elegant solution overall, even if that means that you need to implement possibly awkward constructs that do not exist natively in one's language?

The point is that good programmers don't have a language. The quote from the book talks about "programming tools at their disposal" - that means if you know perl and Java, then maybe you should use perl for that quick string manipulation. Programming languages aren't boxes to limit us, but tools we use to solve problems. This is (imo) what Code Complete is getting at. Don't code in a programming language/environment box, put the best solution into the best programming language/environment for you, your problem, and your solution.

Telastyn
  • 108,850
  • 29
  • 239
  • 365