I now program in C# for a living but before that I programmed in python for 5 years. I have found that I write C# very differently than most examples I see on the web. Rather then writing things like:

foreach (string bar in foo)
    //bar has something doen to it here

I write code that looks like this.

foo.ForEach( c => c.someActionhere() )


var result = foo.Select( c =>
                    //Some code here to transform the item.

I think my using code like above came from my love of map and reduce in python - while not exactly the same thing, the concepts are close.

Now it's time for my question. What concepts do you take and move with you from language to language; that allow you to solve a problem in a way that is not the normal accepted solution in that language?

  • 4
    I'm not completely sure what you're asking here. Do you want a list of cross-language concepts, or are you interested in the permissability of using another languages' style in another? – Michael K Mar 3 '11 at 15:57
  • 3
    Actually, many Python programmers aren't too fond of map and reduce. But only because you can do the same thing, and a few more, and even several of them at once, with list comprehensions and generator expressions. – user7043 Mar 3 '11 at 16:01
  • Ya list comprehensions came after the version of python we used. I actually love them as well but spent a lot of time with map and such. – Erin Mar 3 '11 at 16:07
  • @Michael: permissability of using another language's style or more to the point which things do you use. – Erin Mar 3 '11 at 16:17
  • "The normal accepted solution" is a rather loaded expression to my mind. I could consider how many ways could I get a "Hello World!" web page written in code that would run under IIS using some form of ASP.Net that could include literals, script blocks, or just raw HTML for a few ways where each has its own advantages and disadvantages. – JB King Mar 3 '11 at 16:55

I'm not claiming these are unusual or "not the normal accepted solution", but here are a few concept migrations in my career:

  • Learned C first
  • After learning Java, I started structuring my C code with functions like [structname]_new and [structname]_destroy. A few OO ideas crept into my imperative code.
  • After learning ML, I used more static methods in my Java code and thought about problems as chained actions versus chained objects.
  • After dabbling with Prolog, I started worrying about state and side effects. I figured if Prolog could avoid being explicit about state, I could too.
  • I went through a short phase where I pushed too much logic into the database after becoming handy with t-sql and pl/sql. Luckily, this was short lived (though I still enjoy a good complicated stored proc).
  • My time with Ruby absolutely ruined my C# code as I tried to figure out "meta" solutions for everything. I've recovered for the most part. Note: C# reflection is not a substitute for a good dynamic language.
  • Writing VBA in MS Excel... Well, I know it influences something...
  • My occasional trip back to C makes me fret about code in other languages. For a day, I worry that I can't see EXACTLY what's going on under the hood.
  • I had the same thing happen with state/side effects. My Java code lately has been tending toward functional. – Michael K Mar 4 '11 at 16:23

I think that writing idiomatic code is generally the best thing to do. It makes it easier for other people that are used to working in that language to follow what you are doing.

That being said, though, there is absolutely nothing wrong with using other styles. If it seems like it fits for the task you are doing, go for it! One reason to learn other languages is to learn other ways of accomplishing similiar tasks.

In your case, the functional way of looping is perfectly fine. Nothing wrong with being declarative; for a single action, it (to me, anyway) is perfectly clear and is short. For more complicated actions, I would still use foreach.

  • 1
    Here is the interesting thing. Since we started using the declarative syntax here we have had less problems in our processing systems. – Erin Mar 3 '11 at 20:17
  • @Erin Any idea why? I suppose it could be the somewhat more concise syntax, but that really doesn't make sense... – Michael K Mar 3 '11 at 20:22
  • One of the differences is we now look at a lot of problems as data transformations. – Erin Mar 3 '11 at 20:33
  • @Erin, which one is the declarative syntax? – user1249 Mar 4 '11 at 7:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.