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
I've been using C/C++ for almost everything for 15 years now.
I guess it generally comes with job switching and many times, it involved learning a new language
Maybe the question I really want to ask is how often do you really get to choose your programming languages...
Since I love to program and also do it as a hobby, every time I start a new hobby project or go looking for an open source project with which to get involved I have the opportunity to switch languages. Specifically, if I want to learn a new language I'll typically go find a book, read it, then either start a new project or find an existing project with the specific aim of exercising the language that currently interests me.
At work it's pretty much Java all the time (with a little Python thrown in for good measure), but then it is a solid language so I don't mind it very much at all.
I switch when the job requirements suit a particular language or another. Right tool for the right job, right??? Right???
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!
How often I switch projects and whatever's the best language to do it in.
Pointless being tied to one and limiting oneself.
...about every 2 hours, on the current job.
Having said that, I speak over 60 programming languages (to varying levels of fluency) at last count, and I do the Pragmatic Programmers thing of doing another one every year. I may not be the best person to ask.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
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--
>> 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.
In my (corporate) neck of the woods, people have been flocking to Xamarin (C#-based) for multiplatform mobile development for the past two years. Final tune-ups can be performed by a limited number (or contracted) platform-specific folks, but not much original "guts of the code" is being developed on "just" Android Java or Apple's proprietary languages these days.
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)
I assume you don't include switching between JavaScript and PHP / C# / Java. That would be many times a day in my case when I'm working on a website. But I also have another contract where I use Node.js and Unity, so in that case the switch between JavaScript and C# is really a different context.
I don't switch programming languages, I learn new ones. I know C, C++, Objective C, Fortran, Java, G (Labview), Python, Mathematica, Ladder logic, GLSL, OpenCL kernel language , Logo, Basic, php, JavaScript, lisp, and more than likely things I've forgotten about. Hell I created my own custom language interpreter in g. I apply what I've learned from every programming language to solve problems in whatever language I'm currently working in.
If you are asking when to change languages you're asking the wrong question. I never switch languages I only learn new ones.
... it keeps things interesting.
Besides, I hate Bob in QA and it gives him conniptions trying to read it.
Twice a day
Approximately every 3 months I switch "main" language. In the last 12 months I've worked in Java, C++, Python, and C# depending on whichever project my employers see fit to have me on next.
How often do you tackle a project using a language you haven't touched in years to dust off your knowledge and demonstrate your fluency?
...I basically have three areas I write in.
There are the short and sweet (I mean, we all intend them to be short and sweet, no matter how unwieldy they get) system administration scripts. Those are basically always bash, although after I write them I always go "Damn, I keep meaning to try execline and forgetting it exists!"
There's frontend Web dev. Javascript rules the day here, until WebAssembly finally gets... assembled.
Then there's "everything else", which for the first ten years I wrote code meant Perl. I also flirted with Ruby and Haskell, didn't like Python much, despise PHP and used it anyway when debugging the seemingly-endless string of PHP webapps out there, and somehow convinced myself C/C++/C# were too hard for me to learn.
Then I discovered Rust, and now it's basically my favourite language for anything. Rust has actually made me seriously consider moving from administration and support to development (if anyone local was hiring entry-level Rust developers, anyway!). Will I consider other languages in the future? Probably. But I'm going to consider Rust first.
I still do some 8080/Z80 programming for my collection of CPM / TRS-80 machines. Also a little 6809/68HC11 for some embedded controller boards we made 20 years ago.
I even wrote a printer driver for a Heathkit 6800 system , had to enter all the hex codes in by hand via the keypad,
at least I had an assembler that generated the hex for me.
Managed to even squeeze a 256 step sine/square/random signal generator at 100Hz into an 8MHz 8051 derivative, had to count clock cycles on that one.
Ahh the good old days.
Comment removed based on user account deletion
For what I do, a lot of problems are more easily solved through domain specific languages than constantly using a general programming language. So I might make a small framework in a standard language, but all the important stuff is all defined in human readable text files. Like: Default 20min operation timeout, Start operation XX, Start operation YY, Wait for operation XX to finish, etc...
The best part of that is if you develop each command as a module than you can reuse them on other projects. The interns kind of hating having to learn all the modules, but having them saves a ton of development time. Code reuse when done right is extremely efficient.
In the last two months, I've used three different programming languages, maybe more.
The disturbing thing about the question is that it seems to assume you can only program at work. If so, I feel sad for you......you've never caught the enjoyment of programming.
"First they came for the slanderers and i said nothing."
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 don't change.
I'll use whatever I feel like, or think best fits the program, whatever is available, or whatever the job requires. Asking how often I "switch" is asking how often a tinkerer "switches" toolsets between woodworking, metalworking, electronics, house painting, house cleaning, cooking, you name it.
The analogy of a nearly but not quite entirely unusable toolset is an apt one, and in that light it's quite amazing people try so hard to make it work against the odds. Me, I'm not about hammering the problem into my preferred solution providing tool by any brute force necessary. I'm about finagling a solution from the grasping hands of the problem without it realising it's been robbed. That's an entirely different mindset, and one in which the posed question has no meaningful answer. So, if this is the question you feel the need to ask, now you know what your answer ought to be. Curiously, there are a few other languages with "fits all problems" mindsets and corresponding toolset analogies. The one with the moustaches, for example.
I use MongoDB because it's webscale. I also pipe data to dev/null because it's fast as hell.
But seriously, for web stuff, php/javascript and for Windows server work, believe it or not, VB.NET, because that's what the code I've got to work with was written in.
How often do you want to get fired for whipping up something in a language nobody else in your department is familiar with, simply because you thought it would be a fun exercise in "dusting off your knowledge and demonstrating your fluency?"
I just bought a used book from Amazon, "Writing Compilers and Interpreters: An Applied Approach," by Ronald Mak (1991 edition), to write an interpreter and compiler in an ancient dialect of C written for DOS-based C compilers, and the target language is probably an equally ancient dialect of Pascal. The 1991 edition supposedly has working C code, whereas later editions has C++ code that doesn't translate into a modern dialect. After this, I'm going to write a BASIC interpreter and compiler.
Seriously, right tool for the job you're doing. I script things in various languages and write low latency C++ at the same time. Who gives a shit?
Bash shell - miscellaneous scripts
Perl - glue programs/scripts
Java - webapp
Javascript - webapp frontend
Obj-C - iOS app
PL/SQL - database triggers
I've been doing C/C++ for decades.
I've picked up some Java, Python.
Can do C# when it's the front end (I'm not a GUI guy).
Of course shell script is always useful.
I can do all that I need to with JavaScript/Node.js and PHP. Can code in a variety of other languages (perl, Python, C/C#), but never saw the need to switch really.
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?"
Perhaps Slashdot needs a new motto?
Slashdot news for script kiddies.
Computer scientists and engineers select the right tool for the job. Programming language doesn't matter as much as being able to solve the problem or task efficiently.
The company I work for has many infrastructural services and is actually quite open to alternatives. Once we were all Ruby and Java, but now we have a group developing production code in Kotlin and a production service written in Elixir. These newer languages have internal champions who worked really hard to establish that there was value and that there were not big risks.
...I've been programming in Fortran on cards for 50 years so I can't tell how often I swap until I pick up one of them new fangled languages like APL. If that happens in ten years, then I can answer "60 years" but until then, I have no idea.
I've been a developer on some pretty damn big projects. The kind of projects used by Fortune 500 companies -- everything from end-user facing applications all the down to low-level infrastructure projects.
If there's one thing I've noticed about all of these large projects over the years, it's that there is rarely ever only one programming language in use. Web apps will use Javascript on the front end and one or more language son the back-end. Large scale C/C++ apps will have a variety of scripts surrounding them. Every project needs an installer, some form of scripting for the build processes, deployment, automated QA, and (frequently) database management. There may even be a mobile app attached to the project. I've had to switch between C/C++, Bash scripting, Java (with JNI), SQL, and REXX, all in the same project.
The point being, if you work on a large enough project, and aren't a junior developer, you're probably switching between a bunch of different languages already. Those languages are probably fairly stable (i.e: you probably won't see too often where you change a massive project from Java to C#), although I've certainly introduced new languages and processes to big projects to make "dumb" processes smarter. The ability to do that, however, often comes when you get to a point in your career where you can specify and/or contribute to significant architectural changes.
I've also been fortunate enough to work at a few places where you can spend 10% of your time working on personal interest projects. If you're fortunate enough to be in such an organization, this is a great time to try out new languages that interest you. If not, find (or start) a project in the interesting language of your choice, and work on it in your own time. If you make it Open Source, and put it on GitHub or the like, you can include it as experience on a resume.
Yaz
I switch between languages several times a day, sometimes I use two at once, doesn't everybody who codes? I have a method for understanding the capabilities of a language by implementing some design patterns when I learn a new one, which is pretty fun to do. I have no shame, I am a geek!
Sometimes the features of one language teach you something new that you can apply to other languages. Learning is addictive, it's why I love programming.
Is it just me or does anyone else get the feeling that these odd questions are being asked by recruiters trying to figure out how technologists work?
My ism, it's full of beliefs.
Well, I switched from FORTRAN77 to C in 1981. Switched from C to C++ in 1990. Still using C++. Clients hire me to do C++. The right guy for the job I always say. For fun these days I have also been doing some Arduino stuff. Kinda refreshing. Reminds me of the old days..
Grandpa, Mom says you need to get off the computer.
How do you mean "switch". At my work we have a main dev language and a couple in-house languages that are used to generate code. I also use emacs as my main programming environment, so I write a little bit of elisp weekly, probably. Or do you mean how often do I abandon a language and move to a new one forever? In that case, not once in 15 years.
How often is it that you have a brand new system, in which you get to choose your language? Unless you are independently wealthy, or part of a funded started (indirectly independently wealthy, partially) the answer is probably not very often. Whenever someone has a brand new, completely open, technological problem, they have a green field.
This is not very common, at least for me. I have a BS + MS in computer science, worked for three years as an employee in two companies, and now own my own small software company (with two guys I pay to write code for me) and have been in business for myself for four years. I charge enough money to pay my people, and my bills, through revenue. That means, by definition, that my customers have to be able to pay. I live in a poor state, without a tidal wave of venture capital. Almost everyone here has a legacy system, which is generating them money, which they can use to pay us. Those systems come with constraints.
There have been three times in my 10+ years of experience creating software during which I was able to 100% choose everything technology related for a project. Once was part of a barely funded start up. The other was part of a successful business that contracted with my company to greatly expand their eCommerce, completely scrapping their existing system and letting me choose everything. The third is ongoing - a customer described their problem in a high level, and nothing existed to solve it. For the third example, I am bound by (light) constraints regarding the other system we are interfacing with, and it has to be web-based. Otherwise, my more than full time experience, has been as a maintenance programmer, or as a manager over a team of maintenance programmers. This guy is way more eloquent than I am about the subject, and way smarter + more successful. Think about what the very successful people have to say about these kind of things.
I think different people, in different states, have different approaches. The most poorly organized organizations, and ventures, had very few constraints. They didn't have to answer to anyone about their technological choices, and typically had money to "build something." Sometimes that results in beautiful leaps forward, for humanity as a whole. I think most of the time it doesn't. Maintenance programming means you are maintaining something useful, for someone that is interested in paying you. You'll also learn new skills, and new languages / technologies / tools, just out of necessity, rather than being freely chosen, with no constraints.
Lisp, Python or C# by choice. I'm moderately fond of ObjC and Swift.
C#, Python and JS for work, occasional PHP if I'm unlucky.
SourcePawn (ugh) or LPC (MudOS) for funnies.
Perl when I'm too lazy to port legacy stuff to something maintainable.
Started programming in Turbo Pascal, moved to Turbo & Netwide Assembler, then Lisp, LPC, C, C++, and onwards. First professional programming job was in PHP, of all things.
Overall preference: Python, since there's almost no mental translation happening. It maps very closely to the way I structure code in my head.
Given the set of products we have, from a single provider, I have to switch between: python, javascript, vendor specific language, java, bash, perl, xslt, power shell and sql on an almost daily basis. I rarely end a day dealing with a single language. Unfortunately, no C/C++ at my working place.
Achille Talon
Hop!
I am doing infrastructure for a well known, yet not public SF company. I've had days where I had to write code in 5 languages, going from interpreted languages with almost no type support, to Scala's type battleship. This raises problems for learning: I learned Scala somewhere else, doing nothing but Scala for months. When you can dive deep into a language, it's easy to remember it, and then bring back the knowledge on command. But without a deep dive, it's really hard to learn a language, especially when you deal with a bunch of similar ones. I never have to do much Ruby, or much Python, so they never stick in my head, and the lack of a compiler means I often write terrible, broken things. Maybe if I only wrote ruby for 3 months, then only python for 3 months, then maybe they would stick, but that's not now infrastructure work goes.
BASIC -> Pascal -> C -> grave
when you pry them out of my cold dead hands.
Uh, wait a minute.. .
You can change or add a language on the job and then apply for a position in a new job.
Some positions don't expect to hire people profficient in a specific language. Mainly in large companies which can afford a significant ramp up period or companies using rare languages.
I did various small jobs doing C and Pascal. Including translating PL1 to C. My first real full time position after graduating was in Java and I more or less stayed in that world for the last 13 years. I did a foray doing a non hands-on position in C#. And currently write Scala which largely grows from Java developers. Though I write small amounts of code in many languages.
My wife on the other hand did 8 years of developing C++ on windows at various companies and was feeling stuck, believing thus isn't a technology stack with much future in good companies. But eventually found a position doing Linux kernel development and then transfered internally to a Python position.
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.
I bet I have used languages with the same frequency as this kind of question comes up on /. -- current favourite is alpasisp+++^21
Seriously, it's all just syntax, convention, and architecture, so I don't bother to track. Off the top of my head, I'm up to 30+ "languages" in 30+ years. Throw in media (yes, starting with punch cards), then it gets worse.
I think a more relevant question is how often does one advance their architecture, paradigms, and most importantly debugging skills. Anyone can write a program that compiles and does something. Building something that is understandable, useful, usable, and maintainable, now that's a discussion.
Before college, it was some Pascal because that's what the client was already using. That was in the client's apartment.
During college, a professor had some existing Fortran code needed to be worked with. There was also a project out of a guy's livingroom that I prototyped in Basic and then my friends came onboard, said WTF man this needs to be assembly langauge. They were right so we made it so. Other projects were in assembly language and C because, we were working directly with the hardware mostly. Oh and there was a little Pascal for some classic MacOS apps.
Towards the end of college and right after it was classic MacOS apps using C++ (MacApp framework).
A few years later Java came along and our team decided to move to that.
Then I joined PayPal and it was all existing custom C and C++. Eventually there were 100% new projects using Java and I was all on that, going back and forth from day to day between the old C/C++ and the new Java code.
After PayPal, I had a chance to learn and use Python at a small startup that had some code needing an owner. Alas they ran out of money and shut down. The next two employers had existing Java code needing attention.
Next language will likely depend on what the employer needs but, I have zero interest in PHP!
At work we code in Java, C, C++ and Python. We simply choose the language best suited for the task at hand. Of course, many stick to the parts written entirely in Java or C++, but some of us shuffle around, but sometimes we have to make functionality, which are best spread between languages.
In my oppinion a good programmer can easily cope with different languages - and will be better from it because you can be inspired from how things are done over in the other language.
Mostly its Systemverilog, tcl and c for me but now and then a script in bash, ruby or perl. And then there xml, makefiles, lisp and several custom formats on top of that
I pick what I like and use it, currently. For UNIX stuff that means Python, though I'm forced to use Perl a lot as well. For Windows stuff or if I have carte blanche I use C#/.NET.
I think if you're really good in two languages and can swing back into another one or two that you're "rusty" at, you're fine. This cock measuring contest about knowing 15 languages is fucking silly and childish.
Currently I prototype personal projects in Python or C# depending on the need. Javascript for now-rare-to-me web dev. At work, 99% Python because Openstack.
OK, this breaks down into two domains:
If you are programming for a personal, or one person project, you have -some- choice, depending upon the target platform.
If you are joining a pro shop, the decisions have already been made. You either know the language and paradigm, or you convinced someone in your interview process that you could come up to speed in an acceptable amount if time.
I honestly fail to understand these debates.... logic is...... logic, once you understand it, the programming language is just a tool to express it.
And on that note, shitty, faulty code, that does not parse input properly AND handle exceptions is the root cause of almost all of the security problems we deal with, and it does not matter in what language the shitty code was written.
Oh, and NEVER try to invent your own crypto, unless you have a PhD, and THEN get it peer reviewed. But that is algorithmic, not programmatic...... and almost certainly not language specific.
Red
You think, but it's unlikely to be the case now days.
Compilers and Binary JIT optimizers can make optimizations you could never imagine were possible.
The days of hand optimizing assembler for programs are over with. Only place that skill is particularly useful or relevant is in toolchain development.
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
Would it? I wasn't ever able to write better assembly code than GCC with O1 and I guess it is the same for many people. Super scalar CPU is hard to optimize, how am I supposed to know that generated ASM code with 2 times instructions and 1.5 times cycles required for all of them will execute in half the time compared to my own hand-written code?
Compilers are good for the mainstream architectures.
For fringe architectures you have to be happy if the compiler generates code that does approximately what you intended.
Then again, I also work with small targets (couple of ten kB RAM, couple of hundred kB Flash).
Oh, and I switch to Matlab script occasionally, when determining what the small devices should actually do.
I do compilers, low level OS stuff, debuggers, code analysis tools, so I'm always having to switch languages or keep up with other languages. When I have more of a choice my current preferences are a mixture of C++14, Perl and Assembly ( especially PowerPC ). Modern C++ is a pretty nice language and I consider it distinct from C++98 and earlier. I also have way too much fun playing with meta-programming when I can. And template meta-programming is always fun for adding another level. Wrote a binary object file parser once that was pretty much all default member initializers ( thanks C++14 ) and template meta programming. Why write a function when the compiler will do it for you, especially when you are writing another compiler.
I work at the real bottom of it. While other people think about "which OS (version) do I have to work on?", I sometimes don't even have a processor to work with.
I do FPGAs with VHDL, ARM CPUs in C and assembler, usually without any OS at all (think graphical UI on a machine with 2 kilobytes of RAM!), maybe with some library routines (not a full OS) for networking. Sometimes I have to work on the PC side of things, so I have a good part of my build chain (anything after the C and VHDL compilers to create update packages, etc), the communication libraries for my PC programmers, or simple tools in C and Perl, and sometimes BASH. And if it comes to worse, I do a bit of SQL, PHP, HTML, and even Lotus Script.
Switching between VHDL and C is so common, at the moment I have two VHDL and one C project open, and I work both - usually, while the VHDL synthesizes (10-15 minutes for one build), I write the test routines in C.
Used BASIC , FORTRAN and Pascal in school ('76 to' 82), used Tandem TAL, 6502, Z80 and 68000 assemblers, FORTH, C, C++, and Postscript at various jobs until I started using NeXTSTEP in 1989, used Obj-C from 1989 to the present, and I started using Swift when it came out two years ago.
So, Obj-C was my main language for around 27 years. I expect that Swift will be what I use from now until I stop coding altogether.
Along the way, I also had occasion to use Perl, various shells, and a tiny bit of Python and COBOL.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
8051 needs to die! $5000 for a compiler to write for texas instruments current bluetooth chips...
Not sure about you guys, but while I've used everything from Basic to Bash to C family, and every language Du Jour of the past 20 years all the way to in house DSL's when I need to perform implementation tasks.
But when I do the real work of programming I do this shit in English.
Programming isn't a single task. It's a series of actions involving asking questions regarding requirements and seeking out the best answers to those questions.
The process of answer seeking usually reveals the right language for the particular sub task at hand, but rarely is a program so trivial it is composed of a single subtask. So we end up with a mix of whatever languages will produce the best results for the tasks they need to handle.
I've been involved in writing everything from special purpose drivers for microcontrollers and smartcard apps that need recover from tearing (someone pulling the card out prematurely) all the way on up to mission critical corporate infrastructure where downtime can be quantified not in hours but in kilodollars per minute.
Furthermore, I find that the longer I do this professionally the less satisfaction I obtain from being an implementor. I'll learn a new language as it's gaining relevancy, so I'm in the loop and understand what's creators envisioned it's usecases to be. In general thoug most languages are general purpose DSLs and as such really do have limits to what you can do with them before you are no longer using the best tool for the job and start to produce a maintenance or security nightmare.
Rarely have I used any single language to pull it all off except English. Whether I'm asking questions of my customers, or explaining what we need to do to my subordinates, it's English all the way. :D
How do you do c++ scripts?
You use a package like ROOT which we use at CERN for data analysis. The original author had the idea that he would save physicists the time to learn a separate scripting language by using interpreted C++ as a scripting language. As you can imagine this did not work out very well. Firstly C++ has an appallingly bad syntax for scripting use and secondly there are many features they were unable to script like virtual functions.
The result that the scripting language was more of a C+/- which was badly documented and also very buggy. One of the worst ones I ever found ws actually using compiled code where adding a blank line i.e. just a new line character to the source code caused duplicate symbol errors due to using the C preprocessor to generate a symbol which only differed by the line number the macro was called on!
Debugging in general was also bizarre because the error messages you got rarely if ever pointed you to the problem and the memory management is also extremely unclear. The only thing which kept it somewhat usable was the development of the python interface...which of course completely undermined the original vision of scripted C++.
Unless you are in one of those 'multitasking' environments where everybody is feeling very busy but efficiency is crap, you can pretty much stick to the language that best suite the work you are doing.
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.
Most programming languages are the same imperative/OO thing, and after 5 or 6 you just don't care any more. If the project allows, do choose the best one for the job, even if mixing, but don't get too held up on this. As a previous poster said, the main programming language is... English.
Now switching platforms is another problem, and that can hurt a bit. Still, after a while the pain dulls.
I apologize for the lack of a signature.
I guess you are still working on that project.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
C# to Java to ANSI C/C++ to Python and back.... pretty much every working day....
DO YOU SWITCH SPANNERS
I've nearly mastered Windows XP.
Isn't that a TI problem, not 8051 problem?
Being a software development consultant I get to work on various projects throughout the year. With every new project I tend to choose the language and tools that suit the project best.
And if you're working on Android, I would say it's worth taking a look at Kotlin instead of Java for your next project.
Between the early 90's and today, I've switched from machine language to C and C++, and recently to Python. I don't think I will switch to another favorite any time soon.
Between dropping traditional C support in C compilers around '00, to all the new breakage thanks to C++11 compatibility in C11 for legacy code, to various library related breakages as a result of the above, ugh!
Once you have standardized a language it should NOT change. If you need a new revision due to failures of your definition, then you should treat it as a wholly new language and NOT shit all over the legacy code, causing hundreds of new issues of 'legacy code', 'transition code', and 'new code' all of which work fine on their expected compiler versions, but all of which fail if you try and move them backward, forward, or onto the only compiler release that works on your one esoteric processor that wasn't supported before, and now isn't supported after.
While somebody will no doubt say 'You have the source, you can fix it!' How many people practically have the knowledge AND time to deal with fixing their compiler's hardware support, their code, and any programming/language definition mistakes that are/were/will be in their compiler toolchain?
Just as examples, both gcc and clang STILL miscompile certain snippets of code 20+ and 10+ years later meaning the two compilers may not be interposable for non-trivial programs and breakage that occurs may not be visible until it is too late. Combine that with different standard c++ libraries, different c++ versions, different c versions, and different years of code generation and you can end up with a morass of corner cases that all subtley break just enough that somewhere down the line you find out you have tons of garbage data that was just close enough to keep working, but not enough to give you the results you needed now, years later, with no easy way to recovery. Sure this is a stretch of an example, but the bugs are all there and I'm sure more than a few of you have run into many of them when bringing legacy code up to compliance, or rewriting modern code to compile on a legacy system. How do *YOU* do it?
You know that there are still lower performance processors in use, do you?
I don't do ActionScript anymore (for Obvious reasons) and I've been doing more serious JavaScript lately (same reasons).
I moved into 'serious' PHP roughly 5 years back and will probably use it for another few years. I do various PLs on the side (C#, Python) but not as a mainstay.
I've been trying to pick up a truly compiled language (C++) for decades and now will probably finally do so. I generally like to pick up languages I expect to use until the day I die. That's why I only use FOSS PLs - ActionScript was a sole exception to that.
My 2 Eurocents.
We suffer more in our imagination than in reality. - Seneca
I said it!
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Full stack coding switching between Java, JavaScript. There's a lot of markup (HTML, XML) and SQL in there too.
and there is no switch statement, it is just called SELECT CASE...END SELECT, you insensitive clod!
I'm doing theoretical physics, and for the last couple of years, roughly half of my time has been comprised of numerical simulations. I'm free to choose the language I want for the programming part, since the main results that I'm paid to produce are not the simulation codes themselves, but the physical predictions they result in. (In practice, I started this project using Matlab, but it was too slow so I ended up rewriting it in Fortran 2008 for computation and Python for data visualization.)
Every time the C++ standards committee get together.
Ada is my first love, and it's been my primary language since 1985. Unfortunately, nobody has wanted systems built in Ada since the 1980s, so I've had to settle for Ada dialects such as PL/SQL and PL/pgSQL.I've had to code in the more modern languages as well, and given the contributions these languages make to project failures, I'm firmly of the opinion that if you want a large system built to last, build it in Ada.
I have never switching programming languages. But does they change themselves over time?
It's a stupid question. I never switch languages. I use several. Hell, by the time I finished highschool I was quite fluent in half a dozen. That was 19 years ago, extrapolate. I have favorites, not many, but usually I code in what's easier to do what I want to do, or in what is specifically requested. That's it. The question is still stupid.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
Matlab/Octave for quick simulations and signal processing
Python for scripting and controlling equipment, and some data analysis
C for embedded processors
Ruby for running test scripts, since the test engine only accepts Ruby.
I stick with C++ (primary), C (interface with many libraries), bash, and a little Python -- That is because most of my work involves data analytics, parallel simulation on compute clusters. For me compute time is #1 factor (as several of my simulations run for 4-6 days on 100 cores).
I'm a CIS adjunct, so it changes from semester to semester for me. This summer semester, I'm teaching advanced web design, so that includes JavaScript. Fall Semester will be web programming w/databases, so it will be either PHP w/MySQL or ASP.NET w/MS SQL--haven't decided yet, though I'd prefer PHP. Spring semester is usually an intro to programming course, and is either Java or Visual Basic, depending on where I'm teaching.I also used to teach Unix Shell Scripting & DOS batch files, but those courses were discontinued.
Taking guns away from the 99% gives the 1% 100% of the power.
And that's what most folks don't understand, it's just syntax. And when I see supposed computer "scientists" say the "right tool for the right job", cringe.
This isn't construction, dentistry or surgery. It's one thing when you're programming on metal and you're stuck with whatever is there, but if you're manipulating data, any language will do just fine just as well.
If one has to use "the right tool for the right job" in order to implement an algorithm, then they really haven't mastered their craft.
Comment removed based on user account deletion
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.
Nearly my own history, exactly. As languages evolve, so do the programmers.
It's not just all about languages of course since claiming to be a C++ programmer says squat of your ability to write a GUI. And writing a GUI for a desktop is different from one on a phone or on the web for that matter. So breadth of experience is important and feeds into the next thing. It also demonstrates to prospective employers that you are capable of learning new and can adapt your thinking. Even if you haven't learned tech X, you make have skills from tech Y which are transferable.
This is a somewhat silly question. Programming languages are tools and you use the right tool for the job. How often does a carpenter grab a different tool out of his toolbox? As often as he needs it. Your first paragraph gets to the point. If you're programming a particular target, then there's probably one or two tools best suited for it. Use that one!
Using the head of a screw drive to drive a nail might work, but why would someone do that when there's a hammer?
outside of personal projects of course. When it comes to professional work, the languages one uses are usually either dictated by whatever's currently in use at the company/project. For new projects, it's often times obvious which one you should use.
Now I have worked with folks (usually young and inexperienced) who always want to switch to using whatever the hot, new language of the day is but that's usually a waste of time and a mistake.
This story:
http://catb.org/esr/writings/unix-koans/recruiter.html
What is fluent? I haven't quite been programming for 300 years (only 40), but during that time I have certainly been fluent in at least eight languages. Some similar (Pascal/RatFor, C++/Java), others fairly different (Prolog, Lisp). The thing is, there are two aspects to fluency, and the second one is problematic:
- The syntax and semantics of the language. This is only difficult if you're learning a new paradigm. Once you know a particular paradigm, learning a new language in that paradigm is relatively easy.
- The built-in libraries, plus whatever external frameworks you need. This is essential knowledge, if you are going to be effective and productive on a particular project. At the same time, this is problematic, because there are zillions of frameworks, and they are continually changing.
I have always thought that job postings that require a particular language, or a particular framework, are stupid. A good programmer with a broad background can learn what they need in a few weeks (caveat: see the note above about new paradigms). A bad programmer, well, they're useless even if they have experience in some specific technology. Heck, this doesn't even make sense for entry-level positions: New programmers, fresh out of school, are going to require serious training and mentoring anyway, before you can trust them on business-critical systems.
Enjoy life! This is not a dress rehearsal.
In my personal life, I switch between languages when I feel like it. I've used about twenty-five so far (I counted). There was one year when I used over ten. These days, I tend to stick with the same half dozen for most things.
In my professional life, I have to choose the best tool for my coworkers' joint ability to maintain. Do I want to tell my manager that it's worthwhile to make everyone on the team learn Dart so I can get this one thing done in six days instead of eight? No; I'd be the only person willing to maintain the thing.
Frameworks are more important. People tend not to think quite as much of frameworks than of languages, but it can take longer to learn a framework, and it can be more constraining. For instance, at my job we have an ember.js application. No one on the team knows Ember. We can't maintain the application very well. It would take bloody ages to learn Ember compared to how long it took me to learn Javascript.
Conversely, I wrote a service in nodejs because we expected to open source it. More people know nodejs than Vertx, and the setup feels lighter. Because the platform was built on async IO, all the libraries you find play nicely with that model. Vertx, on the other hand, is built on Java but requires you to find libraries that will never block the main loop -- not a particularly natural or easy thing.
and I work on a few different projects, so on a daily basis I switch between Java, "old" JavaScript, ES6 JavaScript, Perl, PHP, batch programming, SQL. It used to be confusing, but when you're an old geezer like me, it becomes second nature. I sometimes miss the days when I did UNIX programming with nothing but Perl, C, and shell scripting.
BASIC, FORTRAN, PL/1, APL, COBOL, BCPL, C, ALGOL, Pascal, Various assembly languages (6502, S/370, PDP-11, VAX), C++, Java, Perl, PHP, C#...
And at that point, I do care: C# and Java are too confusingly alike-but-different to make a convenient fast switch. It's not just IT - I have the same problem with Dutch and German.
But maybe that's just because I'm getting old and/or my brain is now full.
Except in embedded systems and few webscale systems, performance is really not an issue in most software. What is needed is how easy it is for a human to program and extend it. The issues of 90s n before is not there now for most applications. Programming is getting a human thought/idea ..model it into a mathematical problem/model and from there the faster n easier the machine (language) can help, it's better. e.g you say you want a collection of data to be sorted, using some thing as key/ordering; and not care how the machine/language does it for you.
C may still be good for those embedded/performance critical; for rest I see language like python does the human-idea/algorithm to final-result much faster. It enables you to think in high level data structures/data manipulation and not worry about machine level issues. The higher you can abstract things, the faster and more easily you can extend the software. And s/w is an iterative task; you never know how the system is going to grow; so the easier it is to extend it's better.
Just resting: APL
In my sleep: C/C++, template metaprogramming
Intermediate: R
Passable: Perl, Python, shell
Long past: BASIC
At least once: Java, Pascal, OpenCL, Lua, VHDL, Snobol, Prolog, Forth, Lisp, TeX
Thoroughly evaluated: JavaScript
A few months back I looked at that list and decided I needed to add some tools more concurrency oriented, and something from the functional camp.
Learning rapidly: Elixir/Erlang/ELM, Go
My strategy in learning a language is to consume as much material as possible from the language designers, from during the language's actual design process.
YouTube makes my learning style ten times less difficult to arrange than it used to be. I keep a personal wiki, and I'm an extraordinarily efficient note-taker, so I care very little precisely what sticks in the first pass, so long as I manage to identify the language's motivating ideals and community norms.
2016 - MS .Net 4.0 .net Framework 2.0 (C#) .net Framework 1.1 (VB)
2015 - jsRender, jsViews
2014 - Raspbery Pi, jQuery UI
2013 - SVG, d3, RSS
2012 - jQuery, Ruby, nodeJS/node-webkit
2011 - Android
2010 - Arduino
2009 - Linux (Ubuntu), GTK+, SSH
2008 - Mono Framework 2.6 (C#)
2007 - MS T-SQL & Microsoft SQL Managment Studio
2006 - PHP, MySQL, AJAX
2005 - MS
2004 - Python, PBasic (microcontroller code)
2003 - RealBasic (Mac)
2002 - JavaScript, DHTML
2001 - MS
2000 - C++, Java, VBA
1999 - Linux (RedHat), bash
1998 - Visual Basic, HTML
1997 - PowerBasic
1996 - QBasic
1994 - GWBasic
...and I can still fondly remember:
10 color (int(rnd * 16)): print chr$(int(rnd*127)+127): $k = inkey$; if len($k)=0 goto 10
I wrote my own scripting language in Oracle PL/SQL (!) a couple of years back, and since then I write as much client-code I can in my own language.
Why? Because I can.
Sure, there's the odd project here and there where my clients, or the other "developers" they've hired, tries to force me to use some hocus-pocus-library - in Java/Python/PHP/Perl/you-name-it, which the project "absolute requires", but no one really understand why, or can tell me what it actually does. Essentially everything they try to force-feed me is a wrapper for some normal https-communication with XML/JSON parsing, or some fundamental economical/statistical calculation, but in 100 MB compiled code... I normally just rewrite the stuff I need in my own language, or in Oracle PL/SQL... I understand why I shouldn't "reinvent the wheel again", but I'm old-school, and my wheels turn faster than your wheels, and uses less memory, and has no known security holes, and are not dependent on yada-yada-yada, and... you get the idea.
I have seen so many "job openings" for people who knows about "programming language X" or "programming language Y" etc etc, and I fail to understand why the language-decision are being made by the guys hiring. Wouldn't it be better to let the actual developers choose? Hire problem-solvers, not syntax-gurus.
I have a set of tools, and I use the one I think is best for the job. Sometimes I will evaluate something new or less used, but only if I think it is still a good fit. People that have a default tool and use it for everything may "switch" after a time, but having a default tool that is not a good approach in the first place.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Yes, I'm part of this thread, as a 65 year old. I first wrote a little FORTRAN program in 1966 to calculate Ï to run on an ICL mainframe that was part of the UK steel industry. Because computer time was so expensive, 'they' (management) wouldn't let it loop and loop.
On my list is Filetab: https://en.wikipedia.org/wiki/... as mad as Perl and, like Perl, very useful.
On y va, qui mal y pense!
Sounds like the OP isn't a programmer yet.
While not trivial, it's certainly not hard, once you learn the foundations to start writing in another.
On my average day I write Ruby, Swift, and Erlang. On my less average Java, Scala, and JacaScript.
It's true. Why do I love C?
In 20 years of programming in C, it has never failed me.
There are very few other things in my life that I can say that about.
The writer and the editor seem to be on different pages. I'll try to answer both.
-- How much choice do you really get to have over which language to use?
Actually I usually get a LOT of choice in language. The business is interested in two thing:
1) getting the project done (so it can get paid) and
2) being able to maintain the project so that future requests from the customer can be handled.
As long as you address those two factors - language/framework/architecture choice is up to you. Of course, this is a loaded question - for example: I prefer Perl or Ruby - but the last scripts I wrote were in Python - because most of the team knows Python and point #2.
-- How often do you switch programming languages?
Or - more to the point - how often do you learn new languages.
I started professionally programming in 1994. Most of the languages (except SQL and Python/Perl) that I use on a daily basis were invented yet. (Java, Javascript came later).
Professionally I find I have to "reinvent" myself every 5 years or so. Could be longer; could be shorter - but on average it seems to be about that long. I do NOT HAVE to "reinvent" myself, but I find it useful to do so (better pay, better opportunities, chances to leave jokers behind).
That said - I do NOT learn a new language every 5 years. Rather I'm always learning a new languages (Go, Elixer, Haskell, Rust, Ember, Angular, React are on my list or I am currently studying them). And that's before I look at non-language items (Design Patterns, Architecture, etc.)
Some people hate that (quote: "Oh, but you're supposed to never stop learning, stay young, blah blah blah") That's fine. Personally I wouldn't have it any other way. I HATE being bored. YMMV.
If it works and it doesn't mandate being US Government spyware then use it.
If some still-alive CIA spook threatens to harm you or your family if you don't put spyware in it.. kill them.
Unless you are a franatic job hopper (may not be voluntary given the trends these last 10 years), it is successful projects that determine what languages survive and successful projects do not change languages very often.
On the other hand, most folks who depends on a paycheck from writting code probably uses a handful of different languages every day because languages (or large frameworks in general purpose languages) get their power from specialization. So I use some mixture of Java, SQL, Groovy, shell scripts (not even counting the different flavors of frameworks in Java) every week these days.
As somebody who got their first paycheck writting RPG-2 in 1969 and moving on to IBM 360 assmember, PL/I, SQL, C, C++, Java with brief flirtations with other less well known stuff along the way.
While competentcy (knowing the idioms) with the tool at hand is important, knowing why you are doing things is what separates the adequate from the brilliant. And that really does not depend on the specific language unless it is something totally brain dead or grossly inappropriate.
This obsession with language for language's sake I blame on HR and PHBs who put out requisitions for programmers with 10 yrs experience in Swift for their next killer iOS app.
At 35 I'm a subscriber to the 'switch every 10 years' philosophy.
.NET web stack. The two Linux/OSS/C++ companies are either tanking or have their employees giving very negative reviews and leaving. Five years later I'm making more now, but it was a big shift and I'm not sure I'm going to do it again.
Started in C++ in 2004. When I tried moving to Raleigh I found there were too many local C++ developers and too few C++ positions, so I took a pay cut to switch from Linux/OSS/C++ to
Think I might switch to R at some point if it gives me an edge on the age discrimination thing.
Basically I'm flying by the seat of my pants.
How Often Do You Switch Programming Languages?
This is the wrong focus. A more accurate (and interesting question) is how often do you switch stacks or architectures?
Embedded programming using, say, the Wind River toolchain can be quite distinct from doing Linux systems programming using the GNU tool chain. And these two are quite distinct from Windows systems programming using (duh) Windows toolchains. And these are all done (typically) in C. Similarly, C++ programming on Linux will be different from Windows programming, and more so when we start adding stacks and libraries like Qt when the objective is to use Qt's higher level capabilities instead of OS portability (which sometimes is not a bad thing.)
Same with Java. Right now I'm doing core Java, dealing directly with NIO, threading, etc, all outside the safety net of a container. For better or worse, our work does not use OSGI (and that would have been a very distinct type of work if such an architectural choice have been made.)
That is quite distinct from EE development. Working specifically to stay within a web container can be quite distinct from working on something *that exploits* every nook and cranny off an EE container. Then you can throw Spring (and/or OSGI) into the mix which can cut through every one of these dimensions in the Java world. And let's not get started when you move into a completely different paradigm (say vert.x)
In Javascript, this is even more radical since modern Javascript (for better or worse) has become some sort of meta-language that sits below a higher-level framework or architecture - be it jquery or dojo or extjs in the recent past, AngularJX, backbone, React and what now in our current times. Each of these poses a learning (and possibly architectural) challenge.
One sees the same with Python and Ruby to a lesser extend.
The .NET world provides more continuity in how things are build and a developer can, with relative ease, jump back and forth from C# to Managed C++.
And in the application space you have an additional dimension - application data storage. SQL or NoSQL. That will change how you design and code.
So the question that is more relevant is, how often do you change platforms and stacks. Because you could very well be using the same language for 6 years and have experienced a significant development and architectural shift.
I disagree - you can pretty much do anything with any general purpose programming language, that part is certainly true - but some things are vastly simpler to do using the "right tool for the right job." Only masochists would use Fortran or COBOL for writing a web service, and if you're talking about manipulating copious amounts of textual data, a scripting language like PERL will be a lot easier than C. Of course, if you're writing system scripts, you're not going to want to do it in COBOL. So cringe away - but there certainly are "right tools for the right job." I'm not implying only one language is good as solving problems in any particular domain, but that some languages are simply not suitable (in that it's a lot more work, and a lot more prone to problems) for certain domains of problems.
Stupid sexy Flanders.
I rarely got to choose a programming language, but rather used what the boss ordered me to.
For anything outside hardware control it depends on which language has the most relevant libraries in the problem domain, where the code you write is simply the glue. You don't want to spend time reinventing the wheel unless it's a hobby or an educational project. No need to switch unless you're changing problem domains.
I didnt see JOVIAL mentioned here yet. My first job out of school required me to program in JOVIAL. It went well...learned ADA, C, C++ after that... Wrote in a few others (took existing code and added functionality or fixed bugs) but not fluent. It feels like once I knew how to program the language didnt really matter. Sure it took a few days to spin up, and maybe a few weeks to get really good at a new language, but there is plenty of online stuff and usually someone else had been around longer then I and didn't mind teaching me a few tricks....in 2010 I switched over to Linux Admin full time. I enjoy it more the programming (after 20 years needed something new) but I could still pick up ADA, JOVIAL, C/C++ and be back in the grove within a few weeks...
#include bier;
I write in several different languages and like to switch things up.
If I'm compiling a big whopping gob of code I make a whole lotta build scripts using bash. If its the application directly driving the device, then the natural choice is C. If its a small time-critical application, then also C. If its a web page, then usually something like PHP or JavaScript (Both have serious problems, but are portable 'good enough for the network' code. Anything backend will be done in a real language anyway. I don't really know why anyone uses Java. I had real hopes it would be dead by now. It should have gone the way of COBOL at least 10 years ago. Its almost as fast as COBOL, is only about 40% larger than a COBOL program of similar use, and only has a syntax of about 500,000,000 built in routines, 90% of which you need to be familiar with before you can do anything useful. It is a good language for doctors who make money treating programmers with carpal tunnel syndrome. There are other languages around that have specific uses (If you program windows phone then you want to use .net or C#, provided you have all the licenses and gold certified stickers to enable full access along with the double-secret developers only extra libraries and exclusive-group development tools in the microsoft clean room).
does what I need it to do. Only thing I'd switch to is probably assembly, since that would make the code run faster.
This suffers under the misapprehension that you, as a human being, will be able to optimize for your processor (likely a pipelined architecture, perhaps with decades of inherited nits in it) better than your C compiler. You could be one of those handful of assembly gods for which that is true (or you could have a compiler with a freakishly shitty optimizer), but that's highly unlikely.
Of course there will be specific small cases where you might catch it doing something that can be improved, but in the general case assembly-level optimization these days is a problem best left to the compiler. This is why most C compilers have ignored low-level crap like the "register" keyword for years. ("Oh look! The human thinks he can optimize register allocation better than me. How adorable!")
About every 5 years I am picking up the latest languages that have survived the fashion-burnout because it's what Employers are looking for.
~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
I started with C in 1981, and used that (with a side-trip to Pascal) till about 1998, at which point I started tinkering with Perl. I have used Perl solidly since then, but just downloaded Go this week and started to tinker with that. So Go could be by next language. Who knows.
I routinely work on iOS (Swift, ObjC, some C), Android (Java, some C/C++), Xamarin (C#), Java Server, and .NET server. Lately we've been using Swift 3 server for some POCs. On the mobile side, you have very limited choices.
You can do native, which means Java on Android and Objective-C and Swift on iOS. You can do compile-to-native, which for me is C# on Xamarin, compiled to the native languages (C on iOS and C#Mono to JNI to Dalvik on Android) You can do Web-UI or Pseudo-UI with tools that work off Javascript such as Phonegap, Fiori, Titanium.UI, etc, but these generally lead to poor user experience.
On the server side, your choice is generally dictated by whatever the architect who designed it decided in the beginning (if you are lucky, this was you). Everyone comes in and wants to rewrite the ancient thing that sits on the backend, but it's often not worth it. I love J2EE but it's not what I'd recommend today for a new project. We're actively exploring Swift on the server, but it's not really production ready yet and won't be until the fall at least.
- Vincit qui patitur.
Once someone learns basic concepts, such as if..then..else, loops, pointers, and recursion for example, many programming language skills come down to syntax, libraries, and debugging. I jumped from programming COBOL for 15 years to C, C++, and Java without any issues, so I'd guess that someone who is a decent developer to begin with shouldn't have too much of a problem shifting gears to most other languages. I've also worked in a smattering of other languages (PL/I, FORTRAN) and far too many '3rd generation' tools. I even once modified code for a proprietary language I didn't even have a manual for.
Logic, pointer theory, and spatial relationships are probably the hardest things for anyone to understand. Those that can comprehend basic logic constructs and are able to 'see' code in their head can probably easily shift from language to language with ease. Those that struggle with any language probably will have a difficult time picking up new ones.
I think the biggest deterrent to learning new languages today isn't syntax or how the language works, it's the libraries and associated debugging skills. I had far more trouble learning C, C++, and Java libraries than I did learning the actual language. Modern IDEs make it a bit easier with predictive typing and on-screen syntax checking. But trying to figure out how to read a file or output to the screen can be extremely difficult in some languages because of all the possible options with all of the different libraries. Fortunately, anyone skilled in Google can usually find code examples rather quickly.
And then there is debugging, which I think is still an art. Many years (decades??) ago, I had a developer come to me with a persistent bug he couldn't fix. After he explained it to me, he started to show me the code. I stopped him, and told him to go look at a specific part of the program, he was missing a period. He thought I was pulling his leg, but left and came back shortly and asked how I knew what the problem was without even looking at the code. I remember saying to him 'Scott .. the only difference between you and me is I've already made that mistake several times'. Debugging, like libraries, in any language takes significant experience to get good at.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
My primary work product is a C/C++ manufacturing process-control application with bits of Lua and Perl embedded in it. Surrounding it are some web services, which I generally write in Python and Perl, with the front-ends obviously in Javascript.. There are some backend data-crunching services that process XML, and I've written those in Java.
A totally separate media-oriented project is a spitball of shell scripts, Perl, Javascript, and C, which I'm slowly replacing with Python, C++, Javascript, and Go. It's less a case of tossing the old code to replace it with something nifty and more the case of refactoring the code into a better-fitting implementation, now that we have a decade or so of use-cases to reflect upon.
I used to be a "C or GTFO" sort of guy until I realized how much time I was wasting by reimplementing hash tables and B-trees wherever I needed them. Python and Perl are decidedly Not Fast, but if they don't have to be fast, I can save a lot of stress and reduce the technical debt of code maintenance by writing the program in something where the problem domain fits better idiomatically. Sure, Java is annoying, but if you need to fan-out a couple hundred threads of data crunching, and your source data and results are in XML, the only thing that might fit better is C#.
I once read the suggestion to learn a new programming language every year. Do this. Get past "Hello, World," and at least solve toy problems. If you came from C, your whole world will change when you "get" map. If you came from Javascript, you'll have a whole new appreciation for the machine when you grok pointers. Try writing a piece of code in a functional style in a nonfunctional language (especially C) and discover how the language works against you and your resulting code is woefully inefficient.
Then, you'll be in a great position to embrace whatever tools you find and select the best one for the task at hand.
Pining for the days when The Glorious MEEPT!!! graced SlapDash with his wisdom.
I enjoy programming and have gotten to the point where I can pick up and start home projects on a whim. Normal workdays usually involve Python, maybe JavaScript and a heavier language, usually C/C++ or Java, now Scala. Of course build system DSLs are a plenty: make, cmake, autotools, pants, scons, etc. When I home I pick a personal project, with the language depending on the use case. Things that can possibly see the light of day get prototyped in Python. Experiments are usually Lisp or something new that helps solve the issue. Actual code I'm trying to release is Java for Android, C++ for performance, and Vala for home libraries which compiles to C.
WHY would anybody switch languages?
I never have. I just learn new ones as needed. Glad to see I'm not alone and all common sense has not departed this site.
I still have unused punch cards in a box around here some place, I used to keep a paper tape in my drawer as a reminder of how easy things have become.
I've coded assembly for more processors than I can recall, written in FORTRAN, COBOL, BASIC, C, C++, C#, RPG, Forth, Pascal, Modula-2, Python, Java, JavaScript, and probably others I forgot to name. I expect to learn more over the years ahead and will love or hate the new ones as appropriate, though I must confess that while I found C# interesting, I'm not that impressed by most of the post C++ stuff.
At their core, they are all the same: just a human-friendly wrapper for standard low-level concepts that can be implemented in assembler if needed. The point is to understand how computers actually work, down on the metal. Everything else is just fluff. I use some OOP concepts even in assembly - even did coding in a structured version of assembly using a tool called SALUT on an 8MHz PC back in the 1980s. It's all just keywords and syntax, and what's available for a particular platform, and what other members of any team for any project are willing/able to use. I'm every bit as comfortable with a bloated IDE as with a text editor and command line. Toggle switches and LEDs are still fine for me.
I presume you're in a similar spot. I'm always dismayed when a younger programmer gets all wrapped-up in a particular language or fad - they just don't seem to get it at all. Above the ones and zeros it's all just wallpaper.
For me learning the language is only about 15% of the cost. The rest are learning the tool chain, best practices, and above all the usage of the available libraries or class libraries. I'll be nearly any competent C programmer can switch to Java faster than they can make the transition from GtK to Swing.
I'm not a developer or programmer in any sense of the words, but I got tired of writing things like shell/batch scripts as a system admin years ago and tried learning Python (I also tried Ruby and Lua). I just needed something that I could standardize on for automating and monitoring regular system tasks and parsing text or modifying data to move from one application to another. I needed something that I could write once on any system (logic structure) and quickly modify to run on any other system. Python fit the bill and was very easy to learn. Since I'll probably never develop full fledged applications, I'll most likely stick with Python for the foreseeable future. Why tax my brain on another language when I learn more and more about Python and it works perfectly for what I need to accomplish?
MANMAN software On HP's MPE/iX 7.5
Tracy Johnson
Old fashioned text games hosted below:
http://empire.openmpe.com/
BT
I switch programming languages all the time: half the time I'm writing code in C#, the other half the time I'm writing code in javascript. I jump between them frequently, even in the same project! :p [/totally not what you meant]
Bullshit
Try scientific computing with Erlang. Can it be done? Sure. Will it be more efficient in both developer and run time over a scientific language? Fuck no.
Try massively distributed computing with C or Matlab. Can you do it? Sure. Will it be more efficient in both developer and run time? Fuck no.
There are languages that are not only more suited but completely more competent in certain domains than others.
How often so you want to get fired because you don't program on your own time?
Answer: Every job until you stop getting offers because you fell behind.