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.
Related
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.
Its always said that more you program, the better you become. Sounds good and true.
But I was wondering if there is a proven route to becoming a better programmer.
Something like:
Learn a
Learn b
Learn c > 'Now you are good to burn the engines'
Try stuff around based on your learning.
The answer might be similar to a CS course roadmap, but I want to hear from successful programmers who might want to pitch in with something notable.
Thanks
It's not true that practice makes perfect.
It's perfect practice that makes perfect.
If all you do is keep repeating the same bad practices again and again, you'll only make it possible to create bad code faster.
By all means keep coding. But at the same time be critical of everything you do. Always have a jaundiced eye that looks for ways to do things better. Read widely to get new ideas. Talk to others about how they do things. Look at other people's code, good and bad.
There's no "sure" way to learn anything that I know of. If there was, anyone could master this.
All questions are rhetorical and meant to stimulate thought.
Technical parts:
Design Patterns - There are probably some specific to a domain but generally these are useful ways of starting parts of an application. Do you know MVC or MVP?
Basic algorithm starting points - Divide and conquer, dynamic programming, recursion, creating special data types like a heap, being greedy, etc.
Problem solving skills - How easily can you jump in and find where a bug is? Can you think of multiple solutions to the problem?
Abstract modelling - How well can you picture things in your head in terms of code or classes when someone is describing a problem?
High level versus low level - How well do you understand when one wants something high or low? This is just something I'd toss out there as these terms get through around a lot, like a high level view of something or a low level language.
Process parts:
Agile - Do you know Scrum, XP, and other new approaches to managing software projects? How about principles like YAGNI, DRY and KISS? Or principles like SOLID? Ideas like Broken Windows?
Developer Environment - How well do you know the IDE you use? Source Control? Continuous Integration? Do you know the bottle necks on your machine in terms of being productive?
xDD - Do you know of TDD, BDD, and other developments driven from a paradigm?
Refactoring - Do you go back over your old code and make it better or do you tend to write once and then abandon your code?
Soft skills:
Emotional Intelligence - Can be useful for presentations and working with others mostly.
Passions/Motivation - Do you know what gets your juices flowing and just kick butt in terms of being productive? Do you know what you would like to do for many many years?
My main piece of advice would be: don't be afraid to rewrite your own code. Look at stuff you wrote even a month ago and you will see flaws and want to rewrite stuff.
Make sure that you understand some fundamentals: collections, equality, hashcodes etc. These are useful across pretty much all modern languages.
Depending on the language you use - use lint and metric tools and run them over your code. Not all their suggestions will be applicable but learning which are important and which are not is important. E.g FindBugs, PMD etc for Java.
Above all refine and keep refining your work. Don't treat your work as abandonware!
Learn your 1st programming language a new programming paradigm or a
find a mentor you can learn from
Apply what you've learnt in a real world project
Learn from your mistakes and successes and goto step one
The trick is knowing what to learn first:
Programming languages - this is the place to start bcause you cannot write software without knowing at least one of these. After you've mastered one language try learning another.
Programming paradigm - i.e. object oriented, dynamic/functional programming etc. Try to learn a new one with each new language.
Design concepts - S.O.L.I.D, design patterns as well as architectural concepts.
People skills - learn to communicate your ideas.
Team leadership - learn how to sweep others and how to become a team or technological lead.
After that the sky is the limit.
I would look at improving roughly in this order, in iterations with each building on the previous one:
Programming concepts. Understand things like memory management, pointers, stacks, variable scope, etc.
Languages. Work on mastering several modern languages.
Design concepts. Learn about design patterns. Practice using them.
Communication. Often-overlooked. You can only become a highly valued Software Engineer if you can communicate effectively with non-tech people. Learn to listen and understand the needs that people are expressing, translate that into a set of requirements and a technical design, but then explain what you understood (and designed) back to them, in terms they can understand, for validation before you code. This is not an easy one to master, but it is essential.
Architectural concepts. Learn to understand the big picture of large, complex systems.
Learning a programming language is in many ways similar to learning a spoken language. The only way to get good at it is to do it as often as possible. In other works
Practice, practice, read and then practice more
Take time to learn about all sorts of coding techniques, tools and programming wisdom. This I have found to be crucial to my development. It's to easy to just code away and feel productive. What about what could be if you just had some more knowledge / weaponry under your belt to bang out that next widget.
Knowledge/know how is our real currency. The more we know the more we can make a better decision about how something should be done and do it faster.
For example, learn about:
•Development Practices, Software Design, Estimation, Methodologies Business Analysis Database Design (there are a lot of great books out there and online resources)
•Read Code - Open Source Projects are a good place for this. Read
Programming blogs
•Try to participate on Open Source
Projects.
•Look for programming user groups in
your town and/or someone who can mentor you.
And yes, as mentioned practice. Don't just read, do and watch how you will improve. :)
Practice, practice, practice.
Once you're over the basic hump of being able to program, you can also read useful books (i.e. Code Complete, Effective Java or equivalents, etc.) for ideas on how to improve your code.
First and foremost write code. Write as much as you can. Tackle hard problems. If you want to be a really good programmer you need to get into the guts of what you are doing. Spend a lot of time in debuggers looking at how things work. If you want to be a good programmer who really understands what is going on you need to get down to the metal and write highly async code, learn about how processors work and why SSE is so awesome. Understand threading primitives and be able to write them as well as describe what is actually happening in the processor. I could keep going here but you get the idea.
Second find someone who knows a lot more than you and learn. This relationship will work better if you are already deeply immersed in writing lots of code.
Third, spend some time in a large high quality open source code base. I learned a ton from the Quake I and Quake II code. Helped me be a better programmer.
Fourth take on hard problems. Push your limits. Build things that you thought were impossible. Right now I am writing a specialized compiler. I have learned so much just working on this for the last couple of months.
Sure, strictly speaking, the more you practice programming, the better you become at solving those sorts of problems. But is that what you really want?
Programming is a human activity more than a technological one, at its heart. It's easy to improve your computer skills, not so hard to improve your interpersonal skills.
Read "Journey of the Software Professional" by Hohmann. One of the concepts the concepts Hohmann describes is the "cognitive library," which includes both programming skills and non-programming skills. Expand your cognitive library, and your programming skill will improve too.
Read a lot of non-programming books too, and observe the world around you. Creating useful metaphors is an essential skill for the successful programmer. Why do restaurants do things how they do? What trade-offs is the garbage department making when they pick up the garbage every few days instead of every day? How does scaling affect how a grocery store does business? Be an inquisitive human to be a better programmer.
For me, there has to be a reason to learn something new... that is, unless I have a project in mind or some problem I need to solve, there's no hope. If that prerequisite is met, then I usually try to get "Hello, world" working, and after that the sky's the limit. So much of development these days is just learning new APIs. Occasionally there's some kind of paradigm shift that blows your mind, but that's not as common as people like to think, IMHO.
Find a program that intrigues you, one that solves a problem, or one that would simplify many of your tasks. Try to write something similar. You'll get up to speed very quickly and have fun doing it at the same time.
You can try learning one thing really well and then expanding out to programming areas that are associated with the things that you have learnt, so that you can offer complete solutions to customers.
At the same time, devote part of your time to explore things outside your comfort zone.
One you have learned something, try to learn something a little harder. Read and practice a lot about things that seem confusing at first time (lambda functins, threading, array manipulation, etc). It will take its time, but once you have practiced enough, what seemed confusing at first, will be familiar and easy.
In addition to the rest of the great advice already given here, don't be afraid to read about coding and good practice, but also take everything with a grain of salt and see what works best for you. A lot of advice is opinion.
Good sites to read:
-thedailywtf.com
-joelonsoftware.com
-codinghorror.com
-blogs.msdn.com/oldnewthing
A great place to get practice is programming competition websites. Those will help you learn how to write good algorithms, not necessarily maintainable code, but they're still a good place to start for learning.
The one I used to use (back when I had time) was:
http://uva.onlinejudge.org/
Learn more than one language. One at a time, definitely, but ultimately you should be fluent in a couple. This will give you a better perspective I think, and help you to become an expert at programming, rather than being an expert at a certain language.
Learn the ins and outs of computers at all levels, hardware, os, etc. Ideally you should be able to build your own system, install multiple operating systems on it, and diagnose just about every problem that can arise. I know many programmers who are not "computer tech people" and their failure to understand what is happening at every level becomes a major hindrance in diagnosing and fixing unusual bugs or performance issues.
As well as looking at 'last weeks code', talk to users of your work after delivery - be one yourself if possible.
Its not my bag, but some of the best coders I know have spent time supporting applications. The experience improved their product I'm sure.
eat breath dream the programming language your using (no seriously, it helps)
There are two kinds of learning -
1. Informal (like how you learned how to function in society- through interaction with peers and family)
2. Formal (like your high school training- through planned instruction)
If you want an entry-level programming job, formal training via an undergrad Computer Science/Engineering degree is the way to go. However, if you want to become a rock-star developer, it is best done by informal training- make unintentional mistakes and have senior developers curse at you, learn a design pattern because an app you are updating uses it, almost cry because a bad developer wrote a huge messy program lacking documentation and best practices and now you have to do several updates to it ASAP; thing of these nature.
It is hard for anyone to give you a list of all you need to know. It varies per area (e.g. a web developer vs. to a desktop developer) and it varies per company (e.g. Microsoft that sells software vs. General Motors that mainly just use it in their cars.) Informal traiing and being engaged in trying to learn to do your job better and get promoted is your best bet in my opinion.
To prove my point, everyone here has great answers but they all differ. Ask a rock-star developer how he learned something or when, why; they may not know- things just happen.
Practice, individually and collectively
Keep an open mind, always learn new things, don't limit yourself to what's familiar. Not solely from a tech perspective, ui design, people skills, ... Don't be afraid of what's new
Peer review, talk to people about your code, let people talk to you about their code, everyone has a unique way of looking at a problem and you will learn a great deal from peers
Love coding. If you love what you're doing, putting in alot of time seems effortless. Every coder needs the drive!
One small addition to these good answers. When I work on someone else's code, usually I pick up something new. If you have the opportunity to work with someone else that is of equal or greater skill, noticing their programming style can teach you tons.
For example, in C++ & Javascript I no longer use if() statements without braces. The reason is that it's just too easy to mistakenly put:
while (true) {
if (a > b)
print a
print b
}
This is an obvious typo, but very easy to introduce, especially if you're editing existing code. I just call it defensive programming in my mind, but little tricks like this are valuable at making you better.
So, find a peer or mentor, and work on their code.
I am not sure if the OP was looking for general advice on how to be a good programmer, but rather something more specific.
I know I am reviving this thread, but I found it because I was trying to see if anyone asked this question already.
What I had in mind was, can we come up with a "knowledge-map" of programming concepts similar to the map that Khan Academy uses.
As a programmer, I want to be able to visualize the dependencies and relationships between different ideas, so that I can understand what skill level I am currently at; what I need to know before tackling a challenging subject; and be able to visualize my progress.
The very belief in the roadmap's existence blocks the road to perfection.
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Have you ever tried learning a language while on a project? I have, and from my personal experience I can say that it takes courage, effort, time, thinking, lots of caffeine and no sleep. Sometimes this has to be done without choice, other times you choose to do it; if you are working on a personal project for example.
What I normally do in this kind of situation, and I believe everyone does, is "build" on top of my current knowledge of languages, structures, syntax and logic. What I find difficult to cope with, is the difference of integrity in some cases. Some languages offer a good background for future learning and "language study", they pose as a good source of information or a frame of reference and can give a "firm" grasp of what's to come. Other languages form or introduce a new way of thinking and are harder to get used to.
Sometimes you unintentionally think in a specific language and when introduced to a new way of thinking, a new language, can cause confusion or make you get lost between the "borders" of your new and your current knowledge of languages.
What can be a good solution in this case? What should be used to broaden the knowledge of the new language, a new way of thinking, and maintain or incorporate the current knowledge of other languages inside the "borders" of the new language?
I find I need to do a project to properly learn a language, but those can be personal projects. When I learned Python on the job, I first expected (and found) a significant slowdown in my productivity for a while. I read the standard tutorials, coding standards and I lurked on the Python list for a while, which gave me a much better idea of the best practices of the language.
Doing things like coding dojos and stuff when learning a language can help you get a feel for things. I just recently changed jobs and went back to Java, and I spent some time working on toy programs just to get back in the feel for things (I'm also reading Effective Java, 2nd edition as my previous major experience had been with Java 1.4).
I think, in some respects no matter what the impetus for learning the language, you have to start by imitating good patterns in the new language. Whether that means finding a good book, with excellent code examples, good on-line tutorials, or following the lead of a more experienced developer, you have to absorb what it means to write good code in a particular language first. Once you have developed a level of comfort, you can start branching out and and experimenting with alternatives to the patterns that you've learned, looking for ways to apply things you've learned from other languages, but keeping within the "rules" of the language. Eventually, you'll get to the point where you know you can 'break the rules" that you learned earlier because you have enough experience to know when they do/don't apply.
My personal preference, even when forced to learn a new language, is to start with some throw away code. Even starting from good tutorials, you'll undoubtedly write code that later you will look back on and not understand how stupid you could have been. I prefer, if possible, to write as my first foray into a language code that will be thrown away and not come back to haunt me later. The alternative is to spend a lot of time refactoring as you learn more and more. Eventually, you'll end up doing this, too.
I would like to mention ALT.NET here
Self-organizing, ad-hoc community of developers bound by a desire to improve ourselves, challenge assumptions, and help each other pursue excellence in the practice of software development.
So in the spirit of ALT.NET, it is challenging but useful to reach out of your comfort zone to learn new languages. Some things that really helped me are as follows:
Understand the history behind a language or script. Knowing evolution helps a lot.
Pick the right book. Research StackOverflow and Amazon.com to find the right book to help you ease the growing pains.
OOP is fairly common in most of the mature languages, so you can skip many of the chapters related to OOP in many books. Syntax learning will be a gradual process. I commonly bookmark some quick handy guides for that.
Read as many community forums as possible to understand the common pitfalls of the new language.
Attend some local meetups to interact with the community and share your pains.
Take one pitch at a time by building small not so complicated applications and thereby gaining momentum.
Make sure you create a reference frame for what you need to learn. Things like how security, logging, multithreading are handled.
Be Open minded, you can be critical, but if you hate something then do not learn that language.
Finally, I think it is worthwhile to learn one strong languages like C# or Java, one functional language and one scripting language like ruby or python.
These things helped me tremendously and I think will help all software engineers and architects to really gear for any development environment.
I learned PHP after I was hired to be the project lead on the Zend Framework project.
It helped that I had 20 years of professional programming background, and good knowledge of C, Java, Perl, JavaScript, SQL, etc. I've also gravitated towards dynamic scripting languages for most of my career. I've written applications in awk, frameworks in shell, macro packages in troff, I even wrote a forum using only sed.
Things to help learn a language on the job:
Reading code and documentation.
Listening to mailing lists and blogs of the community.
Talking to experts in the language, fortunately several of whom were my immediate teammates.
Writing practice code, and asked for code reviews and coaching.(Zend_Console_Getopt was my first significant PHP contribution).
Learning the tools that go along with the language. PHPUnit, Xdebug, phpDoc, phing, etc.
Of course I did apply what I knew from other programming languages. Many computer science concepts are language-universal. The differences of a given language are often simply idiomatic, a way of stating something that can be done another way in another language. This is especially true for languages like Perl or PHP, which both borrow a lot of idioms from earlier languages.
It also helped that I took courses in Compiler Design in college. Having a good foundation in how languages are constructed makes it easier to pick up new languages. At some level, they're all just ways of abstracting runtime stacks and object references.
If you're a junior member of the team and don't know the language, this is not necessarily an issue at all. As long as there is some code review and supervision, you can be a productive.
Language syntax is one issue, but architectural differences are a more important concern. Many languages are also development platforms, and if you don't have experience with the platform, you don't know how to create a viable solution architecture. So if you're the project lead or working solo, you'd better have some experience on the platform before you do your design work.
For example, I would say an experienced C# coder with no VB experience would probably survive a VB.NET project just fine. In fact, it would be more difficult for a developer who only had experience in C#/ASP.NET to complete a C# WPF project than a VB ASP.NET project. An experienced PHP developer might hesitate a bit on a ColdFusion project, but they probably won't make any serious blunders because they are familiar with a script based web development architecture.
Many concepts, such as object modelling and database query strategies, translate just fine between languages. But there is always a learning curve for a new platform, and sometimes it can be quite nasty. The worst case is that the project must be thrown out because the architure is too wrong to refactor.
I like to learn a new language while working on a project, because a real project will usually force me to learn aspects of the language that I might otherwise skip. One of the first things I like to to is read code in that language, and jump in. I find resources (such as books and various internet sites) to help as I go along.
Then, after I've been working on it for a while, I like to read (or re-read) books or other resources on the language. By this time I have some knowledge, so this will help solidify some things and also point out areas where I am flat-out wrong in my understanding. For instance, I can see that I was making incorrect assumptions about similarities between languages.
This also applies to tools -- after using a tool for a while and learning the basics, reading (or skimming) the documentation can teach me a lot.
In my opinion, you should try to avoid that. I know, most of the times you can't but in any case try not to mix the new language with the old one, and never add to the mixture old habits, practices and patterns.
Always try to find resources that will help you get through the new language in the way the language works, not in the way other languages do; that will never have a happy ending, and if it does it will be very hard to modify it to the right way.
Cheers.
Yes I have.
I mean, is there another way? The only language I ever learned that was not on a project was ABC basic, which was what you used on my first computer.
I would recommend if you start with a certain language, stick with it. I only say that because many times in the past I tried more and more different ones, and the one I started out with was the best :D
Everytime I have/want to learn a new language, I force myself to find something to code.
But to be sure I did it well, I always want to be able to check my code and what it ouputs.
To do so, I just try to do the same kind of stuff with languages I know and to compare the outputs. For that, I created a little project (hosted on Github) with an exercise sheet and the correction for every language I learnt. It's a good way to learn in my opinion because it gives you a real little project.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I've been programming for several years now and since then I have learned several concepts and techniques that have made me a better programmer (i.e. OOP, MVC, regex, hashing, etc). I feel too that by been able to learn several languages (basic, pascal, C/C++, lisp, prolog, python) I have widen my horizons in a very possitive way. But since some time ago I feel like I'm not learning any new good "trick". Can you suggest some interesting concept/technique/trick that could make me retake the learning flow?
A good paradigm shift always allows you to see things differently and become a better developer. I would suggest you read up on functional programming and maybe learn a functional language like Haskell or Scheme.
YAGNI (You Ain't Gonna Need It) and DTSTTCPW (Do The Simplest Thing That Could Possibly Work)
It's easy to spend a lot of time thinking about edge cases, and find that you've implemented something that's completely useless. I believe that a far better approach is to knock out a simple prototype, and then poke and prod it until you understand the domain well enough to create production code.
Recognize, however, that your prototype is going to evolve into production code whether you like it or not. So write it with that in mind.
Learning how to use your IDE and tools. This to me resulted in a far greater productivity increase.
For examples:
learning how to use a source level debugger
using tools like purify/boundschecker
fxcop
etc. I realize I am dating myself, but those were big steps. There are many more.
Any time you can change the way you think about a problem or solve a problem without having to undo previous work is HUGE gain. Process, tools, etc all can help with that. Don't limit yourself to finding silver bullet techniques for productivity gains.
Watching productive people work and getting them to tell you what they are doing and why is also invaluable.
If I'm honest, using, and learning a great framework like .NET has really increased my productivity.
I'm often amazed what people are willing to reinvent due to their ignorance that the very same function already exists in the framework.
AGILE and especially Test Driven Development. Best thing to happen to software development since the invention of Object Oriented Design.
Concerning coding, I'd say design patterns and architecture patterns are always nice to look at and can help you write cleaner/better code.
For methodology I would advice Agile development that is great. There are a numerous number of techniques and methods (I'm personally fan of extreme programming) and reading that can keep you busy and improve your general approach.
Finally I'd say learn new languages like Ruby
Design patterns
SCRUM process
DiSC assessment (and understanding of how it applies to collaborative s/w development)
StackOverflow.com (of course!)
Google
... other stuff too, I'm sure
Design Patterns. Learning how to break dependence upon implementation and inheritance, and depending on interfaces (contracts) instead changed the way I think about programming.
Debugging. Once I figured out how to actually step through the code and go line-by-line, examining the underlying state, it revolutionized how I troubleshoot code.
Practice, practice practice: I didn't realize how important it is to keep working on my skills apart from work until a relatively short time ago. Mistakes and solutions I make at home make me a better programmer at work, and vice a versa. Learning should never stop if you want to be good at something, and programming isn't an exception.
If I had to pick just one, I'd say Test-Driven Design, aka TDD: write unit tests (and check that they fail) before you incrementally add features.
Try to learn to see things from the user's standpoint.
For example:
learn how to write meaningful error messages
learn how to produce usable applications
learn some basic speed-optimization techniques
Remember that the user sees your application, not your code.
VIM Quick Reference Card. After I started using advanced vim (macros, plugins) I have stopped doing any repetitive actions during coding manually.
Apart from that, Scrum and working at night, when noone interrupts You gave me the highest benefit.
If you want to expand your experience into web programming, you should try and get a good handle on the HTTP Request/Response paradigm. This will make creating web apps much easier on you because you understand the underlying framework.
(http)://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
I would look at some of the newer languages that combine OO and functional elements, like C# or Scala.
Learning Smalltalk has helped me become more productive. It is an easy language to learn and things can be built extremely quickly. For a stunning productivity aid check out Seaside, it's a framework for building web applications. Moreover, if you have only been used to curly brace languages Smalltalk will also make you smile!
I was helped by the following paradigms in this order:
1) bottom-up programming
2) top-down programming (C, Pascal)
3) object-oriented programming (Smalltalk, Java)
4) functional programming (lisp, Mathematica)
with some logic programming thrown in (prolog).
nHibernate hands down. The fact that I dont need to write database functionality for my business objects is very useful and time saving.
High level understanding, creating good abstractions with proper dependencies, is what pays off in long term. For example, Law of Demeter is an important guideline. I recommend also reading Eric Evan's Domain Driven Design
Code generators. They're the best thing in software engineering.
Would you like to write all your projects in asm? Nope, let's generate it from C++. Or from something sat above the JVM which diligently generates the necessary machine code.
Duplicating the same source code all over the place, but stuck with a language that insists on the line noise? Use macros.
Want to use lambdas in a language that doesn't have them? Work out how to fake the anonymous name and variable scoping required then generate the boilerplate.
None of the readily available languages quite fit your pattern of thought, desired syntax or even semantics? Write a compiler for a new one.
Better languages are nice. Better design patterns are nice. Emacs is awesome. But compilers are where all the power lies in our field. I suspect the only reason they aren't mentioned in any of the other answers is that we can't imagine programming without any.
Copy/paste technique
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.