What are the technical questions I simply must have answers for before I approach someone about introducing a new language?
I'm looking for the list of technical questions that without a really good answer, I should not even waste anyone's time by proposing that we use language X.
PS: (def X clojure)
A crash course in politics for engineers...
Despite all the mission-statement baloney meant to sound noble and emphasize community support, the real purpose of every business is return on investment or, equivalently, maximizing shareholder value. If it's a government agency, it's kind of still the same question but the legal owners will have no direct influence and instead you will have proxy owners, such as higher agencies or powerful individual officials.
Decisions, however, are almost always made by agents, and so the principal-agent problem (also called the agency dilemma) appears; the agents (the management) will make a decision in their interest, and not necessarily according to the shareholder's interest as is theoretically required. In a government agency this is almost 100% of the consideration.
Sadly, this stirs in all the Dilbert and Parkinson's Law complexities.
The best you can conclude is that decisions will be justified on the basis of risk, cost, and benefit, but will tend to be made on the basis of what credit and blame is in store for the agent and understood by the agent, which is a narrow risk consideration of questionable value to the principal but at least an identifiable one.
So, we should now apply this to the language question. Your manager is likely to avoid threats, risks, scandals, and controversies. His application of the principals's concerns will be mainly through the constraints of budgets and expectations. Here are some examples that should be mostly self-explanatory.
If you want to use Java or PHP:
Everyone is doing it this way
This is the industry-standard approach for this type of problem
This is the low-risk approach
Similar systems have been done many times in Java/PHP
(That's the "no one ever got fired for buying IBM" argument.)
If you want to use Ruby:
Ruby is in the Tiobe top-ten (not quite an industry standard, so this is the best you can do)
PHP and Java are higher-cost technologies (he probably has a budget as an attempt to mitigate the principal-agent problem)
PHP and Java are going to be out of fashion "soon" (maybe not, but phrased as a "risk of appearing to stupidly use old tech', and implying the lack of later credit and recognition)
Ruby is an advanced language with powerful abstractions for cost-effective development (a weak argument for the agent, but offers the possibility of credit. The least effective of all the arguments.)
If you want to use Clojure:
You better prototype the system on weekends and evenings and present it as a solved problem.
Emphasize parallel Java / Clojure development ("if necessary the entire system can be written in Clojure Java")
Make all the Java arguments and then say something about "the best of both worlds"
Productivity with a language is neither the only factor, nor a simple scalar in itself. Important questions include:
How easy is it to learn the language, if it's not already familiar to people on the team?
How easy is it to become expert at the language?
Does the team have access to one or more language experts who have the bandwidth to do the necessary mentoring?
Are good learning materials (books, blogs, tutorials) and support channels (fora, IRC, mailing lists) available?
Does the language (or some framework in that language) allow a competent programmer to write the software faster than what you're using now?
How maintainable is the language? How readable is the syntax to a competent programmer encountering someone else's code for the first time? (Think of APL and Perl.)
Is the language somehow better applicable to your problem domain than what you're using now (e.g., functional languages for distributed computing)?
How well does the language/platform meet business needs not related to development speed (e.g., performance, scalability)?
What are the available tools like, and what do they cost? Is there a debugger available? An IDE? Refactoring and unit test support built into the IDE? Build management and deployment tools?
So much depends on what you're currently using, what you're switching to and why that it's difficult to answer. But these are always important:
What can I do if I choose a new language that I could not do before?
What could I do faster than I can currently with the new language?
How will the rest of the team cope with the introduction of the new language?
If I left, could someone else new to the language pick up where I left off without too many problems?
What is the business case?
It comes down to ROI (Return On Investment).
It is not only about an individual's productivity but:
the whole team
impact on product lifecycle
maintainability
etc.
How easy is it to pick up? I find this is not that important.
Does it have IDE support? Pretty important, but you can work without it.
Is there a debugger available? I think this is the most important question I would ask. Once you have a working debugger, you can usually get anything done.
We hired a team this year and decided to use Clojure as our weapon of choice. The team's background was primarily Java-based but also a wide variety of other languages for hobby work.
The criteria we considered were:
Can we leverage the Java/JVM background of the team and integrate with an existing Java-based product?
Can we achieve performance on par with Java?
Can we build thread-safe concurrent maintainable programs?
Can we leverage a higher level of abstraction
Can we hire/train people to work in the language?
Can we maintain a large codebase in the language?
Are sufficient tools available to work effectively in the language?
Is there an active community of people growing the language and libs?
We seriously considered Groovy, Scala, and Clojure. I really enjoy Groovy for lightweight apps but I had serious questions about performance. Scala and Clojure both have lots to offer on all of the points above. In the end, our problem domain involves a lot of symbolic manipulation and we felt that Clojure would be a better match but I suspect Scala also would work well.
What will your new language offer that an existing language doesn't already?
We have languages that do just about everything in every way today. So before introducing a new language, make sure there isn't one already existing that does everything your new language does. And make sure you know exactly what features your new language will offer that aren't offered in the same combination or at all by other languages.
Unless of course you're just doing this for your own education - in which case forget this question and have at it!
How will this improve my productivity?
If this cannot be answered pack up and go home.
What's the point? / Why?
How will it make my job easier?
Q1: Can I hire people with these skills?
Q2: When I call our outsourcing partner account managers, and ask how much would a typical fixed-cost project cost, if done in the usual way, or done using language X, is the multiplier more than 1?
Q3: Does everyone else in my department also have a favorite language that does about the same job as my favorite language, and should their favorite languages be used as well? What are the practical consequences of this?
A good question to ask is what is the size of the community around the language/framework. For instance, ruby/rails has a significant community around it, which would make me more comfortable that I would not be "the first kid on the block" to have to deal with a particular problem.
Why limit yourself to one language? Figure out which problems are solved best by which language and offer up services. If the bandwidth between the services is too high, then migrate the problematic services together based on which language solves both best.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
After a while surfing on source code of big projects especially application servers like this, I have understand these projects are not developing by one language. Many of them are using python for secondary language.
Now I have four questions:
Why is used more than one language?
Why python is used for secondary often?
Why python is not used to develop all parts of projects and they still is using c/c++?
And which the parts of projects should be developed with python and which part of projects is using c/c++?
Hard and soft layers
Programming language designs tend to trade off between "high-level" features, which enhance programmer productivity at the cost of speed, and "low-level" features, which require a great deal of programmer effort but produce very fast code.
Therefore it sometimes makes sense to use two languages on a project:
Write 90% of the code in an expressive, high level language which is easy to write and maintain.
Write the 10% of performance-critical code in a low-level language which is harder to write, but allows for comprehensive optimisation.
c2wiki calls this the HardAndSoftLayers pattern:
By virtue of the first rule of optimization, go ahead and write most of your code in the highest level language you can find.
By virtue of the third rule of optimization, when you must, use a profiler and find the slow parts of your program. Take those parts, and write them in a lower-level language.
For reference, the rules of optimisation are:
First Rule Of Optimization - Don't.
Second Rule Of Optimization - Don't... yet.
Profile Before Optimizing
The rule is pretty simple: the developers choose the language(s) based more or less on the following criterias:
their familiarity with it
how easily you can do the task using that language
how well is suited the language to the specific task
Today most of the development done in this multilingual environments are huge solutions, where different components need to communicate, exchange data or simply do work which is comprised of more than one step. It is easier to write the communication/data interpretation/whatever wrapping necessary part in a language such as python and then leave the real time and speed needy work to be done by some lower level language which compiles directly without the need for an interpreter.
Let's dig a little bit deeper.
How familiar are the developers with the programming language depends on the background of each developer. If they are given a free choice, obviously they will pick the language they know the best, unless there is a lobby from someone else... usually higher in the management chain. Python is not necessarily the language of choice, python is simply an easy to use and learn language, which is well suited for most tasks. Our project has no bit of python in it, only tons of ruby code. Because the main developer liked ruby at that time, so we're stuck with it.
If you know more than one programming language you know that each of them is doing the same thing differently. For example, creating a socket, connecting to a server, reading the stuff and printing it out is just a few lines of Erlang code, but it takes a lot more to do it in C++ (for example...) So again, if you have a task you know how to solve easily in a specific language you are going to stuck to it. People are lazy, they don't necessarily learn new stuff unless needed.
Obviously you are not going to write a device driver in python, and it is much easier to create a complete web service with java than with plain C... but you still would need the part of the solution that does the hardware close thing. When you have a task you carefully measure the requirements and implications and wisely choose the language you will do it in. Because it will stuck to it forever.
Sometimes python is not good enough.
Dealing with computer vision, image or sound processing, calculate tones of data is not really what python is good at. Other language like C or C++ is really good at those fields.
support your primary language is java, and you want to glue other languages into one project. That where we need Python. Python is well known glue language. you can use ctype,SWIG, Jython, ironPython or other method to bind multiple language.
Guess I answered this question at 1.
Need for speed. go for C or C++ . Care more about productivity, go with Python.
Without referring to the project you sent, I'll give you my 50c for why the company I work for, as to why we use python quite often in our projects.
Primarily, we have no python code relating to the software solution itself. All python code either relates to assist with development, machine set up, common framework tools deployment for testing, and vastly for code generation.
Why is used more than one language?
No project we work on has only one language, when looking at all our enterprise level solutions or large scale implementations.
This is mostly due to the fact that our tiers are written in languages that provide best performance and usability at each level separately.
For instance, C++ for speedy core back-end services, and C#.NET for rapidly developed and provide good UI for the front-end.
Why python is used for secondary often?
Personally, apart for the reasons I explained above, we don't make use of python 'secondary often'. We use C++/C# as the most common pair, but depending on the platform, might be other pairs.
Why python is not used to develop all parts of projects and they still is using c/c++?
Python is great for quick solutions and doing things you wish your shell could do. This largely involves file management, etc.
C++ is perhaps the fastest compiled language, providing optimal usage for core and largely used actions.
Based on that, and the fact that the market has more knowledge and experience in C++ (for many reasons), C++ is the more popular choice.
And which the parts of projects should be developed with python and which part of projects is using c/c++?
I believe I may have already addressed that above.
-
I hope I could help, please remember this is only my personal opinion and by no means should this be taken as a fact.
Hi I want to know why people develop library applications and employee management applications in C++ (this application, for example), when clearly the same thing can be done in C# and VB.NET in a much prettier way. Even banking applications are mostly in C++. Is there a good reason why, apart from the fact that compiled C++ code executes faster?
Can anyone shed some light on this?
C: 1972
C++: 1979
C#: 2000
Now think of the lifetime of a library, especially in a bank, plus, you get to use the libraries (theoretically) on almost every computersystem in existence (as opposed to C#)
You will also still find a lot of COBOL (1960) there.
The main reasons for C++ for say banking applications is:
Legacy code. A large financial firm typically has ~10-20-30 years of business specific C/C++ libraries developed in-house, plus a bunch of business specific vendor libraries which may not be available for C#
A LOT of that financial code runs on Unix/Linux. While you can purely theoretically build C# code for Linux, it's definitely NOT an established technology you want to bet billion dollar amounts on.
C++ is usable on other types of systems, whereas c# and vb.net are not.
Apart from technical reasons (such that C++ is an "unmanaged" language with quite different capabilities and properties than .NET languages), this can simply be due to preferences. Not all people find that C# and VB.NET are the best tool for every task. Or the prettiest. Why do you think so? And why should others not have similarly good reasons for choosing another tool of their liking?
Update, in reply to Konrad's comment:
It's correct that "preference" is indeed too narrow a term. There's other facets to it:
Managers / bosses can turn their (possibly badly informed) preferences into business policies;
A corporation's decade-old codebase can mean that when it comes to choosing the programming language for some new task, you'll evaluate languages with a different perspective. You want to or need to reuse the existing code, so interop with the old code's language must be possible.
It might be a factor of the knowledge economy of a particular company. For example, the bigger a company gets, or the less staff turnover they have, the harder it will be to replace competence, process and tooling to accommodate, for example, a new language. C/C++ has been around for quite some time, and many developers as well as development shops have that background.
Concerning banking applications, the reason is, I would guess, mostly because you have a close to metal environment which allows you to utilise realtime programming in a dependable fashion.
Every language has its pros and cons and no one language is best for every application. Programs in C++are harder to write, but can take advantage of platform-specific hardware and features. Because they're compiled, they also tend to run a bit faster. C# programs are easier to write, but aren't able to access underlying resources and can't be ported to non-Windows platforms very easily.
In short, it really depends on the application needs. If you need raw speed and explicit resource management, go with C++. If you want ease of coding and clarity, go with C#.
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 9 years ago.
Improve this question
I am learning Clojure and I really am loving some of its features. The time is coming to think of some real "pet projects" and I realize I'm not sure how to actually use Clojure.
I see many web and templating frameworks (e.g. Compojure), but somehow I'm in doubt on whether it's worth it. I feel that in the long run it can't serve the needs of real world applications which you address with Spring, Hibernate and some pieces of the Java EE stack.
On the other hand, I see great potential in the concurrency features but I'm short on ideas on how to really use them.
Enough background, my questions are:
What are the feasible applications of Clojure and functional programming? What idea for a pet project can you suggest which wouldn't be rewriting the stuff I did with OO/Java EE into different syntax? I'm looking for something what really exploits Clojure's potential and leads to a solution which feels a lot better (not just in syntax) than OO/structural programming.
Is it common, or at least reasonable, to mix Clojure and Java? I mean either of using Clojure for tiny libraries in 95% Java projects, or building Java apps on top of the core written in Clojure.
Edit: Thanks for all the great answers. They're all really inspiring. So if you have anything else to add, go ahead and don't be put off by the fact that one has been accepted.
In answer to the "background" part of the question:
I think you should read Jörg W. Mittag's answer to an SO question entitled "Real world Haskell programming". He makes a number of excellent points. Read on for my take on the FP in the real world issue; scroll past the horizontal line for answers to the two actual questions.
There's a number of FP-centric companies which seem to be really good at what they're doing; for some examples, google Jane Street (OCaml), Galois (Haskell), FlightCaster (Clojure for backend heavy lifting; I seem to remember reading that their frontend is currently done in Rails). Supposedly automated trading strategies are often coded in FP-oriented languages; that would indeed make perfect sense, although I have no inside data to confirm this. For additional examples to do with Clojure, see the list of companies on the success stories page.
Some people seem to be enjoying a degree of success in addressing the needs of real world applications in Rails, Django etc. It would appear that they feel no need to touch J2EE & friends. Not that these have much to do with FP, but they are like FP in that they're nothing like the "Enterprise Languages" of the present.
As for the two actual questions:
Why not just pick up whatever it is you've last been thinking to do and do it in Clojure? Obviously anything can be done in Java (and most things probably have been), but a leaner language might make the product cleaner, the experience more pleasant and less time consuming etc.
About mixing Clojure and Java -- I've seen a decent amount of Clojure code using a couple of classes coded directly in Java (for whatever reason). I've tried going the other way around myself and it's a bit of a pain in that it's much simpler to work with interface inheritance than class inheritance in Clojure, unexpected coupling in the Java code can seriously interfere with the ability of the Clojure code to do things in the most natural way etc. Still, it's entirely possible to extend a Java programme in Clojure and it seems like a particularly safe & sane way of experimenting with it for the worried Java developer.
Functional programming can be applied to almost any task. Web applications, scientific applications, games, you name it.
It is very common to mix Clojure and Java, since Clojure does not have many dedicated libraries for things like I/O or networking.
Organizations that already have a lot of Java code can use Clojure for small subsections of their Java projects.
For new projects, it is usually more effective to use Clojure as the high-level driver language, calling Java libraries where necessary.
I have been working on a small web application using Clojure, and while there is nothing special about the application that could not have been done in a different language, the experience of writing it has been completely different. I have written web apps using ASP.net and moving to Clojure was less about learning the different syntax and more about learning a different way to think and program. Having to learn a different way to think will occur regardless of the project you choose to work on, so I would worry less about finding the perfect functional project and more about finding something you just want to work on.
I think the answer to this has a great deal to do with the context your project is embedded in, and the constraints that imposes on you. Absent social factors I think Clojure is likely at least as "good" a language as Java is for any problem, with the possible exception of cases where you need the last bit of performance. And even in those cases things are not nearly as simple as they seem. For one thing some future version of Clojure can probably, in the theoretical limit, be compiled to bytecode that is as "fast" as what Java is compiled into (assuming a bit more work from the programmer at bottlenecks.) More importantly, optimization is a multi-factorial problem, and one in which programmer productivity and the flexibility of code factors heavily. So while there is a sense in which it would be accurate to say that Clojure is slower than Java, that sense might not be the important one when discussing the performance of a particular application.
So I'd say that if you disregard social factors Clojure's use cases are close to a superset of Java's. I wouldn't try to write a Linux kernel module in clojure though...
Of course, it's true that not all problems have equally natural solutions in functional languages. But people have come up with some interesting ways of dealing with some of the cases where FP seems to map badly to the domain, and anyway Clojure actually offers you enough escape hatches from pure FP that if you really feel the need to write part of your program in an imperative style you can (though of course you give up some of the benefits of Clojure in that case.) In the worst case you could use Clojure to drive the Java library in much the same way that you would in Java... it's hard to imagine a case where that would be a good idea, but in most cases that would not be markedly inferior to just using Java, and in many it might be better.
I'm still a neophyte at Clojure, though I've been programming in CL and scheme for a long time, and I spent about five years writing Java for a living. But I would probably prefer Clojure to Java for just about anything even without knowing it quite as well, as long as there were no social factors involved.
It would be a mistake to dismiss social factors though. I've been a Lisp programmer long enough to have a finely honed instinct for how well a Lisp will work in a given context. I've introduced Lisp to commercial settings where it has been a big win, and I've introduced it to settings where it really wasn't. I'd think long and hard about staking your career on successfully transitioning a team of programmers to any Lisp, Clojure included, particularly if they are not too keen on the idea.
Just to give you an idea of what I think Clojure might be useful for, I am currently writing a lot of poker-related code in Clojure. Some of it is pretty simple stuff (finding the best five card hand you can make from seven cards) and some of it is a bit more interesting (looking at someone's playing history and extracting meaningful trends from it using a few heuristics and some basic statistics.) None of it requires much in the way of Clojure's sophisticated concurrency mechanisms, but it is still much nicer (for me at least) in Clojure than it would be in, say, Java.
There are certainly some other cases that someone might describe where Clojure wins big because of its sophisticated mechanisms for managing concurrency, etc. I am aiming at something more modest- I am just pointing out that even if you don't need those mechanisms you might find Clojure a very congenial language for general purpose programming, albeit one that requires you to rethink how you abstract things if you're coming from an imperative/OO background. And hey, if you need the concurrency mechanisms (as you might, the way things are going), at least you already know Clojure.
I like writing game programs when I learn a new language.
I am in the process of learning Clojure and started writing a Spider solitaire player. If you have never played Spider, don't start; it is very additive :-). See http://www.spidersolitaire.org/.
In writing this game, I am getting to use several things that I want to learn: functional programming, concurrency, Java-interop (for Swing), etc.
I have also started writing a Bejeweled player (http://www.popcap.com/games/free/bejeweled2), but have run into a problem finding the definitive rules for scoring the game.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Which sector of software industry uses C++?
C++ was for many years the holy grail of mission critical high performance development. However, it seems that for the past 10 years like much of the development world has moved to Java and C#. My quesiton is this, is C++ effectively relegated to embedded systems, OS, Browser and other special purpose development? Should I let this skillset go the way of the VB 6 and other skillsets that are no longer showing the same level of demand and value in the market? I love C++ and would love to update my knowledge in it, but I wouldn't even know where to begin to try to apply it to common business problems today.
Regards.
First of all, I doubt anybody can give a definitive answer -- there's just no way to tell exactly how much any particular language is really used. Nearly anything you can measure is a secondary measurement, such as how many people are advertising jobs using that language. The problem is that this tends to show relatively new languages as dominating to a much greater degree than is real.
That said, my belief is as follows. At one time, C++ was the hot new language on the block, and there was a bubble when it dominated the market. That bubble deflated quite a while ago. Since then, use of C++ has been growing on an absolute basis, but the market has been growing (quite a bit) faster so its shrinking on a relative basis.
There are a couple of reasons this doesn't show up in most secondary measures such as job advertisements though. A couple of the obvious ones include:
Many teams producing C++ have now had years to "settle in", so the turnover rate is relatively low.
It's now well established where it's used, so positions tend to be filled by internal promotions.
There's another effect I almost hesitate to mention, but it's true no matter how little a lot of people like it: there are both programmers and managers who are more excited about "new" than effective. This leads to a large group of wannabes who are constantly on the move to the latest and greatest "technology" (whether that happens to be a language, framework, platform, or whatever). They get a job, loaf (or worse, actually write some code), then move on to their next victim...er...employer. They cause a lot of "churn", and inflate the number of job advertisements, but produce little or nothing of any real value. That group moved from C++ to Java a long time ago, and have long since moved from Java to C# to Ruby on Rails to Hadoop to whatever the managers are excited about this week.
Lest I sound excessively negative, I should add that along the way, a few of them really find something they're good at, and (mostly) tend to stay with that. Unfortunately, for every one who does, there are at least five more new graduates to join the throng...
"C++ effectively relegated to embedded systems, OS, Browser"
"other special purpose development"
You mean 99% of the code people run on a daily basis?
C++ is still heavily used in many mission critical financial applications. For example, most of Bloomberg's platforms are based on C++ with very little front end in other languages. Many investment banks and hedge funds use algorithmic trading systems written completely in C++ (e.g., Tower Research Capital, Knight Capital, etc.).
If you've been out of C++ for a while, you may need to get used to a whole bunch of now-standard libraries. When I was doing most of my C++, STL was fairly new and you either adopted the Microsoft libs or did not. If I went back to C++ now, I'll have to learn all the new libraries to be effective.
I think most of the movement to other languages is related to web development and web-centric development. The main exception to that would be Google, which still primarily use C++ and Python.
C++ is still valuable for many high performance apps. There are other technologies, and depends on the situation different languages are better suited for your needs. But if you want strong performance, good control of what your code is doing, and flexible networking and programming stack, C++ is still a good choice.
A better suggestion is: let the problems come to you and find the language that best suites the situation, rather than take a language and go look for problems.
Still: if you know C++ well, you can learn/program in anything.
To this day, C++ is the only language which is both object oriented and compiled (or at least, which has a mature ecosystem of optimizing compilers). Which leaves it as the sole choice for most large scale, compute-intense projects.
To me the prominent example is games and game engines - these are huuuuuge projects that squeeze machines for milisecond-fractions. MS is trying to get some traction for XNA (a managed game-dev framework - basically a DirectX wrapper ), but most probably would never get any for AAA game productions.
If I take a look at the applications I have installed on the laptop I am writing this message on, I see a lot of C/C++ and few (if any) managed apps. Examples? Google Chrome, Firefox, iTunes, uTorrent, Spotify, Picasa, Google Earth, OpenOffice, Notepad++, IrfanView... this list goes on and on. I write desktop applications for a living, which are installed on thousands of PCs worldwide, and C++ is still my language of choice. The lack of dependencies (WTL is your friend) is a massive plus IMHO (and that of my customers I should add!.) YMMV though - as a seasoned developer I think I am productive enough in C++, but I can't speak for everybody.
It hasn't gone away if you need to do something really, really fast. If "fast enough" is OK, then C# and Java are fine, but if you have a calculation that takes hours or days, or you need something to happen on the microsecond timescale (i.e. high frequency trading) C++ is still the language to use.
More often than not, we get lost in the hype cycle. First there was Java, then came PHP, and currently is Python. But the fact of the matter is development of general purpose desktop application still requires use of libraries like Carbon/Cocoa for mac, GTK/QT for Linux, MFC for Windows. All of which are C/C++ based. So are most applications written for these platforms. So calling C++ as being relegated to embedded is not right, although yeah its being extensively used now, unlike earlier when it was just assembly or C at the max. In my opinion, if you want a high performance application with great looking GUI, it still has to be done in C/C++.
Different languages are prevalent in different domains. It is interesting that you think it might be rendered unimportant by being relegated to embedded systems when in fact that is where most software development occurs; at least in terms of number of projects/products.
There are many ways of measuring, and a number of them are presented here: http://langpop.com/. The evidence suggests that C++ remains important.
I'm not sure whether the gaming industry falls under "general purpose development", but if you want to develop anything that you intend to get working on more than a single console, C++ is what's for lunch. While many gaming and 3D libraries have extensions for other languages, they -all- have extensions for C/C++.
C++ is still used everywhere you want the best performance. Its major advantage is that you can use literally for everything. In addition to what other people have said you can also use it to power websites, for instance OkCupid uses it almost exclusively.
As the recent Hip Hop of Facebook shows, in the end, if you can afford it (ie. you have a large and competent team) you can always gains something using it. Then it also a matter of scale, other than industry.
C++ is still very popular. For instance, combined with Qt it is often used.
C++ is usually used for systems work, generally defined as software where the UI is not central, not application work -- where the UI is central. So, for general business use it's probably not very interesting and those problems are better solved with a higher level language. However, there will always be low level systems work to be done, and C or C++ is the practical answer for those problems right now.
As a general development language? Well, it depends on your industry, but I've worked in two different industries and there is always plenty of C++ work:
Telecoms
Embedded devices often use C and C++ for core services
Network equipment, often very complex, heavily utilize C++
Software apps that work with hardware will often be written in C++
Financial Services
Trade Execution systems are often in C++. You cannot have your garbage collection kick in when you're executing an order for a customer.
Algorithmic and high-frequency trading systems are usually in C++
General trading systems that do not have strict speed requirements seem to be in C++ and Java, with C# starting to show up as well.
Administrative applications tends to be written in Java, VB, or C# these days
Recently there is a trend towards functional languages for quantitative analysis, so F# and Haskell are starting to appear, and SAS and Matlab are always common too
I read somewhere that Nyse/Euronext uses Java, but that they disable the garbage collector and run on servers with insane amounts of memory.
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 8 years ago.
Improve this question
Is anyone out there using D for real world applications? If so, what are you using it for? I can't seem to find anything big on the web written in D.
Despite the lack of known big users, D seems like a very promissing language to me, and according to TIOBE, it's fairly popular.
I do bioinformatics work in D. For me, the key thing about D is that it takes a very level-headed approach to tradeoffs and recognizes the principle of diminishing returns.
Unlike C++, which adheres rigorously to the zero-overhead principle, D allows features that may have a small performance/space cost if they make the language a lot more usable. These include garbage collection, a monitor object for each class, runtime type info, etc.
Unlike Ruby, Python, PHP, etc, D tries to be almost as fast as C, even if it is less dynamic and slightly more difficult to program in than scripting languages.
The result is a language that is optimal when both development time and execution time matter about equally, which in my field is most of the time.
Similarly, D takes a very level-headed approach to safety vs. flexibility. It assumes that programmers basically know what they're doing, but do make mistakes.
Unlike C and C++, it assumes that you don't want to use pointers, unsafe casts, manual memory management, etc, everywhere in your code, because they're error prone, and assumes that you don't want to sift through multi-page template error messages when you screw up just to use resizable arrays.
Unlike Java and other bondage-and-discipline languages, D assumes that sometimes pointers, unsafe casts, manual memory management, etc. are a necessary evil, and assumes you're smart enough to handle real templates, operator overloading, etc. without writing obfuscated code. It also assumes that you may screw up and access an array out of bounds, but that the programmer knows best what tradeoff should be made between safety and speed in any given situation. Therefore, whether arrays are bounds checked is simply determined by a compiler switch.
I'm using D for my research work in the area of computer graphics. I and others have had papers published in our fields based on work done using D. I think it's definitely ready for use on small to medium sized research projects where performance matters. It's a nice fit for research work because often you're starting from scratch anyway, so you don't have much legacy code to worry about integrating with.
Another popular area for use seems to be web services. Hopefully someone else can comment who's in this space, but there too I think the idea is that performance often really matters so you want a compiled-to-the-metal language. Services are often fairly small, self-contained processes, so interop with large amounts of legacy C++ code is not really necessary or useful. Thus D can get its foot in the door.
I think D will continue to gain grass-roots followers in this way -- on smaller projects that for whatever reason can afford to ditch the C++ legacy in order to gain a programming language that's much more enjoyable to use, and perhaps more productive too.
But until there's a huge number of grass-roots users there won't be much in the way of big corporate users I suspect.
I know of one smallish company that have sent a mail server product to the market. They had at least 2 people working full time on the project.
Also, a major player in the IT business have several employees using D in larger internal projects.
Further I know of one company seeking venture funding, several (at least 4) employees in smaller companies using D either part or full time, and at least a couple (including me) actively seeking opportunities in the consulting market.
I've probably left out a few that I should have known about, and probably some I haven't heard about, but that still exists, as the above is more or less those I know myself via the community.
A small percentage of my current income comes from D.
I use D for web development and it proved quite a lot more productive compared to C/C++.
There are a lot of frameworks based on ruby/php/python, of course.
But when you want to develop something unique that also have to be as fast as C and nearly as easy as to program with as you do in many script languages, then D is a good choice.
I use D for a hardware in the loop (HIL) test environment. This is for software tests in the automotive area. D can be used here, because as a system programming language it is possible to be used in real-time programs (IRQ handlers in a linux real-time extension RTAI-LXRT).
With the ongoing port of SWT/JFace I plan to do more and work in D which I would have been done in Java before.
Facebook announced that they are using it in production as of today.
I'm using D in research about compile time code translation. The advanced templating combined with tuples and mixins makes code translation much easier and allows for code translation to be done during compile time without requiring a separate tool.
There are some examples of physicists using D to enhance their programs with meta-programming in D.
video - Conference talk, could not find source site of physicist use.
Our whole (high-traffic) network infrastructure is based only on D1 and tango. We are a young startup company in Berlin: sociomantic.com
My current work task is a system to translate C# to D. This is as part of a for profit project to develop a software system.
Well, I have written a couple of research papers in D as have others.
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.announce&artnum=13337
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=9466.
It seems that Remedy Games has a large D2 codebase for their games (cf. Using D Alongside a Game Engine by Manu Evans - DConf 2013).
They are a big company, knowing that a big company is using D is very good.
A lot of the games released by ABA Games are written in D 1.x, though I imagine the console ports had to be rewritten in C++.
I've written quite a few game prototypes in D, but I'm not sure if that qualifies as 'real world' since I wrote them for my own benefit and have never released any of them.
I wrote (and I am still maintaining and developing) a software for the conversion of tester protocols from various hardware testing stations to a standardized output format for traceability and stuff like that.
All together over 5k lines of code, written with D 1.x and the Phobos library.
D is so easy to learn, and disregarding some pitfalls (in the Phobos library) a real joy to program.
I used D for my research project on developing a global optimization algorithm. I applied it to the problem of training neural networks. It's up to you whether you want to call this "real world".
I wrote a wrapper script that builds DGCC on OS X
http://github.com/davecheney/make-gdc-apple/tree/master
I'd love to hear from other DMD programmers out there
I use D2, the second standard of the version. I wrote real-time applications (3D engine, for instance).
The language gets more and more powerful each day. D is very pragmatic and all the embedded features, especially the metaprogramming paradigm, makes it far over C++, in my opinion. The syntax is clearer, you can use the strength of functional programming through functions such as filter or reduce, and one of the most important feature: you can use all the C libs.
Definitely my favourite language, and I’m pretty sure it will be a spread used language.
I suppose we can read something into the lack of immediate answers to this question and that is that not many/any of the acive stackoverflow responders are using D. I was also a little surprised about the level of its ranking in the TIOBE listing that you link to.
Having said that, Walter Bright has been working on the language for quite a number of years now and I think he has quite a number of `followers' who remember what a good job he did with the Zortech C++ compiler back in the '90s. I also note that the language appears to be leaning towards the functional direction now.
The D's official website enumerates the organizations that are currently using D.
http://dlang.org/orgs-using-d.html
The D wiki also provides a list of organizations, but it's outdated.
Just watch carefully DConf talks.
DConf 2013
DConf 2014
Almost all people there work for some company, and they use D at work.
I am starting a project to rewrite some of our internal tools from Perl to D. I chose D because I'm pretty excited about the design philosophies of the language. I've been programming for a long time and used a lot of languages, from assemblers to high-level (mostly C) to scripting languages (mostly Perl), and D is the first language I've been enthused about learning in many years.
I decided to move to a compiled language for one main reason - security. Functionally, Perl works quite well for the toolset I work on, but it's insecure - anyone that can run a script can also read, copy and create their own modified version of the tool. (And they do.) I know there are circuitous methods to get around this problem (sort of), but to be honest I don't have enough hours in the day to manage all of that and still get my primary job done.
I started a ray-traced renderer in D with ldmd2.
http://palaes.rudanium.org/SubSpace/render.php