On the subject of art and programming, I really like how Fred Brooks described it in "The Mythical Man-Month":
The delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of imagination. Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself.
Bertrand Russell also had this to say: Mathematics, rightly viewed, possesses not only truth, but supreme beauty—a beauty cold and austere, like that of sculpture, without appeal to any part of our weaker nature, without the gorgeous trappings of painting or music, yet sublimely pure, and capable of a stern perfection such as only the greatest art can show.
I think this could equally be said for computer programming, except it is given life. We can see theory animated.
Programming 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 mine is to follow arguments on technical subjects and see if I can see these groups talking at cross purposes because they see the world from their perspective. Although if it relates to Haskell I don't bother as it's a gimme.
Where I do see a difference between software and aerospace is that, in software, there's a more noticeable feeling of hierarchy. To paraphrase: Haskellers look down on C programmers look down on Javascript programmers (like some sort of geeks' That Was The Week That Was sketch).
Maybe it was like this in aero too (I was quite young). What I do know is that I was in awe of the skills of the crafties I worked with. Unless you've watched a chap spray paint a propeller to a finer tolerance than a purpose built robot, you only have a partial understanding of the word exquisite.
The reason I find Haskell interesting is precisely that it's the only place I know where the theoretically-minded and the practically-minded get together and interpollinate. Everywhere else the one group pretty much just sneers at the other. If it doesn't always go 100% smoothly in Haskell-land, well, it's not as if we collectively have a lot of practice in getting along across that boundary.
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.)
Very insightful comment, thanks. I've never thought of things that way before. I guess the practice/theory intersection explains what I find so appealing about Haskell.
In CS you build abstractions on top of binary data and binary data operations. Who says I can't build abstractions on top of wood or clay? What is the true nature of an "abstraction"? What is a computer?
We try to create this machine that does things that exist only in the virtual world. Abstract operations and abstract data are the primitives or so it seems. The problem is these constructs are limited. We cannot have an unlimited amount of data nor can we have an unlimited amount of computing speed.
Why is this supposedly purely virtual abstraction limited? Because nothing can be purely virtual. Abstract data and procedure are both in itself abstractions on top of physical objects that are limited by the laws of the physical world (aka the laws of physics). There is a deeper physical primitive that exists underneath this abstraction we call information. Every virtual bit in a computer is an abstraction on top of this physical primitive.
What is this primitive?: silicon, aka Clay (SiO2).
So in short, if computers are artistic clay sculptures, then programmers are working with clay. Thus every time you program you are doing "arts and crafts." Programmers are both artists and craftsmen, the terms are one and the same.
I think this is a confusing essay, because in everyday speech "art" is employed to mean something very different from "an art" and we get lost in semantics. The continued references to obsolete definitions confuse things further.
In practice, the phrase "an art" is usually used in the same way as "an artform", as it is not meant to be taken literally; a commentator may say "there's a real art to mastering the offside trap" in football, but he does not mean that the defender should be put in a glass case in a contemporary art gallery.
The whole art/science classification of programming appears to me to be people defending their philosophy or encampment. If you're working in formal methods, you're likely to say "it's about the science", but if you're hacking the last cycle out of a console processor in the games industry you might say "wow, that was really clever, it's really an art this isn't it?"
I'd say both of these views are daft. "Science" is usually synonymous with Physics/Chemistry/Biology, which are inescapably different from programming or Computer Science. Similarly, fine arts is not isomorphic to programming.
What we usually do is much more like a craft. Sure, it has elements of engineering and maths, and in CS research we borrow some of the scientific method some of the time, but you could probably say the same about any craft, e.g. making jewellery, pottery, etc.
All crafts can strive for both beauty and utility, and can borrow from scientific methods and engineering when appropriate, but "pure" science or "pure" art they ain't. There's no ground truth in craft, and there's a strong degree of utility, which precludes it from being science or art respectively.
I've heard this discussion dozens of times. Always the mathematicians want CS to be a science, and the hackers want it to be an art or maybe engineering, but I think the argument is counter-productive. Programming is quite unique, but if you really want a relative description, it's kinda like a craft that uses certain maths and engineering in places.
I think dropping "science" from "Computer Science" would help immeasurably. Simply renaming a university department to "Computing" might stop students and staff worrying what they are.
I agree, but I'll go further than you - I don't think this essay is confusing at all. It's simply nonsense - the kind of thing someone clever writes when they're discussing a subject completely outside their area of competence.
CS can be a craft. It's not one of the arts, not even if it's beautifully put together, because the arts are not primarily about technique - they're about capturing and distilling human experiences using allusions and associations to (re)create those experiences. Fluent technique is a useful tool that help with that, but it's not the point.
(Modern art is a bit more limited than that, but that's more or less what art meant for most of Western history.)
The experiences created by the most timeless art are focused, but also ambiguous and complicated. You can get lost in them, and although there's often a clear theme, you can't define the rest of what's happening with absolute final precision.
That's almost exactly the opposite of what good code does. Which is why "That's a clever, clean solution" is an experience that exists in the craftsman's world, and is either peripheral or completely absent from an artist's view.
>I think dropping "science" from "Computer Science" would help immeasurably.
At my university the joke was always that it should be called "Computer Studies." Only a nugget of algorithmic research is genuinely scientific, and that lives in a tiny corner of the rest of the Pure Math. There could be a lot more formal provability, but going down that route would put a lot of programmers out of work, because the level of difficulty is much higher than that needed to crank out some JavaScript.
What's left is usually neither rigorous nor beautiful.
To which I reply: Did you actually read the essay? Since you started the ad hominem argument, I feel free to continue in that vein.
What is interesting is that most "programming" is exactly "capturing and distilling human experiences using allusions and associations to (re)create those experiences". What else is coding a front-end to an application that saves time and/or labour, and/or makes possible things that were, before the program, impossible? An Art, a Craft or a Science? From your very definition, "Art" would be the answer.
And yet, you begin your criticism with "It's simply nonsense"
> I agree, but I'll go further than you - I don't think this essay is confusing at all. It's simply nonsense - the kind of thing someone clever writes when they're discussing a subject completely outside their area of competence.
Whilst I know a little about art, I'm not confident enough in my own experience to put it so strongly.
> because the arts are not primarily about technique
Agreed. I think your subsequent definition of art is a brave one! It's difficult to define, but I get where you're coming from. As you hint at in the subsequent paragraph.
> What's left is usually neither rigorous nor beautiful.
A bit harsh! But yes, there's a large body in the middle that just gets things done.
Sounds like you may be immersed in the arts world, and I've already cited these before, but you may enjoy the Grayson Perry lectures if you haven't listened to them already. I found them refreshingly straight-talking:
> I agree, but I'll go further than you - I don't think this essay is confusing at all. It's simply nonsense - the kind of thing someone clever writes when they're discussing a subject completely outside their area of competence.
I'm not sure what you're implying here, but Knuth does know what art is, as he almost majored in Music. See this for some recent work: https://www.youtube.com/watch?v=e_1a6bHGQGo
I think Computer Science is the branch of maths that studies computing. Things like Computability, Complexity Theory and Information Theory are clearly branches of Maths, and Math is a science. Now, most CS courses are not about this: they are engineering courses at heart, that only use CS in the way a Civil Engineering course may us Physics.
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 created, you are closer to a craftsman. Where do you stand?
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 "Let's do something unheard" when writing his partitions.
They might not try to invent something original, but they end up with something original and touching people deep in their psyche. Compare that to a perfectly fluent user interface you "just love". Is that a craft? Or is there something more in it? Can you really quantify and automate the process of coming up with it?
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.
I think it's more of an art in the classical sense (which is like a craft), in that we are artisans rather than artists.
The difference being that we primarily create things valued for their utility, rather than their aesthetics. Video games being the possible exception, although even there the programmers are essentially building a vehicle for the art-stuff (story, graphics, gameplay, music) to shine through.
I am learning technology so that I can express my ideas and share them with the rest of the world, and have fun with likeminded people. I also do photography at the pro level, movies, compose music in a world-class home music studio etc. I assume if you want to be great at art, you have to be great at techn(ology/ique). In my case it means I need to write superb pixel shaders, create VSTis producing sound nobody else has produced before and still awesome, stabilizing hyperlapses with my own computer vision algorithm, making robots dance and so on. For that I need to study whatever I find at MIT/Stanford/Harvard/etc even if it is very very difficult. So is this a craft?
If I recall correctly this was Brooks stance - can't remember if it was the mythical man month or one of the related essays. But they're approaching it from different angles: Brooks manifesto was very much in the commercial setting. Knuth perhaps inhabits that more platonic problem domain. For me it's quite a philosophical pursuit and for those programming in an applied scientific context maybe it's more em scientific.
you're absolutely right, i've seen beautiful, useful interfaces impossible to maintain due to lack of backend skill, i've seen great core functionality let down by bare-boned interfaces that don't let the user easily do the multiple parts of a particular task without too much effort involved in manually doing each part of it.
Great read. Indeed programming is not a 'gentle art', I would say it's a 'brutal art'.
There was an article outlining a continuum between art and science, where engineering was somewhere in the middle. Art is the least rigorous of them, while science has the most rigor.
Being a science enthusiast, reading on quantum physics, evolutionary biology, etc., I've learned more/less how scientists think. It has a lot to do with coming up with not only good explanations, but explanations that are extremely hard to vary. Explanations that risk falling apart if you try to change any aspect of it. This together with a mountain of evidence supporting said explanation, makes for good science.
Art on the other hand, is arguably vague by definition. Art that is doesn't leave room for interpretation is often bland. Art also has a huge human component, whereas science tries to do away with it.
In my opinion, programming can easily be both an art and a science. There's no need to constrain it to either one. On one hand, you have the mathematical theory of information, describing a hard-to-vary explanation that is backed up with great math(s). On the other, you have an infinite set of tools from which you can craft whatever your imagination is capable of coming up with. Programming, having its foundations in mathematics, leverages its infinite potential, and with it the possibility of creating both works of art, and scientific facts. It is this universe of possibility that takes only the toughest of minds to venture and explore.
Art can occur when the same person is both the source of the requirements for the program, and the implementor of the program. Much of the art is in the coming up with the specification: that is the concept in the art. The concept can be skillfully rendered into code. Concept + skillful rendering = art.
Perhaps a way to refine this understanding is to consider a different medium more typically believed to be artistic: film.
A director will construct the artistic vision (akin to the requirements/concept) and then work with film music composer to add music (analogous to development). Is the composer and artist practicing art? I would suggest that the word "craftsman" is better suited to the work the film composer does (assuming that they aren't also directing). That doesn't mean that a film composer cannot also be an artist in his/her own right, but in this context their input is arbitrarily limited by the artistic vision of the director... even if the director's vision allows for significant discretion by the composer.
Most development work, as you point out, has this separation of creative impulse from the implementing crafts. I do think there is "art" involved in programming, but only when the creative impulse is joined with the craft of development in a single mind.
What about algorithm problems for with the most efficient Big-O solution is known? How can you "skillfully" render code when there is only one best possible way to do it?
I would argue that in those cases, programming is not an art because the arriving at the solution is very mechanical and there is literally zero room for creativity. Thus imo this answer isn't broad enough to fully define "Art"
Change the x that the big O is about, for example by using vector instructions.
Implement a theoretically less efficient algorithm that is faster (examples: switch to a O(n^2) sort for small data set, or to a linear search for smallish arrays)
Causal isolation from other humans is a risk factor in muddled thinking and poor architecture. Adding people to a project does not make it any less likely to become muddy, though.
" The moral of this story, it seems to me, is that we should make use of the idea of limited resources in our own education. We can all benefit by doing occasional "toy" programs, when artificial restrictions are set up, so that we are forced to push our abilities to the limit. We shouldn't live in the lap of luxury all the time, since that tends to make us lethargic."
I take for Science the natural and social sciences (see Wikipedia article on Science). In other words, Physics and all its sub divisions. In this respect, programming is not a science. CS is mostly a sub division of Math (also, not a science). Programming is a mix of engineering (that is finding an optimal solution given a set of known tools to a non-universal problem) and art - anything that allows for creativity in the forming of a finalized product. Most engineering disciplines have an aspect of art in them, but programming is perhaps the most artful thanks to the incredibly wide range of close-to-optimal solutions. But programming is also one more thing: a social process, the process of organising people and their work (which is neither science, nor math, nor art).
Why 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?
Love this part, "In fact, when I first picked up a dictionary in order to study the words "art" and "science," I happened to glance at the editor's preface, which began by saying, "The making of a dictionary is both a science and an art.""
Knuth has a very abstract and fuzzy definition of "Art." Personally I feel "art" possesses a more concrete definition.
When the most efficient solution to a problem isn't known we rely on art and design to fill the void. When the path to the most efficient solution of a problem is known we rely on "science" or technical procedures to deduce the best possible answer.
For many problems in programming we know the best possible solution. However, for most of the apps we build to solve problems in the name of entrepreneurship or business, no efficient solution is known. In fact, in these situations, the problem isn't even clearly defined. When we don't know the "best" solution we use intuition and creativity to come up with a solution that we only intuitively know to be somewhat efficient.
Programming isn't the only area where this occurs. All of engineering relies on art and design to solve problems where the most efficient solution isn't known.
For example, what is the shortest distance between point A and point B? The answer is a straight line. There is no design or art as part of this solution because a straight line is mathematically proven to be the most efficient possible answer. The answer, in essence, was calculated and thus no "art" or design was involved. Utilizing art in this case would be as pointless as drawing an artsy squiggly line between point a and point b.
Now, allow me to modify the problem to make it a little more complex. Instead of calculating the shortest path between two points, how do I find the most efficient way to transport a person from point A to point B?
The most efficient answer is mind boggling complex, you have to account for the personalities and definitions of "efficient" for every possible person you can transport, energy, speed, obstacles etc etc. There probably is a most efficient solution but know one knows it.
Here, where it is very hard for us to deduce the most efficient solution we rely on Art.
With "art" we can come up with multitudes of solutions to the problem on how to transport a person from point a to point b. Cars (thousands of different models), flying vehicles (thousands of different innovations as well) are two possible examples out of many forms of locomotion. The reason why there are so many models/solutions is because we can never concretely determine which "solution" was the most efficient.
This is what we mean when we use the word "Art" in the context of "The Art of Programming" or "The Art of combat." We are essentially describing a problem domain space that is so complex our pathetic human minds our reduced to a sort of aimless wandering (aka creativity) to come up with a solution that isn't even the most efficient one.
I use the word aimless because we iterate over our solutions endlessly in an endless quest to arrive at the best solution. The "quest" is essentially endless because our "path" is aimless. We will never ever create the most efficient OS or iphone app of all time because we don't even know what the hell that even means. Instead we are cursed to iterate endlessly over our programs creating version after version for all eternity.
The majority of problems in the real world rely on a bit of "art" to arrive at a solution. In fact, most of the problems where an "efficient" solution is known are just theoretical conjectures that only exist in an idealized virtual universe.
> Meanwhile we have actually succeeded in making our discipline a science, and in a remarkably simple way: merely by deciding to call it "computer science."
Well not only that but we actually stuffed two misnomers in there. It is not really a science, and it is not really about computers. Chip design, graphics, storage, input devices is more about computers as such.
Peter Naur (who unfortunately passed away recently) suggested the term "datalogy", to indicate that computer science doesn't necessarily have anything to do with computers, but instead is about the treatment of data[0]. The term "datalogi" is actually used in Denmark instead of "computer science".
How does this fit with, say, designing an ergonomic phone interface? Or constructing quantum computers using optics? I think this is another example of one person calling Computer Science what they would like it to be, because of their background.
Designing an ergonomic phone interface can be grouped under communication design, thus art. Constructing a quantum computer using optics clearly falls into the physics department, at least until physics spins off an engineering department for quantum stuff, like it spun off mechanics and electronics in earlier centuries.
I consider the term "computer science" historically motivated and anachronistic. Similar to how old people would stereotypically describe their child's job as "something with computers", we muddled subtopics of various sciences together just because they're doing "something with computers".
With computing technology and methodology now permeating nearly all areas of science, art, and engineering, maybe it's time to tear down the computer science departments and reintegrate their pieces back into the appropriate departments.
Or maybe we shouldn't, for we would lose the extremely diverse curriculum that a CS degree includes.
I've heard mathematics classified as a "structural science", as opposed to the "natural sciences". Theoretical CS fits into that "structural science" umbrella term very well.
Ok I can see that. Though I never heard the term "structural science". At least in US I most people talk about Science and Math. Math is explicitly not included in the "Science" category because it is mentioned separately. Otherwise it would be like saying "Engineering and Chemical Engineering".
CS is a funny beast. It's the first time we're seriously dealing with machines executing abstract math directly. There's nothing to study via experimentation - computing is pure math, and hardware stuff is pure engineering (since computation is not tied to particular branch of physics - you can make computing run on anything, not just electrons and photons). It's best to conceptually split the two, if we want to stay with the original terminology. But I guess now it's kind of too late - it's the definition of the word 'science' that will get relaxed.
This is stretching it, but if you accept automata theory as a part of CS (not very controversial) and accept cellular automata like the game of life as a branch of automata theory (not very controversial) and accept some research methods involving experimentation and observation of the behavior of random seeds as part of cellular automata theory (not very controversial) then the very extended argument stretches from hard core CS to 'stick a random seed in the CA, run it, and ta da, we observe the un predicted existence of gliders!'. Its stretching it but I think its acceptable.
I was going to list some formal percolation theory studies in as an applied version of imaginary network routing protocols or could be seen as a very weird emulation of a CA, kinda, but that's probably going way too far. Practical simulation of a specific algo is obviously cheating, but simulation of an abstract concept is maybe not cheaty. Possibly there is, or will be, an analytic topological pure math theory that could be applied to mathematically prove constants currently only discovered by experiment in perc theory. If you're ever bored and want to run some simulations, perc theory is very project euler like in that a short(ish) question quickly results in "I guess I gotta run it and see".
Another "stretch the limits" is there is no unclassified explanation of some peculiar corners of some crypto algos. Hard to know if they're truly random, determined by experimental runs against possibly classified cracking techniques, or intentional back doors, or intentional classified design techniques. But relying on military intel classification "we can't rule out experimental methods being used in secret" is kinda cheaty in the spirit of the discussion.
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, every time we vary a parameter, every time we optimize a program, we are running experiments.
At least if we're doing it right.
If you're not doing experiments, I have a hard time categorizing what you are doing as computer science.
In physics, we do experiments because we don't know the rules of the natural world. That's the only way we can learn them.
In CS/programming, if we're doing any experiments, they're done because we're too stupid to infer the right answer beforehand. Insofar as you're dealing with the theoretical part of the problem, you shouldn't need any experiments, because the results are purely mathematic and should be perfectly predictable. And if you're doing hardware experiments, it's not computer science either - that's electrical engineering or applied physics. Whatever other tests you may be doing to save some time are still the engineering type.
The point is, computer science doesn't have any area in which it could use experiments for discovery. It's fair to say then, that it's not really a science. (It's also fair to point out that the line between science and engineering is getting blurry nowadays.)
> In CS/programming, if we're doing any experiments, they're
> done because we're too stupid to infer the right answer
That's the same as for physics. In theory, there is no difference between theory and practice. In practice, there is.
More specifically, for CS: what you're describing is an alternate universe where the halting problem[1] doesn't exist, or rather has been solved. In short, there is no way to predict, in the general case, whether a program will terminate or not, other than running it (= doing the experiment).
More generally, if you have a mechanism that predicts with perfect accuracy what the output of my program is, more quickly than running the program, then I will just call that new mechanism "the program", and use that instead of the original program. And then you're back to running the program to find out what it does.
UPDATE: To me, this is a (if not THE) fundamental results of theoretical computer science: a precise description of its limits. And since this is an article by Knuth: "Beware of bugs in the above code; I have only proved it correct, not tried it"[2]
You're describing software engineering, not computer science.
CS is big-O, Chomsky hierarchy, finite automata, type theory, and computability classes. It's the study of algorithms & data structures, not their implementations. In other words, CS is a branch of math.
Theoretical computer science is a division or subset of general computer science and mathematics that focuses on more abstract or mathematical aspects of computing and includes the theory of computation.
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't science because well everything is running experiments? I am going to buy milk -- it's an experiment to see what happens. Maybe I won't find parking. I am drinking coffee in the morning, it's an experiment to see if it will still keep me awake.
By that token we've diluted the word science to not really mean anything anymore.
"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."
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.
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.
Wow. Just wow. Please don't project your insecurities on others.
Look, I tend to say that "Computer Science" is a bit pretentious, "playing with computers" is overall more appropriate for the level our field is at. Not sure where you got Einstein from. And, in the words of Wolfgang Pauli: "Ach, that isn't even wrong".
Bringing Einstein, who was a theorist, into a discussion about experiments is downright silly, and makes me question whether you have any idea as to what you're talking about.
Second, assuming for the sake of argument that Einstein was an experimenter, it would be just about the biggest straw-man imaginable. If experiments are only experiments if performed by one of the greatest scientists who ever lived, then science effectively doesn't exist and there are no scientists, to several significant figures.
However, the question was not who is an awesome scientist, but whether there are experiments in CS, whether empiricism is relevant especially vs. the entire field being a trivial application of mathematical theory.
And that is, for me, easy to answer: it is a highly empirical field. If you think it is a trivial application of mathematical theory, you don't know what you're talking about, neither in theory nor in practice.
And yes: there is a lot of science being done that isn't at the level of Einstein or the people at CERN or Fermilab.
This fits in well with the "code as craft" argument presented in the comments here. Most craftsmen need to make a living by producing rather boring, functional pieces in a large volume, while occasionally taking the time to manufacture an intricate masterpiece.
In this sense, your run-of-the-mill Rails app is the IKEA table of coding.
That one is a scanned PDF; its contents don't appear to be indexed by, e.g., Google; its availability is dependent on the continued goodwill of the ACM.
Paul Graham's copy is plain HTML, sitting on the open web where anyone can see it and index it, and while for the rest of us its availability is dependent on PG's continued goodwill presumably he likes being able to rely on it staying there as long as he wants unless he's explicitly forced to take it down somehow.
You have a point. I still find it odd to use a personal domain (other than the author's) for this purpose, with the Internet Archive and other options being available.
Searching for "Computer Programming as an Art" the PDF comes up as the second link (below PG's rip off). Not that it's even relevant because it's given as a direct link.
A scanned PDF is a closer reproduction to the original presentation, and easier to save for later to read.
I trust the ACM's "goodwill" to continue hosting it more than I trust it to remain on PG's website.
Knuth is famous for focusing on writing his books. He even stopped using email because it was too distracting. I doubt he has the time (or interest) to export all his writing to modern indexable formats on a site he maintains (Prof. Knuth feel free to yell at me about this assumption). He is clearly credited. Just getting the knowledge out there is good.
What I find truly astonishing is that this 1974 paper is so relavent today.
The original title is completely bewildering. And now it looks like an article entitled "Knuth: Computer Programming as an Art," possibly written by Paul Graham. Just write:
"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 me, is that we should make use of the idea of limited resources in our own education. We can all benefit by doing occasional "toy" programs, when artificial restrictions are set up, so that we are forced to push our abilities to the limit. We shouldn't live in the lap of luxury all the time, since that tends to make us lethargic. The art of tackling miniproblems with all our energy will sharpen our talents for the real problems, and the experience will help us to get more pleasure from our accomplishments on less restricted equipment."
So true. Robert Rodriguez filmed El Mariachi with almost no resources. It's why the demoscene produced - and still produces - such amazing creations within its self-imposed strict limits. It's one of the reasons why the Raspberry Pi is so popular and why you see the most beautiful ARM assembly on the Gameboy.
And conversely I think it's why Web development is collapsing under the weight of too many shiny things. It's lethargic and living in the lap of luxury. I watched a video the other day of AirBNB talking about the evolution of its Web site. The 2008 version was fine: Rails, a database and dynamic page output. The 2015 version was insane: Rails, React, Node, all sorts of dependencies, some stuff I'd never heard of but that the speaker assured was good, complex mobile optimization when you could instead, you know, just write lean and mean mobile-friendly HTML.
Limit yourself instead and see what happens - the results might just be awesome.
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.
I was stirring :) I think that it's not coincidental that Web development frameworks are collapsing under their own weight and programmers are going mad because there's just too many shiny things.
If we define an art as strive to reach an aesthetic global optimum, by balancing form and meaning (syntax and semantics, if you wish, design and implementation) with attention to every single detail, then [some] programming is an art without a slightest doubt.
Aesthetic global optimum can never be reached as it changes with time and differs among people. We are cursed to eternally iterate over our programs in attempt to reach this lofty goal.
Let me know if you've seen any program that can be described as aesthetically optimal.
Do you honestly think that writers, painters or composers doesn't know it, or it stopped them from striving?
Millions of little pieces - Data modules from GHC, especially logic, lists, big chunks from Erlang stdlib, lib9, libbio, libutf from Inferno, parts of various Lisps, tons of code from carefully written books (PoFAD, PAIP/ALMA, OnLisp, etc) well-crafted projects like nginx, or even something like this:
Dude, I wasn't even arguing with you. It's a true statement.
My response was not meant to be in opposition to yours, it's just a remark. There was no need to say that. Don't start shit. Your comment needs to be flagged.
"According to most dictionaries "science" means knowledge that has been logically arranged and systematized in the form of general "laws.""
Ahh yes, the logical arrangement.
Programming Law #1: Thou shalt tab to indent.
Programming Law #2: Nested loops shall indent deeper to the right.
How about the six laws of depth in art?
1. Perspective - 2-point, 3-point...
2. Lower on canvas is closer, higher is further away
3. Atmosphere - clearer is closer, blur is further
3b. Color intensity - higher saturation is closer
4. Chiaroscuro - the next alternation is further (combination of #2 and #5)
5. Overlap - this behind that
6. Scale - bigger is closer
Art has plenty of laws, some very complex, but you won't find them in Google. You have to find the artists' artist and mix her color 5000 times, like roll-on-your-head Shaolin Temple skull-hardening. Return to the 36th Chamber and draw with charcoal attached to the end of a long stick of bamboo, then ring the bell, for another style has died.
> You have to find the artists' artist and mix her color 5000 times, like roll-on-your-head Shaolin Temple skull-hardening. Return to the 36th Chamber and draw with charcoal attached to the end of a long stick of bamboo, then ring the bell, for another style has died.
The delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of imagination. Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself.
I wrote more on this subject in "Why I Love Coding" http://henrikwarne.com/2012/06/02/why-i-love-coding/