Domain: aw.com
Stories and comments across the archive that link to aw.com.
Comments · 62
-
Re:Why subsidize?
You missed Washington's half-century handjob for Big Oil, the Oil Depletion Allowance.
http://wps.aw.com/aw_carltonper_modernio_4/21/5566/1424998.cw/content/index.html
One year Texaco paid less in Federal Income Tax than just one of the cleaning ladies at its NY headquarters.
-
Re:Specifics?
The problem he solved is determining the exact path of a projectile, when accounting for air resistance. The drag coefficient for air resistance depends nonlinearly on velocity, so when it is included in the model the equations become difficult to solve (previously impossible, but apparently now done. Though I haven't found any links to his actual work). Here is an example of setting up the problem, and then solving it numerically.
-
Re:Buying ARM for a leg?
Monopolies are only one facet of antitrust laws. What Apple would be doing here is Vertical Integration. Which is just as illegal as using a monopoly to engage in anticompetitive activities.
-
hey, anyone notice the book cover?
what's up with the fish-leaping-to-another-bowl pic on the cover:
cover of Beating the College Bubble
I've seen that pic somewhere before:
cover of STATS: Modeling the World
Coincidence?
-
I can source this.We talked about this in a Biology 2 class.
It's common knowlege amonst scientsits, but deffinatley not amongst the general population.
Check out Biology 7th edition, by Campbell and Reece. This link might have it if you own the book (I haven't used the online portion of the text).Read the sections on selection pressures and evolution. I don't have the book in front of me or I'd put up some quotes.
-
Re:now what to do
Pretty good guess.
http://wps.aw.com/wps/media/objects/877/898586/top ics/topic02.pdf
22hp @ 67mph for a reasonably aerodynamic sports car (Porsche Carrera,drag coefficient 0.35. My car has a drag coefficient of 0.31...). -
A few more for the mix
Some others that should be read by most programmers:
The Dragon book
Some modern compiler book, like one of Appel's, or possibly the new Aho, Sethi, Lam, and Ullman book when it's released.
Purely Functional Data Structures by Chris Okasaki
possibly Algorithms : A Functional Programming Approach by A. R. Fethi, though it's a bit light
SICP, which has been mentioned a couple of times
and does anyone know if there's a book out there on how to get off your ass and write some good documentation to accompany your code. -
Re:Nothing for you to see here
Eh? Antitrust laws do not simply protect against monopolies/cartels, but instead protect against anything that intentionally restrains trade (as vague as that is). There are several solid pages on vertical integration/antitrust (one, two ). Isn't payola a clear case of vertical integration? If you can control the channels of production, it doesn't matter if you have lots of competitors who will sell at a lower price than you; the customer doesn't have access to their product.
-
Re:Diamonds aren't rare
According to this article, Russia did flood the market with low quality diamonds. DeBeers reacted by concentrating on high quality diamonds which went up in value rather than down as the low quality ones did.
-
Re:What is it about Cathedrals?
"igb" is correct; in fact, some cathedrals have never been finished, even though they are quite useful and beautiful! Antonio Gaudi's La Sagrada Familia Cathedral in Barcelona is perhaps the perfect example of a fantastic structure that is taking centuries to construct!
Brooks has some interesting points on this in The Mythical Man Month:
A cathedral is typically being built by many architects of course. This is at least true by the fact that most of the architects did not live long enough to survive the completion of the building. Normally although the successor of an architect has shared or at least continued the construction along the ideas and visions of his former colleague.
But in Europe there are also cathedrals, that have been built by a series of architects where one did not share the ideas and vision of the previous one. These normally have a longer building time (things were destroyed and rebuilt or changed) or a very inconsistent look. But I do not think, ESR has enough history knowledge to know about this
;-).The term normally is of course important here, since there are cathedrals, that have different styles combined within them and are still very beautiful
Open-Source on the other hand generally tries to built a cathedral without an architect. Interestingly it works -- somehow, most of the time
;-). -
Re:Green Transportation?
both are greener than a car, particularly in urban, stop-start traffic.
How much greener? See my previous post: ...The bicycle is the perfect transducer to match man's metabolic energy to the impedance of locomotion. Equipped with this tool, man outstrips the efficiency of not only all machines but all other animals as well. See link and below for numbers.
How about the efficiency of a car? Numbers from here give 45mpg to equal to 66Cal/km:
45m/gal = 19km/L
with an energy density of 5.3x10^6J/L for gasoline, we get
278947J/km = 66625cal/km = 66Cal/km
Car: 66 Calories/km
Walking: 0.75 Calories/km => 88x more effiecent than a car (at 45mpg)
Biking: 0.15 Calories/km => 440x more effiecent than a car (at 45mpg)
(note, the above assume that the numbers in the linked article for people, are in nutritional "C"alaries = kilocalories, instead of SI calories. If they are SI, then the bike is 440,000x more efficient.)
The bike just rocks. :-) -
Re:The truth about XPOn the other hand, there's Fred Brooks' advice from The Mythical Man-Month: "Plan to throw the first one away. You will anyhow."
Sometimes, it really is easier to treat the first one as a prototype of what you'd really like, and then write that second one correctly, from scratch. Witness Mac Classic -> Mac OSX, Win9x -> WinNT, Perl5 -> Perl6, etc.
A lot of these prominent "next-generation" systems may share ideas & even code from their predecessors, but the essential point with each is that they all represent deliberate jump-cuts from the past. Sometimes it really is easier and better to rewrite something, whether or not you fully grok the original.
The real trick is to design systems well enough that, when someone comes along with better ideas, the framework you provide is robust enough to adapt. Mac Classic, Win9x/DOS, and Perl5 are all too inflexible for future use, though at this point each of them is still useful to certain groups. Their successors, however, are all designed with future expandability in mind, so that the "second system curse" can hopefully be avoided. History will tell if it ended up working in any of these cases...
-
Re:There's Nothing New Under the SunOther industries will follow as the necessary skills and infrastructure become more wide-spread.
Many will, but I don't think this one need go.
To keep development work here, we must exploit the one advantage we have over people 10,000 miles away: we're closer. Sure, that sounds too simple. But hear me out.
The traditional dominant development process, the Waterfall, assumes that you can put every important fact about a piece of software into a requirements document. That document is then turned over to the geeks, who could be kept in a sealed room, for construction. N months later, perfect software comes out.
We all know this is bunk. And not just from practical experience; if the requirements document really had all the needed information, then you could just write a requirements document compiler and dispense with the programmers completely. But it's the bunk that allows outsourced development companies to work. Not just because it allows them to pretend a development center on the other side of the planet is just as good. Even worse, because we believe this bunk, their development centers are just as good as keeping the engineers in the building (or city, or state) next door, as is common practice here.
So what should we do instead? We should pick development methods that take advantage of the highest-bandwidth, lowest-latency communication available to us: physical presence. If we put the engineers in the same room as the domain experts and the product managers, then we can build software more quickly and more efficiently than before.
But we get more than that. If you put everybody together, then you get unmatched ability to respond to change, change in the market, in your customer needs, in your competitor's products. A bunch of people in a room can turn on a dime compared with the difficulty of changing specs, changing contracts, and updating people who are asleep when you are awake. Even better, you can create change, forcing your competitors to try to keep pace with you.
So for those interested in keeping at least a few develoment jobs in the US, check out the book Agile Software Development Ecosystems (prices). Or look at one of the many Agile methods directly:
And for the record, I think world trade is great. If somebody in India can really do my job for 1/10th as much; then I should find something new to do, something that provides matchable value to my clients. -
Learning LinuxI have found the best way to learn something is total immersion. I have found that most "Learning" books are more suited for non-technical users, but fustrating for techies.
Pick up one of the following books: Running Linux from O'Reilly or Linux System Administration: A User's Guide from Addison-Wesley. Browse the books to get a general idea on what to do for basic tasks.
Next, find a friendly distribution that will allow you to get started, such as Mandrake.
Finally, use the OS. Try doing as much as possible in Linux. I'd suggest trying to connect to the internet first, the wealth of information available will help you with any later problems. But with each task you don't know how to do or problem you need to solve, look it up in the book you purchased or online. It may seem fustrating at times, but it really seems to stick in memory better if you actually have to do the task.
-
Publisher's site/sample chapter.
Here's the publisher's page on this book. It even includes a sample chapter.
Enjoy -
Publisher's site/sample chapter.
Here's the publisher's page on this book. It even includes a sample chapter.
Enjoy -
Re:Did you know 1+1=2?
Tao of Programming, s3.4.
Also see The Mythical Man Month , by Frederick Brooks. -
Re:XP is so VASTLY overrated...
The few things in XP that are controversial (like pair programming) don't work.
Yes it does. Maybe it didn't work for you, but it's worked fine at the company I'm at, and there are plenty of case studies showing that our experience isn't atypical. Pick up a copy of Pair Programming Illuminated if you don't want to take my word for it. It might also tell you what it is that went wrong when you tried to pair. -
Re:Yet...
Once again back on topic, I've heard about simmiler projects, the first one that comes to mind is the guy who made a copy machine out of legos here. (He now works for them.) Has anyone else seen any other insanly cool projects?
-
The Feynman Lectures
I think the Feynman Lectures on Physics are generallly considered a good overall reference, he seems to have a way of explaning the fundamental principals of physics that is easy(ier) to understand.
-
Re:Ah, Word
I've set the "Normal" stylesheet to 10 point Courier on 24 pt leading and turned off all the toolbars . . . The only reason I'm using Word is because you can import a styled Word document into InDesign and let InDesign's stylesheet override the formatting in the Word document.
Have you considered LaTeX? It lets you write your docs in a simple text editor (which is pretty much what you've turned Word into) and then apply the correct formatting, pagination, endnotes, citations, fonts, figures, and layout later.
It works great in Mac OS X, and has a few good Mac OS-native frontends. It produces PS or PDF, and doesn't cost a dime! The markup language takes a little getting used to, but there are some excellent books available, or you can use a WYSIWYG front-end.
-
Re:Not Surprising
-
Linux: The TextbookLinux: The Textbook
Publisher: Addison Wesley
Copyright: 2002
Format: Paper, 678 pp
ISBN: 0-201-72595-9
Status: Published 07/02/2001
Retail Price: $52.00 USI know nothing about this publication, but the table of contents suggests it covers the areas you want.
-
Linux: The TextbookLinux: The Textbook
Publisher: Addison Wesley
Copyright: 2002
Format: Paper, 678 pp
ISBN: 0-201-72595-9
Status: Published 07/02/2001
Retail Price: $52.00 USI know nothing about this publication, but the table of contents suggests it covers the areas you want.
-
Textbooks, Resources, LDP
As an academic myself, a few different issues spring to mind. I'll try to organize them in a somewhat coherent fashion.
First, I would ask if you really need textbooks? While most professors still use textbooks, a lot of people do fine without using any textbooks at all. Yes, it requires more effort on the part of the professor to research all of the sources themself; however, in my experience, the results are certainly worth it. Rather than teaching a politically-correct, watered-down course, you can tailor it to precisely what you feel is important. And shouldn't that be a professor's obligation anyhow?
For sources, I would start with the LDP, the FSF, O'Reilly, and Addison-Wesley. These guys easily make up over 95% of my tech bookshelf.
Addison-Wesley also does textbooks. I don't know how good they are but if they pay as much attention to their textbooks as they do to their IT texts, they'll be excellent.
On another matter, if you're going to consider rolling your own textbooks, don't reinvent the wheel. Much, if not most, of the documenation out there is under a free-as-in-speech license. Use it. Also, I don't think that you need to start your own website. I can't speak for the LDP but it seems to me that they would be delighted to assist you in developing the texts that you need.
Finally, if you go to the effort of developing all of this content, please do the right thing and share it with the community. Ideally, this would through a free-as-in-speech license. -
Vendor specific
The biggest downside of the STL is when it doesn't work.
Sure, the standard is >3 years old now, but a lot of compiler vendors are still working out bugs with either the STL, their compiler, or their linker still.
Under AIX, we've run into relatively few problems with the STL itself, but the linker is pretty bad. Between it and the compiler compiles take forever (which is why I've been surfing /. more recently), and the executables are freaking huge.
This is, obviously, an AIX-specific problem. And it's pretty much an old story - every vendor has their own quirks with the compiler and/or linker.
Beyond that -- I've found a few things missing in the STL that would be really nice to have.
First, the only smart pointer is std::auto_ptr. It's pretty useless, since you can't use it in a collection, and you can't have more than one thing pointing at an object/memory block at once. This can be worked around though, since there are libraries that have better smart pointers. Check out Loki or Boost for two.
Second, there's no way to automagically ignore case on a std::string, or to upper/lower case it easily. Yes, I know, you can muck around with traits, but that's a PITA and renders your string uncopyable to other strings easily. Yes, I also know that you can use a transform() to do it. But this still isn't as nice as myString.lower().
Third, there's no date or datetime classes. You have to fall back on C time functions for them. I haven't looked for a good C++ library to handle date/time, but I'm sure there's one out there.
Fourth, there's no regular expression matching on strings. We use PCRE with a C++ wrapper and it works fine for what we need though.
Both 2 and 3 are due largely to internationalization issues... in the case of 2 there's a lot of languages in which upper and lower case are non-sensical. And after having thought about the i18n issues regarding dates, I don't blame the standardization committee a bit for running away screaming from them (what date range? which calendar? how do you change between calendars? what about date weirdness with some calendars (like the missing days in the Gregorian calendar)? etc).
I used RogueWave prior to this job, so I tried to think of some of the things I was used to in RW and weren't in the STL. By and large I prefer the STL though. The container classes in particular are a lot more sane than RW's. -
Re:Why?In Kernagan and Pike's The Practice of Programming they argue that programs that are written to be portable are inherently better programs. The abstractions that need to be done to make a program work across different operating systems and architectures, (and don't think of "Unix" as a single operating system. Think of it as a family of operating systems.) are abstractions that help improve program quality.
If systems seem all the same to you, then either the range of systems you have developed for are rather limited, or the complexity of the development has been rather shallow.
-
Re:Integrated database computers: IBM AS/400
> Well, when 7 dead astronauts are traced to SQL flaws, then perhaps the "real relational" model will finally get the attention that it allegedly deserves.
You should read the authors you criticize before being ironic about them anyway, my example was purposefully overshooted to try to bring your attention to the fact that theory is practical, and there is more than one book about that, but you seem to have also purposefully missed the point.
> What you need to sell it is catchy buzzwords and toy examples and techno-cliches that inject half-baked ideas (or even those that happen to be full-baked) to PHB's.
Here I agree with you. But all this can come just after an implementation of the relational model gains some acceptance. It’s a chicken-and-egg problem which was broken for the basic relational ideas by IBM Future System’s System R prototype which eventually became SQL/DS. BS12 could have been it for the full relational compliance, but perhaps now it’s too late for it, even with IBM newfound open source friendliness. But Alphora Dataphor could be it, too bad slashdotters don’t want to hear about it. There were at least two rejected submissions about it.
> I agree that NULL stinks overall. It's few benefits are not with the myriad frustrations it causes.
You get the point relating to NULLs. You can say about the same about duplicates, inconsistent language design, lack of closure, arbitrary restrictions, broken types and domains system, mistaken object support (the relvar == class blunder), and the list goes ever on that’s why it’s way better to ditch SQL and start all over again, and that’s why we need The Third Manifesto.
-
Some more recommendationsI'm no security expert, I've only just recently started reading. And incidentally, a couple of days ago I've begun reading "Security Engineering". So far I share the reviewers very good impression.
I'd like to recommend some complementary books; each of these approach security from a different angle
- Secrets & Lies by Bruce Schneier. Deals with the "soft" issues. What are the threads to networked systems? Who are the attackers? One of the messages: Risks can't be avoided -- manage them.
- Building Secure Software by John Viega and Gary McGraw This one's closer to technological issues related to security. Risks of various base technologies (languages, middleware). Introductory details on buffer overflow attacks, random numbers, cryptography. Some organizational/dev process stuff.
- Secure Programming for Linux and Unix HOWTO
- by David A. Wheeler. Technical security down to the C-level. Programming techniques.
Michael
-
Re:dead tree books
I hardly buy any paper book, but happily buy CD/HTML books, if available. I boycott paper books. I am so used to reading on the screen that I just prefer it.
It's faster to access a browser bookmark to an HTML page on the harddisk than to get a book out of the shelf and find the right page. Switching between windows is also faster for me than switching between screen/mouse and book on the desk, esp. with large screens.
A good example is the Design Patterns CD. Too bad that Bjarne is not available on CD. -
Re:dead tree books
I hardly buy any paper book, but happily buy CD/HTML books, if available. I boycott paper books. I am so used to reading on the screen that I just prefer it.
It's faster to access a browser bookmark to an HTML page on the harddisk than to get a book out of the shelf and find the right page. Switching between windows is also faster for me than switching between screen/mouse and book on the desk, esp. with large screens.
A good example is the Design Patterns CD. Too bad that Bjarne is not available on CD. -
the ideal tech books
...are short. Say, around 250-270 pages.
Not huge 500+ page tomes that try to cover everything.
Not books with 3+ page code segments (and certainly not with code that doesn't compile).
Skinny, easily totable books. A good example is Effective C++--256 pages (plus or minus a few for endpapers and colophon).
Books that can be read quickly, with comprehensive indices to find what you want, and bibliographies to other short books with details.
Why?
Because these are the shortcomings I perceive in the major market. (O'Reilly's books being among the biggest offenders, the pocket reference books aside.) A large book is harder to have open on your desk, harder to move back and forth in your laptop bag, and (more importantly) tends to suffer from lack of editing -- authors will repeat themselves and say the same things over and over again. (They also tend to repeat themselves.) Anyone who's done book-writing knows that it's much easier and better to edit down too much content than to try to generate filler.
There is a drawback to this, though. Imagine how much more Addison Wesley would have had to have charged for The Bible had it come in six, easily digestible segments. And I do make exceptions for things that are meant to be references. -
Large-scale projects.
Large-scale project management (open-source and non). This is something that gets taught at few if any universities but is, obviously, necessary in the real world. The Mythical Man Month is useful but it hasn't been updated for a while and that applies more to the IBM manager culture than the domain of a few programmers or a distributed Bazaar.
I'd love to see a book that outlines major successes *cough*GNU/Linux & Slashdot*cough*, semi-successes *cough* ? *cough*, and failures. Including interviews, looks at their organizational structure (leutenants, an overmanager, etc.) tools, and life cycles. I'd also love to see some debate on the Multi-language/Single-Language question. -
On the whole...I agree with the reviewer. I have the book and a large amount of it is going on and on about a non-software system. While this is not great for applying the UML to current projects at work, it is _really_ good if I need a quick reference to things like what is the difference between an aggregation (a zoo is still a zoo if it has 1 or more anaimals) and a composition (a table can't be a table without a top and legs) that is easily real world understandable. A better book for reference though is UML Distilled by Addison-Wesley.
psxndc
-
Re:Insightful or useless banter?you'd imagine they would use an open document format.
Care to expand on how PDF isn't an open format? It's fully documented by Adobe in the book "PDF Reference" (ISBN: 0201615886 for the current 1.3 version, or 0201758393 for the soon to be released 1.4 version). It's also available online in various places, for example, http://wotsit.org. Furthermore, several independent implementations of PDF encoders and viewers exist, such as xpdf and ghostscript. Yes, many PDFs include LZW compressed data, but that's a problem with Unisys, not Adobe, and there are non-patent-infringing ways of uncompressing the data anyway. Plus, modern PDFs are compressed with the patent-free deflate algorithm. So exactly how more open do you want PDF to be?
-
Re:What they missed
Efficient programming tools.
Go back and read Fred Brooks' excellent book, The Mythical Man-Month (original copyright, 1975, 20th anniversary edition in 1995), and specifically chapter 16, "No Silver-Bullet -- Essence and Accident in Software Engineering". If you come across the 20th anniversary edition, also check out chapter 17, "No Silver Bullet" Refired, and the following chapter that discusses which of Brooks' predictions did, didn't, and were/are waiting to come to pass. Chapter 16 is captioned, succinctly,
There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicitly.
Even though that was written decades ago now, it's every bit as true now as it was then. There are no programming breakthroughs on the horizon. Four programmers never will be able to write a better Photoshop in four months, because Adobe has been pouring dozens or hundreds of very smart programmers on the problem for years now, and they've had access to the very best development tools and methodologies available.
As one very smart and very skilled Perl hacker I know mentioned recently, he *hates* Perl and he *hates* programming, not because Perl is such a bad language -- he doesn't seem to think that it is -- but that even a cleverly idiomatic, high level language like that can't do anything to make the everyday logical issues in programming go away. All it can do is, as much as possible, minimize the burden of having to juggle syntax, implementation details, and high & low level logical issues all at the same time.
No software development breakthrough has been able to eliminate those problems. Not high level languages, not object-oriented tools & methodologies, not artificial intelligence or expert systems or graphical / icon based programming or fancy debuggers or advanced IDEs or more powerful hardware. None of it has made the essential, intractable problems go away, though most of them have made the ancilliary issues less problematic. As Brooks puts it (emphasis his):
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compares to the conceptual errors in most systems.
If this is true, building software will always be hard. There is inherently no silver bullet.
And that about sums it up. You might as well focus on the hardware advances, because Moore's Law is still making it proceed at an incredible clip. But software? It isn't growing any faster than any other human endeavour, which is to say, it's moving slowly and it always will. It's not the software's fault that the hardware is making it look pokey, so please don't ask any more of it [in terms of methodology or technique] than the last fifty years of experience have been demonstrate. Clearly, we're moving ahead as fast as we can, and that means slowly...
-
How about Copliens book as prior art ?In James Coplien's famous book of 1992, chapter 9 is all about patching running code with new code at run-time:
Chapter 9 also presents idioms supporting incremental run-time update. Implementations of this idiom are necessarily dependent on many details of the target platform. The gist of this material is to familiarize the reader with the level of technology at which incremental loading issues must be worked.
Might be worth seeing if any of that is useful as prior art, or the bibliography or uses he describes can illustrate that the problems and techniques were alreayd well known at the time.
T -
Re:lots out there
Codewarrior has some nice features for sure, but after the license fiasco at UK, I'll never use it.
Synopsis:
For intro to programing (CS115) the gods above decide it was time to move to an IDE, so packaged with our text(excellent book for intro C/C++ programing BTW), they bundled a copy of CodeWarrior 4 that had license keys that expired about a week after classes began. So the CS department had to scramble with Metrowerks to get new keys, but I kept chuging along with HTML-Kit, puTTY and the student webserver, with my ~home/bin mounted on my windows box. Every program was compiled with -ansi and -wall switches. I double checked on codewarrior to make sure it would compile before submitting programs, but that was about it. -
Physics
The Feynman Lectures on Physics.
see http://www.aw.com/product/0,2627,0201500647,00.htm l -
The Language List
It won't be complete if I don't include The Language List. Not only this page contains resources for those esoteric ones, but also other "saner" languages too.
For those of you who want to create programming languages, make sure you read the underlying principles. If you know all these stuffs, your programming language will not be just a toy!
-
Re:Coincidently...Well:
Modern Operating Systems
Linux Kernel Internals Unix Kernel Internals is better but I couldn't find a link
C Programming Language -- you gotta have the bible
These aren't nearly enoguh resources, but they're a good start. Of course if you just want your own UI it depends on what you want. You can write your own window managers ect for X or you can use
"Cracking Shells" in Unix Programming to give you a jump start on writing your own shell which is not a bad little project. Of course in order to build your own shell you'll probably want to have a scripting language tied to it so make sure to pick up the Dragon Book. -
Suggested reading, Parnas' "How to fake it"
In 1986 David L. Parnas and PC Clements published a paper entitled, A Rational Design Process: How and Why To Fake It. Parnas and Clements present a strategy for imposing overlying order upon the often fractured development process; the goal of which is to produce better software. Doing snippets of work for managers/clients who don't care about quality as much as they care about costs is often a cause of this fracturing.
I couldn't find a copy of the paper online, but it has recently been re-published in Software Fundamentals: Collected Papers by David L. Parnas.
-
Re:Java lacks genericity...
It's almost the complete opposite, actually. For a start, the myth that templates cause code bloat is falling apart.
Perhaps more importantly, much state-of-the-art research in C++ relates to good use of templates. Some very powerful techniques, particularly relating to efficient and flexible library design, have come from templates. Check out the Blitz++ and Loki libraries for examples.
-
Re:templates and operator overloading are good thiI agree with you. This guy obviously wants a language that is easy to compile. Unfortunately, that misses the entire point of having a compiler in the first place.
As soon as I saw that he got rid of automatic objects, operator overloading, templates and multiple inheritance, I knew that he does not have much knowledge about the use of these features in large projects. Most complaints I hear about C++ usually focus on these items and are made by people who do not fully understand the power and flexibility they provide. They are stuck in the 2-D world of simple datatypes and containers of X.
Automatic objects are absolutely essential for the "resource initialization is acquisition" paradigm. Mutex locks, for example, are trivial to use with this technique. And they work automatically when exceptions are thrown. This is why automatic variables are a pain to implement with exceptions, but with D the programmer will have to clean up manually, writing the code that C++ compilers generate automatically.
Operator overloading is used for a lot more than complex, string and smart pointer objects. The [] operator is used on anything that acts like an array or map. The () operator is essential for nice functors, callbacks and generative programming. Operator overloading and templates has been used to create parsers that allow users to write BNF-style grammars directly in C++. I once used them to easily build ASTs for C expressions.
Which brings us to templates. Templates are a crucial element of C++. So much so that most experts now advise less inheritance and more template specialization. They are used for much more than "container of X." The whole C++ generative programming movement is based upon them. They in turn require things like operator overloading because templates are a weaker form of binding. Rather than conforming to the "isa" relationship, a template argument need only implement the syntactic interface of the operations used in the template.
Templates are so important that even Java is going to get them.
Multiple inheritance does have a performance penalty and certainly is complicated for implementors, but it is incredibly useful. Again, generative programming along with advanced generic programming with design patterns uses MI mixins to add features to objects. See books by Andrei Alexandrescu and Krzysztof Czarnecki and Ulrich Eisenecker for what I'm talking about. This is very cool stuff.
Be very suspicious of languages developed by and for compiler writers.
-
MetaPost
-
Re:C++?
imho...
C++ isn't easy to understand for a beginner.
The books listed below are the best at explaining it.
This book is online:
Thinking in C++
You'll have to pay for these:
Accelerated C++
C++ Primer -
Re:C++?
imho...
C++ isn't easy to understand for a beginner.
The books listed below are the best at explaining it.
This book is online:
Thinking in C++
You'll have to pay for these:
Accelerated C++
C++ Primer -
Re:Pardon me?
There are also bugs associated with straight DNS queries. Go, now, and shut down BIND.
You've never been responsible for administering a secure system have you? If you have, then you're miserable at it. Read some. I'd recommend "Firewalls & Internet Security" by Cheswick & Bellovin. Or "Building Internet Firewalls" by Chapman & Zwickey. Both of these books describe one of the primary security priniciples: "least privilege". In short it says, don't allow anything that you don't have to.
If you have to allow DNS queries, then you have to. But just because you have to allow those queries doesn't mean you should also allow zone xfer. It's quite simple arithmetic: the number of security holes in DNS queries is less than the number of security holes in DNS queries + the number of secrurity holes in DNS zone transfers.
This is like a store with a "closed, come back later" sign vs. a "open" sign. Are people made criminals for looking at a closed store in your world?
No, but when people come poking at my alarm system to see what happens, especially when they have no reason for doing it, I can't help but assume that they're trying to figure out my weaknesses for some other reason.
Your analogy is collosally bad. It assumes that you can look at my computer, without it impacting my computer. In the store analogy, you are of course correct, simply looking at the store to see if its closed is not criminal. But looking at my computer, requires that you actively use bandwidth that I PAID FOR, and make use of computing equipment that I PAID FOR. You are already impacting my expenses. You should have *no* expectation that I'm providing DNS zone transfers, therefore you should not go looking. You should also not probe my syslog ports, nor my printer ports, nor my RPC ports.
Looking to see if the store is closed is one thing. Peeking through the window to see where the safe is kept is another thing altogther.
The average Internet user has no idea that you are offended when they connect to port 31337 because they were trying to get to some high-port FTP site, but they can infer from the connection refusal that there is nothing there for them.
You are an id10t. 31337 is the TCP connect port for BackOriface. 27374 is the TCP connect port for SubSeven. These are remote controllable trojan horses that have been widely spread through email virii. Anyone connecting on those ports, should by default be seen as hostile.
If security for you includes worrying about incoming TCP SYN packets, fine. But don't make trouble for users because they had the nerve to use the Internet as it was intended, because I'm sure you use the Internet too.
The original intention of the Internet also included the idea that no for profit organizations should be on the internet. The original intention of the internet included bugs. So, according to you, we should simply drop all prudence because someone 30 years ago couldn't forsee everything that would be happening today?
No. I think the deal here is that you want to continue running your port scans and justify it under the heading of "well it's just the way the Internet is sposed to work". Maybe. But do that to my machines and I will make trouble for you. Don't like it? I don't care.
-- -
Re:Multithreading Can Be a Good General Design
I feel that being able to multithread code effectively in Java would make a programmer advanced in that topic.
Here's the best book on the subject:
Doug Lea, Concurrent Programming in Java. Second Edition: Design Principles and Patterns
book home page
author home page (pointer to online supplement for the book)
at Fatbrain
at Amazon -
Re:Don't do eitherI think you could help answer your own question by trying to identify more clearly what you want to get out of going back to school. You mention that you feel that you're "lacking in [your] skills". I know people who've gone through full undergrad and masters degrees in CS who still feel that way when it comes to writing code in the real world, so I think you need to figure out more about what you need or want to know more about, and try to find a school that'll give you that, or even pursue that knowledge outside of school.
If one of your goals is to have the piece of paper that says you're a qualified computer scientist, then clearly you have to go back to school in some form to get that. But if that doesn't matter so much to you, there are plenty of ways outside of school to gain knowledge that's directly relevant to your skills, or that will provide you with an excellent foundation to work from.
If you're good at studying by yourself, on the CS side there are classic textbooks like SICP (link has full text; also see the Slashdot review) and other reference books like Knuth's The Art of Computer Programming, or more focused books like Aho et al on Compilers. Studying material like this on your own can be difficult without any guidance, which is of course one of the reasons people go to college. But starting along this road may also help identify what you're interested in and what you're not, and where your strong and weak points are. That could help you choose your next step.
If you do start self-studying, some social support can help - joining mailing lists related to the topics you're interested in, finding local people who're interested in pursuing something similar (perhaps via clubs), etc.
Aside from the traditional pure CS material, there are plenty of good books out there that relate more directly to the world of work. One book that I've recently found helpful is "Analysis Patterns - Reusable Object Models" by Martin Fowler. This covers patterns that arise often in general business and financial applications, so may not be the kind of thing you're looking for specifically, but I mention it as an example of the kind of stuff that's out there - there's far more than just "Java for Dummies", and if you want to improve your skills and knowledge, you should seek some of these out.
If you do go back to to school, I think in some respects, Math might be a better choice, since (a) you really love it and (b) I think it's a "deeper" subject - compared to many advanced math topics, much of computer science is simple by comparison. But this comes back to what you want out of it: a math degree would open up science and engineering jobs that you could never get without it, but it doesn't directly provide you with CS skills, although a smart employer should recognize that a math major with CS skills is a great catch.