The shortage of high-tech employees is a myth. There IS a shortage of low-paid slave laborers, so the computer
industry wants imported wage slaves. Companies are too cheap to pay for experienced programmers, they claim
that anyone over 25 years old is obsolete, retraining time is too long, they want too much pay due to seniority, etc
etc.
I don't believe it. I'm hearing this a lot, but it's not what I'm seeing myself.
Just this morning, the FedEx man arrived with a job and H1B offer for me in the USA. I'm nearly 38. I've got 15 years experience in programming and they've offered me a 6-figure salary, doing EJB, JSP and things like that -- none of which I've done (exactly) before. My (phone) interviews were full of "do you know X?". "No, but I know Y and Z, which are similar".
I just don't see any evidence for "anyone over 25 years old is obsolete" or slave wage rates being paid or unwillingness to do retraining or anything like that. Maybe I'm just blind, but everything I've seen indicates that $100k+ is still regarded as a good salary in the USA -- certainly the article that kicked off this discussion seemed to think that a couple earning six figures between them were doing OK. So, how am I being exploited? I'd really like to know before I sign...
An actual benchmark here. I had a Christmas puzzle that involved placing 4x4 tiles so that coloured patterns on the edges matched. Failing to do it manually, I wrote a Haskell program to solve it -- 2 hours to write, 20 seconds to run, gave all the solutions. I then developed a C program to do the same thing. About six hours to write, less than 2 seconds to run.
I had a similar experience about ten years ago. Visiting a friend's place they had a puzzle that sounds similar -- squares with four turtle heads or tails on them and you had to match them. The only computer they had was a Mac Plus with Turbo Pascal. 45 minutes of coding and 10 seconds of runtime later, we had all the solutions.
Using this test, Pascal is a better prototyping language than is Haskell.
Oh, and that was on an 8 MHz Mac Plus. The runtime on a modern system would be undetectable.
Anyway my point is that a mini like a PDP11 that could support 30 timeshared users for tens of thousands of $$ WAS a big deal.
Right. Here in NZ the big old universities had B6700's, but the new boy Waikato got a PDP11/70. I used that in 1981 and it ran about 40 - 50 users in 768 KB of core, on the RSTS/E oprating system.
By the next year we had a VAX 11/780 which ran about the same number of users in 1 MB or 1.5 MB (I forget) on VAX/VMS.
During the day both those systems were slloooowwww. But in the small hours with only half a dozen people using them they were really quite snappy -- certainly better than any PC you could get at the time.
I mean, can you imagine what the people that have spent 6 years getting a MSCS have gone through? Let's see, in 1994 they were using Win3.11/Dos5. 1995, Win95A. '96-Win95B. 1998 - Win98. 1999 - Win98SE. Toss in the changes made to Windows NT/2000 (That would be from 3.51 to W2K) and all of the different *nixs and look what you have... People with a lot of knowledge about outdated, mundane, obsolete technology.
You appear to be confusing a degree with a polytech course.
My partner (who is a classical pianist who did eight years of university study in music at one of the best conservatories in Russia) just finished a one year computer course at the local polytech. Yeah, it was all the sort fo stuff you list and will be obsolete in five years.
But my own Computer Science batchelor's degree is now sixteen years old and is in *no* way out of date. Sure, no one uses VAXes (let alone PDP-11's) any more, and Pascal, Modula-2, BCPL, COBOL, FranzLISP, and FORTRAN are getting pretty thin on the ground too. But that doesn't worry me at all. I've been able to, over the years, without any trouble at all, pick up PL/I then PostScript then Object Pascal then C++ then Java then Scheme then Perl then Dylan (and probably a few I've forgotten) as I've gone along. What's the problem? They're all the same under the hood anyway, differing only in convenience. Hell, I'm pretty damn good at PowerPC and 68K assembler too, not just the PDP-11 and VAX and 6502 that I was taught on.
As for OSes. Well, I haven't used VMS for a long time, though apparently they're still selling it. I learned Unix at university (on a Zilog System 8000) and it really isn't all that different today, and if you knew Unix and RT-11 and CP/M then getting sufficiently lobotomised to operate MS-DOS wasn't all that hard, although it was pretty painful.
MacOS gave me a bit of a shock in 1984 (I was still at University then and we got a couple of the first model). Totally cool system and I swallowed the loose-leaf Inside Mac that year, though I wasn't able to start programming on it professionally until three years later in 1987.
If you know MacOS then getting sufficiently lobotomised to understand Windows 3.1 in 1991 or so wasn't all that hard, although it was certainly painful.
But most of what I learned at university wasn't about particular hardware, or particular operating systems, or particular programming languages. It was about the principles of those things, and of data structures and algorithms, and of database design, and software engineering, and computer graphics. Virtually every textbook I have from that time is not only still relevant but still respected! A later version of Aho and Ullman's compiler book is still universally known as "The Dragon Book". Foley and van Dam's graphics book will probably never go out of date. Speaking of which, Date is still today being updated and relevant to database design and theory. Tanenbaum's computer networks book still teaches the fundamentals even as TCP/IP takes over everything. Copi's Logic book is still as good as ever. Knuth is today finding a new generation of readers with a new edition.
I've never thrown away a single textbook I had in 1981 - 1984. I've never seen a reason to. And I'm not having any problems (at age 37) getting work on the very latest technology -- hell, I usually know it before the recent grads do, thanks to being alerted by the internet, and I certainly understand it and realise the limitations a lot better because of my experience.
About Sweeney's paper(truly excellent, incidentally), a couple things come to mind. He talks about the concept that "C=A+B" should be equivalent to C[n]=A[n]+B[n] -- in other words, take the first value of the A array, add it to the first value of the B array, and then put that in the first element of the C array. After all, that's what C=A+B obviously means, right?
This is exactly correct. There is no one "intuitive" meaning to "C=A+B" that beats out all others.
Fortunately, plenty of programming languages give you all the power to express any of the possible meanings concisely, without having to write lots of loops. I'll use Dylan for my examples, but you could as well use Scheme or SmallTalk. define variable B = #[1, 2, 3, 4]; define variable C = #[1, 10, 100, 1000]; ? map(\+, B, C); ==> #[2, 12, 103, 1004]
I don't know about that. Perl thinks C=A+B would expand to "C is the A list with the B list tacked on at the end". The add is one dimensional, not two dimensional--the two lists are glued together, not mixed into a sum. I think that's rather logical.
And what of another perfectly logical explanation? Maybe C is meant to be a single integer. Now you take all the ints in A, and all the ints in B, add 'em all up, and put 'em in that C value.
Of course, this ambiguity of what a simple "+" does isn't limited to "+". What might someone mean by "*"? C[n]=A[n]*B[n]? Dot product? Cross product? Multiply all the elements together? All are equally valid.
The solution isn't lots and lots of specialised operators. It's having easy ways to combine the operators we already have.
Some of the above examples might look inefficient, but in fact using a modern compiler they all compile down to the same simple loops that you would otherwise write by hand.
I don't believe it. I'm hearing this a lot, but it's not what I'm seeing myself.
Just this morning, the FedEx man arrived with a job and H1B offer for me in the USA. I'm nearly 38. I've got 15 years experience in programming and they've offered me a 6-figure salary, doing EJB, JSP and things like that -- none of which I've done (exactly) before. My (phone) interviews were full of "do you know X?". "No, but I know Y and Z, which are similar".
I just don't see any evidence for "anyone over 25 years old is obsolete" or slave wage rates being paid or unwillingness to do retraining or anything like that. Maybe I'm just blind, but everything I've seen indicates that $100k+ is still regarded as a good salary in the USA -- certainly the article that kicked off this discussion seemed to think that a couple earning six figures between them were doing OK. So, how am I being exploited? I'd really like to know before I sign...
I had a similar experience about ten years ago. Visiting a friend's place they had a puzzle that sounds similar -- squares with four turtle heads or tails on them and you had to match them. The only computer they had was a Mac Plus with Turbo Pascal. 45 minutes of coding and 10 seconds of runtime later, we had all the solutions.
Using this test, Pascal is a better prototyping language than is Haskell.
Oh, and that was on an 8 MHz Mac Plus. The runtime on a modern system would be undetectable.
Right. Here in NZ the big old universities had B6700's, but the new boy Waikato got a PDP11/70. I used that in 1981 and it ran about 40 - 50 users in 768 KB of core, on the RSTS/E oprating system.
By the next year we had a VAX 11/780 which ran about the same number of users in 1 MB or 1.5 MB (I forget) on VAX/VMS.
During the day both those systems were slloooowwww. But in the small hours with only half a dozen people using them they were really quite snappy -- certainly better than any PC you could get at the time.
You appear to be confusing a degree with a polytech course.
My partner (who is a classical pianist who did eight years of university study in music at one of the best conservatories in Russia) just finished a one year computer course at the local polytech. Yeah, it was all the sort fo stuff you list and will be obsolete in five years.
But my own Computer Science batchelor's degree is now sixteen years old and is in *no* way out of date. Sure, no one uses VAXes (let alone PDP-11's) any more, and Pascal, Modula-2, BCPL, COBOL, FranzLISP, and FORTRAN are getting pretty thin on the ground too. But that doesn't worry me at all. I've been able to, over the years, without any trouble at all, pick up PL/I then PostScript then Object Pascal then C++ then Java then Scheme then Perl then Dylan (and probably a few I've forgotten) as I've gone along. What's the problem? They're all the same under the hood anyway, differing only in convenience. Hell, I'm pretty damn good at PowerPC and 68K assembler too, not just the PDP-11 and VAX and 6502 that I was taught on.
As for OSes. Well, I haven't used VMS for a long time, though apparently they're still selling it. I learned Unix at university (on a Zilog System 8000) and it really isn't all that different today, and if you knew Unix and RT-11 and CP/M then getting sufficiently lobotomised to operate MS-DOS wasn't all that hard, although it was pretty painful.
MacOS gave me a bit of a shock in 1984 (I was still at University then and we got a couple of the first model). Totally cool system and I swallowed the loose-leaf Inside Mac that year, though I wasn't able to start programming on it professionally until three years later in 1987.
If you know MacOS then getting sufficiently lobotomised to understand Windows 3.1 in 1991 or so wasn't all that hard, although it was certainly painful.
But most of what I learned at university wasn't about particular hardware, or particular operating systems, or particular programming languages. It was about the principles of those things, and of data structures and algorithms, and of database design, and software engineering, and computer graphics. Virtually every textbook I have from that time is not only still relevant but still respected! A later version of Aho and Ullman's compiler book is still universally known as "The Dragon Book". Foley and van Dam's graphics book will probably never go out of date. Speaking of which, Date is still today being updated and relevant to database design and theory. Tanenbaum's computer networks book still teaches the fundamentals even as TCP/IP takes over everything. Copi's Logic book is still as good as ever. Knuth is today finding a new generation of readers with a new edition.
I've never thrown away a single textbook I had in 1981 - 1984. I've never seen a reason to. And I'm not having any problems (at age 37) getting work on the very latest technology -- hell, I usually know it before the recent grads do, thanks to being alerted by the internet, and I certainly understand it and realise the limitations a lot better because of my experience.
This is exactly correct. There is no one "intuitive" meaning to "C=A+B" that beats out all others.
Fortunately, plenty of programming languages give you all the power to express any of the possible meanings concisely, without having to write lots of loops. I'll use Dylan for my examples, but you could as well use Scheme or SmallTalk. define variable B = #[1, 2, 3, 4]; define variable C = #[1, 10, 100, 1000]; ? map(\+, B, C); ==> #[2, 12, 103, 1004]
I don't know about that. Perl thinks C=A+B would expand to "C is the A list with the B list tacked on at the end". The add is one dimensional, not two dimensional--the two lists are glued together, not mixed into a sum. I think that's rather logical.
? concatenate(B, C); ==> #[1, 2, 3, 4, 1, 10, 100, 1000]
And what of another perfectly logical explanation? Maybe C is meant to be a single integer. Now you take all the ints in A, and all the ints in B, add 'em all up, and put 'em in that C value.
Lots of ways to do this one...
? reduce(\+, 0, map(\+, B, C)); ==> 1121 ? reduce(\+, 0, B) + reduce(\+, 0, C); ==> 1121 ? apply(\+, map(curry(reduce, \+, 0), list(B, C))); ==> 1121 ? reduce(\+, 0, concatenate(B, C)); ==> 1121
Of course, this ambiguity of what a simple "+" does isn't limited to "+". What might someone mean by "*"? C[n]=A[n]*B[n]? Dot product? Cross product? Multiply all the elements together? All are equally valid.
The solution isn't lots and lots of specialised operators. It's having easy ways to combine the operators we already have.
Some of the above examples might look inefficient, but in fact using a modern compiler they all compile down to the same simple loops that you would otherwise write by hand.