Ask HN: How do you switch between programming languages?
67 comments
I think this is something you naturally get better at. You start to resize that languages have similar ideas, but different representations.
Is this a problem that is having a significant impact, or just an annoyance?
If you aren’t using an IDE, then you definitely should start. Any good IDE for the languages you mentioned will provide lots of help with incorrect syntax. Be sure you have it properly configured so that it can give you as much help as possible.
I program in many different languages and I always have to search for things when switching to one I haven’t used recently. I view this not as a bad thing. Google exists for this very purpose, and there isn’t too much benefit to intentional memorization.
Lastly, the book The Programmers Brain touches on how to remember syntax among other things. It might be useful.
Is this a problem that is having a significant impact, or just an annoyance?
If you aren’t using an IDE, then you definitely should start. Any good IDE for the languages you mentioned will provide lots of help with incorrect syntax. Be sure you have it properly configured so that it can give you as much help as possible.
I program in many different languages and I always have to search for things when switching to one I haven’t used recently. I view this not as a bad thing. Google exists for this very purpose, and there isn’t too much benefit to intentional memorization.
Lastly, the book The Programmers Brain touches on how to remember syntax among other things. It might be useful.
For OP, I switch between Java, Ruby, python, bash, read scala, rust, Haskell, go…
And the advice here in this comment chain is spot on:
1. Know the underlying concepts, all programming languages are “same” after awhile (ex: object.prop, function calls, global vs non-globals, lambdas/anon funcs.
2. Use a compiler and or linter to catch syntax errors and don’t worry about memorizing it - knowing how to read the output/error msg and solving the issue is more important
And the advice here in this comment chain is spot on:
1. Know the underlying concepts, all programming languages are “same” after awhile (ex: object.prop, function calls, global vs non-globals, lambdas/anon funcs.
2. Use a compiler and or linter to catch syntax errors and don’t worry about memorizing it - knowing how to read the output/error msg and solving the issue is more important
Same here, different set of 8 or so languages I cycle through. I stopped caring. From time to time I'll make a silly mistake like using "def" in rust instead of "fn". The highlighter or the compiler will shout at me, I'll fix it and move on.
Two things I forgot to add. Most programming languages have ‘linters’. Linters analyze syntactically valid code for mistakes of different types. Mistakes can be something like you forgot to use a variable you created, to you’re performing some operation incorrectly.
Linters are useful in general, but in your case they can help you write better code when you aren’t as familiar with the language. Go has a project called golangci-lint, while TypeScript has eslint.
The second thing is code formatters. Every language has its own formatting style, so it can be nice to have a program that does the formatting for you. Go has gofmt, and TS has Prettier (among others).
These tools add some complexity, but if you set these up you’ll have some extra guard rails as long as you remember to run them, or even better run them as a GitHub Action.
Linters are useful in general, but in your case they can help you write better code when you aren’t as familiar with the language. Go has a project called golangci-lint, while TypeScript has eslint.
The second thing is code formatters. Every language has its own formatting style, so it can be nice to have a program that does the formatting for you. Go has gofmt, and TS has Prettier (among others).
These tools add some complexity, but if you set these up you’ll have some extra guard rails as long as you remember to run them, or even better run them as a GitHub Action.
I program professionally in C, Python and Javascript.
Instead of starting with a empty file, I copy an existing file in the language that I'm using. Simply by seeing examples of syntactically correct code, I assimilate. It's only a 90% solution. For example using single quotes on strings in C and putting a ';' at the end of lines tends to creep into my Python code.
Instead of starting with a empty file, I copy an existing file in the language that I'm using. Simply by seeing examples of syntactically correct code, I assimilate. It's only a 90% solution. For example using single quotes on strings in C and putting a ';' at the end of lines tends to creep into my Python code.
Why not use double quotes for strings in all languages? It makes sense for a number of reasons. Single quotes are much more likely to be in the contents of a string than double quotes.
Of course, if you have a style guide, you should stick to that.
Of course, if you have a style guide, you should stick to that.
In some languages double quotes have different meaning to single quotes, for example in shell variables expand inside double quotes but not inside single. So you need to know which your current language uses.
I've gotten used to duckduckgo for even basic things for the first few hours after picking up a language I didn't use for a while. Here are some examples of things I searched for: "rust join two iterables", "rust impl sum", "rust tokio select macro", "rust impl bitand for bool", "rust convert pathbuf to path", "rust join paths", "rust check if file exists", "rust tuple windows", "rust rand gen_range", "rust generate n random numbers", "rust system exit".
Then there are the small differences where trial-and-errors + immediate IDE feedback give me the answer. For example, is it 'len(foo)' or 'foo.len()?' Is it 'int foo' or 'foo: int'? Is it 'let foo = ...' or just 'foo = ...'?
The more you code, the better you get at 1) adapting faster, 2) accepting that you need to "land". "Landing" can take hours or days, if you measure by how simple things you have to search for.
Your two concrete examples are "dangerous syntax"; another one (although not language-specific) is forgetting to close a parenthesis: They're the kind of errors that give poor error messages in many languages, and so take unproportionally long to debug considering how banal the mistake is. I think that over time, you learn to be more careful in the places where you've wasted the most time.
Then there are the small differences where trial-and-errors + immediate IDE feedback give me the answer. For example, is it 'len(foo)' or 'foo.len()?' Is it 'int foo' or 'foo: int'? Is it 'let foo = ...' or just 'foo = ...'?
The more you code, the better you get at 1) adapting faster, 2) accepting that you need to "land". "Landing" can take hours or days, if you measure by how simple things you have to search for.
Your two concrete examples are "dangerous syntax"; another one (although not language-specific) is forgetting to close a parenthesis: They're the kind of errors that give poor error messages in many languages, and so take unproportionally long to debug considering how banal the mistake is. I think that over time, you learn to be more careful in the places where you've wasted the most time.
Thanks to having too many jobs/responsibilities, I currently am switching multiple times daily between Rust, Typescript, Dart, Python, and sometimes, god forbid, C/C++. Usually at a moments notice, because a lot of times I'm writing FFI between those languages so it's multiple at the same time.
I just fuck up in small ways, a lot, and accept that I'm gonna do so thanks to context switching. func/function/fn, var/let/auto/wait I don't even have inference in this language, etc. It just happens, and there's some idiom bleed too.
Luckily IDEs are usually real fast to squiggly red line things now and boot me back into whatever the current context is going to be, and for the code I get reviews on, idiom bleed can be called out.
I just fuck up in small ways, a lot, and accept that I'm gonna do so thanks to context switching. func/function/fn, var/let/auto/wait I don't even have inference in this language, etc. It just happens, and there's some idiom bleed too.
Luckily IDEs are usually real fast to squiggly red line things now and boot me back into whatever the current context is going to be, and for the code I get reviews on, idiom bleed can be called out.
I switch between Ruby and C++ frequently. My trick, which I admit is complete unplanned fluke, is different IDEs. Sublime for Ruby and XCode for C++. They look so different that my brain just disregards the other language. I briefly tried Ruby in XCode and nothing made any sense.
Assuming you don't want to install multiple editors, perhaps different colour schemes might produce something similar in your brain.
Assuming you don't want to install multiple editors, perhaps different colour schemes might produce something similar in your brain.
I move between 4 different languages depending on what I'm working on.
I would only say I'm an advanced-to-expert user of one of them. The others I'm just an intermediate user.
When switching languages there's always a period of about 10 minutes where I'm adjusting to the syntax. Then there's a period of up to a few hours to get my head back into the correct space. For example, moving to a functional language like Erlang requires me a bit longer to get comfortable again.
I've pretty much always got the docs open when I move over to my less comfortable languages for the first few days.
I would only say I'm an advanced-to-expert user of one of them. The others I'm just an intermediate user.
When switching languages there's always a period of about 10 minutes where I'm adjusting to the syntax. Then there's a period of up to a few hours to get my head back into the correct space. For example, moving to a functional language like Erlang requires me a bit longer to get comfortable again.
I've pretty much always got the docs open when I move over to my less comfortable languages for the first few days.
Unfortunately it just takes time until switching becomes easy/natural.
I write Typescript at work atm (quite unfortunate, in the process of campaigning for something more suitable) but program all of my personal projects in a combination of Java/Kotlin or Rust. Previously I wrote Java/Kotlin professionally and still maintain some OSS and personal projects in Python, Perl and Ruby despite not using those languages regularly anymore.
I would say the tougher part is if you need to switch IDEs. I was originally doing Typescript in IntelliJ which was fine but after needing to adopt Visual Studio Code for team alignment reasons it's more annoying to switch, not because of syntax but because of keyboard shortcuts and IDE capabilities I'm used to.
So I guess I would suggest using a common IDE if you can but otherwise it will just come with time.
I write Typescript at work atm (quite unfortunate, in the process of campaigning for something more suitable) but program all of my personal projects in a combination of Java/Kotlin or Rust. Previously I wrote Java/Kotlin professionally and still maintain some OSS and personal projects in Python, Perl and Ruby despite not using those languages regularly anymore.
I would say the tougher part is if you need to switch IDEs. I was originally doing Typescript in IntelliJ which was fine but after needing to adopt Visual Studio Code for team alignment reasons it's more annoying to switch, not because of syntax but because of keyboard shortcuts and IDE capabilities I'm used to.
So I guess I would suggest using a common IDE if you can but otherwise it will just come with time.
Before I start working on a project, I spend a couple of minutes to read and understand the logic of the current code base related to the change. By doing this, it naturally reminds me about the language syntax, the framework, the project convention, and the team's best practice. If you do it regularly, you will feel it more natural. Most of the modern languages' projects are easy to identified the scope of changes. Don't pay too much attention to the languages syntax, but rather to the logic.
I have done +12 langs and who knows how many data formats, sql/dsl dialects and all that.
One simply trick I do is use different Editors/IDEs for each lang, with distinct themes.
So for example, I associate work on python with Sublime, json/js with VS Code, Rust with IntelliJ, Android with Android Studio (yes, I know I could do both in IntelliJ!), Swift with Xcode.
It super handy this way because one big trouble of do all in the same UI is that "switch" bring everything at once, instead when all is their focused UI have things side-by-side with different themes/fonts let everything be distinct.
Weirdly, I can't like the same theme/font across everything, I suppose some stuff look nicer here than there :)
One simply trick I do is use different Editors/IDEs for each lang, with distinct themes.
So for example, I associate work on python with Sublime, json/js with VS Code, Rust with IntelliJ, Android with Android Studio (yes, I know I could do both in IntelliJ!), Swift with Xcode.
It super handy this way because one big trouble of do all in the same UI is that "switch" bring everything at once, instead when all is their focused UI have things side-by-side with different themes/fonts let everything be distinct.
Weirdly, I can't like the same theme/font across everything, I suppose some stuff look nicer here than there :)
I currently switch between Go, Rust, Python, Java and Kotlin pretty regularly.
One minor thing that helped a lot was to have custom IDE settings for each (different code fonts, different background colours, etc.).
I found it helped get into the mindset of a language a bit quicker by having them differentiated (e.g. I can switch to window and know what language I'm dealing with without having to read any code).
One minor thing that helped a lot was to have custom IDE settings for each (different code fonts, different background colours, etc.).
I found it helped get into the mindset of a language a bit quicker by having them differentiated (e.g. I can switch to window and know what language I'm dealing with without having to read any code).
For some reason this isn’t an issue with me. Past month I’ve been writing C#, Python, and Lua pretty much equally.
While I do sometimes almost write “nil” instead of “None” in Python, it’s rare enough not to be an issue.
Maybe it helps that I also use three human languages in my daily life, and mixing up words just isn’t something that happens (although forgetting does).
While I do sometimes almost write “nil” instead of “None” in Python, it’s rare enough not to be an issue.
Maybe it helps that I also use three human languages in my daily life, and mixing up words just isn’t something that happens (although forgetting does).
I code in java, golang and python, with occasional forays into terraform, SQL, JS, C and other bits and pieces.
For my main three, these days I use the jetbrains IDEs, and they are helpful enough that I tend to switch mode fairly quickly with their suggestions.
Back when I used to use gedit with a shell open underneath for basically everything, it was a bit harder. I was mostly coding in C and C++ then, and python felt really different and was harder to flip into.
That said, the more frequently you do these sorts of context switches, the better you're likely to get at them.
For my main three, these days I use the jetbrains IDEs, and they are helpful enough that I tend to switch mode fairly quickly with their suggestions.
Back when I used to use gedit with a shell open underneath for basically everything, it was a bit harder. I was mostly coding in C and C++ then, and python felt really different and was harder to flip into.
That said, the more frequently you do these sorts of context switches, the better you're likely to get at them.
Speaking several languages, shifting mindset helps. There's a sort of caricature, a mixture of traits in the mind that helps to shift to Nordic versus central or southern European languages, where imagining the demeanour and cultural sensibilities of a particular country or group of speakers helps to shift character and hence language. For instance, by imagining a stereotypical French person, it helps me to switch language without too much effort, and funnily enough, my behavioural attitudes and view on life experience a very slight shift too by switching language; you tend to see things a bit differently.
While it might not help with something as specific as semicolons, the same shift helps to focus on typical solutions in the problem space for that particular language. I'm more likely to install dependencies and use classes in Python than Go, or try functional programming paradigms in Javascript. Switching archetypes somehow helps to switch paradigms and dialects of even similar languages.
Where it goes wrong though is to be thrown as a consultant in several different projects at a time, where different code bases use different styles – such as semicolon versus no-semicolon Javascript. I've come to rely on tooling for those things, which is likely the best solution anyway when a project has a lot of different or external contributors. In the grand scheme of things, and especially these days, it's OK to rely on the computer telling you it didn't quite get something because you missed a semicolon, and to focus on the higher logic as a human being.
While it might not help with something as specific as semicolons, the same shift helps to focus on typical solutions in the problem space for that particular language. I'm more likely to install dependencies and use classes in Python than Go, or try functional programming paradigms in Javascript. Switching archetypes somehow helps to switch paradigms and dialects of even similar languages.
Where it goes wrong though is to be thrown as a consultant in several different projects at a time, where different code bases use different styles – such as semicolon versus no-semicolon Javascript. I've come to rely on tooling for those things, which is likely the best solution anyway when a project has a lot of different or external contributors. In the grand scheme of things, and especially these days, it's OK to rely on the computer telling you it didn't quite get something because you missed a semicolon, and to focus on the higher logic as a human being.
Editor support can really help with transitioning.
I write C++, Matlab, python, and bash all with regilarity, and eventually your brain separates out the sytanx for each one.
This sums up nicely exactly what I was going to say. A solid editor helps me transition if I've been thinking in a different language.
I lean heavily on syntax highlighting and linters that run inline. In VSCode I get eslint warnings as I type, reminding me of the rules of the language. In Xcode I get inline warnings in my Swift code but it takes an eternity, and sometimes a rebuild (iOS development can be a miserable experience).
That said, I used to write Kotlin and to this day I still occasionally, mistakenly use its syntax when writing Swift. I may not be the best one to provide advice.
That said, I used to write Kotlin and to this day I still occasionally, mistakenly use its syntax when writing Swift. I may not be the best one to provide advice.
It may seem silly, but I try to use different IDEs, editors or at least different colour schemes for different languages. Currently that generally means XCode for C++, VSCode for javascript (current main two) & Sublime Text for everything else. Helps me mentally context switch just that little bit quicker, though luckily the syntax isn’t all that “close” as you put it.
You'll get used to it the more you practice. Give it a few years, you'll hardly notice it. Also it helps that you don't fall into the trap of "one IDE for all programming languages", like the evangelists of VSCode plugins and/or vim preach out there.
Keep each programming language with its classical IDE, the more visually different one another is the easy the switch is.
For example I use Zend for PHP, Delphi for Object Pascal, Visual Studio for C# and for rare occasions I need same Visual Studio for C++ I have it differently configured both with colors and with menus arrangements to be strongly different than the C# one. Also I employ the strategy of each project in its own virtual machine. Nothing runs in the host OS, everything is in virtual machines.
Having this kind of development process is very easy to switch to that part of my brain dealing with that programming language, even when multiple virtual machines are running and I am switching between them.
Hope this helps and good luck.
Keep each programming language with its classical IDE, the more visually different one another is the easy the switch is.
For example I use Zend for PHP, Delphi for Object Pascal, Visual Studio for C# and for rare occasions I need same Visual Studio for C++ I have it differently configured both with colors and with menus arrangements to be strongly different than the C# one. Also I employ the strategy of each project in its own virtual machine. Nothing runs in the host OS, everything is in virtual machines.
Having this kind of development process is very easy to switch to that part of my brain dealing with that programming language, even when multiple virtual machines are running and I am switching between them.
Hope this helps and good luck.
> it helps that you don't fall into the trap of "one IDE for all programming languages"
I don't see this as a trap at all. I use IntelliJ for practically everything, and switching languages frequently (currently between Typescript and Scala several times a day) has not been difficult. I get way more benefit from developing increased familiarity with my environment.
I don't see this as a trap at all. I use IntelliJ for practically everything, and switching languages frequently (currently between Typescript and Scala several times a day) has not been difficult. I get way more benefit from developing increased familiarity with my environment.
I always find this to be handy: https://learnxinyminutes.com/
It is useful as a cheat sheet.
In addition: if you have experience in multiple "imperative" language (read: non-functional / non-prolog / etc) it's easy to pick up another language using that site alone.
It is useful as a cheat sheet.
In addition: if you have experience in multiple "imperative" language (read: non-functional / non-prolog / etc) it's easy to pick up another language using that site alone.
> I am an amateur developer
Nowadays I mostly work with Java, Node.js (JavaScript/TypeScript) and Rust. I have been programming professionally for about 15 years, and I have been paid for work in C++, C#, Python, PHP in the past, not to mention a gazillion languages that I used on my side projects.
> I find it difficult to switch between the grammar of the languages
I have similar issues that you describe (wasting a few minutes, in my case, because of some syntax error) if I start off from an empty file or if a few days have passed from the last time that I used a certain tech. If I am continuing work on an on-going project I first do smaller tasks in existing codebase to get "into it", If I am starting a new project I sometimes copy an old one to get started and I edit it (delete most of the code, modify the config etc.)
Also, a lot is gained if you make yourself aware that you just switched to a different tech.
Obviously (is it?) I use an IDE and that helps _a lot_.
Nowadays I mostly work with Java, Node.js (JavaScript/TypeScript) and Rust. I have been programming professionally for about 15 years, and I have been paid for work in C++, C#, Python, PHP in the past, not to mention a gazillion languages that I used on my side projects.
> I find it difficult to switch between the grammar of the languages
I have similar issues that you describe (wasting a few minutes, in my case, because of some syntax error) if I start off from an empty file or if a few days have passed from the last time that I used a certain tech. If I am continuing work on an on-going project I first do smaller tasks in existing codebase to get "into it", If I am starting a new project I sometimes copy an old one to get started and I edit it (delete most of the code, modify the config etc.)
Also, a lot is gained if you make yourself aware that you just switched to a different tech.
Obviously (is it?) I use an IDE and that helps _a lot_.
I find that the more languages I learn, the easier it becomes to switch between them.
Each language's syntax depends on the design choices of that language, and the wider your knowledge, the better "feeling" you have for why does a language use a certain syntax, and switching between them starts coming naturally.
Each language's syntax depends on the design choices of that language, and the wider your knowledge, the better "feeling" you have for why does a language use a certain syntax, and switching between them starts coming naturally.
As everyone says, time. With time, programming languages become like speech since they use the same area of the brain [1]
[1] https://medicalxpress.com/news/2020-06-language-brain-scans-...
[1] https://medicalxpress.com/news/2020-06-language-brain-scans-...
At your stage I think switching too much can be detrimental. You are still learning and getting familiar with both the craft itself and the languages.
The same goes for tooling, frameworks, and libraries.
You probably want to have extended deep focus on as few "things" at a time as you can afford now, given that you are experiencing issues.
Look up spaced repetition and other techniques - IME much of what goes for learning human languages apply to programming languages as well.
Just like it's counterproductive to start taking beginner classes in French, German, and Spanish at the same time... Get to base level with one and then adding more gets a lot easier.
Over time, as you get practice, code switching will become second nature, especially if you do it more. I might be even advice more senior devs to do more of what you should do less of right now, if that makes sense.
The same goes for tooling, frameworks, and libraries.
You probably want to have extended deep focus on as few "things" at a time as you can afford now, given that you are experiencing issues.
Look up spaced repetition and other techniques - IME much of what goes for learning human languages apply to programming languages as well.
Just like it's counterproductive to start taking beginner classes in French, German, and Spanish at the same time... Get to base level with one and then adding more gets a lot easier.
Over time, as you get practice, code switching will become second nature, especially if you do it more. I might be even advice more senior devs to do more of what you should do less of right now, if that makes sense.
I think this is a cognitive problem that people either suffer together with you in the same boat without a clear solution, or else: "what are you talking about; I use four different languages with deceptive similarities in an average workday and have never had any issues".
Like "do you have any tricks to better distinguish red and green color?"
You have to become an expert in the tools you're using. Study the languages in depth at their specification level, not just tutorials.
If you know several languages well enough to write parser almost entirely from memory, and you still get mixed up when switching between them, then it's down to some cognitive difference between you and people who don't have that problem. Maybe some mild form of dyslexia or something along those lines.
Like "do you have any tricks to better distinguish red and green color?"
You have to become an expert in the tools you're using. Study the languages in depth at their specification level, not just tutorials.
If you know several languages well enough to write parser almost entirely from memory, and you still get mixed up when switching between them, then it's down to some cognitive difference between you and people who don't have that problem. Maybe some mild form of dyslexia or something along those lines.
Do you have any tricks/hacks to make the switch easier?
Your brain will stay confused until it learns language “instincts” to the level when you just know how to write in it and don’t have to think about it, like riding a bike. This only comes with experience, ime. I’d advise you to isolate your time more, e.g. a week in go, another week in ts, to allow experience to sink in and form two distinct “wells”, but not sure if that’s actually required or feasible.
I also like a comment about having different IDEs. I’m using a similar technique for ssh and rdp, where critical servers have a distinct background or prompt, so I don’t fool around when it screams production A or production B.
I still can see specific colors when thinking about C (08), BASIC (18) and Pascal (1E).
Your brain will stay confused until it learns language “instincts” to the level when you just know how to write in it and don’t have to think about it, like riding a bike. This only comes with experience, ime. I’d advise you to isolate your time more, e.g. a week in go, another week in ts, to allow experience to sink in and form two distinct “wells”, but not sure if that’s actually required or feasible.
I also like a comment about having different IDEs. I’m using a similar technique for ssh and rdp, where critical servers have a distinct background or prompt, so I don’t fool around when it screams production A or production B.
I still can see specific colors when thinking about C (08), BASIC (18) and Pascal (1E).
No tricks or tips, but your post reminded me of a professor I had in undergrad. My man had been in computer science since before the name was invented... he started out as an aeronautical engineer (worked on the B-52 and Boeing 707, which were fascinating stories in their own right), and got into computing through some of the early aeronautical simulation work.
He was well-known for starting to illustrate something in Java or C (or whatever the nominal language for the class was), then, about 5 whiteboards later, he'd be writing in Lisp or FORTRAN, then go back to Java to wrap it up.
Awesome professor, though. Language wandering aside, he gave some of the clearest explanations I've ever encountered.
He was well-known for starting to illustrate something in Java or C (or whatever the nominal language for the class was), then, about 5 whiteboards later, he'd be writing in Lisp or FORTRAN, then go back to Java to wrap it up.
Awesome professor, though. Language wandering aside, he gave some of the clearest explanations I've ever encountered.
I program Java and javascript for money and a mix of APL, BQN, J, emacs lisp, and clojure for fun.
The biggest challenge is switching from one array language to another, they are very similar but have subtle differences that I forget. Mostly because I am still not proficient at any of them.
Switching between a mainly imperative OOP langauge to a functional language is always very smooth, especially since my preference is lisp so the syntax and patterns are completely different, although modern Java has taken on a lot of functional goodness.
But I never really think about the switch, it has all become second nature to me.
I never thought about it but maybe it is related to being multi-lingual? E.g. I can switch between Danish and English no problem as well.
The biggest challenge is switching from one array language to another, they are very similar but have subtle differences that I forget. Mostly because I am still not proficient at any of them.
Switching between a mainly imperative OOP langauge to a functional language is always very smooth, especially since my preference is lisp so the syntax and patterns are completely different, although modern Java has taken on a lot of functional goodness.
But I never really think about the switch, it has all become second nature to me.
I never thought about it but maybe it is related to being multi-lingual? E.g. I can switch between Danish and English no problem as well.
First off, don’t get discouraged by it, it happens to us all. I have 30 years of professional programming experience and I’ve used a dozen languages in depth and I find myself googling language syntax if I’ve been away from a language for a few months. Particularly “for” loops—they vary a lot between languages and it’s hard to remember which syntax any one language uses.
If you have a decent editor it should mark syntax errors as you type which is super helpful. I’ve absent mindedly typed “func” when I meant “fn” or “function” countless times and seeing it not get highlighted correctly or having the next line indented incorrectly usually tips me off before I run/compile it.
If you have a decent editor it should mark syntax errors as you type which is super helpful. I’ve absent mindedly typed “func” when I meant “fn” or “function” countless times and seeing it not get highlighted correctly or having the next line indented incorrectly usually tips me off before I run/compile it.
While I switch relatively effortlessly between programming languages, the problem does indeed exist. I try not to switch between languages in the same day... or at least, not too many times... OK, who am I kidding, at least not every half an hour.
I think you should just spend a significant amount of time in both languages and over time you’ll be all good.
I programmed in JS for a year before picking up python. I would struggle with python’s syntax for a while but over time it just worked out. Same thing now with clojure.
I think it’s the same as being bilingual. Your brain just switches effortlessly given enough practice
I programmed in JS for a year before picking up python. I would struggle with python’s syntax for a while but over time it just worked out. Same thing now with clojure.
I think it’s the same as being bilingual. Your brain just switches effortlessly given enough practice
The problem is that you're a self-described amateur and as such have difficulty thinking at a level above the language that you are working in. As you get better, you will begin to understand that they're all very slightly different ways of doing basically the same thing and will come to think of things either at a much higher or lower level, depending on what you're doing.
The language is never important... it's an implementation detail and something that you pick based what is best for the job, library support etc. Software engineering principles are universal.
The language is never important... it's an implementation detail and something that you pick based what is best for the job, library support etc. Software engineering principles are universal.
I do not code professionally but have been doing it for 30 years or so, across a few languages.
It is not the software engineering that is the problem, it is context switching.
It is not the software engineering that is the problem, it is context switching.
I switch between several languages, depending on my project role, and whatever I happen to do as hobby coding.
It comes with time, you get used to switch context, and to ignore the speed bump that occurs when switching.
Additionally getting some quick references for the languages, or personal notes, helps a lot.
Then you only need to search for concepts like "open a file" get the snippet and hop into the next problem.
Naturally the "Jake of all trades, master of none" does apply to some extent, but what matters is delivery, pretty code that isn't delivered doesn't help business.
It comes with time, you get used to switch context, and to ignore the speed bump that occurs when switching.
Additionally getting some quick references for the languages, or personal notes, helps a lot.
Then you only need to search for concepts like "open a file" get the snippet and hop into the next problem.
Naturally the "Jake of all trades, master of none" does apply to some extent, but what matters is delivery, pretty code that isn't delivered doesn't help business.
Use a linter, a formatter or any other tool that complains early and often.
Have a starting setup for each programming language. Being surrounded by a supporting environment helps. You don't have to start with a blank document in a dumb editor.
Pick an IDE that you like. I really like PyCharm but vscode is also quite great.
To that extend you might even go further and have some specific visual clues per programming language. Whether that's different editors, editor profiles / themes depends on you.
Pick an IDE that you like. I really like PyCharm but vscode is also quite great.
To that extend you might even go further and have some specific visual clues per programming language. Whether that's different editors, editor profiles / themes depends on you.
There are plugins for vim/emacs/vscode to aggressively lint/highlight various errors as you type and/or save.
Since two of the languages you've mentioned are compiled, they should be giving you specific line/column/error information on syntax errors. If it's taking you a day to de-cipher explicit error reports from the compiler, it's probably time to better familiarize yourself with compiler lingo (most people recommend "the dragon book").
Since two of the languages you've mentioned are compiled, they should be giving you specific line/column/error information on syntax errors. If it's taking you a day to de-cipher explicit error reports from the compiler, it's probably time to better familiarize yourself with compiler lingo (most people recommend "the dragon book").
Considering he’s an amateur programmer I doubt he wants to delve into compilers, which is a hard topic even for CS students.
With that being said it is a great thing to know, but likely unnecessary unless you’re very serious about programming.
With that being said it is a great thing to know, but likely unnecessary unless you’re very serious about programming.
Didn't tell him to write one from scratch. Just suggested boning-up on the lingo: grammars, tokens, lexing, parsing, etc. An understanding of the first 2-3 chapters would be more than sufficient.
Getting a firm grasp on such things made every language I deal with "click". Knowing how the sausage is made--if only at the kindergarten field-trip level--brings all of the trade-offs language designers have to make into relief. With this knowledge, you'll know where the sharp corners are to begin with--the ones that were unavoidable due to the limitations of the medium. This is much better than beating one's head against the wall over a syntax error while being pissed at the language for not being a miracle.
Getting a firm grasp on such things made every language I deal with "click". Knowing how the sausage is made--if only at the kindergarten field-trip level--brings all of the trade-offs language designers have to make into relief. With this knowledge, you'll know where the sharp corners are to begin with--the ones that were unavoidable due to the limitations of the medium. This is much better than beating one's head against the wall over a syntax error while being pissed at the language for not being a miracle.
I agree that this is a great thing for any serious programmer to do. It depends on the person though. Someone that codes for fun would not want to spend any amount of time in a compiler text.
What helps a lot is proper IDE support for your language; it will correct you when you type the wrong thing.
Other than that, I think it's just a matter of experience. The more you use them, the more you switch, the easier it gets.
I recently had to switch to Java after years of mostly doing js and typescript, and though I'd done lots of Java in the past, it was a frustrating experience because there are a lot of things that ts/js just do better than Java.
Other than that, I think it's just a matter of experience. The more you use them, the more you switch, the easier it gets.
I recently had to switch to Java after years of mostly doing js and typescript, and though I'd done lots of Java in the past, it was a frustrating experience because there are a lot of things that ts/js just do better than Java.
Wait you spend a day pondering over an extra colon? Shouldn't that be a syntax error anyway? In general it's probably best to stick to one or two languages until you feel sufficiently proficient at programming in general instead of just accumulating low value knowledge about various syntaxes specially so for languages with gnarly syntax like Go.
Give it some time. I don't think there is any trick here beside experience.
Go and TS(js\java\c++ etc) may look similar now but they won't after some time.
Go and TS(js\java\c++ etc) may look similar now but they won't after some time.
I relay on Autohotkey string replacements. For example, it drives me insane how every language has to have its own syntax for simple string operations. Is it SUBSTRING? SUBSTR? 1-based? 0-based? etc. So I create my own .substr hotkey, that then outputs the variants, and sometimes is even context sensitive to the file type I am in.
a) keep doing it
b) try to do work in different languages in blocks, and don't switch in between all the time
c) keep doing it
d) nobody wants to hear that, but .. keep doing it.
I program in more languages that I care to enumerate and some are just so in-grained in me that I don't make mistakes with 'close' naming. I'd be more efficient in a single language if I only programmed in that, true, but I think I'm more efficient overall because I bring a wide variety of solution sketches with me that can be applied depending on scope and primary, secondary, tertiary (and more) concerns. Once you have the first half-dozen to dozen languages under your belt, ideally with different paradigma (OO, FP, logic, old-school structural/procedural, bare-metal, VM/script) the next dozen dozen will be a piece of cake and your biggest problem is the warm-up of the language keyword and stdlib name cache. Hence b), above.
I program in more languages that I care to enumerate and some are just so in-grained in me that I don't make mistakes with 'close' naming. I'd be more efficient in a single language if I only programmed in that, true, but I think I'm more efficient overall because I bring a wide variety of solution sketches with me that can be applied depending on scope and primary, secondary, tertiary (and more) concerns. Once you have the first half-dozen to dozen languages under your belt, ideally with different paradigma (OO, FP, logic, old-school structural/procedural, bare-metal, VM/script) the next dozen dozen will be a piece of cake and your biggest problem is the warm-up of the language keyword and stdlib name cache. Hence b), above.
Use the most aggressive linter and warning settings, and an editor or IDE which shows warning/error squiggles while typing.
Practice- is the only answer… more time in the seat with each language and it will become more natural… practice may not make perfect but it can make permanent so in your editor as you think through a problem spend time formatting your code manually… it’ll both improve your ability to type and familiarity with each language’s syntax
My approach has been to write and practice small programs in languages that I use. Refresh, rewrite, practice snippets before fitting into large program and then when I get a flow, I continue iterating on large programs.
When your programs are small, switching between languages is very easy.
When your programs are small, switching between languages is very easy.
I program in Java, C++, Go, PHP and Ruby. For me Intellij Idea (and related products) is a lifesaver. Without it, I would lost most energy on slightly different ways to compile, test, deploy...
With Idea most things are uniform, and programming language is just slightly different flavour.
I always have to lookup the elvis or null save operators and end up cursing the java version optional.ofNullable().orElse()
?? ?: ?. .? &. || and more ascii salad
Also the semicolon or access of ivars with arrow, this, self or directly is a gradient transition every time.
?? ?: ?. .? &. || and more ascii salad
Also the semicolon or access of ivars with arrow, this, self or directly is a gradient transition every time.
A very long time ago when editors were unhelpful I was able to give the background a subtle colour depending on the file type. It put me in the right frame of mind without thinking about it. Not sure what modern editors would support that.
I always had to speak 2/3 languages at home and never had issues to context switch between natural languages. It usually the same in programming, I just context switch and it humm just feel natural...
Lucky you, I am trilingual (mother and father tongue, and the place I was brought up) and speak a fourth one daily.
I do not have any problems switching between them, but this unfortunately does not carry over to development.
I do not have any problems switching between them, but this unfortunately does not carry over to development.
Haha i code javascript in frontend and backend i feel like a god.
Tricks and trips for you: no hacks there mate, you just keep doing it till you get used to it. So the tip is to just keep going. Time is your ally.
Tricks and trips for you: no hacks there mate, you just keep doing it till you get used to it. So the tip is to just keep going. Time is your ally.
I refer to my own cheat sheets from time to time.
For example, iteration is so different in TypeScript and Python and I sometimes must remind me about brackets in TS/JS. So I finally resort to a cheat sheet.
Highly recommended!
For example, iteration is so different in TypeScript and Python and I sometimes must remind me about brackets in TS/JS. So I finally resort to a cheat sheet.
Highly recommended!
I switch between Scala and Python all the time.
My trick is to use different editors with different color schemes. IntelliJ for Scala, VSCode for Python. My brain switches immediately.
My trick is to use different editors with different color schemes. IntelliJ for Scala, VSCode for Python. My brain switches immediately.
Clumsily?
When I occasionally write Perl, I wonder why perl -c kicks out error messages, then remember I'm supposed to use "sub", not "def".
When I occasionally write Perl, I wonder why perl -c kicks out error messages, then remember I'm supposed to use "sub", not "def".
Live templates ( keyboard expansions ) , so that ';' in python expands to '' etc.
Use decent IDE like Idea to take away all those primitive syntax issues.
practice, practice, practice. there are some speed up hacks like 'don't start with an empty file' but mostly practice.
1. Install VS code
2. install language runtime support extension for first language
3. Install language runtime support extension for second language
4. RFTM #1
5. RTFM #2
2. install language runtime support extension for first language
3. Install language runtime support extension for second language
4. RFTM #1
5. RTFM #2
:set syntax=language
copilot might be good at this
I find it difficult to switch between the grammar of the languages (especially ones that are rather close such as Go and TS) and spend a day pondering over bugs which are an extra colon, or a dot in the wrong line.
Do you have any tricks/hacks to make the switch easier?
---
Note: by "close" I mean "visually close": "func" vs "function", stacked chained methods that either have their dot at the end of the previous line, or at the beginning on the next, single vs double quotes, types prefixed by a colon or not, ...