| |||||||||||||
lambda functionslambda functionsPosted Dec 9, 2005 8:17 UTC (Fri) by ncm (subscriber, #165)In reply to: lambda functions by dvdeug Parent article: The Boost C++ Libraries
We're not discussing scripting languages. You don't use a garden tractor in a mine, however handy it might be in the back yard. A Skil saw is of little value when you're building a jetliner.
FORTRAN, COBOL, and (yes) FORTH are almost as old as LISP. Even in their modernesque forms they implement no concepts more recent than the '70s. You omitted assembly language.
(Log in to post comments)
lambda functions Posted Dec 9, 2005 9:08 UTC (Fri) by khim (subscriber, #9252) [Link] Yes, it's very true that C, FORTRAN, COBOL and even Java/C# do not include a lot of modern ideas. The fact of the matter is: they are used more often by "industry" then C++. C++ has it's place but the only reason it's used at all are few good (and few not-so-good) toolkits: Qt, MFC, ATL, etc. In last 10 years I was involved in many projects and only tiny part was written in C++ - mostly things for Windows (Microsoft only recently switched away from C++). While what you said is true (different languages are suitable for different purposes) it all looks to me like try to define "industrial use" in such a way as to make C++ winner. Let's define "industrial use" as "something done by big boys". What ? They are using scripting laguages. Ok - let's explicitly exclude them. Oops - still no win: huge number of things is done in C or FORTRAN ? Let's say that "ancient laguages" are not of concern. Still C++ is not winner ? Ok - let's ignore VM-based laguages as well. And so on. In the end you'll define some niche where C++ is clear leader - but this can be done for almost any language. Even very obscure langauges.
lambda functions Posted Dec 9, 2005 18:43 UTC (Fri) by ncm (subscriber, #165) [Link] C++ is not a niche language. Webpage support is not, as a rule, an industrial use (although web interfaces occasionally appear in industrial settings). GUI coding, likewise, is not an industrial use.
Any language suffices for easy problems. Hard problems demand range. If you confine yourself to easy problems, you won't notice the built-in limits of your language. When you do need the range, minor inconveniences are easy to overlook.
Of course most problems are easy, and most people spend their time solving easy problems. It's generally not hard to ignore the hard problems, and the people working on them.
lambda functions Posted Dec 9, 2005 21:25 UTC (Fri) by dvdeug (subscriber, #10998) [Link] Writing an application as quickly as possible is not an easy job, yet it's one that Visual Basic makes easy. Solving complex problems of logical inference is not an easy job, but it's one that PROLOG and similar logical languages make easy. Writing an expandable editor like EMACS is not easy, but it's one that LISP makes easier. Writing a webpage generator isn't that hard, but it's a lot easier in Perl than C++.
C++ has less range than Common Lisp. If you demand that all core language features "map to a machine instruction or two", what more can you expect?
It's seriously absurd to dismiss all problems besides "industrial" problems as easy. There's no challenge to writing a paycheck generator. There's challenge to writing code to control a 757 (code written in Ada, BTW), but it's not in the range; it's in getting things done, always exactly correct, on a very tight time schedule.
A game is not a trivial thing; it's funny that many game programmers either refuse to use C++ for speed reasons, or use scripting languages to control much of the game's actions. Obviously, C++ doesn't provide the right range for them.
C++ Game development Posted Dec 10, 2005 6:03 UTC (Sat) by mvogt (guest, #34379) [Link] I disagree with your assertion that C++ is not used for games for performance reasons. I think commercial games are very often written in C++.
If you look at sourceforge, two categories I sampled as having high-performance requirements (simulations and first-person shooters) have more than half of their listed projects listed with C++ as a development language.
C++ can be used with almost no abstraction penalty over C, depending on what features you choose to employ. There is a good document establishing the efficiency costs of various C++ features available at http://www.research.att.com/~bs/Performance-TR.pdf
I agree that many games have a component written in scripting languages; I think that this is probably a reflection of the rapid time-to-market pressure in the game market as much as anything else.
C++ Game development Posted Dec 10, 2005 7:32 UTC (Sat) by dvdeug (subscriber, #10998) [Link] But rapid time-to-market is something that makes a problem hard, and there's no reason to dismiss languages that are ideal for solving such hard problems as unworthy of study.
C++ Game development Posted Dec 10, 2005 8:22 UTC (Sat) by mvogt (guest, #34379) [Link] Of course such languages should not be dismissed, but nor should they be espoused for tasks they're not designed for.
Ideally, C++ can be used together with a language designed for embedding (such as Lua) for game development.
That said, games are an unusual domain, where even correctness can be less important than performance or speed-to-market.
C++ Game development Posted Dec 10, 2005 8:53 UTC (Sat) by dvdeug (subscriber, #10998) [Link] Since when is correctness taking second place to performance and speed-to-market unusual? C++ itself puts correctness second to performance in relegating bounded arrays to the library. If you put correctness first, you would use the SPARK programming language, or something similar, and never release unless every possible test has been passed. But in reality, virtually every program releases with known bugs, frequently major ones. Jon Bentley mentions in one of the Programming Pearls books that given a 10x speed improvement on his typesetting system or all the bugs fixed, that he would have taken the speed up. If you (believably) made the offer on the GCC list, I suspect the list would blow up in a flame war over the issue.
C++ Game development Posted Dec 10, 2005 22:05 UTC (Sat) by mvogt (guest, #34379) [Link] Fair enough, there are obviously application domains where approximations are acceptable, and those where they are not. What would be the point of a 'grep' that returned most matches, or a 'find' with false positives?
C++ does not put correctness second to performance, it ensures that you needn't pay for what you don't use. (Ignoring legacy C built-in arrays,) if you can guarantee array bounds will not be violated you can use the subscript operator for unchecked access; you can use the 'at' member function to get runtime checking where desirable. 'Relegating... to the library' has been the favoured C++ evolution strategy, for right or wrong. It doesn't indicate that something is less correct or important.
I will admit that C++ puts guranateed correctness second to pragmatism. Languages that don't have not been conspicuously successful in general purpose programming.
lambda functions Posted Dec 9, 2005 21:07 UTC (Fri) by dvdeug (subscriber, #10998) [Link] So if you redefine industrial use as not to include "scripting" languages and not to include "web" languages and not Visual Basic, and exclude languages much more than 20 years old, then your statement might be true. But how is that an indictment of academia? Why should academia care only about your subset of the real world usage?
Modern Fortran supports object-orientation and exception handling. If modern Fortran supports no concepts more recent than the 70s, I'm curious what features of C++ are more recent than the 70s?
Recent features of programming languages Posted Dec 10, 2005 5:49 UTC (Sat) by mvogt (guest, #34379) [Link] Well, all ideas are old, of course, but the feature that separates C++ from its closest peers (probably Ada, Eiffel, Objective-C) is the support for compile-time metaprogramming.
It's certainly not elegant, and was almost accidental in its design, but it combines very well with C++'s don't-pay-for-what-you-don't-use philosophy, and its ability to adjust its interface through operator overloading.
But, the point that these are all old ideas is valid. Their age probably indicates the amount of time and experience required to get a community of implementors and developers to assimilate a set of ideas.
lambda functions Posted Dec 10, 2005 8:28 UTC (Sat) by ncm (subscriber, #165) [Link] None of those scripting languages, nor "web languages", nor Visual Basic came from academia. For that matter, neither did FORTRAN or COBOL. Most have been reviled by academia, for generally good reasons. The various LISPs, Prologs, Haskell, the MLs, and suchlike have largely failed to escape academia, also for good reasons. Industry briefly flirted with Algol, Pascal, Ada, and their ilk, as well as Smalltalk, and then largely abandoned them, again for good reasons.
C++, in its original conception, supported one important new concept: the destructor. Languages conceived since have failed to adopt it, limiting the effectiveness of their exception handling, and the languages' industrial usefulness. (No, "finalize" doesn't help.)
Later additions, particularly templates in the form standardized by ISO, enabled STL, Boost, and a constellation of matrix- and signal-processing libraries that outperform languages specialized for the purpose. Only CAML has matched C++'s capability to define fast, powerful libraries, but often cannot be used industrially because of its limited support for resource management.
Object orientation has turned out not to be nearly so important as the '90s hype machine suggested. Languages designed to the hypesters' criteria have turned out peculiarly limited.
Why should academia care about industrial usefulness? Arguably, no reason; certainly academic art and literary criticism have precious little to do with actual art or literature. However, an academic who cares to avoid sterility and irrelevance must confront fundamentally hard, large real-world problems. Such problems are, by their nature, not limited to conveniently proscribed domains. Tools to address them must be equally well prepared for bit twiddling, lambda calculus, hard-core numerics, real-time hardware resource management, fancy data structures, and what-have-you. Academic CS department hostility to serious engineering needs leaves its graduates ill-prepared to contribute.
lambda functions Posted Dec 10, 2005 8:46 UTC (Sat) by dvdeug (subscriber, #10998) [Link] Most concepts embedded in C++ were originally developed in academic languages. It's not always about the languages academia developed; it's about how they influenced the languages that everyone uses.
Once again, your definition of industrial usefulness ignores most real-life problems. A huge number of computer people run servers; they may not touch a compiled language for years on end, but write and edit in scripting languages all day long. Or they may maintain websites or write Java games to be played on line, or program off-line games in Python, like Civ 4. Not every real life problem is to be tackled with C++.
lambda functions Posted Dec 10, 2005 10:21 UTC (Sat) by ncm (subscriber, #165) [Link] As I said, most problems are easy. Actually, most hard problems don't involve any coding whatsoever.
You don't learn much from solving the same easy problem over and over, or even from solving lots of easy problems. Hard problems teach deep lessons, if you can bring yourself to pay attention. A problem that was impossible to solve until you invented something new is more precious than any book.
|
|||||||||||||