The article says "free rein". The summary says "free reign". "Rein" is the "correct" term, although apparently folk usage of "reign" is moving up fast.
Implementing a minimal FORTH interpreter (actually a compiler to intermediate representation) might be simple, but a full-on ANSI FORTH interpreter is not so easy. I used to read comp.lang.forth and there were frequent postings from people who were trying to write their own interpreters who got stuck.
FORTH is also not the easiest language to learn, the addition example you mention being the least of the hurdles. FORTH is not fully postfix and when you get into creating words, things get hairy. I enjoyed using the language, but I think LISP or SCHEME would be easier to learn. (And, in my experience, SCHEME was easier to learn.)
And prior to 30 years ago, there were the Tiny BASICs espoused by Dr. Dobb's Journal of Tiny BASIC Calisthenics & Orthodontia - Running Light without Overbyte, which ran in 2KB.
I read one of Ariely's books recently (Predictably Irrational). He studies how real consumers make decisions, often irrational decisions, in contrast to traditional economics which assumes every consumer makes rational decisions. It was a very good book and the case studies made his point well.
Donald Knuth made a similar point to your last paragraph in his reply to the Gotos-Considered-Harmful article way back when. Good programmers will write structured code in any language, whether it allows gotos or not, whether it is a high-level language or assembly language. Conversely, bad programmers will write unstructured code in a language with only structured statements and no gotos.
(Disclaimer: I learned programming on a TI SR-56 programmable calculator and, later, a TI-58 programmable calculator. That experience didn't seem to hobble my later education and career in computers.)
Have you ever worked on non-trivial applications? I worked on satellite ground systems for 25 years, first in image processing and then in monitoring and control. The heavy-weight math was done by actual mathematicians; e.g., those who understood spherical geometry, etc. We programmers were basically moving data around; a smattering of basic math and basic statistics was involved and, yes, some discrete math. The math certainly had nothing to do with scaling applications; we were already processing high-speed data streams.
The Green Car Reports link in the summary confirms this partly (it doesn't name the vehicle):
"Work Funded: $169 million for engineering integration work on the Karma; $360 million for development of a mid-size extended-range electric vehicle, to be built in a former GM plant in Wilmington, Delaware"
... most MS-DOS developers picked TurboPascal in the 1980s. C came into wider use later on DOS platforms. I love C, but Algol 60 was also a thing of beauty. (I used Norwegian University Algol back in the late 1970s on our Univac mainframes at the University of Maryland; NU-Algol was a pleasure to work with.)
I think his name was Jonas, not Johan, Salk. And, in the U.S., we actually didn't and don't use his live-virus vaccine; we use some other guy's dead-virus vaccine that came out about the same time. But your point is well-taken.
Scott Adams once had a blog entry describing the best and worst jobs in the world: the best being a drone pilot scarfing down Doritos in the comfort of a command center and the worst being Al Qaeda's #2 in command (obviously written before OBL was killed).
Yes, those were the days. The cool thing about the Swinger was that, with flash, if you turned the distance down to the closest setting, you essentially had a pinhole camera with an infinite depth-of-field. I took a couple of close-up pictures of my model railroad layout this way - you know, kind of standing on the track with the train coming at you, all in focus. Wish I'd taken more advantage of it at the time, but I was a kid and film was expensive.
Yes, that happens all the time in the private sector. Now excuse me while I go read those postings about the HP tablet and the HP CEOs who've walked away with multi-million-dollar compensation packages.
"often unions funnel more money to candidates who favor them in lawmaking and negotiations"
Quick, let's make up a name for them... hmmm.... "Lobbyists"? Evil unions - you'd never see businessmen stooping to such tactics.
I liked WRITING SOLID CODE when it came out, but, for some inexplicable reason, Maguire made the same mistake (in one of the footnotes, IIRC) I had to keep correcting our company's GUI programmer about every six months. You've got a hierarchy of GUI objects; each object has two links, one to the first child and a second to the next sibling. Two links?! Why, we can use a binary-tree algorithm to traverse the tree. No, no, no - logically it is not a binary tree despite having two links in each node and performing a binary-tree traversal makes no sense (and potentially leads to a deep stack of recursive calls). That our company's GUI programmer would read Knuth every six months and regurgitate this idea didn't surprise me, but I expected better from one of Microsoft's supposed top programmers.
Not read as a beginning programmer, but OOSC is probably the best software engineering book I've ever read. First edition here too. I haven't looked at the second edition, but I imagine the increased size of the second edition dilutes its effectiveness.
When I got interested in computers back in the late 1970s, I read everything I could about different computer languages, including the standard COBOL book at the time (McCracken?). I finally got to use the language in a database class in college; it wasn't bad and had some nice features. A few years ago, our software group took a week-long course on CORBA and everyone, including the instructor but not including me, laughed when he mentioned that there was even a CORBA binding for COBOL. That's what you get when people think C++ is the peak of perfection and have little knowledge of or interest in other languages. (Many years ago, a professor with COBOL experience posted a complete 4-line COBOL program to sort a file on the comp.lang.c USENET news group. The program was portable to any COBOL system. The ENVIROMENT statements, etc. are all optional, hence the brevity of the program. No C program could match it - remember that exec("sort...") only works on UNIX systems.)
Yes, bad programmers are bad, but let's consider the more numerous average programmers who have no intuitive sense of objects and their code reflects that fact. A good C++ program can be a thing of beauty, but the average C++ code is not - and the complexities of C++ make it darn hard to maintain the large quantity of average C++ code. Average programmers also produce average code in other languages, but at least, with the simpler languages like C, you have more than a snowball's chance in heck of figuring out what the code does. Design patterns are great, but, in my experience are unknown outside a very few of the elite programmers. And then you get average maintenance programmers trying to make sense out of some elite programmer's design-pattern-based code. (Of course, as Lispers like to point out, the common design patterns are used to overcome shortcomings in languages like C++ and Java.)
In 2006, I wrote a not insignificant program in Guile - loved it. Added CORBA bindings to communicate with our other processes. The program calculated derived parameters from various satellite telemetry values (e.g., compute the sun angle based on 3 telemetry values). My manager blew a gasket when he found out that I had implemented it in this strange language. What else could I do - the spacecraft engineers had specified the equations for the over 800 derived parameters in a variant of Scheme! (The variation came in the fact that, where a telemetry point was referenced like a variable, the computation had to check the status flags of the telemetry point to determine whether to use it or not. Depending on the function being applied, a bad point would either be skipped or the calculation [or subexpression] would fail. It was a simple matter to read in the equations and rewrite them to correctly take into account the telemetry point references.)
The program was beautiful, extremely fast, and worked like a charm. It wasn't my fault that I was the only one in the company who could look at the spacecraft engineers' documentation and realize they were using Scheme. When I left the company the following year (with the code well-commented), I imagine my manager, who wasn't a bad programmer himself, probably leaped in and rewrote the whole thing in C++, hand-coding each and every one of those 800+ calculations.
Not to mention other countries that had or have no regulation - the Eastern European communist countries that turned out to be toxic dumps when opened to the West and let's not forget the London fog.
"... leaving us with not so viable alternative - the Opera."
I've been a happy Opera user (Linux and Windows both in the past, but now Windows mostly) for over 10 years - used to have to buy it, but well-worth its low price back then. FF is dirt slow on my old XP machine and IE8 seems equally slow; I only boot them up when a financial web site uses browser-specific pages. (For example, at work, I was one of the few Linux users and our electronic timecard system only worked in IE, so I purchased Crossover to run IE - booting up into Windows just to fill out my timecard was a non-trivial option, as has already been hashed out by work users in the recent "boot time" discussion.) I haven't been bitten by the Chrome bug since Opera has been lean and mean for all these years and I haven't found any need to change to a new browser.
Computing has, over the years, become more and more infested with math, but the two don't really mix when you get right down to it. (There's been a similar situation regarding math in econcomics; e.g., econometricians building models for mathematics sake rather than any economic reality they represent; there have even been calls for not requiring other than basic math courses for undergraduate economics majors.) I'm of the belief, first heard from one of the computer science greats - I can't remember who - that the ability to write clearly is more important to programming than any grounding in mathematics. If you can outline and compose a coherent argument in the written language of your choice, you'll probably be good programmer.
I don't think programmers are less capable now than earlier. There's just been a loss of connection between the software and the hardware. I happened to look at a piece of code a young programmer wrote in C++ to insert a 4-byte length field at the beginning of a file. A simple task, keeping in mind that the field had to be big-endian. This programmer, however, formatted the length value as an ASCII hex string, decoded the hex string 2 digits at a time to place the bytes into an array, and then wrote the 4-byte array out to the file. This solution boggled my mind!
As other posters have noted, I think it is because colleges teach using ever higher-level languages and are skimping on the lower-level architecture and operating systems courses. (On the other hand, we learned LISP and SNOBOL when I was in college, so high-level languages are not a bad thing; my own preferred languages are C and Scheme.)
Slashdot Mirror
The article says "free rein". The summary says "free reign". "Rein" is the "correct" term, although apparently folk usage of "reign" is moving up fast.
And the Republicans had majorities for the first 6 years ...
Implementing a minimal FORTH interpreter (actually a compiler to intermediate representation) might be simple, but a full-on ANSI FORTH interpreter is not so easy. I used to read comp.lang.forth and there were frequent postings from people who were trying to write their own interpreters who got stuck. FORTH is also not the easiest language to learn, the addition example you mention being the least of the hurdles. FORTH is not fully postfix and when you get into creating words, things get hairy. I enjoyed using the language, but I think LISP or SCHEME would be easier to learn. (And, in my experience, SCHEME was easier to learn.)
And prior to 30 years ago, there were the Tiny BASICs espoused by Dr. Dobb's Journal of Tiny BASIC Calisthenics & Orthodontia - Running Light without Overbyte, which ran in 2KB.
I read one of Ariely's books recently (Predictably Irrational). He studies how real consumers make decisions, often irrational decisions, in contrast to traditional economics which assumes every consumer makes rational decisions. It was a very good book and the case studies made his point well.
Donald Knuth made a similar point to your last paragraph in his reply to the Gotos-Considered-Harmful article way back when. Good programmers will write structured code in any language, whether it allows gotos or not, whether it is a high-level language or assembly language. Conversely, bad programmers will write unstructured code in a language with only structured statements and no gotos.
(Disclaimer: I learned programming on a TI SR-56 programmable calculator and, later, a TI-58 programmable calculator. That experience didn't seem to hobble my later education and career in computers.)
But that's the whole question, isn't it? What are the *relevant* "easily quantifiable measures"?
Have you ever worked on non-trivial applications? I worked on satellite ground systems for 25 years, first in image processing and then in monitoring and control. The heavy-weight math was done by actual mathematicians; e.g., those who understood spherical geometry, etc. We programmers were basically moving data around; a smattering of basic math and basic statistics was involved and, yes, some discrete math. The math certainly had nothing to do with scaling applications; we were already processing high-speed data streams.
The Green Car Reports link in the summary confirms this partly (it doesn't name the vehicle): "Work Funded: $169 million for engineering integration work on the Karma; $360 million for development of a mid-size extended-range electric vehicle, to be built in a former GM plant in Wilmington, Delaware"
... most MS-DOS developers picked TurboPascal in the 1980s. C came into wider use later on DOS platforms. I love C, but Algol 60 was also a thing of beauty. (I used Norwegian University Algol back in the late 1970s on our Univac mainframes at the University of Maryland; NU-Algol was a pleasure to work with.)
I think his name was Jonas, not Johan, Salk. And, in the U.S., we actually didn't and don't use his live-virus vaccine; we use some other guy's dead-virus vaccine that came out about the same time. But your point is well-taken.
Scott Adams once had a blog entry describing the best and worst jobs in the world: the best being a drone pilot scarfing down Doritos in the comfort of a command center and the worst being Al Qaeda's #2 in command (obviously written before OBL was killed).
Good one! :)
Yes, those were the days. The cool thing about the Swinger was that, with flash, if you turned the distance down to the closest setting, you essentially had a pinhole camera with an infinite depth-of-field. I took a couple of close-up pictures of my model railroad layout this way - you know, kind of standing on the track with the train coming at you, all in focus. Wish I'd taken more advantage of it at the time, but I was a kid and film was expensive.
"like firing for incompetence"
... hmmm .... "Lobbyists"? Evil unions - you'd never see businessmen stooping to such tactics.
Yes, that happens all the time in the private sector. Now excuse me while I go read those postings about the HP tablet and the HP CEOs who've walked away with multi-million-dollar compensation packages.
"often unions funnel more money to candidates who favor them in lawmaking and negotiations"
Quick, let's make up a name for them
I liked WRITING SOLID CODE when it came out, but, for some inexplicable reason, Maguire made the same mistake (in one of the footnotes, IIRC) I had to keep correcting our company's GUI programmer about every six months. You've got a hierarchy of GUI objects; each object has two links, one to the first child and a second to the next sibling. Two links?! Why, we can use a binary-tree algorithm to traverse the tree. No, no, no - logically it is not a binary tree despite having two links in each node and performing a binary-tree traversal makes no sense (and potentially leads to a deep stack of recursive calls). That our company's GUI programmer would read Knuth every six months and regurgitate this idea didn't surprise me, but I expected better from one of Microsoft's supposed top programmers.
Not read as a beginning programmer, but OOSC is probably the best software engineering book I've ever read. First edition here too. I haven't looked at the second edition, but I imagine the increased size of the second edition dilutes its effectiveness.
When I got interested in computers back in the late 1970s, I read everything I could about different computer languages, including the standard COBOL book at the time (McCracken?). I finally got to use the language in a database class in college; it wasn't bad and had some nice features. A few years ago, our software group took a week-long course on CORBA and everyone, including the instructor but not including me, laughed when he mentioned that there was even a CORBA binding for COBOL. That's what you get when people think C++ is the peak of perfection and have little knowledge of or interest in other languages. (Many years ago, a professor with COBOL experience posted a complete 4-line COBOL program to sort a file on the comp.lang.c USENET news group. The program was portable to any COBOL system. The ENVIROMENT statements, etc. are all optional, hence the brevity of the program. No C program could match it - remember that exec("sort ...") only works on UNIX systems.)
Yes, bad programmers are bad, but let's consider the more numerous average programmers who have no intuitive sense of objects and their code reflects that fact. A good C++ program can be a thing of beauty, but the average C++ code is not - and the complexities of C++ make it darn hard to maintain the large quantity of average C++ code. Average programmers also produce average code in other languages, but at least, with the simpler languages like C, you have more than a snowball's chance in heck of figuring out what the code does. Design patterns are great, but, in my experience are unknown outside a very few of the elite programmers. And then you get average maintenance programmers trying to make sense out of some elite programmer's design-pattern-based code. (Of course, as Lispers like to point out, the common design patterns are used to overcome shortcomings in languages like C++ and Java.)
In 2006, I wrote a not insignificant program in Guile - loved it. Added CORBA bindings to communicate with our other processes. The program calculated derived parameters from various satellite telemetry values (e.g., compute the sun angle based on 3 telemetry values). My manager blew a gasket when he found out that I had implemented it in this strange language. What else could I do - the spacecraft engineers had specified the equations for the over 800 derived parameters in a variant of Scheme! (The variation came in the fact that, where a telemetry point was referenced like a variable, the computation had to check the status flags of the telemetry point to determine whether to use it or not. Depending on the function being applied, a bad point would either be skipped or the calculation [or subexpression] would fail. It was a simple matter to read in the equations and rewrite them to correctly take into account the telemetry point references.)
The program was beautiful, extremely fast, and worked like a charm. It wasn't my fault that I was the only one in the company who could look at the spacecraft engineers' documentation and realize they were using Scheme. When I left the company the following year (with the code well-commented), I imagine my manager, who wasn't a bad programmer himself, probably leaped in and rewrote the whole thing in C++, hand-coding each and every one of those 800+ calculations.
Not to mention other countries that had or have no regulation - the Eastern European communist countries that turned out to be toxic dumps when opened to the West and let's not forget the London fog.
And we all know that businessmen, honest to a fault one and all, would never weight the scales in their favor.
"... leaving us with not so viable alternative - the Opera."
I've been a happy Opera user (Linux and Windows both in the past, but now Windows mostly) for over 10 years - used to have to buy it, but well-worth its low price back then. FF is dirt slow on my old XP machine and IE8 seems equally slow; I only boot them up when a financial web site uses browser-specific pages. (For example, at work, I was one of the few Linux users and our electronic timecard system only worked in IE, so I purchased Crossover to run IE - booting up into Windows just to fill out my timecard was a non-trivial option, as has already been hashed out by work users in the recent "boot time" discussion.) I haven't been bitten by the Chrome bug since Opera has been lean and mean for all these years and I haven't found any need to change to a new browser.
Computing has, over the years, become more and more infested with math, but the two don't really mix when you get right down to it. (There's been a similar situation regarding math in econcomics; e.g., econometricians building models for mathematics sake rather than any economic reality they represent; there have even been calls for not requiring other than basic math courses for undergraduate economics majors.) I'm of the belief, first heard from one of the computer science greats - I can't remember who - that the ability to write clearly is more important to programming than any grounding in mathematics. If you can outline and compose a coherent argument in the written language of your choice, you'll probably be good programmer.
I don't think programmers are less capable now than earlier. There's just been a loss of connection between the software and the hardware. I happened to look at a piece of code a young programmer wrote in C++ to insert a 4-byte length field at the beginning of a file. A simple task, keeping in mind that the field had to be big-endian. This programmer, however, formatted the length value as an ASCII hex string, decoded the hex string 2 digits at a time to place the bytes into an array, and then wrote the 4-byte array out to the file. This solution boggled my mind!
As other posters have noted, I think it is because colleges teach using ever higher-level languages and are skimping on the lower-level architecture and operating systems courses. (On the other hand, we learned LISP and SNOBOL when I was in college, so high-level languages are not a bad thing; my own preferred languages are C and Scheme.)