3 ms·

I think this quote from an ACM interview with Donald Knuth in answer to a question on the future of programming sums up the problem of the current state of prog

by gcheong 18y ago

I think this quote from an ACM interview with Donald Knuth in answer to a question on the future of programming sums up the problem of the current state of programming nicely: "I'm worried about the present state of programming. Programmers now are supposed to mostly just use libraries. Programmers aren't allowed to do their own thing from scratch anymore. They're supposed to assemble reusable code that somebody else has written. There's a bunch of things on the menu and you choose from these and put them together. Where's the fun in that? Where's the beauty in that? We have to figure out a way we can make programming interesting for the next generation of programmers." reference: http://portal.acm.org/citation.cfm?id=1378715 http://portal.acm.org/citation.cfm?id=1378715

potatolicious 18y ago
Typical bottom-up thinking. While I do enjoy rolling my own libs from scratch from time to time, the availability of a lot of reusable, well-documented, well-designed code have permitted me to tackle, as a single person, projects that would not have been possible years ago. I wanted to create a 3D data visualization app just for kicks a while back. Guess what, I didn't have to roll my own OpenGL graphics libs, nor my XML parser, but I still had a blast putting it all together, and being able to focus on UI (the main motivator for the project) instead of the nitty gritty behind the scenes. I think it's valid to have some concern about coders becoming less capable at low-level code-from-scratch principles, but I don't think it's fair to say that the library-centric development today is less fun.
- derefr 18y ago
  Knuth thinks in algorithms, not solutions. In his day, people were constantly inventing new algorithms--if you've never done it before, you should at least be able to guess that it's a big rush. That's what Knuth thinks of programming as: a series of completely new inventions and associated rushes. What he's actually trying to say was that, as a usefully large number of algorithms for everyday tasks have already been discovered (optimally, even!) and codified into "libraries", people are running out of (easy) things to invent, and so aren't getting that rush as often. What was needed, in his mind, was a replacement for the rush, as that was what he saw as the raison d'etre of programming; being a mathematician himself, it was probably the only reason he programmed at all! Of course, we've gotten on just fine without the rush. "Programming" as solving problems has continued to flourish; Knuth's "programming"--really referring to the scientific method applied, as it should be, to Computer Science--has quieted. It used to be that every programmer was a practicing computer scientist by necessity, just as every astronaut is currently an astrophysicist by necessity. When "platforms of discovery" (computers being one, the vacuum of space being another) mature, the need (or ability) for their practitioners to be involved in the creation of the theory underlying the field diminishes. This doesn't mean the field "dies"--it merely segregates.
sd 18y ago
Remember that this is about teaching students to program and not about producing code for a business on deadline. I learned much more about how to program by doing things myself from scratch than using the relevant libraries. Also, I find learning the low-level stuff much more interesting that memorizing libraries and reading documentation.
Tamerlin 18y ago
That sounds about right. The programming tasks most of us get are trivial, but we end up spending an egregious amount of time on integration and configuration, so the projects still take a long time to complete, and the technical challenges we have time to deal with are rarely all that interesting. (My current position is to some extent an exception, though I'm finding that getting things done in Java with its various bloatware frameworks takes a LOT more time and effort than in most other languages/platforms, including .NET.)
hs 18y ago
i looked up a sample code for single file upload, tweaking it to handle corner cases; however, there's a cgi library for that shrug ... better, simpler but as a bonus, i now know http request better :D ... extending the cgi library, for example, uploading multiple files in one http request library also has another use, for testing for example, i got stuck char used as separator/ending in netstring, used in lighttpd's scgi i looked at python scgi library source code, saw the output scgi variables etc, then readjust my porting code but i strongly agree that building something from scratch is tremendously rewarding ... no matter how crappy it's - there's a beauty only u got the priviledge to enjoy ... FUN!

by gcheong 18y ago

potatolicious 18y ago

Typical bottom-up thinking. While I do enjoy rolling my own libs from scratch from time to time, the availability of a lot of reusable, well-documented, well-designed code have permitted me to tackle, as a single person, projects that would not have been possible years ago. I wanted to create a 3D data visualization app just for kicks a while back. Guess what, I didn't have to roll my own OpenGL graphics libs, nor my XML parser, but I still had a blast putting it all together, and being able to focus on UI (the main motivator for the project) instead of the nitty gritty behind the scenes. I think it's valid to have some concern about coders becoming less capable at low-level code-from-scratch principles, but I don't think it's fair to say that the library-centric development today is less fun.

derefr 18y ago
Knuth thinks in algorithms, not solutions. In his day, people were constantly inventing new algorithms--if you've never done it before, you should at least be able to guess that it's a big rush. That's what Knuth thinks of programming as: a series of completely new inventions and associated rushes. What he's actually trying to say was that, as a usefully large number of algorithms for everyday tasks have already been discovered (optimally, even!) and codified into "libraries", people are running out of (easy) things to invent, and so aren't getting that rush as often. What was needed, in his mind, was a replacement for the rush, as that was what he saw as the raison d'etre of programming; being a mathematician himself, it was probably the only reason he programmed at all! Of course, we've gotten on just fine without the rush. "Programming" as solving problems has continued to flourish; Knuth's "programming"--really referring to the scientific method applied, as it should be, to Computer Science--has quieted. It used to be that every programmer was a practicing computer scientist by necessity, just as every astronaut is currently an astrophysicist by necessity. When "platforms of discovery" (computers being one, the vacuum of space being another) mature, the need (or ability) for their practitioners to be involved in the creation of the theory underlying the field diminishes. This doesn't mean the field "dies"--it merely segregates.

sd 18y ago

Remember that this is about teaching students to program and not about producing code for a business on deadline. I learned much more about how to program by doing things myself from scratch than using the relevant libraries. Also, I find learning the low-level stuff much more interesting that memorizing libraries and reading documentation.

Tamerlin 18y ago

That sounds about right. The programming tasks most of us get are trivial, but we end up spending an egregious amount of time on integration and configuration, so the projects still take a long time to complete, and the technical challenges we have time to deal with are rarely all that interesting. (My current position is to some extent an exception, though I'm finding that getting things done in Java with its various bloatware frameworks takes a LOT more time and effort than in most other languages/platforms, including .NET.)

hs 18y ago

i looked up a sample code for single file upload, tweaking it to handle corner cases; however, there's a cgi library for that shrug ... better, simpler but as a bonus, i now know http request better :D ... extending the cgi library, for example, uploading multiple files in one http request library also has another use, for testing for example, i got stuck char used as separator/ending in netstring, used in lighttpd's scgi i looked at python scgi library source code, saw the output scgi variables etc, then readjust my porting code but i strongly agree that building something from scratch is tremendously rewarding ... no matter how crappy it's - there's a beauty only u got the priviledge to enjoy ... FUN!