That's just a rounding error. Everyone knows BUS speeds end in 00, 33, or 66 (i.e., they go in increments of thirds of 100), so they rounded to the nearest possible increment.
> Maybe we all need to learn to speak the Indian languages. What do they speak?
That's a tall order. There are almost as many Hindustani languages as there are African languages. You can see a list of the *major* ones here: http://en.wikipedia.org/wiki/Category:Langu ages_of _India
Of course, each village has its own dialect, and a lot of the people are polyglots. In general, I'd guess that the three languages a random person from India is most likely to know are probably Hindi, Tamil, and English -- but this is like saying that the three languages a European is most likely to know are English, German, and Russian. (Note the presense of English on both lists; it's on the equivalent list for every continent or major geopolitical region.)
> As an Emacser, you should definitely get into Common Lisp. I don't know > Inform, so I can't compare the object-oriented parts of the two languages, > but I have yet to come up with an object-oriented feature that I really > wanted and Common Lisp didn't provide. (Incidentally, that includes > multiple inheritance, which is only present in one of the more popular > programming languages.)
Inform has multiple inheritance of *course*, a full inheritance tree. Any language that doesn't is not, as far as I'm concerned, really object-oriented. Inform also, orthogonal to the inheritance tree, has an object forest, which is a *really* useful data structure for organizing objects. And it has instance properties, which a lot of the wimpier pseudo-object-oriented languages don't have.
Say you have an object, foo, which inherits from two classes, Bar and Baz. Baz in turn inherents from Quux, which inherents from Lambda and Chortle. foo also belongs to the metaclass Object (whereas, Bar, Baz, Quux, Lambda, and Chortle belong to metaclass Class). Now, Lambda provides a property called aleph, with a string for the default value, and a property called beth, with a number for the default value. Chortle provides gimmel, with a routine for the default. Quux overrides Lambda's value for aleph with a routine that determines the correct string dynamically, based on the current situation. Bar overrides Chortle's (routine) value for gimmel with a more interesting/precise routine better suited for Bar objects.
All of that is just garden-variety multiple inheritance, but here's where it gets interesting: foo can also override the value for any of these properties in any way it chooses, and additionally can also provide the properties daleth and waw. (Recall that foo is an individual object -- an instance, in C++ parlance, not a class.)
Then there's the object forest: you can move foo into/onto another object, wibble, so that foo is a child of wibble, and move some other objects to wibble also, so that foo has siblings. Then you can move objects to foo so that it has children. Think of it as a general tree that is built into the language core. Additionally, there's an objectloop control-flow thing for looping over the objects that are in a certain object, belong to a certain class, provide a certain property, or meet other specified criteria.
Infix syntax is one of the things I don't miss in elisp, so I don't see why I should miss it in Common Lisp either. What I do miss in elisp is a sane quoting syntax for regular expressions; all those double-backslashed regex metacharacters make the regular expression library, powerful as it is, a serious pain in the neck to actually use. When I need regexen, I usually write the code in Perl instead -- in some cases I would anyway, because Perl is just generally better for some things (and the CPAN is several orders of magnitude easier to use for finding and installing modules than the Emacs equivalent). However, Perl isn't so hot in some cases, such as when large amounts of user intervention are required -- elisp is particularly good for situations where you want to integrate what's being done into an editing environment; Perl just can't hack that; its UI isn't made for that.
(Yeah, there are the special versions of Emacs with Perl embedded. I've never gotten around to trying them out. Maybe I should. But maybe elisp should be extended with a better regex-quoting construct, too.)
INTERCAL also has had some influence on other languages, such as unlambda, so an argument could be made for including it in the chart. (Mind you, I would not want to have to defend such an argument against all possible rational counterarguments.)
> could wax on in Oldtimer Mode some more, and talk about carrying my coding > forms uphill in the snow (both directions) but I'll spare you youngsters. > Shoot, this was the late 70's; some of you think the Oldies songs on the > radio are newer than that....
Oh, don't get me started on that noise they try to pass off as music these days. Bah, twentieth-century "music" is all a bunch of new-fangled garbage. Most of it doesn't even have counterpoint -- I'm not sure where they get off calling it music if it doesn't have counterpoint. Preposterous. Music without counterpoint, bah, what's next, candy without sugar? Beer without alcohol? Back in my day we wouldn't have stood for such things. We listened to fugue -- real music with real character -- and the candy we ate rotted our teeth, and people who drank beer got drunk -- and they liked it that way.
Come back here, you little rapscallion, I'm not through with you yet, whippersnapper...
> Common Lisp is also object-oriented and beats every other language I > know in that arena.
Common Lisp is one of those languages I keep telling myself I Really Ought To Learn. But I haven't gotten around to it yet.
The best OO I've ever seen in any language is Inform. Knocks the socks off of everything. Perl is _finally_ getting decent OO in version 6, but it *still* won't have some of the niftier OO features of Inform, such as the object forest and the objectloop control flow structure, both of which are incredibly useful, sometimes in unexpected ways. (They were designed for solving a particular class of problems that are important for Inform's special purpose, but they're useful generally.)
> Emacs has been around for approximately 30+ years. Why would I want to > learn an arbitrary set of keybindings that have no historical basis or > applicability elsewhere?
Exactly. Emacs has supported the cursor keys since they were added to the keyboard (what, in the seventies?), so why would you want to learn ^a for ^e for end and so forth, when those keys won't work in other applications, but the regular ones *will* work in Emacs, and have for decades?
And for standard key bindings that Emacs *doesn't* support out of the box, when every other application in the universe does (such as ^a for select all), well, that's what Emacs gives us the ability to rebind keys for, isn't it?
What annoys me is that other applications don't have some of the functionality that I'm accustomed to in Emacs. For example, it bugs me no end that I can't do C-h k in OpenOffice or Mozilla. If they had that functionality on another keystroke, I'd rebind Emacs to match so I don't have to switch keybindings whenever I switch windows -- but the other apps don't have that capability at all, so I still have to remember whether I'm in Emacs or not. (Describe key is just one of numerous Emacs features I miss in other apps. Apropos is another. Paren matching is another.)
Huh. I would not have guessed any of those keys in a million years. ^e doesn't do anything particularly unique. (I think it duplicates what the end key does. I have no idea why anyone would need a second key combination for that.) ^a I don't know what it used to do, because I rebound it to select the whole buffer several years ago and haven't looked back. ^f flips between two cursor positions on my setup, but I think that's a customization too; I don't really know what it does OOTB. ^b and ^n are cycle-buffer-permissive and cycle-buffer-backward-permissive, or, as I like to think of them, Back a buffer and Next buffer. Those might be ones I customized too, or not, I don't recall; maybe one of the minor modes I use rebinds them. ^p is another key that just duplicates one of the cursor keys, so who needs that? And ^d is another dupe, this time for delete. Yeah, we've already got backspace for deleting backward and two distinct delete keys for deleting forwards, I *sure* needed one more key combination for *that*.
If there are a handful of key bindings people would want in other apps, I would have guessed ones like maybe C-x C-f and C-x C-s and so forth, but I never would have come up with the ones you listed. I had to use C-h k to identify what some of them even do.
> But I do like your approach of just including open office in the GNU > emacs distro.
Works for me. While we're at it, can we get MySQL and Apache on the CPAN so that we can install them with CPAN.pm like every other Perl module, so that all the hillion jillion modules that depend on them don't need "external dependencies"? Thanks. Also, ActivePerl should come with gcc and make and so on so that CPAN.pm will work correctly on Win32, like it does on every other OS. Whatever makes our lives easier by requiring less fussing around to get things working. I've still got over 15% of the space on my filesystem free -- free as in doing nothing useful at the moment, and it's only a 25G filesystem, which is small by today's standards, and I've spared nothing in terms of installing everything useful. (Two different versions of Gnus, just because I didn't bother to rm the old one? Check. Half a dozen versions of Mozilla? Check. Multiple versions of OO.o? Yes, and cetera. I could probably free up another five GB without giving up anything current.)
Re:The hole in our Apple theories
on
Solaris 10 Released
·
· Score: 1, Insightful
Apple doesn't have the _infrastructure_ to compete with Microsoft. If they were to suddenly get even 5% of Microsoft's market share in a year, it would be more than a company Apple's size could handle -- it would *double* the size of their business, and while that may sound attractive on the face of it, it's the kind of thing that could destroy a company as easily as raise it up.
Don't get me wrong: I'm not saying Apple doesn't want to grow. They do. But they want to grow in a way that works for them as a company. The Mac Mini could conceivably boost their market share considerably -- by as much as 50% in three years, I guesstimate, which is huge (if it materializes, which is hard to predict), and by then they'll have figured out where they want to go next. The iPod isn't exactly hurting them either.
It's also noteworthy that Apple's growth pattern is healthier than Microsoft's, in that it's more diverse. Microsoft is almost entirely in software, and a little hardware. Apple's got a nice ballance of hardware and software and has been moving into music. I've been wondering for years why Microsoft doesn't diversify more -- at their size, they should be in half a dozen industries. They should own a big movie studio and a major restaurant chain, or something. When you're that big, you're supposed to wonder, "What happens if a competitor comes along and forces us to cut prices to compete until the profits in our entire industry are razor thin?" Microsoft *knows* this can happen, and they're scared to death of Linux in particular, but what are they doing about it? Nothing. (Well, sure, they're doing plenty to try to *prevent* that from happening, but they're doing nothing to ensure their survival and profitablity as a company in the event it *does* happen.)
Long term, I like Apple's prospects better than Microsoft's, because they're manifestly smarter about the way they conduct business.
But of the three, I'd worry most about Sun. They do have the ballance of hardware and software (and support contracts), but they've always had that, and they don't seem to have fundamentally improved their business any time lately, unless I missed something. Solaris is a cool product, but Solaris 10 is an incremental upgrade, and what *else* is Sun producing? Incremental hardware upgrades to match, sure... but what else? And their marketing just isn't up to the standards of Apple and Microsoft. HP has carved out nice niches for itself in PC hardware and especially printers, so if they lose a lot of big corporate support contracts to Microsoft or someone else, it'll hurt, but it won't kill them. I'm less sure about Sun.
Sure, they could turn it around. They could potentially turn Java into something, for example, but so far I don't see where they're making any money on it. They're halfway on the Linux support bandwagon, but they're going to have to compete there with the same players Solaris has been competing with -- HP, IBM, and so forth. It doesn't differentiate them at all, really. They need to carve out a niche for themselves in another market, where they can differentiate themselves better.
> What would it take to get emacs bindings into the release?
It would probably be easier to just write an openoffice-document-mode, so that you could edit OpenOffice documents in Emacs.
This is only _slightly_ tongue-in-cheek. Whenever people ask for Emacs bindings in another app, I know they don't realize what they're asking for. Emacs has the most expansive and flexible binding system in all of software; wanting OpenOffice to have Emacs' binding system is like wanting it to have TeX's text rendering capabilities or Gimp's graphics capabilities. It really isn't far off from being harder than writing an Emacs mode for OO documents.
Grammar checking is AI complete, and all the grammar-checking programs I've ever seen are worse than useless -- literally: the people who use them end up with *worse* grammar than the people who don't, because they're wrong *more* than half the time.
You name any grammar checker you want, and I'll write ten sentences with one obvious grammatical error each: if the grammar checker finds at least five of the errors without finding more than five bogus "errors" that are in fact correct, I'll eat my hat.
> My G3 clocked at 300MHz kicks the CRAP out of my 800MHz C3-ezra.
*shrug*.
My old Pentium II / 233 system kicked the everliving bejeebers out of the G3 iMac / 400 at work. But I think that had a lot more to do with the amount of RAM than with the CPU, since the PII/233 had 256 MB of RAM, and the iMac had just 32 MB. The performance difference was so tangible, you didn't have to touch _it_, because _it_ reached out and grabbed _YOU_. (And I wasn't even _in_ Soviet Russia.)
That's generally the case: CPU speed is way less important to performance than the amount of RAM. I always go cheap on the CPU and get extra RAM; you get better performance that way. Switching back and forth between apps, for example, is instant if you have enough RAM; if you don't, it can take several seconds.
So the Mac Mini's being a G4 doesn't bother me a bit; if I were getting one, I'd just throw some extra RAM at it. And I'd be pretty tempted to do that (despite being up to now a PC user), if I needed a new computer right now, but what I've currently got should be good for another couple of years at least, so I'm exercising a little self control and not buying one.
It's easier to just tunnel through one of the firewalls. From system A, ssh into the firewall on system B's end, then from there do whatever you need to do over the LAN to system B. Alternatively, if you're sitting at system A, shell into your own firewall and temporarily forward a port back to yourself, which system B can use to connect to you. This can be reasonably secure if you 1: use a nonstandard port to ward off automated attacks, script kiddies, and worms, 2: use ssl or somesuch so the traffic is hard to sniff, 3: require system B to use a password to get into system A, and 4: turn off the port forwarding when you're not using it, to keep the window of opportunity narrow for any potential attacker. If you're really paranoid, use one-time passwords.
> Your |insert computer illiterate relation| needs help fixing something > that VNC'ing into their box would easily fix. However, because you > recommended that they put their windows box behind a firewall, which > oddly enough they did, leaves you without the ability to easily connect > to their machine without yet another couple steps, mainly setting up > their firewall to allow you to connect to their machine.
Oooh, let me answer this one. This one's easy:
Since the firewall is an old Pentium 90 running *nix, which I installed and administer (when it needs any administering, which is not so terribly often), I just ssh into the firewall, and from there do whatever I need to do across the LAN.
Perhaps, but no version of vi is as small as UED, which I used to keep on a bootable 360K floppy, along with various other important utilities including fdisk and format. 38704 bytes of goodness. I must have experimented with eighty or ninety different text editors over the course of six years or so and never found another one as conveniently useable as UED. But then in 1998 I started messing around with Linux, and I needed an editor that would work there. At first I tried to set up a combination of dosemu/UED, but it just wasn't convenient enough (having to copy files to where dosemu could see them, then back afterward), so I rebooted into Windows 95, downloaded NTEmacs, made myself learn it. Once I got comfortable with Emacs, I never looked back, and having given up UED, it was inevitable that I would proceed to give up all the platform-dependent applications that I had been relying on and free myself. I finally did that circa 2001; Pegasus Mail was the last holdout, and after trying a dozen platform-independent mailreaders the only one that had the essential features I had come to rely on in Pegasus Mail was Gnus, so I learned that, and my OS was commoditized. I initially switched to Linux, but a couple of years later when I was having hardware problems with my Linux box I used Windows Me for a couple of months; now I'm back on Linux, but I've been thinking about experimenting with BSD. I can use or just try out pretty much any OS I fancy -- I'm *free*. I'll never let myself get locked into a particular platform again.
Okay, I went a little off-topic there, but my basic point was that the text editor is the most important piece of software on the system (for a poweruser/borderline-developer such as myself; obviously it's different for end users), and UED was a really great one in its day, but I had to give it up to leave DOS.
The thing is, ed is hugely oversized for what you get. Check *this* out:
Here we see that ed is almost as large as Notepad, but Notepad is a full screen editor. (A lousy one, but nevermind. EDIT.COM is only a little better.) The one weighing in at 38K is the Useful Editor, an old freeware text editor for DOS. Not only is it a full-screen editor, it's a tremendously cuspy one at that, much better than EDIT.COM, and the only editor to-date that I've discovered that has a feature I wish Emacs had (namely, the way it handles copying and pasting, especially with regard to rectangular blocks; it also handles traditional ranges, of course). But ed isn't a full-screen editor; it's a line-editor, like EDLIN, which weighs in much lighter.
Also, in checking the size of Emacs, you've looked only at the portion of Emacs that's written in C. Most of Emacs is written at lisp. Fortunately it's rather modular and uses a nifty autoloading feature that keeps its memory footprint down to mostly just the features you use; otherwise it would have memory footprint more comparable to OpenOffice. (You think I'm joking; I'm not. If you want Emacs to look chunky, compare source tarball sizes instead of executable sizes or memory footprint; Emacs looks much more enormous that way. The memory footprint, for what you get, is actually pretty lean and mean, due to the autoloading.)
As far as key bindings, I don't use the standard Emacs ones; I have them rebound to my specifications (not just in terms of which keys do a given thing, but in terms of what exactly happens when a given key is pressed). I thought that was rather the point of using extensible and customizeable software. Arguments about the relative value of the defaults in different applications tend to get lost on me, because as far as I'm concerned, the defaults are for people who don't know what they want or care what they get.
The problem with Dvorak is that it makes the same mistakes as QWERTY.
Fundamentally, how you arrange the letters -- assuming you use some logical arrangement that makes a bit of sense -- is not the only thing that matters. QWERTY (in order to keep typewriters from jamming) arranges them so that it's statistically less likely for adjascent letters to occur on the same finger and more likely for them to occur on opposite hands. This does speed up typing somewhat over, say, an alphabetical layout (once you are comfortably familiar with the layout you are using, of course). Dvorak instead goes out of its way to put the letters that are most frequently used in English on the keys that are easiest to hit. This too speeds up typing somewhat over an alphabetical layout.
But they both have serious flaws, and it's not in how they lay out the letters. It's in how they handle the other keys, which they do virtually the same way. The numbers across the top are okay, and the spacebar is okay -- well, the spacebar would be okay if it didn't waste one whole thumb. The thumb is unique among the hand's fingers in that it can easily operate independently from the other fingers. This makes it ideal for the spacebar, because space is statistically more likely than any other character to be typed right before or right after any other character. However, the thumb is *also* ideal for a bucky key, the most important being shift, for a similar reason: you can hold a key down with the thumb, and all your other fingers can still hit any key they could hit before. Try that with the shift key where it is now: it doesn't work, which is the main reason we have two shift keys, which is wasteful and makes the layout larger than it needs to be. A second thumb bar for shift would be much more efficient, in terms of typing speed, and as an added bonus it reduces by one the number of keys needed. *Plus*, it substantially reduces the frequency with which you hyperextend your pinky. If your pinkies hurt after a long bout of typing, this is the answer.
There are other mistakes both layouts make. Ctrl is similarly poorly positioned and should definitely be put where it's easier to hit. On the other hand, the window key is in a bad place. It's effect is much more drastic than ctrl, in that it takes keyboard focus completely away from the application or window that had it and thoroughly disrupts whatever was being done, so it should be out of the way more. Where the traditional layouts have put it, it gets hit mostly by mistake and becomes an annoyance -- quite needlessly, because there are plenty of out of the way places where it could be put such that it would not be hit by mistake while the user is typing. Right next to Print Screen, for example, would be a great place for it.
I could go on and on, but basically it comes down to this: QWERTY and Dvorak both took great care when arranging the letters, and it shows: they're both pretty decent arrangements for that (for different reasons). But they appear to have put no thought whatsoever into the arrangment of the other keys (except the spacebar), and that shows too: the arrangement of the other keys *sucks* on these layouts. That is where the next round of improvements needs to be made.
I'd start by putting shift and ctrl below the spacebar, where they can be hit or held with the left and right thumb, respectively, with no impact on where the other fingers can be. (This makes *one* combination hard -- Shift-Ctrl-Space -- but that's a rather unusual combination, and it makes every other shift and ctrl combination much faster and easier. Care would have to be taken so that normal hitting of the spacebar with either thumb would not hit these keys by mistake, but that's easily possible if a gap the size of a single key is left between them and the spacebar.) Then I'd proceed by putting as much thought into the placement of every other key as was put into the placement of the letters.
> "British accent"? Which particular accent is that? Irish? Scottish? > Welsh? Scouse? Geordie? Cockney? Werzel? Mancunian? See how meaningless > the phrase "British accent" is?
No, there's a particular accent we mean when we say "British accent" over here. I don't know what it's called over there, or which part of Britain it's from. It's definitely not Cockney, and it's also not Welsh, Irish, or Scottish, nor is it the mumbly speech of BBC commentators. There's a certain accent that is meant. Those others we call by their specific names, but the one in question we just call a British accent or sometimes we also call it an English accent. (The words "English" and "British" are used _mostly_ interchangeably over here, although I've never heard the English Channel called the British Channel. It's not that we don't know the difference (okay, some people don't, but that's another matter); we just don't feel the need to make the distinction most of the time.)
Similarly, the phrase "Southern accent" doesn't mean "any accent from south of here". A Jamaican accent is a Jamacian accent, and a Texan accent is a Texan accent, and New Orleans has its own peculiarities, but a Southern accent is the one spoken in Georgia and the Carolinas (among other states).
Probably many of the teams not using version control should be, but there are certainly circumstances wherein it isn't necessary. Sometimes the division of labor on a project is such that each developer really only has to make changes his own parts of the project -- his own files, or, in some cases, his own library or application. This is not the norm even for proprietary software and is probably _very_ unusual in the open-source world, but it does happen occasionally.
And, of course, there are always the projects with pretty much just one programmer (though there may also be other people doing e.g. content, art, music, PR, marketing, or what-have-you).
I currently don't use any version control for Net::Server::POP3, because no other developers have expressed an interest in working with me on it. (Which is fine; it's a small module and probably only needs one developer. It does build on the work of others, e.g. by using Net::Server, but I have not contributed anything back to Net::Server itself, because I haven't needed to make any changes to it; I just use it.)
> it's a natural repellant made from chemicals already produced by the body. > This leads to a high likelihood that it's not dangerous.
Non sequiteur. Ammonia is a natural chemical already produced by the body (occurring prominently, for example, in urine), but when a tanker truck carrying ammonia spills on the highway, it's an environmental disaster. Bile is a natural chemical already produced by the body and is a natural emulsifier. Endorphins and human growth hormone and steroids (such as testosterone) are natural chemicals already produced by the body. These are all quite dangerous chemicals, if used improperly or in the wrong amounts.
It's all about how much you use and how you use it. The right amount of chlorine used correctly makes water safe to drink; the wrong amount used improperly will kill you even faster than the bacteria it's saving you from. This is just as true for "natural" chemicals as any other kind.
> if they are so much focused on speed, couldn't this be the mysql killer > for web applications that don't need funky features but where concurrency > and speed are important
As near as I can make out from the (somewhat nontechnical) article, this is not a traditional database in any normal sense; it's more like a query engine for streaming data. It doesn't permanently store all the data in the stream that's passing through it. What it does store, I take it, is query results. So I guess basically you set up your queries ahead of time, and the results accumulate as the data flows through.
This could be useful for some things, but it's not going to kill off any of the current database engines because, fundamentally, it doesn't do the same thing. Indeed, the article claims that big companies have tried to (ab)use Oracle to do what this does, and it didn't work out. Translation, the jobs this thing will be taking over are not currently jobs that Oracle is performing -- nor, presumably, MySQL either. It isn't made to do what they do and compete with them; it's made to do something different, but (the company behind it hopes) also useful.
Over the hill is 40 (because, average age of death is about 80, so you're halfway there at 40). Middle age begins at 30. (50, in case you were wondering, is older than dirt; 60 is senior citizen; 70 is decrepit; at 80 you're a living fossil.) 25 is nothing in particular, but my college roommate pointed out to me when I turned 20 that 20 is halfway to 40, and 40 is halfway to death. Sure made *me* feel good about turning 20. I suppose that means 25 is a quarter of the way to 100, or a third of the way to 75, if you want to look at it that way.
A word of encouragement: Don't feel too bad about turning 25. I'm 30 now, and it seems like I was 25 just a few weeks ago;-)
Slashdot Mirror
That's just a rounding error. Everyone knows BUS speeds end in 00, 33, or 66
(i.e., they go in increments of thirds of 100), so they rounded to the nearest
possible increment.
> Maybe we all need to learn to speak the Indian languages. What do they speak?
u ages_of _India
That's a tall order. There are almost as many Hindustani languages as there
are African languages. You can see a list of the *major* ones here:
http://en.wikipedia.org/wiki/Category:Lang
Of course, each village has its own dialect, and a lot of the people are
polyglots. In general, I'd guess that the three languages a random person
from India is most likely to know are probably Hindi, Tamil, and English --
but this is like saying that the three languages a European is most likely
to know are English, German, and Russian. (Note the presense of English
on both lists; it's on the equivalent list for every continent or major
geopolitical region.)
> As an Emacser, you should definitely get into Common Lisp. I don't know
> Inform, so I can't compare the object-oriented parts of the two languages,
> but I have yet to come up with an object-oriented feature that I really
> wanted and Common Lisp didn't provide. (Incidentally, that includes
> multiple inheritance, which is only present in one of the more popular
> programming languages.)
Inform has multiple inheritance of *course*, a full inheritance tree. Any
language that doesn't is not, as far as I'm concerned, really object-oriented.
Inform also, orthogonal to the inheritance tree, has an object forest, which
is a *really* useful data structure for organizing objects. And it has
instance properties, which a lot of the wimpier pseudo-object-oriented
languages don't have.
Say you have an object, foo, which inherits from two classes, Bar and Baz.
Baz in turn inherents from Quux, which inherents from Lambda and Chortle.
foo also belongs to the metaclass Object (whereas, Bar, Baz, Quux, Lambda,
and Chortle belong to metaclass Class). Now, Lambda provides a property
called aleph, with a string for the default value, and a property called
beth, with a number for the default value. Chortle provides gimmel, with
a routine for the default. Quux overrides Lambda's value for aleph with
a routine that determines the correct string dynamically, based on the
current situation. Bar overrides Chortle's (routine) value for gimmel
with a more interesting/precise routine better suited for Bar objects.
All of that is just garden-variety multiple inheritance, but here's where
it gets interesting: foo can also override the value for any of these
properties in any way it chooses, and additionally can also provide the
properties daleth and waw. (Recall that foo is an individual object -- an
instance, in C++ parlance, not a class.)
Then there's the object forest: you can move foo into/onto another object,
wibble, so that foo is a child of wibble, and move some other objects to
wibble also, so that foo has siblings. Then you can move objects to foo
so that it has children. Think of it as a general tree that is built into
the language core. Additionally, there's an objectloop control-flow thing
for looping over the objects that are in a certain object, belong to a
certain class, provide a certain property, or meet other specified criteria.
Inform does not have multimethods, however.
Infix syntax is one of the things I don't miss in elisp, so I don't see why
I should miss it in Common Lisp either. What I do miss in elisp is a sane
quoting syntax for regular expressions; all those double-backslashed regex
metacharacters make the regular expression library, powerful as it is, a
serious pain in the neck to actually use. When I need regexen, I usually
write the code in Perl instead -- in some cases I would anyway, because
Perl is just generally better for some things (and the CPAN is several orders
of magnitude easier to use for finding and installing modules than the Emacs
equivalent). However, Perl isn't so hot in some cases, such as when large
amounts of user intervention are required -- elisp is particularly good for
situations where you want to integrate what's being done into an editing
environment; Perl just can't hack that; its UI isn't made for that.
(Yeah, there are the special versions of Emacs with Perl embedded. I've never
gotten around to trying them out. Maybe I should. But maybe elisp should
be extended with a better regex-quoting construct, too.)
The INTERCAL tree looks something like this...
INTERCAL (1972) --> C-INTERCAL (1990) --> THREADED INTERCAL
INTERCAL also has had some influence on other languages, such as unlambda,
so an argument could be made for including it in the chart. (Mind you, I
would not want to have to defend such an argument against all possible
rational counterarguments.)
> could wax on in Oldtimer Mode some more, and talk about carrying my coding
> forms uphill in the snow (both directions) but I'll spare you youngsters.
> Shoot, this was the late 70's; some of you think the Oldies songs on the
> radio are newer than that....
Oh, don't get me started on that noise they try to pass off as music these
days. Bah, twentieth-century "music" is all a bunch of new-fangled garbage.
Most of it doesn't even have counterpoint -- I'm not sure where they get off
calling it music if it doesn't have counterpoint. Preposterous. Music
without counterpoint, bah, what's next, candy without sugar? Beer without
alcohol? Back in my day we wouldn't have stood for such things. We listened
to fugue -- real music with real character -- and the candy we ate rotted
our teeth, and people who drank beer got drunk -- and they liked it that way.
Come back here, you little rapscallion, I'm not through with you yet,
whippersnapper...
> Common Lisp is also object-oriented and beats every other language I
> know in that arena.
Common Lisp is one of those languages I keep telling myself I Really Ought To
Learn. But I haven't gotten around to it yet.
The best OO I've ever seen in any language is Inform. Knocks the socks off
of everything. Perl is _finally_ getting decent OO in version 6, but it
*still* won't have some of the niftier OO features of Inform, such as the
object forest and the objectloop control flow structure, both of which are
incredibly useful, sometimes in unexpected ways. (They were designed for
solving a particular class of problems that are important for Inform's
special purpose, but they're useful generally.)
> Emacs has been around for approximately 30+ years. Why would I want to
> learn an arbitrary set of keybindings that have no historical basis or
> applicability elsewhere?
Exactly. Emacs has supported the cursor keys since they were added to the
keyboard (what, in the seventies?), so why would you want to learn ^a for
^e for end and so forth, when those keys won't work in other applications,
but the regular ones *will* work in Emacs, and have for decades?
And for standard key bindings that Emacs *doesn't* support out of the box,
when every other application in the universe does (such as ^a for select all),
well, that's what Emacs gives us the ability to rebind keys for, isn't it?
What annoys me is that other applications don't have some of the functionality
that I'm accustomed to in Emacs. For example, it bugs me no end that I can't
do C-h k in OpenOffice or Mozilla. If they had that functionality on another
keystroke, I'd rebind Emacs to match so I don't have to switch keybindings
whenever I switch windows -- but the other apps don't have that capability
at all, so I still have to remember whether I'm in Emacs or not. (Describe
key is just one of numerous Emacs features I miss in other apps. Apropos
is another. Paren matching is another.)
> ^a, ^e, ^f, ^n, ^p, ^b, ^d
Huh. I would not have guessed any of those keys in a million years. ^e
doesn't do anything particularly unique. (I think it duplicates what the
end key does. I have no idea why anyone would need a second key combination
for that.) ^a I don't know what it used to do, because I rebound it to select
the whole buffer several years ago and haven't looked back. ^f flips between
two cursor positions on my setup, but I think that's a customization too; I
don't really know what it does OOTB. ^b and ^n are cycle-buffer-permissive
and cycle-buffer-backward-permissive, or, as I like to think of them, Back
a buffer and Next buffer. Those might be ones I customized too, or not, I
don't recall; maybe one of the minor modes I use rebinds them. ^p is another
key that just duplicates one of the cursor keys, so who needs that? And ^d
is another dupe, this time for delete. Yeah, we've already got backspace
for deleting backward and two distinct delete keys for deleting forwards,
I *sure* needed one more key combination for *that*.
If there are a handful of key bindings people would want in other apps, I
would have guessed ones like maybe C-x C-f and C-x C-s and so forth, but I
never would have come up with the ones you listed. I had to use C-h k to
identify what some of them even do.
> But I do like your approach of just including open office in the GNU
> emacs distro.
Works for me. While we're at it, can we get MySQL and Apache on the CPAN
so that we can install them with CPAN.pm like every other Perl module,
so that all the hillion jillion modules that depend on them don't need
"external dependencies"? Thanks. Also, ActivePerl should come with gcc
and make and so on so that CPAN.pm will work correctly on Win32, like it
does on every other OS. Whatever makes our lives easier by requiring less
fussing around to get things working. I've still got over 15% of the space
on my filesystem free -- free as in doing nothing useful at the moment, and
it's only a 25G filesystem, which is small by today's standards, and I've
spared nothing in terms of installing everything useful. (Two different
versions of Gnus, just because I didn't bother to rm the old one? Check.
Half a dozen versions of Mozilla? Check. Multiple versions of OO.o? Yes,
and cetera. I could probably free up another five GB without giving up
anything current.)
Apple doesn't have the _infrastructure_ to compete with Microsoft. If they
were to suddenly get even 5% of Microsoft's market share in a year, it would
be more than a company Apple's size could handle -- it would *double* the
size of their business, and while that may sound attractive on the face of
it, it's the kind of thing that could destroy a company as easily as raise
it up.
Don't get me wrong: I'm not saying Apple doesn't want to grow. They do.
But they want to grow in a way that works for them as a company. The Mac
Mini could conceivably boost their market share considerably -- by as much
as 50% in three years, I guesstimate, which is huge (if it materializes,
which is hard to predict), and by then they'll have figured out where they
want to go next. The iPod isn't exactly hurting them either.
It's also noteworthy that Apple's growth pattern is healthier than
Microsoft's, in that it's more diverse. Microsoft is almost entirely in
software, and a little hardware. Apple's got a nice ballance of hardware
and software and has been moving into music. I've been wondering for
years why Microsoft doesn't diversify more -- at their size, they should
be in half a dozen industries. They should own a big movie studio and
a major restaurant chain, or something. When you're that big, you're
supposed to wonder, "What happens if a competitor comes along and forces
us to cut prices to compete until the profits in our entire industry are
razor thin?" Microsoft *knows* this can happen, and they're scared to
death of Linux in particular, but what are they doing about it? Nothing.
(Well, sure, they're doing plenty to try to *prevent* that from happening,
but they're doing nothing to ensure their survival and profitablity as a
company in the event it *does* happen.)
Long term, I like Apple's prospects better than Microsoft's, because
they're manifestly smarter about the way they conduct business.
But of the three, I'd worry most about Sun. They do have the ballance
of hardware and software (and support contracts), but they've always had
that, and they don't seem to have fundamentally improved their business
any time lately, unless I missed something. Solaris is a cool product,
but Solaris 10 is an incremental upgrade, and what *else* is Sun producing?
Incremental hardware upgrades to match, sure... but what else? And their
marketing just isn't up to the standards of Apple and Microsoft. HP has
carved out nice niches for itself in PC hardware and especially printers,
so if they lose a lot of big corporate support contracts to Microsoft or
someone else, it'll hurt, but it won't kill them. I'm less sure about Sun.
Sure, they could turn it around. They could potentially turn Java into
something, for example, but so far I don't see where they're making any
money on it. They're halfway on the Linux support bandwagon, but they're
going to have to compete there with the same players Solaris has been
competing with -- HP, IBM, and so forth. It doesn't differentiate them
at all, really. They need to carve out a niche for themselves in another
market, where they can differentiate themselves better.
> FWIW, it sounds awfully similar to Frozen Bubble --- was FB based on Snood?
Frozen Bubble is based on Magic Bubble, an arcade game from the early nineties.
I've never heard of Snood before.
> What would it take to get emacs bindings into the release?
It would probably be easier to just write an openoffice-document-mode, so
that you could edit OpenOffice documents in Emacs.
This is only _slightly_ tongue-in-cheek. Whenever people ask for Emacs
bindings in another app, I know they don't realize what they're asking for.
Emacs has the most expansive and flexible binding system in all of software;
wanting OpenOffice to have Emacs' binding system is like wanting it to have
TeX's text rendering capabilities or Gimp's graphics capabilities. It
really isn't far off from being harder than writing an Emacs mode for OO
documents.
Grammar checking is AI complete, and all the grammar-checking programs I've
ever seen are worse than useless -- literally: the people who use them end
up with *worse* grammar than the people who don't, because they're wrong
*more* than half the time.
You name any grammar checker you want, and I'll write ten sentences with
one obvious grammatical error each: if the grammar checker finds at least
five of the errors without finding more than five bogus "errors" that are
in fact correct, I'll eat my hat.
> My G3 clocked at 300MHz kicks the CRAP out of my 800MHz C3-ezra.
*shrug*.
My old Pentium II / 233 system kicked the everliving bejeebers out of the
G3 iMac / 400 at work. But I think that had a lot more to do with the
amount of RAM than with the CPU, since the PII/233 had 256 MB of RAM, and
the iMac had just 32 MB. The performance difference was so tangible, you
didn't have to touch _it_, because _it_ reached out and grabbed _YOU_.
(And I wasn't even _in_ Soviet Russia.)
That's generally the case: CPU speed is way less important to performance
than the amount of RAM. I always go cheap on the CPU and get extra RAM; you
get better performance that way. Switching back and forth between apps,
for example, is instant if you have enough RAM; if you don't, it can take
several seconds.
So the Mac Mini's being a G4 doesn't bother me a bit; if I were getting one,
I'd just throw some extra RAM at it. And I'd be pretty tempted to do that
(despite being up to now a PC user), if I needed a new computer right now,
but what I've currently got should be good for another couple of years at
least, so I'm exercising a little self control and not buying one.
It's easier to just tunnel through one of the firewalls. From system A, ssh
into the firewall on system B's end, then from there do whatever you need to
do over the LAN to system B. Alternatively, if you're sitting at system A,
shell into your own firewall and temporarily forward a port back to yourself,
which system B can use to connect to you. This can be reasonably secure if
you 1: use a nonstandard port to ward off automated attacks, script kiddies,
and worms, 2: use ssl or somesuch so the traffic is hard to sniff, 3: require
system B to use a password to get into system A, and 4: turn off the port
forwarding when you're not using it, to keep the window of opportunity narrow
for any potential attacker. If you're really paranoid, use one-time passwords.
> Your |insert computer illiterate relation| needs help fixing something
> that VNC'ing into their box would easily fix. However, because you
> recommended that they put their windows box behind a firewall, which
> oddly enough they did, leaves you without the ability to easily connect
> to their machine without yet another couple steps, mainly setting up
> their firewall to allow you to connect to their machine.
Oooh, let me answer this one. This one's easy:
Since the firewall is an old Pentium 90 running *nix, which I installed and
administer (when it needs any administering, which is not so terribly often),
I just ssh into the firewall, and from there do whatever I need to do across
the LAN.
Perhaps, but no version of vi is as small as UED, which I used to keep on a
bootable 360K floppy, along with various other important utilities including
fdisk and format. 38704 bytes of goodness. I must have experimented with
eighty or ninety different text editors over the course of six years or so
and never found another one as conveniently useable as UED. But then in
1998 I started messing around with Linux, and I needed an editor that would
work there. At first I tried to set up a combination of dosemu/UED, but it
just wasn't convenient enough (having to copy files to where dosemu could
see them, then back afterward), so I rebooted into Windows 95, downloaded
NTEmacs, made myself learn it. Once I got comfortable with Emacs, I never
looked back, and having given up UED, it was inevitable that I would proceed
to give up all the platform-dependent applications that I had been relying
on and free myself. I finally did that circa 2001; Pegasus Mail was the
last holdout, and after trying a dozen platform-independent mailreaders the
only one that had the essential features I had come to rely on in Pegasus
Mail was Gnus, so I learned that, and my OS was commoditized. I initially
switched to Linux, but a couple of years later when I was having hardware
problems with my Linux box I used Windows Me for a couple of months; now
I'm back on Linux, but I've been thinking about experimenting with BSD.
I can use or just try out pretty much any OS I fancy -- I'm *free*. I'll
never let myself get locked into a particular platform again.
Okay, I went a little off-topic there, but my basic point was that the
text editor is the most important piece of software on the system (for
a poweruser/borderline-developer such as myself; obviously it's different
for end users), and UED was a really great one in its day, but I had to
give it up to leave DOS.
Oops, forgot the size listing: /bin/ed* /bin/sed* /bin/vi* /usr/bin/emacs* /winme/95_copy/WINDOWS/COMMAND/EDIT.COM*r -- 1 root root 7.4K Apr 1 1988 /winme/dos_partn_copy/S/3/EDLIN.COM* /winme/dos_partn_copy/S/UTIL/UED.EXE* /winme/WINDOWS/NOTEPAD.EXE*
-rwxr-xr-x 1 root root 42K Jul 22 2003
-rwxr-xr-x 1 root root 87K Apr 11 2003
-rwxr-xr-x 1 root root 1.2M Sep 4 2003
-rwxr-xr-x 1 root root 4.3M Aug 27 2003
-rwxr--r-- 1 root root 69K Aug 24 1996
-rwxr--
-rwxr--r-- 1 root root 38K Feb 10 1998
-rwxr--r-- 1 root root 52K Jun 8 2000
The thing is, ed is hugely oversized for what you get. Check *this* out:
Here we see that ed is almost as large as Notepad, but Notepad is a full screen
editor. (A lousy one, but nevermind. EDIT.COM is only a little better.) The
one weighing in at 38K is the Useful Editor, an old freeware text editor for
DOS. Not only is it a full-screen editor, it's a tremendously cuspy one at
that, much better than EDIT.COM, and the only editor to-date that I've
discovered that has a feature I wish Emacs had (namely, the way it handles
copying and pasting, especially with regard to rectangular blocks; it also
handles traditional ranges, of course). But ed isn't a full-screen editor;
it's a line-editor, like EDLIN, which weighs in much lighter.
Also, in checking the size of Emacs, you've looked only at the portion of
Emacs that's written in C. Most of Emacs is written at lisp. Fortunately
it's rather modular and uses a nifty autoloading feature that keeps its
memory footprint down to mostly just the features you use; otherwise it
would have memory footprint more comparable to OpenOffice. (You think I'm
joking; I'm not. If you want Emacs to look chunky, compare source tarball
sizes instead of executable sizes or memory footprint; Emacs looks much
more enormous that way. The memory footprint, for what you get, is actually
pretty lean and mean, due to the autoloading.)
As far as key bindings, I don't use the standard Emacs ones; I have them
rebound to my specifications (not just in terms of which keys do a given
thing, but in terms of what exactly happens when a given key is pressed).
I thought that was rather the point of using extensible and customizeable
software. Arguments about the relative value of the defaults in different
applications tend to get lost on me, because as far as I'm concerned, the
defaults are for people who don't know what they want or care what they get.
The problem with Dvorak is that it makes the same mistakes as QWERTY.
Fundamentally, how you arrange the letters -- assuming you use some logical
arrangement that makes a bit of sense -- is not the only thing that matters.
QWERTY (in order to keep typewriters from jamming) arranges them so that it's
statistically less likely for adjascent letters to occur on the same finger
and more likely for them to occur on opposite hands. This does speed up
typing somewhat over, say, an alphabetical layout (once you are comfortably
familiar with the layout you are using, of course). Dvorak instead goes out
of its way to put the letters that are most frequently used in English on
the keys that are easiest to hit. This too speeds up typing somewhat over
an alphabetical layout.
But they both have serious flaws, and it's not in how they lay out the letters.
It's in how they handle the other keys, which they do virtually the same way.
The numbers across the top are okay, and the spacebar is okay -- well, the
spacebar would be okay if it didn't waste one whole thumb. The thumb is
unique among the hand's fingers in that it can easily operate independently
from the other fingers. This makes it ideal for the spacebar, because space
is statistically more likely than any other character to be typed right
before or right after any other character. However, the thumb is *also*
ideal for a bucky key, the most important being shift, for a similar reason:
you can hold a key down with the thumb, and all your other fingers can still
hit any key they could hit before. Try that with the shift key where it is
now: it doesn't work, which is the main reason we have two shift keys,
which is wasteful and makes the layout larger than it needs to be. A second
thumb bar for shift would be much more efficient, in terms of typing speed,
and as an added bonus it reduces by one the number of keys needed. *Plus*,
it substantially reduces the frequency with which you hyperextend your pinky.
If your pinkies hurt after a long bout of typing, this is the answer.
There are other mistakes both layouts make. Ctrl is similarly poorly
positioned and should definitely be put where it's easier to hit. On the
other hand, the window key is in a bad place. It's effect is much more
drastic than ctrl, in that it takes keyboard focus completely away from the
application or window that had it and thoroughly disrupts whatever was being
done, so it should be out of the way more. Where the traditional layouts
have put it, it gets hit mostly by mistake and becomes an annoyance -- quite
needlessly, because there are plenty of out of the way places where it could
be put such that it would not be hit by mistake while the user is typing.
Right next to Print Screen, for example, would be a great place for it.
I could go on and on, but basically it comes down to this: QWERTY and Dvorak
both took great care when arranging the letters, and it shows: they're both
pretty decent arrangements for that (for different reasons). But they appear
to have put no thought whatsoever into the arrangment of the other keys
(except the spacebar), and that shows too: the arrangement of the other
keys *sucks* on these layouts. That is where the next round of improvements
needs to be made.
I'd start by putting shift and ctrl below the spacebar, where they can be
hit or held with the left and right thumb, respectively, with no impact on
where the other fingers can be. (This makes *one* combination hard --
Shift-Ctrl-Space -- but that's a rather unusual combination, and it makes
every other shift and ctrl combination much faster and easier. Care would
have to be taken so that normal hitting of the spacebar with either thumb
would not hit these keys by mistake, but that's easily possible if a gap
the size of a single key is left between them and the spacebar.) Then I'd
proceed by putting as much thought into the placement of every other key
as was put into the placement of the letters.
> "British accent"? Which particular accent is that? Irish? Scottish?
> Welsh? Scouse? Geordie? Cockney? Werzel? Mancunian? See how meaningless
> the phrase "British accent" is?
No, there's a particular accent we mean when we say "British accent" over
here. I don't know what it's called over there, or which part of Britain
it's from. It's definitely not Cockney, and it's also not Welsh, Irish,
or Scottish, nor is it the mumbly speech of BBC commentators. There's a
certain accent that is meant. Those others we call by their specific names,
but the one in question we just call a British accent or sometimes we also
call it an English accent. (The words "English" and "British" are used
_mostly_ interchangeably over here, although I've never heard the English
Channel called the British Channel. It's not that we don't know the
difference (okay, some people don't, but that's another matter); we just
don't feel the need to make the distinction most of the time.)
Similarly, the phrase "Southern accent" doesn't mean "any accent from south
of here". A Jamaican accent is a Jamacian accent, and a Texan accent is a
Texan accent, and New Orleans has its own peculiarities, but a Southern accent
is the one spoken in Georgia and the Carolinas (among other states).
Probably many of the teams not using version control should be, but there
are certainly circumstances wherein it isn't necessary. Sometimes the
division of labor on a project is such that each developer really only has
to make changes his own parts of the project -- his own files, or, in some
cases, his own library or application. This is not the norm even for
proprietary software and is probably _very_ unusual in the open-source world,
but it does happen occasionally.
And, of course, there are always the projects with pretty much just one
programmer (though there may also be other people doing e.g. content, art,
music, PR, marketing, or what-have-you).
I currently don't use any version control for Net::Server::POP3, because
no other developers have expressed an interest in working with me on it.
(Which is fine; it's a small module and probably only needs one developer.
It does build on the work of others, e.g. by using Net::Server, but I have
not contributed anything back to Net::Server itself, because I haven't
needed to make any changes to it; I just use it.)
> it's a natural repellant made from chemicals already produced by the body.
> This leads to a high likelihood that it's not dangerous.
Non sequiteur. Ammonia is a natural chemical already produced by the body
(occurring prominently, for example, in urine), but when a tanker truck
carrying ammonia spills on the highway, it's an environmental disaster.
Bile is a natural chemical already produced by the body and is a natural
emulsifier. Endorphins and human growth hormone and steroids (such as
testosterone) are natural chemicals already produced by the body. These are
all quite dangerous chemicals, if used improperly or in the wrong amounts.
It's all about how much you use and how you use it. The right amount of
chlorine used correctly makes water safe to drink; the wrong amount used
improperly will kill you even faster than the bacteria it's saving you from.
This is just as true for "natural" chemicals as any other kind.
> if they are so much focused on speed, couldn't this be the mysql killer
> for web applications that don't need funky features but where concurrency
> and speed are important
As near as I can make out from the (somewhat nontechnical) article, this
is not a traditional database in any normal sense; it's more like a query
engine for streaming data. It doesn't permanently store all the data in
the stream that's passing through it. What it does store, I take it, is
query results. So I guess basically you set up your queries ahead of time,
and the results accumulate as the data flows through.
This could be useful for some things, but it's not going to kill off any
of the current database engines because, fundamentally, it doesn't do the
same thing. Indeed, the article claims that big companies have tried to
(ab)use Oracle to do what this does, and it didn't work out. Translation,
the jobs this thing will be taking over are not currently jobs that Oracle
is performing -- nor, presumably, MySQL either. It isn't made to do what
they do and compete with them; it's made to do something different, but
(the company behind it hopes) also useful.
> I'll be 25.. Practically over the hill.
;-)
Over the hill is 40 (because, average age of death is about 80, so you're
halfway there at 40). Middle age begins at 30. (50, in case you were
wondering, is older than dirt; 60 is senior citizen; 70 is decrepit; at
80 you're a living fossil.) 25 is nothing in particular, but my college
roommate pointed out to me when I turned 20 that 20 is halfway to 40, and
40 is halfway to death. Sure made *me* feel good about turning 20. I
suppose that means 25 is a quarter of the way to 100, or a third of the
way to 75, if you want to look at it that way.
A word of encouragement: Don't feel too bad about turning 25. I'm 30 now,
and it seems like I was 25 just a few weeks ago