Can a developer truly be Language Agnostic?

Question

Apologies this question could be interpreted as a question not to ask but an impending project has lead me to this.

• When you ( as in a developers / designer ) first encounter a task / project do you not find yourselves mini solving it as it unravels ( either read or spoken )?(1) If so are your thoughts in "a programming language?"

• If you're asked to re-factor a project entitled "web0.2b" which was originally written in occam 2.1 (2) ( to make it easier ) (3) which was absurdly fully documented and 100% working ( they just wanted 10 new features ) would you're first thoughts not instinctively be " I'll migrate this puppy to {your favorite > web0.2b language here}"?.

Now I know ( and have professionally coding experience in ) an array of languages ( C++, Objective-C, Java , Javascript, PHP, Perl 5, Pascal, modula-3, BBC Basic(4) to name a few ) but find myself drawn to one for 99% of tasks. My decisions tend to not be language agnostic. I want to solve it so I generally do what the romans do especially when in Rome.

So my question is can you being language agnostic ever derive at an implementable solution without thinking in a language?

(1) naturally none of use start coding at this stage do we..
(2) or any other pre 1993-4 / pre WEB2.0 / etc.. language
(3) for the sake of argument say a "cool dude"(tm) in Khvoy wrote a compiler back then called Cockatoo
(3) ok ok Pascal onwards I haven't but I've writting projects in.. does that count?

Answer 1

The only question you really only need to answer is: Is this the best solution you have for the problem at hand?

One of the most important lessons I've learned in software development is that, when faced with a problem, you always have to consider context, which includes answering questions such as:

• What is the core competency of your team (the team can be just you)?
• What tools do you have at hand?
• What tools do you need to acquire? How much will they cost you?
• How much will it cost you to master those new tools?
• Does the tool really really solve your problems?
• What problems that the new tools introduce? (It's almost inevitable)

That being said, if you want to stick with your preferred language because it's your core competency, and it requires a flat/zero learning curve, and it solves the problem at hand in a way that is not significantly different and with almost the same performance as whatever new and shiny tool they say you need, then by all means stick with your preferred tool.

Of course in this context, by "tool" I mean "programming language", as that is what it is. :)

Now, on legacy systems if the legacy system is large enough such that porting it to your preferred tool will only have diminishing returns -- of course the answer will be to stick to whatever language the legacy system is written in.

Answer 2

On the subject of porting:

• How Microsoft Lost the API War

waste a few months porting it to another programming environment, something which will not benefit a single customer and therefore will not gain us one additional sale

• Things You Should Never Do, Part I - Don't rewrite code. Porting to a different language is in the same category as rewriting.

Answer 3

The only ones who can be truly agnostic are those who work for themselves (ahem, Jeff). Where I work we're a .Net shop. If I was presented with a problem and said, "You know what, I could write a Perl script that would knock that out in a second." It really wouldn't matter. My boss's reaction would be - "well, let's use .Net so everyone else can support it" - (of course after he asked me what Perl was).

And you know what, in the end, he'd be right. All tool sets have their pros and cons but when you're in a room with 20 other developers who need to interact with your code, update your code, etc - the best solution is most often not a software agnostic decision,

Answer 4

I learned programming by being taught how to break a problem down into it's basic steps. First using flow charts and then PDL. I was taught this before ever being taught a programming language. During a 6 month period of time I learned FORTRAN, COBOL, Assembler (IBM & Honeywell, & Motorola), PL/I, C, and Basic. Because of that start, I still solve/design things at the PDL level and then implement it with whatever tools I need to use.

Even if I know I have to use .NET I still think of it in PDL. The writing of code then becomes the translation of the PDL and the original PDL can become the comments. Programming this way is also an iterative process because you make multiple passes expanding on the detail until you end up with a program.

Answer 5

I tend to think in programming language all the time when thinking about a programming problem, but I think this is more or less natural, just like I think in English when speaking English or thinking in German when speaking German (My teacher in school once said: To truly learn a language, you don't have to speak it - you have to be able to think in it automatically, so that you can get rid of a translation step between your thoughts and your words).

As for a Product: I would be really careful re-factoring it. Who knows how many workarounds and bugfixes are in there? That horrible loop that sounds like someone is stupid - maybe it's just there for that Bug with Turkish Windows running with a russian Keyboard which French regional settings to type an é? Also, usually it will take longer to re-implement in another language than just trying to add more features to the existing and - hopefully - stable core.

Also, it's something new to learn, and who would NOT love to have occam in his CV, right between COBOL and C#? :-D

Answer 6

"If the only tool you have is a hammer, every problem looks like a nail"

I think it is important for a well-rounded developer to have at least a high-level knowledge of several languages. I started out my dev career as a PHP programmer, and have since migrated to C#. Along the way I've looked at quite a few other languages/technologies simply because I want to know that I can see a problem from at least a coupe of points of view before deciding on what to use.

In practical terms, though, I am employed as a C# developer so that limits my choice somewhat when I look at a task at work. I have a feeling that there are lots of people in the same boat as me, but it does worry me that lots of apps are developed without a thought about what would be best.

Answer 7

It really does depend, but I'd say about half of the time I think without reference to any particular language. For example, I might think to myself: "ok, the features might really be distinctive; first I'll try a clustering to check on that, and if so maybe I can just use Naive Bayes". I think if a problem is close enough to a domain (like machine learning or GIS or statistics), then I will think outside of programming languages. It'll also happen for certain data structure problems, where I really do see things in terms of boxes and arrows, with no particular reference to code.

Answer 8

The solution depends on what language you're using and what language you use will depend on your solution so it's a hideous recursive loop. Maybe.

What I'm trying to say is that you can't come up with any detail in a solution without knowing what language you're going to be using (will I have pointers? will I have dynamic memory? will I have garbage collection? will I have a library to do task X?).

I can't think of a single project I've worked on where the decision over what language to use wasn't one of the easiest and simplest decisions. There always seems to be some very strong reasons to use one language over another, be it because person Y only knows language Z or that the customer wants it in language R.

The solution then falls out from what language you have and the idioms for going about solving problems in that language.

Answer 9

1. I tend to think in pages and databases (being a web developer), but also think in Imperative Language Pseudo code

2. I would definitely learn the language, considering it was only 10 features, unless after looking at the new "old" language I find the features will be very difficult to implement. I would however decide how big the features are, and also inquire if the project will need more features in the future, before tackling the project. Definitely situational.

I think the real answer is No We Don't Think purely Agnostically, in the same way you can never be pure of all judgement. You might think you don't bias toward a specific language, but you do. It's what you know. Sure you might know 100 languages, but it might be the 101st that would solve the problem best.

Also, productivity is a factor in the answer, I can finish solving a problem in a shorter amount of time than I can learn a new language and solve the problem in that language. Thus I think in the languages I have the most experience in most of the time.

Doing upfront design using models (UML, or Napkin drawings) is one way to go. It helps you think of the problem as concepts and solutions, instead of classes and implementation.

I use pseudo-code when I'm discussing a possible solution, however that's not really language agnostic since I usually use some form of loops and conditionals, thus biased toward imperative languages.

Answer 10

I would argue that most developers formulate algorithms using the language paradigm that they are most familiar with. Familiarity with multiple paradigms (functional, imperative, oop, logic) can radically change your thoughts on how a problem can be solved. The Sapir-Whorf hypothesis of linguistics discusses the more general phenomenon.

When a Lisp programmer and a C++ programmer start thinking about how they will solve a problem at a high level, I'm sure those thoughts are very different. Though probably not much difference between a C# and a C++ developer. So I think it's more along the lines of language paradigms.

Answer 11

Being given a project written in a "unknown" language is different from starting a project from scratch. I would be less inclined to start a project in a new language than modifying an existing project.

One benefit of computer languages is that, in the end, they all do the same thing -- push bits around computer memory.

A benefit about most software applications is that they all pretty much do "the same thing", only slightly different.

That means that if you are dropped in to a unknown code base, even in an unknown language, you can be somewhat confident that a) you are already familiar with pushing bits around in memory, and b) whatever change is required to the system, it's probably doing something very similar already.

Combine that with c) Google to find someone, somewhere, who has already done what you want to do, and soon the task become basic labor.

It does, however help a lot if you d) already know how to do what needs to be done in some other computer language.

Now, certainly familiarity with the language speeds up the process, then you just have to learn the application. Starting from scratch with a new build chain, etc. will definitely slow you down.

In this case, the slow response, that's what an experienced developer in the environment brings as value to the table.

Now, obviously if you're trying to add features to an assembly language program on a 10 bit processor that has been optimized for the past 10 years to run in 8K of RAM, there's going to be issues.

But most systems are really straightforward. Having example code (i.e. the running system) is an immense help and you can likely "cut and paste" your way to glory once you get familiar with walking around the system.

Stumbling blocks happen when you run in to things like "We want to put our Paradox application on web" and find that internet connectivity may well be something that the version of Paradox they're using didn't even conceive of.

Doesn't make it impossible, tho. (Perhaps a new program written in VB using JET to talk to the Paradox tables will suffice, for example.) Just may have to think out of the box a little.

I do not fear computers. Given a little bit time and some documentation, I'm confident I can figure most anything out. Whether I can do that efficiently enough for the customer to make it worth the effort, is a different task completely.

But source code is an amazing thing. Not everything, mind, they all have their hidden tricks and traps, but it sure tells a lot of the story.