They both prove the socialist model does work for information based technologies such as source code,math, music, things like that
Linux works, because participation is voluntary.
It's not at all clear that napster works. I mean, the company is dead, and they came under a lot of fire, because they were basically grabbing the
work of artists-- participation was not voluntary, and a lot of contributors were unhappy because of this.
Socialism does not work unless the participants
are volunteers (and in that case, it really is
not that much like socialist governments)
In my opinion, if copyright goes it will be because it is unworkable economically (ie, unenforceable)
It will not go away because of this. It has been around
for a long time, and it is not substantially easier
today to violate copyright than it was 10 years ago.
Instead, former IP shops will become service firms, charging for the creation rather than the duplication of ideas.
Right, and there would be a general move towards secrecy, NDAs and contracts as protection. If trust doesn't work (the main weakness of copyright
is that users are for the most part trusted to comply), you're likely to see tougher measures --
more reluctance to release the work (because without
copyright, it's not really in your interests to
release anything)
These
companies aren't going to just roll over and
contribute to the public domain for free.
But putting people into jail for sending emails to lists of people seems as wrong as putting someone in jail for port scanning or other things where there are likely to be legitimate actions that will be outlawed.
What if they use a forged email address, and the mail is not tagged with anything that is easy to filter (like adv) ?
The real difference between portscanning and sending spam is that portscanning does not waste
my time or money. Spamming does. Personally, I think each spammer deserves a black eye from me, for having the arrogance to intrude on my personal email facilities. OTOH, someone who scans my network doesn't annoy me as long as they don't attack one of my machines.
I would assume that fraud laws apply to fraud. Just because it is the internet does not mean that such laws are suspended.
Assume all you like, but that's not going to make it true. Don't blow smoke, and don't speculate. The
problem with your assumption is that it's certainly
not true in general. You can tell lies, and cheat
at golf, without being sued. Not all acts of
dishonesty are covered by fraud legislation.
I think you just insinuated that the source of all messages sent should be verifiable by court order.
No. He believes that having an email address doesn't give every spammer the right to use it
as their advertising space.
So you would make Freenet illegal, since it exists to strongly protect the anonymity of the creaters and users of information even against a court order?
There are some forms of electronic communication
where anonymity is appropriate, and some where it
isn't. I don't know a whole lot about freenet.
In the case of usenet, I'd certainly say anonymity is appropriate, but then, usenet is not
my personal mailbox.
EMail was created without strong authentication. If you want it, then make another protocol that clearly supplies it and let people who value that use it.
There are disadvantages of having strong authentication, mostly that it's inconvenient.
Whining that the current wide-open email system is abused is about as useful as whining about your web page getting unexpectedly slashdotted.
I don't want to whine about it. I'd rather sue the bastards into oblivion, and then let them do the whining, while I laugh all the way to the bank.
If some day copyright goes away, then we'll be in a different boat. But then there won't be as much of a need for licenses like the GPL, because the culture will be so different.
If copyright goes, we will see a move towards secrecy, technical measures, click-through/other contractual models. Reading these posts, copyright
is actually the most benevolent of the available
alternatives. If copyright goes away, there will certainly be a "change of culture", but it will not be one that furthers the interests of free software.
I can make changes and have them online in 3 minutes tested and all! Now try that with your favourite compiled language;-)
Easy to do with good design. Use dynamically loaded
modules. Decouple interface from implementation by using "handle" classes. Use interpreted languages to write "outer
layers" of your application, etc. Minor changes in implementation do not require big recompiles. Changes in important interfaces do (but then, they usually also require code updates.)
40MB of perl, huh ? Just thinking about that makes my head hurt. Perl was the first language I learned, but I'm glad to have left it behind.
Implementations are NOT good. Take the top compilers used today, (Intel's, MS VC++, GCC, Borland) and see how many programs compile on all of them!
A lot of programs compile on all of them. Pick a random C++ textbook, and nearly all the code in that book will compile on all major compilers.
I'm not sure what your complaint is.
Of course, there are extensions, and one vendors
extensions will not be the same as another vendors,
but this doesn't mean that the standard "is a failure". Actually, it's just a reflection of the
fact that in C++, there is a clear distinction between "language" and "platform", while in Java
there is not. This is a design tradeoff that java makes, not a free lunch.
In the example that you site as a good place for native GUI's is the most ignorant arguement I've seen on slashdot to date. Not even Java promised that you wouldn't have to rewrite the GUI for PDA's. (Don't quote hype, find a trusted source where SUN claimed you could run the same code on a PDA) The GUI's are fundamentally different in that case. The look AND the feel of the program should be customizable by the user. That is the promise of Java's LNF.
Try to understand my argument before launching into name-calling. I know Sun didn't promise that you could use the same GUI code for PDAs and desktops. But different platforms do have different looks and feels Claims that these "should" be customisable by the user are contentious at best. I'm not going to get drawn into this argument, but it's certainly not as obvious as you make it sound.
excuse me but I think the fact that they have a financial statement is enough proof that they are a for profit entity.
Not at all. You can have financial statements without being for profit. Financial statements
imply revenue and operating costs, but not profit.
ANSI is nonprofit, the only real spec they are known for is the one that causes my ls to be colorful:)
They are also known for C and C++ (-;
Besides, if the ANSI standard was so hard to implement, one could argue that the tools used to implement it where inferior. Just think about that one for a moment
Seriously, the spec is hard to implement because of its complexity. There are a lot of good tools available (including java, which apparently didn't prove to be useful to any known implementor)
This loss of control as you would call it is what ensures that my program will run on ANY Java runtime environment.
No it doesn't. The JVM spec is what provides this assurance.
Submitting
java to a non-partisan standards body would not
hurt this goal.
If SUN wasn't in control, C# would have been J++ and not a single thing SUN or the JCP would have done could have mattered.
Do you think it is better that we have C# as opposed to J++ ?
You just can't call it certified until it passes the tests. I only wished C/C++ was like that. That alone would be enough that I would still be using it. There's the difference that SUN sees between ISO/ANSI and the JCP.
Regarding C, all recent compilers should be able to compile conforming ANSI 1990 C code. Portability issues have to do with platform specific code (eg implementation defined extensions), not the language itself. Regarding C++, the main issue here is that it has taken a long time to implement the standard. A certification process would not have resulted in vendors implementing the standard any faster.
Not that GC should be forced, but it should at least be an option!
gc is an option, because there are gc implementations
for C++. It's not in the standard, but the standard doesn't say that you can't use gc.
Just because there is an ISO/ANSI standard for C/C++ doesn't mean that people follow it, yet they still call it C or C++.
There's no rule saying that you have to follow
the standard, but there are standards compliance test suites, and in practice, implementations are
good enough that you can usually code to the standard and expect your code to work.
Honestly, do you think that GCC is perfectly ANSI compliant? I don't see how since v3 caused everyone to fix some of their non-ANSI code.
gcc had substantial standards compliance issues prior to the
release of gcc 3.0.
There's as much of an ANSI standard for C/C++ as there is for SQL. It's very difficult to write SQL or C/C++ code that works on multiple compilers in the way you intend. ISO/ANSI has been a complete failure in ensuring that the standard is followed.
Sorry, completely and utterly false. The standard has been succesful, and because of it, there are a number of compiler vendors who are rapidly converging to conforming implementations. It's taken some time for vendors to implement the C++ standard, because it is a very complex standard that is difficult to implement correctly. But to dismiss it as a "failure" on the grounds that it took a while to implement is dishonest or stupid.
I think that even for the user's sake there needs to be some consistancy between GUI's. Native GUI's are a terrible thing in most cases. Just because it looks like the host operating system doesn't make it a good thing. Really, the most successful programs are skinnable and look nothing like the host OS.
False, false and false. Native GUIs are good, because platforms need a consistent interface, and what's appropriate on one platform may not be appropriate on another (eg PDA vs PC). Consistent look is not the issue, consistent feel is. Most succesful programs are not skinnable (but even then, that's a change of look and not feel.
Don't be so afraid of Java. ISO/ANSI are independant companies for profit themselves.
No, they aren't "companies".
I fail to see the difference between them and the JCP.
Apparently Sun does see a substantial difference,
because it was not willing to accept the loss
of control that would have resulted from turning
Java over to a non-partisan standards organisation.
Java is a great technology, but that doesn't excuse your ignorance about ANSI/ISO.
Could it be that there is something wrong with the languages which we use? You know darn well that there's something wrong! I invite you to explore the dark side of C/C++ in this timely paper [virginia.edu] by Mark Sakkinen.
Timely ? It may have been at the time of writing. It's out of date now, and a lot of the complaints it raises have been addressed by the addition of templates, STL, etc. C compatibility features that
the author complains about are
still included in the language, but they are primarily there to support legacy code-- for example, there's no reason to use arrays in new
code.
I'm not sure what you consider to be "the underlying problem". There is no programming language that provides the guarantee that programmers will write bug-free code.
Where is this "better" technology that is "inherently safer" that you speak of ? If it really is "better", why isn't everyone using it ?
Somehow, though, practice doesn't seem to have quite caught up with reality. If we took this maxim really seriously throughout software development, the percentage of application written in higher-level languages like Perl, TCL, Python, Java, and Lisp that ease the programmer's burden by doing their own memory management would be rising fast.
Many of these high level languages have problems of their own. Languages like Python, Perl, and TCL
lack any sort of compile time checking, which makes them error prone, and less scalable. This is
why you don't see many applications that are millions
of lines long developed in these languages.
Simply put, memory management is not the only
issue that programmers deal with maintainability is very important, and
robust compile time checks, and the clarity that
comes from having to explicitly declare interfaces
and having the compiler check types is a maintenance benefit.
And indeed this is happening within the Unix world, though outside it most applications shops still seem stuck with the archaic Unix strategy of coding in C (or C++).
Another fallacy -- that C++ is somehow "equivalent" to C. C++ does not make memory management as simple as java, but it is certainly
simpler than C, and arguably, for nontrivial applications, it is at least as good as languages that force a reference counted system on the user (python, perl) as reference counting is often
not an appropriate memory management model.
Re:Not convinced at all
on
Think Python
·
· Score: 1
I guess we would need to know the definition of "freestanding" in this context.
My understanding is that most implementations are
intended to be "hosted" (as opposed to "free standing"). See 17.4.1.3 and 1.4. A freestanding implementation does not have to ship STL. My understanding is that the main purpose of
this is to allow smaller implementations that are
suitable for embedded systems programming, or other
environments that have special requirements.
However, the weak typing (very late binding) would be a problem in this case. Beginners will have enough trouble understanding the language without the need to handle implicit types. I'd very much suggest a strongly typed object-oriented language such as C++, Java, or Eiffel, where the types are always explicit.
I disagree with this. Strong typing is not at all intuitive, and beginners expect to be able to
do things like store different types of items
in a list (you should see how often that question comes up on comp.lang.c++ !)
Implicit types behave in a way that naive users
expect. It is much easier to understand polymorphism in a dynamically typed language than
it is to understand how polymorphism works in a statically typed language.
I'd recommend Python as a beginners language, but
of course everyone should move on and learn more
languages.
Re:Not convinced at all
on
Think Python
·
· Score: 1
haven't used Python, so I'm a little cautious about talking about it, but I'm fairly confident saying they're are a lot more C and C++ libraries available to a C++ programmer than off the shelf Python packages.
First, the author is talking rubbish. Python is a
good teaching language, but C++ and java are also
great technologies, and I think it speaks ill of the author that he doesn't appear to understand the advantages of compiled languages. So I'd think twice about using his book.
However,
Python is a great teaching language, because it is
simple, and it doesn't get in the way of the programmer. You can just type code and get feedback immediately. Or edit a module, reload it, and try it out.
Compile time type checking, and high performance are useful for developing huge applications, but
for the beginner who just wants to become familiar with simple programming concepts, the compile cycle is just a nuisance.
Re:Not convinced at all
on
Think Python
·
· Score: 2
Much of the preface by Jeff Elkner basically compared C++ to Python and has a go at the deficiencies of C++.
...
Python is a great language, but it is just plain ignorant to sell it as a C++ replacement. It makes
substantially different design tradeoffs, which makes it suitable for very different programming
problems. C++ has better compile time checking,
and better performance, while python has more runtime flexibility.
Actually, Python and C++ work very well
together, I see them as collaborators more than competitors.
For a good introduction to Python, I'd recommend Mark Lutz's Learning Python
Re:Not convinced at all
on
Think Python
·
· Score: 3, Insightful
But think that your comment about main() might indicate a lack of understanding on your part, not on Elkners.
I don't think that the ANSI C specification defines a return type for main() (I did a quick grep of the spec to check).
The C++ spec certainly specifies that the return
type of main() is int. It's covered in 3.6.1 of the C++ standard. (I'm pretty sure the same is true for C).
Also, in practice, different implementations require different return types.
They're not conforming implementations if they require that main() doesn't return int.
Re:Python is a GREAT language, but. . .
on
Think Python
·
· Score: 2
1. I have yet to find a solid dev environment that includes a great debugger.
I've found Ipython to be very useful. It's not a complete development environment, but it works quite well. It's not the same as a debugger-- it has some relative advantages and disadvantages.
A point in its favor is that Python always issues backtraces automatically, which is the most essential function of a debugger.
Its a pain to move blocks around and anyone who doesn't use an editor with auto-indent is screwed
You're pretty screwed without auto-indent anyway (-; Re tabs set to spaces: tabs need to be set to spaces or tabs. As long as they're not set to a mixture of the two, there shouldn't be any problems.
# As has already been mentioning, not too much one can teach about memory management and pointers with python. .
The Python API will give you so much pointers and memory
management that it hurts (-;
As an example, I would much rather have an early homework be a sorting algorithm and then have them reuse this algorithm in other homeworks than let them just type "xxx.sort()".
An alternative philosophy is that it's a good idea
to learn to reuse a well designed library before
rolling ones own poor quality imitation. Python
opens up interesting possibilities by allowing one to pass in predicates: L.sort(lambda x,y: y-x),
etc etc. It's a good thing to expose students to
flexible and well design class libraries, rather
than encouraging them to reinvent the wheel. Then
they can implement their own custom containers.
Now, I have a question. Who is the most reliable publisher of computer books. It seems that O'Reilly is all the craze, but I have been disappointed with their accuracy and editing of late, though I buy their books if they are on discount or the only good text.
The best publisher depends on the subject matter. Addison Wesley have by far the best lineup of C++ books (almost a monopoly on good C++ books), while
Prentice Hall have most of the good C books. O'Reilly have most of the good UNIX-centric books: Python, Perl, and general UNIX stuff,
Addison Wesley are probably the most consistent of publishers, and have one of the highest signal to noise ratios. They published at least one of the Stevens titles (Advanced Programming in the UNIX environment)
You're absolutely right. I should be ashamed for wanting a stable ABI.
There's no shame in wanting a stable ABI. What is truly shameful is your ignorant ranting. Everyone wants a stable ABI, but there are bugs that need to be fixed for the ABI to stabilise, and in the interim states (where there are outstanding bugs or non-implemented parts of the standard), you have a choice between stagnation and breaking compatibility from time to time.
So your complaint really boils down to the fact that you don't feel the gcc project has moved fast enough, but the simple fact of the matter is that it is doing quite well compared to competing compilers in terms of support for ANSI/ISO C++.
Thanks for the explanation. So, I assume that once they "get it right", they won't change the ABI anymore, or not often anyway.
That's correct. Once they have it right, they can freeze the ABI, and they're hoping that 3.2 will be the release where they get it right. They may have to change the standard library, but the changes will not probably not affect binary comptibility (because the streams library is stable, and the other part of the standard library, STL, is a source-only library)
In versions up to the present for the past few years they have compiled with gcc 2.96.x which if you read the docs on the gnu gcc [gnu.org] web site specifically stated that it was developement and SHOULD NOT BE USED FOR PRODUCTION
Most criticisms of Redhats compiler release are without substance, and this is no exception.
Redhats gcc 2.96 release was not a straight grab out
of the CVS repository, it was Redhats fork of gcc. They added patches, and got it working properly.
Redhat were right to fork. The release issued by the gcc project could not compile glibc on all target architectures. The gcc 3.0 release was late, and when there was a release, it was too broken to use for a distribution. The gcc project are certainly within their rights releasing something that meets the testing/release requirements they set, but what's good enough for the gcc project is not good enough for a Linux distributor. The linux distributor needs to be able to compile glibc on all architectures, and needs to compile KDE correctly.
Hence not using those distributions "because of the compiler" is just plain ignorant. gcc 2.96 was the best free compiler available until the release of gcc 3.1., which has now taken the title.
The main reason gcc 3.1 is incompatible with older releases is because the old releases have bugs that are fixed in gcc 3.1. The incompatibilities are caused by the improved ABI, and a more compliant standard library.
Shipping two versions of glibc doesn't really solve any problems-- you just end up with parallel sets of libraries (bloat).
Fortuantely, you need neither two compilers nor two glibc versions. Only C++ libraries are a problem. You need different versions of libstdc++. This is not a new problem. Most distributions already ship several different libstdc++ versions.
The GCC team made the decision to finalize the C++ standard in a *stable* branch. This was a bad decision. They should be creating a standards compliant compiler and library in an unstable branch.
??? There is a "stable" branch with a fixed ABI, there are lots of them. 3.0.4 is the latest maintenance release of 3.0. And gcc 3.1 will have 3.1.1 as a maintenance release.
If they did stagnate and not implement any changes that would break the ABI (which would have amounted to keeping a very broken standard library), others would have forked (Redhat forked anyway, with distributors using the forked version because they didn't release a new compiler
quickly enough for Redhat)
Changing the ABI between minor versions is a bad thing.
What do you call a "minor version" ? Look at the duration between the point releases. They are "minor" only in the sense that the second most significant digit has changed.
Once the ISO Standard for C++ was released a few years ago, the g++ ABI should have been finalized and set in stone.
They could indeed have done so, but they wouldn't have been able to test the new ABI until they had a release that implemented it, would they ? Anyone can mouth off about how they "should" have set the ABI in stone instantaneously, but when it comes to actually implementing it, and then fixing the bugs -- how many patches did you submit ?
I'm still waiting for the day when the GCC crew gets a clue. Proper prior planning prevents perennial problems. There's absolutely no reason for this incompatibility.
In the real world, you inevitablty discover bugs after the release. The incompatibilities were inevitable-- the standard library implementation has been severely broken in all releases prior to 3.0 (for example, std:: not working properly,
the class heirarchy itself is not as described in the standard, and there are important classes missing) So prior to gcc 3.0, the reasons
for the incompatibilities, is that they were still in the process of implementing a (close to) conforming compiler. Post gcc 3.0, they're ironing out the bugs.
Compared to other C++ implementations, gcc is actually doing pretty well with regards to standards compliance. There are some popular compilers that still don't have partial template specialisation working.
If you followed the gcc mailing lists, you'd realise that these guys aren't clowns. The gcc project use automated tests, and careful bug tracking. To the extent that they've made mistakes (for example, inadequate checking of their C++ compiler), they've tried to learn from them.
It's a large project, and arguably one of the better managed ones around.
Slashdot Mirror
Linux works, because participation is voluntary.
It's not at all clear that napster works. I mean, the company is dead, and they came under a lot of fire, because they were basically grabbing the work of artists-- participation was not voluntary, and a lot of contributors were unhappy because of this.
Socialism does not work unless the participants are volunteers (and in that case, it really is not that much like socialist governments)
It will not go away because of this. It has been around for a long time, and it is not substantially easier today to violate copyright than it was 10 years ago.
Instead, former IP shops will become service firms, charging for the creation rather than the duplication of ideas.
Right, and there would be a general move towards secrecy, NDAs and contracts as protection. If trust doesn't work (the main weakness of copyright is that users are for the most part trusted to comply), you're likely to see tougher measures -- more reluctance to release the work (because without copyright, it's not really in your interests to release anything) These companies aren't going to just roll over and contribute to the public domain for free.
No, I wouldn't. My webpage is intended for access by the general public. My email is not. It is a personal communication facility.
What if they use a forged email address, and the mail is not tagged with anything that is easy to filter (like adv) ?
The real difference between portscanning and sending spam is that portscanning does not waste my time or money. Spamming does. Personally, I think each spammer deserves a black eye from me, for having the arrogance to intrude on my personal email facilities. OTOH, someone who scans my network doesn't annoy me as long as they don't attack one of my machines.
Assume all you like, but that's not going to make it true. Don't blow smoke, and don't speculate. The problem with your assumption is that it's certainly not true in general. You can tell lies, and cheat at golf, without being sued. Not all acts of dishonesty are covered by fraud legislation.
I think you just insinuated that the source of all messages sent should be verifiable by court order.
No. He believes that having an email address doesn't give every spammer the right to use it as their advertising space.
So you would make Freenet illegal, since it exists to strongly protect the anonymity of the creaters and users of information even against a court order?
There are some forms of electronic communication where anonymity is appropriate, and some where it isn't. I don't know a whole lot about freenet. In the case of usenet, I'd certainly say anonymity is appropriate, but then, usenet is not my personal mailbox.
EMail was created without strong authentication. If you want it, then make another protocol that clearly supplies it and let people who value that use it.
There are disadvantages of having strong authentication, mostly that it's inconvenient.
Whining that the current wide-open email system is abused is about as useful as whining about your web page getting unexpectedly slashdotted.
I don't want to whine about it. I'd rather sue the bastards into oblivion, and then let them do the whining, while I laugh all the way to the bank.
If copyright goes, we will see a move towards secrecy, technical measures, click-through/other contractual models. Reading these posts, copyright is actually the most benevolent of the available alternatives. If copyright goes away, there will certainly be a "change of culture", but it will not be one that furthers the interests of free software.
Easy to do with good design. Use dynamically loaded modules. Decouple interface from implementation by using "handle" classes. Use interpreted languages to write "outer layers" of your application, etc. Minor changes in implementation do not require big recompiles. Changes in important interfaces do (but then, they usually also require code updates.)
40MB of perl, huh ? Just thinking about that makes my head hurt. Perl was the first language I learned, but I'm glad to have left it behind.
A lot of programs compile on all of them. Pick a random C++ textbook, and nearly all the code in that book will compile on all major compilers. I'm not sure what your complaint is.
Of course, there are extensions, and one vendors extensions will not be the same as another vendors, but this doesn't mean that the standard "is a failure". Actually, it's just a reflection of the fact that in C++, there is a clear distinction between "language" and "platform", while in Java there is not. This is a design tradeoff that java makes, not a free lunch.
In the example that you site as a good place for native GUI's is the most ignorant arguement I've seen on slashdot to date. Not even Java promised that you wouldn't have to rewrite the GUI for PDA's. (Don't quote hype, find a trusted source where SUN claimed you could run the same code on a PDA) The GUI's are fundamentally different in that case. The look AND the feel of the program should be customizable by the user. That is the promise of Java's LNF.
Try to understand my argument before launching into name-calling. I know Sun didn't promise that you could use the same GUI code for PDAs and desktops. But different platforms do have different looks and feels Claims that these "should" be customisable by the user are contentious at best. I'm not going to get drawn into this argument, but it's certainly not as obvious as you make it sound.
excuse me but I think the fact that they have a financial statement is enough proof that they are a for profit entity.
Not at all. You can have financial statements without being for profit. Financial statements imply revenue and operating costs, but not profit.
ANSI is nonprofit, the only real spec they are known for is the one that causes my ls to be colorful :)
They are also known for C and C++ (-;
Besides, if the ANSI standard was so hard to implement, one could argue that the tools used to implement it where inferior. Just think about that one for a moment
Seriously, the spec is hard to implement because of its complexity. There are a lot of good tools available (including java, which apparently didn't prove to be useful to any known implementor)
This loss of control as you would call it is what ensures that my program will run on ANY Java runtime environment.
No it doesn't. The JVM spec is what provides this assurance. Submitting java to a non-partisan standards body would not hurt this goal.
If SUN wasn't in control, C# would have been J++ and not a single thing SUN or the JCP would have done could have mattered.
Do you think it is better that we have C# as opposed to J++ ?
You just can't call it certified until it passes the tests. I only wished C/C++ was like that. That alone would be enough that I would still be using it. There's the difference that SUN sees between ISO/ANSI and the JCP.
Regarding C, all recent compilers should be able to compile conforming ANSI 1990 C code. Portability issues have to do with platform specific code (eg implementation defined extensions), not the language itself. Regarding C++, the main issue here is that it has taken a long time to implement the standard. A certification process would not have resulted in vendors implementing the standard any faster.
gc is an option, because there are gc implementations for C++. It's not in the standard, but the standard doesn't say that you can't use gc.
Just because there is an ISO/ANSI standard for C/C++ doesn't mean that people follow it, yet they still call it C or C++.
There's no rule saying that you have to follow the standard, but there are standards compliance test suites, and in practice, implementations are good enough that you can usually code to the standard and expect your code to work.
Honestly, do you think that GCC is perfectly ANSI compliant? I don't see how since v3 caused everyone to fix some of their non-ANSI code.
gcc had substantial standards compliance issues prior to the release of gcc 3.0.
There's as much of an ANSI standard for C/C++ as there is for SQL. It's very difficult to write SQL or C/C++ code that works on multiple compilers in the way you intend. ISO/ANSI has been a complete failure in ensuring that the standard is followed.
Sorry, completely and utterly false. The standard has been succesful, and because of it, there are a number of compiler vendors who are rapidly converging to conforming implementations. It's taken some time for vendors to implement the C++ standard, because it is a very complex standard that is difficult to implement correctly. But to dismiss it as a "failure" on the grounds that it took a while to implement is dishonest or stupid.
I think that even for the user's sake there needs to be some consistancy between GUI's. Native GUI's are a terrible thing in most cases. Just because it looks like the host operating system doesn't make it a good thing. Really, the most successful programs are skinnable and look nothing like the host OS.
False, false and false. Native GUIs are good, because platforms need a consistent interface, and what's appropriate on one platform may not be appropriate on another (eg PDA vs PC). Consistent look is not the issue, consistent feel is. Most succesful programs are not skinnable (but even then, that's a change of look and not feel.
Don't be so afraid of Java. ISO/ANSI are independant companies for profit themselves.
No, they aren't "companies".
I fail to see the difference between them and the JCP.
Apparently Sun does see a substantial difference, because it was not willing to accept the loss of control that would have resulted from turning Java over to a non-partisan standards organisation.
Java is a great technology, but that doesn't excuse your ignorance about ANSI/ISO.
Timely ? It may have been at the time of writing. It's out of date now, and a lot of the complaints it raises have been addressed by the addition of templates, STL, etc. C compatibility features that the author complains about are still included in the language, but they are primarily there to support legacy code-- for example, there's no reason to use arrays in new code.
I'm not sure what you consider to be "the underlying problem". There is no programming language that provides the guarantee that programmers will write bug-free code. Where is this "better" technology that is "inherently safer" that you speak of ? If it really is "better", why isn't everyone using it ?
Many of these high level languages have problems of their own. Languages like Python, Perl, and TCL lack any sort of compile time checking, which makes them error prone, and less scalable. This is why you don't see many applications that are millions of lines long developed in these languages. Simply put, memory management is not the only issue that programmers deal with maintainability is very important, and robust compile time checks, and the clarity that comes from having to explicitly declare interfaces and having the compiler check types is a maintenance benefit.
And indeed this is happening within the Unix world, though outside it most applications shops still seem stuck with the archaic Unix strategy of coding in C (or C++).
Another fallacy -- that C++ is somehow "equivalent" to C. C++ does not make memory management as simple as java, but it is certainly simpler than C, and arguably, for nontrivial applications, it is at least as good as languages that force a reference counted system on the user (python, perl) as reference counting is often not an appropriate memory management model.
My understanding is that most implementations are intended to be "hosted" (as opposed to "free standing"). See 17.4.1.3 and 1.4. A freestanding implementation does not have to ship STL. My understanding is that the main purpose of this is to allow smaller implementations that are suitable for embedded systems programming, or other environments that have special requirements.
I disagree with this. Strong typing is not at all intuitive, and beginners expect to be able to do things like store different types of items in a list (you should see how often that question comes up on comp.lang.c++ !)
Implicit types behave in a way that naive users expect. It is much easier to understand polymorphism in a dynamically typed language than it is to understand how polymorphism works in a statically typed language.
I'd recommend Python as a beginners language, but of course everyone should move on and learn more languages.
First, the author is talking rubbish. Python is a good teaching language, but C++ and java are also great technologies, and I think it speaks ill of the author that he doesn't appear to understand the advantages of compiled languages. So I'd think twice about using his book.
However, Python is a great teaching language, because it is simple, and it doesn't get in the way of the programmer. You can just type code and get feedback immediately. Or edit a module, reload it, and try it out.
Compile time type checking, and high performance are useful for developing huge applications, but for the beginner who just wants to become familiar with simple programming concepts, the compile cycle is just a nuisance.
Python is a great language, but it is just plain ignorant to sell it as a C++ replacement. It makes substantially different design tradeoffs, which makes it suitable for very different programming problems. C++ has better compile time checking, and better performance, while python has more runtime flexibility.
Actually, Python and C++ work very well together, I see them as collaborators more than competitors.
For a good introduction to Python, I'd recommend Mark Lutz's Learning Python
The C++ spec certainly specifies that the return type of main() is int. It's covered in 3.6.1 of the C++ standard. (I'm pretty sure the same is true for C).
Also, in practice, different implementations require different return types.
They're not conforming implementations if they require that main() doesn't return int.
I've found Ipython to be very useful. It's not a complete development environment, but it works quite well. It's not the same as a debugger-- it has some relative advantages and disadvantages. A point in its favor is that Python always issues backtraces automatically, which is the most essential function of a debugger.
Its a pain to move blocks around and anyone who doesn't use an editor with auto-indent is screwed
You're pretty screwed without auto-indent anyway (-; Re tabs set to spaces: tabs need to be set to spaces or tabs. As long as they're not set to a mixture of the two, there shouldn't be any problems.
# As has already been mentioning, not too much one can teach about memory management and pointers with python. .
The Python API will give you so much pointers and memory management that it hurts (-;
As an example, I would much rather have an early homework be a sorting algorithm and then have them reuse this algorithm in other homeworks than let them just type "xxx.sort()".
An alternative philosophy is that it's a good idea to learn to reuse a well designed library before rolling ones own poor quality imitation. Python opens up interesting possibilities by allowing one to pass in predicates: L.sort(lambda x,y: y-x), etc etc. It's a good thing to expose students to flexible and well design class libraries, rather than encouraging them to reinvent the wheel. Then they can implement their own custom containers.
The best publisher depends on the subject matter. Addison Wesley have by far the best lineup of C++ books (almost a monopoly on good C++ books), while Prentice Hall have most of the good C books. O'Reilly have most of the good UNIX-centric books: Python, Perl, and general UNIX stuff,
Addison Wesley are probably the most consistent of publishers, and have one of the highest signal to noise ratios. They published at least one of the Stevens titles (Advanced Programming in the UNIX environment)
There's no shame in wanting a stable ABI. What is truly shameful is your ignorant ranting. Everyone wants a stable ABI, but there are bugs that need to be fixed for the ABI to stabilise, and in the interim states (where there are outstanding bugs or non-implemented parts of the standard), you have a choice between stagnation and breaking compatibility from time to time.
So your complaint really boils down to the fact that you don't feel the gcc project has moved fast enough, but the simple fact of the matter is that it is doing quite well compared to competing compilers in terms of support for ANSI/ISO C++.
That's correct. Once they have it right, they can freeze the ABI, and they're hoping that 3.2 will be the release where they get it right. They may have to change the standard library, but the changes will not probably not affect binary comptibility (because the streams library is stable, and the other part of the standard library, STL, is a source-only library)
Most criticisms of Redhats compiler release are without substance, and this is no exception.
Shipping two versions of glibc doesn't really solve any problems-- you just end up with parallel sets of libraries (bloat).
Fortuantely, you need neither two compilers nor two glibc versions. Only C++ libraries are a problem. You need different versions of libstdc++. This is not a new problem. Most distributions already ship several different libstdc++ versions.
??? There is a "stable" branch with a fixed ABI, there are lots of them. 3.0.4 is the latest maintenance release of 3.0. And gcc 3.1 will have 3.1.1 as a maintenance release. If they did stagnate and not implement any changes that would break the ABI (which would have amounted to keeping a very broken standard library), others would have forked (Redhat forked anyway, with distributors using the forked version because they didn't release a new compiler quickly enough for Redhat)
Changing the ABI between minor versions is a bad thing.
What do you call a "minor version" ? Look at the duration between the point releases. They are "minor" only in the sense that the second most significant digit has changed.
They could indeed have done so, but they wouldn't have been able to test the new ABI until they had a release that implemented it, would they ? Anyone can mouth off about how they "should" have set the ABI in stone instantaneously, but when it comes to actually implementing it, and then fixing the bugs -- how many patches did you submit ?
In the real world, you inevitablty discover bugs after the release. The incompatibilities were inevitable-- the standard library implementation has been severely broken in all releases prior to 3.0 (for example, std:: not working properly, the class heirarchy itself is not as described in the standard, and there are important classes missing) So prior to gcc 3.0, the reasons for the incompatibilities, is that they were still in the process of implementing a (close to) conforming compiler. Post gcc 3.0, they're ironing out the bugs.
Compared to other C++ implementations, gcc is actually doing pretty well with regards to standards compliance. There are some popular compilers that still don't have partial template specialisation working.
If you followed the gcc mailing lists, you'd realise that these guys aren't clowns. The gcc project use automated tests, and careful bug tracking. To the extent that they've made mistakes (for example, inadequate checking of their C++ compiler), they've tried to learn from them. It's a large project, and arguably one of the better managed ones around.