There's a bunch of portability GUI libraries for C++, notably Qt and WxWindows.
Re:Neither CS nor CIS: MATH
on
CS vs CIS
·
· Score: 1
I'd have to agree with this. I've seen math articles published in CS journals and vice versa.
BTW, I consider the book "Intro to algorithms" by Cormen et al to be a math book. I mean, it's a book of theorems and proofs. There is a fair bit of overlap between what "mathematicians" and "computer scientists" do. Of course, one could argue that all the computer science literature is a sort of mathematics; I don't see substantial differences.
Re:Regrets, I've had a few.
on
CS vs CIS
·
· Score: 1
If you can learn about things like complexity theory and compiler construction on your own - I don't mean
how to use lex and yacc, I mean if you can pick up the Dragon Book and understand it without stepping into
a classroom - then you're a supergenius, and you might as well go to school and get a diploma to increase
your marketability.
A degree in a very theoretical course such as math/physics tends to make the harder CS material a tad easier to absorb, because you get exposed to abstractions (in fact you see things like automata, algorithms and Turing machines, though the way you approach them is quite different)
Re:But that's most engineering curriculums
on
CS vs CIS
·
· Score: 1
I just went after a pure math degree because I was good at it and I enjoyed it. It's certainly "mind expanding", though in a different way to the liberal arts degree.
Re:But that's most engineering curriculums
on
CS vs CIS
·
· Score: 1
Math are all about
solving real-world problems:
Excuse me ? Math is about solving problems, real world or not. The problems I solve have no obvious (and probably no non-obvious) relevance to "real world" problems.
UNIX is nearly 30 years old. C and procedural programming are over 25 years old, object oriented programming is over 30 years old (eg: SIMULA), and algorithms were studied before computers were invented. And none of these things are going to go away any time soon.
Unless you're spending the entire degree memorising MFC, your knowledge will not be obsolete for a long time.
it isn't??
that's odd.
i wonder exactly what it was i've been doing all day, since apparently i wasn't editing postscript...
I meant that it's not editable by mere mortals. It's a perfectly good language, but it's not intended to be hand-coded by document authors. How many people do you know who actually hand-code documents in postscript ?
IIRC there's a version of framemaker that supports SGML. In any case, I agree with the people who say that some SGML/XML DTD should be used. (btw, going with sgml was the smartest thing the LDP did...)
See www.stopspam.org for some advice considerably better than this. As usual, slashdot digs up a poor quality site.
1800 numbers are not always toll free. You could end up making an expensive call. If you want to abuse the 1800 number, do it from a public phone to make sure they're paying and to prevent them from tracing you.
Don't reply directly to spammers. What, you think they actually read their mail ? Most of them use disposable addresses. Certainly, the return address will not be one from which they read email. DO complain to the idiots ISP. See stopspam.org for more ideas (for example, if they claim to have made money with the scheme, report it to the IRS!)
Never respond with a threat. (btw, if you mailbomb to the wrong address, you'll really get burnt)
having said all this, I think spammers should be fined on a per-message basis, or on the basis of the number of complaints against them.
One way or another, CORBA still needs to deal with the basic problem of object serialisation. Which would seem to be close to functionaly equivalent to building a DOM tree.
I guess I meant this more as a matter of relative importance. Without knowing
understanding algorithms, programing methodologies such as OO, procedutal programming, etc. don't do
you a lot of good.
Actually, they'll get you quite a long way. For example, web development doesn't require much knowledge about algorithms. In general, lower level coding requires more knowledge about algorithms. Obviously, to be a good programmer, you need to know algorithms. And you also need to know OO.
I fear that students are to eager and teachers may be too willing to leap right in to "This is
how you write a program in XXX" rather than "These are the kinds of things a computer can do...
The fact that they are using java doesn't imply that the course is going to be about java.
I still think being able to design
and analyze algorithms is more important than OO.
I'd argue that they're both essential. I wouldn't even think of hiring someone who didn't understand OO if I was hiring programmers.
People programmed for years without OO,
but they
didn't program without understanding algorithms.
OO goes back a long way, it's over 30 years old (Simula, for example). So people have known about OO for a long time. For example, it was known about in the days of UNIX, and it seems that the designers of UNIX understood OO concepts (for example, the file IO API).
It might not have enjoyed as much use/popularity back then, but then, yesterdays software was a lot simpler than todays, and programmers needed to think more about efficiency than they did about large scale design. (indeed, a lot of old software reflects the emphasis on efficiency and not design, for example DOS, and Win3.1)
Nowadays, programmers using high level languages don't really need to think that much about efficiency, but all programmers certainly need to understand OO.
In highschool geometry class, we did proofs, we didn't learn how to use the latest straightedges and
protractors.
When you did proofs in high school geometry, you'd spent years before hand grasping the fundamentals and using protractors and straight edges.
I agree with your implicit point though that you didn't use the "latest" ones, and I don't think there's an overwhelming advantage (besides the availability of textbooks) in using java compared to using something older (such as Smalltalk, Eiffel, or LISP for example)
And since I'm fairly certain that nobody will ever read this, let me say that OO is not a magic bullet,
I couldn't agree more. OO is just one of many programming paradigms. There are other paradigms which are also very important, such as procedural programming, modular programming, and generic programming.
and I
don't think it deserves the same fundemental treatment that should be given to algorithms.
Oh, I do. I think OO programming is essential. If you're not using an OO language, then it's even more essential, because the language doesn't impose any OO discipline on you.
The idea that if
only you lay out your data in a OO manner, the algorithms will be readily apparent is utter rubish.
Well that's an obvious straw man. I don't know who'd be so silly to say something this absurd though. This is why C++ embraces generic programming. Bjarne's description of the generic programming paradigm begins with "Decide which algorithms you want", in other words, you choose the algorithms first, and then choose a suitable container. Bjarne doesn't try to pretend that this programming style is a subset of OO (though it seems java sort of does try to ram generic programming into OO. Which I think is a mistake btw and is one of the reasons I prefer C++)
In fact if you look at STL, it is completely about algorithms and not about OO (there are objects, sure. But there is no inheritence. STL is "object based", but not "object oriented").
OO addresses issues orthogonal to algorithm choices. The main point of OO is to express commonality through inheritence, which results in consistent API designs, reusable code and reusable interfaces. The fact that algorithms are essential does not in any way make software design principles any less essential. Both are essential topics.
CS should be about computer science more than computer programming. Students need to be learning
about algorithms, data structures, big-O, proofs of correctness, modularity, and so on -- concepts that will
benefit them in any language they later choose to employ -- rather than get bound up in the syntactical
nuances of any particular language or environment.
I agree with this apart from the fact that some of the topics you mention are a tad advanced for high school students.
I don't think there's an advantage of using obscure languages. It's harder to find compilers and books and the teachers are less likely to know it. BTW, Knuth's "hypothetical machine language" is horrible. It's the only thing I don't like about the book. For a book that uses an interesting "pseudocode" language, see "Object Oriented software construction" (which actually uses Eiffel, but introduces it as an anonymous notational language)
I wouldn't want to be the one grading the papers that were written using "all languages". You've obviously never graded before.
BTW, the fact that they do choose a specific language does not mean that the exam is necessarily a language syntax test. Indeed, one needs a notation to properly describe something like algorithms, polymorphism, etc.
I would take a different approach. I think CS curricula should be able to employ whichever language or
languages the instructor sees fit to teach concepts.
But to some degree, choosing the language is choosing the concepts. For example, by choosing Java, you are making a decision to teach certain things (OO) and not teach other things (memory management).
Languages may go "out of style", but OO will not.
Or
should we instead present algorithms in pseudocode
No -- "algorithms in pseudocode" is a relatively advanced course which requires some mathematical foundations. If you're teaching Algorithms to University studets, you could take the pseudo-code approach (See "Introduction to algorithms", Cormen et al) but for beginners, even a course in algorithms should probably start with the students reusing classes, and then understanding how to implement them.
I thought that ssh gave you a warning if someones public key changed. So a simple solution would be to be careful about these warnings. ssh checks public keys, so in the example he gives, ssh would give a warning because Charlies public key is different from Bobs. They important thing is to be careful about how you obtain someones public key.
That's what's called a "flimsy rationalisation". Finding clever ways to cheat the artist out of their revenue is not going to benefit the artist.
Not all artists play in concerts. Only famous artists can make money "promoting things". And Merchandising is something the band can't easily do themselves, they would need to enlist the services of someone else ( who would be open to the same criticisms as the "big bad record companies" ).
I see a lot of this kind of thing, and the "record companies" seem to be used as a convenient whipping boy to justify piracy, or the misguided attitude that it's OK to circumvent the artists compensation because they can make money "some other way".
From my understanding it cost just pennies to produce a CD, and a few bucks to market it (say, $4-$5 total) Most markup is 50-70% above that so a CD should cost
anywhere between $6-$9.
Your "cost statistics" are completely fictitious. A CD should cost however much it costs. If someone can set up a record company that can make CDs available at lower prices and offer a better value proposition to the artists, then all the major record companies will obviously lose business. The price fixing in question involved a few major record companies and top 40 records. So it doesn't seem to have increased the prices of CDs overall by orders of magnitude, but rather resulted in moderate price excesses in top 40 CDs (where they could afford to reduce the price but don't)
Few CD's cost $9, most are in the $15-19 price range. (there are exceptions I know)
Most ??? Most of the ones I purchase are in the $8-14 price range.
On to making my point. Until now there has been no counterweight to the high cost of purchasing CD's
Yes there has -- the market. If someone is capable of inventing a business model that offers a better value proposition to the artist, and offers lower prices to the consumers, then they will prevail. All napster does is provide an easy way to cheat.
The new economy isn't about technology so much as it's about a companies ability to be dynamic and USE technology to further increse profits. The recording industry,
instead of finding new solutions is going back to old tactics (lawyers & courtrooms)
Common rhetoric. Actually, the record companies are working with napster to establish a legitimate business model for the "new economy". They're not really objecting to the "technology" as much as they are to the blatant piracy commited in the name of "technology".
The killer, of course, from my (consumer) perspective is pricing. I think that "old" music (say, greater than 10 years) ought to be downloadable for no more than a dollar,
It's not going to get cheaper because it's old, but it will get cheaper once the musician is no longer entitled to royalties (ie: is dead). There are already budget priced CDs from famous jazz musicians that work out at well under $1- per song. I would expect that you would see similar price reductions when downloading online.
This huge sum of extra money has to be coming from somewhere, and simple laws of nature state that for every dollar in profit
they make, someone got ripped off a dollar [since by definition profit is a sum of money above and beyond manufacturing and distribution charges, meaning basically that
profit is whatever the difference bhetween the price of the product is, and what it is actually worth]
No, this is not accurate. The worth of a product is not a direct function of its production costs.
What's wrong with companies making profiut ? I mean, isn't that what companies are supposed to do? (if they are not supposed to make profits, there is no incentive for companies to provide more utility or lower prices to customers) It's called "capitalism". At the very least, in context of a capitalist society, the fact that a company is "making profit" does not mean that it is ripping its customers off -- it means that the company in question is performing well.
And no, companies aren't to blame for the low moral standards of the "pirates". Just as retail stores aren't "responsible" for the fact that shoplifters steal (because the products are "too expensive")
If the CD is not worth $20, well don't buy it. If you really have to own it that badly, it's probably worth $20- to you, unless your honesty can be bought for a twenty dollar bill (meaning you're either very poor, very dishonest, or both)
n lots of circumstances, these efficiency gains
Usually more important to efficiency is algorithmic choices and quality of program implementation
-- and few developers are worth a damn in this arena.
So C++/Java is usually moot point regards efficiency trade-offs, because programmers product is such
slop anyway.
I don't know about java, but at least in C++, there are generic container classes, and the C++ standard has performance gaurantees (big-O) on the effectiveness of these algorithms. So it's not accurate that the C++ programmers product is always "slop", because they can reuse well designed and implemented container classes for a lot of their work.
Java is a lot more productive than C++.
Or so they say. It's true that C++ code that makes heavy use of pointers is error-prone and needs extra care maintenance-wise, and should be locked up in a library where client code can't see it.
But if we only require java-like performance, then why use pointer-arrays instead of vectors, and why use char* instead of string ? Most of the things that are error-prone in C++ boil down to instances of the developer choosing speed over safety. If you want to sacrifice a little speed and forget about pointer arithmatic, you can do that, and you'll still be faster than java.
Slashdot Mirror
It's not "persistent". RTF-article.
Hotline Client has an ad running at all times.
Probably covered by the patent. But it seems NZ got the patent specifically so they could go after Juno, so they most likely won't get sued.
I'd have to agree with this. I've seen math articles published in CS journals and vice versa. BTW, I consider the book "Intro to algorithms" by Cormen et al to be a math book. I mean, it's a book of theorems and proofs. There is a fair bit of overlap between what "mathematicians" and "computer scientists" do. Of course, one could argue that all the computer science literature is a sort of mathematics; I don't see substantial differences.
A degree in a very theoretical course such as math/physics tends to make the harder CS material a tad easier to absorb, because you get exposed to abstractions (in fact you see things like automata, algorithms and Turing machines, though the way you approach them is quite different)
Excuse me ? Math is about solving problems, real world or not. The problems I solve have no obvious (and probably no non-obvious) relevance to "real world" problems.
Unless you're spending the entire degree memorising MFC, your knowledge will not be obsolete for a long time.
Did you try aslab www.aslab.com ? They're a linux shop.
I meant that it's not editable by mere mortals. It's a perfectly good language, but it's not intended to be hand-coded by document authors. How many people do you know who actually hand-code documents in postscript ?
IIRC there's a version of framemaker that supports SGML. In any case, I agree with the people who say that some SGML/XML DTD should be used. (btw, going with sgml was the smartest thing the LDP did ...)
and editable was one of the requirements.
- 1800 numbers are not always toll free. You could end up making an expensive call. If you want to abuse the 1800 number, do it from a public phone to make sure they're paying and to prevent them from tracing you.
-
Don't reply directly to spammers. What, you think they actually read their mail ? Most of them use disposable addresses. Certainly, the return address will not be one from which they read email. DO complain to the idiots ISP. See stopspam.org for more ideas (for example, if they claim to have made money with the scheme, report it to the IRS!)
-
Never respond with a threat. (btw, if you mailbomb to the wrong address, you'll really get burnt)
having said all this, I think spammers should be fined on a per-message basis, or on the basis of the number of complaints against them.One way or another, CORBA still needs to deal with the basic problem of object serialisation. Which would seem to be close to functionaly equivalent to building a DOM tree.
Actually, they'll get you quite a long way. For example, web development doesn't require much knowledge about algorithms. In general, lower level coding requires more knowledge about algorithms. Obviously, to be a good programmer, you need to know algorithms. And you also need to know OO.
I fear that students are to eager and teachers may be too willing to leap right in to "This is how you write a program in XXX" rather than "These are the kinds of things a computer can do...
The fact that they are using java doesn't imply that the course is going to be about java.
I still think being able to design and analyze algorithms is more important than OO.
I'd argue that they're both essential. I wouldn't even think of hiring someone who didn't understand OO if I was hiring programmers.
People programmed for years without OO, but they didn't program without understanding algorithms.
OO goes back a long way, it's over 30 years old (Simula, for example). So people have known about OO for a long time. For example, it was known about in the days of UNIX, and it seems that the designers of UNIX understood OO concepts (for example, the file IO API). It might not have enjoyed as much use/popularity back then, but then, yesterdays software was a lot simpler than todays, and programmers needed to think more about efficiency than they did about large scale design. (indeed, a lot of old software reflects the emphasis on efficiency and not design, for example DOS, and Win3.1) Nowadays, programmers using high level languages don't really need to think that much about efficiency, but all programmers certainly need to understand OO.
When you did proofs in high school geometry, you'd spent years before hand grasping the fundamentals and using protractors and straight edges.
I agree with your implicit point though that you didn't use the "latest" ones, and I don't think there's an overwhelming advantage (besides the availability of textbooks) in using java compared to using something older (such as Smalltalk, Eiffel, or LISP for example)
And since I'm fairly certain that nobody will ever read this, let me say that OO is not a magic bullet,
I couldn't agree more. OO is just one of many programming paradigms. There are other paradigms which are also very important, such as procedural programming, modular programming, and generic programming.
and I don't think it deserves the same fundemental treatment that should be given to algorithms.
Oh, I do. I think OO programming is essential. If you're not using an OO language, then it's even more essential, because the language doesn't impose any OO discipline on you.
The idea that if only you lay out your data in a OO manner, the algorithms will be readily apparent is utter rubish.
Well that's an obvious straw man. I don't know who'd be so silly to say something this absurd though. This is why C++ embraces generic programming. Bjarne's description of the generic programming paradigm begins with "Decide which algorithms you want", in other words, you choose the algorithms first, and then choose a suitable container. Bjarne doesn't try to pretend that this programming style is a subset of OO (though it seems java sort of does try to ram generic programming into OO. Which I think is a mistake btw and is one of the reasons I prefer C++) In fact if you look at STL, it is completely about algorithms and not about OO (there are objects, sure. But there is no inheritence. STL is "object based", but not "object oriented").
OO addresses issues orthogonal to algorithm choices. The main point of OO is to express commonality through inheritence, which results in consistent API designs, reusable code and reusable interfaces. The fact that algorithms are essential does not in any way make software design principles any less essential. Both are essential topics.
I agree with this apart from the fact that some of the topics you mention are a tad advanced for high school students. I don't think there's an advantage of using obscure languages. It's harder to find compilers and books and the teachers are less likely to know it. BTW, Knuth's "hypothetical machine language" is horrible. It's the only thing I don't like about the book. For a book that uses an interesting "pseudocode" language, see "Object Oriented software construction" (which actually uses Eiffel, but introduces it as an anonymous notational language)
BTW, the fact that they do choose a specific language does not mean that the exam is necessarily a language syntax test. Indeed, one needs a notation to properly describe something like algorithms, polymorphism, etc.
But to some degree, choosing the language is choosing the concepts. For example, by choosing Java, you are making a decision to teach certain things (OO) and not teach other things (memory management). Languages may go "out of style", but OO will not.
Or should we instead present algorithms in pseudocode
No -- "algorithms in pseudocode" is a relatively advanced course which requires some mathematical foundations. If you're teaching Algorithms to University studets, you could take the pseudo-code approach (See "Introduction to algorithms", Cormen et al) but for beginners, even a course in algorithms should probably start with the students reusing classes, and then understanding how to implement them.
I see a lot of this kind of thing, and the "record companies" seem to be used as a convenient whipping boy to justify piracy, or the misguided attitude that it's OK to circumvent the artists compensation because they can make money "some other way".
Your "cost statistics" are completely fictitious. A CD should cost however much it costs. If someone can set up a record company that can make CDs available at lower prices and offer a better value proposition to the artists, then all the major record companies will obviously lose business. The price fixing in question involved a few major record companies and top 40 records. So it doesn't seem to have increased the prices of CDs overall by orders of magnitude, but rather resulted in moderate price excesses in top 40 CDs (where they could afford to reduce the price but don't)
Few CD's cost $9, most are in the $15-19 price range. (there are exceptions I know)
Most ??? Most of the ones I purchase are in the $8-14 price range.
On to making my point. Until now there has been no counterweight to the high cost of purchasing CD's
Yes there has -- the market. If someone is capable of inventing a business model that offers a better value proposition to the artist, and offers lower prices to the consumers, then they will prevail. All napster does is provide an easy way to cheat.
The new economy isn't about technology so much as it's about a companies ability to be dynamic and USE technology to further increse profits. The recording industry, instead of finding new solutions is going back to old tactics (lawyers & courtrooms)
Common rhetoric. Actually, the record companies are working with napster to establish a legitimate business model for the "new economy". They're not really objecting to the "technology" as much as they are to the blatant piracy commited in the name of "technology".
It's not going to get cheaper because it's old, but it will get cheaper once the musician is no longer entitled to royalties (ie: is dead). There are already budget priced CDs from famous jazz musicians that work out at well under $1- per song. I would expect that you would see similar price reductions when downloading online.
No, this is not accurate. The worth of a product is not a direct function of its production costs. What's wrong with companies making profiut ? I mean, isn't that what companies are supposed to do? (if they are not supposed to make profits, there is no incentive for companies to provide more utility or lower prices to customers) It's called "capitalism". At the very least, in context of a capitalist society, the fact that a company is "making profit" does not mean that it is ripping its customers off -- it means that the company in question is performing well.
And no, companies aren't to blame for the low moral standards of the "pirates". Just as retail stores aren't "responsible" for the fact that shoplifters steal (because the products are "too expensive")
If the CD is not worth $20, well don't buy it. If you really have to own it that badly, it's probably worth $20- to you, unless your honesty can be bought for a twenty dollar bill (meaning you're either very poor, very dishonest, or both)
I suggest you go kick yourself right now.
So C++/Java is usually moot point regards efficiency trade-offs, because programmers product is such slop anyway.
I don't know about java, but at least in C++, there are generic container classes, and the C++ standard has performance gaurantees (big-O) on the effectiveness of these algorithms. So it's not accurate that the C++ programmers product is always "slop", because they can reuse well designed and implemented container classes for a lot of their work.
Java is a lot more productive than C++.
Or so they say. It's true that C++ code that makes heavy use of pointers is error-prone and needs extra care maintenance-wise, and should be locked up in a library where client code can't see it. But if we only require java-like performance, then why use pointer-arrays instead of vectors, and why use char* instead of string ? Most of the things that are error-prone in C++ boil down to instances of the developer choosing speed over safety. If you want to sacrifice a little speed and forget about pointer arithmatic, you can do that, and you'll still be faster than java.