Knuth: Computer Programming as an Art (1974)
91–100 of 110 posts
Re: Knuth: Computer Programming as an Art (1974)
#92Earlier quoted context omitted.
Michelangelo was working with chisel, colors, palette - was he a craftsman? How about guys that were replicating his work? They would have been closer to the 'craftmanship' side. Programming is art for many of us. For some it's a craft. If you are original and independent thinker in our profession, have creative ideas nobody had prior to you, you are much closer to an artist. If you just reuse what somebody else crea…
> if you are original and independent thinker You equate art with originality, but Knuth do not, and most arts except "Contemporary Art" did not either. Just turn your eyes to Quattrocento or Chinese landscapes: these artists are not trying to invent something or be original. Listen to Bach: where is the inventions? It is just a natural flow of notes in a structuring harmonic frame. I do not imagine Bach thinking "Le…
My view is that most people that view programming as a craft are middle managers that somehow need to get ants working on whatever they need. However if your innate inspiration comes from somewhere else, if you "feel" the algorithms and their optimality, wake up during nights when inspiration knocks on your the door of your mind to start working on an idea you just saw with your inner eye, you won't view programming as a craft at all.
Re: Knuth: Computer Programming as an Art (1974)
#93Earlier quoted context omitted.
I am tempted to write: "what part isn't?" Seriously, just about everything we do in computer science is experimentation, at least if it involves... physical computers . Every time we run a program, we run an experiment. At least if we have some expectation of what we want the program to do. Every time we write a test, or run a test suite, we are running an experiment. Every time we implement some sort of abstraction,…
> at least if it involves...physical computers. Yeah you "explore stuff" in any field. Science, art, math, every day life, when learning a craft (welding etc). Just because you explore doesn't mean that is what the core of what computer science is. > Every time we implement some sort of abstraction, every time we vary a parameter, every time we optimize a program, we are running experiments. Ok, what in life then isn…
And you do experiments in many fields!
"An experiment is a procedure carried out to verify, refute, or establish the validity of a hypothesis. Experiments provide insight into cause-and-effect by demonstrating what outcome occurs when a particular factor is manipulated. Experiments vary greatly in goal and scale, but always rely on repeatable procedure and logical analysis of the results."
https://en.wikipedia.org/wiki/Experiment
Particularly debugging, if you aren't completely random, usually takes on the form of repeated experiments.
http://c2.com/cgi/wiki?DebuggingAndTheScientificMethod
I have done a lot of performance work in my career, and there you run experiments almost continuously. At least you do if you actually want to have an effect. Admittedly, many people try to optimize without running experiments. That tends to not be very effective.
And yes, computer systems are easily sufficiently complex that reasoning it out ahead of time without running the experiment tends to be completely futile except for the most trivial arrangements. In fact, even in some situations that seem completely trivial.
> I am going to buy milk -- it's an experiment to see what happens.
If you have a hypothesis and you're trying to find out if it is true or not, sure, that can be an experiment. Usually it probably won't be.
> I am drinking coffee in the morning, it's an experiment to see if it will still keep me awake.
That certainly can be an experiment, for example if you vary the amount of coffee to see how much of will be keep you awake. Though it seems unlikely that you will be isolating the variables sufficiently. With computers, isolating the variables is often a lot simpler.
> By that token we've diluted the word science to not really mean anything anymore.
Going with your straw-men: probably.
Re: Knuth: Computer Programming as an Art (1974)
#94Re: Knuth: Computer Programming as an Art (1974)
#95Earlier quoted context omitted.
> at least if it involves...physical computers. Yeah you "explore stuff" in any field. Science, art, math, every day life, when learning a craft (welding etc). Just because you explore doesn't mean that is what the core of what computer science is. > Every time we implement some sort of abstraction, every time we vary a parameter, every time we optimize a program, we are running experiments. Ok, what in life then isn…
> Yeah you "explore stuff" in any field. And you do experiments in many fields! "An experiment is a procedure carried out to verify, refute, or establish the validity of a hypothesis. Experiments provide insight into cause-and-effect by demonstrating what outcome occurs when a particular factor is manipulated. Experiments vary greatly in goal and scale, but always rely on repeatable procedure and logical analysis of…
See you are proving my own point. Just because you do exploratory stuff and run "experiments" that doesn't make what you science. What isn't science then?
> I have done a lot of performance work in my career, and there you run experiments almost continuously
Yes me too. But I am not a scientist like Einstein.
There is a stretch in going from I am debugging some program and trying various things to saying I am a scientist.
You can sure call yourself a scientist but you have to explore why you want to do that. Is to make yourself feel better because the word "programmer" is boring or implies a lower status. What about craftsman, you are" crafting software" is that imply something undesirable, if so why? What about business problem solver?
Licensed engineers even scoff at software "engineers" even calling themselves "engineers" (even though what most computer scientist do is kind of like engineering), because they don't have a license etc.
Re: Knuth: Computer Programming as an Art (1974)
#96"How did they develop their skill? The best film makers through the years usually seem to have learned their art in comparatively primitive circumstances, often in other countries with a limited movie industry. And in recent years the most important things we have been learning about programming seem to have originated with people who did not have access to very large computers. The moral of this story, it seems to m…
I think you're mixing up the intended use of the "toy project," i.e. skill development, with the complexity of a real world project with a growing number of use cases, including a proliferating number of mobile devices and features –– just something to keep in mind.
Re: Knuth: Computer Programming as an Art (1974)
#97Herzog: Never. All I've ever wanted to be is a foot soldier of cinema.
Re: Knuth: Computer Programming as an Art (1974)
#98I lived the day to see YC giving credit to PG for an article written by Knuth. What's next? Symphony No. 9 by Paul Graham? Theory of Relativity by Paul Graham? The Bible? :-)
Re: Knuth: Computer Programming as an Art (1974)
#99Programming is much more of a craft than it is either an art or a science. Good craftsmanship combines beauty with utility, as does good coding. Programmers work with abstractions, rather than with wood or clay. And their craft is as cerebral and intellectually demanding as an art or a science. But it's still a craft.
The way I tend to picture roles in software is in analogy to my old job in aerospace. We have scientists/researchers who focus on the theoretical aspects. We have engineers who have a reasonable understanding of the theoretical aspects and tend to work in the design space. And we have craftsmen/technicians who have a reasonable understanding of design and tend to spend most of their time coding. A sort of pastime of…
Consequently, Haskell is one of the few places where any interesting progress is being made in the field of programming. The pure theoreticals continue spinning off into ever-more-rarified lands of type theory that are already all but impossible to use in practice, and the practicals are stuck shuffling around the same things over and over again in the same basic languages they've had since the late 1990s, just with a few more fancier curlicues added. (Every once in a while they'll import an idea from the academic side, but not without pretending they came up with it on their own while still sneering at the very thought that maybe if one thing was useful from over there, other things might be useful too....)
(Rust may someday also be an exception, though I'm currently unsure whether Rust's community will make progress in the general field of programming, or whether they'll make Rust-specific progress. A certain amount of Rust-specific progress is required either way before we can tell.)
Re: Knuth: Computer Programming as an Art (1974)
#100Why is it that "it's more art than science" gets so much use, whereas "it's more science than art" is never used? We use the former to explain why a given process is not deterministic -- for example, appraising artwork, drafting a business plan. Why is it never necessary to explain that a process is deterministic?