David Brunton
Wednesday, April 23, 2008
Zebra Stripes in Processing 0135
The image to the right was not created using processing. However, it did serve as an inspiration for the latest in my series of natural-looking patterns made with cellular automata and Processing 0135.
My latest masterpiece is called "zebra" and I bet you'll never guess what it looks like. I changed the colors around from "goo" and added a further limit that each pixel can only swap with the pixel horizontally adjacent to itself. I didn't start from scratch, so it's possible there's still some green goo behavior lurking in there somewhere, but the code is included behind that link.
Without further ado, I present zebra. I lifted the zebra image from here on Wikipedia, and it's GFDL, so to be on the fair side, feel free to copy anything in this post under the same terms as that image. Thanks, Miraceti!
(edit: as with previous installments, click to randomize, space-bar to start)
The image to the right was not created using processing. However, it did serve as an inspiration for the latest in my series of natural-looking patterns made with cellular automata and Processing 0135.My latest masterpiece is called "zebra" and I bet you'll never guess what it looks like. I changed the colors around from "goo" and added a further limit that each pixel can only swap with the pixel horizontally adjacent to itself. I didn't start from scratch, so it's possible there's still some green goo behavior lurking in there somewhere, but the code is included behind that link.
Without further ado, I present zebra. I lifted the zebra image from here on Wikipedia, and it's GFDL, so to be on the fair side, feel free to copy anything in this post under the same terms as that image. Thanks, Miraceti!
(edit: as with previous installments, click to randomize, space-bar to start)
Labels: art, cellular automata, processing, programming
¶ 4:27 PM Links to this post
Tuesday, March 25, 2008
Perl 6 Is Not Just a Language
Perl 6 is a programming language I've discussed before.
Like anyone else who spent more than five minutes on the Perl 6 IRC channel, I got a commit bit to Pugs, but Pugs isn't really moving. Perl 6 has some traction on other fronts: Rakudo is moving along at a good clip, Parrot keeps getting cooler, and Perl 5 keeps getting more Perl 6 syntax built in. There are variants of Perl 6 syntax, too: KindaPerl, NotQuitePerl, etc.
Now, I'm not part of the Perl 6 design team, and I don't speak for anyone but myself. But Perl 6 is still a long ways off. I mean a real Perl 6 with mutable grammar and meaningful interoperability with other Perls and maybe other languages as well, along with all the pretty new syntax that could probably be "done" a lot sooner if it weren't so tied up in other aspects of the implementation.
By "a long ways off" I mean "more than five years."
I don't say this to denigrate the efforts that are bringing us pieces of Perl 6 right now. I say this in the interest of recognizing how big a change Perl 6 is likely to be. Especially if it keeps the interesting bits that Larry Wall seems pretty likely to keep. It's a whole culture. And it has to be rewritten from scratch. And we're just starting.
Perl 6 is not just a language.
It's a new programming culture that recognizes programmers for the language designers we are, and gives us the tools we need to do it well. A presumption that we will write code which looks at itself and adapts. A recognition that most the good ideas will be someone else's, and we should have easy ways to use them.
These kinds of changes won't come easy, especially since they'll break so many of our existing tools. Syntax highlighters and IDEs and testing frameworks will all need to be rethought, along with who knows what else. Best practices will need to be borrowed from communities that have dealt with some of the same problems, and new practices will need to be invented for dealing with new problems. We'll have to gradually move in that direction, discovering obstacles along the way, and hopefully not forgetting to enjoy ourselves.
Yeah, Perl 6 is still a ways off. But getting there is still fun. And once we've gotten there it will be worth it.
Since we'll be able to use Perl 6 to write Perl 7.
Like anyone else who spent more than five minutes on the Perl 6 IRC channel, I got a commit bit to Pugs, but Pugs isn't really moving. Perl 6 has some traction on other fronts: Rakudo is moving along at a good clip, Parrot keeps getting cooler, and Perl 5 keeps getting more Perl 6 syntax built in. There are variants of Perl 6 syntax, too: KindaPerl, NotQuitePerl, etc.
Now, I'm not part of the Perl 6 design team, and I don't speak for anyone but myself. But Perl 6 is still a long ways off. I mean a real Perl 6 with mutable grammar and meaningful interoperability with other Perls and maybe other languages as well, along with all the pretty new syntax that could probably be "done" a lot sooner if it weren't so tied up in other aspects of the implementation.
By "a long ways off" I mean "more than five years."
I don't say this to denigrate the efforts that are bringing us pieces of Perl 6 right now. I say this in the interest of recognizing how big a change Perl 6 is likely to be. Especially if it keeps the interesting bits that Larry Wall seems pretty likely to keep. It's a whole culture. And it has to be rewritten from scratch. And we're just starting.
Perl 6 is not just a language.
It's a new programming culture that recognizes programmers for the language designers we are, and gives us the tools we need to do it well. A presumption that we will write code which looks at itself and adapts. A recognition that most the good ideas will be someone else's, and we should have easy ways to use them.
These kinds of changes won't come easy, especially since they'll break so many of our existing tools. Syntax highlighters and IDEs and testing frameworks will all need to be rethought, along with who knows what else. Best practices will need to be borrowed from communities that have dealt with some of the same problems, and new practices will need to be invented for dealing with new problems. We'll have to gradually move in that direction, discovering obstacles along the way, and hopefully not forgetting to enjoy ourselves.
Yeah, Perl 6 is still a ways off. But getting there is still fun. And once we've gotten there it will be worth it.
Since we'll be able to use Perl 6 to write Perl 7.
Labels: culture, perl, perl6, programming
¶ 1:50 PM Links to this post
Friday, February 29, 2008
Perl 6, Compiling, and Even More Smartness of Others
In the previous post, I talked about why I like Perl:
Perl 6 is a new language, which is much like Perl in some ways. Unless there is some secret Perl Cabal working on a project they're not talking about, Perl 6 is still a ways away. But there are a number of interesting documents that describe what Perl 6 will do when it comes, which bear thinking about, particularly in the context of Perl.
Of course, there is new syntax- new nouns and verbs and even punctuation that some people will love and some people will hate but most people will just use (or not use) without thinking about it a great deal. From what I've seen of it, I like the new grammar in Perl 6, and I especially like that it is a grammar (rather than an implementation of a grammar, like Perl). But syntax aside, there are two points worth noting about Perl 6 that mirror Perl's original contributions in many ways:
On Boundaries
Perl blurred the traditional boundary between scripting and application development. Using Perl, application developers write code quickly that is platform independent and easily modified. These three variables (speed, portability, and agility) are not altogether unrelated, but that is a topic for another day. With the caveats spelled out in the previous post, Ruby and Python erase these boundaries even more completely.
Perl 6 is aiming for a different boundary. Traditionally, there is a huge gulf between a programming language and its compiler. This gulf is filled with Compiler Compilers like yacc and bison, which make grammars into parsers, which parse languages, which create an abstract syntax tree, which is ultimately compiled down to machine instructions (either virtual, or actual, physical machine instructions). It's a lot of steps.
Perl 6 is not the first language to aim for this boundary, by a long shot. But Perl 6 does take aim with style and flair. If the approach is successful, it may signal the end of learning a new syntax for writing parsers with compiler-compilers. Programmers themselves will be able to experiment with creating new programming paradigms by rewriting the rules as they go along.
Is this a good idea?
The heck if I know. I imagine it will not be used by a great horde of programmers, but then most programming language features aren't.
There are a number of other features that take aim at this boundary, but setting their phasers on stun rather than kill. The design of Perl 6 has a great deal of introspection built in- giving programmers the ability to not only inspect the contents of a container, but also to inspect the container itself, and even make changes to the container.
Once again, I don't really know if this is a good idea. Python and Ruby have already got it in the form of duckpunching or monkeypatching or whatever they're calling it these days. We're going to call it Perl 6, and rather than hating it, we're going to love it. Since, after all, there is more than one way to do it.
On Leveraging the Smartness of Others
Perl programmers believe that other Perl programmers are real smart. It's why CPAN works so well. But there are problems with this belief. Sometimes other programmers get smarter faster than I do, which means they change how their code works in a new version. CPAN made it a little hard to grab a specific instance of someone else's smartness. There might also be more than one smart person working on a particular problem, who both call their code by the same name (since they're both real smart). CPAN made it a little hard to pick one or to not care or to do whatever else I want to do in that instance.
On top of all this, there are times when I may even think someone else is smart, who isn't even a Perl (or Perl 6) programmer. I know it sounds far-fetched, but it does happen sometimes.
Once again, Perl 6 is not the first language to aim for this ability. Perl gave us interfaces to the C programming language, and others eventually, but they are real hard to use unless someone else had already done it (which is often the case). Perhaps I should say real hard to write.
Perl 6 provides enough optional type declaration that writing interfaces to other languages becomes much easier. And in the case that Perl is running on a (possibly virtual) machine that supports other languages (approximately 100% of the time in the current implementation efforts), it will (hopefully) be a no-brainer, such that using the smartness of others will be the same kind of reflex it was with Perl.
And as for CPAN- Perl 6 comes packaged with a nice abstraction layer that allows a great deal of information to be specified about a given class or grammar or package. Authors, versions, and namespaces are built in.
So, I imagine in the future world of Perl 6, I'm going to care even less about who wrote the code I'm running (especially if that person is not-me), but to be able to trust more reliably that the code won't be changing out from under me. I may even care less about what language it's written in, which brings us full-circle to the earlier point.
The code I'm running very well may look like it's written in Ruby or Python, but simply be using a grammar from one of those languages on top of Perl 6. Wouldn't that be strange? Talk about blurring boundaries.
Conclusion
It's hard to conclude anything from this exploration. But it is worth noting that after thinking about it for a while, I do think taking down the language/compiler barrier is a great long-term goal, and I do think (re-)using the smartness of other people is nice. And I admit that it's possible Perl programmers eventually lost their way on the latter some time in the past twenty years. It happens to the best of us. Twenty more years, and we'll be ready for version seven, which will, according to Larry, be the perfect language.
- Perl fudged the boundary between scripting and application development
- Perl gave smart people a way to share their smartness: CPAN
Perl 6 is a new language, which is much like Perl in some ways. Unless there is some secret Perl Cabal working on a project they're not talking about, Perl 6 is still a ways away. But there are a number of interesting documents that describe what Perl 6 will do when it comes, which bear thinking about, particularly in the context of Perl.
Of course, there is new syntax- new nouns and verbs and even punctuation that some people will love and some people will hate but most people will just use (or not use) without thinking about it a great deal. From what I've seen of it, I like the new grammar in Perl 6, and I especially like that it is a grammar (rather than an implementation of a grammar, like Perl). But syntax aside, there are two points worth noting about Perl 6 that mirror Perl's original contributions in many ways:
- Perl 6 is fudging the boundary between language and compiler
- Perl 6 is making it easier to use the smartness of other people
On Boundaries
Perl blurred the traditional boundary between scripting and application development. Using Perl, application developers write code quickly that is platform independent and easily modified. These three variables (speed, portability, and agility) are not altogether unrelated, but that is a topic for another day. With the caveats spelled out in the previous post, Ruby and Python erase these boundaries even more completely.
Perl 6 is aiming for a different boundary. Traditionally, there is a huge gulf between a programming language and its compiler. This gulf is filled with Compiler Compilers like yacc and bison, which make grammars into parsers, which parse languages, which create an abstract syntax tree, which is ultimately compiled down to machine instructions (either virtual, or actual, physical machine instructions). It's a lot of steps.
Perl 6 is not the first language to aim for this boundary, by a long shot. But Perl 6 does take aim with style and flair. If the approach is successful, it may signal the end of learning a new syntax for writing parsers with compiler-compilers. Programmers themselves will be able to experiment with creating new programming paradigms by rewriting the rules as they go along.
Is this a good idea?
The heck if I know. I imagine it will not be used by a great horde of programmers, but then most programming language features aren't.
There are a number of other features that take aim at this boundary, but setting their phasers on stun rather than kill. The design of Perl 6 has a great deal of introspection built in- giving programmers the ability to not only inspect the contents of a container, but also to inspect the container itself, and even make changes to the container.
Once again, I don't really know if this is a good idea. Python and Ruby have already got it in the form of duckpunching or monkeypatching or whatever they're calling it these days. We're going to call it Perl 6, and rather than hating it, we're going to love it. Since, after all, there is more than one way to do it.
On Leveraging the Smartness of Others
Perl programmers believe that other Perl programmers are real smart. It's why CPAN works so well. But there are problems with this belief. Sometimes other programmers get smarter faster than I do, which means they change how their code works in a new version. CPAN made it a little hard to grab a specific instance of someone else's smartness. There might also be more than one smart person working on a particular problem, who both call their code by the same name (since they're both real smart). CPAN made it a little hard to pick one or to not care or to do whatever else I want to do in that instance.
On top of all this, there are times when I may even think someone else is smart, who isn't even a Perl (or Perl 6) programmer. I know it sounds far-fetched, but it does happen sometimes.
Once again, Perl 6 is not the first language to aim for this ability. Perl gave us interfaces to the C programming language, and others eventually, but they are real hard to use unless someone else had already done it (which is often the case). Perhaps I should say real hard to write.
Perl 6 provides enough optional type declaration that writing interfaces to other languages becomes much easier. And in the case that Perl is running on a (possibly virtual) machine that supports other languages (approximately 100% of the time in the current implementation efforts), it will (hopefully) be a no-brainer, such that using the smartness of others will be the same kind of reflex it was with Perl.
And as for CPAN- Perl 6 comes packaged with a nice abstraction layer that allows a great deal of information to be specified about a given class or grammar or package. Authors, versions, and namespaces are built in.
So, I imagine in the future world of Perl 6, I'm going to care even less about who wrote the code I'm running (especially if that person is not-me), but to be able to trust more reliably that the code won't be changing out from under me. I may even care less about what language it's written in, which brings us full-circle to the earlier point.
The code I'm running very well may look like it's written in Ruby or Python, but simply be using a grammar from one of those languages on top of Perl 6. Wouldn't that be strange? Talk about blurring boundaries.
Conclusion
It's hard to conclude anything from this exploration. But it is worth noting that after thinking about it for a while, I do think taking down the language/compiler barrier is a great long-term goal, and I do think (re-)using the smartness of other people is nice. And I admit that it's possible Perl programmers eventually lost their way on the latter some time in the past twenty years. It happens to the best of us. Twenty more years, and we'll be ready for version seven, which will, according to Larry, be the perfect language.
Labels: compilers, language design, perl, perl6, programming, python, ruby
¶ 2:24 PM Links to this post
Perl, Scripting, and the Smartness of Others
Perl is the name of a programming language I like.
Meaning, I like the name, and I like the language. Perl opened an ecological niche for programming languages that may have since been filled with other, better languages, but Perl was first. The other languages even have fun names. Python and Ruby come to mind in particular.
The niche is hard to describe- people call them "scripting" languages, but that term only has meaning when they're used for writing scripts (programs that control other programs, basically). Which is not, for the most part, what people do with these languages any more.
The thing that distinguishes the best of these languages is the relationship between development time and execution time. The languages allow people to write code quickly, which may or may not run quickly. They are best used in scenarios where the difference between one second and two seconds probably doesn't matter. For the most part.
Real scripting languages are still used mostly for scripting (e.g. sed, awk, bash). But Perl expanded this niche beyond scripting, and that's one of the things I like it for. People have used Perl for development of all kinds of applications over the past couple decades. Yes, perl is ancient.
When I was thinking about this post, I re-read Steve Yegge's essay about ancient Perl. It's full of his usual blah-blah-blah, but one point in particular amused me:
CPAN is institutional knowledge of a bunch of badass Perl hackers dumped into a central place and mirrored around the world for anyone to use. It is as schizophrenic and disorganized as you might expect from this kind of a resource. But it's also the answer to a big load of common problems that Perl hackers have had. And man, do Perl hackers have problems.
For all of the better-ness of other languages (and I really do like the syntax of those languages better in some ways), they still lack a CPAN. Some of them probably consider this a feature more than it is a bug, which may be the biggest bug of all.
Python and Ruby and their many friends fixed lots of problems with Perl syntax, and maybe even with Perl culture. But while they were busy throwing away the bad syntax Perl inherited from the real scripting languages, they left but the one feature that made Perl more than a novelty, which was not what we could do with it, but what others had already done.
Meaning, I like the name, and I like the language. Perl opened an ecological niche for programming languages that may have since been filled with other, better languages, but Perl was first. The other languages even have fun names. Python and Ruby come to mind in particular.
The niche is hard to describe- people call them "scripting" languages, but that term only has meaning when they're used for writing scripts (programs that control other programs, basically). Which is not, for the most part, what people do with these languages any more.
The thing that distinguishes the best of these languages is the relationship between development time and execution time. The languages allow people to write code quickly, which may or may not run quickly. They are best used in scenarios where the difference between one second and two seconds probably doesn't matter. For the most part.
Real scripting languages are still used mostly for scripting (e.g. sed, awk, bash). But Perl expanded this niche beyond scripting, and that's one of the things I like it for. People have used Perl for development of all kinds of applications over the past couple decades. Yes, perl is ancient.
When I was thinking about this post, I re-read Steve Yegge's essay about ancient Perl. It's full of his usual blah-blah-blah, but one point in particular amused me:
You see, someday I will start my own company, and I'll decide my own hiring bar. I'll of course be my own company's chief technical officer (wouldn't you?), so I'll decide how I expect people to engineer their software. And there will be no Perl. So there's no need for me to get worked up about its use at Amazon. Whew. I feel so much better.I did start my own company. And we did use Perl. Steve Yegge probably makes as much money in a month at Google as I did by selling that company, but it still gives me a very different perspective. We used Perl because it blurred the boundary I talked about earlier, and because of CPAN. The Comprehensive Perl Archive Network. What a beautiful thing. For all they've done, none of those other, better languages have replicated CPAN.
CPAN is institutional knowledge of a bunch of badass Perl hackers dumped into a central place and mirrored around the world for anyone to use. It is as schizophrenic and disorganized as you might expect from this kind of a resource. But it's also the answer to a big load of common problems that Perl hackers have had. And man, do Perl hackers have problems.
For all of the better-ness of other languages (and I really do like the syntax of those languages better in some ways), they still lack a CPAN. Some of them probably consider this a feature more than it is a bug, which may be the biggest bug of all.
Python and Ruby and their many friends fixed lots of problems with Perl syntax, and maybe even with Perl culture. But while they were busy throwing away the bad syntax Perl inherited from the real scripting languages, they left but the one feature that made Perl more than a novelty, which was not what we could do with it, but what others had already done.
Labels: perl, programming, python, ruby
¶ 11:30 AM Links to this post
Thursday, February 21, 2008
Green Goo in Processing 0135
I'm immensely satisfied Processing's ability to make pictures. Today's installation is something I like to call Green Goo (tm). It's much the same as previous applets in that it uses local rules to update each pixel. In this one, we start with a randomly dispersed field of green stuff on a gray background. Each pixel of green stuff looks at its neighboring pixels, and asks each of them, "how many of your neighboring pixels have green stuff in them?" The pixel then tallies the results and if the results are between eight and eighteen, it stays (or turns) green itself.
The code takes some shortcuts, so the rule is less obvious than I would like, but I'm also running it on a slow laptop, so, alas, I needed a few shortcuts. The results of my noodling around can be seen here.
I'm well on my way toward having quite a gallery of these applets, with zebra stripes, coastlines, cow spots, ant tunnels, and now goo. If anyone would be interested in collaborating on making these more interesting or prettier, please drop me an email: dbrunton@gmail.com. Ha! Google catches spam so well that I can publish that here without even worrying.
--
UPDATE: Click the pic to randomize, press space to start the goo gooing.
The code takes some shortcuts, so the rule is less obvious than I would like, but I'm also running it on a slow laptop, so, alas, I needed a few shortcuts. The results of my noodling around can be seen here.
I'm well on my way toward having quite a gallery of these applets, with zebra stripes, coastlines, cow spots, ant tunnels, and now goo. If anyone would be interested in collaborating on making these more interesting or prettier, please drop me an email: dbrunton@gmail.com. Ha! Google catches spam so well that I can publish that here without even worrying.
--
UPDATE: Click the pic to randomize, press space to start the goo gooing.
Labels: goo, pretty, processing, programming
¶ 10:05 PM Links to this post
Monday, January 28, 2008
Brownian Motion Mash Up
So, after reading dchud's post about the last applet, I got thinking about various mash-ups I could, well, mash.
I'm still playing around with some variations on clustering and obstacles (something he mentioned in conversation), but realized I needed to make the original a little bit dumber before making it any smarter. Thus, I have replaced the previous applet's behavior of moving cells that are over the threshold to a random location. Now, instead, they move Brownian style. Any cell over its threshold simply swaps with a random pick of the eight cells adjacent to it.
Interestingly, it results in a whole new class of pictures.
Actually, I adjusted the ratio of green/magenta cells to be exactly equal, and removed the "empty" cells, since theres no need of them in the Brownian motion context.
The results are here.
The applet works the same as the other- click to randomize, space to start. It takes a lot longer to settle into a fully stable state, but there are obvious structures only a few generations in. I think it looks kind of like an ant farm.
I'm still playing around with some variations on clustering and obstacles (something he mentioned in conversation), but realized I needed to make the original a little bit dumber before making it any smarter. Thus, I have replaced the previous applet's behavior of moving cells that are over the threshold to a random location. Now, instead, they move Brownian style. Any cell over its threshold simply swaps with a random pick of the eight cells adjacent to it.
Interestingly, it results in a whole new class of pictures.
Actually, I adjusted the ratio of green/magenta cells to be exactly equal, and removed the "empty" cells, since theres no need of them in the Brownian motion context.
The results are here.
The applet works the same as the other- click to randomize, space to start. It takes a lot longer to settle into a fully stable state, but there are obvious structures only a few generations in. I think it looks kind of like an ant farm.
Labels: brownian motion, cellular automata, pretty, processing, programming, schelling
¶ 10:15 PM Links to this post
Friday, January 25, 2008
Fun With Processing Language
I've been getting asked a lot (at least twice) about why this site isn't updated more frequently. There are three reasons, really. The first is that I've been doing a lot of writing with a pencil, on paper. I know, shocking. The second is that I've been doing some work on physical things (e.g. soldering iron, circuits, and wood. Yes, the kind of wood that's made from trees). And the last is that it took me a while to figure out how to put Processing Applets on the site. I know, I'm supposed to be good with computers.
The applet I'm about to show you is inspired by a paper written in 1971 by Thomas Schelling, called Dynamic Models of Segregation. It turns out that Schelling's model is a great example of sociology (in which I have a degree) and cellular automata (about which I have an obsession) working together. I'm hardly the first person to notice this.
The basic gist of the program is: there are green cells, magenta cells, and "vacant" cells (white). Each of the green and magenta cells have what I deemed a "socially acceptable" preference for living nearby one another. Specifically, each green cell wants to be in a neighborhood (defined as the cells within three pixels radius) that is at least 1/3 green. Same goes for magenta. If any cell finds this preference violated, it moves to a random empty cell.
The behavior of the system is totally different than the (expected) behavior of an individual. The system segregates quite nicely into green and magenta regions, with a vacant white border in-between. This phenomenon is called emergence. A system displays emergence if its behavior differs from the behavior of its components. Equally as important as the philosophical lesson this applet can teach, is that it makes pretty pictures.
Click the mouse to randomize the picture, and press the space bar to get it going again. It will run on its own the first time through. If you're running Internet Explorer, you may need to click through a few dire warnings to get Java to run.
Without further ado, the Schelling Applet.
The applet I'm about to show you is inspired by a paper written in 1971 by Thomas Schelling, called Dynamic Models of Segregation. It turns out that Schelling's model is a great example of sociology (in which I have a degree) and cellular automata (about which I have an obsession) working together. I'm hardly the first person to notice this.
The basic gist of the program is: there are green cells, magenta cells, and "vacant" cells (white). Each of the green and magenta cells have what I deemed a "socially acceptable" preference for living nearby one another. Specifically, each green cell wants to be in a neighborhood (defined as the cells within three pixels radius) that is at least 1/3 green. Same goes for magenta. If any cell finds this preference violated, it moves to a random empty cell.
The behavior of the system is totally different than the (expected) behavior of an individual. The system segregates quite nicely into green and magenta regions, with a vacant white border in-between. This phenomenon is called emergence. A system displays emergence if its behavior differs from the behavior of its components. Equally as important as the philosophical lesson this applet can teach, is that it makes pretty pictures.
Click the mouse to randomize the picture, and press the space bar to get it going again. It will run on its own the first time through. If you're running Internet Explorer, you may need to click through a few dire warnings to get Java to run.
Without further ado, the Schelling Applet.
Labels: cellular automata, pretty, processing, programming, schelling, sociology
¶ 7:00 PM Links to this post
Monday, September 10, 2007
What Programmers Do
For every post on this site, there are five or ten that I write and never post. My favorite topic for these never-posted masterpieces is to answer this question:
What do programmers do?
Before answering the question, "write programs, of course!" I should stipulate that the person who asks such a question is usually not a programmer (except when it's me asking the question, and then I pretend I'm not a programmer).
I think of a programmer as someone who fills two roles: one of specification, and one of abstraction. Too far in one direction, you're a project manager (my current job). Too far in the other direction, you're an electrical engineer (a job I will never have, but always kind of want). But somewhere in the middle, you do both- you coerce specifics from the humans, and coerce abstraction from the machines.
Specification begins with a need, order, complaint, itch, feeling. Something is too difficult, too slow, or not cool enough. Or maybe someone is bribing the programmer with fancy hardware or money or caffeinated beverages. It ends with some detailed notion of how the user of the resulting abstraction will interact with it.
In reality, the specification process might gloss over that last bit, and remain... "less specific." That's generally bad, for reasons I'll elaborate on in some future note.
Abstraction ends with a solution which matches that specification. The abstraction might be many layers deep, but eventually it allows hardware (tediously specific - allowing a very narrow window of electrical charges to perform all its functions) to interact with a person.
And once again, reality. Specification and Abstraction usually happen at the same time. This is often necessary, for reasons I'll elaborate on in some future note.
So in the end, what programmers do ranges from talking to people to playing with hardware, and just about everything in between.
But our job is named for the part we like the best: write programs, of course!
Before answering the question, "write programs, of course!" I should stipulate that the person who asks such a question is usually not a programmer (except when it's me asking the question, and then I pretend I'm not a programmer).
I think of a programmer as someone who fills two roles: one of specification, and one of abstraction. Too far in one direction, you're a project manager (my current job). Too far in the other direction, you're an electrical engineer (a job I will never have, but always kind of want). But somewhere in the middle, you do both- you coerce specifics from the humans, and coerce abstraction from the machines.
Specification begins with a need, order, complaint, itch, feeling. Something is too difficult, too slow, or not cool enough. Or maybe someone is bribing the programmer with fancy hardware or money or caffeinated beverages. It ends with some detailed notion of how the user of the resulting abstraction will interact with it.
In reality, the specification process might gloss over that last bit, and remain... "less specific." That's generally bad, for reasons I'll elaborate on in some future note.
Abstraction ends with a solution which matches that specification. The abstraction might be many layers deep, but eventually it allows hardware (tediously specific - allowing a very narrow window of electrical charges to perform all its functions) to interact with a person.
And once again, reality. Specification and Abstraction usually happen at the same time. This is often necessary, for reasons I'll elaborate on in some future note.
So in the end, what programmers do ranges from talking to people to playing with hardware, and just about everything in between.
But our job is named for the part we like the best: write programs, of course!
Labels: programming
¶ 4:28 PM Links to this post
Monday, July 30, 2007
Of Machines and Tasks
The programmer lives in a simple world. There are machines, and tasks. The task articulates an abstract need. The machine understands only primitive instructions. Between the two is a great gulf, occupied by the programmer.
The programmer builds a bridge over the gulf from both directions. The task must be specified, and the machine's instructions must be abstracted. The former results in a specification, and the latter in a program.
Hence, "programmer."
A better understanding of the programmer's mindset requires a better understanding of both tasks and machines, of both specification and abstraction.
Imagine this simple task: picking a quince.
In terms of efficiency, climbing the tree to pick its fruit is somewhat less efficient than reaching into the tree with a fruit-picker (e.g. stick) and knocking the fruit down. Later, the fruit-picker could also be used as a back-scratcher, tick-flicker, and fire-poker. The picking, scratching, flicking, and poking are tasks the user delegates to the machine.
I mean, the stick.
The specification process starts soon after.
"No, not that apple, the other one."
"Lower, lower, lower."
"Gently!"
"Get back from that fire."
These are all kinds of specifications. They make the task more specific. The stick-as-machine obviously cannot parse these instructions directly, but fast-forward a few thousand years and see what happens as the stick develops.
The world gets along with better and better sticks until folks in the middle part of the twentieth century come up with the bright idea of a general purpose machine. These machines can not only perform calculations, but also remember the results (as well as the calculation, for that matter). In turn, they can be used to control other, simpler machines (sticks, for instance) via input and output channels.
At the most basic level, these machines understand only a single kind of instruction: an electronic signal is either present or absent. On or off. Modern machines come with a number of primitive combinations of this basic instruction, but only a handful are needed to declare a machine complete, or Turing-complete.
Programmers, in turn combine these primitives into abstractions, to meet a specification. Thus, the bridge is built.
The programmer builds a bridge over the gulf from both directions. The task must be specified, and the machine's instructions must be abstracted. The former results in a specification, and the latter in a program.
Hence, "programmer."
A better understanding of the programmer's mindset requires a better understanding of both tasks and machines, of both specification and abstraction.
Imagine this simple task: picking a quince.
In terms of efficiency, climbing the tree to pick its fruit is somewhat less efficient than reaching into the tree with a fruit-picker (e.g. stick) and knocking the fruit down. Later, the fruit-picker could also be used as a back-scratcher, tick-flicker, and fire-poker. The picking, scratching, flicking, and poking are tasks the user delegates to the machine.
I mean, the stick.
The specification process starts soon after.
"No, not that apple, the other one."
"Lower, lower, lower."
"Gently!"
"Get back from that fire."
These are all kinds of specifications. They make the task more specific. The stick-as-machine obviously cannot parse these instructions directly, but fast-forward a few thousand years and see what happens as the stick develops.
The world gets along with better and better sticks until folks in the middle part of the twentieth century come up with the bright idea of a general purpose machine. These machines can not only perform calculations, but also remember the results (as well as the calculation, for that matter). In turn, they can be used to control other, simpler machines (sticks, for instance) via input and output channels.
At the most basic level, these machines understand only a single kind of instruction: an electronic signal is either present or absent. On or off. Modern machines come with a number of primitive combinations of this basic instruction, but only a handful are needed to declare a machine complete, or Turing-complete.
Programmers, in turn combine these primitives into abstractions, to meet a specification. Thus, the bridge is built.
Labels: book, programming
¶ 12:09 PM Links to this post
