Slashdot Mirror
Ask Slashdot: How Often Do You Switch Programming Languages?
An anonymous Slashdot reader writes:
I always see a lot of different opinions about programming languages, but how much choice do you really get to have over which language to use? If you want to develop for Android, then you're probably using Java...and if you're developing for iOS, then you've probably been using Swift or Objective-C. Even when looking for a job, all your most recent job experience is usually tied up in whatever language your current employer insisted on using. (Unless people are routinely getting hired to work on projects in an entirely different language than the one that they're using now...)
Maybe the question I really want to ask is how often do you really get to choose your programming languages... Does it happen when you're swayed by the available development environment or intrigued by the community's stellar reputation, or that buzz of excitement that keeps building up around one particular language? Or are programming languages just something that you eventually just fall into by default?
Leave your answers in the comments. How often do you switch programming languages?
Maybe the question I really want to ask is how often do you really get to choose your programming languages... Does it happen when you're swayed by the available development environment or intrigued by the community's stellar reputation, or that buzz of excitement that keeps building up around one particular language? Or are programming languages just something that you eventually just fall into by default?
Leave your answers in the comments. How often do you switch programming languages?
But then, I only fry firmware-burgers, so 'C' and assembler are it...unless you wanna count all the assembler flavors, then it would be 2 or 3 times a day...
(T)he (O)ld (M)an
Small embedded ARM processors: C
Mid-sized embedded Linux: C++
Bloaty multi-core GUI with printer drivers, etc. running on Windows: C#
Cloudy web servery type stuff: Javascript
And, all of these can be found in a single shipping product. Go Team Silo Go! Hope it sticks when you toss it over the wall!
Or at least it's the project that determines the language.
I use half a dozen different languages every day. You can double that if you look over the past year. There are a lot of factors that go into choosing a programming language and "what's new and cool" rarely is one of them.
The two biggest factors are 'what is the execution environment?' and 'what are the interface requirements?' Basically, 'who is going to run it' and 'what does it have to talk to?' (and they are closely related)
Next comes 'what are the related/currently existing projects already written in?' It's rare that you want to rebuild the whole thing. (Although sometimes that's exactly what you want to do.)
After that, I'll look at the available libraries and tools, but for the most part everything worth using is adequate in those areas.
Finally, if it makes it that far, I'll pick something I'm familiar with, just the make the whole project faster and less work.
Overall, it's been quite a few years since the 'language' of the project was something I even worried about. "When in Rome, do as the Romans do."
--Welcome to the Realm of the Hawke--
There's no point in changing language often. You stick to one and master it. I have a coworker who handles most legacy apps, it doubles the time taken to make fixes because he's in the wrong context.
I'd say 5 years is a good run for a language, you can return to it in a day later on. Sure you can do a quick hack in a non-mastered language, but your style aint stable and 3 months down the line it'll be spaghetti.
ID: the nose did not occur naturally, how would we wear glasses otherwise? (apologies to Voltaire)
... it keeps things interesting.
Besides, I hate Bob in QA and it gives him conniptions trying to read it.
Comment removed based on user account deletion
One thing I do not miss (besides being woken up by the pager) is having my knowledge obsoleted and being forced to learn new things. Oh, but you're supposed to never stop learning, stay young, blah blah blah. Bullshit, that's a bunch of pro-corporate propaganda. Now, I learn something...it sticks. 5 years later, I still know the thing. In fact, after 5 years I'm probably quite good at it. I will stay quite good at it until it changes (slowly or not at all) or I die. Sure, new laws and regulations come along every so often and they must be mastered, but it is nothing like IT. I like this way much better than becoming an expert and then having to start all over at square 1.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
I have switched computer languages many times. Some times for good, some times just for a project, but often I find a "better" language, only to find that it has many dead ends or other problems. My present primary language is actually two: Python and C++. With these two there isn't much I can't do. Where one is weak the other is strong.
.net is solidly in the trash, perl is solidly in my past, and very happily Objective-C is in the dumpster and I set it on fire.
That said, there are some situations where another language is called for. Javascript is pretty much the defacto browser language. Thus I would never try Python or C++ in the browser as that would just be horrible. But I don't really see Javascript as a great a language outside the browser as some people claim. Then there are scripting languages. I use Lua where I give users the ability to extend my programs through scripts because Lua is wonderfully tied into C++ through some awesome language extensions, they are tight and small. So would I say that I switch programming language when I jump to Lua or Javascript?
That all said, some languages are pretty much dead to me. Java is solidly in the trash,
I think that an interesting question would be more, "What language(s) do you presently use, what languages are your last 5 years of code largely in, and what languages are presently on your list of languages you are interested in exploring?"
Grandpa, Mom says you need to get off the computer.
C does what I need it to do. Only thing I'd switch to is probably assembly, since that would make the code run faster.
Be seeing you...
You should almost never have the mentality of "I don't use such-and-such-a-language", whether it's because you don't like semicolons, hate whitespace requirements, or some other bullshit reason (come at me, I know you're out there :P). That doesn't mean you can't prefer one or the other, or even gripe about it to your co-workers; just don't let it get in your way.
If you've done enough programming and know at least 1-2 languages fluently, you should be able to pick up another very quickly (less than a week). Often, at a particular company or on a particular project, you don't get a choice. If you do, the requirements of the project will force you to choose between 2 or 3. If you happen to be in a situation where you have absolute control and get the final say on what language to use, then you should choose the one that is best for the job.
But when I say "best for the job", I don't necessarily mean in some theoretical, push-your-glasses-up-your-nose sense. I mean what will allow you to do the best you can to achieve the requirements of the task at hand. If the task at hand is to teach yourself something, choose a language you're less familiar with. If it's to meet the requirements of a client in a reasonable amount of time, choose a language you are more familiar with. If the application is computation heavy and speed is a requirement, choose a more efficient language. If you are not the sole developer, choose a language that your co-workers would be more comfortable with using.
Often (read: always), more than one of these factors will be relevant. It's up to you, individually or as part of a team, to weigh them and determine the best choice. That is what it means to be an expert.
Simply put, you should switch languages whenever you deem it necessary to do so. To know when it's necessary, you have to expose yourself to a lot of different languages.
Only crack the nuts that crack. You don't put the ones that don't crack in the sack.
Unless you have been programming for about 300 years, there is zero chance you have achieved fluency in more than 2 or 3 of these programming languages. Being able to print "Hello world," does not count as fluency, any more than being able to say, "Hello, my name is Robert," counts as fluency in a human language.
Once you get past the first 6 or so, assuming you chose them carefully, the similarities are apparent. But if it helps, merely being able to write a nontrivial program in a given language doesn't mean that you can call yourself a "X programmer".
Consider what it means to be a Java programmer. I know Java, the language, extremely well. Well enough to write a conforming Java 1.7 to bytecode compiler, I would think. Now here's what I don't know: JSF, Spring, Swing, Maven, Ant, Struts, Android SDK, Eclipse RCP, etc. It's knowing a decent amount of that stuff that which lets you call yourself a "Java programmer" in good conscience. I can write programs in Java, but I'm not a Java programmer.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Disconnect your computer from the internet, and write a fully conforming Ada 2012 compiler in Common Lisp.
Interestingly, Ada isn't one of them. Nor is Python, interestingly.
If you're curious how I got to 60, there are a lot of languages in there which are distinct languages with distinct specs, but are essentially dialects.
Consider the Turner family of languages, for example. I've used KRC, Miranda, Orwell, Miracula, and Haskell. All of them are distinct languages with their own specs. I can remember writing a Prolog interpreter in at least three of them. I can still explain to you some of the key differences between them. if you know two of them you know them all, and besides, one of them is still around.
Other examples of distinct-but-close-enough languages which I have used in a nontrivial manner are Eiffel and Sather, SML and O'Caml (never used Alice), Smalltalk and Newspeak, Object Pascal and Delphi, Agda and Coq (never used Epigram), PostScript and Forth, Java and Modula-3.
And then there's logic languages. I've used (again, seriously used) Prolog, Datalog, Mercury, Oz, Gödel, and KL1. All of them are distinct languages with crucial differences, but so closely related that once you know two of them well (say, one dynamically typed and one statically typed variant), you can get quite productive in most of them within an afternoon.
Oh, and four different assembly languages.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
I dont switch. I start to use programming languages when is see it fit and stop to use them when I see it fit. It is not a 'Everything in one language' thing. Depending on the project, languages switch positions.
1987-1990: Basic
1988-today: Assembler
1989-1993: Pascal
1990-today: C/C++
1995-2010: perl
1996-today: octave/matlab
1999-2005: Autolisp
2000-today: Java
2002-today: Python
1995-today: bash
2007-2011: tcl/tk
60 looks a little bit too mich, but Ehen I look back, I learned several BASIC dialects, Z80 assembler, Turbo Pascal, 8086 ASM, Fortran, C, Modula-2, Scheme, Elisp, Prolog, Objective-C, PHP, Java, Xtend. That are 15 counting the Basiscs AS two languages. I also used XSLT, XSD, Corba which are a transformation language, a data model language and a component interface declaration language. I also know some stuff in HTML, CSS, SQL, EQL,bash, csh, make, ant and maven.
So if I count all those DSLs as programming languages, I am close to 30. Maybe he can provide us with a list.
For small programs, compiling C++ at -O0 takes under a second and the result runs faster than any interpreted language.
I am TheRaven on Soylent News
The first is the implementation of the language. You start with Smalltalk, take out the bits of Smalltalk that are difficult to compile, and then end up with an implementation of a language that is slower than something like Squeak / Pharo, which are simple bytecode interpreters. That doesn't fill anyone with confidence in the language. I can understand Ruby not being faster than a JIT-compiled Smalltalk, but there's no excuse for it not having been faster than a reasonable Smalltalk bytecode interpreter from day one.
Then there's the community. The Ruby community spent a good decade taking 30-year-old ideas and claiming that Ruby had made them possible, that Ruby developers had invented them, and this is why Ruby is so awesome. Rails is a good example of this. ORMs have existed since the '80s. WebObjects was arguably[1] the first ever web app development framework and it included EOF, which did the same thing as Rails in Objective-C (later in Java) and has had an open source reimplementation since the late '90s (GNUstepWeb, later SOPE, the latter of which is used by [Scalable] OpenGroupware.org). Oh, and WebObjects had much better developer tools than Rails, supported multithreading long before Ruby was able to run multithreaded, and was an order of magnitude or so faster.
[1] There's some disagreement, related to announcement / beta / shipping dates, but it's either the first or second.
I am TheRaven on Soylent News
I always see a lot of different opinions about programming languages, but how much choice do you really get to have over which language to use? If you want to develop for Android, then you're probably using Java...and if you're developing for iOS, then you've probably been using Swift or Objective-C. Even when looking for a job, all your most recent job experience is usually tied up in whatever language your current employer insisted on using. (Unless people are routinely getting hired to work on projects in an entirely different language than the one that they're using now...)
Choice? Nowadays not a lot, I think; when I started way too long ago, you would choose a language that was accessible (in my case, one that I could find manuals for), then choose a job that required it. But back then you could get any number of jobs simply for being able to code. I started off with assembler, BASIC and FORTRAN in the 70es when programmers wrote in all upper case, added COBOL and PASCAL (still upper case languages back then) in the 80es, then C. I got into C++ in the 90es (because "The Future Has Arrived, And It Is Object Oriented"), and in the last decade or so I have used a much diverse range of languages - ksh and python for scripting, C, C++ and Java for application development, as well as whatever else was required on occasion. But C has been my main language for most of that time.
Maybe the question I really want to ask is how often do you really get to choose your programming languages... Does it happen when you're swayed by the available development environment or intrigued by the community's stellar reputation, or that buzz of excitement that keeps building up around one particular language? Or are programming languages just something that you eventually just fall into by default?
I think most developers really just code with whatever is used in their project, and will be able to change from one language to another with little difficulty. If I should make a guess, I would say that you start off early in your education by choosing the language that best suits your particular sphere of interest - GUI, back-end, kernel or whatever - but you will inevitably get infected by other languages over time. Personally, I have never paid much attention to what is popular or fashionable, but then I'm not a great follower of trends in general; I just use what seems best suitable. I suppose, when you build up your experience, you begin to notice that the differences between all those languages are fairly minimal - there's the old languages that seem to be made of cast iron and concrete, like COBOL and FORTRAN, there's a load of C style languages (including C++ etc), and then there are the "exotic" languages, if you will excuse my choice of words.
I looked at the syntax of Ruby once, immediatly hated it, and never looked at it again.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
C/C++ is good for canned software meant for wide deployment where you have fine tweaking of the performance so it can run fast on a big set of software. However scripting languages are good for those internal jobs that need to be fast enough but programmed quickly without all the rigor, so you have a useful app running quickly.
Most of my programs I make are server side and I rely on scripting languages to do much of the grunt work because they can do it without the fuss of C.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I get where you're coming from. Being a programmer in "X" is more about knowing the tools and available libraries than it is about knowing the language itself. Somebody who works with C# could probably be very productive un VB.Net within a day or two, even though the languages appear quite different. On the other hand, C# and Java look quite similar in their syntax, but generally don't have much in common in terms of actually working with them. It might take a month or more to get reasonably productive it you switched from C# to Java.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
In my work, we deal with a wide variety (basically a large number of existing projects lead by other groups). So not only language, but style guidelines, processes, everything we adjust continuously to match whatever project we are working on at that moment.
I have been in other positions where you must not use anything but the one true process, language, and style guideline as set forth by the company standards.
In terms of when I *choose* for starting new, it's based on the available skills of the team I can put together. Despite all the 'oh language X is better than language Y', 99% of the time it doesn't really matter. You can do most things in any language, so it's most important to select whatever your team is most comfortable with. Yes, the potential performance and resource utilization may be better in some languages versus others, but most of the time with average teams, design choices will matter far more than runtime/compiler differences.
XML is like violence. If it doesn't solve the problem, use more.
So you are the one that writes all those scripts in the task scheduler with no error handling or logging that fail all the time and make my life a living hell.