您使用新技术或编程语言的标准

Question

What are your criteria or things that you consider when you are an early adopter of a programming language or technology?

Two of the most common explanations I've heard are:

1. It should be "fun" (what I've heard from technical people).
2. It should be capable of solving our problem (what I've heard from business people).

So what's yours?

Answer 1

I've made this change several times over my career spanning various companies, moving from C to Java to Ruby to Haskell for the majority of my software development.

In all cases, I've been looking for more expressive power and better abstractions. This is always driven by business needs: how can I develop better software more cheaply? To me, the challenge of this problem is "fun," so fun rather automatically comes along with it. Justifying the business value to managers can be difficult, however; they often don't have the technical skills to understand why one programming language can be better than another, and are worried about moving to technology that they understand even less than the current one. (I solved this problem by taking over the manager's job as well: I started a company.)

It's hard to say what exactly to look for in a new language. You obviously don't have a detailed grasp of the language, or you would already be using it or know why you're not. Vast experience will bring an instinct that will make certain languages "smell" better than others, but—and this can make it especially hard to convince others to look at a new language—you won't know precisely what features give you big advantages. An example would be pattern matching: it's a feature found in relatively few languages, and though I knew about it, I had no idea when I started in with Haskell that this would be a key contributor to productivity improvement.

While it's negative ("avoid this") advice rather than positive ("do this") advice, one fairly easy rule is to avoid spending a lot of time on languages very similar to ones you already know well. If you already know Ruby, learning Python is not likely to teach you much in the way of big new things; C# and Java would be another example. (Although C# is starting to get a few interesting features that Java doesn't have.)

Looking at what the academic community is doing with a language may be helpful. If it's a fertile area of research for academics, there's almost certainly going to be interesting stuff in there, whereas if it's not it's quite possible that there's nothing interesting there to learn.

Answer 2

My criteria is simple:

• wow factor
• simple
• gets things done
• quick

Answer 3

I want it to do something easily that is hard to do with the tools I'm used to. So I moved to Python, and then Ruby, over Java because I could build a program incrementally, add functions easily, and express programs more concisely (esp. with Ruby, where I can pass blocks/Procs and have clean closures, plus the ability to define nice DSLs making use of blocks and yield.)

I took up Erlang because it expresses Actor-based concurrency well; this makes for easier network programs.

I took up Haskell because it fit with a number of formal methods tools I wanted to experiment with.

Answer 4

1. Open source.
2. Active developer community
3. Active user community, with a friendly mailing list or forum.
4. Some examples and documentation, preferably a tutorial
5. Desirable features (solves problems).

Answer 5

If it's for my personal fun, I need very little excuse, as I do love learning new things, and the best way of learning is by doing. If it's for an employer, customer, or client, the bar is MUCH higher -- I must be convinced that the "new stuff", even after accounting for ramp-up effects and the costs that come with being at the bleeding edge , will do a substantially better job at delivering value to the client (or customer or employer). It's a matter of professional attitude: my job's to deliver top value to the client -- having fun while so doing is auxiliary and secondary. So, in practice, "new" technologies (including languages) that I introduce in a professional setting will generally be ones I've previously grown comfortable and confident with in my own spare time.

Answer 6

Someone has once said something to the effect of:

"If learning a programming language doesn't change the way you think about programming, it's not worth learning."

That's one metric (out of many) to judge the value of learning new languages (or other technology) by. Using this, one might suggest learning the following languages:

• C, because it makes you understand the Von Neumann architecture better than any other language (and it's sort-of random-access Turing Machine like, sorta'...).
• LaTeX (as a programming language, not only as a typesetting system) because it makes you learn about string rewriting systems as a model of computation. Here, sed is similar; learn both, because they're also both useful tools :-)
• Haskell, because it teaches you about functional programming, lambda calculus (yet another model of computation), lazy evaluation, type inference, algebraic datatypes (done with ease), decidability of type systems (ie learn to fear C++)
• Scheme `(or (another) ,Lisp) for its macro system, and dynamic typing, and functional programming done somewhat differently.
• SmallTalk, to learn Object-orientation (so I hear)
• Java, to learn what earning money feels like :D
• Forth, because wisdom bestowed forth learned implies .

... that doesn't explain why I learn python or shell scripting, though. I think you should take enlightenment with a grain of salt and a shovelful of pragmatism :)

Answer 7

1. Should be capable of solving the problem
2. Should be more adequate to solve the problem than other alternatives
3. Should be fun
4. Should have prompt support, either from a community or the company promoting it

Answer 8

A language should be:

1. Easy to use, to learn and to code in.
2. Consistent. Many languages have 50 legacy ways of doing things, this increases the learning curve and turns quite annoying. C# for me is one of those languages.
3. It should provide the most useful solution with the least amount of code. On the other hand sometimes you do need a bit of expressiveness to make sure you're not making a huge mistake.
4. The right tool for the right job and maybe the right tool for any job

Answer 9

My criteria that the language should have:
1. New ideas - If the language is just another Scheme variant, if you know one than I don't feel the need to learn this new one. I will learn it if I think I will learn something new.
2. Similar to another language, but better. For example, while Java and C++ have many of the same ideas, Java's automatic garbage collection makes it a better choice in many cases.

Answer 10

• Gets the most done with the least amount of effort
• Extremely interoperable with different protocols, out of the box
• Fast
• Has lots of libraries built in for stuff 99% of web developers do (PDF's, emailing, reporting, etc..)

Answer 11

It depends on why I'm learning the new language. If I'm learning it for fun, then it has to meet these criteria:

1. Is well it supported on my platform? Something that runs only on Linux isn't interesting to a Windows programmer.
2. Will I learn something new? In other words, does it come up with a new way of doing things?
3. Does it look fun? I don't want to learn Ada even if it has new ways of doing things.

If I'm learning it for work, the criteria are different:

1. How mature is it? Has it been proven to work in the real world?
2. How big is the community?
3. Will it make my job easier? Ie is it worth the time investment versus just doing the task with a language I already know.