Knuth Previews New Math Section For 'The Art of Computer Programming' (stanford.edu)
In 1962, 24-year-old Donald Knuth began writing The Art of Computer Programming -- and 55 years later, he's still working on it. An anonymous reader quotes Knuth's web site at Stanford:
Volume 4B will begin with a special section called 'Mathematical Preliminaries Redux', which extends the 'Mathematical Preliminaries' of Section 1.2 in Volume 1 to things that I didn't know about in the 1960s. Most of this new material deals with probabilities and expectations of random events; there's also an introduction to the theory of martingales.
You can have a sneak preview by looking at the current draft of pre-fascicle 5a (52 pages), last updated 18 January 2017. As usual, rewards will be given to whoever is first to find and report errors or to make valuable suggestions. I'm particularly interested in receiving feedback about the exercises (of which there are 125) and their answers (of which there are 125).
Over the years Knuth gave out over $20,000 in rewards, though most people didn't cash his highly-coveted "hexadecimal checks", and in 2008 Knuth switched to honorary "hexadecimal certificates". In 2014 Knuth complained about the "dumbing down" of computer science history, and his standards remain high. In his most-recent update, 79-year-old Knuth reminds readers that "There's stuff in here that isn't in Wikipedia yet!"
You can have a sneak preview by looking at the current draft of pre-fascicle 5a (52 pages), last updated 18 January 2017. As usual, rewards will be given to whoever is first to find and report errors or to make valuable suggestions. I'm particularly interested in receiving feedback about the exercises (of which there are 125) and their answers (of which there are 125).
Over the years Knuth gave out over $20,000 in rewards, though most people didn't cash his highly-coveted "hexadecimal checks", and in 2008 Knuth switched to honorary "hexadecimal certificates". In 2014 Knuth complained about the "dumbing down" of computer science history, and his standards remain high. In his most-recent update, 79-year-old Knuth reminds readers that "There's stuff in here that isn't in Wikipedia yet!"
Thanks, Donald!
I was with you until "I taught myself PHP."
Similarly, one could argue that a many medical-related treatments are competently performed by people who do not have the benefit of a medical school education. I haven't heard that Knuth considers mastery of, or even familiarity with, his books to be a requirement for writing code.
Donald Knuth is an elitist. It is not necessary to have a background in mathematics to write software. I taught myself PHP and I certainly don't have any kind of mathematics background whatsoever. It isn't dumbing down as he claims. It's about creating opportunities. If you can code and you can do it well without mathematics, so be it. The math side is for those that want to do research. I work in the real world ....
In the "Art of Computer Programming" context mathematics includes various things related to the performance of algorithms (code). Such things are useful, even essential, well beyond the domain of research, in many areas of the real world of software development (coding).
I've never looked at PHP. I have done javascript/ecmascript. A pathetic pile of shit called a language. I've heard PHP is worse than ecmascript, but as I've never done PHP I don't really know.
So, you taught yourself PHP and can call whatsisname irrelevant?
I can only hope I can somehow track your screen name to the name on your resume and get it shitcanned before it hits my desk.
bought Knuth's 3 books in the 80s
invaluable
retired, haven't bought any of his newer books
FFS - those who want to model the real world need to be able to pick up a bit of mathematics somewhere.
That's why in my workplace we have actual engineers churning out shitty code instead of CS graduates who could produce wonderful and efficient code if they had some clue where to start. If you can't even answer the question "what's a fourier transform?" then you are doomed to attempt to solve many problems in ways that will take orders of magnitude more time than really shitty code from someone who can.
You don't have to start with it, but if you don't pick up a bit of mathematics along the way in something that is a very mathematical field you will be very limited in what you can do.
You are, IMHO, and idiot. I have been studying Knuth's work for almost 4 decades now, and am still learning from it. In case you are interested (probably not) it is has a chip in it, I wrote the software that built that chip! Building from his work has given me a US Patent on adaptive systems, numerous technical publications, and such. What can you claim?
Sometimes, real fast is almost as good as real-time.
"There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy. your philosophy"
Yes, you are correct, you don't need much math for some types of programming. However, it saddens me that you would attack a man for wanting to expand and master the study of computer science. He has literally devoted decades of his life to writing books to help programmers such as yourself get better at their craft. If you don't want to learn more about your trade, that is fine too. But don't get upset if you get passed over for a job in favor of some other guy who cracked open Knuth and worked all the exercises.
HA! I just wasted some of your bandwidth with a frivolous sig!
I use LOGO for all of that. It's turtles all the way down.
Inheritance is the sincerest form of nepotism.
> I taught myself PHP
That's awesome. I respect anyone who has the desire to learn, the puts in the work, and has the discipline to see it through.
PHP is of course a language, a set of vocabulary. At the back of any textbook, you'll find a glossary, the language or vocabulary used in the book. You've already learned the language, the glossary, of PHP programming. If you look, you may find there's a lot of cool stuff in the other parts of the book, systems architecture stuff, software engineering, analysis of algorithms, etc.
You need to learn a programming language or two before you learn analysis of algorithms or software engineering, because the languages are the vocabulary words of the field.
To give a concrete example, when I started my current job, the company had a software system that worked - mostly. A team programmers had worked several years on it, and all knew the language they were working in. Customers just wanted it to be faster. It was definitely too slow. Although it was my first month on the job, when I heard the complaints of slowness I said in a meeting "I'd like to take a look at that; I can probably make it 20%-30% faster easily enough for now, then do more after I understand how it all works." The team was rather skeptical, in fact they chuckled out loud at my claim, saying "I rather doubt you can do that". "How long do you think that'll take?", they asked. "Give me a week", I said, though I hadn't yet seen the code. They laughed again, hundreds of thousands of lines of code and this new guy was going to make it 20%-40% faster in a WEEK? Doubtful, they said. To put me in my place, they said "sure, go ahead and try that [wiseguy]."
As I left the meeting I realized I had just taken a big risk. When I went home I told my wife that I had just bet my reputation at the new job on a claim I only hoped I could fulfill. If I failed, it would establish that I'm an arrogant prick. If I succeeded, I'd be known as possibly the best programmer in the building.
Well a week later I had it running 30% faster. Why could I, in a week, make drastic improvements to code they'd been trying to speed up for months and years, code I'd never even seen before? They all knew the language almost as good as I did. But I had been taught to study much more than the language. They knew C, Perl, and Erlang; I knew algorithms and cache theory. So in a week I did in fact make major improvements to their years of work.
Now, I'm going to go upstairs and check the progress of my benchmark. Now six months into the job, a major customer again complained about slowness, so I've been looking at that for a few days. I hope to see that my three day's work has made the system another 20% faster. I'm a tad nervous because I need to impress the new boss, I think that by learning more than just the language (glossary terms) I'll be able to do that.
Donald Knuth is an elitist. It is not necessary to have a background in mathematics to write software. I taught myself PHP and I certainly don't have any kind of mathematics background whatsoever. It isn't dumbing down as he claims. It's about creating opportunities. If you can code and you can do it well without mathematics, so be it. The math side is for those that want to do research. I work in the real world ....
There's a lot of jobs for coders who don't know math, but there's a ceiling on how good a programmer you can become.
Fundamentally all programming is research, you have a problem and you need to develop a robust solution on how to solve it.
Sometimes those problems don't involve math, but sometimes they do. You might need to implement a specific calculation (and understand how to verify and debug it), if you have a large data base you need some math for your queries to return quickly. And for any non-trivial problem where you need to design your own algorithm you need to have enough of a mathematical mindset to write it efficiently.
Think of it like race car driving. Driving a race car has a lot of special skills useless for 99% of of driving in a city. But someone who trains with race cars is probably going to be better at that 99% because they push past their limits. And the 1% where those special skills do come in handy they'll see a drastic difference.
I stole this Sig
I really hope you will retire before 20 years from now on, because at that time being a self-taught PHP developer will be totally worthless on the job market. That's why the maths are important. The more the time grows, the more low cognition level skills loose their value.
So now you're doing web services in PHP for a living. I'm pretty sure in a not so distant future this will be replaced by a series of drag and drops of functionality boxes in a special designed software that a guy paid on tenth of your salary can do. What will you do when that time arrives? Develop the boxes, these require a lot more maths. Develop the software that produce the software from the boxes? That requires a tremendous amount of maths.
Yes it is not necessary to have a big background in maths to write basic software now, thanks to simpler programming models. The thing is, writing those software will be unneeded pretty soon, because the next programming models will be so simple that they will render yours obsolete. You're like the mechanic refusing to learn how electric/hybrid vehicles work. No consequence right now, but not a very safe bet on the future...
Video of some good progressive thrash music
It is not necessary to have a background in mathematics to write software
No it's not, but it is necessary to have a background in mathematics to write good efficient software. If you're slapping together PHP libraries then that's fantastic, but don't pretend that this same level of knowledge applies to identifying the most efficient sorting algorithm, or figuring out how to software decode a CRC message in the lowest number of CPU cycles.
If the world was made of people with your views an octo-CPU quad xeon wouldn't be enough to boot up windows in a reasonable time.
But craftmanship.
For example, even simple things like hash tables and balanced trees are beyond what most current CS graduates can implement or do understand. Forget about things a bit more complicated like a complexity analysis, or a formally specified invariant or pre- and post-conditions. If you do not understand the basics, all higher-order constructs are meaningless because you can only memorize how they behave, but you can never understand it or verify your understanding. And your understanding will at the very least be incomplete and partially wrong.
CS continues to fail (and in fact it is getting worse) at education engineers. Yet the human race knows that for technology you need engineers as soon as you are customizing things or doing new things. Until and unless this gets finally understood and becomes the norm, software and everything built around it will continue to suck badly.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
... "The Art of the Pussy Grab."
It little behooves the best of us to comment on the rest of us.
You still have to work at fixed hours, sometimes stuck on a silly shifts, with the stress of dealing immediately with many requests as they come in, and even by the end of your career you'll be happy if you even reach 6 figures.
My IT support contracts prohibits me from working more than 40 hours a week. I haven't worked overtime in over a decade. I start work at 7AM instead of 9AM or 10AM to avoid the traffic gridlock. I'm responsible for 80,000+ workstations and no longer deal with users. As for dealing with the stress, since I'm working in government IT, I have paid federal holidays (40 hours), paid time off (80 hours) and unpaid time off (40 hours). This year I got an extra month of pay as a Christmas bonus. I'm studying for my InfoSec certifications that should put me in the six-figure club for my next job.
Developers on the other hand have an easy life, working whenever they please, and get paid a lot more from the get-go.
The developers I know work 80 hours a week from 10AM to 12AM (programmer hours), owns a Tesla car or two, have a big house, big wife and big kids. They never get any time off to do anything. If they stop running on the treadmill, everything falls apart because they're one paycheck away from bankruptcy.
Introduction to Algorithms by Cormen et. al. is a good book and covers part of the same space.
I do agree that he uses MIX more than is needed, but it's necessary for a part of what he covers. For other parts C would be a superior substitute. And while I keep several works on algorithms on my shelves, and rarely turn to Knuth, we something isn't covered well elsewhere, that's where I turn.
I think we've pushed this "anyone can grow up to be president" thing too far.
It depends on exactly what you are after. Sedgewick has/had a few books called "Algorithms in C++/Pascal/??" that was decent light coverage. "Algorithms + Data Structures = Programs" by Wirth is pretty good, but I don't think it was ever translated out of Pascal. And the current modern approach is Google (I only recommend that one as a supplement).
P.S.: One of the Sedgewick books had several errors in the algorithms, so be sure you don't get the first edition.
I think we've pushed this "anyone can grow up to be president" thing too far.