If you want minimalistic, ratpoison is there. None of this nonsense about window borders; all windows are fullscreen (which is the default), halfscreen, or quarterscreen.
Not my thing, but hey, it's minimalist.
Personally I rather like sawfish. E would be okay if its iconbox were more featureful or if it supported the Gnome panel's tasklist. icewm is pretty decent too. But I settled on sawfish.
The one window manager I really loathe is metacity.
Not exactly. They understand the value of open-source software and prefer it, and I have heard that they release all of the stuff they develop (such as the excellent harddrake and printerdrake) under open-source licenses, but they do include some things Debian does not, so their policies are apparently not 100% the same. Also, some of the non-download editions of Mandrake include some proprietary commericial software bundled; Debian as a matter of policy does not have any special non-download editions with value-added software bundles. (If this bothers you about Mandrake, you can just get the download edition, which has no such bundles -- though the third CD does have some freely-distributable software that doesn't qualify under everyone's definition of free, but I was under the impression that Debian has a non-free section as well, so that may be neither here nor there.)
Then you have to define it in terms of temperature and pressure, which is a big pain.
What I don't understand is why they don't just define it as the mass of some specific number of standard water molecules. (Or molecules of some other substance, or some number of protons, or whatever.)
Voltage is equal to current times resistance. Current has its own base unit (the amp), but resistance is defined in terms of force and so indirectly depends on the definition of the mass unit.
The kilogram is very important, because the equivalent unit in the other measurement system is obscure. Even if we're not entirely sure _exactly_ how much a kilogram is, we still have to use it, because *nobody* has any idea how much mass a "slug" is. Most people have never even _heard_ of it.
I've been pronouncing it as skwul, where the u is de-emphasised as with a schwa. I also thought about pronouncing it "squall", but I find "skwul" just rolls off the tongue more easily for me, and it's more obvious that that would of course be spelled "sql"; if you say "squall", you expect an a in it someplace.
I certainly can't imagine pronouncing it "sequel"; that adds in _two_ extra vowells that clearly aren't there, which is totally unnecessary. I once heard someone talking about "sequel server" in a speech, and it took me fifteen minutes to figure out he was talking about MS SQL Server, even though I knew very well from context that it had something to do with databases. That's the only time I've ever heard "SQL" pronounced as "sequel".
I call it "Jonadabian". It's a custom layout of my own design. I have an Avant keyboard, so I can put any key in any position I want.
My layout is based on QWERTY, but there are some quite important differences. Most notably, I have shift and control under the home positions of my left and right pinkies (respectively) so that I don't have to hyperextend my pinkies every two seconds. My pinkies used to hurt after a few hours of using the computer, and now they don't.
Overall, I don't think my layout leads to more words per minute than QWERTY (at least, not significantly more), but I like that my pinkies don't hurt, so I'm keeping it:-)
Here are my changes from QWERTY: Where a normally goes is left shift. Where ; normally goes is right ctrl. Where left shift and capslock normally go are both k. There is no capslock. I never use it. Where left win/meta normally goes is [{, and to the right of the spacebar is ]} To the right of p is; Where right shift normally goes is an extra |\ key. Where numlock normally goes is nothing; there is no numlock. Numlock is permanently off. The bottom 4 function keys on the left side (F7-F10) are shift. (This is mostly to prevent hitting them by mistake.) The top two are the left window/meta key (which I do need, but I wanted it out of the way where I won't hit it by mistake) and the menu key. (The function keys along the top row are normal.)
There might be a couple of other changes, but that's most of them at this point. I may make additional improvements from time to time as I think of ways to improve things.
No, she didn't. Play the scene back again. She asked him his opinion, told him she was sorry, that he had what it takes, but that it was like he was _waiting_ for something. He asked what he was waiting for, and she said she didn't know. (Then she speculated: "Your next life maybe? Who knows?" -- but she made it totally clear she didn't know.)
As it turned out, he was waiting for the right motivation, for Morpheus' life to be on the line.
> Personally, I am really used to punch in my password(s) and I > would not be surprised if other could imitate me simply by trying > to input it very efficiently.
Me too, _except_ that I use a modified keyboard layout, which makes certain things take different amounts of time than usual. (For example, switching between upper and lower case is faster, because shift is under a home position on my layout. OTOH, k is rather out of the way and generates an extra pause before or after.)
I still prefer the long-nasty-password approach. Use a password like cEveNaughtDiVulge-canceroussGRANDpapy;rot14impreSS ionismmxi (not my real password, of course), type it fast, and nothing but a sniffer is going to compromise it. Yet something like that is only barely more difficult to memorise than something traditional like Rx7QvGOc0b. (You remember, "seven naught divulge cancerous grandpappy rot14 impressionism xi", eight words (except rot14, which is easy to remember because it's one more than Caesar), but then you make minor tweaks such as elided and doubled letters and case shifts, which your muscle memory will do for you automatically after a dozen times typing it.)
> Actually, he does. I filed a bug report about Emacs and he > fixed it himself.
He does? Well, then strange ideology notwithstanding he's still the man. Emacs r0x0rz. (Okay, so I wish it were multithreaded... but that's me being picky.)
> It CAN use lists, you just have to write the code for that.
It can use lists, but it does not do list-oriented programming in the same way that lisp and Perl can. (Realise that in lisp, a list is also a function, and vice versa, and I've seen this done in Perl also, or something very like it.)
> It can do anything, you just have to write the underlying > class, etc
This is the same argument that was used to explain why assembly language was the most flexible language and why assembly language would always continue to be used for largescale app development.
Congratulations, you've discovered Turing equivalence. Yes, if you want to build what ought to be language features into your code, you can _immitate_ alternative paradigms in just about any language. You can create linked lists of complex records in BASIC, if you want to inflict pain on yourself. (As an exercise in a data structures class, I've done this.)
But this is... very messy. You end up with code that is needlessly difficult to maintain, needlessly bug-prone.
> Want a C++ interpreter in Lisp?
How about a C++ interpreter in C++? Huh? Nobody's ever written one of those either? That's because C++ wasn't designed to be an interpreted language. Now, a C++ _compiler_ in lisp, that wouldn't be so hard. (I don't know that it's been done, but in principle there's no reason it couldn't be. Lisp is not used traditionally for such things, because "it's too slow" -- a problem that is going away these days.)
> Garbage collection simply replaces the memory leak of forgetting > to free() memory with the memory leak of holding onto a reference > too long.
This is true if you do reference counting (like in Perl5), but with true garbage collection this is not so.
> Video games and many other real-time applications are like that.
Yes, realtime games -- because in games performance matters more than stability. Dataloss in a realtime game is generally no really big deal.
> There are several times more embedded systems in use on this > planet than PCs.
Yes, but PCs are used for several times more distinct applications. Any given embedded device is generally not used for very many distict tasks.
Except PDAs, but those are becomming more powerful all the time, just as PCs are, and the idea of running an app written in (say) Perl on a palmtop sounds much less absurd today than it did five years ago.
> The use of C(++) for document-oriented and database-oriented > applications on machines at least as powerful as a PC has > already begun to decrease as Java technology and its clones > catch on
Yes, but Java has many of the same problems as C. Still, the use of VHLLs *is* beginning to catch on, it just hasn't fully arrived yet.
> Stallman has done more harm to the Open Source movement than > anyone else.
That's over the top. Granted, Stallman is an idealistic nutcase with strange ideas and strange priorities, and he likes to shove them down everyone's throat, but nevertheless he has actually provided quite a bit of really useful stuff. He coordinated the early development of some very important things: gcc (without which we wouldn't have Linux *or* Free/Net/Open BSD in their current forms) and a number of important filesystem tools, plus of course Emacs, without which we would all die or (worse;-) have to use vim.
It's only recently, after the OSS movement gained some real momentum in the form of lots of programmers writing code, that RMS seems to have stopped contributing anything useful himself and gone off into full-time-ideology mode. (Does he still write code these days? HURD? What? Anything anyone *uses*?)
Still, even in full-time-ideology mode, he's mostly harmless. Most folks pay more attention to other people (ESR for example), and even the people who consider RMS as the big leader don't buy his most inane ramblings. What harm has he done, other than annoy people such as yourself who haven't learned to ignore him?
Yes, the GS departure is another example of how the Gnu project is becomming irrelevant. But the Gnu project is becomming irrelevant *mostly* because the open-source movement has gained such momentum that it no longer needs the FSF as such. We depend on certain Gnu software, but if the FSF evaporated tomorrow we'd still have (and still be able to develop and improve) that software. The FSF as an institution we no longer need, and the reason we no longer need them is because (though RMS does not realise it yet) they were successful.
The FSF gave people like Linus the tools they needed to create free software. The internet gave them the ability to easily share it. Linux attracted lots of developers and created a critical momentum. Companies like RedHat and IBM gave the movement enough credibility (in the eyes of suits) to force everyone in the industry to take notice. The rest is details.
> People that write bad code will always write bad code
This is true. Software will always have bugs. But it is also irrelevant to the other poster's (completely valid) point: languages that don't provide basic facilities like automatic dynamic storage allocation (and deallocation) are largely to blame for inane errors like segfaults and buffer overruns, the sorts of problems that have plagued the software industry for thirty years although they are 100% preventable.
Yes, that means C and C++ need to be set aside (for most app development) in favour of VHLLs, and the sooner the better. Of course lowlevel languages will continue to be used for inherently lowlevel tasks, like kernels and bootloaders, but in 2003 there's no reasonable excuse to start writing a major userland application in C.
> the point is that C/C++ gives you more power to create better > code than other programming languages do, because they are > much more flexible
They're not more flexible, just more arcane. Okay, so they're more flexible than BASIC and COBOL. Compare them to a decent language, like lisp or Perl, and they suddenly don't seem so flexible. Let's see... just in terms of basic flexibility, which paradigms can you program them in?
paradigm C C++ Perl Python Lisp
procedural yes yes yes yes yes
object-oriented no partly mostly* yes partly
event-oriented no ? yes yes no
list-oriented no no yes yes yes
functional no no yes ? yes
logical no no no* ? no
The ? are where I don't know; maybe someone who knows Python can fill in these blanks for me. I'd also be interested to see other languages charted by paradigm this way.
Gosh, C is so much more flexible than the others...
BTW, Lisp isn't even a VHLL, just a regular third-generation HLL, and older than Cowboy Neal's grandfather, but I threw it in just to show how C suffers from comparison with even half-decent languages, if you compare it on the basis of something other than raw speed. Which brings me to my next point...
The main reason C and C++ are still used is for speed optimisation, but this speed optimisation comes at a cost in terms of developer time and application stability, and in an era when most desktop computers spend 99.99% of their time idle, it's high time we give up some speed optimisation so that our apps can be more stable, easier to maintain and improve, and, in general, better. I would gladly accept applications that run 200% slower in exchange for 95% fewer crashes. Frankly, at this point, processor speed is such a commodity that I'd accept applications that run 200% slower for no tangible gain at all, because I buy the slowest CPU available and it spends almost all of its time idle; the only delays I ever *notice* are when I'm waiting on my CD-ROM drive or my internet connection or trying to work with some data (such as a large image) that's too big to fit in my RAM and so forces swapping -- or when an app crashes and I have to restart it and then redo my work.
C was great in its day, but things have changed and it's time to move on. CPU time is now cheaper than programmer time. It's time for variables that can store arbitrarily large data without overflowing. It's time for lists and strings and namespaces and (dare I say it) matching rules to be first-class citizens. It's time for garbage collection, taint checking, and dynamic typing. It's time for the wide deployment of Very High Level Languages.
Computers crash (and have any number of other problems) largely because almost all software is still developed using third-generation ("high-level") languages. These languages place on the programmer the burden of such fiddly details as allocating and freeing memory and checking the size of allocated memory to see that it's adequate for the data being copied in.
*Most* of the time when an application crashes seemingly at random, it's a memory allocation problem of one kind or another: a buffer that was allocated to small and gets overrun, or a pointer error, or something of that nature. When an application (or your whole system) grows more sluggish the longer you leave it running, that's usually a memory leak: something was allocated and not released properly -- repeatedly. All of these problems result from a lack of excruciating vigilence on the part of the programmers when using a language that requires it. In a large project, maintaining that ceaseless caution is a nightmarish prospect.
Languages (both interpreted and compiled languages) have been around for over a decade that handle these things, freeing the programmer to concentrate on developing the more high-level features of the software, but because this checking imposes some overhead (in terms mostly of CPU time and sometimes some memory footprint), they don't get used for most applications. Yet.
The time is coming, though. The value of VHLLs is beginning to be recognised, *finally*. When software is written in a language with built-in memory management, problems like segmentation faults (core dumps in Unix; in the Windows world these are known as Illegal Operations, formerly known as General Protection Faults) and buffer overruns go away entirely.
Add proper garbage collection (not reference counting like Perl5 does, but real gc, which I hope we will get in Perl6), and you also dispense with memory leaks once and for all.
It's coming. Applications are *beginning* to be developed in this next generation of languages, but it takes time, because all the existing apps are mostly C and C++, and you have to throw them out and start over, which nobody wants to do for obvious reasons.
There will of course always be room for a certain amount of inherently low-level code written in C or one of its kin: code that absolutely can't spare a nanosecond per run, code that has to run on the bare metal (kernels, bootloaders,...), and code needed to bootstrap the VHLL tools (compilers and whatnot). But when C is no more common than assembly language is today, then you'll be done with random crashes.
Applications will of course still have bugs -- circumstances wherein they don't perform as they ought. And you'll still have hangs, because nobody's figured out how to design a compiler or interpreter that can detect an infinite loop, and nobody except Mel[1] has coded up an implementation for completing an infinite loop and passing on to what follows. Perhaps quantum computing will one day change this, but that's outside of the forseeable future. But crashes of the sort where the app suddenly terminates should be mostly a thing of the past within twenty years, ten if we're quite lucky.
[1] Google for "The Story of Mel, A Real Programmer".
This release is important for web developers because it supports the full alpha channel transparency for PNG format images, both in the foreground and the background. Gecko has had support for this for some time, but Opera 6 was missing it.
KHTML (as of Konq 3.1.0) still needs this, and of course MSIE. But when all the browsers you have to support have it, it makes a lot of visual web layout design problems go away.
So, bravo to Opera for supporting the alpha channel.
A VHLL can be compiled, but it has to allow the programmer to take certain things for granted, such as memory management. In a true VHLL, it is not possible to dereference an invalid pointer, not possible to overrun a buffer, not possible to jump to an invalid address,...
It is still possible to shoot yourself in the foot, of course, but you have to do something visibly dangerous, like shell out to a system call with untrusted data -- and compiler warnings can alert you to all the places you do this, so you can check them. You can mess up your checks, of course, or just not bother to be careful, but it's better than a traditional HLL.
> Almost every user application except for cutting edge games > could be written in Perl/tk or Python or XUL or something. > Unfortunately, the ability to do this has existed for years > if people aren't using it now I don't predict that they'll > start.
They are starting; it's just gradual. Also, you (the user) don't always _know_ an app is written in a VHLL. I didn't know printerdrake was written in Perl until I needed to debug a problem I was having. (The problem was not with printerdrake as such, just a printer that wasn't supported, and I had the manufacturer's PPD and was hoping to figure out how to make it work.) I was able to trace the issue as far as foomatic, but I ran into a binary (which was probably written in C) and gave up then.
There's a performance penalty for using current versions of Perl or Python instead of C. But hardware is getting better, making that performance penalty less relevant, and the VHLLs are getting better too. Perl6 is going to be *vastly* better to work in than Perl5, for example. Personally, I would be happy to trade 50% more CPU cycles and 50% more RAM for apps developed in VHLLs, for an assortment of reasons, most notably because such apps would be much easier to maintain.
It will come, in time. They said assembly language would never pass out of vogue, because you got so much better performance with it. Sure, it took longer to write programs, but you got programs that performed better... C and its kin are basically a case of that same thing.
What's odd is that lisp doesn't seem to be in this category (with C I mean), even though it's quite old as HLLs go. I don't think I'd consider common lisp to be a VHLL either, though. I'm not sure where to categorise lisp.
I could almost swear I typed 30%, not 85%... sorry for any confusion. And yes, all statistics courtesy of Flagrant Estimation Incorporated.
Re:this is all well and good
on
GCC 3.3 Released
·
· Score: 2, Insightful
> Windows - developer friendly. Linux - developer hostile.
Is that why Windows has 95% of the users and 60% of the developers, while Linux/BSD/Unix (excluding Mac) have 1% of the users and 85% of the developers? Yeah, Linux is *real* developer-hostile. The way it hides all the implementation details makes it so hard for programmers to get things working...
Calling Linux user-hostile would be a gross exaggeration, but at least it would be barking up something that resembles a tree.
Still, I'm looking forward to the day when normal people don't need C/C++ compilers anymore because everything's written in VHLLs. (The kernel hackers and compiler/interpreter jocks will of course always need the lower-level tools, but application developers someday won't, just as today most of them don't need assembly stuff anymore.)
Sure, and after that let's see if the slashdot effect can also bring down the Yahoo index and the Microsoft homepage.
Anyway, back to topic...
if errno 42 were still available I'd definately vote for EDONTPANIC, but as it stands I'm thinking maybe an acronym that shouldn't offend people who don't happen to know what it means. You know, EWTF or somesuch. If it were actually a user error (as the person who suggested EUSERERR must have thought) I'd say EPEBCAK, but the EDOOFUS error was actually being used for errors in the programmer's own code, so something more like ECANTHAPPEN makes much better sense than EUSERERR. But ECANTHAPPEN isn't really all that funny. (Then again, EDOOFUS is pretty marginal in that regard too.) There's always EONETWOFIVETHREESIRTHREE, I guess.
I get 60-80 spams a day and estimate that most spam either *does* do that or else is illegible due to being written in a foreign character set (mostly: gb2312, ks_c*, and euc_kr*; I believe that the first of these represents Mandarin (Chinese) and one of the others is used for Hangul (a Korean language), but I have no idea about the third one, except that it is Asian and could possibly be ideographic, though less obviously so than gb2312; it could also be syllabic; it doesn't look like an alphabet to me).
> $52K/year is lame for a full-time job? Are you high?
Depends. Where do you live? What education do you have? Job experience? Expenses?
For someone with no college degree and job experience limited to entry-level, largely-unskilled positions, living in the rural US and not supporting a family, that's good money. For a well-educated yuppie living in the northern portion of New Jersey near NYC and sending kids to a private prep school, it is indeed lame for a full-time job. For most people in the US, it's somewhere between.
*shrug*. It's significantly more than I make (working as TCG at a public library), but I work part time so that's not fair. And my expenses are well below average, due to a combination of factors. (To start, I maintain a pedestrian lifestyle, living in a small city; I can walk to any part of town in twenty minutes; I work four blocks from my house. No car, no gas, no car insurance, cheap rent, I pay an ISP bill, but it's less than most people pay for Cable TV, which I don't have... never make long-distance phone calls... don't have a credit card... in a word, I'm frugal. And celibate[1], which also cuts down on expenses (though that's not why I'm celibate; I just prefer to spend most of my time alone). So I can afford to work twenty-five hours a week and put money into savings.) I can well imagine that someone with a position similar to mine, less hatred for spam, fewer morals about pressing oneself on others against their will, and more ambition to make money, might consider such an opportunity to be just the thing.
[1] A loner. In Geek code, that's spelled !r !y-
and the lack of any > is significant.
Slashdot Mirror
If you want minimalistic, ratpoison is there. None of this nonsense
about window borders; all windows are fullscreen (which is the
default), halfscreen, or quarterscreen.
Not my thing, but hey, it's minimalist.
Personally I rather like sawfish. E would be okay if its iconbox
were more featureful or if it supported the Gnome panel's tasklist.
icewm is pretty decent too. But I settled on sawfish.
The one window manager I really loathe is metacity.
Not exactly. They understand the value of open-source software and
prefer it, and I have heard that they release all of the stuff they
develop (such as the excellent harddrake and printerdrake) under
open-source licenses, but they do include some things Debian does
not, so their policies are apparently not 100% the same. Also, some
of the non-download editions of Mandrake include some proprietary
commericial software bundled; Debian as a matter of policy does not
have any special non-download editions with value-added software
bundles. (If this bothers you about Mandrake, you can just get the
download edition, which has no such bundles -- though the third CD
does have some freely-distributable software that doesn't qualify
under everyone's definition of free, but I was under the impression
that Debian has a non-free section as well, so that may be neither
here nor there.)
Then you have to define it in terms of temperature and pressure,
which is a big pain.
What I don't understand is why they don't just define it as the mass
of some specific number of standard water molecules. (Or molecules
of some other substance, or some number of protons, or whatever.)
Voltage is equal to current times resistance. Current has its own
base unit (the amp), but resistance is defined in terms of force
and so indirectly depends on the definition of the mass unit.
The kilogram is very important, because the equivalent unit in the
other measurement system is obscure. Even if we're not entirely
sure _exactly_ how much a kilogram is, we still have to use it,
because *nobody* has any idea how much mass a "slug" is. Most
people have never even _heard_ of it.
I've been pronouncing it as skwul, where the u is de-emphasised as
with a schwa. I also thought about pronouncing it "squall", but I
find "skwul" just rolls off the tongue more easily for me, and it's
more obvious that that would of course be spelled "sql"; if you say
"squall", you expect an a in it someplace.
I certainly can't imagine pronouncing it "sequel"; that adds in
_two_ extra vowells that clearly aren't there, which is totally
unnecessary. I once heard someone talking about "sequel server"
in a speech, and it took me fifteen minutes to figure out he was
talking about MS SQL Server, even though I knew very well from
context that it had something to do with databases. That's the
only time I've ever heard "SQL" pronounced as "sequel".
> what is the layout called that your using?
:-)
;
I call it "Jonadabian". It's a custom layout of
my own design. I have an Avant keyboard, so I
can put any key in any position I want.
My layout is based on QWERTY, but there are some
quite important differences. Most notably, I
have shift and control under the home positions
of my left and right pinkies (respectively) so
that I don't have to hyperextend my pinkies every
two seconds. My pinkies used to hurt after a few
hours of using the computer, and now they don't.
Overall, I don't think my layout leads to more
words per minute than QWERTY (at least, not
significantly more), but I like that my pinkies
don't hurt, so I'm keeping it
Here are my changes from QWERTY:
Where a normally goes is left shift.
Where ; normally goes is right ctrl.
Where left shift and capslock normally go are
both k. There is no capslock. I never use it.
Where left win/meta normally goes is [{,
and to the right of the spacebar is ]}
To the right of p is
Where right shift normally goes is an
extra |\ key.
Where numlock normally goes is nothing; there
is no numlock. Numlock is permanently off.
The bottom 4 function keys on the left side
(F7-F10) are shift. (This is mostly to prevent
hitting them by mistake.) The top two are the
left window/meta key (which I do need, but I
wanted it out of the way where I won't hit it
by mistake) and the menu key. (The function
keys along the top row are normal.)
There might be a couple of other changes, but
that's most of them at this point. I may make
additional improvements from time to time as I
think of ways to improve things.
No, she didn't. Play the scene back again. She asked him his
opinion, told him she was sorry, that he had what it takes, but
that it was like he was _waiting_ for something. He asked what
he was waiting for, and she said she didn't know. (Then she
speculated: "Your next life maybe? Who knows?" -- but she made
it totally clear she didn't know.)
As it turned out, he was waiting for the right motivation, for
Morpheus' life to be on the line.
> Personally, I am really used to punch in my password(s) and I
S ionismmxi
> would not be surprised if other could imitate me simply by trying
> to input it very efficiently.
Me too, _except_ that I use a modified keyboard layout, which makes
certain things take different amounts of time than usual. (For
example, switching between upper and lower case is faster, because
shift is under a home position on my layout. OTOH, k is rather
out of the way and generates an extra pause before or after.)
I still prefer the long-nasty-password approach. Use a password
like cEveNaughtDiVulge-canceroussGRANDpapy;rot14impreS
(not my real password, of course), type it fast, and nothing but
a sniffer is going to compromise it. Yet something like that is
only barely more difficult to memorise than something traditional
like Rx7QvGOc0b. (You remember, "seven naught divulge cancerous
grandpappy rot14 impressionism xi", eight words (except rot14,
which is easy to remember because it's one more than Caesar), but
then you make minor tweaks such as elided and doubled letters and
case shifts, which your muscle memory will do for you automatically
after a dozen times typing it.)
> Actually, he does. I filed a bug report about Emacs and he
> fixed it himself.
He does? Well, then strange ideology notwithstanding he's still
the man. Emacs r0x0rz. (Okay, so I wish it were multithreaded...
but that's me being picky.)
> Opera 6 had full alpha channel support for PNG
It does? But I have this screenshot that shows Opera doing the
same thing MSIE does... [checks] [checks again]
Oh... my bad, that was Opera 5. Huh. I Learn'd som'thin.
On Slashdot. Go figure.
> It CAN use lists, you just have to write the code for that.
It can use lists, but it does not do list-oriented programming in
the same way that lisp and Perl can. (Realise that in lisp, a
list is also a function, and vice versa, and I've seen this done
in Perl also, or something very like it.)
> It can do anything, you just have to write the underlying
> class, etc
This is the same argument that was used to explain why assembly
language was the most flexible language and why assembly language
would always continue to be used for largescale app development.
Congratulations, you've discovered Turing equivalence. Yes,
if you want to build what ought to be language features into
your code, you can _immitate_ alternative paradigms in just
about any language. You can create linked lists of complex
records in BASIC, if you want to inflict pain on yourself.
(As an exercise in a data structures class, I've done this.)
But this is... very messy. You end up with code that is needlessly
difficult to maintain, needlessly bug-prone.
> Want a C++ interpreter in Lisp?
How about a C++ interpreter in C++? Huh? Nobody's ever written
one of those either? That's because C++ wasn't designed to be
an interpreted language. Now, a C++ _compiler_ in lisp, that
wouldn't be so hard. (I don't know that it's been done, but in
principle there's no reason it couldn't be. Lisp is not used
traditionally for such things, because "it's too slow" -- a
problem that is going away these days.)
> Garbage collection simply replaces the memory leak of forgetting
> to free() memory with the memory leak of holding onto a reference
> too long.
This is true if you do reference counting (like in Perl5), but with
true garbage collection this is not so.
> Video games and many other real-time applications are like that.
Yes, realtime games -- because in games performance matters more
than stability. Dataloss in a realtime game is generally no really
big deal.
> There are several times more embedded systems in use on this
> planet than PCs.
Yes, but PCs are used for several times more distinct applications.
Any given embedded device is generally not used for very many
distict tasks.
Except PDAs, but those are becomming more powerful all the time,
just as PCs are, and the idea of running an app written in (say)
Perl on a palmtop sounds much less absurd today than it did five
years ago.
> The use of C(++) for document-oriented and database-oriented
> applications on machines at least as powerful as a PC has
> already begun to decrease as Java technology and its clones
> catch on
Yes, but Java has many of the same problems as C. Still, the
use of VHLLs *is* beginning to catch on, it just hasn't fully
arrived yet.
> Stallman has done more harm to the Open Source movement than
;-)
> anyone else.
That's over the top. Granted, Stallman is an idealistic nutcase
with strange ideas and strange priorities, and he likes to shove
them down everyone's throat, but nevertheless he has actually
provided quite a bit of really useful stuff. He coordinated the
early development of some very important things: gcc (without
which we wouldn't have Linux *or* Free/Net/Open BSD in their
current forms) and a number of important filesystem tools, plus
of course Emacs, without which we would all die or (worse
have to use vim.
It's only recently, after the OSS movement gained some real
momentum in the form of lots of programmers writing code, that
RMS seems to have stopped contributing anything useful himself
and gone off into full-time-ideology mode. (Does he still write
code these days? HURD? What? Anything anyone *uses*?)
Still, even in full-time-ideology mode, he's mostly harmless.
Most folks pay more attention to other people (ESR for example),
and even the people who consider RMS as the big leader don't buy
his most inane ramblings. What harm has he done, other than
annoy people such as yourself who haven't learned to ignore him?
Yes, the GS departure is another example of how the Gnu project
is becomming irrelevant. But the Gnu project is becomming
irrelevant *mostly* because the open-source movement has gained
such momentum that it no longer needs the FSF as such. We depend
on certain Gnu software, but if the FSF evaporated tomorrow we'd
still have (and still be able to develop and improve) that
software. The FSF as an institution we no longer need, and the
reason we no longer need them is because (though RMS does not
realise it yet) they were successful.
The FSF gave people like Linus the tools they needed to create
free software. The internet gave them the ability to easily
share it. Linux attracted lots of developers and created a
critical momentum. Companies like RedHat and IBM gave the
movement enough credibility (in the eyes of suits) to force
everyone in the industry to take notice. The rest is details.
You must be programming in a language without bignums. Please, for ;-)
your own safety, put down your abacus and get a real language
> People that write bad code will always write bad code
This is true. Software will always have bugs. But it is also
irrelevant to the other poster's (completely valid) point:
languages that don't provide basic facilities like automatic
dynamic storage allocation (and deallocation) are largely
to blame for inane errors like segfaults and buffer overruns,
the sorts of problems that have plagued the software industry
for thirty years although they are 100% preventable.
Yes, that means C and C++ need to be set aside (for most app
development) in favour of VHLLs, and the sooner the better.
Of course lowlevel languages will continue to be used for
inherently lowlevel tasks, like kernels and bootloaders, but
in 2003 there's no reasonable excuse to start writing a major
userland application in C.
> the point is that C/C++ gives you more power to create better
> code than other programming languages do, because they are
> much more flexible
They're not more flexible, just more arcane. Okay, so they're
more flexible than BASIC and COBOL. Compare them to a decent
language, like lisp or Perl, and they suddenly don't seem so
flexible. Let's see... just in terms of basic flexibility,
which paradigms can you program them in?
paradigm C C++ Perl Python Lisp
procedural yes yes yes yes yes
object-oriented no partly mostly* yes partly
event-oriented no ? yes yes no
list-oriented no no yes yes yes
functional no no yes ? yes
logical no no no* ? no
The ? are where I don't know; maybe someone who knows Python
can fill in these blanks for me. I'd also be interested to see
other languages charted by paradigm this way.
Gosh, C is so much more flexible than the others...
BTW, Lisp isn't even a VHLL, just a regular third-generation HLL,
and older than Cowboy Neal's grandfather, but I threw it in just
to show how C suffers from comparison with even half-decent
languages, if you compare it on the basis of something other than
raw speed. Which brings me to my next point...
The main reason C and C++ are still used is for speed optimisation,
but this speed optimisation comes at a cost in terms of developer
time and application stability, and in an era when most desktop
computers spend 99.99% of their time idle, it's high time we give
up some speed optimisation so that our apps can be more stable,
easier to maintain and improve, and, in general, better. I would
gladly accept applications that run 200% slower in exchange for
95% fewer crashes. Frankly, at this point, processor speed is such
a commodity that I'd accept applications that run 200% slower for
no tangible gain at all, because I buy the slowest CPU available
and it spends almost all of its time idle; the only delays I ever
*notice* are when I'm waiting on my CD-ROM drive or my internet
connection or trying to work with some data (such as a large image)
that's too big to fit in my RAM and so forces swapping -- or when
an app crashes and I have to restart it and then redo my work.
C was great in its day, but things have changed and it's time
to move on. CPU time is now cheaper than programmer time. It's
time for variables that can store arbitrarily large data without
overflowing. It's time for lists and strings and namespaces and
(dare I say it) matching rules to be first-class citizens. It's
time for garbage collection, taint checking, and dynamic typing.
It's time for the wide deployment of Very High Level Languages.
* Perl6 will fix this big time.
Computers crash (and have any number of other problems) largely
...), and code
because almost all software is still developed using third-generation
("high-level") languages. These languages place on the programmer
the burden of such fiddly details as allocating and freeing memory
and checking the size of allocated memory to see that it's adequate
for the data being copied in.
*Most* of the time when an application crashes seemingly at random,
it's a memory allocation problem of one kind or another: a buffer
that was allocated to small and gets overrun, or a pointer error,
or something of that nature. When an application (or your whole
system) grows more sluggish the longer you leave it running, that's
usually a memory leak: something was allocated and not released
properly -- repeatedly. All of these problems result from a lack
of excruciating vigilence on the part of the programmers when using
a language that requires it. In a large project, maintaining that
ceaseless caution is a nightmarish prospect.
Languages (both interpreted and compiled languages) have been around
for over a decade that handle these things, freeing the programmer
to concentrate on developing the more high-level features of the
software, but because this checking imposes some overhead (in terms
mostly of CPU time and sometimes some memory footprint), they don't
get used for most applications. Yet.
The time is coming, though. The value of VHLLs is beginning to be
recognised, *finally*. When software is written in a language with
built-in memory management, problems like segmentation faults (core
dumps in Unix; in the Windows world these are known as Illegal
Operations, formerly known as General Protection Faults) and buffer
overruns go away entirely.
Add proper garbage collection (not reference counting like Perl5
does, but real gc, which I hope we will get in Perl6), and you
also dispense with memory leaks once and for all.
It's coming. Applications are *beginning* to be developed in this
next generation of languages, but it takes time, because all the
existing apps are mostly C and C++, and you have to throw them out
and start over, which nobody wants to do for obvious reasons.
There will of course always be room for a certain amount of
inherently low-level code written in C or one of its kin: code
that absolutely can't spare a nanosecond per run, code that has
to run on the bare metal (kernels, bootloaders,
needed to bootstrap the VHLL tools (compilers and whatnot). But
when C is no more common than assembly language is today, then
you'll be done with random crashes.
Applications will of course still have bugs -- circumstances
wherein they don't perform as they ought. And you'll still have
hangs, because nobody's figured out how to design a compiler or
interpreter that can detect an infinite loop, and nobody except
Mel[1] has coded up an implementation for completing an infinite
loop and passing on to what follows. Perhaps quantum computing
will one day change this, but that's outside of the forseeable
future. But crashes of the sort where the app suddenly terminates
should be mostly a thing of the past within twenty years, ten if
we're quite lucky.
[1] Google for "The Story of Mel, A Real Programmer".
For those who haven't tried the beta...
This release is important for web developers because it supports
the full alpha channel transparency for PNG format images, both in
the foreground and the background. Gecko has had support for this
for some time, but Opera 6 was missing it.
KHTML (as of Konq 3.1.0) still needs this, and of course MSIE.
But when all the browsers you have to support have it, it makes
a lot of visual web layout design problems go away.
So, bravo to Opera for supporting the alpha channel.
> If Linux really required all those extra developers for that much
> less net production
How do you calculate net production?
> Do Java and C# qualify as "VHLL" to you?
...
No.
A VHLL can be compiled, but it has to allow the programmer to take
certain things for granted, such as memory management. In a true
VHLL, it is not possible to dereference an invalid pointer, not
possible to overrun a buffer, not possible to jump to an invalid
address,
It is still possible to shoot yourself in the foot, of course,
but you have to do something visibly dangerous, like shell out
to a system call with untrusted data -- and compiler warnings
can alert you to all the places you do this, so you can check
them. You can mess up your checks, of course, or just not
bother to be careful, but it's better than a traditional HLL.
> Almost every user application except for cutting edge games
> could be written in Perl/tk or Python or XUL or something.
> Unfortunately, the ability to do this has existed for years
> if people aren't using it now I don't predict that they'll
> start.
They are starting; it's just gradual. Also, you (the user)
don't always _know_ an app is written in a VHLL. I didn't know
printerdrake was written in Perl until I needed to debug a
problem I was having. (The problem was not with printerdrake
as such, just a printer that wasn't supported, and I had the
manufacturer's PPD and was hoping to figure out how to make it
work.) I was able to trace the issue as far as foomatic, but
I ran into a binary (which was probably written in C) and gave
up then.
There's a performance penalty for using current versions of
Perl or Python instead of C. But hardware is getting better,
making that performance penalty less relevant, and the VHLLs
are getting better too. Perl6 is going to be *vastly* better
to work in than Perl5, for example. Personally, I would be
happy to trade 50% more CPU cycles and 50% more RAM for apps
developed in VHLLs, for an assortment of reasons, most notably
because such apps would be much easier to maintain.
It will come, in time. They said assembly language would never
pass out of vogue, because you got so much better performance
with it. Sure, it took longer to write programs, but you got
programs that performed better... C and its kin are basically
a case of that same thing.
What's odd is that lisp doesn't seem to be in this category
(with C I mean), even though it's quite old as HLLs go. I don't
think I'd consider common lisp to be a VHLL either, though. I'm
not sure where to categorise lisp.
I could almost swear I typed 30%, not 85%... sorry for any confusion.
And yes, all statistics courtesy of Flagrant Estimation Incorporated.
> Windows - developer friendly. Linux - developer hostile.
Is that why Windows has 95% of the users and 60% of the developers,
while Linux/BSD/Unix (excluding Mac) have 1% of the users and 85%
of the developers? Yeah, Linux is *real* developer-hostile. The
way it hides all the implementation details makes it so hard for
programmers to get things working...
Calling Linux user-hostile would be a gross exaggeration, but at
least it would be barking up something that resembles a tree.
Dude, that's what Emacs is for.
Still, I'm looking forward to the day when normal people don't need
C/C++ compilers anymore because everything's written in VHLLs. (The
kernel hackers and compiler/interpreter jocks will of course always
need the lower-level tools, but application developers someday won't,
just as today most of them don't need assembly stuff anymore.)
Sure, and after that let's see if the slashdot effect can also
bring down the Yahoo index and the Microsoft homepage.
Anyway, back to topic...
if errno 42 were still available I'd definately vote for EDONTPANIC,
but as it stands I'm thinking maybe an acronym that shouldn't offend
people who don't happen to know what it means. You know, EWTF or
somesuch. If it were actually a user error (as the person who
suggested EUSERERR must have thought) I'd say EPEBCAK, but the
EDOOFUS error was actually being used for errors in the programmer's
own code, so something more like ECANTHAPPEN makes much better sense
than EUSERERR. But ECANTHAPPEN isn't really all that funny. (Then
again, EDOOFUS is pretty marginal in that regard too.) There's
always EONETWOFIVETHREESIRTHREE, I guess.
> Sure, but most spam doesn't do that.
I get 60-80 spams a day and estimate that most spam either *does*
do that or else is illegible due to being written in a foreign
character set (mostly: gb2312, ks_c*, and euc_kr*; I believe that
the first of these represents Mandarin (Chinese) and one of the
others is used for Hangul (a Korean language), but I have no idea
about the third one, except that it is Asian and could possibly
be ideographic, though less obviously so than gb2312; it could
also be syllabic; it doesn't look like an alphabet to me).
> $52K/year is lame for a full-time job? Are you high?
Depends. Where do you live? What education do you have? Job
experience? Expenses?
For someone with no college degree and job experience limited to
entry-level, largely-unskilled positions, living in the rural US
and not supporting a family, that's good money. For a well-educated
yuppie living in the northern portion of New Jersey near NYC and
sending kids to a private prep school, it is indeed lame for a
full-time job. For most people in the US, it's somewhere between.
*shrug*. It's significantly more than I make (working as TCG at
a public library), but I work part time so that's not fair. And
my expenses are well below average, due to a combination of
factors. (To start, I maintain a pedestrian lifestyle, living in
a small city; I can walk to any part of town in twenty minutes; I
work four blocks from my house. No car, no gas, no car insurance,
cheap rent, I pay an ISP bill, but it's less than most people pay
for Cable TV, which I don't have... never make long-distance phone
calls... don't have a credit card... in a word, I'm frugal. And
celibate[1], which also cuts down on expenses (though that's not
why I'm celibate; I just prefer to spend most of my time alone).
So I can afford to work twenty-five hours a week and put money
into savings.) I can well imagine that someone with a position
similar to mine, less hatred for spam, fewer morals about pressing
oneself on others against their will, and more ambition to make
money, might consider such an opportunity to be just the thing.
[1] A loner. In Geek code, that's spelled !r !y-
and the lack of any > is significant.