Are Fortran, Cobol, Basic and Forth high level programming languages?
And if not, what where the first high level programming languages?
Which were the first object-oriented languages?
Fortran - first high level programming language.
Simula - first object-oriented language.
High-level isn't a binary value. There are a whole range of languages in a spectrum from low-level to high-level.
The languages you named are higher level than assembly, but lower level than Lisp.
According to Wikipedia:
The first high-level programming language to be designed for a computer was Plankalkül, created by Konrad Zuse.
"High-level" can have different meanings -- some languages are at higher-levels than others, abstracting farther away from the machine. The original FORTRAN was delivered in 1957 (http://en.wikipedia.org/wiki/Fortran) and was, AFAIK, the first implemented language at a higher level than assembly. Other languages since then can be classified as higher-level. For example, the current Fortran standard, Fortran 2003, has a much higher level of abstraction than the original FORTRAN, providing array operations, some OO features, etc.
CoBOL is technically considered a "high-level" language. It has some functions, and does some elements of memory management. But in the scale of languages, I'd rank it about half of a step above assembler. This is my approximation from my experience with all of these, please edit the response if you want to contribute some more languages.
0 - Binary machine code
0.5 - Assembler
1.0 - CoBOL, Fortran, Pascal, C
1.5 - C++
2.0 - VB6
2.5 - C#, VB .Net, Java, etc
3.0 - Javascript, CSS, SQL
The first OO language was probably Simula, though not many people knew it until Smalltalk came along.
COBOL and FORTRAN (as they are now) as higher level than C. The abstraction of underlying machine is greater. One should expect a COBOL program - even of considerable complexity - to compile on Windows or *Nix without alteration. The same is true of Fortran (though my knowledge is more out of date here).
The latest versions of COBOL are very high level - see managed cobol here: http://knol.google.com/k/alex-turner/micro-focus-managed-cobol/2246polgkyjfl/4#
Please note - I work for a COBOL company - Micro Focus. This might mean my input is biased :)
As for your last question:
Among the first object oriented programming languages was http://en.wikipedia.org/wiki/Simula
The first more or less popular object-oriented language was http://en.wikipedia.org/wiki/Smalltalk
They do since they hide computer hardware abstraction, so they can be considered as high-level.
The first object-oriented language was SmallTalk, according to Wikipedia.
It's all relative. C is low level for those who write Python, C++ for Java developers and so on.
As for the OP's question, yes Fortran is certainly high level. Modern Fortran is almost like MATLAB.
Related
What are the programming languages we can use in the development of an artificial intelligent system? which operating system should be used? can C or C++ programming languages be used?
What are the programming languages we can use in the development of an artificial intelligent system?
Prolog is a good start for reasoning systems. Lisp is a good start for symbolic systems. Both of those can be embedded in other languages, e.g., C++.
which operating system should be used?
Er.... any?
can C or C++ programming languages be used?
Yes.
You probably want to learn more about programming before you tackle AI.
Definitely. And it's a good choice too, because it can be made pretty well performing (which is the main problem in developing a good AI).
But there is no limitation, really. Any language will do.
Just about any language can be used but you want one that works well with your specific domain, and you are comfortable with using.
As already mentioned, PROLOG and LISP are both traditional AI languages. General purpose languages such as Java, C#, and C++ also have their uses.
Also if you are looking at aural language processing, then a language that is good at text processing and data structures would be ideal. Eg. Python and the NLTK toolkit.
Although some languages are more strongly associated with AI programming than others -- e.g., LISP, Prolog -- many different languages can be used.
Any of the general-purpose operating systems may be used.
You can use a procedural language like C. An OO language like C++, Java or C# offers some advantages. Functional and logical languages are also worth considering.
Personally, I've written one A-B game-playing program now in LISP, Java and C#.
Any language can be used to develop Artificial Intelligence, AI, applications; some make implementing the AI concepts easier than others.
Some old time favorites are LISP and Prolog.
If you are well versed in C or C++, then use either one to implement the concepts.
When you want to learn AI programming you should pick a language where you can concentrate on the problem domain instead of the language.
For example in a typical C program about half of the code concerns itself with memory management and error handling. By using a language that supports garbage collection and exceptions you can reduce this amount drastically.
The choice of language also depends on prior works. Are there any or do you want to start from scratch? If the prior works seem to be good, you can hope that they already chose an appropriate language.
It depends on the niche you are interested in, but C++ is probably the most popular language for artificial intelligence. You will find that most libraries are written for it.
You can use languages other than C++, too. Functional languages, such as LISP and F# are good choices for AI, because they offer good tools for decomposing complicated logic.
The operating system is not much of an issue. Whether you choose Windows, Unix, or Mac, you will find a few libraries that are not cross-platform and unavailable for your 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 12 years ago.
All,
There are so many programming languages/Operating systems/device drivers i.e. softwares that are built using C and C++. I was wondering if C and C++ were the only 2 low level programming languages that all companies ever had to build their own product(s)? If there are, why do C and C++ get so much preference over other options?
There are many "medium-level" languages suitable for OS development, but C and to a lesser extent C++ are by far the most popular. There are many reasons for this, including:
The early success of C as the implementation of Unix led to its widespread adoption.
The vast availability of great development tools (compilers, lint, editors, memory leak analysis, profiles, code generators, ad nauseam) makes C even more compelling.
The closeness of C to the "abstract machine" level; unlike, say, Pascal, which has considerably more runtime overhead. This is desirable when writing high performance software. C has sometimes been called a "portable assembler" for its closeness to the hardware.
Forth is sometimes used for developing low level software like device drivers. For example the boot prom for SUN SPARC based servers used to be written in Forth. See http://en.wikipedia.org/wiki/Open_Firmware for details.
There are other low-level languages, but C had the benefit of a 'popularity snowball' effect.
It's about as efficient as any reasonably portable language can be, so it's a good choice for systems programming. Once you build an operating system on it, it makes sense to build tools for the same system with it, so a lot of programmers got exposed to it in the 80s and 90s. Thus it became a lingua franca that all systems programmers were familiar with.
There's relatively little you can do to improve on C without compromising either its efficiency or its portability, so there was no obvious place to compete against it at the low level.
I know some people that do systems programming in D. It is lower level than C#, etc. but had many of the same benefits of modern languages.
Even more than the low level of abstraction, the key feature of C and (C++ with RTTI disabled) that is applicable to system software is that they don't need any runtime library.
See, you can write a compiler in the very same language, but you can't write a runtime in the language that depends on it.
C has a standard library but not a runtime library, so you can implement the standard library in C, and you can also use it to write the runtime libraries for other languages. Ditto for C++ (with RTTI disabled).
No, there are absolute bucketloads of languages that companies use to produce their software. C has a clear advantage over all of them for one particular area, that of very low-level stuff, since it imposes very little between the code and the hardware.
Most other languages (including C++ to some extent, unless you restrict yourself to the C side of it) tend to carry a lot of unnecessary baggage which, while an absolute godsend for applications programming, tend to just get in the way for systems level stuff.
Of course, you could also use assembly code but that's rarely necessary nowadays with the quality of the C compilers.
Ada, Pascal, assembly, Fortran, etc etc. Even when you are limiting the discussion to low-level languages, you still have a lot of choices. There are a lot of companies that don't do much C or C++ work at all (for example, the US military does a considerable amount of work using Ada).
One reason C and C++ are so popular is because so many people know those languages (I realize that's a recursive answer). Companies use C or C++ because it is easy to find a developer who knows the language, and developers learn the language because that is what companies are hiring. It also doesn't hurt that there is a very wide selection of books, compilers, IDEs, debuggers, libraries, etc etc for C and C++, and that C/C++ compilers are available for practically any platform you might encounter. Plus, these languages have been around for quite a while. Legacy C code is more likely to be maintained by a C developer than re-written in another language. Both C and C++ are versatile, powerful languages that will continue to be used for the forseeable future. They are far from being the only option, though.
C has been the lingua-franca since the early days of Unix. There is so much existing C code, so much cultural root, that people just use the language. It's more than that: C is so well designed: in its simplicity, in its speed of learning, speed of compiling, speed of coding, speed of running; in its bible-like tutorial book, in the sheer amount of solid open-source code we still use and hack on today, and the list goes on. It's just a useful language, like no pressure-independent, gravity-independent diamond-sparkled million-dollar pen with finger-prints of angels can replace a pencil.
As for C++, it is not nearly as simple as C. On the contrary: it is arguably more complex than roughly any other language out there, in terms of grammar, dark corners, learning curve, proper modern code and other criteria. One would think this complexity would kill the language, and many in fact have been saying this for decades. Java was born on this premise. But here we are today, roughly thirty years after the language was born, and it's still live and kicking among the 10 most popular tags on StackOverflow. There is a number of people that are passionate about the language, yours-truly among them.
Granted, that doesn't explain why C++ is thriving today as a popular language. I think it's the freedom C++ gives you in supporting so many different programming paradigms. This is how C++ supports programming both as low a level as C, with that same efficiency, and as high a level as other languages, given proper helper libraries. I recommend you read this interview with Bjarne Stroustrup.
C and C++ certainly are not the only alternatives for low-level programming. But they are an option that is very hard to resist. The best option, if I may boldly suggest, if only for their solid, long history that hints they are both here to stay; and for the repertoire of solid code out there that demonstrates the things you can do with these languages. The support the existing software demands promises lots of active boards on the net, lots of hiring companies -- and all in all a live, kicking pair of languages.
How about C#? Many windows applications get built using C#.
How about Perl/Python? Many applications on Windows and Linux get build using those languages.
How about D? Always a nice language to use, but it's sad it does not talk as good as I need with native C++.
Partly because it was one of the first high level languages (after B) that was adopted on a large scale. Languages like Java are owned by companies, which at the drop of a pin could be dropped and then you wouldnt see any updates from oracle. There is also the fact that c and c++ translate to relatively low amounts of assembly code, which makes it much smaller and compact.
There is also, the most important philosophy of C. You dont pay for what you dont need. (i.e in java you have garbage collection, but if you write a program that doesnt need a garbage collector, than you have wasted resources and you pay for it is speed and efficiency.) In C, if you need something, you make it yourself, no lost resources, much more efficient code (depending on the programmer).
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...
Do you think VB is a good language for AI? I originally did AI using mainly Lisp and C/C++ when performance was needed, but recently have been doing some VB programming.
VB has the following advantages:
1. Good debugger (essential!)
2. Good inspector (watch facility)
3. Easy syntax (Intellisense comparable to structure editors of late 80's Lisp environments).
4. Easy to integrate with 3rd party software.
5. Compiles to fast code (CLR performance pretty good)
6. Fast development.
By the way, thanks for all the useful replies. I've upvoted everyone who contributed.
I would suggest you go with C# rather than VB.Net.
You get all the nice features that you discuss but a better (and more familiar) syntax.
Which VB are you talking about here? If you're talking VB.NET then yes, and no.. I would suggest C# or maybe F#.. F# is a functional language and hence is generally better suited for many of the patterns you'll be dealing with when programming AI. The newer versions of C# also have support for language features such as lambda expressions, anonymous delagates et al which may also benefit you!
When you say AI what do you mean? Its a very broad field. If you're just skimming the basics, like guided search and simple knowledge bases then yea VB .Net may seem beneficial. But the language structure and syntax makes it very inadequate when you start to delve into theorem proving, ILP and other areas of machine learning you'll begin to realize that language like Lisp are still being used today because they provide a more natural syntax for expressing AI concepts.
1, 2, and 3 are all aspects that any sufficiently advanced IDE has, so that's not much of an issue for most languages. As for 4, 5, and 6: Python fits 4 and 6, but not 5, as it is not very fast, though some implementations of Python do have better speed than others, depending on their configuration. (Just mentioning Python because you tagged your question with the python tag.)
If you do plan on using the .NET Framework, though, might I suggest C#? The syntax is similar to that of C and C++ (about as similar as the Java syntax is), so it'll be more familiar to you, and it does exactly the same things that VB does (and has all the same IDE features, as they both use the Visual Studio IDE, though I suppose you could use an alternative IDE if you wished, as the VB and C# compilers actually come with the .NET Framework itself and not with Visual Studio).
VB has the following advantages: [...]
But then you go on and list stuff that most modern implementations of Common Lisp offer, especially the commercial ones.
Have you tried Common Lisp recently? What parts of VB.NET do you miss when you're programming in CL?
It depends what you mean by "AI".
One common meaning is just "leading edge software technology" (e.g. chess playing is as of 2010 no longer consider to be very much about artificial intelligence, just a set of basic supporting techniques, because it's not leading edge any longer). For the leading edge stuff, the language should be chosen to suit the particular technology. Neither VB (various variants) nor C++ are likely to be good candidates then.
On the other hand, one might take AI to mean literally "artifical intelligence", the attempt to create true AI, even if just at the level of worm or housefly intelligence. Then the main stumbling block, as noted by Scott Fahlman very very long ago (eighties? seventies?), is the ability to perform huge set intersections in huge semantic nets very rapidly, in parallel, e.g. for recognition of that dangerous animal. And since current hardware isn't up that (the clock speed doesn't at all compensate for the von Neumann bottleneck), except conceivably stuff used by NSA and suchlike, it's a fight for sheer computing efficiency, which means that C++ could be a good choice for the lower levels.
Cheers & hth.,
– Alf
Doesn't matter what language you code AI in, if that language allows you to do complex mathematics. VB.NET has the same features as C# because it uses the same framework. Accessing those parts of the framework may have different callers.
AI requires a lot of optimizations for memory and trimmed custom functions... Get familiar with Reflection namespace for Un-managed memory callers. Pointers are possible and useful in un-managed memory; VB allows for these also which is what all the C# guys fight about because they don't know how to do it in VB. Memory / Pointer and Disc allocation is located in the Marshall Class which is an Interop Service.
http://msdn.microsoft.com/en-us/library/vstudio/system.runtime.interopservices.marshal%28v=vs.100%29.aspx
Anyone that tells you, C++ is the only way to go doesn't understand programming or is simply a bigot that believes C++ is the only language in the world.
AI is typically defined by math delegates that are functional representations of an action; therefore if your mathematics is no good; your code will be no good.
Neural Networks doesn't care what platform they were written in when they are assembled; they are Assembly.
The main reason to use C++ over a managed language these days is to gain the benefits C++ brings to the table. One of the pillars of C++ is "you don't pay for what you don't need". It can be argued though that sometimes you don't want to pay for backward compatibility with C. Many of the odd quirks of C++ can be attributed to this backward compatibility. What other languages are there where "you don't pay for what you don't need" including backward compatibility with C?
Edit/clarification: The real killer for me is in that second sentence. Is there a language truly designed from the ground up that doesn't impose things you don't want on your code? C++ has that as its design philosophy: don't want RTTI? It doesn't exist. Don't want garbage collection? It's not there. The problem with C++ is it (IMO) violates this requirement when it refuses to break from the past. I don't want the cruft of backward compatibility with 20 year old code hampering my going forward. C++ isn't willing to do that. What is/has?
Edit2: I suppose I should have been more clear about what a cost is. There are multiple potential costs. The one I was initially focusing on was runtime cost.
In C++ polymorphism through virtual methods has a cost. But not all methods pay that cost. A non-virtual C++ method is called with the same runtime cost as a plain old C function (having at least one parameter). C++ does not require you to use polymorphism. In other OOP languages all methods are virtual and so the cost of polymorphism cannot be avoided.
Runtime costs are most important but other costs mitigate against that. Assembly language would have the least runtime overhead obviously but the writing and maintenance costs of assembly language are a huge strike against it.
With that in mind the idea is to find languages that provide useful abstractions which, when not in use, do not affect runtime costs.
D language
D is a general purpose systems and applications programming language. It is a higher level language than C++, but retains the ability to write high performance code and interface directly with the operating system API's and with hardware. D is well suited to writing medium to large scale million line programs with teams of developers. D is easy to learn, provides many capabilities to aid the programmer, and is well suited to aggressive compiler optimization technology.
The general look of D is like C and C++. This makes it easier to learn and port code to D. Transitioning from C/C++ to D should feel natural. The programmer will not have to learn an entirely new way of doing things.
D drops C source code compatibility. Extensions to C that maintain source compatibility have already been done (C++ and ObjectiveC). Further work in this area is hampered by so much legacy code it is unlikely that significant improvements can be made.
I'm tempted to downvote this question (but as of yet I have not). Your requirement that "you don't pay for what you don't use" depends very heavily on what exactly you use. You already mentioned in one of your comments that assembly is perhaps the most fluff-free language there is, but you complain about C, which sits somewhere between assembly and C++.
If you find garbage collection and explicit object-oriented features "fluff" then frankly, I think C is probably the best candidate. The language is actually small and elegantly designed. It meets most people's "fits in one's head" requirement. For a language that gives such close control over the hardware, it's very expressive.
If you are not tied to the hardware, then Scheme or some other minimalist dialect of Lisp probably fits the bill for "doesn't impose what you don't want on your code" but again, it all depends so heavily on what exactly it is that you don't want.
If there are some higher-level features you "can't live without" (which it seems you are implying by naming "C++ without C compatibility" as your language of choice) then you should say explicitly what those are. What exactly is C++ bringing to the table that you don't want to sacrifice?
Ada is another alternative - gc is optional in the implementation of the language:
http://en.wikipedia.org/wiki/Ada_(programming_language)
You can also try Ch from : http://www.softintegration.com/
SPECS is alternative syntactic binding for C++. This binding includes a simple syntax for declaring and defining types, functions, objects and templates, and changes several problematic operators and control structures. The resulting syntax is LALR(1) parsable.
Eiffel. Looks like Pascal, has C++ type semantics. Also, adds special "programming by contract" assertions that are built into the language definigion, years before people were talking about "X"Unit libraries.
Try Aikido. Syntactically similar to C++, and I don't think it inherits C style backward compatibility.
Aikido # Wikipedia
I'm not exactly sure what costs backward compatibility with C has...
I'm not exactly sure there are any runtime hits associated with C backwards compatibility, could you elaborate? Certainly the backwards compatibility does give you more rope to hang yourself with but strict enforcement of rules can mitigate that. So I suppose my answer to you is C++ is the language that does what you ask for and you just need a tool to enforce valid constructs.
Edit: odd that i didn't notice the post directly below me with the same first line comment