It does provide a good contrast to doing the same thing using the power of a good functional notation: https://www.youtube.com/watch?...
- Conway's Game Of Life in APL - in less than 8 minutes.
When I started in professional computing in the early '80s, there were probably 30-40% women in areas where I worked. It isn't some kind of innate preference - that tired excuse that gets trotted out to justify any conservative position.
What's changed is this idea of "tracking", as soft as it is. It used to be that a philosophy major, like myself, or an English or history major would get a programming job because most schools did not even offer CS courses, much less CS majors. Now, there is this idea of a course of study along the lines of math and engineering that leads to a career with computers. It's not any one thing that accounts for this shift, but turning the decision to work with technology from a late-stage one to an earlier, long-term one probably doesn't help. It's now like a long corridor of slight but persistent bias - highly evident in the bitter, stupid comments in this discussion - that weeds out women from the field.
...when (leading-edge) schools were just starting to get computers. I found it to be good motivation that I was at the same level as the teachers. We were all in it together, learning this stuff for the first time.
...the U.S. changed its H-1B record retention policy last week, declaring that records used for labor certification, whether in paper or electronic, "are temporary records and subject to destruction" after five years under the new policy. "There was no explanation for the change, and it is perplexing to researchers," reports Computerworld.
"Perplexing to researchers" would not be perplexing to criminal investigators.
Clearly this would not have been a problem but for someone's ignorance of hyphenation. If the intent was to declare the network was free of "Al-Quida", the proper spelling would have been "Al-Quida-Free Terror Network", but someone with that level of sophistication would probably have spelled "Al-Qaeda" correctly as well.
This is the like the difference between "high-school boys" and "high school-boys".
So far, I don't think I've seen a single comment here that got the point of the essay.
He's not talking about incremental "improvements" to existing languages, he's pointing out that the common attitude of "we'll make this language easy to learn by making it look like C" is a poor way to achieve any substantial progress.
This is true but everyone who's invested a substantial amount of time learning the dominant, clumsy, descended-from-microcode paradigm is reluctant to dip a toe into anything requiring them to become a true novice again.
I've long been a big fan of what are now called "functional" languages like APL and J - wait, hold on - I know that started alarm bells ringing and red lights flashing for some of you - and find it painful to have to program in the crap languages that still dominate the programming eco-system. Oh look, another loop - let me guess, I'll have to set up the same boilerplate that I've done for every other loop because this language does not have a grammar to let me apply a function across an array. You want me to continue doing math by counting on my fingers when I've got an actual notation that handles arrays at a high level, but I can't use it because it's "too weird". (end rant)
There have been any number of studies - widely ignored in the CS world - going back decades (see this http://cacm.acm.org/magazines/...) - pointing out how poorly dominant programming memes mesh with the way most people think about problems and processes. Meanwhile, the 1960s called - they want their programming languages and debugging "techniques" back - "printf", anyone?
Not to troll, but the problem with restricting advertising is that you are restricting free speech. This is a legitimate concern: who makes the decisions and on what basis when you start down the path of "strictly factual"? It's not that simple. Any number of repressive governments across the globe have laws against publicizing "false" statements but these laws are clearly used to suppress anything they don't like.
Without having looked at the post or scrutinized the language, here's a couple of guesses: 1) looks like C: i.e. verbose, vacuous, loopy. 2) has crappy (i.e. industry-standard) array-handling. 3) fails to incorporate any of the decades of research about how people approach problems versus how programming languages do.
How much time do you waste with boilerplate crap like this because of nearly clumsy array-handling ideas that date back to the Great Flood? How bloated is code because of the vacuousness of most common languages that require several lines to do the simplest things?
Basing one's choice of language to learn on its current popularity - though this may be economically prudent - retards progress in programming languages almost as much as new languages' emphasis on backwards compatibility and ease of learning for novices.
"Backward compatibility" gives us the backward languages that predominate today. Making things easy for beginners gives us languages mostly only suitable for newbies.
Contrast this novice-oriented, backward-looking orientation with the little-understood idea that a language can be a tool of thought, that it can provide us with useful conceptual building blocks for thinking about computation at a high level.
If you follow the "Risks Digest" - formerly the "Risks in Computing" newslist - now in its 27th year, you'll see that one of the most common themes is the repetition of known bad practices.
"Live and don't learn" could be the official motto of the IT industry.
The facts are otherwise. Based on estimates at a talk I was at recently - see the latter part of this (pdf) http://www.orie.cornell.edu/en... - traditional asset management comprises about 20% of trading volume; HFT accounts for over 30% and hedge funds for more than 25%. There may be some HFT done at hedge funds as well, but it's clear that the tail is wagging the dog.
Good suggestion - much like a suggestion to apply a band-aid to a punctured artery.
You can follow these rules - and more - as rigorously as you please but still be undone by any number of simple things someone can do to a spreadsheet quite easily - like adding a row or column that looks like it's included in a calculation, but isn't.
I suffer the same incomprehension, except I've been using other interpreted environments throughout my career, but the idea is the same.
Compiled languages, though sometimes necessary, often substantially increase the difficulty of programming for no benefit whatsoever.
I understand this looks like flamebait, but I'm _only_ basing this on forty years of personal experience, so what the hell do I know? Since an example is worth a lot, here's one: I recently offered to help a colleague who's taking a C++ class and was reminded of all the unnecessary crap it takes to get even a very simple program to run at all. The problem was to build a Fahrenheit to Celsius (and vice-versa) temperature converter. It was friggin' painful - all the crap we had to put together to assemble even a simple, crappy program that is, at best, capable of doing one conversion at a time (and only a hard-coded little subset of them in an initial version).
The result was multiple source files, comprising a couple dozen lines of code, compiling to megabytes of peripheral files (in the debug version) - you know how this goes. In contrast, I write the Fahrenheit-to-Celsius conversion in a short, single line of my favorite interpreted environment (J), and am able to test it on multiple values at a time, instantly - taking seconds instead of hours. Moreover, J is smart enough that it has a built-in inverse construct to allow me to write the inverse function with another few seconds of effort.
I already hear the compiler-lovers muttering darkly about run-times and "large projects" - completely ignoring the first rule of optimization: find the bottleneck. Most code is - and should be - in small pieces that benefit from being tested quickly in small modules. The metric we should care about is "total time to completion" but this is harder to measure and more subjective than "run time", so we continue to focus on this latter measure to the detriment of productivity.
Slashdot Mirror
..is well-expressed on that site: https://www.youtube.com/watch?... - over 2 1/2 hours.
It does provide a good contrast to doing the same thing using the power of a good functional notation: https://www.youtube.com/watch?...
- Conway's Game Of Life in APL - in less than 8 minutes.
When I was a child, we used to find old light switches and break them open to play with the mercury in them. But it did eventually kill me.
When I started in professional computing in the early '80s, there were probably 30-40% women in areas where I worked. It isn't some kind of innate preference - that tired excuse that gets trotted out to justify any conservative position.
What's changed is this idea of "tracking", as soft as it is. It used to be that a philosophy major, like myself, or an English or history major would get a programming job because most schools did not even offer CS courses, much less CS majors. Now, there is this idea of a course of study along the lines of math and engineering that leads to a career with computers. It's not any one thing that accounts for this shift, but turning the decision to work with technology from a late-stage one to an earlier, long-term one probably doesn't help. It's now like a long corridor of slight but persistent bias - highly evident in the bitter, stupid comments in this discussion - that weeds out women from the field.
...when (leading-edge) schools were just starting to get computers. I found it to be good motivation that I was at the same level as the teachers. We were all in it together, learning this stuff for the first time.
...the Indian "Science" Conference ?
Carly will be the seventh dwarf.
"Perplexing to researchers" would not be perplexing to criminal investigators.
Clearly this would not have been a problem but for someone's ignorance of hyphenation. If the intent was to declare the network was free of "Al-Quida", the proper spelling would have been "Al-Quida-Free Terror Network", but someone with that level of sophistication would probably have spelled "Al-Qaeda" correctly as well.
This is the like the difference between "high-school boys" and "high school-boys".
So far, I don't think I've seen a single comment here that got the point of the essay.
He's not talking about incremental "improvements" to existing languages, he's pointing out that the common attitude of "we'll make this language easy to learn by making it look like C" is a poor way to achieve any substantial progress.
This is true but everyone who's invested a substantial amount of time learning the dominant, clumsy, descended-from-microcode paradigm is reluctant to dip a toe into anything requiring them to become a true novice again.
I've long been a big fan of what are now called "functional" languages like APL and J - wait, hold on - I know that started alarm bells ringing and red lights flashing for some of you - and find it painful to have to program in the crap languages that still dominate the programming eco-system. Oh look, another loop - let me guess, I'll have to set up the same boilerplate that I've done for every other loop because this language does not have a grammar to let me apply a function across an array. You want me to continue doing math by counting on my fingers when I've got an actual notation that handles arrays at a high level, but I can't use it because it's "too weird". (end rant)
There have been any number of studies - widely ignored in the CS world - going back decades (see this http://cacm.acm.org/magazines/...) - pointing out how poorly dominant programming memes mesh with the way most people think about problems and processes. Meanwhile, the 1960s called - they want their programming languages and debugging "techniques" back - "printf", anyone?
That might be your problem.
Not to troll, but the problem with restricting advertising is that you are restricting free speech. This is a legitimate concern: who makes the decisions and on what basis when you start down the path of "strictly factual"? It's not that simple. Any number of repressive governments across the globe have laws against publicizing "false" statements but these laws are clearly used to suppress anything they don't like.
Without having looked at the post or scrutinized the language, here's a couple of guesses:
1) looks like C: i.e. verbose, vacuous, loopy.
2) has crappy (i.e. industry-standard) array-handling.
3) fails to incorporate any of the decades of research about how people approach problems versus how programming languages do.
...especially with law firms specializing in personal injury.
...coming soon?
http://en.wikipedia.org/wiki/S...
Not according to the lack of imagination by the posters here I've seen so far.
How much time do you waste with boilerplate crap like this because of nearly clumsy array-handling ideas that date back to the Great Flood?
How bloated is code because of the vacuousness of most common languages that
require
several lines
to do
the simplest
things?
Basing one's choice of language to learn on its current popularity - though this may be economically prudent - retards progress in programming languages almost as much as new languages' emphasis on backwards compatibility and ease of learning for novices.
"Backward compatibility" gives us the backward languages that predominate today. Making things easy for beginners gives us languages mostly only suitable for newbies.
Contrast this novice-oriented, backward-looking orientation with the little-understood idea that a language can be a tool of thought, that it can provide us with useful conceptual building blocks for thinking about computation at a high level.
If you follow the "Risks Digest" - formerly the "Risks in Computing" newslist - now in its 27th year, you'll see that one of the most common themes is the repetition of known bad practices.
"Live and don't learn" could be the official motto of the IT industry.
How does this bullshit excuse apply to someone like me who's only child has graduated from college?
Clearly false:
http://www.npr.org/blogs/money...
and
http://www.debt.org/faqs/ameri...
...courtesy of xkcd: https://xkcd.com/1127/ .
The facts are otherwise. Based on estimates at a talk I was at recently - see the latter part of this (pdf) http://www.orie.cornell.edu/en... - traditional asset management comprises about 20% of trading volume; HFT accounts for over 30% and hedge funds for more than 25%. There may be some HFT done at hedge funds as well, but it's clear that the tail is wagging the dog.
So, you're talking about the Tea Party?
Good suggestion - much like a suggestion to apply a band-aid to a punctured artery.
You can follow these rules - and more - as rigorously as you please but still be undone by any number of simple things someone can do to a spreadsheet quite easily - like adding a row or column that looks like it's included in a calculation, but isn't.
I suffer the same incomprehension, except I've been using other interpreted environments throughout my career, but the idea is the same.
Compiled languages, though sometimes necessary, often substantially increase the difficulty of programming for no benefit whatsoever.
I understand this looks like flamebait, but I'm _only_ basing this on forty years of personal experience, so what the hell do I know? Since an example is worth a lot, here's one: I recently offered to help a colleague who's taking a C++ class and was reminded of all the unnecessary crap it takes to get even a very simple program to run at all. The problem was to build a Fahrenheit to Celsius (and vice-versa) temperature converter. It was friggin' painful - all the crap we had to put together to assemble even a simple, crappy program that is, at best, capable of doing
one
conversion
at
a
time
(and only a hard-coded little subset of them in an initial version).
The result was multiple source files, comprising a couple dozen lines of code, compiling to megabytes of peripheral files (in the debug version) - you know how this goes. In contrast, I write the Fahrenheit-to-Celsius conversion in a short, single line of my favorite interpreted environment (J), and am able to test it on multiple values at a time, instantly - taking seconds instead of hours. Moreover, J is smart enough that it has a built-in inverse construct to allow me to write the inverse function with another few seconds of effort.
I already hear the compiler-lovers muttering darkly about run-times and "large projects" - completely ignoring the first rule of optimization: find the bottleneck. Most code is - and should be - in small pieces that benefit from being tested quickly in small modules. The metric we should care about is "total time to completion" but this is harder to measure and more subjective than "run time", so we continue to focus on this latter measure to the detriment of productivity.
History?
Don't worry - it's a lot like a soul - if you don't have it, you'll never know.