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 9 years ago.
Improve this question
Many developers will claim that moving from one programming language to another is relatively simple especially if the languages are based on similar paradigms. However, in practice the effort comes not from learning the syntax of the language but in developing a deep understanding of the language nuances and more importantly knowing what is offered in the language’s libraries. For example, switching from Java to .Net is not difficult from a syntactic perspective but programming efficiency requires a good knowledge of the available libraries. Switching from PHP to .Net could present an even greater hurdle given the language disparities.
What are the real overheads for a developer to move to a different language in the same paradigm? What if the paradigms are different?
The biggest challenge (for me) is usually the API, rather than the language itself (.NET notwithstanding). For example, I've been using Microsoft's C++ and C# for a lot of years (Delphi before that). But I have great difficulty getting started on Java; even trivial projects can take me a while. Not because the language is difficult (it's not), but because the APIs are different, and arranged differently.
It takes months to get up to speed on an API to the point you can use it fluently, and years to become "good" and learn all the ins and outs of the language. That's daunting for a lot of developers, because you basically have to devote a significant amount (if not all) of your time and effort toward working in the new language to become an expert at it. Many times, the incentive to move out of your current area of expertise just isn't there.
Same paradigm is much easier because it is really just a matter of grasping the various libraries and locating them quickly as you mentioned.
If the paradigms are different than this switch is more difficult. Moving from a static to dynamic language or a procedural to OOP language will require a different mind set. This will take more time but it is possible and still a very good exercise.
It may be similar to learning foreign languages. If you speak English, than moving to another Latin based language is far easier than going to something like Greek.
For me it would finding good bloggers and useful sites on the language. After a while you get to know where the best people are. Those people and sites are good sources of information for learning the subtleties.
leaving your comfort zone. I think this is one of the biggest reasons some developers don't learn new languages.
But for others, this is what drives them.
Moving within the same paradigm is relatively easy. I find that switching between Java and .NET painless because both platforms offer similar functionality and similar libraries. But switching paradigms could be a real challenge.
My students usually have a hard time going to Functional and Logical languages after learning Java even though the functional and logic programming are easier.
Another problem is switching between types of applications. For example, if you are accustomed to building desktop applications in Java then suddenly try to build web applications in .NET the switch is hard because you are not only learning new languages but new fields of programming.
Another challenge is the tool sets that are available for a particular language. Java and .NET have similar tools but with some differences. If you learned to program using Visual Studio then it is possible that features of Visual Studio become confused with the language. I see students having this problem all the time. When you switch to Java and there is no equivalent menu option of wizard in the new IDE it could cause problems.
I advocate to persons learning programming to learn the core concepts of the paradigm rather than the specific language because it makes you more portable in the future. A person comfortable with Object Oriented Concepts will have an easier time switching between Java and .NET or Python than a person who simple learned how to program in C#.
Just like learning a new human language, for me the biggest problem lies on typical constructions you need to do to solve a problem.
I know that perhaps learning "while" or "for" loops in several languages aren't so difficult - but when your problem goes up one level of abstraction (iterate through this array) you'll find yourself using "[" instead of "(" and vice-versa.
The learning curve can be even steeper if, besides learning a new language, you have to learn a new framework. When I went from typícal ASP.Net to MVC (using NVelocity) I kinda felt myself completely lost - all my knowledge on how to solve typical problems with asp.net control had to be forgotten.
Finally, the biggest challenge happens when you change between languages with different paradigms - because you can no longer think in the same way to solve a problem. Like - when moving from C# to Prolog, instead of thinking in functions, arguments, class hierarchy, etcs... I had to think only in states, events linked to data changes and event chaining via recursion - it was madness but I could finish my university homework.
Coming from 15+ years of C++ background I just had to move to Java for a new project I am working on, and this is a rather painful step. There are tools and frameworks for almost everything, but the learning curve is enormous! The new syntax is nothing to worry about, the API is more difficult, but the most difficult area is to find the way through the all the frameworks.
Also, having to use Eclipse as IDE is a step back in terms of stability and reliability compared to Emacs. The features of Eclipse are really compelling, but the bugs in the IDE cause constant hassle.
Related
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 4 years ago.
Improve this question
I've studied and implemented design patterns for a few years now, and I'm wondering. What are some of the newer design patterns (since the GOF)? Also, what should one, similar to myself, study [in the way of software design] next?
Note: I've been using TDD, and UML for some time now. I'm curious about the newer paradigm shifts, and or newer design patterns.
There is roughly an infinite number of design patterns. Design patterns are just that: a recurrence of tricks programmers use to get things done. The most useful thing about the GoF patterns is how famous they are. In that, they have become a language -- exactly what the GoF hoped to achieve.
Many other patterns you'll find on the web and in literature are "just" useful tricks, not so much a language you can use when you speak to fellow programmers. That said, there is a number of patterns that arose in the past ten years or so, particularly in the realm of web development. See the patterns listed in Martin Fowler's patterns book.
I'm surprised that no one has mentioned Martin Fowler's book Patterns of Enterprise Application Architecture. This is an outstanding book with dozens of patterns, many of which are used in modern ORM design (repository, active record), along with a number of UI layer patterns. Highly recommended.
I am an avid follower and supporter of the PCMEF (now PCBMER) framework
Here's a simpler overview of it.
It kind of understands that enterprise systems are huge an complex, and by combining a bunch of other design patterns together into the PCMBER framework (Presentation, Control, Mediator, Entity and Resource), even the most complex system remain easy to usnerstand and manage.
One of the newer ones that I found particularly useful is Domain Driven Design. Not so much a pattern in its own right, but more of a mindset - to concentrate on the domain objects - i.e. the things that you model and build the rest of application around it.
I found that it gave meaning to principles that we all knew before but were too lazy to deal with - like Single Responsibility Principle and Separation of Concerns. I take those two especially more seriously now.
Another axis of improvement for me was TDD and Dependency Injection. I have discovered that with lots of interfaces and classes implementing them I was able to let go of this fear of only defining something once. That is not to say that it is in conflict with DRY(Don't Repeat Yourself) much. It's OK to have two classes with the same properties if their purposes are different. Encapsulation and SRP are much more important than only defining a property once.
Umm...none of the things people have mentioned are design patterns.
GOF was written implicitly with Java in mind. It explored that space pretty well. However once you go into other languages some patterns are no longer necessary (Observer is rarely used in a language like C# that supports events) and some new ones spring forth. Grab yourself the Pro JavaScript Design Patterns or Design Patterns In Ruby books and see what happens to the stand-by pattens in these very different paradigms.
My favorites lately have come from leaning on the functional drift of modern languages. I'm a big fan of nested closures and of the functional ways of tackling some of the same problems that GoF does (again, see the Ruby book for great examples). I also am currently in love with the idea of internal domain-specific languages which open up into a whole series of design patterns of their own (including nested closures). Also event-aggregation seems to be poised to hit it big in the .Net world in the near future.
A couple other big ones that have hit the scene but aren't discussed as much in GoF - probably because they are more high level then what those guys were going for - are Inversion Of Control Containers, Message Bussing, Aspect-Oriented-Programming, Model-View-Controller, Model-View-Presenter, Model-View-ViewModel, and their ilk.
By the way, these are not design patterns, but if you're looking to progress beyond TDD start looking into Behavior-Driven-Development and Context/Specification.
A huge change from a maintenance aspect is the use of DVCS. If you don't know what one is or haven't used one, I highly suggest reading up on the two hard hitters:
Mercurial (hg): https://www.mercurial-scm.org/
git : http://git-scm.com/
They've done quite a bit to change the workflow of the common programming environment. Not really a pattern/design I spose, but I don't think TDD or UML are technical patterns/designs either at some level. Maybe more like common practices surrounding programming.
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 3 years ago.
Improve this question
I've been coding since my early teenager years. I started out with HTML, went on to PHP/MySQL (created my own forums, social networking sites, etc..) and then branched out into more traditional languages such as Java and C++ (also picked up a little VB .NET in high school). I'm most familiar now with C++ as that is the language of choice taught to us in Computer Science II (skipped Comp Sci I) at RPI. I now feel like I have a very good knowledge of how to program from this class (the homework assignments were brutal).
It is now summer and I am interning at a company that is providing me some level of new experiences with programming, but I want more. I want to feel the incredible satisfaction that I got out of my computer classes at RPI whenever I finished a long assignment (generating every possible wordsearch from a set of words to include and exclude comes to mind).
My question is, where do I go from here? I tried following a tutorials online, but they were all too simple. I then tried heading over to sourceforge and helping out with various projects. But, as soon as I downloaded the code I got lost in its complexity. I have never created actual software of a real life applicapable scale. And I don't know where to get started. How do you transition from programming knowledge to actuall creation of software?
I'm also open to learning new languages (javascript/jQuery, ASP .NET, C#, Python), or using new libraries and/or frameworks with c++ (we only used the STL in Comp Sci II) and other languages. Again my question is, where do I go from here? And I am welcome to all possible answers.
Thanks Much,
Michael
You could join a big open source project, you'll learn a lot and accomplish something cool.
EDIT after comment: If this is too complicated for you, try starting a "real" project. I say "real" because it should be something that you want to do, not a "create a blog" or "how to do a loop". For instance last year I created a fully functional project management system that I now use for some of my projects. If this is real, you will be more motivated and you will want to get this done.
Pick the technology you want for it. I'd recommend Ruby on Rails because it's awesome and full of interesting concepts that will improve the way you code overtime (DRY, RESTful, MVC...)... but you can pick whatever you want.
Try to create your project using what you know and basic tutorials. You will get stuck and have to learn some more in order to get the features you want going. To me that's the best way to improve the way you code and general programming knowledge.
Since you'll start the project from scratch, you'll see where to start and how this will evolve. I'll take the project management tool. We started with "A project has todos" and we ended up with all kind of other features such as a complex calendar, a full ajax interface, a embedded chat...
Once you see how you did this, try doing the same with a friend of yours to get a fealing of teamwork in development. Learn how to use SVN, basecamp... learn about software development processes (Agile!), peer programming..
There's a lot to experience! Then you could give open source another try.
Hope that helps
I'd recommend trying a pure functional language, such as Haskell. It's a completely different way of looking at programming, and I found it very satisfying.
I recommend the book Real World Haskell for learning it.
Edit: In response to comments, my interpretation of the question is where can he go from here as a programmer. Functional programming is a logical direction. For someone learning functional programming for the first time, Haskell is nice because it doesn't really allow for imperative programming practices. Furthermore, it has basically all features you will find in other functional languages, which means it will be easy to pick up other functional languages.
I would suggest looking at Project Euler. It's a great and fun way to learn a new language, and it does provide that level of satisfaction when you solve the problems. They offer a huge range of problems at all levels of difficulty.
I think the best way to improve your skills as a programmer is to do what programming was intended for: solve problems. I'm sure you've been playing around on your machine and at one time thought to yourself "I wish there was a program that did this..." or "I wonder if there are any programs that do X..." Instead of just googling to see if someone else wrote it, write it yourself. Start with something small, and gradually make it more complex. Add features. Allow yourself to fail, and when you do, ask yourself (or us at stackoverflow) how to overcome that obstacle. Once you have the basics of programming, everything else is just making big things out of littler things, and the little things are usually pretty easy.
When you are making something you know you will actually use, it's more fun and more gratifying when you finish.
Do you understand all of the following and how they work?
Linked lists (single and double)
Sequential vs. binary search
Binary trees
Stacks
Red-black trees
Algorithmic complexity and big O notation
Recursion
Hash tables and hashing algorithms
If you don't feel completely conversant in any of these, take a class in data structures and algorithms.
It seems like you've experienced many languages, but have not created a real-world application. Creating software in any of those languages will bring you to a new level.
PS: Creating software is much more than just knowing how to mess around with a language.
Check out Design Patterns.
I believe that's beyond mere simple coding.
You could offer your abilities to a non profit or a friend or someone who needs a website or program built.
Tell them you can do it for free and then just go for it. As you start to make it you'll start to see what you need to learn.
For example I bit ago I had the program Peel www.getpeel.com on my Mac. But sold my Mac for Wind as I am traveling.
Seeing that there was nothing for Windows (or nothing I could find) like Peel. I build my own in PHP and am up to a 4th rebuilding of it as I learn betters ways to do each new thing I am learning.
You've got to find a particular type of functionality that interests you. For me it's been basic socket programming and making my own protocols. I got that feeling when I was able to create a functional file uploading control that worked in conjunction with a file upload service on the server which I had created. The protocol handles authentication, chunking and hash comparison. Sometime soon I plan on incorporating file-resume functionality as well.
Well my advice will be to find a problem/project you are interested in and try to code it. Trying a real problem is something that drives you. Find something not to complex but not too simple. Something to try when starting a new language is to write some tools. You can for example program a python script that print metrics on a C++ project. You can write a tool that extract some statistics from a website you use, etc. When I learn programming game programming was quite fun (I was young :-) ). You can try to program some simple game using a 3D engine like Ogre3D for example. Participate in an opensource project is great too but as you stated perhaps a bit overwhelming for now ;-)
Find something you like and that has a REAL useful goal for you. You will thrive to solve the problem and learn a lot along the way !
I think the transition from the kind of finite tractable problems that are part of class projects (and some internships) to "real world" projects is quite tough. Sounds like language syntax, getting bugs out of code etc. is something you are comforatble with.
When we come to larger projects, probably with many release cycles, with developers working together, different kinds of problems emerge. I remember being shocked when I saw my first big project plan - what a small propertion of the time was actually writing code!
The thing I found helpful as a junior was "Sitting By Nelly", I was lucky enough to work for enlighted employers who put me with very experienced and helpful developers. Sometimes to work with, sometime to work alongside. I reckon that helped me get over the hurdles you describe.
So, I reckon you need to find employment of this kind. Be less concerned about specific technologies, salary etc. Look instead for the culture and level of responsibility you would have.
I think you should really start a "real world application" as suggested here. You will see that a real project requires a bit more than just knowing the language.
I suggest you find some simple problem you had issue with, and make a software that solves that issue.
For example, if you want some kind of software that checks RSS feeds every 5 minutes and makes a little pop-up as soon as a new one comes along. Or you want a program that will let you do simple presentations by just dragging a few pictures in.
Then whatever you choose, start by making the simple solution to the problem and extend from there (like do different settings, extra features etc.)
I've looked for the answer to this question for a while now. Most all of the suggestions are usually either help an open source project or build something that interests you. I'm starting to realize that those answers are vague because what's 'interesting' or 'valuable' experience and how to get started doing it is completely subjective. Also, there's only one way to get real experience, which is to work on real projects. It's difficult but find a project, personal, open source, or otherwise that will increase your knowledge in a technology or platform that you think will hold your interest. Then just dig in. It doesn't have to be of earth shattering importance, just valuable in relation to your own goals.
There is no magic bullet transition from academic puzzle solving programs to real world applications. The best way to learn is just to jump in head first. It will take you a very long time to learn what you need to if you only ever look at your own code. You need to be looking at code written by professionals and struggling to understand why it works the way it does until you do understand it.
It seems overwhelming at first, but you will quickly start to see patterns if the application is at all logical. Well written code will be separated in logical ways, so you should be able to pick it apart one layer at a time.
For example, you could try a bottom up approach where you try to understand how the database interactions are handled before looking at the code that uses the database layer. You keep going upward until you get to the GUI event handlers.
Large enterprise applications can be even harder to understand because there might be a lot more than one executable, or component. Try to stay focused and learn what the component is responsible for doing, and then pick it apart a piece at a time.
You will see that there are not just patterns at the function and class level, but at higher levels as well. This makes it simpler to understand what is going on when you understand those patterns.
Try to find an internship or co-op position. I was in a similar situation after my first few courses. I took a co-op position sophomore year and I learned so much more on the job than I did in class. Class is great for teaching you theory and the basics. I learned C# on my first project on my co-op and that got me my second co-op position at another employer (wanted to see how it was working at a small company).
This past spring, I accepted a position at my first co-op employer, reworking my first major project I had started on my co-op. I have a list of side projects I also want to complete, which will help round out my skills, as well as learn some other languages.
So my suggestion is try finding a job where you can have a great mentor. On my second co-op, I learned alot of the coding standards that I code against from my supervisor. He was a great teacher, and really had some great input, and explained why things should be done certain ways.
You will almost certainly go nowhere unless you find something that interests you. Figure out what is interesting, and then how to write software involving it.
The only way to begin is to begin! There is really no other way... The best answers you get would always tell you this. You have the knowledge, now put it to work!
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.
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 9 years ago.
Improve this question
I remember that in the late 1990s and early 2000s Aspect Oriented Programming (AOP) was supposed to be the "Next Big Thing". Nowadays I see some AOP still around, but it seems to have faded into the background.
There has maybe been a lot of hype in the early 2000's, and what happened is the following: there has been a lot of attempts to create aspect-oriented frameworks, and these attempts have merged into two significant projects in the Java sphere: AspectJ and Spring AOP. AspectJ is complete, complex, academic, somewhat overengineered. Spring AOP covers 80% of use cases with 20% of complexity.
If you look at Google Trends for terms "AspectJ, Spring AOP", then compare to the popularity of Java itself, you will see that the relative popularity of AspectJ is somewhat constant, but Spring AOP is raising. That means that people use AOP, but don't want the complexity of AspectJ. I think that the creators of AspectJ made a lot of tactical mistakes; AspectJ has always been a research project and has not been designed "for the masses".
In the .NET sphere, we have seen a similar interest for AOP in the early 2000's. In 2003, when I started AOP researches, there were half a dozen of AOP weavers for .NET; all were following the path of AspectJ, and all were in infant stage. None of these projects survived. Based on this analysis, I built PostSharp, who was designed to cover 80% of use cases with 20% of complexity, and yet was much more convenient to use than Spring AOP. PostSharp is now considered the leading aspect weaver for .NET. PostSharp 2.0 builds on 5 years of feedback and from industry experience of AspectJ and brings "enterprise-ready" AOP (future will judge if this claim is deserved). Besides PostSharp, other significant players are Spring Framework for .NET and Windsor Castle, two DI-centric application frameworks providing 'also' aspects (aspects are considered as dependencies injected into constructed objects). Since these technologies use runtime weaving, they have severe technical limitations, so practically they can be used only in service objects (that's what these application frameworks have been designed for). Another starting project in .NET is LinFu, which can do 'also' aspects.
To be short, the AOP landscape has undergone some consolidation last years, and probably enters the phase of productivity: customers will use it because it really saves money, not because it is cool. Even if it is very cool :).
Oh, and I forgot: most application servers have built-in support for AOP. Thinking of JBoss, WebSphere, and, to some extent, WCF.
That tends to happen with every "next big thing." Lots of hype, followed by a slow decline in the use of the buzzword. But, even though buzzwords fade and eventually disappear, whatever good ideas were behind them tend to stick around to be absorbed into the mainstream.
[Edit] Okay, an example for those who think I'm "bashing" something, or claiming that aspect oriented programming is going to disappear. At one time the next big thing was structured programming. Object oriented programming grew out of that, and now nobody talks about doing "structured programming" any more. But, in many ways we're still using its best ideas, because OOP adopted them, improved them, and added still more new ideas.
It's around on some projects, my own experience on a recent project is that is too easy to abuse :( !!! What started a a nice way to setup debug, timing and to some extend transaction management, it quickly got corrupted to the weirdest, and hardest code to understand and debug that I've seen in a while.
just to expand a bit on the debug/diagnostic side, the stack traces generated by AOP code many times hide beyond recognition the actual place where the exception took place.
AOP is actually truly brilliant, the problem with it is that no existing language has really great support for it. Sure C# has attributes (which only works when you're CODING the thing) and Java has "injection" (which creates a mess out of the runtime) but in general there are no (mainstream) languages which have truly great support for it...
So it kind of like ended up being a "Design Pattern" (with insanely different implementations in all the different languages though) which after all isn't all that bad I guess ;)
I'm going to suggest that it wasn't big enough. It sounds very appealing, but does it really make coding any easier? I've been wanting to try it out and find what benefits it really holds, but I don't think I do enough coding where I need the relationships that it provides. I don't think it is as beneficial as it sounds.
Also at this point, making it easier to do multicore programming easier is a big thing and I don't think aspect-oriented programming will assist with that.
You can also find lots of content on Adoption Risks.