As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I think I'm going a little crazy.
Right now, I'm working with the following languages (I was just doing a mental inventory):
C++ - our game engine
Assembler - low level debugging and a few co-processor specific routines
Lua - our game engine scripting language
HLSL - for shaders
Python - our build system and utility tools
Objective C/C++ - game engine platform code for Mac and iPhone
C# - A few tools developed in our overseas office
ExtendScript - Photoshop exporting tools
ActionScript - UI scripting
VBScript - some spreadsheet related stuff
PHP - some web related stuff
SQL - some web and tool related stuff
On top of this are the plethora of API's that often have many different ways of doing the same thing: std library, boost, .NET, wxWidgets, Cocoa, Carbon, native script libraries for Python, Lua, etc, OpenGL, Direct3d, GDI, Aqua, augh!
I find myself inadvertently conflating languages and api's, not realizing what I'm doing until I get syntax errors. I feel like I can't possibly keep up with it, and I can't possibly be proficient in all of these areas. Especially outside the realm of C++ and Python, I find myself programming more by looking at manuals that from memory.
Do you have a similar problem? Ideas for compartmentalizing so you're more efficient? Deciding where you want to stay proficient? Organizational tips? Good ways to remember when you switch from Lua to C++ you need to start using semi-colons again? Rants on how complicated we programmers have made things for ourselves?
Any ideas welcome!
A few things I do to keep them seperate...
Use different IDE's / editors / colour schemes for different languages. You start to associate the language with the environment, and when you switch windows your brain gets a big visual cue that it needs to context switch to the new language.
Try to limit context switching to 2 or 3 active languages at a time. Close down any other IDEs or editor windows when you're done with them.
Try to forget the "fire and forget" stuff. A lot of the languages you've listed seem like they wouldn't be things you're actively coding in every day, but rather tools you use to automate daily tasks. As much as possible try to have a "tool day" where you do any work you need to on those tools. Seperate it as much as possible from your day to day coding, so your brain doesn't have to worry about page swapping that stuff in and out all the time.
-- edit cue, not queue.
For any language I plan on learning thoroughly, I will write my own syntax highlighting in Vim. I try and make the colouring strict so that the colouring picks up obvious mistakes as I type them. This helps me remember where to put certain syntax items in case I forget (so // doesn't look like a comment in python, and I always have trouble remembering where to put * or [] in C). If I can't remember a function or method name, I guess it, and if it shows up in colour I know I've spelled it correctly. I also try and choose differing colours so that different languages stand out from each other, it helps my brain remember what language I'm writing in.
I think after a while it comes natural to you. When I was first getting serious about programming I was using a variety of languages - Java and C# especially. I found myself accidentally using certain Java features in C# and the other way around. Luckily for me a lot of their features are identical so it saved me there, but as I moved on this wasn't really a problem.
Try spending a significant amount of time with each language. Sit down and read a good book (or a couple) on each language and get familiar with it. Ask your boss if you can spend most of your time on one section at a time. You will begin to catch more of your mistakes before you make them. For the ones you don't, this is why debuggers were created - a programmer's best friend. I have a terrible memory, and I mean TERRIBLE. You may think it makes programming harder for me but it really doesn't. After using a language for a significant amount of time the functions just seem to come to you.
So try spending more time on each language instead of jumping around and trying to learn them all at once. The information will stick with you better and you will become a lot less flustered and confused when coding time comes around. Try doing things that help keep you focused while programming. If a lot of caffeine helps, go for it! If listening to your favorite music helps, go for it! (for me I can't concentrate whatsoever with the smallest sounds, but everyones different).
Best of luck!
The feature I never get right the first time, when I change from one language to another, is arrays. They always have different syntax, and I end up looking them up every time.
Here is a list of my most used languages and how to implement arrays in them:
//Java:
int[] array1 = new int[5];
int[] array2 = {0, 1, 2, 3, 4};
//C/C++:
int array1[5];
int array2[5] = {0, 1, 2, 3, 4};
//JavaScript:
var array1 = new Array(5);
var array2 = [0, 1, 2, 3, 4];
//PHP:
$array1 = array(5);
$array2 = array(0, 1, 2, 3, 4);
//Python:
array1 = []#According to the comments, we don't care about size!
arary2 = [0, 1, 2, 3, 4]; #Could use range to create a sequence
One of the things you find in web-dev is that almost by definition if you want to be capable of end-to-end work you need to be capable of at least 5 languages (SQL, mid tier, html, css, js), and every slightly different project is going to add something else (jQuery? Flash? XML?).
I think you just sort of have to grok this naturally, but two things really help:
learn concepts, not syntax and lean on IDEs and google when you need to (another reason language specific interview questions make no sense), because these are applicable to anything and it's easier to see the domain specific components sliding in and out than to think you're learning something entirely different
where possible stick to the similar families of language syntax - I know I personally find C# considerably more natural to use than PHP because it's sharing syntax with JS and Actionscript, XML because of it's familiarity for me from HTML
I agree: there are too many languages and APIs out there.
If you were a customer, and languages and APIs were just like T-shirts, you would be happy that you have the biggest choice possible. Hey, if you want a statically typed language which gives you a lot of flexibility and high performance, go with C++! If you want something easier to maintain, go with Java or Python or Ruby or you name it. You have the choice. You should be happy.
But the truth is, you're more like a guy building a house, and languages and APIs are like screws and bolts: they're your tools. If you have 1000 different types of screws and bolts, each with different characteristics and limitations, then your job will be a nightmare. You'd be more focused on your tools than on the house you're building (does this ring a bell?). Of course, I know there is no one-size-fits-all bolt, but you certainly could imagine life with just a few different types of bolts, couldn't you?
I think the problem lies in the fact that guys in the building industry love the houses they're building... and we developers just love the bolts. I'm no exception: I just love to learn a new language or framework. Bolts are so beautiful. ;-)
I personally have almost no hope of forward progress without my half-dozen API and language reference bookmarks sitting right on my desktop.
I feel your pain, bro.
I don't know, though; I think multiple-language proficiency (or at least multiple-language-general-awareness) is just sort of the world we're livin' in, and something we're just gonna have get used to. Somehow. Alas, I don't know what the secret is to keeping sane, though. (Although for me, I can say that beer definitely helps.)
Some folks on my team (I work at Real, too, incidentally) develop in C++ on Windows, for Windows, and that's it -- that's all they've been doing for years, and they're great at it, they love it, and they're totally happy doing that one thing really well.
Me, on the other hand -- I've never been able to settle into any one language, and I don't think I'd want to; generally speaking, I've learned about a language a year for the past ten years, some of them unlike any others (ColdFusion, anyone?), and these days, I do almost all of my work in Flash, Flex and ActionScript. If you'd told me two years ago what I'd be doing today, I'm sure I'd have laughed. Keeping up is exhausting sometimes (I posted similarly a while back -- a few good answers from other folks in there, too), but I can't seem to resist checking out the new stuff, keeping current, etc.
One thing I will say, though, following on from John T's and Scott's comments: books are the only way to go. Books, at least for me, along with reading lots of (good -- not bad) code, are the best way to let a language seep gradually and cohesively into your brain, and that just takes time. Like I said, I'm almost two years now with Flash, and I'm only now beginning to feel like I can speak ActionScript fluently. All told, I've probably got ten AS books on my desk, though, and there are two more downstairs waiting for me once I'm finished with the one I'm reading now.
It never ends. Woohoo!
PS: VBScript, though? Ugh, that's terrible. Sorry, man. ;)
One of the advantages of my job is that I am able to switch from one project to another, with different languages, operating systems, coding rules, QA requirements, ...
The only way I found to stay on top is not to know every bit of every language, but to know what are the reference docs and where I can find them. For instance, I use the man command for perl, TCL/TK and various flavours of Unix and Linux, the online Language Reference Manual for Ada, Apple Developer resources for Objective-C and Cocoa.
Any project scheduling you can do to minimize the context switches could be helpful. Can you put off the web development until the C++ code is stable?
Another thing I try to do is have a good "worked example" of a new language. Try and find small to medium sized samples of the language you're currently using, and keep it handy. I find picking up syntax details from a piece of sample code I'm somewhat familiar with is often quicker than digging the details out of a reference manual.
Humans can't multitask. Period.
http://www.joelonsoftware.com/articles/fog0000000022.html
If you aren't allowed to let other people do the work because they already have full plates, then get more people hired. If you aren't allowed to get more people hired, then maybe people can at least shift priorities so each person can focus a bit more.
For example: If you're full time on the engine, or at any level of commitment beyond bug fixes, why are you working on game logic? And content tools? And build tools? And web development? If you're not talking about a one year time span, with maybe a separate solid month of concentrating on each, then it sounds like you do all the programming, and everyone else just twiddles their thumbs.
Surely you're the expert for only one of these areas, and not all of them. There's that whole "if you got hit by a bus" thing. If you're that guy, then that is job security for you, but terrible for your company and your sanity.
You could try matching up tools a bit more. Move as many things as you can to Python or .Net, since I assume you can't ditch your core technologies for your games.
Related
Using the right language for the job is the key - this is the comment I read in SO and I also belive thats the right thing to do. Because of this we ended up using different languages for different parts of the project - like perl, VBA(Excel Macros), C# etc. We have three to four languages currently in use inside the project. Using the right language for the job has made it immensly more easy to do automate a job, but of late people are complaining that any new person who has to take over the project will have to learn so many different languages to get started. Also it is difficult to find such kind of person. Please note that this is a one to two person working on the project maximum at a given point of time. I would like to know if the method we are following is right or should we converge to single language and try to use it across all the job even though another language might be better suited for it. Your experenece related to this would also help.
Languages used and their purpose:
Perl - Processing large text file(log files)
C# with Silverlight for web based reporting.
LabVIEW for automation
Excel macros for processing data in excel sheets, generating graphs and exporting to powerpoint.
I'd say you are doing it right. Almost all the projects I've ever worked on have used multiple languages, without any problems. I think you may be overestimating the difficulty people have picking up new languages, particularly if they all use the same paradigm. If your project were using Haskell, Smalltalk, C++ and assembler, you might have difficulties, I must admit :-)
Using a variety languages vs maintainability is simply another design decision with cost-vs-benefits trade-offs that, like any design decision, need to considered carefully. While I like using the "absolute best" tool for the task (whatever "absolute best" means), I wouldn't necessarily use it without considering other factors such as:
do we have sufficient skill and experience to implement successfully
will we be able to find the necessary resources to maintain it
do we already use the language/tech in our system
does the increase in complexity to the overall system (e.g. integration issues, the impact on build automation) outweigh the benefits of using the "absolute best" language
is there another language that we already use and have experience in that is usable in lieu of the "absolute best" language
I worked a system with around a dozen engineers that used C++, Java, SQL, TCL, C, shell scripts, and just a touch of Perl. I was proud that we used the "best language" where they made sense, but, in one case, using the "best language" (TCL) was a mistake - not because it was TCL - but rather because we failed to observe the full costs-vs-benefits of the choice:*
we had only 1 engineer deeply familiar with TCL - the original engineer who refused to use anything but TCL for a particular target component - and then that engineer left the project
this target component was the only part of the system to use TCL and it was small relative to the other components in the system
the component could have been also implemented in another language we already used that we had plenty of experience in (C or C++) with some extra effort
the component appeared deceptively simple, but in reality had subtle corner cases that bit us in production (not something we could have known then, but always something to consider as a possibility later)
we had to implement special changes to the nightly build because the TCL compiler (yes, we compiled the TCL code into an executable) wouldn't work unless it could first throw its logo up on the screen - a screen which wasn't available during a cron-initiated automated nightly build. (We resorted to using xvfb to satisfy it.)
when bugs turned up, we had difficult time finding engineers who wanted to work on it
when problems with this component cropped up only after sustained load in the field, we lacked the experience and deep understanding of the TCL execution engine to easily debug it in the field
finally, the maintenance and sustainment team, which is a much smaller team with fewer resources than the main development team, had one more language that they needed training and experience in just to support this relatively small component
Although there were a number of things we could have done to head-off some of the issues we hit down the road (e.g. put more emphasis on getting TCL experience earlier, running better tests to detect the issues earlier, etc), my point is that the overall cost-vs-benefit didn't justify using TCL to code that single component. Again, it was not a mistake to use TCL because it was TCL (TCL is a fine language), but rather it was a mistake because we failed to give full consideration to the cost-vs-benefits.
As a Software Engineer it's your job to learn new languages if you need to. I would say you should go with the right tool for the job.
It's like sweeping the floor with an octopus. Yeah, it gets the job done... kind of... but it's probably not the best tool for the job. You're better off using a mop.
Another option is to create positions geared towards working in specific languages. So you can have a C# developer, a Perl developer, and a VBA developer who will only work with that language. It's a bit more overhead, but it is a workable solution.
Any modern software project of any scope -- even if it's a one-person job -- requires more than one language. For instance, a web project usually requires Javascript, a backend language, and a DB query language (though any of these might be created by the backend language). That said, there's a threshold that is easily reached, and then it would be very hard to find new developers to take over projects. What's the limit? Three languages? Four? Let's say: five is too many, but one would be too few for any reasonably complex project.
Using the right language for the right job is definitely appropriate - I am mainly a web programmer, and I need to know server-side programming (Rails, PHP + others), SQL, Javascript, jQuery, HTML & CSS (not programming languages strictly, but complex things I need to know) - it would be impossible for me to do all of that in a single language or technology.
If you have a team of smart developers, picking up new languages will not be a problem for them. In fact they probably will be eager to do so. Just make sure they are given adequate time (and mentoring) to learn the new language.
Sure, there will be a learning curve to implementing production code if there is a new language to learn, but you will have a stronger team member for it.
If you have developers in your teams who strongly resist learning new languages, unless there is a very good reason (e.g they are justifiably adamant that they are being asked to used a different language when it is not appropriate to do so) - then they are not the sort of developers I'd want in my teams.
And don't bother trying to hire people who know all the languages you use. Hire smart programmers (who probably know at least one language you use) - they should pick up the other languages just fine.
I would be of the opinion, that if I a programmer on my team wanted to introduce a second (or third) language into a project, that there better be VERY VERY good reason to do so; as a project manager I would need to be convinced that the cost of doing so, more than offset the problems. And it would take a lot of convincing.
Splitting up project into multiple languages makes it very expensive to hire the right person(s) to take over that project when it needs maintenance. For small and medium shops it could be a huge obstacle.
Edit: I am not talking about using javascript and c# on the same project, I am talking about using C# for most of the code, F# for a few parts and then VB or C++ for others - there would need to be a compelling reason.
KISS: 'Keep it simple stupid' is a good axiom to follow in most cases.
EDIT: I am not completely opposed to adding languages, but the burden of proof is on the person to who wants to do it. KISS (to me) applies to not only getting the project/product done and shipped, but also must take into account the lifetime maint. and support requirements. Lots of languages come and go, and programmers are attracted to new languages like a moth to a light. Most projects I have worked on, I still oversee and/or support 5 or 10 years later - last thing I want to see is some long forgotten and/or orphaned language responsible for some key part of an application I need to support.
My experience using C++ and Lua was that I wrote more glue than actual operational code and for dubious benefit.
I'd start by saying the issue is whether you are using the right paradigm for the job?
Suppose you know how to do object oriented programming in C#. I don't think the leap to Java is all that great . Although you'd have to familiarize yourself with libraries and syntax, the idea is pretty similar.
If you have procedural parts to your project, such as parsing files and various data transformations, your Perl/Excel Macros seem pretty similar.
But to address your issues, I'd say above all, you'll need clarity in code. Since your staff are using several languages, they won't be familiar with all languages to an equal degree. So make sure of this:
1) Syntactic sugar is explained in comments. Sugars are pretty language specific and may not be obvious to a new reader. For instance, in VBA I seem to remember there are default properties, so that TextBox1 = "Hello" is what you'd write instead of TextBox1.Text = "Hello". This can be confusing. Also, things like LINQ statements can have un-obvious meanings. So make sure people have comments to read.
2) Where two components from different languages have to work together, make excruciatingly specific details about how that happens. For instance, I once had to write a C component to be called from Excel VBA. There's quote a few steps and potential errors in doing this, especially as far as compiler flags. Make sure both sides know how their side of the interaction occurs.
Finally, as far as hiring people goes, I think you have to find people who aren't married to a specific language. To put it vaguely, hire an intelligent person who sees business issues, not code. He'll learn the lingo soon enough.
The title may seem slightly self-contradictory, and I accept that you can't really learn a language quickly. However, an experienced programmer that already has knowledge of a few languagues and different styles (functional, OO, imperative etc.) often wants to get started quickly. I've seen a few websites doing effective "translations" in the form of "just show me syntax equivalence". I can't remember the sites now, but for related languages (e.g. Perl/PHP) it's quite common.
Is there a better resource that covers more languages? Is there a resource that covers idioms as well as syntax? I think this would be incredibly useful for doing small amounts of work on existing code bases where you are not familiar with the language. Looking at the existing code, as we know, is not always a good indicator of quality. Likewise, for "learn by doing" weekend project I always have the urge to write reasonably idiomatic, clean code from the start. Such a resource could also link to known good example projects of varying sizes for those that prefer to learn by reading. Reading a well-written medium sized code base can also be much more practical when access to development environments might be limited.
I think it's possible to find tutorials and summaries for individual languages that provide some of this functionality in disparate web locations but I'm hoping there is a good, centralised, comparative place that the busy programmer can turn to.
You generally have two main things to overcome:
Syntax
Reference
Syntax you can pick up fairly quickly with a language tutorial and a stack of samplecode.
Reference (library/API calls) you need to find a proper guide to; perhaps the language reference, or perhaps google...
With those two in place, following a walkthrough (to get you used to using the development environment) will have you pretty much ready - you'll be able to look up what you want to say (reference), and know how to say it (syntax).
This, of course, applies principally to procedural/oop languages; languages that require a paradigm switch (ML/Haskell) you should go to lectures for ;)
(and for the weirder moments, there's SO!)
In the past my favour was "learning by doing". So e.g. I know a little bit of C++ and a lot of C#.Net but I must write a FTP Tool in Python.
So I sit for an hour and so the syntax differences by a tutorial, than I develop the form itself and look at the generated code. Then I search a open source Python FTP Client and get pieces of code (Not copy and paste, write it self to see, feel and remember the code!)
After a few hours I get it.
So: The mix is the best. A book, a piece of good code, the willing to learn and a free night with much coffee.
At the risk of sounding cheesy, I would start with the language's website tutorial and/or FAQ, followed by asking more specific questions here. SO is my centralized location for programming knowledge.
I remember when I learned Perl. I was asked to modify some Perl code at work and I'd never seen the language before. I had experience with several other languages, however, so it wasn't hard to figure out the syntax with the online Perl docs in one window and the code in another, side-by-side. I don't know that solely reading existing code is necessarily the best way to learn. In my case, I didn't know Perl but I could tell that the person who originally wrote the code didn't know Perl either. I'm not sure I could've distinguished between good Perl and really confusing Perl. It would've been nice to be able to ask questions here at the time.
Language isn't important. What is important is learning your ways around designing algorithms and the proper application of design patterns. Focus on the technique, not the language that implements a certain technique. Once you understand the proper development techniques, any programming language will just become real easy, no matter how obscure they are...
When you put a focus on a language, you're restricting your own knowledge.
http://devcheatsheet.com/ seems to be a step in the right direction: it aggregates cheat sheets/quick references and they are (somewhat) manually reviewed. It's also wide-ranging. It still comes up short a bit in terms of "idiomatic" quick reference: for example, the page on Ruby doesn't mention yield.
Rosetta Code appears to be an excellent resource that includes hints on coding idiomatically and moves from simple (like for-loops) to things like drawing. I haven't checked out how comprehensive it is, but there are a large number of languages and tasks listed. The drawbacks re: original question are:
Some of the linking is not accurate
(navigating Python->ForLoop will
take you to the top of the ForLoop
page, not the Python section). It's a
wiki, this can be improved.
Ideally you could "slice" the wiki
however you chose to see e.g. the top
20 tasks for two languages
side-by-side.
http://hyperpolyglot.org/ seems to be an almost perfect match for what I was looking for. The quality is not always there, or idiom can be lacking, but it has the same intention and is pretty comprehensive.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
At home I'm working on a large personal project written in Java. I recently found employment as a C# developer.
After an 8 hour workday reading C# code, I find it very hard to switch back to Java at home. Actually, my home project stalled almost completely since I've been employed.
At first I thought I'd have to wait for vacation to actually switch back to Java, but even after a week of not having C# on the brain, I did not manage to come into Java-mood again. I do not want to admit that my home project died, but I can't really see a way to overcome this issue.
If it's that bad, can you start the project again in C#? It may be quicker than waiting for your java-mood to return. It should be quicker than starting from scratch, as you've coded the logic and domain already, so you may be able to translate-and-type your way through that bit.
Use a good (and comparable) IDE in both. I switch between C# and Java, and find the combination of Visual Studio with JetBrains ReSharper for C# and IntelliJ Idea for Java makes this straightforward.
Celebrate the differences - I find a spell in C# helps my Java and vice versa. Differences in, for example, the collection frameworks just help you understand the implementations in each language more deeply.
Use the similarities to your advantage. Syntactically, the differences are not great. You should be writing code, not writing C# or writing Java. As Steve McConnell would put it, "code into the language and not in the language" (or something like that - think it's from Code Complete).
In fact, read Code Complete if you haven't already - great training for flipping between languages.
I suppose you could call this the habitual time to recovery,.
It can help to generalize to: programming logic knowledge + syntax and API = Language Knowledge ... because ...
Human beings are creatures of habit and build efficient work methods, memories and psychology based on environments and tasks we perform most often. This is a good thing.
I recently spent alot of time programming in Python, after being almost 100% C for a long time. I picked up Python quite easily and now am switching back to C. To my surprise, the problems I thought I would encounter (missing semi-colons, the random impulse to indent) were not there.
I concluded this is because:
While I was programming Python, I was frequently (daily) looking at the C source of other projects to remember the ones I didn't document too well. Because my C projects fit in with the Python stuff.
I was always looking at the C implementation of some of the Python stuff
I guess the trick is to relate new skills to old skills so that when you conduct tasks in the new skillset, your brain is still thinking about the old skills and how they related. Many theorise that learning is based on this relational foundation in your mind, and knowing about it can help you reduce the learning curve and time to recovery.
Think of it like a relational database. When you do something new, create a forign key and normalize things out. Don't create a whole new table or database.
Learn a generalization of programming logic and build on that with just the changes between languages. You will learn/switch faster.
Sorry for the bad RDBMS analogy
Your brain is full.
Full Brain http://img146.imageshack.us/img146/2469/brainfull.gif
Firstly, if you've put in an 8 hour day programming in any language, it may not be switching languages so much as just needing a break from programming. I can only speak for myself, and I know some SO'ers may feel otherwise, but I often need a break from programming after a full work day of doing it.
Currently I prefer to program in Python, but my job wants me to do shell scripting, Java, JavaScript, PHP, and IDL (that's Interactive Data Language, not Interface Description Language). So, I try to do some Python at home to keep those skills from atrophying. What I find (in addition to often needing a break as mentioned above) is that I get my languages confused a lot when I first switch from one to another. It's easy at that point to give up, but I find that as I get mentally deeper into programming with a given language I make fewer mistakes from the language confusion. So, maybe if you can just push past that first reluctance to use Java, you'll have success. YMMV, of course, and good luck!
This is because of something in psychology called the interference effect, or Stroop Effect. The two tasks are closely related (programming) so the knowledge brought into your mind by one language interferes with the knowledge brought into your mind by the other language.
Here's a cute example of a simple task that is hard to do because of this effect:
http://www.apa.org/science/stroop.html
Switching between two different frameworks is very hard to do. It's even harder if you haven't been doing them for very long.
The question, I think, has to come back to you in that you should ask yourself what you prefer now. If you still like Java and want to keep your skills up in Java, you will probably need to spend more time with it on a semi-daily basis. Working with it on nights and weekends and making sure there are no long breaks in between.
If you prefer C# now and really have no interest in persuing Java, I would convert the project at home to C# as that can only make you a better C# programmer and make you better at your day job.
I wonder if it's related to the similarities between those particular languages. Granted I've not actually used C#, but it seems pretty similar to Java. The similarities might make it difficult to context switch from work to hobby. Maybe you could learn and switch to Python, Haskell, Lisp, etc. for your personal project.
You could try spending some time programming in a completely different language in your spare time. For example, write something in Haskell, Prolog, Mercury, Oz, or Factor.
When (if?) you come back to Java, its similarities to C# will be much more striking than its differences.
That is normal. It may be a problem of Cognitive Flexibility and Inflexibility. It happens with human speech too.
Check yourself. If you are getting too tired to work at home after your regular 8 hour workday reading C# code, and also you want so much to finish your project, and now you find difficult to code in java, you may be suffering from anxiety. If you take some energy drink, coffee, cola, then you are favoring anxiety.
There are exercises for keeping yourself Cognitive Flexible. One of them is to switch for a while (couple of minutes) to Java instead of spending so much time in C#. It is like when you are programming in Java and have to switch to SQL, then to HTML. You are being flexible and switching.
Good luck.
As I answer this i feel I need to make some assumptions here based on personal experience. I write code in C++ or c# on side projects while at work am forced to dangle between php and python
There was a time i was without a steady day job and kept pretty busy on side projects.
When i landed my day job the enthusiasm i had for my side projects dwindled based on two major factors... Like you i was at my job 8 to 9 hrs a day.
2ndly i had an increased steady source of additional revenue so the motivation to code just to earn a living drastically reduced and i found myself more and more opting not to take up any new projects after work coz i jus wasnt in the mood anymore.
I also discovered that with this new attitude i started making rookie mistakes when coding in c++ unlike before. After changing my attitude things picked up again.
My best guess is that you are going through the same thing that i was going through. I suggest you find new ways to get motivated once you leave work and you will find it easier to continue programming in java.
I have a similar thing at work. I write code in JavaScript and c# but at home I write code in Python and JavaScript.
I have sometimes caught myself writing python style code in c# and then getting my tests failing. I agree with Nat that working in a language that is totally different from your work language will help you see the similarities and that they only differences will be where the libraries exist!
You know when you are overworked: it's when you try to find F1 key in the elevator cabin to launch it up!
I think java is for the diligent, and .net is for the lazy.
Perhaps someone would be angry for that,but I wanna say I am a .Neter.The .net syntax is less strict than the java's.In fact in the source code of .net,there is some simplify.
for example,we can use Convert.toDateTime(string) to Convert a String to DateTime directly.
But in java,we should make the difinition of the string's format such as "yyyy-dd-mm" then we can convert.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Question
As stated, have you any tips to help grok / understand / get-your-head-around declarative programming languages?
Or is it simply a case that you’ve to immerse yourself in the language and it’s syntax, until it seeps in, until you get that golden moment where you Get It. This isn’t really an option as I can no longer lock myself in a room for days on end, poring over half a dozen different books on the subject matter (responsibilities being what they are and all)
So, any tips or tricks that helped you when you tackled declarative languages, any insights to pass on?
P.S. I’ll personally upvote the first answer that says “Shutup and put in the work”.
Background
I was 13 years old I when I first started wring code (basic, on my sisters Oric-1).
Since then I’ve worked with many new concepts and many different languages, taking all in my stride, me taking the upper hand quickly enough. Object Orientation? Not a bother. Event driven paradigms? Smoke me a kipper, I’ll be back for breakfast.
Owl, Mfc, ActiveX, Vb3, 4, 5 & 6, VB.Net, Pascal, Delphi, C, C++ & C#. None have stood in my way, at least not for very long.
However recently my perfect score has taken a bit of a battering.
A couple of weeks ago I threw myself into Xaml, and folks, I’m more sinking than swimming.
I think my main problem is that it’s declarative. All my other programming skills are procedural. I’ve hit this block before with MSBuild, I can copy examples of how to get MSBuild things working, but would be lost putting something together from scratch.
Back to Xaml, currently I’m going insane trying to wire triggers to properties and get the effect’s I need.
I may post my specific Xaml question here soon enough. For now I’m asking this general “declarative programming” question.
P.S. No, I'm not actually this cocky. Yes, I stumbled like hell the first time I hit OO and the first time I'd to write an event driven UI (VB3 on Windows 3.11).
Edit
It's starting to sink in, the tenacity that got me this far in this field is paying off, it just takes so much fracking time!
. . . I think I'm getting too old for this stuff . . . :)
I had to teach XSL (or XSLT, as you wish) a bunch at the beginning of the century :), and it's a different world, really. That, however, is the basis for the paradigm-shift: you have to realize that declarative languages really are different. The most important advice I have is to keep studying other people's solutions, put the work in, and really try to stop thinking in FLOW. The worst thing is that, in XSL, there is an "if" and an "else," but usually there's another way to do things.
Unlike learning OO, in XSL (or any declarative language, I suppose) you will not manage to do what you're trying to do unless you do it declaratively.
So the answer is in part, "shut up and do the work" as you suggest, but the more important point is to realize that a lot of the work is getting your head around the paradigm shift. So the real answer is, "keep your eyes peeled for the paradigm shift." You have to stop thinking in flow and start thinking in terms of rules that can fire in any order... if they're done right, it doesn't matter when they fire. When you are finally thinking in rules instead of WHEN stuff happens, you're beginning to grok the shift.
Find some examples, with explanations of the "why", from someone who really knows the language. It's learning the patterns and idioms that makes a difference.
I suspect you're trying to do imperative things in declarative land, which means you think in terms of steps. Write the dataflow down in terms of required inputs + stateless function of those inputs and see if that helps.
Try a functional or functionalesqe language like ML or Scheme.
I don't know what your specific problems with Xaml are (and I haven't used it myself) , but I've found that when using XML based technologies like XSLT, a little LISP or Scheme experience can go a long way. You might want to look at playing with the excellent scheme system available free from http://www.plt-scheme.org.
I can see where this may be blowing your mind. All those languages you list are indeed quite similar (procedural).
Once you get this down, I highly encourage you to learn a functional language as well. You may also find it tough going, but learning it will help your general coding skills greatly. You'll have a whole new bag of tricks (even in procedural languages), and you will never be afraid of recursion again.
Consider your favorite “programmer ignorance” pet peeve. The first code snippet is obviously procedural. In the second snippet you make a declarative statement that for the percentage to be valid it has to be between 0 and 100.
So i'd guess you'll have no trouble grokking declarative programming languages as long as you work on it hard enough... there is no royal road to geometry
Like Binary Worrier, I had a long history with things like C, C++, MFC, etc and have been coming up to speed on XAML, WPF, and C#. I had a side trip through HTML, Javascript, and XSLT which I think helped a great deal in preparing me for XAML.
The basic idea behind XAML is fairly straightforward - it's all about what you show, not what you do. The hard part with XAML is that there is just a ton of implementation details to learn and you wind up learning them all at the same time in order to be able to get much of anything done.
I could probably be more helpful if the question was more specific.
"Programming is about giving a computer a sequence of instructions."
Most programmers react with equanimity to this statement. It's almost like... "duh?"
But the belief in this statement is what causes people to have trouble understanding other programming paradigms. It's not true, and hasn't been for a very long time. To arrive at a better understanding of programming, many may benefit from thinking on why this statement is false.
Even if you programmed in pure assembly, modern processors would rearrange your instructions, perform branch prediction, and attempt to execute multiple potentially codependent instructions at the same time. In this way they think in terms of logical dependencies, not sequences. The sequence metaphor is the false notion that an instruction logically depends on everything that preceded it. If this were true, the best way to reason about programs would be to examine the control flow. But it is not true.
It's not just declarative programming that doesn't fit with this metaphor, but also parallel and asynchronous programming.
I find the easiest way to "grok" a language is simply to start using it exclusively for all your coding. With a completely new language I would say for me the learning curve is approximately 2 weeks of coding about 4-5 hours a day. After that point it suddenly "clicks" and you can start relying less on manuals and docs.
I took a class in college (Programming Languages). It pretty much felt like I was repeatedly slamming my head against a brick wall, but about 3/4 of the way through the class, I realized the wall wasn't there anymore; I had been beating my head against nothing for a few weeks. It was a pretty surreal feeling.
I think any other way won't have the same charm. Read Godel, Escher, Bach; listen to a lot of Emerson, Lake, and Palmer and Kaikhosru Sorabji; smoke some ganja, and put in the time.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does anybody have any tips for utilizing multiple languages at the same time? I use objective-c, c, perl, ruby, bash, ksh, rails, and other proprietary languages every day and am finding increasingly difficult to go back and forth between them on a daily basis. As a trivial example when switching between perl and ruby I constantly forget to use semi-colons in perl and find myself using $ for local vars in ruby. Things are even worse going from objective-c to c: I use function calls (instead meesage invocations) in objective-c. Does anybody have any tips on making working in several languages more productive?
For those of you suggesting IDEs as a solution, although I agree in principle with using an IDE to increase productivity. I tend to do all my coding in vi
A couple of tips:
Slow Down! We're used to working at a frenetic pace as developers. Switching between languages requires some more conscious thought and focus.
Use a good IDE - that shows your errors as you type them. This will be a gentle reminder that you are missing that semi-colon or leaving out a '$' (in many cases)
I have the same issue from time-to-time, but these two things help!
In my personal experience it's horrible to do this kind of task and technology switching, it totally messes up your brain, at the end of a day you're more a cabbage than a tired programmer. Don't do it. If your company forces you to do it start searching another job, if you are doing it for yourself, think once more if you really want this.
I use Java, Python, C, C++ and PHP(!) almost daily, and also trying to learn some more like Clojure and Perl. The best thing to do is to use a good, language-aware, syntax-highlighting, autoformatting editor/IDE that reveals trivial syntax mistakes right away. It definitely helps in switching the language mode of the brain.
I don't think that being able to code in multiple languages is much different from being able to move with a bus, car, bike or foot. The details differ, but the main idea is approximately the same.
Human memory is very context sensitive. Instead of going for one IDE/editor that covers all languages and helps you with error detection and syntax highlighting, you might want to consider going for one editor per language. I know this sounds like overkill and it probably is, so an alternative might be different themes for the editor that you switch when you switch languages. As a drastic example consider yourself using a red background when writing bash scripts and a blue background for your Python programming. With visual clues like that it should be much easier to distinguish what you are currently doing and after a little while this might work without any conscious effort.
Bullet point summary of things I've tried that have helped me:
Whenever reasonable & possible, take a break when you're switching languages
Use languages which are synergistic
Use consistent coding styles across languages
More detail from personal experience:
Switching like this can be very difficult. I've been in similar circumstances - earlier this year I was developing a web app at work with PHP, IDL (Interactive Data Language), JavaScript and some Bash and then doing some projects at home with Python. I found myself making lots of mistakes with syntax when switching from one to another.
The mistakes happened most commonly at work: E.g. when I'd been doing IDL for a while and then would switch to the PHP, I would forget to put dollar signs on the front of variables and semi-colons at the end of the lines. I didn't seem to have as many problems at home; I believe that was at least partly because it was always a few hours between getting home and starting my Python work, so the break probably helped my brain re-set from the languages I was using at work.
One thing that can help is finding languages with certain synergies: I've found that I can switch relatively easily between Python and Java ... yeah, I am still more likely to forget semi-colons at the end of my Java lines if I've been doing Python, but the two languages "sync" well in my brain, so switching isn't as difficult as going from Python to Perl, for example. I've also found it relatively easy to switch between Perl & PHP. YMMV, of course, and I expect different people will find synergies between different sets of languages.
Also, as much as you can, it may help to maintain a consistent coding style between languages. An example: for years I put an opening brace on the line after an if, for, etc. in Java, C, Perl, etc. However, after using Python as my main language for a few years, I've found that I no longer like that style, and have switched to putting opening braces at the end of lines. For me, this has helped create a more consistent appearance across languages, which I find helps ease the switching. Again YMMV.
While it gets better in time, the ability to do this kind of switching between a lot of languages on a daily basis is not for everyone. You should try "clustering" your work in such a way that you finish what you have to do in one language before taking a short break and moving on to the next. This would prevent you going back and forth and impose a schedule that will be easier to follow if you stick to it.
To issue a less abstract suggestion:
There are lots of plugins for Eclipse, and you can make it do most programming languages known to mankind (and probably a few not). However, many of those plugins are less than perfectly integrated. One is annoyingly full of advertisement for its creating company, another one is a memory hog...
For those who haven't heard about it: IntelliJ IDEA has gone (partially) Open Source, and in my experience it's very good at multi-language. I saw a demo a year ago where one of their developers built a program in 6 different languages. A toy, yes, but the IDE did a fine job on language-aware syntax highlighting, refactoring and so forth.
It won't do all your detail work for you, but it can help with some of it - and with good quality.
My recommendation is to give yourself a 15 minute break between switching languages. If you can't do that since you flip between client / server apps, then I would recommend dual screens. Separate client on left and server on right. As someone has already stated, the human mind is context sensitive. Therefore, the way you think and analyze things has a lot to do with it. Any way you can seperate the different contexes would help in making minor oops on a regular basis.
Frequently in my current job I will use different languages, the key for me to making this easier is to get the right tooling. There are some very good general purpose editors out there, which already have a long list of Syntax highlighters, checkers and even autocompletion. Most of which can be further customised. If you set these up to recognised the file extensions then a lot of the pain can be removed.
I generally use these in addition to IDEs, as most IDEs won't support ksh or other scripting, and are harder to customise so having another tool setup makes it easy to flick across. Ideally get one that runs both on Windows and the nixes
I've been using these for some time now
jedit
nedit
emacs
textpad