English, and many other gendered languages, have a long history of using the masculine in place of an unknown. Using "he or she" instead is, in my opinion, both annoying to write and read.
This is something that I always saw as 'English syntactic sugar' as a non-native speaker.
When I realized that a plural form of the third person could be used in a gender-neutral way for the singular form, I was in awe.
* * *
Trivia:
In French, the common rule is "le masculin l'emporte"[1], which means the "male form wins"; if you talk about a group of 100 females and a single male, you must use the male form "ils" instead of the female form "elles".
[1]: [...] on abrège parfois cette règle en "le masculin l'emporte sur le féminin", alors qu'il serait correct de dire : seul les groupes exclusivement féminin sont féminins, les autres utilisent le genre non marqué.
Roughly translated to : It is more correct to say that groups exclusively composed of females are accorded using the female form, while the other groups use the 'unmarked' form (which is the male form).
I usually use they, but now that I think about it, I'm going to start using s/he. It's the same number of characters as they and you can just pronounce it like she when reading it aloud or in your head, since she is the underused pronoun anyway.
Not only is they the obvious alternative, it's always been perfectly good English and has been traced back to long before generic he was introduced—by Latinists who wanted to make English more proper in I forget which century. Now that generic he is rightly getting dumped, the natural solution that existed all along—singular they—is making a comeback. It's a lot better than stilted fabrications like "he or she", "s/he", and the hideous "ostentatious she" that some people (seemingly always liberal males) insist on using to denote programmers, venture capitalists, and other demographically lopsided populations—as if changing the ratio of pronouns would change the ratio of people.
The fascinating thing is that generic he was an ideological construct in the first place, a top-down imposition that never fully caught on in English despite literally centuries of being proclaimed as proper. Singular they continued to be used the whole time, and is found in most (all?) great English writers. (Jane Austen was particularly fond of it.) I don't have citations handy, but people with similar bees in their bonnets have made sure that web searches won't lack for them.
As a card carrying wielder of the ostentatious "she", let me just note that I use it as much for my own benefit as for the benefit of people who read me; specifically: I catch myself writing "he", and correct to "she". Over time, I train myself not to default to "he" so much.
Readability and being to able to maintain the code is just as important as the finished product.
Programming isn't just about one-shot projects, it's also about being able to pickup and work with existing source code. Whether it is for someone else or even yourself in the future.
That's akin to saying: Who cares how Carmack held his keyboard; what matters is what he made.
The code you write is an intrinsic part of the result. There goes form and function as one. There can be art in the function as can be art in the ideas embodied in the source code that carries out the function.
I can't swear to chisels but brushwork is extremely important to paintings; you really haven't seen a painting until you've gotten up close and been able to see the texture made by the strokes, and while maybe in theory you can achieve everything with a ham-fisted caveman grip on a brush it seems unlikely.
Which is to say, actually many people care about how artists hold their brushes.
This has been another entry in the billion part series: Why Analogies Are The Weakest Arguments.
It sounds more like you're saying that software is an art, rather than programming. The details of how the program was created have a similar status to incidental stuff about tools and how Michelangelo used them.
>> I wonder if sometimes all those books actually help you develop an efficient coding practice or are they just some sort of distraction towards your creativity.
That. I'd even go a bit further and say they actually hinder your creativity: can you even think of heroic fantasy without falling back into Tolkien's imagination?
There's a balance to maintain, if you don't think outside the rules and best practices every once in a while then you limit your creativity to content.
It's been argued by a famous artist (Chuck Close), that these kinds of limitations actually allow people to be more creative. When you narrow down your available techniques/tools, you eliminate paralysis of choice, and are forced to be creative with your small toolset. Think "Javascript the good parts".
I believe programming is an art because "Programs must be written for people to read, and only incidentally for machines to execute." (Abelson, SICP)
This heart of the matter, and it means programming is an art, a social one. Like marketing or graphic design, it's an art for other people. Programs must be written to be as readable as possible, to as many people as possible, while still being functional and elegant. This requires an intuition of psychology and sociology, in addition to a firm engineering grasp. A great programmer must be both mathematically brilliant and socially empathic. If she lacks the former, she won't be able to solve Hard Problems; if she lacks the latter, she'll be a Cowboy Coder (http://c2.com/cgi/wiki?CowboyCoder) and her code will be worthless to society.
Things that are made for practical purposes are not art, right? The thing with software is that the code is hidden from view.
There is an opportunity to make something practical by writing very impractical code, that for example, has variables named after fantasy characters, functions having some sort of narrative arc to their naming, maps "drawn" in ASCII...
TheGoblinKing.smites(our_hero) could be a method to reverse an array.
Again, highly impractical, but with a practical result.
Architecture has a similar duality, but in a different kind of way... buildings are indeed functional, but is there no art to the practice of designing them? No room for ornament, expression, or "impractical" intent? For example, ideologies can be encouraged through buildings by manipulating people's response to their sublime grandeur or nostalgia... this seems like a much more artistic and philosophical pursuit that goes well beyond just the pure function of the building as a place to keep things separate from the outside world.
(On John Carmack) "It was written that his code is so ugly according to the best practices standards, that only he completely understands what he has written. And we all know that he is a genius."
Beyond that, even if it was (which it isn't), you are not John Carmack. I don't know if dropping him into the article was supposed to bolster your point, but I can assure you it did the opposite. It reads like an oddly malformed appeal to authority. Bonus point: you can look at his code: https://github.com/id-Software
----
Please, please stop reading books about style and creating your own styles! Follow the language / platform standards and idioms so your code will instantly be readable by other developers. Almost all languages & platforms have dominant coding conventions, follow them. 15 years ago, you had to bake your own standard, you don't need to do it anymore.
Use your creativity on solving your problem, not formatting your code.
Thanks for the links. I didn't say that John's code is ugly, I just remember reading about it in some magazine. They (magazine) obviously didn't have a clue back then ...
By these vague definitions is there any professional endeavor that isn't an art? And if not haven't we just removed all unique meaning from the word 'art'?
It's better described as a craft than an art. Crafts produce something functional and require being pieced together with special knowledge. There is crossover between craft and art, but programmers are closer to the members of guilds, not galleries.
I'm quite happy as a craftsman myself. The problem is the many and diverse meanings of the word "art". At the start of Knuth's speech he quotes some ACM worthy as saying that programming needs to transition from an art to a disciplined science. Here, "art" is used to mean something that involves guesswork and holding one's finger in the air. In the title of TAOCP, on the other hand, Knuth seems to be using the word to mean "craft", as in the Art of Fly Fishing. Neither meaning refers to the practice of fine art. AFAIK no one compares engineering to musical composition or poetry, and engineers don't seem to lose much sleep over it.
The functions of art include philosophical enquiry and invoking a sense of immanence in the receiver, and so on; creating a program might cause some of these things to happen in the programmer, but only as a coincidence. In his poem called The Scent of the Real, Alvin Pang writes "to bear clear witness/to your longing alone/[is] the only art/there is." Software doesn't do it either, other than as a potential medium for visual art or other forms. It seems likely that new, distinctively digital art forms will evolve, but even then it won't be "the programming" that corresponds to "the art".
This is one of the themes in the film A River Run Through It, where a father tells his two sons that they have to find/achieve art in whatever they choose to do in life.
An easy way to think about this is to remember those times when somebody in the workplace does something above and beyond expectations, eg. they solve a problem in particularly brilliant fashion, and colleagues see it and say 'this, this is a work of art.'
Sorry nobody upvoted you. I much prefer your argument! I particularly liked the phrase The execution might as well be left to an automaton. This is the part of the profession - tedious trivial logical translation from specification to program - that I refer to as 'floor sweeping', rather than programming proper (analysis/design/interesting problem solving stuff). Perhaps the percentage of our industry remaining to be liberated from that drugery is high, unfortunately the liberators must be themselves.
Programming is an art, but as you get older and more experienced, you become less able to express yourself in a way that doesn't seem both rote and belabored.
It is closer to making furniture than painting or sculpture, as it tends to need to be practical in some way. But if it were furniture making, you'd continually be presented with new designs, new types of wood and other materials, and new tools to make your furniture with, so you'd never know exactly how long it would take to make a couch or a bedroom set.
It is both. Code and the effect it produces can be a thing of beauty, ugliness, or both, and at times the emotion and creative energy put into it would make it rival any art. But, I agree that more often it is like a craft because it tends to evolve into larger projects that need more skill and technique.
Creatives/artistic types enjoy modular, greenfield development or pushing the limits of confinement to produce something of beauty and use. Practical/craftsman/engineer types enjoy using technique to build, design, and maintain large systems because they enjoy process, skill, and established ways of doing things. There is room for both.
While the difficulty of and controversities over defining what "art" means are proverbial:
No, in full generality it's not - that's pretentious bullshit fancied by amateurs who want to cram as much meaning as possible into what they do.
Like painting, pottery, or photography, programming can be used to do art, but most of the time (99.9%+) it's just a mix of craft and industrial design, done to achieve a practical goal.
In my opinion, art is when you create things that have no actual use or value, but are there simply because they express you as a person.
Since we almost never do this with programming, I don't believe it can be considered an art as practiced by most programmers. That's not to say you can't use it as art, though! Any medium can be used to express art, because art is flowing out of you constantly. Art and humanities should not be separate classifications. Art is humanity.
Not sure how to frame this nicely. The page needs to play better with mobile devices. There is an ever-present back-arrow covering text that gets more obstructive as the page is zoomed. When I decided to follow it to see what was so important that it get in the way, the page it took me to was completely unusable. That aside, I was happy to see that I could actually pinch zoom as some sites block this behavior. Chrome on Galaxy S3.
Firefox Mobile has an addon to force pinch zooming to be allowed everywhere. I've used it on my S3 and it's pretty nice. Has lots of other addons that work with it too, like adblock which is nice for when the mobile connection is dodgy. Syncs bookmarks and such with my desktop too. Overall I've had a pretty good time using ff mobile on my s3. I'd recommend the nightly build. Also has a nice option to request the desktop versions of pages.
As a society, we can build buildings like regular old boxes, so long as it meets our needs for sheltering capacity. We don't do it this way because we've come to appreciate the ability of architects to create a more elegant building (elegant in cost, design, environmental effect).
Most of the programming we do is just building big blocky buildings that most will never see. If we were to spend the time and make it more elegant, we'd only be doing it for ourselves and other programmers, as we are the only ones that can appreciate it for the time being. Trying to simplify code is an art simply because it's unnecessary, but when it's actually achieved, yields some form of value to those that can appreciate it.
By that do you mean that it's difficult to do and you need to practise it? That sounds like a craft. I find it impossible to imagine the Mozart's Requiem or Sistine Chapel of software, much less of programming.
44 comments
[ 5.4 ms ] story [ 86.9 ms ] threadWhen I realized that a plural form of the third person could be used in a gender-neutral way for the singular form, I was in awe.
* * *
Trivia:
In French, the common rule is "le masculin l'emporte"[1], which means the "male form wins"; if you talk about a group of 100 females and a single male, you must use the male form "ils" instead of the female form "elles".
[1]: [...] on abrège parfois cette règle en "le masculin l'emporte sur le féminin", alors qu'il serait correct de dire : seul les groupes exclusivement féminin sont féminins, les autres utilisent le genre non marqué.
Roughly translated to : It is more correct to say that groups exclusively composed of females are accorded using the female form, while the other groups use the 'unmarked' form (which is the male form).
The fascinating thing is that generic he was an ideological construct in the first place, a top-down imposition that never fully caught on in English despite literally centuries of being proclaimed as proper. Singular they continued to be used the whole time, and is found in most (all?) great English writers. (Jane Austen was particularly fond of it.) I don't have citations handy, but people with similar bees in their bonnets have made sure that web searches won't lack for them.
I agree that the singular "they" is superior.
Who cares how Michelangelo held his brush or his chisel; what matters is what he made.
Readability and being to able to maintain the code is just as important as the finished product.
Programming isn't just about one-shot projects, it's also about being able to pickup and work with existing source code. Whether it is for someone else or even yourself in the future.
It's the one thing that is all yours.
The code you write is an intrinsic part of the result. There goes form and function as one. There can be art in the function as can be art in the ideas embodied in the source code that carries out the function.
I can't swear to chisels but brushwork is extremely important to paintings; you really haven't seen a painting until you've gotten up close and been able to see the texture made by the strokes, and while maybe in theory you can achieve everything with a ham-fisted caveman grip on a brush it seems unlikely.
Which is to say, actually many people care about how artists hold their brushes.
This has been another entry in the billion part series: Why Analogies Are The Weakest Arguments.
That. I'd even go a bit further and say they actually hinder your creativity: can you even think of heroic fantasy without falling back into Tolkien's imagination?
You have to know and understand the rules before you can break them in a meaningful way.
http://www.charlierose.com/view/interview/11264
This heart of the matter, and it means programming is an art, a social one. Like marketing or graphic design, it's an art for other people. Programs must be written to be as readable as possible, to as many people as possible, while still being functional and elegant. This requires an intuition of psychology and sociology, in addition to a firm engineering grasp. A great programmer must be both mathematically brilliant and socially empathic. If she lacks the former, she won't be able to solve Hard Problems; if she lacks the latter, she'll be a Cowboy Coder (http://c2.com/cgi/wiki?CowboyCoder) and her code will be worthless to society.
That's why it's an art.
No, it doesn't. It just means that programming is inherently about communication (among other things). That does not, by a long shot, make it art.
Things that are made for practical purposes are not art, right? The thing with software is that the code is hidden from view.
There is an opportunity to make something practical by writing very impractical code, that for example, has variables named after fantasy characters, functions having some sort of narrative arc to their naming, maps "drawn" in ASCII...
TheGoblinKing.smites(our_hero) could be a method to reverse an array.
Again, highly impractical, but with a practical result.
Architecture has a similar duality, but in a different kind of way... buildings are indeed functional, but is there no art to the practice of designing them? No room for ornament, expression, or "impractical" intent? For example, ideologies can be encouraged through buildings by manipulating people's response to their sublime grandeur or nostalgia... this seems like a much more artistic and philosophical pursuit that goes well beyond just the pure function of the building as a place to keep things separate from the outside world.
No, his code isn't ugly. No, not only he understands it. It is actually considered exceptionally beautiful (http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-...).
Beyond that, even if it was (which it isn't), you are not John Carmack. I don't know if dropping him into the article was supposed to bolster your point, but I can assure you it did the opposite. It reads like an oddly malformed appeal to authority. Bonus point: you can look at his code: https://github.com/id-Software
----
Please, please stop reading books about style and creating your own styles! Follow the language / platform standards and idioms so your code will instantly be readable by other developers. Almost all languages & platforms have dominant coding conventions, follow them. 15 years ago, you had to bake your own standard, you don't need to do it anymore.
Use your creativity on solving your problem, not formatting your code.
Yes, yes, and hell yes.
[1] - http://delivery.acm.org/10.1145/1290000/1283929/a1974-knuth....
The functions of art include philosophical enquiry and invoking a sense of immanence in the receiver, and so on; creating a program might cause some of these things to happen in the programmer, but only as a coincidence. In his poem called The Scent of the Real, Alvin Pang writes "to bear clear witness/to your longing alone/[is] the only art/there is." Software doesn't do it either, other than as a potential medium for visual art or other forms. It seems likely that new, distinctively digital art forms will evolve, but even then it won't be "the programming" that corresponds to "the art".
An easy way to think about this is to remember those times when somebody in the workplace does something above and beyond expectations, eg. they solve a problem in particularly brilliant fashion, and colleagues see it and say 'this, this is a work of art.'
It is closer to making furniture than painting or sculpture, as it tends to need to be practical in some way. But if it were furniture making, you'd continually be presented with new designs, new types of wood and other materials, and new tools to make your furniture with, so you'd never know exactly how long it would take to make a couch or a bedroom set.
Creatives/artistic types enjoy modular, greenfield development or pushing the limits of confinement to produce something of beauty and use. Practical/craftsman/engineer types enjoy using technique to build, design, and maintain large systems because they enjoy process, skill, and established ways of doing things. There is room for both.
No, in full generality it's not - that's pretentious bullshit fancied by amateurs who want to cram as much meaning as possible into what they do.
Like painting, pottery, or photography, programming can be used to do art, but most of the time (99.9%+) it's just a mix of craft and industrial design, done to achieve a practical goal.
Since we almost never do this with programming, I don't believe it can be considered an art as practiced by most programmers. That's not to say you can't use it as art, though! Any medium can be used to express art, because art is flowing out of you constantly. Art and humanities should not be separate classifications. Art is humanity.
As a society, we can build buildings like regular old boxes, so long as it meets our needs for sheltering capacity. We don't do it this way because we've come to appreciate the ability of architects to create a more elegant building (elegant in cost, design, environmental effect).
Most of the programming we do is just building big blocky buildings that most will never see. If we were to spend the time and make it more elegant, we'd only be doing it for ourselves and other programmers, as we are the only ones that can appreciate it for the time being. Trying to simplify code is an art simply because it's unnecessary, but when it's actually achieved, yields some form of value to those that can appreciate it.
By that do you mean that it's difficult to do and you need to practise it? That sounds like a craft. I find it impossible to imagine the Mozart's Requiem or Sistine Chapel of software, much less of programming.
They are different skills, varying in levels of importance depending on the context.