Related
I am wondering what are some specific questions I should keep in mind when I am comparing programming languages for use on given work projects. For instance, I am told logic programming languages like Prolog are good for natural language processing. I'm not sure why exactly; I assume it is true because experts say so, but I don't know the consideration that guides them to that conclusion. So I am looking for a simple heuristic, a checklist of questions, I can apply to evaluate programming languages and be able to explain my decisions, so that I can say "Language X is good for Y because it does Z."
The only way I know of to figure out which programming language is most appropriate for a given problem, is to know lots of programming languages. After all, if you don't know screwdrivers exist, how will you know not to use a hammer when you encounter a screw?
Unfortunately, there are thousands (maybe tens of thousands) of programming languages, so learning even a significant portion of them is just not realistic.
However, programming languages implement paradigms. And Peter van Roy's famous poster only lists about 34 of those. Although he deliberately decided to ignore several aspects, including anything related to typing, so the real number is probably higher than that. But we can expect it to be well below 100.
That's still a lot, though, but thankfully, paradigms aren't atomic either, they are composed of concepts. The poster lists about a dozen of those (again ignoring typing and a couple of other things). Significantly less than paradigms.
Learning a significant portion of concepts is entirely feasible. Once you know them, you can look at a problem and see which concepts would be useful to have to build a solution. Then you look at which paradigms contain those concepts and which languages implement those paradigms. Pick one, learn it, use it, solve the problem.
And since you already know the concepts (and thus the paradigms) the language implements, you only need to learn the syntax, not the semantics. There aren't actually that many different syntaxes in the wild (C, C++, Objective-C, Objective-C++, D, Go, Java, C#, ECMAScript, PHP, Vala and many others share a lot of syntax, for example, as do Smalltalk, Self, Newspeak and Objective-C, SML, OCaml and F#, and so on), so chances are, you'll pick that up very quickly. (Besides, with today's modern IDEs that's much less of an issue anyway.)
One small point to bear in mind: if you are an expert in language X and you are asked to develop a program in domain Y for which language Z is supposed to be ideal -- will you deliver sooner and better by writing in the language you are an expert in even if it is not (by some measures) ideal for the problem domain ? Or will you deliver better and sooner by first learning a new language ?
I think your search for a simple heuristic is in vain.
Start with what you're team is familiar with. While there's a lot to be said for the philosophy that a great developer can pick up almost any language in short order, there's a practical side that goes to the fact that if you have a ton of .Net or Java coders, you're best served in starting from that base.
Now, within both stacks you have options on things like functional programming (F#, Erlang, etc.) and other languages on the runtime your team is most familiar with. But it really does boil down to the culture, infrastructure, and (most importantly) the experience and flexibility of the individual developers on your team.
There are several factors to consider:
What is your local expertise? If you have a company full of C programmers, it's probably not worth retraining everybody to be Lisp programmers.
What are your libraries? If you have libraries that you want to use, make sure that they are compatible with your language of choice.
If you are starting a new project with a wide-open field of options, I would recommend taking a few sample problems out of the application domain. Nothing too complex, but nothing trivial either. Then, implement (or have someone from your team implement) these samples in each candidate language. Then, choose the one that is clear, easy, and appropriate.
I'm something of a programming language junkie, and examples abound...
Lisp was originally created as a practical mathematical notation for computer programs
Simula was designed for doing simulations, and gave us objects and classes
C was designed for implementing system software (specifically, the Unix operating system)
Erlang was designed with the aim of improving the development of telephony applications at Ericsson.
Languages like Perl and Ruby also, but these four gave birth to fundamental styles of computer programming, as opposed to "just" implementing an existing methodology or style of solving specific software engineering problems.
Is every new programming paradigm primarily driven by a need to solve a practical problem? Does every new programming language come about from a programmer scratching an itch?
As I plan to dedicate my life to research in new programming languages for AI, I'm wondering whether I should pursue the theory of programming intelligence directly, or attempt to solve practical problems in AI and then "discover" the paradigms to solve them.
No, most are. But you're forgetting Esoteric programming languages.
Example: http://www.dangermouse.net/esoteric/piet.html
A language that uses JPG's as code.
I think that every language is designed according to some need. That need of course can just be the language designers own desire for a more elegant language, a language he himself feels more comfortable programming in.
However, the language that are successful will very likely provide some solutions to a more general need. This need my not necesarely be evident at the time the language is designed, but for it to get recognition I think it has to be a need that is shared and gets shelved out as a general desire at some point.
There are probably a lot of languages out there that did not necessarely address a problem that is shared by many others or maybe even adresses needs that have not been wiledly realized as such.
To you concrete question: I think the best way to discover the shortcomings of current languages is to use them. Of course, the theory may help you to come up with appropriate solutions. So I'd say the best way is (as always) to have theoretical knowledge and practical experience.
You'd think nobody would invest time in inventing, refining, implementing, using and spreading a new way of doing things if "the old ways" worked just fine. And the real world, as in your examples, confirms this theory. All this still applies if we broaden the scope beyond programming paradigms. So I'd say it is safe to assume inventions are (partly) driven by a need for the thing invented.
*hits his smartass alter ego with a bat and takes over the talk*
As for the question in the last paragraph: If anyone knows whether you'll have more fun pursuing theory or solving real problems, it's you. I would choose practice any time of the day - but I'm not you. But from looking at (programming language) history I can tell that all no great (i.e. can be used to get things done) language came from theory. It is logical to assume one can't find a good tool for an application without knowing that application throughoutly from daily work.
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 11 years ago.
I have read numerous time that learning a language such as Haskell, Lisp or Smalltalk will somehow make you a better programmer while you program in other languages.
Is there more than just anecdotal evidence for that claim?
Or is it just the way people rationalize having spend a lot of time learning a programming language that they will never use?
IMHO, it is all about learning a new programming paradigm. If you know Java and then C#, there's not much gain, once both of them have almost the same "type of programming".
But if you get to learn a functional language or dynamic, for instance, you're forced to think another way, and that will probably help you to program better in your favorite language.
It is something like: "It is so easy doing this in {different language you learned}. There must be a better way to do this in {language you already know}". And then you rethink, and build up a more elegant way to do this in {language you already know}.
I don't have any hard evidence, but I have really appreciated the different way of looking at problems that I have since learning lisp (the same goes for python and c).
The key isn't necessarily learning different languages though, I believe that the key is actually the different viewpoints that you gain by learning different programming styles.
Good examples are functional, imperative, object-oriented, etc. Also, there are common design differences is interpreted vs compiled languages; static vs dynamic typing, etc.
Although most people do a majority of their programming using a single style (most commonly OOP over the past few years), I think that all programmers should know multiple styles so that they are better able to see the shortfalls of their own style.
Can't shed much light on this in terms of programming languages, but it seems very similar to the "why learn a dead language?" argument that surrounds Latin, and much of the reasoning there can be applied here.
Programming is a way of thinking, not writing code in programming language X: that is "coding", not "programming".
By knowing at least something about more than just one programming language - preferably across different paradigms, so imperative/OOP/functional/logical - you train that way of thinking about problems outside the context of the specific details and quirks of language X.
I think this always improves your abilities to be(come) a better programmer tremendously.
A great side-effect of learning new languages is the potential for application in your existing language.
For instance, I'm a Java programmer and I took the time to learn my first functional language (Haskell). I was recently asked to learn Scala for an upcoming project. This is extremely easy since I understand the comcepts of guards, recursion, etc. from Haskell.
Deeply learning language just for learning language has too little benefits. If you have a lot of tasks and you don't know language that ideal for solving it then it is make sense to learn that language. Otherwise it is make sense to spend the time to become expert in languages you already know.
I don't know that there will have been much rigorous study regarding the benefits of multi-programming language exposure on overall programming ability, but I would argue that the studies regarding why learning a foreign human language (which you may never use in practice) is beneficial would in general hold equally well for studying foreign programming languages. The benefits ascribed often include improved cognitive abilities as well as improved understanding of one's native language.
here's some links to studies
anecdotally, I complained a great deal about taking COBOL, and have never really used it but was able to apply things I learned in that class at my first job.
If you give any credence to the Pragmatic Programming guys, consider their advice from page 14 of their first book:
Learn at least one new language every year. Different languages
solve the same problems in different ways. By learning several
different approaches, you can help broaden your thinking and avoid
getting stuck in a rut.
Some examples that come to mind:
Knowing C and having to deal with memory management and do-it-yourself data structures can help you understand performance issues when programming in a higher level language where those details are hidden from you.
Conversely, learning an OO language can affect your C programming - with, for example, the concept of Polymorphism prompting you to use function pointers in ways you might not have otherwise.
Learning a language where functions are first class objects that can be passed around can make you think of similar techniques in other languages, even if, in those other languages, you have to make the functions methods in objects that get passed around.
Learning about the way Erlang handles concurrency can make you rethink how much shared state you use between threads in other languages.
Any language that has a built-in feature you find useful can prompt you to implement your own version of that feature in another language that doesn't have it, and thus allow you to solve problems in ways you might not have thought of if you hadn't been exposed to the feature in the language that has it built-in.
Learning about Interfaces in Java can make you think about the benefits of precisely specifying your (small "i") interfaces in other languages that don't have them as a formal construct in a type system.
No doubt there are others.
Learning a language is not a binary event. If you are a decent programmer, you should be able to trust your own instincts as to whether a language offers you a new take on your craft.
Virtually every language worth considering these days can be downloaded and test-driven in a couple of minutes. So do it -- pick one and try it out.
There are a limited number of cases where this "laissez-faire" approach falls short. If you're a complete beginner, of course it doesn't work. When I first learned C, I had to have it beaten into me, but it did turn out to be worth it because it made me understand pointers, memory reference and dynamic allocation in a way I hadn't previously.
But if you know that much already, just poke around and look for a language that makes your lightbulb go on.
Different languages have different ways of implementing the same ideas. By learning new languages, you get a different perspective on how things can be accomplished, and can then use that knowledge to approach how you program in your current environment. Think about object oriented and functional programming. OO Programmers can learn a lot about parrellization from languages like C.
Learning a language, especially one that practices a new paradigm, is very beneficial for every programmer. For example learning Scheme will help someone understand functional programming. The programmer can later practice what he/she learned with other languages like C#. She can think of new ways of doing things.
Also, as languages evolve, it's high likely that the language you use will adopt some features of other languages. Having taught myself Ruby, I was able to grasp the changes in C# 3.0 much easier.
I think learning languages will always benefit you even if you don't use them again. I started playing with Ioke as an attempt to learn something experimental and because of it my JavaScript has improved because certain ideas have been cemented.
learning a new language will possibly give you new insights that you will try translate to your main language.
I don't think there will be any hard evidence--I think this is more of an intuitive thing. Learning a totally different language will help you look at things totally different. Or maybe it won't. In any case, what's the harm in learning something?
It's entirely subjective, but way back when, after taking an undergraduate course in Haskell, I did notice that my programming style in C became more 'Haskell-like' for a while; I used a lot of simple, recursive functions. I also noticed that this programming style seemed to yield some of the same benefits programming in Haskell had; bugs were fewer, code was easier to understand (albeit slower).
So, while learning another programming language may not make everyone a better programmer, it definitely was a learning experience for me, personally.
What are the benefits of learning mathematics or physics that you won't use, or the benefits of studying philosophy or dead tongues?
It's the intellectual achievement and the enlightenment what matters, you will be a wiser person with any new thing that you learn, no matter if they are programming languages, literature, role playing games... of course if it's related to your working field, then you'll actually find a use, sooner or later :-)
I spent some time studying clojure even though I knew I wouldn't use it in the near-term (mostly because I can't really deploy on the JVM).
It has concepts that aren't supported by the languages I use (C#/C/C++/Python/Perl) and I wanted to know what I was missing and also if it would be worth looking into libraries that purport to add these features.
Specifically, I'm very interested in understanding Lisp-style macros and the direct concurrency support. I also spent some time reading the implementation, specifically the datastructures, which was very educational -- good to see a quality implementation of persistent datastructures to learn how they work (and give you immutability without sacrificing much performance).
Bryond what has already been said, I really like new languages just because it can bring new interest to programming. You learn different ways to approach problems and the strengths/weaknesses of certain languages. It is something new to learn and any good programmer should be striving to always be learning new things. It mixes up your daily routine of possibly programming in the same language for years.
I also like what everyone has said about programming perspective.
Some good points have been made.
I would add that learning languages you won't use in production work can be of value
To better appreciate and absorb the arguments and methods in texts and papers that will improve programming ability in languages I do use for production work (e.g. MIX/MMIX for Knuth's Art of Computer Programming; RATFOR for Kernighan and Plauger's Software Tools; I still use some ALGOL-based syntax for some pseudocode although I never wrote runnable code in ALGOL outside University)
To be able to check or prototype programs that will be written in a different language (e.g. some routines for numerical computing in C can be quickly checked or scaled using languages that have appropriate functionality built in such as Fortran, Python or Haskell)
Learning a new language can give insight as to how it could be used to more easily solve problems that were put to one side because of time or complexity constraints.
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.
I have no programming experience but am interested in learning a language.
So reading this section "http://wiki.freaks-unidos.net/weblogs/azul/principles-of-software#extend-your-language-to-match-your-domain" made me curious about programming a single application in 2 or more languages.
How is it actually done?
A few thoughts:
The page you linked to explains pretty clearly how it's done
If you are interested in learning a language, this is probably not the place to start
Programing a single application in two or more languages is only marginally related to the linked document.
Still, in the face of all that, I'll try to give an example of how this works by analogy.
Suppose you need to work with a group of people on some technical task--ranking chess puzzles by difficulty or testing marshmallows for contamination or something. Suppose further that one of the people on your team speaks only Japanese, another only Portuguese, and the third only Esperanto.
Being blessed with the ability to speak all of these languages fluently, your best bet is to make up an artificial language specialized to the task at hand; this is called a Domain Specific Language, or DSL. It should have all the terminology you need to talk about knights and rooks or silicate nanoparticles or whatever for the task, and not much else. Teach this to each of your team members, and then you can give them all their instructions at the same time. They can talk to each other about what they are doing, ask for help (so long as it's related to something covered by your language) as if they all spoke the same language.
That's roughly what he's talking about.
I think you may be trying to run before you can walk. The concepts in there probably require a little programming experience to start with.
The thrust of the article (and frankly poorly expressed) is that when you are programming you often encounter tasks that benefit from a declarative syntax, i.e. you should be able to express the intent of what you want to do and leave the implementation details to a library. A good example is querying a database, it's much more readable (usually) to be able to declaratively describe what you want to do and let some middleware figure out the best way to do it, SQL and Linq are 2 examples of a declarative mechanism for querying data.
This is a very interesting topic, but honestly if you have no programming experience it's probably more of a 201 subject than a 101 subject, get your basics down first.