Related
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 does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
We would like to create some simple automated tests that will be created and maintained by testers. Right now we have a tester who can code in any language, but in the future we might want any tester with a limited knowledge of programming to be able to add or modify the tests.
What is a good programming language for testers who are not great programmers, or programmers at all?
Someone suggested LUA, but I looked into LUA and it might be more complicated that another language would be.
Preferably, the language will be interpreted and not be compiled. Let me know what you think.
Update: C and C++ are under the hood. No one is aspiring to be a programmer really ... it just might be something they could potentially work on if they can handle the task.
Update 2: I am a software engineer who happens to be a tester right now. I am very knowledgeable about the entire lifecycle ... including developing code, so for me I could go with any language but I'm trying to think of other testers who aren't as knowledgeable about programming as I am.
Update 3: The language will need to be able to make calls to the C++ code easily.
You may not even need language depending on what you are testing you can use
Test Modeling tools like CubicTest: http://cubictest.seleniumhq.org/
Highly recommend you check that out if you are doing Web Applications.
Our QA team had great success with it.
Otherwise I would recommend a Domain Specific Language over a General Purpose Language in your problem domain. The DSL might actually be a subset of a GPL (for example Rake for Ruby) so google carefully.
If you can not find an existing DSL then:
Create a DSL for your testers using Ruby or Scheme. Those two languages are the
easiest to create Domain Specific languages.
Python If all else fails and they need a GPL than Python is by far the easiest language to learn IMHO.
EDIT - Based on your updated requirements, Python might be the best fit. I have found it very easy to call C or C++ with Python CTypes. However I am sure Ruby has something equally as good.
I always reccomend Python.
People always think i am crazy, but it is the easiest and most flexible to show people. And you could always design some type of "test" framework, and only expose them to a very small subset of it.
And you can always refer them to :
(source: barnesandnoble.com)
I think that before actually choosing a language, we should define even more precisely what you are looking for.
Garbage collected, as we don't want people to have to understand memory management!!
Good number of modules/libraries around, so as not to reinvent the wheel
Preferably coming up with already existing (and tested) unit-test frameworks
Good documentation for the modules/libraries
Preferably scripting language, because tests have to be modified/run quickly
Easy interaction with C/C++, though the developers will have to provide the interface
And, perhaps most important of all:
clear and "english-like" syntax, so that it will be (at least) readable by non-tech people
Based on this list, I would recommend Python.
It's perhaps the programming language (having reached a critical mass) that is the closest to traditional english / algorithm expressions. It's certainly one of those with the least punctuation / weird symbols that throw off non-programmers
It comes immediately with so much modules that it's unlikely you'll have to dig for more any time soon... comprising a unittest module
The documentation is really good, generally illustrated by examples
It is quite simple to interface it with C
You can even run Python scripts from Java using JPython ;)
We have a in-house software for our non-regression tests. While it's been programmed in Java (probably for the GUI part and the Windows/Unix portability requirement), Python has been elected as the language to use within the non-regression tests themselves.
This is used mostly by our QA people, and even beginners usually take to it pretty easily, even when they don't have any programming background at all.
Note: I don't have any practical experience with LUA, so I am unable to choose between Python or LUA. However, having use both Python and Ruby, I must say that I have found Python much more readable (loop constructs / punctuation). Just make sure not to pick up Perl ;)
Depends a bit on what you want, but for my money Ruby is probably the most comprehensible language around.
Also if you're working with web stuff, then Watir gives you a lot of testing functionality right there.
If your ambition is at all to become a programmer, I'd suggest using the language of the system you're testing.
The experience will make you a better programmer, and the knowledge can only make you a better tester.
Python is a very simple and useful language to understand. Some even compare it to writing pseudocode. It also comes with its own unit testing framework.
EDIT: It also comes with a C API.
I think the better question might be what do you plan on doing with the programs created. I have done Java, html, css, php, mysql, vb, C#, etc, etc. Out of all of them, the fundementals remain the same. You always have the same type of logic from language to language. IF ELSE statements, for loops etc. However if your not planning on creating self loading programs then you would go for something that wouldn't do that.
Persoanlly Java is difficult but allows for a lot of portability. Don't just go with what's easiest, because you might not be able to do anything with it in the future.
EDIT *
if you are still interested, java has the ability to make calls to C++, but not without it's share of problems. Link this link has a look at making calls, but might be a little too involved if you're only hoping to show introductory programming.
Ok, as I understand the question it is really, how can I let non-programmer's write automated tests for an app written in c++? So in this context I would suggest taking a look at Fit and FitNesse.
Fit is essentially a table based F ramework for I ntegration T esting. The idea is that you hook fixtures up into the code to test and those fixtures are then controlled in different ways using nothing more than tables or in the case of FitNesse simple wiki markup which creates the tables under the hood.
The advantage of this is that there is no programming language involved at all. They just need to know what fixtures you have exposed and the proper usage for them.
The drawback of this is that it can be difficult at first to map out the fixtures you need/want for your tests. Also, it is generally more maintenance than using like a unit test framework where the tests are all just in code.
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
Let's say you have a company running a lot of C/C++, and you want to start planning migration to new technologies so you don't end up like COBOL companies 15 years ago.
For now, C/C++ runs more than fine and there is plenty dev on the market for it.
But you want to start thinking about it now, because given the huge running code base and the data sensitivity, you feel it can take 5-10 years to move to the next step without overloading the budget and the dev teams.
You have heard about D, starting to be quite mature, and Go, promising to be quite popular.
What would be your choice and why?
D and Go will probably just become as popular as Python and Ruby are today. They each fill a niche, and even though D was supposed to be a full-fledged replacement of C++, it probably will never acquire enough mass to push C++ away. Not to mention that they both aren't stable/mature enough, and it's unknown whether you'll have support for these languages in 10-20 years for the then-current hardware and operating systems. Considering that C/C++ is pretty much the compiled language and is used in the great majority of operating systems and native-code applications, it's very unlikely that it'll go away in the foreseeable future.
C and C++ are a pretty much unbeatable combo when it comes to native/unmanaged/"lowlevel" languages.
Not because they're the best languages, far from it, but because they're there, they do the job, and they're good enough. There's little doubt that D, for example, is better than C++ in most respects. But it fails in the most important one: Compatibility with all the existing C++ code. Without that requirement, most of that code would be written in a managed language today anyway. The only reason so many codebases use C++ today is because they used it last year, and it'd be too much of a pain to switch to something else. But if and when they switch, they typically don't switch to D. They switch to C# or Java or Python.
The problem for D and other "upcoming" languages competing for the same niches, is that while they're better, they're not groundbreaking enough to motivate people to actually switch to them.
So C and C++ are here to stay. C is unlikely to evolve much further. It is as it is, and one of the niches it has to fill is "simplicity, even for compiler writers". No other language is likely to beat it in that niche, even if they never revise the standard again.
C++ is evolving much more dramatically, with C++0x getting nearer, and they've already got a huge list of features they want to do afterwards. C++ isn't a dead end in any way.
Both languages are here to stay. Perhaps in 50 years other languages will have replaced them, but it won't happen this decade.
I currently use D regularly. I wouldn't recommend it yet for people writing production code because it's too bleeding edge. I get away with it because most of my code is research prototypes in bioinformatics. However, the language is starting to stabilize. Andrei Alexandrescu is releasing a book titled "The D Programming Language" next March, and right now there is a push to stabilize the spec for version 2 of the language in time for the book.
While D is not a formal superset of C, it is what I'd call an idiomatic superset except for the lack of a preprocessor. In other words, any code written in C proper (ignoring the preprocessor), can be trivially translated to D without a redesign, because C concepts like pointers and inline ASM are there and work the same in D as in C. D also supports direct linking to C code and the D standard library includes the entire C standard library.
Also, despite D's lack of libraries because it is still a bleeding edge language, it's a library writer's dream because of its metaprogramming capabilities. If it takes off, it will probably have some pretty impressive libs. For a preview of this, see std.range or std.algorithm in the D2 standard library (Phobos). As another example, I implemented an OpenMP-like parallelism model (parallel foreach, parallel map, parallel reduce, futures) as a pure library in D, without any special compiler support. (See http://cis.jhu.edu/~dsimcha/parallelFuture.html)
Given that you're mostly interested in the long term, I'd say give D 6 months to stabilize (given Andrei's book and the current push to stabilize the language, version 2 should be stable by then) and then take a hard look at it.
Edit: Now that the core language spec is relatively stable and the focus has turned to toolchain and library development, I would recommend D for small production projects unless you are in a very risk-averse environment. Larger projects that absolutely must have good toolchain and library support should still wait, though.
If you believe in the lean manufacturing principles, you should strive to "decide as late as possible". The moment should be the last responsible moment, meaning the moment at which failing to make a decision eliminates an important alternative.
I think this principle can be applied to your situation. Instead of committing now to a language (that you don't even know will be around in 10 years), you should keep your options open. Maybe refactor some of your code so it is a bit more generic or is built on more abstractions, so that when it is indeed required to migrate, the process will be easier.
Stick with C and C++. I don't see it going the way of COBOL, it runs as well as anything, and you'll have no problem finding people to code in C and C++.
C++ -- it is relatively young and updated... It has a big number of compiler vendors and got
improved all the time.
C -- it would live for a long time filling the gap between assembler and higher level languages. It is also very simple and easy to implement language, so it would remain the
first language for various "strange" architectures like embedded or extremely new ones.
D is promising but still very new and unstable specifications and libraries.
Go was born few weeks ago... Never use anything of version 0 for big important projects. Also it is significantly more limited the C++ or D.
2019 update: C++ will stay around for the next 10 years... (if not, I will correct this answer, when it will not be relevant any more....)
the reason companies works with COBOL today is b/c they already have millions of COBOL code written. if the could throw it - they will do it at once, on the other hand - companies work with C/C++ as part of their needs and new projects using this language b/c they can't / don't want to use java/c# any other framework based language - so COBOL is not the analogy here.
Like dsimcha said the D way is currently risky. Yet the language has a huge potential, it is low-level and i've experienced drastically better productivity with D (instead of C++). Perhaps what people feel with dynamic languages.
Go is so much blog-marketed it seems like a joke to me.
Dispatching an interface method is not trivial, and actually slower than dispatching a regular single-inheritance method.
If you'd have a huge codebase the decision is of course more difficult, I would advise only to switch for new projects, not for existing ones.
I wouldn't concentrate on a language but more on the libraries surrounding it. C++ in combination with the boost libraries are an excellent choice. People who develop in C++ tend to have a better understanding of computing, I myself started of with Java which made my life easier by hiding a lot of fundamental stuff, which is good, however I only really started to understand programming once I learned C/C++ (pointers etc).
I do recognise that C++ can be hard (e.g. memory management) so I think it's good to have a 'add on' language where performance is not essential and readability (==maintainability) scores high: I recommend Python for this.
There are countless machines running C++ software, I don't see them shutting down all at once. If C++ will go in the way of COBOL there will be a huge market for application migration. There will be specialized tools developed to translate C++ applications to the popular language of the time (Z++ ???).
So I guess the best advice is to cross that bridge when you come to it.
Check out Intel® Cilk++ Software Development Kit if you want to spark your interest in C++/Multi-Core development. I don't see C or C++ going away anytime soon either.
Comparing C* to Cobol is questionable
Comparing C* to Cobol may lead to the wrong conclusion. C was perfect for its day, a huge leap forward on its introduction, and it still gets the job done today.
I would sum up Cobol on my most charitable day with "nice try".
C and C++ will survive for a long time because they fit the bill well as implementation languages. This won't ever really change.
Also, consider that the main negative issue with C/C++ is the lack of memory safety. This tends to be less and less of a problem as codes mature. This means there will not be a serious reason to replace the old codes.
I expect that software systems will grow outwards from C. Look at the hierarchy today:
application written in a framework such as Rails
application back-end written in Ruby, PHP, Python, C#, whatever
Ruby, PHP, Python, or C# run-time implementation (written in C*)
OS kernel (written in C89)
I don't think the old layers will vanish, and I think legacy higher layers written in C and C++ will simply be supported that way for an indefinite period of time, eventually being phased out for their replacements written in Ruby, Python, C#, or a future development.
We have no idea if Go will find acceptance. Just being by Google is probably not going to be enough.
D? Well, some nice things are being said about it but it won't be taking off either. No user base to speak of. D is #20 in popularity on the TIOBE Index, and dropping fast.
You may say that a language's popularity has little to do with how well it's suited for your company's work. But it has a lot to do with how easy it will be to find people qualified to program in it.
Java is on top and I would be surprised if it went far away in the next 20 years. It's not considered a systems programming language but performs well enough that there are few tasks you'd do in C++ that you couldn't in Java. Certainly these days nobody is willing to task human programmers with the job done (flawlessly and often more effectively) by the garbage collector. I for one considered Java a significant step up from C++ in terms of programming effectivity.
I'm quite impressed by Ruby. It's an elegant, expressive language: You can accomplish a lot with not too much code, yet that code is still mostly legible. One of Ruby's main principles is to be consistent and not hold surprises for the developer. This is an extremely good idea, IMO, and boosts productivity. At the time of the big Rails hype (which may still be ongoing), I made a wide berth around Ruby because its reference implementation is abysmally slow. However, the JRuby folks at Sun have made it blazingly fast on a JVM, so now it's definitely worth some consideration. Ruby provides closures and a good handful of functional programming capabilities (see below for why this important), though it's not really considered a FP language. TIOBE index: 10 and rising.
Something to consider for the future is the fact that CPU makers have run up against a performance limit imposed by physics. No longer is there a 30% faster CPU available every Christmas, as it was in the past. So now to get more performance you need more cores. Software development will need all the help it can get in supporting multi-core concurrent programming. C++ leaves you mostly alone with this, and Java's solutions are horrible by modern standards.
In view of this, there's a certain trend toward functional programming (which eliminates much of the hassle associated with concurrency) as well as languages with better concurrency support. Erlang was written specifically for this and for the ability to swap code in a running program (Ericsson wanted incredible uptimes). Scala is similar to Java but with much stronger support for functional programming and concurrency. Clojure, ditto, but it's a Lisp and it's not even in the top 50 (yet!!).
Scala was developed academics, and shows it: It's sophisticated and downright pedantic about data types; it tries to be the Swiss Army Knife of programming languages. I believe a lot of medium-smart programmers will have trouble getting a grip on Scala. Ruby is less FP and doesn't do so much about concurrency, but it's pragmatic, and fun and easy to get stuff done in. Also, running on the JVM, there is an enormous amount of code readily available in Java libraries, which Ruby can interface with. So:
My bet would be on Ruby, with an outside chance on Scala. But there are plenty of alternatives!
Java. For most low level things Java is fine these days. Why go with a partial solution to C/C++ such as D or Go when you can have something as safe and easy to develop with as Java? If you are looking for a real time solution, D and Go are definitely not it, not to mention they are probably even less supported than Java.
Java is now a system programming language. I don't see how you can consider anything with unsafe constructs such as pointers "next gen". The only reason those insecure constructs ever existed is because it was the pragmatic approach to building a turing complete language. There was no concern of representing the memory in discrete objects, because they just wanted to build something that worked. There are already hard and soft realtime applications in Java, a variety of hardware bytecode processors, and over 2 billion mobile devices running Java. At most all you would have to do is add some constructs for interoperability with devices, which wouldn't be that much code; even in C/C++ you'd still have to add these constructs...
What are you programming? 8-bit microcontrollers with 1KB ram? In that case, it would be pointless to use anything other than the assembler for that platform...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm thinking of trying to make some simple 2d games, but I've yet to choose a language. A lot of people recommend either C++ with SDL or python with pygame. I keep hearing that developement on C++ is fairly slow, and developement time with Python is fairly fast.
Anyways, could anyone elaborate on this? What exactly makes development in C++ so time consuming? The programs I've made have been Project Euler-style in that they're very short and math-based, so I have no experience in larger projects.
There are two things that are relevant between C++ and Python that will affect your time-to-develop any project including a game. There are the languages themselves and the libraries. I've played with the SDL to some extent and peeked at PyGame and for your specific instance I don't think the libraries are going to be much of a factor. So I'll focus on the languages themselves.
Python is a dynamically-typed, garbage-collected language. C++ is a statically-typed, non-garbage-collected language. What this means is that in C++ a lot of your development time will be spent managing memory and dealing with your type structure. This affords you a lot of power, but the question is do you really need it?
If you're looking to write a simple game with some basic graphics and some good gameplay, then I don't think you truly need all the power that C++ will give you. If you're looking to write something that will push the envelope, be the next A-list game, be the next MMO, fit on a console or a handheld device, then you will likely need the power that C++ affords.
The power of Python is in it's ability to allow you to focus more on the problem than having to deal with testing low-level issues such as memory allocation. I can't count how many times days of development have been wasted tracking down memory leaks in C or C++. An advantage of all high level languages.
Python is very easy to learn compared to C++,so you can be up to speed a lot quicker in doing basic programming tasks. Therefore, you'll move quicker into advanced tasks as well.
C++ has a lot of power but has many ways to shoot yourself in the foot compared to Python(not saying that can't be done in Python).
The compile/debug cycle can get old sometimes in C++ depending on what you're trying to do. Although technically speaking, everytime you run a Python script it's getting "compiled" per se, it's just a quicker cycle. A good IDE can help alleviate this is in Python by automatically checking your code for syntax errors while you type it out.
If you have some code you want to test inside a larger project, it's a hassle sometimes to isolate it for testing. Whereas a good Python interpreter such as IPython, makes it easy to test a small bit of code and see how the language behaves and paste it into a file.
Python also interfaces very well with existing C/C++ code through many numerous ways. That way if a new whizbang Python module you created is really slow, then you can soup it up in C/C++ then wrap it up with Python through ctypes, Boost::Python, or SWIG.
And most of all, Python comes with a great standard library that has a lot of stuff figured out for you. It's just a matter of putting the pieces altogether! It has a great community behind it, so if it's not in the standard library, there's a good chance someone out there has solved the problem (PyGame, Numpy, SciPy, Pyserial, PyWin, etc.) for you. You can just google it, grab it and plop the code right into your program...away you go!
I've heard these complaints before about C++, but the fact is, programming in any language with which you are unfamiliar is time consuming.
A good C++ programmer can probably crank out the app much faster than an okay Python programmer and visa versa.
I think C++ often gets a bad reputation because it allows you get much lower level - pointers, memory management, etc, and if you aren't used to thinking about such things, it can take a bit of time. If you are used to working in that environment, it can become second nature.
Unless choice of language is something imposed upon you by your company, team, client, etc. I usually recommend that folks go with the language they are most comfortable with OR most interested in learning more about. If speed is the issue you are concerned with, look at the learning curve for each language and your past experience. C++ tends to have a higher learning curve, but that too depends on the person.
Kindof a non-answer I know.
Python has some big advantages over programming languages like C++. I myself have programmed a lot with C++, C and other programming languages. Lately I am also programming in Python and I got to like it very much!
You can have a quick start with Python. Since it is rather simple to learn (at least with some programming experience and enough abstract thinking), you can have fast successes. Also the script-like behaviour makes starting easy and it is also possible, to quickly test some things in the integrated shell. This can also be good for debugging.
The whole language is packed with powerful features and it has a good and rather complete set of libraries.
There was the argument that with the "right library" you can develop as quickly with C++ as with Python. This might (partly) be, but I myself have never experienced it, because such libraries are rare. I had also a big library at hand, but still lacked many valuable features in C++. The so called "standard template library" STL makes things even worse in my opinion. It is a really powerful library. But it is also that complex, that it adds the complexity of an additional programming language to C++. I really disliked it and in a company I worked in, much worktime was lost, because the compiler was not able to give useful error-output in case of errors in the STL.
Python is different. Instead of putting the "speed of the programm" on the throne -- sacrificing all else (as C++ and especially the STL does) -- it puts "speed of development" first. The language gives you a powerful toolkit and it is accompanied by a huge library. When you need speed, you can also implement time critical things in C or C++ and call it from Python.
There is also at least one big online Game implemented in Python.
It's time consuming because in C++ you have to deal with more low-level tasks.
In Python you are free to focus on the development of the actual game instead of dealing with memory management etc.
there are many things that make c++ longer to develop in. Its lower level, has pointers, different libraries for different systems, the type system, and there are others I am sure I am missing.
It takes about the same amount of time to write the same code in pretty much all of the high level languages. The win is that in certain languages it is easier to use other peoples code. In a lot of Python/Ruby/Perl apps, you write 10% of the code and import libraries to do the other 90%. That is harder in C/C++ since the libraries have different interfaces and other incompatibilities.
C++ vs Python is a pretty personal choice. Personally I feel I lose more time with not having the C/Java class system (more run time errors/debugging time, don't have anywhere near as good auto completion, need to do more documentation and optimization) than I gain (not having to write interfaces/stub function and being able to worry less about memory managment). Other people feel the exact opposite.
In the end it probably depends on the type of game. If your processor intensive go to C++ (maybe with a scripting language if it makes sense). Otherwise use whatever language you prefer
I'd focus more on choosing a framework to build your game on than trying to pick a language. Unless the goal is to learn how games work inside and out, you're going to want to use a framework. Try out a couple, and pick the one that meets your requirements and feels nice to you.
Once you've picked the framework, the language choice becomes easy - use the language for which the framework is written.
There are many options for game frameworks in C++ - pygame works for python. There are many that work with other languages/tools as well (including .NET, Lua, etc.)
Short Answer
Yes python is faster in terms of development time. There are many case studies in real life that show this. However, you don't want to do a 3d graphics engine in Python.
Do you have any programming experience at all? If not, I would start with Python which is easier to learn, even if it is not a better tool for game development. If you decide you want to program games for living, you'll probably need to switch to C++ at some point.
Note that SDL is currently slow, because it basically doesn't use hardware acceleration.
SFML is an alternative of choice, and is available in Python too.
Why limit yourself to those two options? With C# or Java you get access to a huge collection of useful libraries plus garbage collection and (in the case of C#) JIT compiling.
Furthermore, you're saying that you're looking to do game development, but from your task description it sounds like you're also looking at coding your own engine. Is that part of the exercise? Otherwise you should definitely take a look at the available Indie engines out there - lots are cheap of not free and open source.
Needless to say, working from an existing engine is definitely faster than going from scratch :)
Some people would argue that development time is slower in C++ when compared to Python.
Wouldn't it be the case that the time you saved in developing an application (or game) in python is the time you gonna use in improving performance after its developed? and in the later part when you have least options left?
It largely depends upon the purpose for which you are going to develop the application.
If you are thinking for an enterprise application in which case it is going to be hit by millions (web-app) or an application with focus on low-footprint, faster loading into memory, faster execution, then your choice is C++.
If you are projecting your application for not being use at this level, surely Python is the choice to go for.
Maintainability is considerable, but disciplined code can overcome this.
Largely depends upon long term projections. On how serious and critical the application is going to be.
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