I've taken courses, studied, and even developed a little by myself, but so far, i've only worked with Microsoft technologies, and until now I have no problems with it.
I recently got a job in a Microsoft gold partner company for development in C#, VB.net and asp.net.
I'd like tips on how to diversify, learning technologies other than those from Microsoft. Not necessarely for finding another job, I think my job just fits me for my current interests. I think that by learning by myself other languages, frameworks, databases.. I may become a better programmer as a whole and (maybe) at the end of it all having more options of job opportunities, choosing what i'm going to be working with.
What should I start with? how should I do it?
If you're comfortable with C# and VB, learn a language that uses different paradigms. The usual suspects would be Ruby, Erlang, Haskell, Lisp. All of these are available for Windows and other platforms. You might have to get used to different tools to interact with them but that's not necessarily a bad thing.
At the risk of sounding trite, why not install some variant of Linux on a cheap desktop? The mere act of setting up a Linux box is educational.
Once you find your way around it, do some shell scripting and install things like a web server. That should keep you busy for a while. Once you past that, play with some dynamic languages like perl, ruby, python, PHP, etc.
If you're interested in other languages, just pick one and away you go. You sound like you have enough experience to be apt in another language.
If you're looking into a new desktop-development-language then I'd recommend Java or Python, both of which you'd ease into with your C# and VB.NET experience.
If you're looking into web programming, go for PHP?
Browse some source
examples and see what catches your
eye as the most interesting.
Pick up a book on that language.
Ideally, one should know at least one example from each of the major "paradigms":
Assembly (nowadays a dying art, and not that useful)
plain C
one of the OO-variants of C (C++, objective C)
Java or C# (they are very similar, probably no need to learn both)
a scripting language like Ruby or Perl
Javascript (preferrably via Crockford's book)
a non-pure functional language, e.g Scheme (PLT Scheme is a nice learning environment)
a pure-functionalal language like Haskell or OCAML
Erlang (somewhat of a class of its own)
a mathematical/statistical language like R, or J (an APL-successor)
Microsoft technologies aren't bad to start with. My advice would be:
Make sure you aquire sound knowledge about the foundations of programming and the technologies you use. The more basics you know, the more independent you'll be from the latest fads:
Read "Windows Internals" to understand the operating system you're working with. In the process, you will understand other operating systems a lot better.
Toy around with other languages. Learn the differences between statically-typed languages and duct-type languages, functional programming languages, iterative programming languages whatever.
Learn the language you use the best you can. Become John Skeet!
In other words, don't move sideways first. Dig deeper and become better at understanding what you do.
It would be a nice idea to get associated with one the open source programm on http://sf.net. That way you can even have your learning for new platform and also produce some legitimate code. Also you get to look at some good coding practices. Last but not least some giving back to the software community
Maybe think of a project that would be of use to you in your daily life and see if you could develop that in a suitable language. That way you have a goal and at the end of the project you have something useful.
Alternatively why not try learing something not directly programming related, project management might be of use for future roles or do some reading about the history of technology.
These won't add any new languages to your CV but they might add some different aspects to your thinking that might make you a more well rounded potential employee.
I see two main directions to go:
Specific technologies. Select these depending upon how you want to extend yourself, new language (perhaps scripting if you haven't done that, perhaps functional programming), or new techniques (for example, UI programming, or low-level network programming depending upon what you haven't already done), or new OS (Linux if you're a Windows person).
Or, look at higher level problems, for example Design Methods and Team organisation. Read books such as Brooks' Mythical Man Month and Beck's Extreme Pogramming. Consider how to deal with problems bigger that can be solved by one person. Read up on (Rational) Unified Process, UML. Explore revision control systems, Testing techniques, not just Unit Test, but otehr flavours. Think about how you would organise a team if you were the leader. How would the tasks be subdivided, how would communication be managed?
Related
Our business currently revolves around the development of a library, which can be used in a wide spectrum of industries (desktop, mobile, web and embedded). At the moment we only have customers within the desktop and web world and we already see that we are basically having to duplicate our code across multiple languages (c#, java and c++). How is this typically managed in other companies, do we really have to settle for having our middleware written in multiple languages to meet very different industries.
We have tried c# interop along with with java jni but the results where not as good as we had expected and it didn't seem like a good and professional solution.
Anyone have any ideas how we could keep the core in a single language but develop interfaces in different languages allowing for the different industries.
I have not a lot of ideas when it comes to industry, but I guess that the problem is similar to other not-so-strict scenarios. It is unclear also what do you mean by "middleware". Anyway, I would souggest you to not duplicate code and effectively have, if needed, multiple interfaces to the other languages.
In an ideal scenario, it would be very convenient to have one isolated process with your application logic, written in whatever language you feel more comfortable, and have this process to communicate using some inter-process-communication mechanisms (e.g., pipes, sockets, shared memory, files) with thin client-libraries which could be use by the clients in the other languages. That way, you are forced to create a very clean communication/usage protocol and to have some separation of concerns (because all the communication has to be serialized); you gain in robustness (a fatal error in your application process or in your client does not necessarily means a crash in the other one) and you don't have to use ffi mechanisms, but rather things like sockets and pipes. Even more, if you decide to publish your comm. protocol, then third party developers can create wrappers in their exotic predilect language without need of direct linking/importing to your development components.
This kind of paradigm has been in use with success over the years in the unix world and softwares like Mathematica . In a similar move, the developers of java have made the java plugin to work out-of-browser, in a separated process, to reduce interop complexity.
Ah, I forgot, maybe you may use this: ICE (http://www.zeroc.com/overview.html). It is probably the lighter interop layer that you can use to communicate in a clean way java, c++, c#, python and a few others. They even have some embedding solution...
Pick common denominator standards: REST or SOAP/XML over HTTP can be consumed by a lot of languages, including both Java and C#.
You'll be saddled with heavyweight WS-* standards and lots of network latency, but if interoperability is your goal this is one way to achieve it.
Might take a look at the Haxe language. It "compiles" to a dozen other languages.
https://haxe.org/
Somebody please re-tag with appropriate tags
Hello,
This is my story but I guess it holds true for all programmers.
We begin programming with some simple Hello World program. We practice & add functions/classes to the program. But they still maintain the Hello World style. function calling some other functions standard library.
But when it comes to real world projects(I'm just familiar with OpenSource). Lot more other things come into picture. Then begins the hardships of this newbie programmer.
Project Flow:
Program is not running as expected. Make use of Debugger
Making use of third party libraries. Today, we have
library in every popular language for
almost everything we need.
Multiple persons working on same project. Using Version Control
Systems.
Project is growing big. Build Automation
Lot of people started using your application. You need to port it to
different platforms (operating
systems/architectures). Need for
Cross Compiliation
I don't know why but we need Unit Testing Framework and/or unit tests
What else???
The problem in this is the lack of knowledge of this newbie programmer about existence of these things.
What I mean is when I started looking into some real world projects(Opensource). I didn't know what is this? and why we need to do this?
$./configure
$make
$make install
Recently I became aware of the keyword "Build Automation". I was in need of some library which was available for linux but I needed it in windows. I didn't know that its called "Cross compilation" and tools like MinGW/MSYS exist for this purpose. I had to learn these things in the hard way. I wish some one has told me about existence of such things. That would have saved my lot of time.
Today I ran into performance problem and was feeling the need for something. I guess the thing I'm looking for is Profiler. Thanks to my involvement in opensource projects. Even though I didn't realized/felt the need for this, I'm aware of term Unit Testing.
Though this (hard)way of learning things has some big advantages like now, I'm able to figure out solution or some unknown thing very quickly & unlike my other friends I don't get struck at any point. But I hate the wastage of time involved. You do not believe how much I time I wasted in figuring out the Makefiles & Gnu Build System
So, what am I looking for this in this post?
Please complete the Project Flow. I want to see what all things are involved.
For each of the tasks in the Project Flow list. I want to see following information.
Most popular solutions/tools availabe.
Wikipedia list to all alternatives.
[optional] Suggest some good books/tutorials/guides for learning about this. Or link to relavent SO posts/tags.
I know somethings are language & OS specific. I would say we have only handful of major platforms Linux/Unix, Windows, Java, .NET and handful of major languages C, C++, Java, .NET, Python. Address these languages. Its more than sufficient.
Example:
Making use of libraries:
Libraries are distributed in any of the following forms
Source Distrubtion
Static Libraries(*.lib for windows / *.a for linux)
Dynamic Libraries (.dll for windows /.so for linux)
.NET assemblies
I don't know about java
Resources (Now, once I know the above info. I can search on my own for resources)
http://en.wikipedia.org/wiki/Library_(computing)
How To Write Shared Libraries
http://www.tenouk.com/ModuleBB.html
Note:
Please not that I'm not asking to suggest info on how to learn each of these things. I'm asking about what more such kind of things are involved and alternatives for each of them.
Your question seems to be too broad, but in comments you asked for examples of different methods. This would at least enable you to find some other pointers and make your own decisions.
Rational Unified Process (RUP)/Unified Process (UP)
eXtreme Programming (XP)
Scrum
Test Driven Development (TDD)/Behaviour Driven Development (BDD)
Lean Software development
Kanban
Feature Driven Development (FDD)
Those and many more are software development methods, which comprise of different principles, processes and roles. Most of them also come with some sets of practices for different purposes, e.g. ones you mention in your question. Those are quite widely used in real world, although many companies use different combinations and also some own processes and methods. What is not part of what is used so widely, but might give you some interesting views on development are formal methods, which are precise, but most of the time too unpractical.
Though I come from a purely PHP background on the web development side of programming, I have also spent much time with C# and C++ on the desktop.
I don't really want to spark any flame wars, but:
When should you use scripting languages over compiled languages for website development?
(and vice versa)
Just to clarify, for the sake of this question, I define a "scripting language" to mean an interpreted language like PHP, Python, or Ruby, and a "compiled language" to mean a strongly typed, compiled language like C#, C++, Java, or VB.
It depends :-)
On...
...where and how you want to deploy the application
...the skillsets of the engineers in your organization
...what third-party components you want to integrate with or incorporate
Deployment
If you need to be able to deploy the solution on any of dozens of different possible platforms, you may find that you're better off with PHP than Java (for example). There are hundreds of thousands of Java hosting providers out there, but there are probably millions of PHP hosting providers. (And I say this as a Java-head who finds PHP "so so" at best.)
This goes to OS as well. Mono aside, .Net stuff is going to limit you to Windows-based deployment (or lagging behind the cutting edge and having to very, very rigorously test each and every 3rd party component you bring in, to ensure that it doesn't have Mono...issues).
Skillsets
Coming up to speed in an environment or language is non-trivial. For most of us, picking up the basics is pretty quick, but you may not be making the best architectural/design decisions because you're (comparatively) weak on the environment/language. Skillsets count.
Related to this: Skillset hiring counts. Is it easier (and/or cheaper) to hire PHP devs with 3-4 years of experience, or Java devs with 3-4 years of experience, or C# devs, or...?
Buying/finding/integrating vs. building
In your target area of development, which server-side components or packages will you want to integrate with? PHP has a vast array of things available for it, as does Java, as does C# or ASP.Net. But they're different things (by and large), so you'll want to look at what you actually want to use.
Conclusion
So I think it's less a matter of compiled vs. scripted (in today's world), and more a matter of what's the best fit by other criteria for what you're trying to do.
Addendum: Both/And
And of course, there's always "both/and". For instance, I do work in two main, unrelated environments right now, both using a combination of scripted and compiled resources. (One of them is Java + JavaScript via Rhino on Tomcat, the other is compiled COM objects + JScript [again, server-side] on IIS.)
A programmer can write good/bad fast/slow scalable/unscable code in any language. Although, some language and technologies make it harder to do. In my experience, with scripting languages you can produce a small to medium scale application faster than you can with compiled languages like Java. However, as applications grow in size, compiled languages become more suited to the task I think this comes from strongly typing objects, deeper layers of architecture to manage tasks, and more QA frameworks to verify things are running as they should be as changes occur.
I find it to be mostly a matter of opinion. At first I hated the pre-compiled web applications asp.net provides, but I've gotten used to it so I don't hate it anymore. It has advantages and disantages:
Pro
pre-compiled web applications are easy to deploy, often you'll only have to update the bin-directory
pre-compiled web applications perform well
you don't have to upload source code, which is nice imho.
Con
updating a pre-compiled web app generally means the web application is reset, so unless you've changed the session state, it'll end all sessions and log everyone out
rebuilding a large web application can take some time, which is added to the time it took you to write the changes in the first place. I am sometimes impatient.
I've always liked how easy it is to just update one file in a PHP project without having to rebuild a project or something like that, on the other hand, .net has a nice IDE that allows you to debug everying, from back end (C#, VB.net) to front end (Javascript), in one package.
But again; both have advantages and disadvantages.
I wouldn't draw such a sharp distinction between compiled and interpreted languages - this is really just an implementation detail, and tends to change with time (faster than the languages themselves change.) Case in point - thanks to Facebook, PHP is now a "compiled language" too. Another case in point - I enjoy web development with Scheme - and my preferred Scheme implementation now runs a VM and in that sense is at least as compiled as Java is.
So I think the issues to focus on are the expressiveness of the language, its performance, and its ease of deployment - compiled vs. interpreted is only important insofar as it relates to these things.
I'm a big fan of compiled languages everywhere, if for nothing more than the static typing. On the other hand, scripting languages are very convenient -- no binaries to deal with, only text files, which is a big win for web servers.
In the end, it doesn't really matter -- use whatever language you know and feel most comfortable with for the job.
I think that speed is a key concern in a web application, in particular
how fast is it to write my code
how fast is it to fix my code
how fast is it to refactor my code
how fast is it to test my code
That is, I am concerned about the speed of the slowest link: myself. Anything else is fast enough for Twitter-like loads.
Today, the number one on my evaluation list for a new project would be Tornado and Python.
If I had a choice of platforms, of course.
Ah, Python is among the fastest in scripting languages.
For scripting languages, anyone that has a copy of your software could potentially modify your source code because it's open source.
For programming languages, anyone that has a copy the software cannot simply modify your source code because it is compiled.
So I guess, it depends upon your preferences.
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:
It should be "fun" (what I've heard from technical people).
It should be capable of solving our problem (what I've heard from business people).
So what's yours?
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.
My criteria is simple:
wow factor
simple
gets things done
quick
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.
Open source.
Active developer community
Active user community, with a friendly mailing list or forum.
Some examples and documentation, preferably a tutorial
Desirable features (solves problems).
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.
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 (i.e. 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 :)
Should be capable of solving the problem
Should be more adequate to solve the problem than other alternatives
Should be fun
Should have prompt support, either from a community or the company promoting it
A language should be:
Easy to use, to learn and to code in.
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.
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.
The right tool for the right job and maybe the right tool for any job
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.
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..)
It depends on why I'm learning the new language. If I'm learning it for fun, then it has to meet these criteria:
Is well it supported on my platform?
Something that runs only on Linux
isn't interesting to a Windows
programmer.
Will I learn something new? In
other words, does it come up with a
new way of doing things?
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:
How mature is it? Has it been
proven to work in the real world?
How big is the community?
Will it make my job easier? I.e. is
it worth the time investment versus
just doing the task with a language
I already know.
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 7 years ago.
Improve this question
I have an interesting idea for a new programming language. It's based on a new programming paradigm that I've been working out in my head for some time. I finally got around to start working on a basic parser and interpreter for it a few weeks ago.
I want my new language to be successful and I want to eventually create a community around it when it's ready to release. The idea behind it is fairly innovative, so I don't expect it to gain a lot of ground in the business world, but it would thrill me more than anything else to see a handful of start ups use or open source projects use it.
So taking those aims into account, what can I do to help make my language successful? What do language projects do to become successful? What should I avoid at all costs? I'd love to hear opinions or stories about other languages -- successful or not -- so I can think about them as I continue to develop.
So far, the two biggest concerns on my mind are finding a market, access to existing libraries, having amazing tool support. What else might I add to this list?
The true answer is by having a beard.
http://blogs.microsoft.co.il/blogs/tamir/archive/2008/04/28/computer-languages-and-facial-hair-take-two.aspx
Although not specific to new programming languages, the book Producing Open Source Software by Karl Fogel (available to read online) may be contain some hints to the issue of making a community around your new programming language.
In terms of adoption of programming languages in general, it seems like the trend lately has been to have a rich library to make development times shorter.
As there isn't much detail on what your language is like, it's hard to determine whether adoption of the language is going to depend on the availability of a rich library. Perhaps your language will be able to fill a niche that has been overlooked by other languages and be able to gain users. Or perhaps it has a slick name that will draw people in -- there are many factors which can affect the adoption of a language.
Here are some factors that come to mind when thinking about recent successful languages:
Ability to leverage existing libraries in the new language.
Having an adapter to external libraries written in other languages.
Python allows access to code written in C through the Python/C API.
Targeting a platform which already has plenty of libraries available for use.
Groovy and Scala target the Java platform, therefore allowing the use of and interoperation between existing Java code.
Language design and syntax to allow increased productivity.
Many dynamically-typed languages have gained popularity, such as Ruby and Python to name a couple.
More concise and clear code can be written in languages such as Groovy, as opposed to verbose languages such as Java.
Offering features such as functions as first-class objects and closures which aren't offered in more "traditional" languages such as C and Java.
A community of dedicated users who also are willing to teach newcomers on the benefits of a language
The human factor is going to be big in wide-spread support for a language -- if people never start using your language, it won't gain more users.
Also, another suggestion that I could add is to make the development of your language open -- keep your users posted on developments in your language, and allow people to give you feedback. Better yet, let your users take part in the decision-making process, if you feel that is appropriate.
I believe that by offering ways to participate in the bringing up of a language, the more people will feel that they have a stake in the success of the new language, so the more likely it will gain more support.
Good luck!
Most languages that end up taking off rapidly do so by means of a killer app. For C it was Unix. Ruby had Rails. JavaScript is the only available programming system common to most browsers without third-party add-ons.
Another means of success is by fiat. This only works if you have significant clout. For example C#, as nice as a language as it might be, wouldn't be any where near as popular as it is now if Microsoft had not pushed it as hard as it does. Objective-C is the language of MacOS X simply because Apple says so.
The vast majority of languages, though, which lack a single killer app or a major corporate backer have gained success through long term investment of their respective creators. Perl and Python are prime examples. C++ has no single entity behind it, but it has evolved as the needs of developers have changed.
Don't worry about trying to make the language be successful; worry about using it to solve real problems and make real money.
You'll either make lots of money from using this language, or not. Once you have lots of money, others may care how you did it. Or not, either way you have lots of money.
If you don't make lots of money, nobody will want to know how you did it.
Edit based on comment: I define successful as people using it, and people use languages to solve problems, most for profit, thus successful == profitable.
In addition to making the language easy to use (which has several meanings), you should develop a comprehensive library that covers and also provides a good level of abstraction over (the following most important areas):
* Data structures and manipulation
* File I/O support
* XML processing
* Networking (plus web based technologies like HTTP/HTTPS)
* Database support
* Synchronous and asynchronous I/O
* Processes and threads
* Math
A well thought out framework that makes rapid development faster (and easier to maintain) would be a great addition. For this, you should know the currently popular frameworks well.
Keep in mind that it takes a lot of time. I think it took python about 10 years (someone please correct me if I'm wrong).
So even if your community still seems small after say, 5 years, that's not the end of the story.
"It's based on a new programming paradigm that I've been working out in my head for some time."
While laudable, odds are really good that someone has already done something with your "new" paradigm.
To make a language usable, it must build on prior art. Totally new is not a good path to success. My favorite example is Algol 68.
Algol 60 was wildly popular (back in the day, which is a while ago, admittedly).
The experts wanted to build on this success. They proposed some new paradigms, the effort split into factions. The purists put the new paradigms into Algol 68; it disappeared into obscurity. Some folks created a different version of Algol, called PL/I. It did not have any really new paradigms. It actually went somewhere and was used heavily. Another group created Pascal -- it didn't have much that was new -- it discarded things from Algol 60. It actually went somewhere ans was used heavily.
Your new paradigm must have a clear and concise summary so people can fit it into a context of where the language is usable, how it can be used, what the costs and benefits of using it are.
A "new programming paradigm" causes some people to say "why learn a completely new paradigm when the ones I have work so nicely?" You have to be very clear on how it helps to have a new paradigm.
The language and libraries must work, and work very, very well. A language that isn't rock-solid is worthless. In order to be rock-solid it must be very simple.
It has to have a tutorial that will help anyone get started with your language.
Good Framework for Common Tasks
Easy Installation/Deployment
Good Documentation
Debugger/IDE and other Tools
A popular flagship product that uses your language!
Good documentation, including a detailed reference manual as well as simple examples to get people started quickly.
Good library support so that people can actually write useful programs.
Most popular languages seem to be very strong in either or both or both of those.
Use Trojan Horse approach
C++ - The Forgotten Trojan Horse
An interesting article on why C++ can grab the heart of programmers successfully.