Sharing with all of you a useful link containing an interactive tool to study the concept of Venn diagrams in Sets. I think if the students will be learning this concept with this approach,they will understand it in a better manner and will retain this knowledge for longer.Thanks.http://www.stat.tamu.edu/~west/applets/Venn.html
Jumat, 23 Februari 2007
Sacred Platonics
Hi,
The Platonic solids are five geometric structures found repeating in all life. These repeating geometric patterns are the basic building blocks of creation; the foundation of our physical bodies, plants, animals, minerals, sound frequency, music & language, planets, solar systems, stars, galaxies and Universes. Each shape has a resonance with a particular element:"The Platonic solids were known to the ancient Greeks, and were described by Plato in his Timaeus ca. 350 BC. In this work, Plato equated the Tetrahedron with the "element''' fire, the Cube with earth, the Icosahedron with water, the Octahedron with air, and the Dodecahedron with the stuff of which the constellations and heavens were made" Cube/HexahedronThe cube represents the earth energy and is linked to our root Chakra. The Cube is used for grounding energy. The Tetrahedron represents fire and is linked to the Solar Plexus. The Terahedron is used for manifestation and health. Octahedron represents Air and is linked to the Heart Chakra. The Octahedron is used for manifesting peace, love and spiritual development. Dodecahedron represents the Universe and is linked to the Higher Self. The Dodecahedron is used for meditation and focus.Icosahedron represents water and is linked to the Sacral Chakra. The Icosahedron is used to help us connect to emotions.
Thanks for reading.
Selasa, 20 Februari 2007
A Noogler's View of Google
I know I promised I'd blog once a week, but they killed Simone and now I'm just incredibly distraught. How could they? So I guess I'll recycle some stuff from my internal Google blog, from my first few weeks there, about 20 months ago. Blatant self-plagiarism. What's the blogosphere coming to?
I figured I'd publish it so you know what it was like for me as a newcomer at Google. In case you were planning on sending me a resume.
You know. Just in case.
If you want some real content, check out this funny rant about programming language names. It's a good read. Free karma to the first taker!
Anyway, here are my first few entries in my Google internal blog. Ah, to be a Noogler again...
Important Disclaimer (like, duh) - I don't speak for Google. These opinions are my own.
Remember, this was written for a Google audience, so I left a bunch of obvious stuff out. You'll just have to come see for yourself, I guess.
Hope you like it.
Noogler 101
Hiya.
This is my second day as a Noogler. I figured I'd keep a diary of the experience, so we can all look back and laugh. Not at me, of course. Towards me.
The first morning we got badged, and through a minor communications mishap, I wound up with an expression that looks exactly as if they'd said: "one... two... ack, there's a tarantula on your crotch! *click*" HR has assured me that I can go get another picture taken if I want. Unfortunately, today I am, for lack of a better word, fat. As in, obese from eating waaaaaay too much on my first day. Bloated. Stuffed. I almost yakked yesterday, actually. They didn't prepare me adequately for the experience of being surrounded by yummy free food. I had approximately the same reaction as the kids when they first got to Willy Wonka's. "Everything's edible, even the staircase!" is I think what Willy said. Roughly. And that's how it feels here at Google HQ.
I'm sitting in a temp office with a temp office mate. Both of us are heading up to Kirkland next week, aka the Land Where Everyone Appears to be from Microsoft. My office has a big window, and outside the window there's a printer with a red bull on it that says "Bull". It's a popular printer, and people come by all the time and peer at us while they rifle through their print jobs. We're a regular Noogler Zoo, me and my officemate. We have another officemate, a ghost, who evidently never arrived. His big yellow welcome balloons are mostly deflated, their smiles wrinkled into expressions of concern or balloony dismay. We hope he's OK, wherever he is.
So far things have gone pretty well. The only mishaps have been fairly minor. One is that my officemate and I, who appear in most respects to be identical new hires, got slightly different equipment. His desk had his name, some happy balloons, two 24-inch flatscreen monitors, a fully-configured linux box, a set of office supplies, and misc equipment. My desk had my name, some happy balloons, and a box of kleenex. Fortunately, Tech Stops are almost as easy to find as the bathrooms (meaning about 1/10th as easy to find as food and drink), and they were able to hook me up with a laptop that's worked quite well so far. It was supposed to be a Powerbook, according to my recruiter, and it's actually an IBM stinkpad, but I guess I can wrap it in tinfoil and pretend it's the x86 version. At least I got a nice bag with it. One large enough to hold the roughly 150 feet of cables and adapters that came with it, allowing the laptop to be powered by every conceivable power source, including hooking it up to your cat or dog, if I'm interpreting this one strangely-shaped adapter correctly. (Editor's Note: I now have a spiffy 15-inch Powerbook. It rocks.)
I did do better than my officemate (the real one, not the ghost) in one respect: I got put up in the "Joie de Vivre" Hotel Avante, which is air conditioned and filled with toys and serves free beer and wine every day from 6pm-7:30pm. He evidently got placed in a 2-bedroom apartment, one without air conditioning. Someone generously saw fit to equip it with a roommate, though, and didn't tell either of them they'd be sharing. So my officemate says he walked in to an apartment that was 20 degrees hotter than it was outside, to find his new roommate standing in the kitchen in his underwear, cooking dinner. Imagine their surprise.
Anyway, that's about it for days 1 and 2 of my Noogler experience. I hope to be able to take advantage of some of the perks before I head to Kirkland next week, including jumping in the large vat of brightly-colored plastic balls and hoping nobody's asleep under them. If anything else interesting happens, I'll be sure to post it.
Kidtastrophe
The end of my second day as a Noogler ended in a mini-tragedy, as I floundered around in a big vat of plastic balls like a deranged baby elephant seal.
See, my Google mentor was nice enough to give me a tour of the facility, and he made it a point to show me the big pool of colored plastic balls in the corner of the 2nd floor in bldg 42. He said you could just jump in there any time, although you never knew if someone was actually down there. You know, resting or something. After the imagery of someone taking a nap down there as I did a cannonball, I decided I'd hold off for a bit.
But oddly enough, just last week (the week before I started), I'd mentioned to a friend that I had never been in one of those big containers of plastic balls, the ones you find at fancy kids playgrounds, you know, like at McDonalds or something. I guess I never ran into one until I was over the height limit. I think they said height, although it sounded suspiciously like "weight" to my juvenile ears -- the cotton candy muffled what they were saying a bit. So I'd never gone in one. And here was this big, pretty, free one sitting right on my floor. Calling me, sort of. I just *had* to give it a try.
So towards the end of the day, after most (but by no means all) folks had cleared out, I decided to give it a go. I walked over trying to act casual, and just jumped in. Whee! It was every bit as gratifying as I'd imagined. You know how you always wonder whether you'll be buoyant without water, or whether it's easy to walk around, things like that? All my lifelong kiddie questions about vats of plastic balls were answered. It turns out it's really easy to sink like a stone, and kind of hard to get out. And you look like a total dork in the process. Kiddie quicksand. After about 2 minutes, I'd had my fill for a lifetime, and had finally made it back to the edge. I think I only fatally crushed one ball (um, from the vat) during the excursion.
However, not all of me actually left the vat. No, probably not what you're thinking. I wasn't in there that long. But I did discover I was short exactly one badge. You know, my Google badge. D'oh. I didn't realize this until I was back in my office. That's when the nightmarish elements of this real-life story began.
I walked back, trying to look nonchalant, and saw there were about eight guys playing pool at the large pool table that's located approximately 2 feet from the ball vat. Ahem. So, trying to stay casual, I walked around them and carefully got back into the vat. They all stopped playing and just stared at me, as if I'd decided to crawl in the refrigerator. I waved. They didn't wave back. They weren't antagonistic or anything; they were just sort of dumbfounded, and were all staring at me, this fully grown (overly grown, actually) adult standing up to his waist in a tub of plastic balls they'd probably never seen anyone in before.
I squatted down and started thrashing around, and it dawned on one of the sharper ones that I was looking for something. "Vat are you looking fer?" He had a nice accent, maybe Austrian or German. Now everyone was really curious. The pool game was pretty much dead. I wished fervently that I was somewhere far away, maybe Austria or Germany.
"I'll give you two guesses," I said, pretending like I was some sort of career ball-vat guy.
No guesses emerged from the crowd.
"OK. I'm looking for my badge, which fell in here. Happy?" They nodded, and half of them shook their heads sadly in the internationally recognized head gesture for "you poor dumb noogler". They went back to playing pool, a game which, if you'll recall, only requires one person to be paying attention at a time. The rest stood around just staring at me, wondering if I'd find it.
"It should be near the bottom by now, don't you think?" said another smart-looking one.
"Gasp urf unk" said I, thrashing around with my hands and feet. It turns out you can only brush the bottom of the vat (which is only about 3 feet deep) if you get yourself almost completely submerged. Otherwise the balls are too heavy to move very far, and all you can do is poke a fingertip-sized area. And the dude was right; the badge was probably near the bottom. Probably near an edge (the math just kinda works out that way), and the balls are much harder to move around near the edges.
I spent a *long* time in there, maybe 15 minutes, during which time I became more tired of plastic balls than I'd ever have thought possible. I eventually emerged, miserable and defeated. I'd recovered 2 unopened packs of gum, several coins, some rubber bands and some binder clips, but no badge. I was starting to think I'd find Jimmy Hoffa's badge before I ever found mine. I *really* didn't want to be stared at anymore, although on the plus side, they all knew my face well enough by then to spot my badge from 100 paces.
So I went home, and got a new badge in the morning, and even a new badge picture. The old one is deactivated, and will rest in peace, more secure than the Heart of the Ocean, lying at the bottom of that big plastic tub of balls. You're welcome to try to get it. In fact, I dare you. I'll even come and stare.
End of Week One
Today I went to a tech talk. It looked like it was going to be exciting, but evidently signing up to give a tech talk does not, as one might conjecture, automatically make one a good tech-talker. The problem was that most of us were Nooglers, and the presenters didn't give us much context. They jumped immediately down to the lowest implementation details of their project, and we didn't know what the hell it was for, let alone the other projects they constantly cited. It was rough going. After about 15 minutes, several people in the audience were visibly asleep. Since nobody had started to snore audibly yet (which would have livened things up), I "snuck" out.
I do have to quote "snuck", though, because the act involved tripping over at least two people in the 3rd row back, so my exit couldn't really have gone unnoticed to the presenters. I tried the clever gimmick of glancing at my watch, as if I just happened to need to be somewhere else at exactly 12:47pm. Unfortunately I wasn't wearing a watch, so it didn't go over exactly as planned. Oh well.
I walked outside, and into a different world. There was live music playing, with Googlers everywhere on the lawn, and it was a beautiful, sunny, breezy day. There was a huge barbeque going, with juicy bratwursts and other delicious-smelling food. The band appeared to be playing on some sort of period-instruments, and the music was great. Well, I'm a sucker for that kind of music. It sure was nice to be outside, away from the slides and snores.
I ran into a guy I knew a little. I'd interviewed him a few months ago, for my old company, and he'd turned us down to go to Google. We were bummed, since he'd seemed to be the brightest person in his graduating class. I remembered he'd passed my interview in about 12 minutes, so I'd spent the rest of the time chatting with him about how college hires are making their decisions these days. His insights were really the beginning of the mini-investigation I did that wound up with me applying to Google.
That "investigation" started by chatting with college hires about why they were turning us down. Then I looked a little further, and a little further, and discovered that Google has a sort of event horizon, beyond which you're inevitably sucked in. Anyone at another company who looks hard enough into why people choose Google will ultimately apply to Google, if they have the courage. And it's a scary thing, too -- Google's recruiting-marketing has reached the point where a lot of smart, experienced people wonder whether they'd be able to get an offer.
Anyway, I said 'hi' to the guy, who remembered me, and we laughed a little about the whole situation. Then I headed back to my office.
Unfortunately, I have a remarkable propensity for getting lost on the campus, or at least disoriented. I realized I'd gone in the wrong direction (towards the food, as if that outcome were anything but preordained), and to get to my office, I'd have to walk back past the tech talk that I'd "snuck" out of. Oops. So with as little chalance as I could muster, I walked quickly by the room. As I went by, I glanced in, and as far as I could tell, they were on the same slide as when I left. I bolted.
Right now I'm sitting in a massage chair, looking out over what seems to be a big park or golf course. Sun's shining. Campus is beautiful. I'm sad to be leaving. Why can't Mountain View be in Seattle?
Tune in next time for my exploration of the wonderful world of the Kirkland Design Center, which you should check out on Google Earth! (The office looks taller in real life.)
Incidentally, a bit of good news: someone found my badge, the one I thought was lost forever in the tub of plastic balls in Building 42. I happened to be walking by the pool table nearby when some guy pointed it out to me. The badge was sitting on a little table between the ball vat and the pool table. I'm not terribly surprised, in retrospect, since I've noticed people evidently spend a lot of time in that tub -- talking on cell phones, or solving complex mathematical problems in their heads, or rooting around like starving boars in a full dumpster looking for lost wallets and wedding rings and so on. I guess it was only a matter of time.
Settling In
Well, I've spent a few food-filled weeks in the Land Where Everyone's From Microsoft, so I figured it was time to blog again.
They really are, you know. From Microsoft. You can walk up to anyone in the Kirkland Office, even a potted plant, and say: "So! I'll bet you a million dollars you're not from Microsoft." And 80% of the time, they get all dejected and say: "Yeah, I was there." They're not even happy they won the bet.
So then I say: "Wow. Microsoft. That must have been cool." I get this evil gleam in my eye when I say it, but they don't notice since they're all dejected and looking at their shoes. (They're $1000 shoes, but they're still dejected. I guess if you're dejected, looking at your $1000 shoes can cheer you up a little.)
And they say: "Well, it was cool! Except we never launched our project. And we hated all the other teams. And they hated us. And each other. And our customers kind of hated our project too. And we couldn't make any forward progress, because we were crushed under the weight of blah blah blah..." They tell me their whole, sad, shaggy-dog story, and it's always the same. Project was cool, never launched it, everyone hates each other. (Editor's Note: actual percentages and experiences may vary. Some shoe prices inflated for dramatic effect.)
It's really cheery around here, I tell ya.
Actually it is really cheery, because everyone knows they're not at their old company anymore. If you ask anyone: "are you glad you came to Google?" They always brighten up instantly and say: "oh, hell yeah! I'm actually writing code!"
I'm actually editing these conversations down a bit, because what they really sound like is this:
Me: "Armph omph mmfph *gulp* So! *chomp* *chew* *chew* *mrmph* You from Microsoft?"
Them: "... mmmm *chew* *chew* mmmm *chew* *chew* .... mmmm *chew* mmm..."
Me: "Caught you with your mouth full, eh? Sorry. *CHOMP* *chew* *chew* *chew* ..."
Them: "... *gulp* yeah. sucked there. *CHWOMPH* omph mmfph *chew* *chew* ..."
And so on. I assume Google's master plan is pretty much the same as the witch's from Hansel and Gretel:
I mean, come on, it's pretty obvious they're going to eat us. Geez, we've all read fairy tales before. Nobody just gives you a bunch of free food for as long as you want without killing you and eating you. Like, duh. But I can vouch for Kirkland: when the Feasting Day OKR comes around, we'll be ready. I myself would probably go well with cranberry sauce.
Anyway, until then, the main pastime, other than researching how the Romans managed to eat several meals at one sitting, is Foosball. This is a game I've been introduced to since I came to Kirkland. I've seen it before, and always thought it looked kind of lame, but that just shows you what I know. Foosball is a way of life around here. Which makes it... not lame, see?
I can't quite figure out whether it's popular because it's the only thing to do other than stuff your face (except on Mondays when you can poll the massage calendar hoping someone will cancel) or if it's actually fun in its own right. You could do a scientific experiment, and bring some other game in and put it near the foosball table. But if we ever had the space and the budget for another game, we'd get another foosball table. (Editor's Note, Feb 19 2007 - we now have two tornado tables, air hockey, a pool table, darts, and other stuff. But foosball is still by far the most popular.)
I think Google would probably approve another table, even though various academic studies have shown that on the Grand Scale of Calorie-Burning Activities, playing foosball falls somewhere between "comatose" and "deceased". Most of the calories burned playing foosball are spent contracting your stomach muscles, which happens when you're laughing really really hard, because I just scored on myself again. Believe me, it's not possible to be worse at foosball than I am. I think I'm the only person who's necessitated consulting the rules to see whether it counts if you serve, then score on yourself without the ball touching the other player's men.
Other than eating and foosball, punctuated by the occasional multi-hour bout of intense programming, the major fun activities in Kirkland include:
* having construction workers watch you go to the bathroom. They sometimes offer helpful advice. ("You missed a spot." "Thanks.") They're putting in showers, and the workers use the toilet stalls as storage lockers.
* sitting in one of the $5000 massage chairs and punching buttons randomly, since the instructions are all in Japanese.
* uh, and other stuff that's way too fun to tell you about.
Oh, who am I kidding. All we do for fun is play foosball. I don't think the showers are going to add too many new fun new activities -- at least I seriously hope they don't -- so it looks like foosball is the pastime of choice for now.
In the meantime, I think I'll go see what's in the fridge. MMMMmmmmm, looks like milk and pancakes, with sugar, apples, and nuts. They're so nice to us!
I figured I'd publish it so you know what it was like for me as a newcomer at Google. In case you were planning on sending me a resume.
You know. Just in case.
If you want some real content, check out this funny rant about programming language names. It's a good read. Free karma to the first taker!
Anyway, here are my first few entries in my Google internal blog. Ah, to be a Noogler again...
Important Disclaimer (like, duh) - I don't speak for Google. These opinions are my own.
Remember, this was written for a Google audience, so I left a bunch of obvious stuff out. You'll just have to come see for yourself, I guess.
Hope you like it.
Noogler 101
Tuesday, June 14, 2005
Hiya.
This is my second day as a Noogler. I figured I'd keep a diary of the experience, so we can all look back and laugh. Not at me, of course. Towards me.
The first morning we got badged, and through a minor communications mishap, I wound up with an expression that looks exactly as if they'd said: "one... two... ack, there's a tarantula on your crotch! *click*" HR has assured me that I can go get another picture taken if I want. Unfortunately, today I am, for lack of a better word, fat. As in, obese from eating waaaaaay too much on my first day. Bloated. Stuffed. I almost yakked yesterday, actually. They didn't prepare me adequately for the experience of being surrounded by yummy free food. I had approximately the same reaction as the kids when they first got to Willy Wonka's. "Everything's edible, even the staircase!" is I think what Willy said. Roughly. And that's how it feels here at Google HQ.
I'm sitting in a temp office with a temp office mate. Both of us are heading up to Kirkland next week, aka the Land Where Everyone Appears to be from Microsoft. My office has a big window, and outside the window there's a printer with a red bull on it that says "Bull". It's a popular printer, and people come by all the time and peer at us while they rifle through their print jobs. We're a regular Noogler Zoo, me and my officemate. We have another officemate, a ghost, who evidently never arrived. His big yellow welcome balloons are mostly deflated, their smiles wrinkled into expressions of concern or balloony dismay. We hope he's OK, wherever he is.
So far things have gone pretty well. The only mishaps have been fairly minor. One is that my officemate and I, who appear in most respects to be identical new hires, got slightly different equipment. His desk had his name, some happy balloons, two 24-inch flatscreen monitors, a fully-configured linux box, a set of office supplies, and misc equipment. My desk had my name, some happy balloons, and a box of kleenex. Fortunately, Tech Stops are almost as easy to find as the bathrooms (meaning about 1/10th as easy to find as food and drink), and they were able to hook me up with a laptop that's worked quite well so far. It was supposed to be a Powerbook, according to my recruiter, and it's actually an IBM stinkpad, but I guess I can wrap it in tinfoil and pretend it's the x86 version. At least I got a nice bag with it. One large enough to hold the roughly 150 feet of cables and adapters that came with it, allowing the laptop to be powered by every conceivable power source, including hooking it up to your cat or dog, if I'm interpreting this one strangely-shaped adapter correctly. (Editor's Note: I now have a spiffy 15-inch Powerbook. It rocks.)
I did do better than my officemate (the real one, not the ghost) in one respect: I got put up in the "Joie de Vivre" Hotel Avante, which is air conditioned and filled with toys and serves free beer and wine every day from 6pm-7:30pm. He evidently got placed in a 2-bedroom apartment, one without air conditioning. Someone generously saw fit to equip it with a roommate, though, and didn't tell either of them they'd be sharing. So my officemate says he walked in to an apartment that was 20 degrees hotter than it was outside, to find his new roommate standing in the kitchen in his underwear, cooking dinner. Imagine their surprise.
Anyway, that's about it for days 1 and 2 of my Noogler experience. I hope to be able to take advantage of some of the perks before I head to Kirkland next week, including jumping in the large vat of brightly-colored plastic balls and hoping nobody's asleep under them. If anything else interesting happens, I'll be sure to post it.
Kidtastrophe
Wednesday, June 15, 2005
The end of my second day as a Noogler ended in a mini-tragedy, as I floundered around in a big vat of plastic balls like a deranged baby elephant seal.
See, my Google mentor was nice enough to give me a tour of the facility, and he made it a point to show me the big pool of colored plastic balls in the corner of the 2nd floor in bldg 42. He said you could just jump in there any time, although you never knew if someone was actually down there. You know, resting or something. After the imagery of someone taking a nap down there as I did a cannonball, I decided I'd hold off for a bit.
But oddly enough, just last week (the week before I started), I'd mentioned to a friend that I had never been in one of those big containers of plastic balls, the ones you find at fancy kids playgrounds, you know, like at McDonalds or something. I guess I never ran into one until I was over the height limit. I think they said height, although it sounded suspiciously like "weight" to my juvenile ears -- the cotton candy muffled what they were saying a bit. So I'd never gone in one. And here was this big, pretty, free one sitting right on my floor. Calling me, sort of. I just *had* to give it a try.
So towards the end of the day, after most (but by no means all) folks had cleared out, I decided to give it a go. I walked over trying to act casual, and just jumped in. Whee! It was every bit as gratifying as I'd imagined. You know how you always wonder whether you'll be buoyant without water, or whether it's easy to walk around, things like that? All my lifelong kiddie questions about vats of plastic balls were answered. It turns out it's really easy to sink like a stone, and kind of hard to get out. And you look like a total dork in the process. Kiddie quicksand. After about 2 minutes, I'd had my fill for a lifetime, and had finally made it back to the edge. I think I only fatally crushed one ball (um, from the vat) during the excursion.
However, not all of me actually left the vat. No, probably not what you're thinking. I wasn't in there that long. But I did discover I was short exactly one badge. You know, my Google badge. D'oh. I didn't realize this until I was back in my office. That's when the nightmarish elements of this real-life story began.
I walked back, trying to look nonchalant, and saw there were about eight guys playing pool at the large pool table that's located approximately 2 feet from the ball vat. Ahem. So, trying to stay casual, I walked around them and carefully got back into the vat. They all stopped playing and just stared at me, as if I'd decided to crawl in the refrigerator. I waved. They didn't wave back. They weren't antagonistic or anything; they were just sort of dumbfounded, and were all staring at me, this fully grown (overly grown, actually) adult standing up to his waist in a tub of plastic balls they'd probably never seen anyone in before.
I squatted down and started thrashing around, and it dawned on one of the sharper ones that I was looking for something. "Vat are you looking fer?" He had a nice accent, maybe Austrian or German. Now everyone was really curious. The pool game was pretty much dead. I wished fervently that I was somewhere far away, maybe Austria or Germany.
"I'll give you two guesses," I said, pretending like I was some sort of career ball-vat guy.
No guesses emerged from the crowd.
"OK. I'm looking for my badge, which fell in here. Happy?" They nodded, and half of them shook their heads sadly in the internationally recognized head gesture for "you poor dumb noogler". They went back to playing pool, a game which, if you'll recall, only requires one person to be paying attention at a time. The rest stood around just staring at me, wondering if I'd find it.
"It should be near the bottom by now, don't you think?" said another smart-looking one.
"Gasp urf unk" said I, thrashing around with my hands and feet. It turns out you can only brush the bottom of the vat (which is only about 3 feet deep) if you get yourself almost completely submerged. Otherwise the balls are too heavy to move very far, and all you can do is poke a fingertip-sized area. And the dude was right; the badge was probably near the bottom. Probably near an edge (the math just kinda works out that way), and the balls are much harder to move around near the edges.
I spent a *long* time in there, maybe 15 minutes, during which time I became more tired of plastic balls than I'd ever have thought possible. I eventually emerged, miserable and defeated. I'd recovered 2 unopened packs of gum, several coins, some rubber bands and some binder clips, but no badge. I was starting to think I'd find Jimmy Hoffa's badge before I ever found mine. I *really* didn't want to be stared at anymore, although on the plus side, they all knew my face well enough by then to spot my badge from 100 paces.
So I went home, and got a new badge in the morning, and even a new badge picture. The old one is deactivated, and will rest in peace, more secure than the Heart of the Ocean, lying at the bottom of that big plastic tub of balls. You're welcome to try to get it. In fact, I dare you. I'll even come and stare.
End of Week One
Friday, June 17, 2005
Today I went to a tech talk. It looked like it was going to be exciting, but evidently signing up to give a tech talk does not, as one might conjecture, automatically make one a good tech-talker. The problem was that most of us were Nooglers, and the presenters didn't give us much context. They jumped immediately down to the lowest implementation details of their project, and we didn't know what the hell it was for, let alone the other projects they constantly cited. It was rough going. After about 15 minutes, several people in the audience were visibly asleep. Since nobody had started to snore audibly yet (which would have livened things up), I "snuck" out.
I do have to quote "snuck", though, because the act involved tripping over at least two people in the 3rd row back, so my exit couldn't really have gone unnoticed to the presenters. I tried the clever gimmick of glancing at my watch, as if I just happened to need to be somewhere else at exactly 12:47pm. Unfortunately I wasn't wearing a watch, so it didn't go over exactly as planned. Oh well.
I walked outside, and into a different world. There was live music playing, with Googlers everywhere on the lawn, and it was a beautiful, sunny, breezy day. There was a huge barbeque going, with juicy bratwursts and other delicious-smelling food. The band appeared to be playing on some sort of period-instruments, and the music was great. Well, I'm a sucker for that kind of music. It sure was nice to be outside, away from the slides and snores.
I ran into a guy I knew a little. I'd interviewed him a few months ago, for my old company, and he'd turned us down to go to Google. We were bummed, since he'd seemed to be the brightest person in his graduating class. I remembered he'd passed my interview in about 12 minutes, so I'd spent the rest of the time chatting with him about how college hires are making their decisions these days. His insights were really the beginning of the mini-investigation I did that wound up with me applying to Google.
That "investigation" started by chatting with college hires about why they were turning us down. Then I looked a little further, and a little further, and discovered that Google has a sort of event horizon, beyond which you're inevitably sucked in. Anyone at another company who looks hard enough into why people choose Google will ultimately apply to Google, if they have the courage. And it's a scary thing, too -- Google's recruiting-marketing has reached the point where a lot of smart, experienced people wonder whether they'd be able to get an offer.
Anyway, I said 'hi' to the guy, who remembered me, and we laughed a little about the whole situation. Then I headed back to my office.
Unfortunately, I have a remarkable propensity for getting lost on the campus, or at least disoriented. I realized I'd gone in the wrong direction (towards the food, as if that outcome were anything but preordained), and to get to my office, I'd have to walk back past the tech talk that I'd "snuck" out of. Oops. So with as little chalance as I could muster, I walked quickly by the room. As I went by, I glanced in, and as far as I could tell, they were on the same slide as when I left. I bolted.
Right now I'm sitting in a massage chair, looking out over what seems to be a big park or golf course. Sun's shining. Campus is beautiful. I'm sad to be leaving. Why can't Mountain View be in Seattle?
Tune in next time for my exploration of the wonderful world of the Kirkland Design Center, which you should check out on Google Earth! (The office looks taller in real life.)
Incidentally, a bit of good news: someone found my badge, the one I thought was lost forever in the tub of plastic balls in Building 42. I happened to be walking by the pool table nearby when some guy pointed it out to me. The badge was sitting on a little table between the ball vat and the pool table. I'm not terribly surprised, in retrospect, since I've noticed people evidently spend a lot of time in that tub -- talking on cell phones, or solving complex mathematical problems in their heads, or rooting around like starving boars in a full dumpster looking for lost wallets and wedding rings and so on. I guess it was only a matter of time.
Settling In
Sunday, July 17, 2005
Well, I've spent a few food-filled weeks in the Land Where Everyone's From Microsoft, so I figured it was time to blog again.
They really are, you know. From Microsoft. You can walk up to anyone in the Kirkland Office, even a potted plant, and say: "So! I'll bet you a million dollars you're not from Microsoft." And 80% of the time, they get all dejected and say: "Yeah, I was there." They're not even happy they won the bet.
So then I say: "Wow. Microsoft. That must have been cool." I get this evil gleam in my eye when I say it, but they don't notice since they're all dejected and looking at their shoes. (They're $1000 shoes, but they're still dejected. I guess if you're dejected, looking at your $1000 shoes can cheer you up a little.)
And they say: "Well, it was cool! Except we never launched our project. And we hated all the other teams. And they hated us. And each other. And our customers kind of hated our project too. And we couldn't make any forward progress, because we were crushed under the weight of blah blah blah..." They tell me their whole, sad, shaggy-dog story, and it's always the same. Project was cool, never launched it, everyone hates each other. (Editor's Note: actual percentages and experiences may vary. Some shoe prices inflated for dramatic effect.)
It's really cheery around here, I tell ya.
Actually it is really cheery, because everyone knows they're not at their old company anymore. If you ask anyone: "are you glad you came to Google?" They always brighten up instantly and say: "oh, hell yeah! I'm actually writing code!"
I'm actually editing these conversations down a bit, because what they really sound like is this:
Me: "Armph omph mmfph *gulp* So! *chomp* *chew* *chew* *mrmph* You from Microsoft?"
Them: "... mmmm *chew* *chew* mmmm *chew* *chew* .... mmmm *chew* mmm..."
Me: "Caught you with your mouth full, eh? Sorry. *CHOMP* *chew* *chew* *chew* ..."
Them: "... *gulp* yeah. sucked there. *CHWOMPH* omph mmfph *chew* *chew* ..."
And so on. I assume Google's master plan is pretty much the same as the witch's from Hansel and Gretel:
Hansel, who liked the taste of the roof, tore down a great piece of it, and Gretel pushed out the whole of one round window-pane, sat down, and enjoyed herself with it. Suddenly the door opened, and a woman as old as the hills, who supported herself on crutches, came creeping out. Hansel and Gretel were so terribly frightened that they let fall what they had in their hands.
The old woman, however, nodded her head, and said, "Oh, you dear children, who has brought you here. Do come in, and stay with me. No harm shall happen to you." She took them both by the hand, and led them into her little house. Then good food was set before them, milk and pancakes, with sugar, apples, and nuts. Afterwards two pretty little beds were covered with clean white linen, and Hansel and Gretel lay down in them, and thought they were in heaven.
The old woman had only pretended to be so kind. She was in reality a wicked witch, who lay in wait for children, and had only built the little house of bread in order to entice them there. When a child fell into her power, she killed it, cooked and ate it, and that was a feast day with her.
I mean, come on, it's pretty obvious they're going to eat us. Geez, we've all read fairy tales before. Nobody just gives you a bunch of free food for as long as you want without killing you and eating you. Like, duh. But I can vouch for Kirkland: when the Feasting Day OKR comes around, we'll be ready. I myself would probably go well with cranberry sauce.
Anyway, until then, the main pastime, other than researching how the Romans managed to eat several meals at one sitting, is Foosball. This is a game I've been introduced to since I came to Kirkland. I've seen it before, and always thought it looked kind of lame, but that just shows you what I know. Foosball is a way of life around here. Which makes it... not lame, see?
I can't quite figure out whether it's popular because it's the only thing to do other than stuff your face (except on Mondays when you can poll the massage calendar hoping someone will cancel) or if it's actually fun in its own right. You could do a scientific experiment, and bring some other game in and put it near the foosball table. But if we ever had the space and the budget for another game, we'd get another foosball table. (Editor's Note, Feb 19 2007 - we now have two tornado tables, air hockey, a pool table, darts, and other stuff. But foosball is still by far the most popular.)
I think Google would probably approve another table, even though various academic studies have shown that on the Grand Scale of Calorie-Burning Activities, playing foosball falls somewhere between "comatose" and "deceased". Most of the calories burned playing foosball are spent contracting your stomach muscles, which happens when you're laughing really really hard, because I just scored on myself again. Believe me, it's not possible to be worse at foosball than I am. I think I'm the only person who's necessitated consulting the rules to see whether it counts if you serve, then score on yourself without the ball touching the other player's men.
Other than eating and foosball, punctuated by the occasional multi-hour bout of intense programming, the major fun activities in Kirkland include:
* having construction workers watch you go to the bathroom. They sometimes offer helpful advice. ("You missed a spot." "Thanks.") They're putting in showers, and the workers use the toilet stalls as storage lockers.
* sitting in one of the $5000 massage chairs and punching buttons randomly, since the instructions are all in Japanese.
* uh, and other stuff that's way too fun to tell you about.
Oh, who am I kidding. All we do for fun is play foosball. I don't think the showers are going to add too many new fun new activities -- at least I seriously hope they don't -- so it looks like foosball is the pastime of choice for now.
In the meantime, I think I'll go see what's in the fridge. MMMMmmmmm, looks like milk and pancakes, with sugar, apples, and nuts. They're so nice to us!
Senin, 19 Februari 2007
Mnemonics as an aid of learning
1)Pi mnemonics are memory aids for remembering the first few decimal digits of Pi:
3.1415926535897932384626433....
The most common type of mnemonic is the word-length mnemonic in which the number of letters in each word corresponds to a digit. This simple one gives pi to seven decimal places:
How I wish I could calculate pi.
May I have a large container of coffee?
Counting the letters of each word gives you the value of pi to 7 places.
2)Please Excuse My Dear Aunt Sally
Parentheses, Exponents, Multiplication, Division, Addition, Subtraction
3) Lucky Cows Drink Milk
The ascending order of Roman numerals: LCDM ...
3.1415926535897932384626433....
The most common type of mnemonic is the word-length mnemonic in which the number of letters in each word corresponds to a digit. This simple one gives pi to seven decimal places:
How I wish I could calculate pi.
May I have a large container of coffee?
Counting the letters of each word gives you the value of pi to 7 places.
2)Please Excuse My Dear Aunt Sally
Parentheses, Exponents, Multiplication, Division, Addition, Subtraction
3) Lucky Cows Drink Milk
The ascending order of Roman numerals: LCDM ...
Minggu, 18 Februari 2007
Utility Blogging
I love my profession of teaching and particularly love the new challenges that learning with digital tools and upcoming technologies brings. “Learning new things” is the motto of my life. I think Learning/Implementing new strategies for teaching/learning ,utilising e-tools for preparing the content, using web resources for sharing etc. will definitely make the teaching/learning process more productive and effective. Today I will share with you my experience of creating a blog and its utility. Blogging has allowed me to reflect. It is an informal way of professional growth.By means of it I am able to exchange my experiences and thoughts with others. I write for myself as well as for others. I like to reflect on what I have found online and also to share new ideas and findings with others. It helps to assimilate the new knowledge by writing about it and preserving the same in a blog post for future reference. Blogging has given me a chance to convey my piece/thoughts/experiences etc in my own way.I got freedom to express my ideas in my own way which bring in a feeling of fulfillment and confidence .
You may use your blog to...
• reflect on teaching experiences.
• write a description of a particular topic.
• collaborate with other teachers.
• describe what worked during a lesson and what didn’t.
• provide teaching tips for other teachers.
• write about something you learned from another teacher.
• explore important teaching and learning issues .
• write a description of a particular topic.
• collaborate with other teachers.
• describe what worked during a lesson and what didn’t.
• provide teaching tips for other teachers.
• write about something you learned from another teacher.
• explore important teaching and learning issues .
Visit my class blog http://mykhmsmathclass.blogspot.com
Rabu, 14 Februari 2007
Open Source Software
Open source softwares are creating waves in education. I am exploring and working on it since December 2006. I have realised that it has a lot of potential to transform the traditional methods of teaching/learning mathematics. I believe learning in life ia a never ending process. The time has arrived that we teachers have to take up bold initiatives to take a turn in educating the students only through chalk and talk. I have tried working on various math tools like Geogebra, C.a.R , Graph sketcher and many more .These tools are really effective.
1.Graph Sketcher lets you make elegant and precise graphs in seconds, simply by sketching what you want.I think if we incorporate technology in math education it can create miracles. As you all know it is very tedious to draw graphs on a board if done manually.With the help of these kind of softwares we can create graphs in fraction of seconds .
2. GeoGebra is a free and multi-platform dynamic mathematics software for schools that joins geometry, algebra and calculus.
What is GeoGebra? See About.
What does GeoGebra look like? See Screenshots and Examples.
What can I do with GeoGebra? See Help and GeoGebraWiki.
Where do I get GeoGebra? See WebStart and Download.
Chek out the following link for more details.
http://www.geogebra.org/cms/
You can explore the following links to see the readymade lessons.
http://math247.jot.com/GeoGebrahttp://math247.jot.com/WikiHome/Library/How%20to%20Mathcasts/Learn%20and%20Use%20GeoGebra
3. Graph is an open source application used to draw mathematical graphs in a coordinate system. Visit its official site and know more about it.http://www.padowan.dk/graph/I find this software very interesting and useful in doing analysis of graphs. It saves time and the students would be able to analyse so many graphs in one period of duration 35 minutes.
4. Free mind Mapping software
This one is really a very interesting and useful software. Know about it in detail from the following link.http://freemind.sourceforge.net/wiki/index.php/Main_PageI think for recapitulation of a topic in mathematics, we teachers can prepare mind maps using this software and also it would help us in keeping a track of what all we have done in a chapter and what is left uncovered? Also, mindmaps may be utilised while teaching the history of a topic, suggesting useful study links to the students, organising lesson plans etc. I find it very interesting and useful.
5.SpeQ
SpeQ is a small, extensive mathematics program with a simple, intuitive interface. All calculations are entered in a sheet. In there you can freely add, edit and execute all calculations. You can define variables and functions, and plot graphs of your functions. You can save your calculations for later re-use.
Know more about it...
http://www.speqmath.com/
1.Graph Sketcher lets you make elegant and precise graphs in seconds, simply by sketching what you want.I think if we incorporate technology in math education it can create miracles. As you all know it is very tedious to draw graphs on a board if done manually.With the help of these kind of softwares we can create graphs in fraction of seconds .
2. GeoGebra is a free and multi-platform dynamic mathematics software for schools that joins geometry, algebra and calculus.
What is GeoGebra? See About.
What does GeoGebra look like? See Screenshots and Examples.
What can I do with GeoGebra? See Help and GeoGebraWiki.
Where do I get GeoGebra? See WebStart and Download.
Chek out the following link for more details.
http://www.geogebra.org/cms/
You can explore the following links to see the readymade lessons.
http://math247.jot.com/GeoGebrahttp://math247.jot.com/WikiHome/Library/How%20to%20Mathcasts/Learn%20and%20Use%20GeoGebra
3. Graph is an open source application used to draw mathematical graphs in a coordinate system. Visit its official site and know more about it.http://www.padowan.dk/graph/I find this software very interesting and useful in doing analysis of graphs. It saves time and the students would be able to analyse so many graphs in one period of duration 35 minutes.
4. Free mind Mapping software
This one is really a very interesting and useful software. Know about it in detail from the following link.http://freemind.sourceforge.net/wiki/index.php/Main_PageI think for recapitulation of a topic in mathematics, we teachers can prepare mind maps using this software and also it would help us in keeping a track of what all we have done in a chapter and what is left uncovered? Also, mindmaps may be utilised while teaching the history of a topic, suggesting useful study links to the students, organising lesson plans etc. I find it very interesting and useful.
5.SpeQ
SpeQ is a small, extensive mathematics program with a simple, intuitive interface. All calculations are entered in a sheet. In there you can freely add, edit and execute all calculations. You can define variables and functions, and plot graphs of your functions. You can save your calculations for later re-use.
Know more about it...
http://www.speqmath.com/
Sabtu, 10 Februari 2007
The Next Big Language
| There seems to be a long period of initial obscurity for any new language. Then after that comes a long period of semi-obscurity, followed by total obscurity. —Paul Bissex |
Note: after I wrote this entry, one or two commenters speculated that I might be talking about something Google is doing. They're barking up the wrong tree: I may not be the smartest feller ever to fall off the cabbage truck, but I'm not -that- stupid. The speculation in this blog is all based on stuff I've read on the net. It's purely my own ideas and opinions, and I don't speak for Google (nor in today's entry, even -about- Google). You'll have to look beyond Google for clues about NBL. Enjoy!
People are always asking me to comment on their new programming language they're designing. I don't know about you, but I find that pretty funny, given the general trend of my comments on existing languages. I mean, if you saw someone walking around kicking people directly in the metaphorical groin, would you go up and beg them to do it to you too?
And I feel bad about giving them my feedback, because I don't want to discourage them. It's just that nobody will ever, ever use their language. The odds are impossibly stacked against it. Not to be discouraging, of course.
But people are still always trying to make new languages, because we have yet to see a language that is (a) popular and (b) doesn't suck. Do you disagree? If so, I don't mind. It just means your standards aren't as high as mine. Nothing wrong with that.
Back when I was in the Navy, just out of boot camp, an otherwise entirely forgettable petty officer first class instructor of ours offered us, unasked and free of charge, his sage advice on how to pick up women at a bar: "Go ugly early." With this declaration, he had made it clear that he and I thought rather differently about certain things in life. But I had to hand it to him: here was a man of conviction. He didn't care what other people thought of him, or for that matter, what he thought of himself. He had defined his philosophy and he was sticking with it.
And in a sense, he taught me a valuable lesson, although it's not the one he probably thought he was teaching me. I'll pass it on to you, unasked and free of charge. If you want to spare yourself a lot of angst in deciding which programming language to use, then I recommend this simple rule: Go ugly early. C++ will go out with you in a heartbeat.
For my part, I want to encourage people to make their own languages, because doing it makes you a world-class programmer. Seriously. Not just a better programmer, but a best programmer. I've said it before, and I'm sticking with it: having a deep understanding of compilers is what separates the wheat from the chaff. I say that without having the slightest frigging clue what "chaff" is, but let's assume it's some sort of inferior wheat substitute, possibly made from tofu.
But I really need to stop spending time telling people individually why their languages are doomed to fail. Instead, I'll summarize it in today's blog entry.
Summary: your language is doomed to fail, with probability 1 minus epsilon. If you fell off a thirty-story building, you might survive (anyone else watch the last episode of Heroes? wasn't that an awesome scene?) but for all practical purposes the odds are nil.
Before I go into slightly more detail, I'll let you in on a secret. Just between you and me. Nobody else will know but us. The secret is that last week I got an insider's tip: I know what the Next Big Language is going to be.
You probably imagine some sort of Old Boys Network that's responsible for deciding what we unwashed masses are going to use next. You know, a bunch of corporate executive cigar-chomping porcine thugs sitting on each others' boards, conspiring and maneuvering to wheel and deal with mergers and consolidations, and suddenly language XYZ is endorsed by all the big companies at once, so you have to learn it or you'll get fired and deported and have to go live on the streets in some fly-specked third world country where, ironically, you don't speak the language there either. Well, that's exactly how it works; how the hell do you think we all wound up programming in Java?
Seriously, though. I know I have a very slight tendency to exaggerate a wee bit now and again, for dramatic effect. And I don't always stop at stretching my metaphors; sometimes I drag them out to the back alley and beat the living crap out of them. But it should be clear that there's a grain of truth to my cigar-chomping executives: most successful languages have had some pretty serious corporate backing. C++ had AT&T and Microsoft. Java had Sun and IBM. C# and Visual Basic had Microsoft. Perl basically had O'Reilly. JavaScript had Netscape, Sun, and Microsoft (among others). And so on.
And I found a tip — a rather detail-packed one at that — as to which way the wind is blowing. Let's face it: I've been digging into this story for years, so it should be no surprise that I got the scoop. (Hint: the "tip" was synthesized from reading a bunch of public web pages, so you've got all the clues you need.)
Unfortunately I can't tell you what language it is. For one thing, you probably wouldn't believe me. For another, it wouldn't be fair; there are plenty of contenders out there, and it seems like they should all have a fighting chance. Instead, I'm going to outline the characteristics that a language needs in order to be a megahit. You won't like some of them, and I sure as hell don't like some of them, but we're talking stark reality here. It's not a matter of opinion.
I'm really killing two birds here: by telling you where languages are headed, I'm giving you enough hints to figure out what the Next Big Language is without committing to anything, thereby evading the inevitable jihad against me if I were to say its name. Second, I'm giving language designers valuable information that should help them get their language adopted, if that's their goal.
But first, some preliminaries and caveats are in order.
You won't be deported to Columbia
Just because the Next Big Language (NBL from now on) is going to arrive very soon (timeline: 18-24 months, as far as I can tell, which in language terms means "imminent") doesn't mean your language is going away. You won't lose your job, so don't freak out on me.
What it does mean is that there's going to be a massive momentum shift, so if you start preparing now, it's not going to hit you as hard when it happens. You'll be ready.
Heck, if you're lucky, you already know the language — at least the subset of it that exists today. If so, you've got a big head start.
NBL does not replace C++
NBL is garbage collected. There will always be a bunch of engineers who think that's evil, and they'll continue to use C++.
C++ does need to get replaced someday. It's just horrid, and everyone knows it. However, there aren't very many people trying to replace it, either. The only contenders I'm aware of are Objective C and the D Programming Language.
D's a really beautiful language. By rights it should be the next C++. However, C++ programmers won't have it because it's garbage collected (even though it can be disabled, and even though Stroustroup himself is now advocating adding garbage collection to C++). Walter Bright is one hell of a lot smarter than the C++ programmers who won't look at his language, and he has demonstrated that D is as fast as or faster than C++ and nearly as expressive as Ruby or Python. It's a secret weapon just waiting to be seized by some smart company or open-source project.
But nobody ever accuses programmers of being wise.
I don't know much about Objective C, to be honest; I've read one or two books about it, and it looks decent-ish, but not inspiring in the way that D is (for instance.) So I can't say much about it. Seems kinda ho-hum to me.
Anyway, most of the language research and effort and creativity out there, both in academia and industry, is focused on higher-level languages, so it looks like C++ will continue to struggle happily in its tar pit for some years to come.
NBL isn't about winning beauty contests
When I refer to NBL, the Next Big Language, I specifically mean the next popular language. I.e., a language that you yourself will wind up learning and actually using. You can point to all sorts of languages, both existing and in the works, that are prettier than NBL. Doesn't matter, though. Heck, as you'll see (Rule #1), beauty is one of the obstacles to adoption.
If your goal as a language designer is to design a language that meets your own personal sense of aesthetics, then you're an artist, and I salute you. For my part, I'm looking for the middle ground between hard-nosed I-don't-care pragmatism (in which case you go ugly early, use Java or C++, and be done with it) and idealistic better-world optimism. And I think a lot of other people are too.
In any case, I'm not claiming that NBL is a great language; I'm just saying it doesn't suck. In practice it's actually quite good, and it will be very, very popular. NBL isn't the 100-year language, but it will definitely be the 10- to 20-year language.
And now, on to the features. Get ready to get mad.
The Language Arena
Here's how you compete in the programming language arena today. Follow these rules and you stand a chance. Ignore them and your language will be Lion Chow.
Rule #1: C-like syntax
C(++)-like syntax is the standard. Your language's popularity will fall off as a direct function of how far you deviate from it.
There's plenty of wiggle room in the way you define classes and other OOP constructs, but you'll need to stick fairly closely to the basic control-flow constructs, arithmetic expressions and operators, and the use of curly-braces for delimiting blocks and function bodies.
This is because programmers are lame, but hey, it's your target audience. Give the people what they want.
People sometimes ask me why I think C's syntax is bad. The reason is pretty simple: it's too complicated. Well, C's wasn't so bad, but when you throw OOP into the mix (whether it's Java's, or C++'s, or D's, or anyone's), the grammar becomes enormously complex, with hundreds of productions.
It might feel, as a programmer using a C-like syntax, that the syntax is helping you out. Unfortunately, as soon as you try to write code that deals with the language itself, you hit a wall.
Case in point: Java folks always wish they had a better Java code formatter. The best one ever written was Jalopy, but it never took off, in part because it wasn't open source, but also in part because its manual was astoundingly long and complicated. Why? Because it provided rules for customizing every last one of the hundreds of edge cases in Java's syntax. And this was before Java 5 came along and made it even more complicated with generics and so on.
So people settle for the one built into Eclipse, but nobody ever goes in and messes with its actual internal mechanisms themselves, because even if they're unhappy with the way it handles certain syntactic cases, it's too damned complicated to bother with.
Most programmers don't realize how often they need to deal with code that processes code. It's an important case that comes up in many, many everyday situations, but we don't have particularly good tools for dealing with it, because the syntax itself prevents it from being easy.
That's why it's bad.
Unfortunately, even Ruby and Python (which "feel" simpler, syntactically) both also have very complicated grammars, making it nontrivial to write code that processes them, even with parsers that hand you the AST directly.
Whatever. Now you know why I think C's syntax is bad. It's because it is bad.
But bad or not, NBL will have approximately C-like syntax because if it doesn't, most programmers won't give it a second glance.
Sigh.
Rule #2: Dynamic typing with optional static types.
There are two ways to make a language. The old way is to make it super static, to protect programmers from hurting themselves. The classic example is SML, which is so fanatically typed that you're guaranteed never to get a runtime exception, because you will never get your goddamn program to compile. There's nothing more fun than having your compiler tell you: "Error: expected type (int, int, int) but got type (int, int, int)". Sheesh.
When you make a static language, you will be forced to add dynamism to it, because otherwise it's like programming in a straitjacket. If you don't add dynamic features to your static language, then assuming everyone hasn't ditched it entirely, they will start building in the dynamic features themselves, no matter how hard it is, and how awkward they are to use.
The other way to design a language is to make it dynamic, and then you'll be forced to add static checks in later. If you don't, then programmers will start simulating static checks using assertions and preprocessors and all manner of other hacks, in an effort to help lock things down once they've stabilized past the prototyping phase.
Adding in optional static types is the ideal solution. It helps with performance, it helps with code reliability and (possibly) readability, it helps IDEs navigate your code, and most importantly, it helps combat the incredible FUD that dynamic languages inspire in people who come from static backgrounds.
It should be pretty obvious that dynamic + optional static types is a better approach than static + optional dynamic features. The latter is premature optimization, plain and simple: the root of all evil.
So NBL will be a dynamic language with optional static types.
As a special sneak preview, its static type system will include a "standard" class system (i.e. the kind you're used to if you do any conventional OOP using C++ or Java or Python or whatever, as opposed to Common Lisp's object system or some other unconventional one.) Not that the standard system is any better, but it's what people want.
Rule #3: Performance
NBL will perform about as well as Java. That means if it's one of the big existing dynamic languages out there, something major is going to have to happen with performance.
It turns out that eval() is one of the key things that gets in the way of performance optimizations. It can easily invalidate all sorts of otherwise reasonable assumptions about variable bindings, stack addresses and so on. It's also pretty important, so you can't just get rid of it.
So NBL will have to do something clever about eval.
Generally speaking, NBL will have to have a much greater focus on performance than so-called "scripting languages" have had in the past. I mean, if it's really the Next Big Thing, it'll have to run on mobile devices, game platforms, and all sorts of other hardware-constrained devices.
It sounds impossible, I know. But it's not. Those compiler writers are a tricky bunch, and they have decades of experience. A bunch of them got together and did a lot of head-scratching over NBL, and the result is going to perform quite nicely.
Rule #4: Tools
Let's face it: one of the biggest reasons people haven't adopted Ruby or Python is the lack of IDE support. IDEs like Visual Studio and Eclipse have set the bar and the expectations for most programmers out there.
I can't tell you how many times I've heard people say they wouldn't use Ruby because it lacks automated refactoring tools. Ruby doesn't actually need them in the way Java does; it's like refusing to switch to an electric car because there's no place to put the gasoline. But programmers are a stubborn bunch, and to win them over you have to give them what they think they want.
So NBL will have great tools. They might not be Java-great on Day One of NBL's reign, but they'll be a lot better than the options available for Perl/Python/Ruby/Tcl and the rest of the popular dynamic languages out there today.
Rule #5: Kitchen Sink
Word on the street is that all languages are evolving towards each other. It's another way of saying they all have feature envy. So NBL is going to have to play along.
Here's a short list of programming-language features that have become ad-hoc standards that everyone expects:
- Object-literal syntax for arrays and hashes
- Array slicing and other intelligent collection operators
- Perl 5 compatible regular expression literals
- Destructuring bind (e.g. x, y = returnTwoValues())
- Function literals and first-class, non-broken closures
- Standard OOP with classes, instances, interfaces, polymorphism, etc.
- Visibility quantifiers (public/private/protected)
- Iterators and generators
- List comprehensions
- Namespaces and packages
- Cross-platform GUI
- Operator overloading
- Keyword and rest parameters
- First-class parser and AST support
- Static typing and duck typing
- Type expressions and statically checkable semantics
- Solid string and collection libraries
- Strings and streams act like collections
Additionally, NBL will have first-class continuations and call/cc. I hear it may even (eventually) have a hygienic macro system, although not in any near-term release.
Not sure about threads. I tend to think you need them, although of course they can be simulated with call/cc. I've also noticed that languages with poor threading support tend to use multiprocessing, which makes them more scalable across machines, since by the time you've set up IPC, distributing across machines isn't much of an architectural change. But I think threads (or equivalent) are still useful. Hopefully NBL has a story here.
Rule 6: Multi-Platform
NBL will run, at a minimum, both standalone and on the JVM. I'm not sure about plans for .NET, but it seems like that will have to happen as well.
And there are two other platforms that NBL will run on which, more than anything else, are responsible for its upcoming dominance, but I'd be giving away too much if I told you what they were.
It's all about not sucking
The features I've outlined don't make NBL a great language. I think a truly great language would support Erlang-style concurrency, would have a simpler syntax and a powerful macro system, and would probably have much better support for high-level declarative constructs, e.g. path expressions, structural dispatch (e.g. OCaml's match ... with statement) and query minilanguages. Among other things.
The features I've outlined are basically the minimal set of requirements for not sucking. At least off the top of my head; I've probably overlooked a few.
Well... OK, I think C-style syntax kinda sucks, for reasons I've outlined, but it's a price I'm willing to pay, because I think there's no choice. Rule #1 is in there strictly to support popularity.
Looking at the list, it's amazing that you have to work so hard just to meet the minimum standard for not sucking. The bar has really gone up for programming languages.
Not to discourage you or anything.
Is NBL (the one whose name I won't tell you) guaranteed to be the Next Big Language? I think it's got about a 90+% chance, but there's still hope for the other runner-ups.
For instance, it might be possible to get away with non-C syntax, provided you offer everything else I've listed here, but you'll have to bear in mind that you're competing against NBL, which has all the features of your language plus C-like syntax. So your language would have to offer something not in this list that gives it a huge leg up on NBL. (And I'm afraid simpler syntax alone won't do it; you're going to have to offer something that compensates for your lack of C syntax, because that's just how programmers are.)
So it's possible. But my bet is on NBL.
And now, if you'd like to see some excellent variations on the old game of Shoot The Messenger, enjoy the comments!
Rabu, 07 Februari 2007
My save-excursion
A friend of mine on a neighboring team at Google presented me with an interesting math problem the other day. It went like this:
Friend: Hey Stevey!
Me: Uh, you know people don't actually call me that to my face, right? Only behind my back.
Friend: (cheerily) But you're Stevey! Look at your badge!
Me: Sigh. OK, fine already. What's this math problem?
Friend: Let's say there's this hypothetical blogger who writes for 4 hours a month, and he desperately needs an editor who will never materialize, and in those 4 hours he produces very... large... ummm...
Me: And what exactly are you trying to say there, ex-friend?
Ex-friend: Oh, nothing! It's purely hypothetical! I'm just saying that I, er, well, I've been reading for hours and I'm only half done with your last blog entry, and I accidentally fell asleep and had a wonderful dream that I was finished reading it, and then I woke up and my keyboard was gone. Plus I'm still not done yet.
Me: That was a pretty long story.
Ex-friend: (reading what I wrote) That's not what I said! What do you mean the keyboard was gone?
Me: Uh, never mind. I'll fix it in the real blog.
Ex-friend: Fine. Whatever. Anyway, we were all thinking...
Me: Oh! So it's "we" now, is it? And who are my other ex-friends in this particular hypothetical situation?
Ex-friend: Jared and Todd and Jeremy.
Me: B-b-but — you can't say their names in my blog!
Ex-friend: Oopsie.
Me: There are people listening!
Ex-friend: No, Stevey, I think your readers all died of starvation on account of trying to finish your blogs in one sitting.
Me: D'oh! OK. Yeah. I think I get it. You're saying — and correct me if I'm wrong here — that if I write for an hour a week, I'll produce blogs that are only like 600 times too long, rather than the usual, ah...
Really-ex-friend-now: 2400.
Me: Ouch! That's just... low. (frowning vaguely, looking at my fingers) I know how to multiply, you know. I was just thinking about something else, that's all.
Really-ex-friend-now: Well, we think maybe you should give it a try! Just one hour a week. You could be, like, a columnist.
Me: Yeah! I won't get paid, and nobody will read any of it, but otherwise it's pretty much exactly the same as a columnist in all respects. I can be like... like Paul Graham, and sit around in my underwear writing articles about how I get to sit around in my underwear writing articles about stuff, on account of having written everything in Lisp. Except I'll still have to wear pants.
Friend: Um. (edging nervously towards the door) So does this mean I don't have to finish that last blog about Cinderella?
Me: *sigh* Pinocchio. And no, you don't have to finish it. He dies at the end, anyway.
Friend: (sympathetic frowny-face) Sad. (runs out)
Stevey's Blog... Column... Thing.
So! I'm going to try writing for an hour a week, and also try limiting my blog to a certain number of words that columnists apparently never actually discuss but which appears to be around 800, and we'll see if it nets me fewer complaints. And I'm going to start... last Friday! This blog is officially 3 days late, but I figured apologizing could get me a couple of extra words.
As of that last paragraph, I was at 2338 chars, or 437 five-letter words, at least in the first draft. I'll spend the rest of today's entry explaining how I knew that.
Since I'm writing this in Emacs (where else?) I need an Emacs command that will count the non-whitespace characters in the current buffer and tell me how many there are so far, plus divide by five to show how many "words" I've written, since as we all know from fifth-grade English class, words are always five letters.
First I type
I start with the basic interactive function skeleton:
That's pretty much the minimal command you can invoke with M-x. After typing it out, I put the cursor anywhere inside the function definition and type
Now we can type M-x blog-column-length to see the "hi there" message printed to the minibuffer. If I were doing lots of output, I could use
Note: by evaluating my function, I've fully integrated it into Emacs. I can tab-complete the command name, do
I mean, if you were trying to follow along with our little exercise in Eclipse, at this point you might have it out of the box, maybe, but there would be parts all over the floor, styrofoam everywhere, and you'd be staring at the 10-page Hello, World demo trying to figure out where
Anyway, all that's left is to count the characters. It helps to know one wacky thing about Emacs: most functions are written as scripted versions of exactly what you would have done by hand. That's how it got to be called "Emacs" — Editor Macros. As you learn the editor commands, you're also learning how to program Emacs, because you can use all those commands in your elisp code. Sweet!
There are lots of ways to count the non-whitespace characters in the buffer, but the first one that came to mind is to go to the beginning of the buffer and start looking at each character, incrementing some counter if it's not whitespace, and keep going until we get to the end of the buffer.
So that's what we'll do. First, go to the beginning of the buffer:
You could also use
Then we need a loop. How about "while"? Sounds good to me. Let's loop while we're not at the end of the buffer:
Oh, let's wrap the whole thing in a
Really. It's a real Emacs haiku. Look it up! The only Eclipse haiku I know goes like this:
That's what they used to say about Emacs, but then hardware got faster so they needed a new elephant.
Anyway, here's what we've got so far:
First, we need to declare a variable. I'm tellin' ya: declaring your variables is all the rage these days.
This declares a variable
Next we need to say "unless we're looking at a whitespace char, increment char-count". Here's how:
Gosh. And everyone always says they despise Lisp. It's not that hard, is it? The only trick is knowing where to put the parentheses, and that's easy. It's just
Plus those extra ones around the
Then we move the cursor forward:
Putting it all together:
Et voila. Almost exactly 1 hour. Well, 90 minutes, but who's counting.
6936 chars, 1387 words. OK, it's a little longer than my target, but what's a few words in the pursuit of Emacs education between friends? Plus I got a couple of jabs in at Eclipse, so it's not a total loss.
See you all next week!
Friend: Hey Stevey!
Me: Uh, you know people don't actually call me that to my face, right? Only behind my back.
Friend: (cheerily) But you're Stevey! Look at your badge!
Me: Sigh. OK, fine already. What's this math problem?
Friend: Let's say there's this hypothetical blogger who writes for 4 hours a month, and he desperately needs an editor who will never materialize, and in those 4 hours he produces very... large... ummm...
Me: And what exactly are you trying to say there, ex-friend?
Ex-friend: Oh, nothing! It's purely hypothetical! I'm just saying that I, er, well, I've been reading for hours and I'm only half done with your last blog entry, and I accidentally fell asleep and had a wonderful dream that I was finished reading it, and then I woke up and my keyboard was gone. Plus I'm still not done yet.
Me: That was a pretty long story.
Ex-friend: (reading what I wrote) That's not what I said! What do you mean the keyboard was gone?
Me: Uh, never mind. I'll fix it in the real blog.
Ex-friend: Fine. Whatever. Anyway, we were all thinking...
Me: Oh! So it's "we" now, is it? And who are my other ex-friends in this particular hypothetical situation?
Ex-friend: Jared and Todd and Jeremy.
Me: B-b-but — you can't say their names in my blog!
Ex-friend: Oopsie.
Me: There are people listening!
Ex-friend: No, Stevey, I think your readers all died of starvation on account of trying to finish your blogs in one sitting.
Me: D'oh! OK. Yeah. I think I get it. You're saying — and correct me if I'm wrong here — that if I write for an hour a week, I'll produce blogs that are only like 600 times too long, rather than the usual, ah...
Really-ex-friend-now: 2400.
Me: Ouch! That's just... low. (frowning vaguely, looking at my fingers) I know how to multiply, you know. I was just thinking about something else, that's all.
Really-ex-friend-now: Well, we think maybe you should give it a try! Just one hour a week. You could be, like, a columnist.
Me: Yeah! I won't get paid, and nobody will read any of it, but otherwise it's pretty much exactly the same as a columnist in all respects. I can be like... like Paul Graham, and sit around in my underwear writing articles about how I get to sit around in my underwear writing articles about stuff, on account of having written everything in Lisp. Except I'll still have to wear pants.
Friend: Um. (edging nervously towards the door) So does this mean I don't have to finish that last blog about Cinderella?
Me: *sigh* Pinocchio. And no, you don't have to finish it. He dies at the end, anyway.
Friend: (sympathetic frowny-face) Sad. (runs out)
Stevey's Blog... Column... Thing.
So! I'm going to try writing for an hour a week, and also try limiting my blog to a certain number of words that columnists apparently never actually discuss but which appears to be around 800, and we'll see if it nets me fewer complaints. And I'm going to start... last Friday! This blog is officially 3 days late, but I figured apologizing could get me a couple of extra words.
As of that last paragraph, I was at 2338 chars, or 437 five-letter words, at least in the first draft. I'll spend the rest of today's entry explaining how I knew that.
Since I'm writing this in Emacs (where else?) I need an Emacs command that will count the non-whitespace characters in the current buffer and tell me how many there are so far, plus divide by five to show how many "words" I've written, since as we all know from fifth-grade English class, words are always five letters.
First I type
C-x 2 and switch to my *scratch* buffer. You can write lisp code there. When it's tested, you can copy it into a file somewhere that's loaded by your .emacs.I start with the basic interactive function skeleton:
(defun blog-column-length ()
"Print stats on current blog column, or blogollum, or whatever"
(interactive)
(message "hi there"))
That's pretty much the minimal command you can invoke with M-x. After typing it out, I put the cursor anywhere inside the function definition and type
M-C-x (i.e., Ctrl-Alt-x) to evaluate it. Note that we don't have to restart Emacs to do this. *Ahem*. At least Eclipse comes with free bullets.Now we can type M-x blog-column-length to see the "hi there" message printed to the minibuffer. If I were doing lots of output, I could use
with-output-to-temp-buffer, but I figure this can just be a one-liner. The (message) function takes arguments similar to C's printf.Note: by evaluating my function, I've fully integrated it into Emacs. I can tab-complete the command name, do
M-x describe-function to read the help string, do M-x apropos blog to find it in the list of commands that have 'blog' in the name, and so on. Emacs is cool. Why aren't all editors like this?I mean, if you were trying to follow along with our little exercise in Eclipse, at this point you might have it out of the box, maybe, but there would be parts all over the floor, styrofoam everywhere, and you'd be staring at the 10-page Hello, World demo trying to figure out where
main() goes. Good ole Eclipse. And I hear the Visual Studio team was jealous of Eclipse's "lightweight" plugin system. (Is it any wonder that developers never customize their tools? Jeez.)Anyway, all that's left is to count the characters. It helps to know one wacky thing about Emacs: most functions are written as scripted versions of exactly what you would have done by hand. That's how it got to be called "Emacs" — Editor Macros. As you learn the editor commands, you're also learning how to program Emacs, because you can use all those commands in your elisp code. Sweet!
There are lots of ways to count the non-whitespace characters in the buffer, but the first one that came to mind is to go to the beginning of the buffer and start looking at each character, incrementing some counter if it's not whitespace, and keep going until we get to the end of the buffer.
So that's what we'll do. First, go to the beginning of the buffer:
(goto-char (point-min))
You could also use
(beginning-of-buffer)if you prefer. No biggie.
Then we need a loop. How about "while"? Sounds good to me. Let's loop while we're not at the end of the buffer:
(while (not (eobp))It's good to know all the little functions for testing if you're at the beginning of the line (bolp), end of line (eolp), beginning of buffer (bobp), end of buffer (eobp), etc. 'p' means predicate; i.e. a function that returns true/false. It's just a lispy naming convention.
)
Oh, let's wrap the whole thing in a
save-excursion. That's an emacs macro that saves/restores the point and mark around any editing operations. If you want to be able to run your command without affecting the user's actual cursor position, use save-excursion. You see it all over. There's even a haiku about it:The friends chat gaily,
I stand up to join their talk.
My save-excursion.
Really. It's a real Emacs haiku. Look it up! The only Eclipse haiku I know goes like this:
startApplication()
thenWaitFriggingForever()
thenItGoesRealSlow()
That's what they used to say about Emacs, but then hardware got faster so they needed a new elephant.
Anyway, here's what we've got so far:
(defun blog-column-length ()
"Print stats on current blog column, or blogollum, or whatever"
(interactive)
(save-excursion
(goto-char (point-min))
(while (not (eobp))
;; we're going to increment a counter in here
)
(message "count will be displayed here")))
First, we need to declare a variable. I'm tellin' ya: declaring your variables is all the rage these days.
(let ((char-count 0))
This declares a variable
char-count, initialized to zero, within the scope of the let-block, which is sort of like a curly-brace block in C or Java. The extra parens date back to 1955, and they get real grumpy if you mention them, so let's not.Next we need to say "unless we're looking at a whitespace char, increment char-count". Here's how:
(unless (looking-at "[ \t\r\n]")
(incf char-count))
Gosh. And everyone always says they despise Lisp. It's not that hard, is it? The only trick is knowing where to put the parentheses, and that's easy. It's just
(function arg arg arg). If arg is a call to a function, then you parenthesize it, and it all nests nicely, sorta like XML but without all the yelling.Plus those extra ones around the
let-declaration, but we don't talk about them, remember? That's how you remember them.Then we move the cursor forward:
(forward-char 1)
Putting it all together:
(defun blog-column-length ()
"Print stats on current blog column, or blogollum, or whatever"
(interactive)
(save-excursion
(goto-char (point-min))
(let ((char-count 0))
(while (not (eobp))
(unless (looking-at "[ \t\r\n]")
(incf char-count))
(forward-char 1))
(message "%d chars, %d words" char-count (/ char-count 5)))))
Et voila. Almost exactly 1 hour. Well, 90 minutes, but who's counting.
6936 chars, 1387 words. OK, it's a little longer than my target, but what's a few words in the pursuit of Emacs education between friends? Plus I got a couple of jabs in at Eclipse, so it's not a total loss.
See you all next week!
Sabtu, 03 Februari 2007
Algebra tiles Manipulatives
Today I am going to discuss about a mathematical model which we have prepared in our Planet Infinity.
Algebra tiles Manipulative…..
II) Representation of x^2 -x - 6
· To represent this we need 1 square tile representing x^2 , 5 algebra tiles representing x and 6 algebra tiles representing 1.
· By splitting the middle term of the given polynomial we get the expression x^2 -3x +2x - 6.
· Place a square tile of dimension 10X10 representing x^2 .
· Add 2 tiles of dimension 10 X 1 each to any side of the tile x^2.The area of new shape formed represents x^2 +2x.
· Subtract 3 tiles of dimension 10 X 1 each to the side adjacent to the previous side. The area of new shape formed represents x^2 +2x-3x.
· Subtract 6 tiles of dimension 1 X 1 each to complete the rectangle. The area of new shape formed represents x^2 +2x-3x-6.
IV) Representation of x^2 +x -6
· To represent this we need 1 square tile representing x^2 , 5 algebra tiles representing x and 6 algebra tiles representing 1.
· By splitting the middle term of the given polynomial we get the expression x^2 +3x -2x - 6.
· Place a square tile of dimension 10X10 representing x^2 .
· Add 3 tiles of dimension 10 X 1 each to any side of the tile x2.The area of new shape formed represents x^2 +3x.
· Subtract 2 tiles of dimension 10 X 1 each from the side adjacent to the previous side. The area of new shape formed represents x^2 +3x-2x.
· Subtract 6 tiles of dimension 1 X 1 each to complete the rectangle. The area of new shape formed represents x^2 +3x-2x-6.
· Observation
· In the representation of x^2 +5x + 6 , a rectangle is formed whose sides are (x+3) and (x+2) which are the factors of it.
· In the representation of x^2 -x - 6 , a rectangle is formed whose sides are (x-3) and (x+2) which are the factors of it.
· In the representation of x^2 -5x + 6 , a rectangle is formed whose sides are (x-3) and (x-2) which are the factors of it.
· In the representation of x^2 +x - 6 , a rectangle is formed whose sides are (x+3) and (x-2) which are the factors of it.
Result:
Thus we have observed that in all the four cases a rectangle is formed whose sides are the factors of the given polynomial.
Algebra tiles Manipulative…..
Objectives:
· To eliminate the frustration or anxiety involved with multiplying and factoring polynomials through the usage of Algebra Tiles.
· Understanding the concept of variables by naming tiles.
· Visualizing quadratic terms in polynomials as squares.
· Performing basic operations, such as addition and subtraction, on polynomials
· Factoring second-degree polynomials .
INTRODUCTION :
An old Chinese proverb states:
I hear, and I forget;I see, and I remember;I do, and I learn.
· They say mathematics is not a spectator sport, but by demonstrations, it can be done.
· In this mathematics model, representation of factorization of algebraic expressions using algebra tiles is done.
· That is how algebra manipulatives, i.e. algebra tiles make the difficult concept of "factoring second-degree polynomials" into a simple puzzle that’s fun. We have used a set of algebra tiles to factor the given polynomial. They help convert the abstract concept of polynomials into tangible objects - tiles.
What are manipulatives?
· Manipulatives are materials that are physically handled in order to see actual examples of heads - the tools for solving equations, visual representations of algebraic factoring, and a multitude of other skills and concepts. Manipulatives can introduce mathematical topics and reinforce conceptual understanding in powerful ways.
What are Algebra Tiles?
· They work by the concept that every rectangle has a length, width and area. The length and the width are the lengths of the sides of the rectangle in some unit. The area is how many squares of that unit it takes to cover the rectangle.The sides of the rectangle are the factors of the given polynomial.
· To eliminate the frustration or anxiety involved with multiplying and factoring polynomials through the usage of Algebra Tiles.
· Understanding the concept of variables by naming tiles.
· Visualizing quadratic terms in polynomials as squares.
· Performing basic operations, such as addition and subtraction, on polynomials
· Factoring second-degree polynomials .
INTRODUCTION :
An old Chinese proverb states:
I hear, and I forget;I see, and I remember;I do, and I learn.
· They say mathematics is not a spectator sport, but by demonstrations, it can be done.
· In this mathematics model, representation of factorization of algebraic expressions using algebra tiles is done.
· That is how algebra manipulatives, i.e. algebra tiles make the difficult concept of "factoring second-degree polynomials" into a simple puzzle that’s fun. We have used a set of algebra tiles to factor the given polynomial. They help convert the abstract concept of polynomials into tangible objects - tiles.
What are manipulatives?
· Manipulatives are materials that are physically handled in order to see actual examples of heads - the tools for solving equations, visual representations of algebraic factoring, and a multitude of other skills and concepts. Manipulatives can introduce mathematical topics and reinforce conceptual understanding in powerful ways.
What are Algebra Tiles?
· They work by the concept that every rectangle has a length, width and area. The length and the width are the lengths of the sides of the rectangle in some unit. The area is how many squares of that unit it takes to cover the rectangle.The sides of the rectangle are the factors of the given polynomial.
Nomenclature:
Algebra tiles have a variety of other names:
Algetiles
Math tiles
Virtual tiles.
History:
Algebra tiles have a variety of other names:
Algetiles
Math tiles
Virtual tiles.
History:
The first use of algebraic manipulatives to illustrate algebraic ideas was by math educator Zoltan dienes who used base 10 blocks.The idea was powerful, and launche dthe idea of algebraic manipulatives.
· Mary Laylock improved on dieles’ model, by using multi base blocks. Instead of just working with base ten blocks, a trinomial factoring had to work on all bases. She also introduced upstairs representation of minus, which made it possible to represent a product involving minus like (x+1)(x-1) in a geometrically correct way.
· Peter Rasmussen used base +10, +5, +25 tiles for convenience. He also created the non commensurable x, which solved the prolem of false factorings encountered when using arithmetic blocks fo variables. His model of minus combined with Laylock’s idea with clor scheme. The tiles were only painted on one side, so that if a tile is turned over its unpainted side, it is considered negative.
· The algebra tiles of today are based on Rasmussen’s ground breaking model.
Utility:
· They help in bridging the gap from the concrete to the abstract.
· Algebra tiles can be very beneficial in understanding the concept of "like terms" and combining of terms.
Application of Algebra Tiles:
· Multiplication of monomials and binomials
· Representation of quadratic polynomials.
· Solution of Linear equations in one variable.
· Solution of a quadratic equation
· Understanding integers.
· Addition and subtraction of polynomials.
Description of Physical Model
· Preparation:
We have prepared Algebra Tiles
• Square tiles of dimension 10 X 10 each, representing x^2.
• Rectangular tiles of dimension 10 X 1 each , representing x .
• Square tiles of dimension 1 X 1 each representing 1.
· Assumption:
We have assumed that
• In the rectangular tiles each of dimension x sq units the top side represents (+ x) and the bottom side represents (- x).
• Similarly in the square tiles each of dimension 1 sq unit the top side represents (+1) and the bottom side represents (-1).
· PROCEDURE
I) Representation of x^2 +5x + 6
· To represent this we need 1 square tile representing x^2 , 5 algebra tiles representing x and 6 algebra tiles representing 1.
· By splitting the middle term of the given polynomial we get the expression x^2 +3x +2x + 6.
· Place a square tile of dimension 10X10 representing x^2 .
· Add 3 tiles of dimension 10 X 1 each to any side of the tile x^2.The area of new shape formed represents x^2 +3x.
· Add 2 tiles of dimension 10 X 1 each to the side adjacent to the previous side. The area of new shape formed represents x^2 +3x+2x.
· Add 6 tiles of dimension 1 X 1 each to complete the rectangle. The area of new shape formed represents x^2 +3x+2x+6.
· Mary Laylock improved on dieles’ model, by using multi base blocks. Instead of just working with base ten blocks, a trinomial factoring had to work on all bases. She also introduced upstairs representation of minus, which made it possible to represent a product involving minus like (x+1)(x-1) in a geometrically correct way.
· Peter Rasmussen used base +10, +5, +25 tiles for convenience. He also created the non commensurable x, which solved the prolem of false factorings encountered when using arithmetic blocks fo variables. His model of minus combined with Laylock’s idea with clor scheme. The tiles were only painted on one side, so that if a tile is turned over its unpainted side, it is considered negative.
· The algebra tiles of today are based on Rasmussen’s ground breaking model.
Utility:
· They help in bridging the gap from the concrete to the abstract.
· Algebra tiles can be very beneficial in understanding the concept of "like terms" and combining of terms.
Application of Algebra Tiles:
· Multiplication of monomials and binomials
· Representation of quadratic polynomials.
· Solution of Linear equations in one variable.
· Solution of a quadratic equation
· Understanding integers.
· Addition and subtraction of polynomials.
Description of Physical Model
· Preparation:
We have prepared Algebra Tiles
• Square tiles of dimension 10 X 10 each, representing x^2.
• Rectangular tiles of dimension 10 X 1 each , representing x .
• Square tiles of dimension 1 X 1 each representing 1.
· Assumption:
We have assumed that
• In the rectangular tiles each of dimension x sq units the top side represents (+ x) and the bottom side represents (- x).
• Similarly in the square tiles each of dimension 1 sq unit the top side represents (+1) and the bottom side represents (-1).
· PROCEDURE
I) Representation of x^2 +5x + 6
· To represent this we need 1 square tile representing x^2 , 5 algebra tiles representing x and 6 algebra tiles representing 1.
· By splitting the middle term of the given polynomial we get the expression x^2 +3x +2x + 6.
· Place a square tile of dimension 10X10 representing x^2 .
· Add 3 tiles of dimension 10 X 1 each to any side of the tile x^2.The area of new shape formed represents x^2 +3x.
· Add 2 tiles of dimension 10 X 1 each to the side adjacent to the previous side. The area of new shape formed represents x^2 +3x+2x.
· Add 6 tiles of dimension 1 X 1 each to complete the rectangle. The area of new shape formed represents x^2 +3x+2x+6.
II) Representation of x^2 -x - 6
· To represent this we need 1 square tile representing x^2 , 5 algebra tiles representing x and 6 algebra tiles representing 1.
· By splitting the middle term of the given polynomial we get the expression x^2 -3x +2x - 6.
· Place a square tile of dimension 10X10 representing x^2 .
· Add 2 tiles of dimension 10 X 1 each to any side of the tile x^2.The area of new shape formed represents x^2 +2x.
· Subtract 3 tiles of dimension 10 X 1 each to the side adjacent to the previous side. The area of new shape formed represents x^2 +2x-3x.
· Subtract 6 tiles of dimension 1 X 1 each to complete the rectangle. The area of new shape formed represents x^2 +2x-3x-6.
. 
III) Representation of x^2 -5x + 6
· To represent this we need 1 square tile representing x2 , 5 algebra tiles representing x and 6 algebra tiles representing 1.
· By splitting the middle term of the given polynomial we get the expression x^2 -3x -2x + 6.
· Place a square tile of dimension 10X10 representing x^2 .
· Subtract 3 tiles of dimension 10 X 1 each to any side of the tile x^2.The area of new shape formed represents x^2 -3x.
· Add 6 tiles of dimension 1 X 1 each to get 2 tiles of dimension 10 X 1 each to the side adjacent to the previous side. The area of new shape formed represents x^2 -3x+6.
· Subtract 2 tiles of dimension 10 X 1 each to complete the rectangle. The area of new shape formed represents x^2 -3x+6-2x.
III) Representation of x^2 -5x + 6
· To represent this we need 1 square tile representing x2 , 5 algebra tiles representing x and 6 algebra tiles representing 1.
· By splitting the middle term of the given polynomial we get the expression x^2 -3x -2x + 6.
· Place a square tile of dimension 10X10 representing x^2 .
· Subtract 3 tiles of dimension 10 X 1 each to any side of the tile x^2.The area of new shape formed represents x^2 -3x.
· Add 6 tiles of dimension 1 X 1 each to get 2 tiles of dimension 10 X 1 each to the side adjacent to the previous side. The area of new shape formed represents x^2 -3x+6.
· Subtract 2 tiles of dimension 10 X 1 each to complete the rectangle. The area of new shape formed represents x^2 -3x+6-2x.
IV) Representation of x^2 +x -6
· To represent this we need 1 square tile representing x^2 , 5 algebra tiles representing x and 6 algebra tiles representing 1.
· By splitting the middle term of the given polynomial we get the expression x^2 +3x -2x - 6.
· Place a square tile of dimension 10X10 representing x^2 .
· Add 3 tiles of dimension 10 X 1 each to any side of the tile x2.The area of new shape formed represents x^2 +3x.
· Subtract 2 tiles of dimension 10 X 1 each from the side adjacent to the previous side. The area of new shape formed represents x^2 +3x-2x.
· Subtract 6 tiles of dimension 1 X 1 each to complete the rectangle. The area of new shape formed represents x^2 +3x-2x-6.
· Observation
· In the representation of x^2 +5x + 6 , a rectangle is formed whose sides are (x+3) and (x+2) which are the factors of it.
· In the representation of x^2 -x - 6 , a rectangle is formed whose sides are (x-3) and (x+2) which are the factors of it.
· In the representation of x^2 -5x + 6 , a rectangle is formed whose sides are (x-3) and (x-2) which are the factors of it.
· In the representation of x^2 +x - 6 , a rectangle is formed whose sides are (x+3) and (x-2) which are the factors of it.
Result:
Thus we have observed that in all the four cases a rectangle is formed whose sides are the factors of the given polynomial.
Selasa, 30 Januari 2007
Optical Illusions
What is an optical Illusion?
It is an optical phenomenon resulting in false visual impressions.
Observe the following figures and enjoy the illusions.....
1)Is it a face or the word Liar?
2)Faces or Vases?
3)Which line segment is bigger?
4) Duck or a rabbit?
5) Find the lowest step.
6) Are the two horizontal lines parallel or non-parallel?
7) Count the number of legs.
8) Lines are straight or bending?
I hope you have enjoyed this. Share any other with me.
Bye.
It is an optical phenomenon resulting in false visual impressions.
Observe the following figures and enjoy the illusions.....
1)Is it a face or the word Liar?
2)Faces or Vases?
3)Which line segment is bigger?
4) Duck or a rabbit?
5) Find the lowest step.
6) Are the two horizontal lines parallel or non-parallel?
7) Count the number of legs.
8) Lines are straight or bending?
I hope you have enjoyed this. Share any other with me.
Bye.
Jumat, 19 Januari 2007
Square Puzzle
"Thinking is progress. Non-thinking is stagnation of the individual, organisation and the country. Thinking leads to action. Knowledge without action is useless and irrelevant. Knowledge with action, converts adversity into prosperity."
Once again with an interesting puzzle.
Enjoy .....
Thanks.
Chao!
T Puzzle
One of my friends asked me to add some interesting puzzles to my blog. Today I thought of doing the same. I am starting, by adding them one by one.
This is an interesting puzzle which the children of all the age groups love to do. Try it out. I hope you will also enjoy it.
Rabu, 17 Januari 2007
Amazing Facts
What is the greatest sign of success for a teacher...? It is to be able to say "the children are now working as if I did not exist. Maria Montessori
Who says mathematics is a dull subject. I do not agree.
Who says mathematics is a dull subject. I do not agree.
Talk about these facts to students, it will act as a catalyst to start learning automatically.
Amazing facts in mathematics….ingredients for improving learning.
Among all shapes with the same area Circle has the shortest perimeter.
In a group of 23 people, at least two have the same birthday with the probability greater than 1/2 .
Among all shapes with the same perimeter a Circle has the largest area.
12+3-4+5+67+8+9=100 and there exists at least one other representation of 100 with 9 digits in the right order and math operations in between.
There are just five regular polyhedra.
Pi=3.14159 26535 89793 23846 26433 83279 50288 41971 69399 37510 58209 74944 59230 78164 06286 20899 86280 34825 34211 70679 82148 08651 32823
12345679 x 18 = 222222222
12345679 x 27 = 333333333
12345679 x 36 = 444444444
12345679 x 45 = 555555555
12345679 x 54 = 666666666
12345679 x 63 = 777777777
12345679 x 72 = 888888888
12345679 x 81 = 999999999
332 = 1089
3332 = 110889
33332 = 11108889
333332 = 1111088889
3333332 = 111110888889
88 = 9x9 + 7
888 = 98x9+6
8888 = 987x9+5
88888 = 9876x9+4
888888 = 98765x9+3
8888888 = 987654x9+2
88888888 = 9876543x9+1
1729 is the Ramanujan’s number. When the great Indian mathematician was lying ill in the hospital, Dr. Hardy came to visit him. He said ,the taxi number 1729, in which he came is a boring number.Suddenly Ramanujan’s face lit up & he said , it is not a boring number. It is the only number that is the sum of 2 cubes in two different ways.
10^3 + 9^3 = 1729 & 12^3 + 1^3 = 1729.
Amazing facts in mathematics….ingredients for improving learning.
Among all shapes with the same area Circle has the shortest perimeter.
In a group of 23 people, at least two have the same birthday with the probability greater than 1/2 .
Among all shapes with the same perimeter a Circle has the largest area.
12+3-4+5+67+8+9=100 and there exists at least one other representation of 100 with 9 digits in the right order and math operations in between.
There are just five regular polyhedra.
Pi=3.14159 26535 89793 23846 26433 83279 50288 41971 69399 37510 58209 74944 59230 78164 06286 20899 86280 34825 34211 70679 82148 08651 32823
12345679 x 18 = 222222222
12345679 x 27 = 333333333
12345679 x 36 = 444444444
12345679 x 45 = 555555555
12345679 x 54 = 666666666
12345679 x 63 = 777777777
12345679 x 72 = 888888888
12345679 x 81 = 999999999
332 = 1089
3332 = 110889
33332 = 11108889
333332 = 1111088889
3333332 = 111110888889
88 = 9x9 + 7
888 = 98x9+6
8888 = 987x9+5
88888 = 9876x9+4
888888 = 98765x9+3
8888888 = 987654x9+2
88888888 = 9876543x9+1
1729 is the Ramanujan’s number. When the great Indian mathematician was lying ill in the hospital, Dr. Hardy came to visit him. He said ,the taxi number 1729, in which he came is a boring number.Suddenly Ramanujan’s face lit up & he said , it is not a boring number. It is the only number that is the sum of 2 cubes in two different ways.
10^3 + 9^3 = 1729 & 12^3 + 1^3 = 1729.
The Pinocchio Problem
I only permit myself about 4 hours a month for blogging. That's been my rough budget for the past year or so. Normally I have all sorts of topics I'd like to write about, things I'm kicking around, and it's not too hard to pick one. But for the past month, I've only had one thing on my mind, and I've been going nuts trying to find a way to voice it — you know, to present it in a nice, concise way so you can gulp it down. And so far I'm failing. I think that means I don't understand it very well. Maybe trying to write it down will help.
It's about designing software. See, it seems like there's a good way to design software. A best way, even. And nobody does it. Well, a few people do, but even in those rare instances, I think it's accidental half the time.
I've been thinking about this problem on and off for quite a while, and wouldn't you know it, suddenly 18 years have gone by and I still can't quite articulate this... well, design principle, if that's what it is. But for the past month, I feel like I've been getting closer. Maybe you can help! I'll tell you what I know, and you can tell me what you know, and maybe we'll figure out something extraordinary.
By way of setting context for today's blog, I'll summarize everything I've ever written to date in one sentence: I think most software is crap. Well, that's not quite right. It's fairer to say that I think all software is crap. Yeah. There you have it, Stevey in a Nutshell: software is crap.
Even so, I think some software systems are better than others: the producer of the crap in question swallowed some pennies, maybe, so their crap is shiny in places. Once in a while someone will even swallow a ruby, and their crap is both beautiful and valuable, viewed from a certain, ah, distance. But a turd is still a turd, no matter how many precious stones someone ate to make it.
Lovely metaphor, eh? Made it myself!
Whenever I reflect on the software systems I like best — the ones that feel like old friends, like nice places to live — I see that they have some properties in common. I'll tell you what they are, at least the ones I've noticed, in a minute. Promise. But it's not the whole story. Once you add these properties to a software system, if you do them right, then you usually get a system that's as good as we can make them today. But they're still crap!
The real problem comes when I start thinking about what would happen if we could build software systems that aren't crappy. That thought exercise raises all sorts of interesting questions, and I don't know the answers to any of them. But I'll throw them out there too, maybe, as long as I don't go over my 4-hour time limit. Life beckons, and all that.
Favorite Systems
The big realization I had, sometime in the last month or so, is that all of the common properties of my favorite software systems can be derived from a single root cause: one property, or design principle, that if present will cause software to take on the right characteristics automatically.
What are my favorite software systems? Here are a few of the very best: Unix. Windows XP. Mac OS/X. Emacs. Microsoft Excel. Firefox. Ruby on Rails. Python. Ruby. Scheme. Common Lisp. LP Muds. The Java Virtual Machine.
A few more that just barely make the cut, for now: Microsoft Word. OmniGraffle Pro. JavaScript. Perforce.
Some that I think would make the cut if I learned how to use them effectively: The GIMP. Mathematica. VIM. Lua. Internet Explorer.
Most popular software systems out there don't make the cut. Most of them are quite useful, but I think they lack the essential properties of ideal software design. Examples: IntelliJ. Eclipse. Visual Studio. Java. C++. Perl. Nethack. Microsoft PowerPoint. All Nintendo and PlayStation console games. Nearly all PC games, with the notable exceptions of Doom and Quake. Most web applications, including highly useful ones like Amazon.com or Google Maps.
I won't keep you in suspense. I think the most important principle in all of software design is this: Systems should never reboot.
If you design a system so that it never needs to reboot, then you will eventually, even if it's by a very roundabout path, arrive at a system that will live forever.
All the systems I've listed need to reboot occasionally, which means their practical lifespan is anywhere from a dozen to a hundred more years. Some of them are getting up there — lots of them are in their twenties and thirties now, and there are even a few in their early forties. But they're all still a far cry from immortal.
I think the second most important design principle, really a corollary to the first, is that systems must be able to grow without rebooting. A system that can't grow over time is static, so it really isn't a system at all; it's a function. It might be a very complex function with lots of possible inputs and outputs. It might be a very useful function, and it might live for a long time. But functions are always either replaced or subsumed by systems that can grow. And I've come to believe, over nearly two decades of thinking about this, that systems that can grow and change without rebooting can live forever.
Essential Features
Here are some of the properties shared by the best software systems in the world today. Not all systems have all the properties I'll list here; I think very few of them have the full superset. I think you'll see that the more of the essential properties a system has, the more powerful, important, and long-lived it is.
Note: most of these are features for programmers. Features for non-technical end-users don't contribute to a system's lifespan. In the fullness of time, I believe programming fluency will become as ubiquitous as literacy, so it won't matter.
First: every great system has a command shell. It is always an integral part of the system. It's been there since the system was born. The designer of the system couldn't imagine life without a command shell. The command shell is a full interface to the system: anything you can do with the system in some other way can also be done in the command shell. Great command shells are a big topic in their own right (most of the essential properties of living systems are, come to think of it.) A rough sketch: a great command shell always has a command language, an interactive help facility, a scripting language, an extension system, a command-history facility, and a rich command-line editor. A truly great command shell is an example of a living system in its own right: it can survive its parent system and migrate elsewhere.
All existing command shells are crap, but they are an essential component of building the best software that can be built today.
Emacs can be thought of as the ultimate command shell: what happens when command shells are taken to their logical extreme, or at least as far as anyone has taken the idea to date.
Command shells aren't the only common feature of the greatest software systems in the world, though, so we'll have to leave them for now.
Great systems also have advice. There's no universally accepted name for this feature. Sometimes it's called hooks, or filters, or aspect-oriented programming. As far as I know, Lisp had it first, and it's called advice in Lisp. Advice is a mini-framework that provides before, around, and after hooks by which you can programmatically modify the behavior of some action or function call in the system. Not all advice systems are created equal. The more scope that is given to an advice system — that is, the more reach it has in the system it's advising — the more powerful the parent system will be.
Ruby on Rails has a minor advice system, which Rails calls "filters". It is (only) capable of advising controller actions, which are special functions that render page requests. You can't put a before-, after-, or around-filter on any old API function in the system, although Ruby itself makes this possible to some extent through its metaprogramming facilities. But it's insufficient for advice to be merely theoretically possible. Advice must be built into the system from the ground up, and must be exposed as a first-class, well-documented programmer interface. Advice is very, very powerful. Even the simple action-filtering system in Rails offers amazing flexibility; it's hard to imagine writing a Rails app without it.
Emacs has a sophisticated advice system. Common Lisp has, arguably, the most powerful advice system in the world, which contributes in no small part to the power of the language. Aspect-Oriented Programming is a herculean attempt to bring advice to the Java language, but due to fundamental limitations of Java, it has to be implemented as a language extension with its own compiler and other language tools, which has severely hampered adoption. Another impediment is that Java programmers prefer to write dead systems, and any hint of a breath of life in the system bothers them greatly.
To be sure, it bothers me too. Living software is a little scary. It's no surprise that most programmers prefer writing marionettes instead of real people; marionettes are a lot easier to manage. But I think living software is more interesting, and more useful, and quite frankly it's an inevitability in any event, so we might as well strive to understand it better. To me, that means building it.
Moving right along, world-class software systems always have an extension language and a plug-in system — a way for programmers to extend the base functionality of the application. Sometimes plugins are called "mods". It's a way for your users to grow the system in ways the designer didn't anticipate.
Microsoft Excel has an excellent mod system. It's quite a remarkable programming framework, verging on being a platform in its own right. Like all the best mod systems, it's tiered, with the easy entry point being Excel macros, working its way up through a full COM interface that can be scripted using VB or even Python or Ruby: any language with COM bindings.
One of the killer features that made Doom and Quake so popular was their mod systems. Doom had some basic facilities for scripting your own levels, sprites, and even game logic. Quake had QuakeC, which is still, I think, the gold standard for PC game scripting, but my info is a little dated, since for the past five years or so I've played mostly console games, which are sadly all deader than a coffin-nail.
The very best plug-in systems are powerful enough to build the entire application in its own plug-in system. This has been the core philosophy behind both Emacs and Eclipse. There's a minimal bootstrap layer, which as we will see functions as the system's hardware, and the rest of the system, to the greatest extent possible (as dictated by performance, usually), is written in the extension language.
Firefox has a plugin system. It's a real piece of crap, but it has one, and one thing you'll quickly discover if you build a plug-in system is that there will always be a few crazed programmers who learn to use it and push it to its limits. This may fool you into thinking you have a good plug-in system, but in reality it has to be both easy to use and possible to use without rebooting the system; Firefox breaks both of these cardinal rules, so it's in an unstable state: either it'll get fixed, or something better will come along and everyone will switch to that.
What's really amazing to me is that there isn't even a special bypass for Firefox extension developers. Their development cycle is amazingly painful, as they have to manually re-install the plugin (using the GUI) on every change. With some symlink trickery you can get around about half the steps, but the community actually frowns on this! They evidently feel that if the user is going to experience the installation pain one time, then the programmer must experience it every single time a line of code changes, as a perpetual reminder that Firefox has a crappy plug-in system that the programmer can't actually do anything about. Fun!
Firefox was given a gift by a programmer named Aaron Boodman, now at Google. The gift was GreaseMonkey, which provides an alternate way of writing Firefox extensions. Unlike Firefox's regular plug-in system, GreaseMonkey extensions can be installed and updated without rebooting Firefox, and they're relatively easy to write. This gift has given Firefox new legs. I doubt most Firefox developers (let alone the Firefox user community at large) fully appreciate the importance of GreaseMonkey to the long-term survival of Firefox.
Interestingly, GreaseMonkey is implemented as a Firefox plugin that offers its own plugin system. This is a common pattern in plug-in systems: some plugins will grow large and configurable enough to be viewed as standalone applications. Emacs has many such plugins: the advice package is a good example. For that matter, the Rails filtering system is also implemented in the style of an optional system extension. Plugins, like other software systems, also have a lifespan that's determined by how well they incorporate the features I'm discussing today. They eventually need command shells, advice, extension languages, and so on. However, plugins usually get these things for free by virtue of having been built within a living system.
Building extensible systems is much harder than the alternative. It's commonly estimated at being three to five times harder than building the equivalent non-extensible version of the system. Adding a plug-in system is much easier up front. Adding extensibility to an existing legacy system is fantastically difficult, and requires massive refactoring of the system. The refactoring needed is rarely of the pretty little automatable type currently so fashionable in Java circles. It typically requires effort of the same order as a full rewrite of the system, although as with all refactoring, the risk can be mitigated by putting thorough unit tests in place first.
Many software systems these days are accessible only remotely, over a network, e.g. via a browser and HTTP. Some of the bigger companies that have built such systems, including Yahoo!, Amazon.com and eBay, have begun to realize that programmer extensibility is a critical feature for the long-term survival of their systems. They have begun selectively opening up access to their internal systems, usually via web service interfaces. This provides a certain level of extensibility: in particular, it enables independent software developers to create their own interfaces to the system. Over time, I think a key differentiator in the web-application space will be the quality of the programmer access to the systems backing the web apps.
Plugin systems have security issues. They have usability issues. They have namespace issues. They have dependency-graph issues. They have backwards-compatibility issues. Plugin systems are damn hard to do at all, let alone do well. And they are absolutely essential for ensuring the long-term survival of software systems.
What other features do great software systems have?
I think one important element, at least today, is that they either have to be a killer app, or they need one. Every world-class software system is, by its very nature, a platform. If you have a command-shell, and an extension language with advice, and a plug-in architecture, then you've already got the makings of a platform. But you need to give users some reason for using it in the first place. So the GIMP is for editing images, Eclipse is for editing Java code, Emacs is for editing plain text, Rails is for building web apps, Firefox is for browsing, Python is for scripting, Lua is for embedding, Mathematica is for math, and so on. Each of them can be stretched into other domains, but they're strongest when they're being used in their niche.
The most generic software systems, I think, are operating systems and programming languages, and even they have a primary purpose. OSes are primarily for resource management, and the most successful programming languages have usually carved out some niche: you use C++ when you need speed, Perl when you need Unix system administration, and Java when you need an especially fat API to impress a client. JavaScript had a lock on browser programming, Lisp has been mostly carried by Emacs all these years, and Ruby has taken off mostly due to Rails.
So software systems need a niche. Someday there may be a generic software system so powerful and well-designed that it's the best system to use for literally everything. Maybe you'll be the one to build it.
The last big feature I'll enumerate today, and it's just as important as the rest, is that great software systems are introspective. You can poke around and examine them at runtime, and ideally they poke around and examine themselves as well. At the very least they should have some basic health monitoring in place. Even in a relatively small system with lots of static checking, you still need monitoring on things like input and output queues, and for large systems, you need to monitor just about everything, including the monitoring systems. (If you don't have meta-monitoring, one bad thing that can happen is that your system gets into a state where all the health checks are returning OK, but the system is in fact totally wedged.)
Introspection can (and should) take many different forms, not just health monitoring. System administration tools and diagnostics are one kind of introspection; single-step debugging is another; profiling is yet another. Dynamic linking is still another: the system needs to be able to (for instance) run bytecode verifiers to make sure the code being loaded passes basic security checks. Introspection usually comes with a performance penalty, so many programmers avoid it at runtime, or they make do with whatever minimal introspection facilities the underlying system provides (e.g. RTTI or Java's reflection facility). If you trade off introspection for speed, you're carving years or even decades off the lifespan of your software system. If you're a consultant, or you just want to get it working so you can move on to something else, then maybe it doesn't matter. But I think most programmers prefer to work on systems that will last a long time.
There's a long tail of other features shared by the best software systems, but at this juncture I think it's best to talk a bit about how they all derive from not rebooting, at which point you should be able to identify the other common features easily enough.
Rebooting is Dying
I can't do this topic justice today, partly because it's a big topic, and partly because I just don't understand it very well. So the best I can do is sketch the outlines of it, and hopefully you'll get the picture.
First, let's get some philosophical perspectives out of the way. I take a very broad view of software: most of it isn't man-made. It's only the man-made stuff that's crap. There's a lot of pretty good naturally-occurring software out there. I think that the workings of our brains can mostly be considered software, and the workings of our bodies are definitely software. (Heck, we can even see the assembly-language instructions in our DNA, although we haven't quite figured out the full code yet.) So people are carrying around at least two software systems: body and mind.
I also think of stable ecosystems as being software systems, and for that matter, so are stable governments. So, too, are organizations of people, e.g. companies like the one you work for. Unless I grossly misunderstood Turing's position, software is anything that can produce computation, and computation only requires a machine with some simple mechanisms for changing the machine's state in deterministic ways, including branches, jumps, and reading/writing of persistent state, plus some set of instructions (a program) for playing out these operations.
I'm assuming my definition of software here is self-evident enough that I don't need to defend the position that not all software is man-made.
So my first argument against rebooting is that in nature it doesn't happen. Or, more accurately, when it does happen it's pretty catastrophic. If you don't like the way a person works, you don't kill them, fix their DNA, and then regrow them. If you don't like the way a government works, you don't shut it down, figure out what's wrong, and start it back up again. Why, then, do we almost always develop software that way?
My next argument against rebooting is from plain old software, the kind programmers make today. Take off your programmer's hat for a moment, and think about rebooting as an end user. Do you like having to reboot your software? Of course not. It's inconvenient.
Do you remember way back, maybe ten years ago, when Microsoft made the decision to eliminate all reboots from Windows NT? I've never worked at Microsoft and I heard this thirdhand, so I don't know exactly how it went down, but my understanding is that some exec got pissed off that seemingly every configuration change required a system reboot, and he or she orchestrated a massive effort to remove them all. When I heard about it, they were down to just five scenarios where a full restart was required. Just think of the impact that change had on the U.S. economy — millions of people saving 5 to 30 minutes a day on downtime from Windows reboots. It's just staggering. If only they could have eliminated the blue screens, it would have been pretty darn good software, wouldn't it?
Linux has gone through some growing pains here, and it's finally getting better, but I would guess it still has many more reboot scenarios than Windows does today.
However, I think the reboot problem may be much deeper than a little inconvenience. Viewed from a radical, yet possibly defensible perspective, a reboot is a murder.
How so? Well, one of the biggest unsolved open questions of all time is the question of consciousness: what the heck is it? What does it mean to be conscious? What exactly does it mean to be self-aware? Are pets conscious? Insects? Venus fly-traps? Where do you draw the line? At various times in history, the question of consciousness has gone in and out of fashion, but for the past few decades it's been very much in, and philosophers and cognitive scientists are working together to try to figure it out. As far as I can tell, the prevailing viewpoint (or leading theory, or whatever) is something like this: consciousness is recursive self-awareness, and it's a gradient (as opposed to a simple on/off) that's apparently a function of how many inputs and/or recursive levels of self-awareness your brain can process simultaneously. So pets are conscious, just not as much as people are. At least that's what I've gathered from reading various books, papers and essays about it written over the past 30 years or so.
Also, a particular consciousness (i.e. a specific person) is localized, focused uniquely at any given time in a manner similar to the way your vision can only be focused on a specific location. That means if you clone it, you've created a separate person. At least that seems to be what the big thought leaders like Daniel Dennett are saying. I.e. if you were somehow able to upload your brain's software to some other blank brain and "turn it on", you'd have a person just like you, but it wouldn't be you, and that person would immediately begin to diverge from you by virtue of having different experiences.
Well, if any of this is true (and weenie academics are welcome to come poke holes in minutiae of my exposition, with the understanding that pedantry is unlikely to change the big picture here very much), then software can be conscious. It's debatable whether any software in the world today is conscious enough to present any ethical problems with shutting it off, but you have to wonder how far off it really is.
For instance, I used to think of my dog Cino (a shih-tzu) as a relatively simple state machine: pee, poo, sleep, eat, play, lick nose for hours. As I got to know him, I gradually discerned many more states, hundreds of them, maybe even thousands, but I'm still not entirely convinced that his behavior isn't deterministic. I love him to pieces, so I'll give him the benefit of the doubt and assume he has a free will. But it's clear that you can predict his behavior at least 90% of the time without much effort. I imagine the same is true for me!
A dog seems more complex than a mouse, which is in turn probably a lot more complex than a cockroach, and at some point down the chain (maybe at ants? flatworms? single-celled organisms?) it seems like there's going to be a point where the animal is completely deterministic.
At least it seemed that way to me at first, but I now think otherwise. I personally believe that all creatures can exhibit some nondeterminism, precisely to the extent that they are composed of software rather than hardware. Your hardware is definitely deterministic. Anything Cino has done since he was born, without needing to be taught, is either hardware or firmware (i.e. built-in software that can't be unlearned or changed). Routines for going to pee (and knowing when it's time), sneezing and other reflexes, processing sensory information, digesting food, and thousands of others are all hardcoded in either his brain firmware or his body firmware, and it works predictably; any observable differences are attributable to his software responding to the current environment.
In other words, I think that both consciousness and free will (i.e. nondeterminism) are software properties.
Nobody's going to shed a tear over the deliberate slaying of an amoeba. Well, most people won't. Similarly, I don't think it makes sense to get worked up when your "Hello, World!" process commits ritual suicide by exiting main() after emitting its one message to the world. But I think we've established that each invocation of your "Hello, World" program is creating a separate instance of a minute consciousness.
Well... sort of. A "Hello, World" program, which has no loops or branches, can't exhibit any nondeterminism (unless it's imposed externally, e.g. by a random hardware error), so you can think of it as pure hardware implemented in software. But somewhere between Hello, World and Hal 9000 lies a minimal software program that can be considered to possess rudimentary consciousness, at which point turning it off is tantamount to killing it.
Do we have any software that complicated today? Complex enough and self-aware enough to be considered conscious from an ethical standpoint? Probably not. But I think we'll get there someday, and by then I sure hope we're not developing software the way we do today, with a compile/reboot cycle.
I think of most of the software we build today as being like setting up dominoes. It's Domino Design. You design it very carefully, and it runs once, during which time the dominoes all fall in a nice, predictable order, and if necessary you pick them all up again. The end result can be much fancier than you can achieve with dominoes — think of all the frames in the movie Toy Story, for instance. Not much different, but definitely fancier.
Even really complex pieces of software like search engines or e-commerce systems are generally approached using Domino Design. If you program primarily in C++ or Java, you're almost certainly guilty of it.
Rebooting a domino system is unavoidable. The notion of rebooting it for every change, every upgrade, is hardwired into the way we think about these systems. As for me, I don't think dominoes are very interesting. I'd personally rather play with an amoeba. And I'd think twice before squishing it and finding myself a new amoeba, if, for instance, it refused to learn to run a maze or something.
DWIM and QWAN
My thinking in this section is a bit fuzzy, so I'll keep it short. DWIM is a cute acronym invented, I think, by Larry Wall. It means "Do What I Mean", and the Perl community bandies it about quite a bit.
The idea behind DWIM is that perfect software is like a grateful djinn in a bottle who is granting you a wish. I'm not talking about those cheap-ass wishes you get from fountains or shooting stars, either. Everyone knows you have to phrase penny-wishes in legalese because the Wish Fairy gives you literally what you asked for, not what you meant. Just like all the software you use. In contrast, the DWIM genie is on your side, and is tolerant of grammatical and logical mistakes that might otherwise result in getting the wrong thing. ("A guy walks into a bar with a miniature piano and a twelve-inch pianist...")
DWIM is ostensibly what every programmer is trying to build into their software, but it's almost always done by guesswork, making assumptions about your end-users. Sometimes it's done by collaborative filtering or some other algorithmic approach, but that's error-prone as well. The only way to make DWIM appear more than fleetingly and accidentally is to create truly intelligent software — not just conscious, but intelligent, and hopefully also wise and perceptive and (gulp) friendly.
But that's where it starts to get a little worrisome, since everyone knows that "intelligent" doesn't necessarily imply sympathy to your cause, especially given that your cause may well be stupid.
So do we want DWIM or no? On the one hand, we want our software to be so good that it predicts your every desire and responds to all your needs, so you can live that hedonistic lifestyle you've always craved. On the other hand, it appears that the only way to do that is to create software that could easily be smarter than we are, at which point we worry about being marginalized at best, or enslaved and/or exterminated at worst.
I think this explains, at least in part, why most of our industry is trying to achieve pseudo-DWIM by building bigger and bigger dead systems. (And what better language for building big, dead systems than Java?) Dead systems are safely deterministic and controllable.
Let's be slightly less ambitious for a moment, and assume for the sake of argument that building conscious, intelligent software is unlikely to happen in our lifetime. Is it still possible to build software that's better than the run-of-the-mill crap most of us are churning out today?
There's another genie named QWAN, invented by the architect Christopher Alexander; it stands for "Quality Without a Name", and (much like the elusive thesis of this essay) it's something he's known about most of his life, and has been trying to both articulate it and find a way to produce it reliably for the entire time. In short, QWAN is an all-but intangible "I know it when I see it" property of certain spaces and/or structures that appears to be (a) most achievable via organic growth, and (b) mysteriously dependent on some hardware or firmware in the human brain, since it triggers warm fuzzies for just about everyone, but nobody really knows why.
At some point in the murky past, some software professionals realized that software can also have QWAN, and in the interim it's become clear that it's just as difficult to pin down in software as in physical architecture.
However, I'll assert that QWAN is most apparent in exactly the systems I listed as my favorites earlier in this essay, and it's mostly absent in the systems I said lacked the essential properties of living software. (I then enumerated a few of the big ones and did some vague hand-waving about the rest of them, in case you've forgotten.)
People have observed that Emacs has QWAN: a nice, organic, comfortable rightness that fits like a pair of old jeans, or a snug warm chair in a library by a fire. It's very right-brain stuff we're talking about here, all touchy and feely and sensitive: exactly the kind of thing that programmers are often so lousy at, so it's no wonder we don't know the recipe for building it into our software. But unlike with UI design, software QWAN can only come from the programmer, who is playing the roles of interior decorator, head chef, and ergonomic consultant for all the programmer-users of said software.
That's why I think most software is crap. I'm not talking about the end-user experience, I'm talking about the programmer experience (if it even offers one). Design is an art, not a science, and most of us aren't born artists. So it's actually pretty remarkable when QWAN evidences itself even a little in a software system.
Note, incidentally, that the end-user experience and programmer experience offered by a software system are almost totally orthogonal. Visual Studio actually offers a pretty slick end-user experience, where the end-user in question is a programmer trying to write some C++ or C# code (as opposed to trying to build tools to help write C++ or C# code, or to help automate away other common tasks.) Emacs offers a completely hostile end-user experience and a nearly unparalleled programmer experience. Eclipse is somewhere in the middle in both dimensions, but is definitely weighted more towards the end-user programmer than the programmer-user.
Finally, there are some aspects to QWAN that probably can't be captured in any recipe. Just adding my ingredients (a command shell, an extension language and advice system, etc.) will improve your software system, but it's no guarantee that QWAN will appear. Some of it just boils down to taste. And since tastes differ, and QWAN is nowhere near as smart as its cousin DWIM, one person's QWAN may be another's software hell.
I still think we should try to build it.
The Role of Type Systems
OK. I've finally built up enough context to be able to explain my position on type systems.
In short, type systems are for building hardware. Every software system has a machine beneath it — a stack of machines, actually, a whole heap of them, from the von Neumann machine with its CPUs and registers and buses down through the semiconductors and doping barriers to the atoms and quarks and their quantum-mechanical underpinnings.
But I take a broader view of hardware. Hardware is anything that produces computations deterministically and is so inflexible that you must either break it or replace it wholesale in order to change it. So it's not just the physical hardware made of atoms; in my view the hardware of a machine also encompasses any software that cannot be changed without a system reboot.
The notion of a type system is closely tied to the notions of "compile time" and "static checking". I tend to take a very broad view of type systems; I consider all constraint systems imposed on computation to be types of type systems, including things like scoping and visibility constraints (public/private/protected/friend/etc.), security constraints, even the fundamental computing architecture of the program as defined by its complete set of function signatures. My view of "static" typing actually includes some stuff that happens at runtime.
But most people, when they talk about static type systems, are talking about the kinds of validations that occur at compile time (with the help of type annotations that are part of the language syntax, and optionally type inference that's run on the IR built from the AST) and which evaporate at runtime.
Static type systems have several benefits over deferring the constraint checking to runtime. For one thing, they can result in faster code, because if you do your checking up front, and you can guarantee the system won't change at runtime, then you don't need to do the checks at runtime. For another, static constraints can often be examined and reported on by tools other than the compiler (e.g. your IDE), which can make it easier to follow the program flow.
And that's all just ducky.
There's nothing wrong with static type systems. You just have to realize that when you use them, you're building hardware, not software.
A static type system has absolutely no runtime effect on a correct program: exactly the same machine code is generated regardless of how many types you chose to model. Case in point: C++ code is no more efficient than C code, and C lacks any but the most primitive type system. C isn't dynamically typed, but it's not particularly statically typed either. It's possible to write fast, robust programs in straight C. (Emacs and the Linux kernel are two fine examples.)
The proper use of a static type system is to freeze software into hardware. Whenever when a particular set of deterministic operations (e.g. OpenGL rendering primitives) becomes ubiquitous enough and stable enough that it's worth trading off some flexibility to create a high-performance machine layer out of the API, we move it into hardware. But it's mostly a performance optimization (and in very small part, a standardization move, I suppose) that incurs a dramatic penalty in flexibility.
Because most programmers nowadays prefer to build marionettes rather than scary real children, most programming is oriented towards building layer upon layer of hardware. C++ and Java programmers (and I'd be willing to bet, C# programmers) are by default baking every line of code they write into hardware by modeling everything in the type system up front.
It's possible to write loosely-typed C++ and Java code using just arrays, linked lists, hashes, trees, and functions, but it's strongly deprecated (or at least frowned upon) in both camps, where strong typing and heavy-duty modeling have been growing increasingly fashionable for over a decade, to the detriment of productivity (which translates to software schedule) and flexibility (which also translates to schedule, via the ability to incorporate new features).
The devotees of the Hindley-Milner type system (which originated in academia and has only rarely escaped into the industry) like to believe that the H-M type system is far better than the Java or C++ type systems, because (among other reasons) it has fewer holes in it.
The reason H-M isn't used in the industry, folks, is that it doesn't have any holes. If you're trying to build software, but you believe (as most do) that you do it by repeatedly building and discarding hardware in a long, painful cycle until the hardware finally does what you want, then you need escape hatches: ways to tell the type system to shut the hell up, that you know what you're doing, that your program is in fact producing the desired computation. Type casts, narrowing and widening conversions, friend functions to bypass the standard class protections, stuffing minilanguages into strings and parsing them out by hand, there are dozens of ways to bypass the type systems in Java and C++, and programmers use them all the time, because (little do they know) they're actually trying to build software, not hardware.
H-M is very pretty, in a totally useless formal mathematical sense. It handles a few computation constructs very nicely; the pattern matching dispatch found in Haskell, SML and OCaml is particularly handy. Unsurprisingly, it handles some other common and highly desirable constructs awkwardly at best, but they explain those scenarios away by saying that you're mistaken, you don't actually want them. You know, things like, oh, setting variables. You don't want to do that, trust them on this. (OCaml lets you do it, but they look down their noses at such impurities.)
It's true that with some effort you can build beautiful, lithe marionettes with Haskell. But they will forever remain little wooden Pinocchio, never to be granted their wish for boyhood by the Good Fairy. Haskell has little or no notion of dynamic code loading or runtime reflection; it's such an alien concept to them that it's difficult even to discuss why they might be useful with a Haskell fan: their world-view just doesn't incorporate the idea of software that grows while it's alive and breathing.
Looking around at the somewhat shabby offerings available in the land of dynamic typing, it's not hard to see why so many programmers view dynamic languages as toys. The main crop of popular dynamic languages includes Perl, PHP, Python, Visual Basic, JavaScript, Ruby, Tcl, and Lua. With all due respect to the language designers, they all apparently flunked out of compiler school before starting work on their scripting languages. Case in point: they all screwed up lexical scoping. Ironically, having their scripting languages propelled into the limelight has turned all of them (Larry, Guido, Matz, Brendan, etc.) into world-class language designers, which makes them, Salieri-like, able to appreciate the weaknesses of their languages (which can now change only with great difficulty) in a way that most programmers will never know.
Scheme has great promise, but suffers from the fatal flaw that it can never grow, not in the way industrial-strength languages and platforms need to grow to sustain massive programmer populations. It has to stay small to keep its niche, which is in CS education.
Common Lisp is in many ways really ideal: it's a dynamically typed language with optional type annotations (i.e. you build software, then selectively turn it into hardware), lots of great tools and documentation, all of the essential features of living software I've enumerated in this essay, and a fair bit of QWAN thrown in for good measure. However, it has stopped growing, and programmers can sense momentum like a shark senses blood. Common Lisp has all of the exciting energy of a debate between William F. Buckley, Jr. and Charleton Heston. (I watched one once, and I'd swear they both slept through half of it.)
Plus Lisp lacks a C-like syntax. We will never be able to make real progress in computing and language design in our industry until C syntax is wholly eradicated: a task that could take fifty years. The only way to make progress in the meantime is to separate the model (the AST) and the presentation (the syntax) in programming languages, allow skinnable syntax, and let the C-like-syntax lovers continue to use it until they're all dead. Common Lisp could be enhanced to permit alternate syntaxes, but since it's not growing anymore, it's not going to happen. I would look elsewhere for the Next Big Thing.
Conclusion
It's 3:30am; I've overshot my monthly budget by over 2 hours. You might actually get a succinct blog out of me next month! In any case, I think I've got everything I wanted off my chest.
I think we want to build software that does what you mean. It will change society in ways that are difficult to predict, since DWIM can only really come from truly intelligent software. Nevertheless, I think it's what we want.
I doubt it will happen any time soon, because most programmers are relentlessly focused on building hardware, through diligent overapplication of their type systems to what would otherwise be perfectly good software.
In the interim between now and the emergence of DWIM from its magic lamp, I think we should build living software. These systems may only be as alive as a tree, but that should be sufficient to awaken QWAN in them, and all systems that have any QWAN at all are truly wonderful to use — at least as a programmer; their end-user quality varies widely.
Living software has a command shell, since you need a way to talk to it like a grown-up. It has an extension language, since you need a way to help it grow. It has an advice system, since you need a way to train and tailor it. It has a niche, since it needs users in order to thrive. It has a plug-in architecture, so you can dress it up for your party. And it is self-aware to the maximum extent possible given the external performance constraints. These features must be seamlessly and elegantly integrated, each subsystem implemented with the same care and attention to detail as the system as a whole.
And you shouldn't need to murder it every time you grow it. If you treat your software like a living thing, then eventually it just might become one.
If we ever wake up a real AI, I think it should be named Pinocchio.
It's about designing software. See, it seems like there's a good way to design software. A best way, even. And nobody does it. Well, a few people do, but even in those rare instances, I think it's accidental half the time.
I've been thinking about this problem on and off for quite a while, and wouldn't you know it, suddenly 18 years have gone by and I still can't quite articulate this... well, design principle, if that's what it is. But for the past month, I feel like I've been getting closer. Maybe you can help! I'll tell you what I know, and you can tell me what you know, and maybe we'll figure out something extraordinary.
By way of setting context for today's blog, I'll summarize everything I've ever written to date in one sentence: I think most software is crap. Well, that's not quite right. It's fairer to say that I think all software is crap. Yeah. There you have it, Stevey in a Nutshell: software is crap.
Even so, I think some software systems are better than others: the producer of the crap in question swallowed some pennies, maybe, so their crap is shiny in places. Once in a while someone will even swallow a ruby, and their crap is both beautiful and valuable, viewed from a certain, ah, distance. But a turd is still a turd, no matter how many precious stones someone ate to make it.
Lovely metaphor, eh? Made it myself!
Whenever I reflect on the software systems I like best — the ones that feel like old friends, like nice places to live — I see that they have some properties in common. I'll tell you what they are, at least the ones I've noticed, in a minute. Promise. But it's not the whole story. Once you add these properties to a software system, if you do them right, then you usually get a system that's as good as we can make them today. But they're still crap!
The real problem comes when I start thinking about what would happen if we could build software systems that aren't crappy. That thought exercise raises all sorts of interesting questions, and I don't know the answers to any of them. But I'll throw them out there too, maybe, as long as I don't go over my 4-hour time limit. Life beckons, and all that.
Favorite Systems
The big realization I had, sometime in the last month or so, is that all of the common properties of my favorite software systems can be derived from a single root cause: one property, or design principle, that if present will cause software to take on the right characteristics automatically.
What are my favorite software systems? Here are a few of the very best: Unix. Windows XP. Mac OS/X. Emacs. Microsoft Excel. Firefox. Ruby on Rails. Python. Ruby. Scheme. Common Lisp. LP Muds. The Java Virtual Machine.
A few more that just barely make the cut, for now: Microsoft Word. OmniGraffle Pro. JavaScript. Perforce.
Some that I think would make the cut if I learned how to use them effectively: The GIMP. Mathematica. VIM. Lua. Internet Explorer.
Most popular software systems out there don't make the cut. Most of them are quite useful, but I think they lack the essential properties of ideal software design. Examples: IntelliJ. Eclipse. Visual Studio. Java. C++. Perl. Nethack. Microsoft PowerPoint. All Nintendo and PlayStation console games. Nearly all PC games, with the notable exceptions of Doom and Quake. Most web applications, including highly useful ones like Amazon.com or Google Maps.
I won't keep you in suspense. I think the most important principle in all of software design is this: Systems should never reboot.
If you design a system so that it never needs to reboot, then you will eventually, even if it's by a very roundabout path, arrive at a system that will live forever.
All the systems I've listed need to reboot occasionally, which means their practical lifespan is anywhere from a dozen to a hundred more years. Some of them are getting up there — lots of them are in their twenties and thirties now, and there are even a few in their early forties. But they're all still a far cry from immortal.
I think the second most important design principle, really a corollary to the first, is that systems must be able to grow without rebooting. A system that can't grow over time is static, so it really isn't a system at all; it's a function. It might be a very complex function with lots of possible inputs and outputs. It might be a very useful function, and it might live for a long time. But functions are always either replaced or subsumed by systems that can grow. And I've come to believe, over nearly two decades of thinking about this, that systems that can grow and change without rebooting can live forever.
Essential Features
Here are some of the properties shared by the best software systems in the world today. Not all systems have all the properties I'll list here; I think very few of them have the full superset. I think you'll see that the more of the essential properties a system has, the more powerful, important, and long-lived it is.
Note: most of these are features for programmers. Features for non-technical end-users don't contribute to a system's lifespan. In the fullness of time, I believe programming fluency will become as ubiquitous as literacy, so it won't matter.
First: every great system has a command shell. It is always an integral part of the system. It's been there since the system was born. The designer of the system couldn't imagine life without a command shell. The command shell is a full interface to the system: anything you can do with the system in some other way can also be done in the command shell. Great command shells are a big topic in their own right (most of the essential properties of living systems are, come to think of it.) A rough sketch: a great command shell always has a command language, an interactive help facility, a scripting language, an extension system, a command-history facility, and a rich command-line editor. A truly great command shell is an example of a living system in its own right: it can survive its parent system and migrate elsewhere.
All existing command shells are crap, but they are an essential component of building the best software that can be built today.
Emacs can be thought of as the ultimate command shell: what happens when command shells are taken to their logical extreme, or at least as far as anyone has taken the idea to date.
Command shells aren't the only common feature of the greatest software systems in the world, though, so we'll have to leave them for now.
Great systems also have advice. There's no universally accepted name for this feature. Sometimes it's called hooks, or filters, or aspect-oriented programming. As far as I know, Lisp had it first, and it's called advice in Lisp. Advice is a mini-framework that provides before, around, and after hooks by which you can programmatically modify the behavior of some action or function call in the system. Not all advice systems are created equal. The more scope that is given to an advice system — that is, the more reach it has in the system it's advising — the more powerful the parent system will be.
Ruby on Rails has a minor advice system, which Rails calls "filters". It is (only) capable of advising controller actions, which are special functions that render page requests. You can't put a before-, after-, or around-filter on any old API function in the system, although Ruby itself makes this possible to some extent through its metaprogramming facilities. But it's insufficient for advice to be merely theoretically possible. Advice must be built into the system from the ground up, and must be exposed as a first-class, well-documented programmer interface. Advice is very, very powerful. Even the simple action-filtering system in Rails offers amazing flexibility; it's hard to imagine writing a Rails app without it.
Emacs has a sophisticated advice system. Common Lisp has, arguably, the most powerful advice system in the world, which contributes in no small part to the power of the language. Aspect-Oriented Programming is a herculean attempt to bring advice to the Java language, but due to fundamental limitations of Java, it has to be implemented as a language extension with its own compiler and other language tools, which has severely hampered adoption. Another impediment is that Java programmers prefer to write dead systems, and any hint of a breath of life in the system bothers them greatly.
To be sure, it bothers me too. Living software is a little scary. It's no surprise that most programmers prefer writing marionettes instead of real people; marionettes are a lot easier to manage. But I think living software is more interesting, and more useful, and quite frankly it's an inevitability in any event, so we might as well strive to understand it better. To me, that means building it.
Moving right along, world-class software systems always have an extension language and a plug-in system — a way for programmers to extend the base functionality of the application. Sometimes plugins are called "mods". It's a way for your users to grow the system in ways the designer didn't anticipate.
Microsoft Excel has an excellent mod system. It's quite a remarkable programming framework, verging on being a platform in its own right. Like all the best mod systems, it's tiered, with the easy entry point being Excel macros, working its way up through a full COM interface that can be scripted using VB or even Python or Ruby: any language with COM bindings.
One of the killer features that made Doom and Quake so popular was their mod systems. Doom had some basic facilities for scripting your own levels, sprites, and even game logic. Quake had QuakeC, which is still, I think, the gold standard for PC game scripting, but my info is a little dated, since for the past five years or so I've played mostly console games, which are sadly all deader than a coffin-nail.
The very best plug-in systems are powerful enough to build the entire application in its own plug-in system. This has been the core philosophy behind both Emacs and Eclipse. There's a minimal bootstrap layer, which as we will see functions as the system's hardware, and the rest of the system, to the greatest extent possible (as dictated by performance, usually), is written in the extension language.
Firefox has a plugin system. It's a real piece of crap, but it has one, and one thing you'll quickly discover if you build a plug-in system is that there will always be a few crazed programmers who learn to use it and push it to its limits. This may fool you into thinking you have a good plug-in system, but in reality it has to be both easy to use and possible to use without rebooting the system; Firefox breaks both of these cardinal rules, so it's in an unstable state: either it'll get fixed, or something better will come along and everyone will switch to that.
What's really amazing to me is that there isn't even a special bypass for Firefox extension developers. Their development cycle is amazingly painful, as they have to manually re-install the plugin (using the GUI) on every change. With some symlink trickery you can get around about half the steps, but the community actually frowns on this! They evidently feel that if the user is going to experience the installation pain one time, then the programmer must experience it every single time a line of code changes, as a perpetual reminder that Firefox has a crappy plug-in system that the programmer can't actually do anything about. Fun!
Firefox was given a gift by a programmer named Aaron Boodman, now at Google. The gift was GreaseMonkey, which provides an alternate way of writing Firefox extensions. Unlike Firefox's regular plug-in system, GreaseMonkey extensions can be installed and updated without rebooting Firefox, and they're relatively easy to write. This gift has given Firefox new legs. I doubt most Firefox developers (let alone the Firefox user community at large) fully appreciate the importance of GreaseMonkey to the long-term survival of Firefox.
Interestingly, GreaseMonkey is implemented as a Firefox plugin that offers its own plugin system. This is a common pattern in plug-in systems: some plugins will grow large and configurable enough to be viewed as standalone applications. Emacs has many such plugins: the advice package is a good example. For that matter, the Rails filtering system is also implemented in the style of an optional system extension. Plugins, like other software systems, also have a lifespan that's determined by how well they incorporate the features I'm discussing today. They eventually need command shells, advice, extension languages, and so on. However, plugins usually get these things for free by virtue of having been built within a living system.
Building extensible systems is much harder than the alternative. It's commonly estimated at being three to five times harder than building the equivalent non-extensible version of the system. Adding a plug-in system is much easier up front. Adding extensibility to an existing legacy system is fantastically difficult, and requires massive refactoring of the system. The refactoring needed is rarely of the pretty little automatable type currently so fashionable in Java circles. It typically requires effort of the same order as a full rewrite of the system, although as with all refactoring, the risk can be mitigated by putting thorough unit tests in place first.
Many software systems these days are accessible only remotely, over a network, e.g. via a browser and HTTP. Some of the bigger companies that have built such systems, including Yahoo!, Amazon.com and eBay, have begun to realize that programmer extensibility is a critical feature for the long-term survival of their systems. They have begun selectively opening up access to their internal systems, usually via web service interfaces. This provides a certain level of extensibility: in particular, it enables independent software developers to create their own interfaces to the system. Over time, I think a key differentiator in the web-application space will be the quality of the programmer access to the systems backing the web apps.
Plugin systems have security issues. They have usability issues. They have namespace issues. They have dependency-graph issues. They have backwards-compatibility issues. Plugin systems are damn hard to do at all, let alone do well. And they are absolutely essential for ensuring the long-term survival of software systems.
What other features do great software systems have?
I think one important element, at least today, is that they either have to be a killer app, or they need one. Every world-class software system is, by its very nature, a platform. If you have a command-shell, and an extension language with advice, and a plug-in architecture, then you've already got the makings of a platform. But you need to give users some reason for using it in the first place. So the GIMP is for editing images, Eclipse is for editing Java code, Emacs is for editing plain text, Rails is for building web apps, Firefox is for browsing, Python is for scripting, Lua is for embedding, Mathematica is for math, and so on. Each of them can be stretched into other domains, but they're strongest when they're being used in their niche.
The most generic software systems, I think, are operating systems and programming languages, and even they have a primary purpose. OSes are primarily for resource management, and the most successful programming languages have usually carved out some niche: you use C++ when you need speed, Perl when you need Unix system administration, and Java when you need an especially fat API to impress a client. JavaScript had a lock on browser programming, Lisp has been mostly carried by Emacs all these years, and Ruby has taken off mostly due to Rails.
So software systems need a niche. Someday there may be a generic software system so powerful and well-designed that it's the best system to use for literally everything. Maybe you'll be the one to build it.
The last big feature I'll enumerate today, and it's just as important as the rest, is that great software systems are introspective. You can poke around and examine them at runtime, and ideally they poke around and examine themselves as well. At the very least they should have some basic health monitoring in place. Even in a relatively small system with lots of static checking, you still need monitoring on things like input and output queues, and for large systems, you need to monitor just about everything, including the monitoring systems. (If you don't have meta-monitoring, one bad thing that can happen is that your system gets into a state where all the health checks are returning OK, but the system is in fact totally wedged.)
Introspection can (and should) take many different forms, not just health monitoring. System administration tools and diagnostics are one kind of introspection; single-step debugging is another; profiling is yet another. Dynamic linking is still another: the system needs to be able to (for instance) run bytecode verifiers to make sure the code being loaded passes basic security checks. Introspection usually comes with a performance penalty, so many programmers avoid it at runtime, or they make do with whatever minimal introspection facilities the underlying system provides (e.g. RTTI or Java's reflection facility). If you trade off introspection for speed, you're carving years or even decades off the lifespan of your software system. If you're a consultant, or you just want to get it working so you can move on to something else, then maybe it doesn't matter. But I think most programmers prefer to work on systems that will last a long time.
There's a long tail of other features shared by the best software systems, but at this juncture I think it's best to talk a bit about how they all derive from not rebooting, at which point you should be able to identify the other common features easily enough.
Rebooting is Dying
I can't do this topic justice today, partly because it's a big topic, and partly because I just don't understand it very well. So the best I can do is sketch the outlines of it, and hopefully you'll get the picture.
First, let's get some philosophical perspectives out of the way. I take a very broad view of software: most of it isn't man-made. It's only the man-made stuff that's crap. There's a lot of pretty good naturally-occurring software out there. I think that the workings of our brains can mostly be considered software, and the workings of our bodies are definitely software. (Heck, we can even see the assembly-language instructions in our DNA, although we haven't quite figured out the full code yet.) So people are carrying around at least two software systems: body and mind.
I also think of stable ecosystems as being software systems, and for that matter, so are stable governments. So, too, are organizations of people, e.g. companies like the one you work for. Unless I grossly misunderstood Turing's position, software is anything that can produce computation, and computation only requires a machine with some simple mechanisms for changing the machine's state in deterministic ways, including branches, jumps, and reading/writing of persistent state, plus some set of instructions (a program) for playing out these operations.
I'm assuming my definition of software here is self-evident enough that I don't need to defend the position that not all software is man-made.
So my first argument against rebooting is that in nature it doesn't happen. Or, more accurately, when it does happen it's pretty catastrophic. If you don't like the way a person works, you don't kill them, fix their DNA, and then regrow them. If you don't like the way a government works, you don't shut it down, figure out what's wrong, and start it back up again. Why, then, do we almost always develop software that way?
My next argument against rebooting is from plain old software, the kind programmers make today. Take off your programmer's hat for a moment, and think about rebooting as an end user. Do you like having to reboot your software? Of course not. It's inconvenient.
Do you remember way back, maybe ten years ago, when Microsoft made the decision to eliminate all reboots from Windows NT? I've never worked at Microsoft and I heard this thirdhand, so I don't know exactly how it went down, but my understanding is that some exec got pissed off that seemingly every configuration change required a system reboot, and he or she orchestrated a massive effort to remove them all. When I heard about it, they were down to just five scenarios where a full restart was required. Just think of the impact that change had on the U.S. economy — millions of people saving 5 to 30 minutes a day on downtime from Windows reboots. It's just staggering. If only they could have eliminated the blue screens, it would have been pretty darn good software, wouldn't it?
Linux has gone through some growing pains here, and it's finally getting better, but I would guess it still has many more reboot scenarios than Windows does today.
However, I think the reboot problem may be much deeper than a little inconvenience. Viewed from a radical, yet possibly defensible perspective, a reboot is a murder.
How so? Well, one of the biggest unsolved open questions of all time is the question of consciousness: what the heck is it? What does it mean to be conscious? What exactly does it mean to be self-aware? Are pets conscious? Insects? Venus fly-traps? Where do you draw the line? At various times in history, the question of consciousness has gone in and out of fashion, but for the past few decades it's been very much in, and philosophers and cognitive scientists are working together to try to figure it out. As far as I can tell, the prevailing viewpoint (or leading theory, or whatever) is something like this: consciousness is recursive self-awareness, and it's a gradient (as opposed to a simple on/off) that's apparently a function of how many inputs and/or recursive levels of self-awareness your brain can process simultaneously. So pets are conscious, just not as much as people are. At least that's what I've gathered from reading various books, papers and essays about it written over the past 30 years or so.
Also, a particular consciousness (i.e. a specific person) is localized, focused uniquely at any given time in a manner similar to the way your vision can only be focused on a specific location. That means if you clone it, you've created a separate person. At least that seems to be what the big thought leaders like Daniel Dennett are saying. I.e. if you were somehow able to upload your brain's software to some other blank brain and "turn it on", you'd have a person just like you, but it wouldn't be you, and that person would immediately begin to diverge from you by virtue of having different experiences.
Well, if any of this is true (and weenie academics are welcome to come poke holes in minutiae of my exposition, with the understanding that pedantry is unlikely to change the big picture here very much), then software can be conscious. It's debatable whether any software in the world today is conscious enough to present any ethical problems with shutting it off, but you have to wonder how far off it really is.
For instance, I used to think of my dog Cino (a shih-tzu) as a relatively simple state machine: pee, poo, sleep, eat, play, lick nose for hours. As I got to know him, I gradually discerned many more states, hundreds of them, maybe even thousands, but I'm still not entirely convinced that his behavior isn't deterministic. I love him to pieces, so I'll give him the benefit of the doubt and assume he has a free will. But it's clear that you can predict his behavior at least 90% of the time without much effort. I imagine the same is true for me!
A dog seems more complex than a mouse, which is in turn probably a lot more complex than a cockroach, and at some point down the chain (maybe at ants? flatworms? single-celled organisms?) it seems like there's going to be a point where the animal is completely deterministic.
At least it seemed that way to me at first, but I now think otherwise. I personally believe that all creatures can exhibit some nondeterminism, precisely to the extent that they are composed of software rather than hardware. Your hardware is definitely deterministic. Anything Cino has done since he was born, without needing to be taught, is either hardware or firmware (i.e. built-in software that can't be unlearned or changed). Routines for going to pee (and knowing when it's time), sneezing and other reflexes, processing sensory information, digesting food, and thousands of others are all hardcoded in either his brain firmware or his body firmware, and it works predictably; any observable differences are attributable to his software responding to the current environment.
In other words, I think that both consciousness and free will (i.e. nondeterminism) are software properties.
Nobody's going to shed a tear over the deliberate slaying of an amoeba. Well, most people won't. Similarly, I don't think it makes sense to get worked up when your "Hello, World!" process commits ritual suicide by exiting main() after emitting its one message to the world. But I think we've established that each invocation of your "Hello, World" program is creating a separate instance of a minute consciousness.
Well... sort of. A "Hello, World" program, which has no loops or branches, can't exhibit any nondeterminism (unless it's imposed externally, e.g. by a random hardware error), so you can think of it as pure hardware implemented in software. But somewhere between Hello, World and Hal 9000 lies a minimal software program that can be considered to possess rudimentary consciousness, at which point turning it off is tantamount to killing it.
Do we have any software that complicated today? Complex enough and self-aware enough to be considered conscious from an ethical standpoint? Probably not. But I think we'll get there someday, and by then I sure hope we're not developing software the way we do today, with a compile/reboot cycle.
I think of most of the software we build today as being like setting up dominoes. It's Domino Design. You design it very carefully, and it runs once, during which time the dominoes all fall in a nice, predictable order, and if necessary you pick them all up again. The end result can be much fancier than you can achieve with dominoes — think of all the frames in the movie Toy Story, for instance. Not much different, but definitely fancier.
Even really complex pieces of software like search engines or e-commerce systems are generally approached using Domino Design. If you program primarily in C++ or Java, you're almost certainly guilty of it.
Rebooting a domino system is unavoidable. The notion of rebooting it for every change, every upgrade, is hardwired into the way we think about these systems. As for me, I don't think dominoes are very interesting. I'd personally rather play with an amoeba. And I'd think twice before squishing it and finding myself a new amoeba, if, for instance, it refused to learn to run a maze or something.
DWIM and QWAN
My thinking in this section is a bit fuzzy, so I'll keep it short. DWIM is a cute acronym invented, I think, by Larry Wall. It means "Do What I Mean", and the Perl community bandies it about quite a bit.
The idea behind DWIM is that perfect software is like a grateful djinn in a bottle who is granting you a wish. I'm not talking about those cheap-ass wishes you get from fountains or shooting stars, either. Everyone knows you have to phrase penny-wishes in legalese because the Wish Fairy gives you literally what you asked for, not what you meant. Just like all the software you use. In contrast, the DWIM genie is on your side, and is tolerant of grammatical and logical mistakes that might otherwise result in getting the wrong thing. ("A guy walks into a bar with a miniature piano and a twelve-inch pianist...")
DWIM is ostensibly what every programmer is trying to build into their software, but it's almost always done by guesswork, making assumptions about your end-users. Sometimes it's done by collaborative filtering or some other algorithmic approach, but that's error-prone as well. The only way to make DWIM appear more than fleetingly and accidentally is to create truly intelligent software — not just conscious, but intelligent, and hopefully also wise and perceptive and (gulp) friendly.
But that's where it starts to get a little worrisome, since everyone knows that "intelligent" doesn't necessarily imply sympathy to your cause, especially given that your cause may well be stupid.
So do we want DWIM or no? On the one hand, we want our software to be so good that it predicts your every desire and responds to all your needs, so you can live that hedonistic lifestyle you've always craved. On the other hand, it appears that the only way to do that is to create software that could easily be smarter than we are, at which point we worry about being marginalized at best, or enslaved and/or exterminated at worst.
I think this explains, at least in part, why most of our industry is trying to achieve pseudo-DWIM by building bigger and bigger dead systems. (And what better language for building big, dead systems than Java?) Dead systems are safely deterministic and controllable.
Let's be slightly less ambitious for a moment, and assume for the sake of argument that building conscious, intelligent software is unlikely to happen in our lifetime. Is it still possible to build software that's better than the run-of-the-mill crap most of us are churning out today?
There's another genie named QWAN, invented by the architect Christopher Alexander; it stands for "Quality Without a Name", and (much like the elusive thesis of this essay) it's something he's known about most of his life, and has been trying to both articulate it and find a way to produce it reliably for the entire time. In short, QWAN is an all-but intangible "I know it when I see it" property of certain spaces and/or structures that appears to be (a) most achievable via organic growth, and (b) mysteriously dependent on some hardware or firmware in the human brain, since it triggers warm fuzzies for just about everyone, but nobody really knows why.
At some point in the murky past, some software professionals realized that software can also have QWAN, and in the interim it's become clear that it's just as difficult to pin down in software as in physical architecture.
However, I'll assert that QWAN is most apparent in exactly the systems I listed as my favorites earlier in this essay, and it's mostly absent in the systems I said lacked the essential properties of living software. (I then enumerated a few of the big ones and did some vague hand-waving about the rest of them, in case you've forgotten.)
People have observed that Emacs has QWAN: a nice, organic, comfortable rightness that fits like a pair of old jeans, or a snug warm chair in a library by a fire. It's very right-brain stuff we're talking about here, all touchy and feely and sensitive: exactly the kind of thing that programmers are often so lousy at, so it's no wonder we don't know the recipe for building it into our software. But unlike with UI design, software QWAN can only come from the programmer, who is playing the roles of interior decorator, head chef, and ergonomic consultant for all the programmer-users of said software.
That's why I think most software is crap. I'm not talking about the end-user experience, I'm talking about the programmer experience (if it even offers one). Design is an art, not a science, and most of us aren't born artists. So it's actually pretty remarkable when QWAN evidences itself even a little in a software system.
Note, incidentally, that the end-user experience and programmer experience offered by a software system are almost totally orthogonal. Visual Studio actually offers a pretty slick end-user experience, where the end-user in question is a programmer trying to write some C++ or C# code (as opposed to trying to build tools to help write C++ or C# code, or to help automate away other common tasks.) Emacs offers a completely hostile end-user experience and a nearly unparalleled programmer experience. Eclipse is somewhere in the middle in both dimensions, but is definitely weighted more towards the end-user programmer than the programmer-user.
Finally, there are some aspects to QWAN that probably can't be captured in any recipe. Just adding my ingredients (a command shell, an extension language and advice system, etc.) will improve your software system, but it's no guarantee that QWAN will appear. Some of it just boils down to taste. And since tastes differ, and QWAN is nowhere near as smart as its cousin DWIM, one person's QWAN may be another's software hell.
I still think we should try to build it.
The Role of Type Systems
OK. I've finally built up enough context to be able to explain my position on type systems.
In short, type systems are for building hardware. Every software system has a machine beneath it — a stack of machines, actually, a whole heap of them, from the von Neumann machine with its CPUs and registers and buses down through the semiconductors and doping barriers to the atoms and quarks and their quantum-mechanical underpinnings.
But I take a broader view of hardware. Hardware is anything that produces computations deterministically and is so inflexible that you must either break it or replace it wholesale in order to change it. So it's not just the physical hardware made of atoms; in my view the hardware of a machine also encompasses any software that cannot be changed without a system reboot.
The notion of a type system is closely tied to the notions of "compile time" and "static checking". I tend to take a very broad view of type systems; I consider all constraint systems imposed on computation to be types of type systems, including things like scoping and visibility constraints (public/private/protected/friend/etc.), security constraints, even the fundamental computing architecture of the program as defined by its complete set of function signatures. My view of "static" typing actually includes some stuff that happens at runtime.
But most people, when they talk about static type systems, are talking about the kinds of validations that occur at compile time (with the help of type annotations that are part of the language syntax, and optionally type inference that's run on the IR built from the AST) and which evaporate at runtime.
Static type systems have several benefits over deferring the constraint checking to runtime. For one thing, they can result in faster code, because if you do your checking up front, and you can guarantee the system won't change at runtime, then you don't need to do the checks at runtime. For another, static constraints can often be examined and reported on by tools other than the compiler (e.g. your IDE), which can make it easier to follow the program flow.
And that's all just ducky.
There's nothing wrong with static type systems. You just have to realize that when you use them, you're building hardware, not software.
A static type system has absolutely no runtime effect on a correct program: exactly the same machine code is generated regardless of how many types you chose to model. Case in point: C++ code is no more efficient than C code, and C lacks any but the most primitive type system. C isn't dynamically typed, but it's not particularly statically typed either. It's possible to write fast, robust programs in straight C. (Emacs and the Linux kernel are two fine examples.)
The proper use of a static type system is to freeze software into hardware. Whenever when a particular set of deterministic operations (e.g. OpenGL rendering primitives) becomes ubiquitous enough and stable enough that it's worth trading off some flexibility to create a high-performance machine layer out of the API, we move it into hardware. But it's mostly a performance optimization (and in very small part, a standardization move, I suppose) that incurs a dramatic penalty in flexibility.
Because most programmers nowadays prefer to build marionettes rather than scary real children, most programming is oriented towards building layer upon layer of hardware. C++ and Java programmers (and I'd be willing to bet, C# programmers) are by default baking every line of code they write into hardware by modeling everything in the type system up front.
It's possible to write loosely-typed C++ and Java code using just arrays, linked lists, hashes, trees, and functions, but it's strongly deprecated (or at least frowned upon) in both camps, where strong typing and heavy-duty modeling have been growing increasingly fashionable for over a decade, to the detriment of productivity (which translates to software schedule) and flexibility (which also translates to schedule, via the ability to incorporate new features).
The devotees of the Hindley-Milner type system (which originated in academia and has only rarely escaped into the industry) like to believe that the H-M type system is far better than the Java or C++ type systems, because (among other reasons) it has fewer holes in it.
The reason H-M isn't used in the industry, folks, is that it doesn't have any holes. If you're trying to build software, but you believe (as most do) that you do it by repeatedly building and discarding hardware in a long, painful cycle until the hardware finally does what you want, then you need escape hatches: ways to tell the type system to shut the hell up, that you know what you're doing, that your program is in fact producing the desired computation. Type casts, narrowing and widening conversions, friend functions to bypass the standard class protections, stuffing minilanguages into strings and parsing them out by hand, there are dozens of ways to bypass the type systems in Java and C++, and programmers use them all the time, because (little do they know) they're actually trying to build software, not hardware.
H-M is very pretty, in a totally useless formal mathematical sense. It handles a few computation constructs very nicely; the pattern matching dispatch found in Haskell, SML and OCaml is particularly handy. Unsurprisingly, it handles some other common and highly desirable constructs awkwardly at best, but they explain those scenarios away by saying that you're mistaken, you don't actually want them. You know, things like, oh, setting variables. You don't want to do that, trust them on this. (OCaml lets you do it, but they look down their noses at such impurities.)
It's true that with some effort you can build beautiful, lithe marionettes with Haskell. But they will forever remain little wooden Pinocchio, never to be granted their wish for boyhood by the Good Fairy. Haskell has little or no notion of dynamic code loading or runtime reflection; it's such an alien concept to them that it's difficult even to discuss why they might be useful with a Haskell fan: their world-view just doesn't incorporate the idea of software that grows while it's alive and breathing.
Looking around at the somewhat shabby offerings available in the land of dynamic typing, it's not hard to see why so many programmers view dynamic languages as toys. The main crop of popular dynamic languages includes Perl, PHP, Python, Visual Basic, JavaScript, Ruby, Tcl, and Lua. With all due respect to the language designers, they all apparently flunked out of compiler school before starting work on their scripting languages. Case in point: they all screwed up lexical scoping. Ironically, having their scripting languages propelled into the limelight has turned all of them (Larry, Guido, Matz, Brendan, etc.) into world-class language designers, which makes them, Salieri-like, able to appreciate the weaknesses of their languages (which can now change only with great difficulty) in a way that most programmers will never know.
Scheme has great promise, but suffers from the fatal flaw that it can never grow, not in the way industrial-strength languages and platforms need to grow to sustain massive programmer populations. It has to stay small to keep its niche, which is in CS education.
Common Lisp is in many ways really ideal: it's a dynamically typed language with optional type annotations (i.e. you build software, then selectively turn it into hardware), lots of great tools and documentation, all of the essential features of living software I've enumerated in this essay, and a fair bit of QWAN thrown in for good measure. However, it has stopped growing, and programmers can sense momentum like a shark senses blood. Common Lisp has all of the exciting energy of a debate between William F. Buckley, Jr. and Charleton Heston. (I watched one once, and I'd swear they both slept through half of it.)
Plus Lisp lacks a C-like syntax. We will never be able to make real progress in computing and language design in our industry until C syntax is wholly eradicated: a task that could take fifty years. The only way to make progress in the meantime is to separate the model (the AST) and the presentation (the syntax) in programming languages, allow skinnable syntax, and let the C-like-syntax lovers continue to use it until they're all dead. Common Lisp could be enhanced to permit alternate syntaxes, but since it's not growing anymore, it's not going to happen. I would look elsewhere for the Next Big Thing.
Conclusion
It's 3:30am; I've overshot my monthly budget by over 2 hours. You might actually get a succinct blog out of me next month! In any case, I think I've got everything I wanted off my chest.
I think we want to build software that does what you mean. It will change society in ways that are difficult to predict, since DWIM can only really come from truly intelligent software. Nevertheless, I think it's what we want.
I doubt it will happen any time soon, because most programmers are relentlessly focused on building hardware, through diligent overapplication of their type systems to what would otherwise be perfectly good software.
In the interim between now and the emergence of DWIM from its magic lamp, I think we should build living software. These systems may only be as alive as a tree, but that should be sufficient to awaken QWAN in them, and all systems that have any QWAN at all are truly wonderful to use — at least as a programmer; their end-user quality varies widely.
Living software has a command shell, since you need a way to talk to it like a grown-up. It has an extension language, since you need a way to help it grow. It has an advice system, since you need a way to train and tailor it. It has a niche, since it needs users in order to thrive. It has a plug-in architecture, so you can dress it up for your party. And it is self-aware to the maximum extent possible given the external performance constraints. These features must be seamlessly and elegantly integrated, each subsystem implemented with the same care and attention to detail as the system as a whole.
And you shouldn't need to murder it every time you grow it. If you treat your software like a living thing, then eventually it just might become one.
If we ever wake up a real AI, I think it should be named Pinocchio.
Langganan:
Postingan (Atom)