My first C++ book, 'A Computer Science Tapestry', had a page dedicated to her that has stuck with me since I read it in highschool.
Grace Hopper "was a proponent of innovative thinking and kept a clock on her desk that ran counterclockwise to show that things could be done differently. Although very proud of her career in the Navy, Hopper had little tolerance for bureaucracies, saying:
It’s better to show that something can be done and apologize for not asking permission, than to try to persuade the powers that be at the beginning.”
The reason I became a programmer. Grace -> COBOL -> My father -> Me. In the basement, pecking away at tiny green monochrome screen and loading 8" floppy drives on Cromemco Systems-3, COBOL was the first language I tried to learn, wee age of 12. Although, honestly I don't think I ever grokked it as much as the simpler language put forth in thy little white book on my father's bookshelf by fellows K&R.
She was back from the era when most computer programmers were female. Until late 1940s, the word "computer" meant a clerk who used did long clculations by hand or adding machine. These were mainly mathematical tables or military operations. Some of these women transitioned into programing jobs when the first programmable digital computers began in the late 1940s. Programming was either switchboard rewiring or punch cards/tape then.
Having recently met a soon-to-be retiring COBOL programmer, he talked about how much money there is in it because the work force is aging out and there aren't any people to replace them. It got me thinking that ultimately it was the culture of COBOL that killed it.
C was first and foremost designed to be a very portable language (for the early 70s). I think its endurance is largely attributable to this fact, that C was the first relatively easy to configure and deploy widespread throughout the world. It's difficult to imagine anything like Unix happening without C.
But COBOL on the other hand is written essentially in a vacuum. It's written in relatively closed environments, for closed systems, for closed purposes. You don't share COBOL code because, well, for the most part there isn't anything worth sharing, it's all to purpose specific.
And I think we see this in other places. Arduino is not the best, or cheapest, MCU hardware. But it's the easiest for which users can share code with each other. The "sketch" mentality for Arduino code has led to an explosion of copy-pasta examples across the net, and they are easy to integrate into one's own sketches on one's own hardware. Compare that to the TI MSP430 (which I personally think is every bit as good as the Arduino Uno, at a quarter of the price), pre-Energia, and it's a night and day difference.
Did the Web take off because it was fundamentally great, or was it because you could "view source" on any page? I spent hours in highschool, looking at other people's HTML and JS (but not CSS! It didn't exist yet!) on their sites. Saving their sites, hacking at the code (hacking as in "what one does with a machete"). Compare that to AOL and its keyword system.
So perhaps the lesson is: if your system doesn't encourage remixing, it's ultimately doomed to failure.
if your system doesn't encourage remixing, it's ultimately doomed to failure.
However, never forget that the market for IT can stay irrational longer than you can stay patient. Cobol is more than fifty years old. People are still emailing Word files to each other. And the post popular gaming systems are still closed consoles.
COBOL predates SQL by about 15 years. In the 60s and early 70s, there was a school of thought that programming languages could be made more like written languages, and that this would make it easier for the programmer to reason about programs, especially in the business context where companies were starving for programmers, companies who saw the university system as focusing too narrowly on academic theory. We get BASIC in the interim between COBOL and SQL as well. COBOL, BASIC, and SQL were all designed with non-Computer Scientists in mind, for "practical" applications.
At the very least, I think it's an unnecessary context-switch. Why introduce yet another language in your toolchain? The boss isn't going to be able to understand the natural language tests, because s/he will be introducing their own assumptions to the ambiguous nature of human language. Like how non-programmers tend to use "or" to mean "exclusive-or". Or the plethora of issues that come up when assuming N-based indexing when you actually have (1 - N)-based indexing (for values of N that are either 0 or 1).
And, personally, the wordiness just gets in the way, at least for me. Extra words just means I can make more mistakes. I truly despise these languages that seem forgiving yet have more rules that more concise, orderly ones (any other ones).
Yes, that is certainly the case. Sure, you make the programming language easier to understand for someone in their first week of learning it, but overall it ultimately slows everything down. That's probably why the concept has never really taken off. "The proof is in the pudding".
That said, I sometimes wonder what programming in such a verbose language with a sufficiently intelligent IntelliSense system would be like. I accidentally started a small, thumbnail project in VB.NET the other day, because I had just re-installed Visual Studio and had forgotten that it defaults project templates to VB on first-run. Instead of starting over, I thought I'd use it as a chance to check in on VB and see what it has become.
Some things really pissed me off. Block delineation with Begin/End is a pain in the ass. Generic parameter lists being grouped in round parens was extremely confusing. But otherwise the extra wordiness was almost completely obviated by the editor. It was a very odd experience.
I don't like the Python-style of significant white-space, because I think formatting of code should be the job of the editor, and the compiler or interpreter shouldn't care about layout. However, I've been very curious to see new experiments in making code more readable. LightTable (http://www.lighttable.com/) looks very interesting, with it's ability to (supposedly) group sections of code in arbitrary locations on the screen. I haven't yet figured out how to make it do it. I started using it on Windows and Linux for a Node.js project I'm working on, and it was definitely an interesting concept, but I couldn't seem to get it to work just right, or anywhere near what the demo suggested would be possible. That said, it was still quite easy on the eyes, so I find myself still using even if it isn't working 100% yet.
Racket has some interesting things going for it with code flow visualizations. The UI stuff is kind of fiddly on Linux, and the utility of reference arrows seems dubious at best, at least in their current implementation. But the macro expander is pretty amazing.
Ultimately, I think it's going to take a bit of new editor design, a bit of new language design.
Where does it say in the leaks that Google was providing the access?
That the NSA had access wasn't because Google was providing it. The NSA got access through some shady practices. They have access to all the files when the NSA can listen in on all the traffic. Not because Google gave them permission.
Very irritating when you claim something with a source when the source counters your own point:
> "If they are doing this, they are doing it without our knowledge," one said.
It's totally relevant. You implied that Google is wasting their time with doodles rather than these privacy issues. If they're not creating said doodles themselves, then they're not wasting their time.
You literally created your account 12 minutes ago just to bash Google?
Google is not just posting doodles on the front page. Last time I heard they also have a browser. So they can shift those percentages, and by helping APNG, they can help themselves: their front-page will load faster. It's a win-win.
Lossy wouldn't look bad, it's just not a direct comparison :) Here are 3 files: a lossless WebP and two lossy ones with max and min quality settings https://www.dropbox.com/sh/q1jqoru5ljtq9on/P2ELh8NkA6?lst The lossless one is slightly bigger than the GIF which I did not expect. The high-quality lossy one is obviously overkill and is huge! The low-quality lossy one is smaller but looks like crap.