Lisp is fast, when you add type annotations (optional) to variables and then compile, without it it is not that fast.
take a look at this language comparison, and of course the (flawed, but still not worthless) great shootout. or just google for "optimization" on comp.lang.lisp.
Static typing languages (Java,C#) allow for greater bytecode performance.
i've heard loads of people saying this, but i've never seen anybody explain why this is necessarily so. what, precisely, about statically typed languages makes it easier to optimize them when compiling them to bytecode, in particular?
and what's so different about bytecode (as opposed to native code) that we can't optimize dynamic languages when compiling them to bytecode, even though we have been able to optimize dynamic languages when compiling them to native code for decades already? i don't get it.
Python is slower than compiled languages, because it is interpreted (from bytecode, at best; that's still a far cry from real compilation). static versus dynamic typing has nothing to do with it.
Lisp is dynamic and fast, because lisp is natively compiled. C# is compiled (maybe JIT-compiled, but that counts) to something reasonably fast, even though it's static. Java's just a fucking mess, and what Python needs is a good native compiler - a JIT-compiler would do.
i'm not sure what crack you're smoking that makes you not like Python's OO syntax. it makes a helluva lot more sense to me than, say, Java's.
maybe not the depths of hades, but it definitely leaves the door to pandemonium unlocked and ajar.
having to install software by means of source tarball and bunch of patches makes it that much harder to integrate with your favourite package management system. (rpm, apt, whathaveyou. maybe the gentoo users have something like a solution to this - does emerge track what it installs where and when, like RPM does? i sure hope so!)
this matters to those of us who use one machine to do more than one thing, because tracking which files belong to which package installed at what date gets painful when you have a lot of packages all installed by tarball plus patches, especially if it's done over a long span of time or by more than one person. you want to keep track of that, because otherwise you can't ever be really sure some random file is needed; that the new tarball you just did "make install" on didn't trample some file in/usr/etc or wherever that another tarball needed not to have trampled; or that "make uninstall" won't wipe out a.so you'll need the next time the server must be rebooted. package managers track all that metadata for you and make handling a multi-use server or workstation a lot easier, because they give you one single place to go to for finding it all.
sure, you can build your own source RPM to do this for you. it is possible to maintain your own.spec files for insert-random-number of packages you want to use whose maintainers would like for you to install by tarball instead. but unless doing that and that alone are all your job duties, you'll probably just download postfix in the vendor-provided RPMs instead and forget about it, because that very same server has all these other software packages that won't maintain themselves, either, and your life is just too short.
postfix certainly has a lot more configuration than qmail. (or what i remember of qmail - it's been a few years now, for me.) but it's not really that hard of a configuration, at least not if you use any non-bernstein software. unless you've thoroughly soaked in dan's one-line-per-file, all-machine-parsable, damn-human-readability configuration syntax kool-aid, postfix is fairly ordinary as Unixish config files go.
the only real quirks are that postfix uses about a dozen different files for different purposes / subsystems in the herd of daemons that make it up, and that a few of 'em have to be "byte-compiled" into berkeleyDB format to improve access speed before the daemons proper will read 'em. getting used to these is no harder than getting used to djb's, shall we generously call it, unusual mindset on what makes a config file good.
and, frankly, several of djb's config files look a lot more like sendmail.cf to me than any of postfix's ones. it's the same machine-readability-über-alles principle in 'em both, if you ask me. postfix generally doesn't play that mindgame on you, certainly not nearly as much.
as has been noted, postfix seems to be edging out sendmail as the default MTA in most distros.
i don't think the situation is all that analogous with DNS servers, though. sendmail is and always was an unbelievable mess to set up and maintain; the mere fact that a bunch of m4 macros was considered an improvement on the config system that preceded them should tell you something. (if it doesn't, you haven't had much exposure to m4. count that a blessing and keep away from the thing.)
by comparison, BIND versions >= 8 are simple, straightforward and eminently sensible both to configure and to keep running. as well, BIND's had its share of security problems, but nothing has nearly as awful a security track record as sendmail, not by a long shot.
finally, the cricket book is about half the size of the bat book, maybe less. i don't know about you, but that tells me BIND is a smaller, easier to learn system than sendmail.
the way it works is this: your rocket, before you fire it up, is going around the sun already. (can't help this, you've gotta start from earth, and it's going around the sun, so...) it's going around at a given speed, same speed as the earth's going - about 30KM/sec.
that speed can't just disappear. you can point at the sun and fire, but when you fire, you'd still be going sideways at those 30 klicks per sec. after you fired, you'd also be going forward at some other speed - whatever your engine gave you - but the sideways speed'd still be there.
your forward speed would be getting you closer to the sun, at least at first, but unless it was absolutely insanely huge a forward speed, it wouldn't be enough - the sideways speed would still make you miss the sun. you'd still be orbiting it, just more elliptically than before you lit your candle.
the way to break orbit is to eliminate that original, orbital velocity you started out with. just "point at the sun and shoot" isn't the best way of doing this. you want to point sideways to the sun, in the opposite direction from where you're already heading, and shoot.
One thing's for sure: this world has an endless supply of idiots, they're not going away, and the law of averages says that some of those idiots will always be working at nuclear facilities.
this is completely true, and it applies to every single thing we ever do or can do. however, it is not relevant to the debate at hand, precisely because it is universally applicable.
the only way this argument would matter would be if there was something magically special about nuclear power that set it apart from every other remotely dangerous thing we do or might do. for example, if there was no way to control, mitigate and manage the risks inherent in it, like we manage the risks involved in every other undertaking; or, for another, if the risks inherent in nuclear power were somehow magically different from the risks we take in other undertakings, not just in magnitude but in kind, such that we couldn't use the same decision tree on it as we do on other risky things.
yes, there are risks in nuclear power. yes, it is possible to screw it up. but so too are there risks in anything else that's worth doing - would you like us to just stay huddled under our blankets for fear of stubbing our toes? every other risk we mitigate as best we can, and then we make a value judgement as to whether or not the benefit is worth the marginal risk remaining. are you trying to claim that this method doesn't work when dealing with nuclear power, for some reason?
or are you claiming to have a good argument - supported by objective evidence - that the benefit of nuclear power, even after you figure in the best job we can do at managing and mitigating its inherent risks, is not at the end of the day worth the marginal risk remaining? i would like to see that argument and its evidence, if so. most people who try to claim this last just make blatant assertions without backing their judgement up with anything.
In order to get to the sun you have to cancel out the 30 km/s orbital speed (where 0 km/s is the Sun's 'orbit') and that will require enourmous amounts of energy.
No, you don't. This might be true if you were trying to gently land on the sun.
nope, grandparent is right.
think of it this way: if you could ignore the gravity of the sun, then cancelling out the earth's orbital velocity would leave you stationary in space. you'd be sitting where the earth was when you fired your rocket, and one year later you'd get hit head-on by the planet at a godawful speed.
since you can't ignore the sun's gravity, you'd actually end up accelerating towards the sun at whatever rate the sun exerts out here; some time after you finished your engine burn, you'd hit the star head-on at an even more mindboggling speed. (well, technically we're already accelerating towards the sun that way, that's what keeps the planet's orbit curved into an ellipse... but ignore that for now, we don't want to get that egg-headed.)
if you cancelled out only part of the earth's orbital velocity, you'd go into a more-or-less elliptical orbit around the sun. if it was elliptical enough, you might get dragged in due to to aerodynamic drag by the outer parts of the corona, but it'd take a while.
i don't have a back yard, so no. however, if i had to choose between storing the nuclear waste a gigawatt plant puts out in a year on my property and storing the waste put out by a gigawatt fossil-burning plant over the same year in the same place, i'd pick the nuclear waste in a red-hot second. there'd be a lot less of it, even after you figure in the shielding and protection the stuff'd need.
plus, the low-level waste would be decayed down to safe levels in my lifetime, at which point i could start looking into finding some way to maybe recycle at least part of it somehow. i'd just love to see you find any use for most of what comes out of a coal-burner's backside, ever. CO2, mercury and sulfur don't sell for very much these days.
I for one have never quite understood your paranoia about the government.
that's because you live under a government that can actually be trusted.
i didn't use to understand americans either, then i moved here. now i'm amazed they aren't even more paranoid and distrustful of the corrupt egomaniacal idiots they've got running the place. of course, their paranoia and fear don't actually do anything to help the situation, but at least i can understand the impulse.
Senders that use SPF + SES (Signed Envelope Sender) make it possible
so, you set up SPF to fix the problem with SMTP; and you set up SRS to fix the problem with SPF; and now you're telling me to set up something called SES to fix the problem with SRS...
can you at least see why this progression doesn't give me a whole lot of confidence?
I'm sorry, but 99.99% of legitimate mail is not forwarded anymore.
87% of all statistics are made up on the spot. your "99.99%" figure up there does not belong in the remaining 13%.
all you're basically saying is that you don't forward any of your mail, and you're too arrogant to give a good goddamn about anybody who does, so screw 'em. only you don't seem to have the balls to come right out and say that, so you make up statistics to lend some make-believe credence to your prejudices.
i forward quite a lot of my mail. if any better options were available to me, i'd use them. none of the options actually are any better than forwarding, though, so any "solution" that breaks forwarding is not going to get my time of day.
there - you've publicized your arrogance on slashdot, and i have publicized mine. i maintain that my dick is bigger than yours, therefore i win. what say you?
All the languages mentioned in the article are just as "stack-based" as C and Java (with the possible exceptions of prolog and haskell, depending on your definition.)
there are stack-based (and RxRS-compliant) Scheme implementations out there? i thought it was tricky at best to implement continuations in a stack-based system, don't you have to allocate them on the heap? (or have i just proven how clueless i really am about Scheme compiler design...?)
Any compiled language by definition can't create functions on the fly
i wish people would learn LISP before claiming LISP is impossible.
the trick is to have a runtime system that includes a parser and compiler for your language; it can then compile any newly created functions on the fly for you. it's not as grotty as it sounds - we've got several decades of experience with it already, most of the bugs got ironed out back fifteen years ago or so.
of course, an alternative method is to not have your language be compiled, or be at most bytecode-compiled; interpreters and byte-code compilers are often a bit lighter-weight than a "full" native-language compiler, so don't burden you with quite as large a runtime library. whether the gain is worth it is a bit debatable, though.
Hopper thought she was making the language more "natural" by giving it a pseudo-English syntax. What didn't occur to her that real English is much more complicated and ambiguous than any computer language
in all fairness, that probably wasn't nearly so obvious to people back than (what was it, forty or fifty years ago now?) as it is to us today. the sample she had to judge from was machine code, probably assembly, maybe FORTRAN, and not a whole lot else, after all.
even so, the more i learn about COBOL, the more certain i am that the good admiral is probably still in purgatory for it. let's hope the language will finally up and die sometime soon.
yeah, but this works much better in SQL than in Cobol. probably because SQL is declarative; Cobol tries to use the same broken look-like-english concept to describe procedures, and that just goes straight to hell in a handbasket.
besides, SQL doesn't have the needs for abstraction that Turing-complete programming languages do; that lets it completely avoid several other ways in which Cobol screws the pooch. most of scoping, for example. or anything to help you do procedural abstraction. and nobody can claim SQL's grammar is anywhere nearly as badly FUBAR as Cobol's, not while sober they can't. and...
(i'm taking a mandatory Cobol class this semester; does it show?)
what's wrong with OO, for me, is that it doesn't read and write Visio files. Visio gets used quite a lot in the classes i'm currently taking, and it's a surprisingly good vector graphics package; it certainly beats the stuffing out of OOo Draw. i'd still love to dump it, if only so i wouldn't have to keep rebooting into win2k to run MSOffice, but i can't just ignore my instructors' charts - or turn in certain assignments without good charts of my own - so Visio on 'doze it is.
i've heard rumors that sibelius' base engine is written in ASM and could be easily ported to linux from OS X.
surely you must mean to say you've heard two different rumors there.
music notation programs don't seem like trivial exercises[*]; if one (or even the engine of one) were written in assembly, you'd very likely have a behemoth of an assembly language program. such a thing would not be easy to port between operating systems, even operating systems on the same hardware platform - i wouldn't want to think about porting one across both hardware and OS lines.
OTOH, the core engine of a music scorer doesn't seem like it would need to be any inherently platform-dependent beast. i bet it probably could be written very portably if someone wanted to do so - just not in assembly.
[*] by my own personal standard for determining triviality in programming - how many teenage geeks just learning to program write one for fun. ergo: IRC clients are very trivial indeed, ICQ clients are not much less so, but RDBMSs are likely even harder than OS kernels.
i thought the usual punishment for confusing rifles and guns was to get the privilege of cleaning out every gun on base with a cleaning kit made for rifles...
no, the prereqs installed fine, i'm on to the main VS install. it goes along for a while, then complains it can't find certain DLLs on the install CD and asks me to check it out.
the DLLs are on the CD, just not in the directory the installer goes looking for them - and, naturally, it won't let me tell it to look elsewhere. argh! plus, this is an academic edition install, using CDs that probably hundreds of people have used before me; the division computer expert hasn't heard of any of them getting this problem.
what i'm gonna do is copy the whole thing to harddisk, then move the files around as needed every time it complains - since, luckily, the complaint dialog boxes all seem to have "retry" buttons. they don't all have "ignore" buttons, only some of them do, at some point i get stuck having to cancel and roll back the whole install... for no reason i can think of.
over ten years of using it, i cannot remember linux ever doing such a thing to me. not once.
[...] f*cked up OEM version of WinXP that gets shipped with Compaq boxen these days. What it means is that after installing Linux, any time you opt to boot into Windows (to export contacts from Exchange ready for Evolution fer instance) it spots that the MBR has been altered by the bootloader and initiates the 'Recovery for Morons' mode [...]
LILO on a floppy.
floppy in, boots to linux; floppy out, boots to XP. XP never even knows LILO or Linux is there. keep a couple extra copies of the magical LILO boot floppy just in case, and keep 'em all write protected of course. not really any slower on bootup, since all that's on the floppy is LILO itself; kernel, initrd and so on get loaded from the root fs just like in a normal install.
learned this when my wife got an XP box (a HP OEM machine, as it happens, they're not much less FUBAR than what you're describing as it turns out) and i didn't dare mess with her MBR lest i bring down the wrath of you-broke-my-brand-new-windows-you-brute on my head. has worked fine ever since - that floppy is constantly in the drive, just ejected if she wants to go to XP. she never uses the floppy drive for anything else anyway, so this way at least it's good for something.
'course, i've been too lazy to make any spare copies of the disk (though i know i should). so if the floppy ever dies on me, i'll boot from the mandrake CD and use its rescue mode to LILO another one.
you're running one distribution of linux. doesn't much matter which one, because they each have their own one method of (un)installing stuff. these methods tend to work just fine, in my experience - it's been years since Mandrake gave me the sort of headaches i've currently got trying to install Visual Studio.NET on Windows 2000 server, for instance. (no, you don't want to know...) stick to packages made for your one distro, and using its one method of installing, and things'll go fine. step over that line, and it'll be just as hard as trying to run random windows 3.11 software on 2000 Professional can at times be... it might work, or it might not.
uninstalling, see above - if anything, this tends to work better on linux, because most uninstalls don't tend to leave junk files behind undeleted.
no need for virus software - well, i've certainly not needed any so far, have you...?
one place two methods. regedt and regedt32. and i dare you to claim those random-gibberish alphabet-soup registry keys make more sense than pick-a-file-from-/etc-at-random; sure, there's jillions of them, but at least they tend to be in something vaguely resembling english. hey, a lot of them even have their own man pages. man pages may suck, but how many registry keys have even that much?
simple upgrade to 2.6: wait until the distribution you prefer puts out a new version that's based off 2.6 by default, upgrade to that using the distribution's preferred upgrade method. simple. if you want it now now now, things'll get trickier, that's true. so's running Longhorn, so what?
in linux, to do some advanced things, i need to be at least experienced - i won't call myself an expert, because i know how much i still have left to learn. but in windows, sometimes you try to do something simple and the experts get baffled at what happens. my own local friendly windows sysadmin type has never heard of the problem i'm having installing Visual Studio (see above) and can't give me any better advice than what i already thought of myself - which will be, copy the install CD to hard disk and try to fix it manually from there while the install is in progress. neither of us have the slightest clue why it is i'm having inexplicable problems. whereas, in my experience, a Linux expert will usually be able to answer at least that last question if not any other.
Slashdot Mirror
take a look at this language comparison, and of course the (flawed, but still not worthless) great shootout. or just google for "optimization" on comp.lang.lisp.
i've heard loads of people saying this, but i've never seen anybody explain why this is necessarily so. what, precisely, about statically typed languages makes it easier to optimize them when compiling them to bytecode, in particular?
and what's so different about bytecode (as opposed to native code) that we can't optimize dynamic languages when compiling them to bytecode, even though we have been able to optimize dynamic languages when compiling them to native code for decades already? i don't get it.
Lisp is dynamic and fast, because lisp is natively compiled. C# is compiled (maybe JIT-compiled, but that counts) to something reasonably fast, even though it's static. Java's just a fucking mess, and what Python needs is a good native compiler - a JIT-compiler would do.
i'm not sure what crack you're smoking that makes you not like Python's OO syntax. it makes a helluva lot more sense to me than, say, Java's.
having to install software by means of source tarball and bunch of patches makes it that much harder to integrate with your favourite package management system. (rpm, apt, whathaveyou. maybe the gentoo users have something like a solution to this - does emerge track what it installs where and when, like RPM does? i sure hope so!)
this matters to those of us who use one machine to do more than one thing, because tracking which files belong to which package installed at what date gets painful when you have a lot of packages all installed by tarball plus patches, especially if it's done over a long span of time or by more than one person. you want to keep track of that, because otherwise you can't ever be really sure some random file is needed; that the new tarball you just did "make install" on didn't trample some file in /usr/etc or wherever that another tarball needed not to have trampled; or that "make uninstall" won't wipe out a .so you'll need the next time the server must be rebooted. package managers track all that metadata for you and make handling a multi-use server or workstation a lot easier, because they give you one single place to go to for finding it all.
sure, you can build your own source RPM to do this for you. it is possible to maintain your own .spec files for insert-random-number of packages you want to use whose maintainers would like for you to install by tarball instead. but unless doing that and that alone are all your job duties, you'll probably just download postfix in the vendor-provided RPMs instead and forget about it, because that very same server has all these other software packages that won't maintain themselves, either, and your life is just too short.
the only real quirks are that postfix uses about a dozen different files for different purposes / subsystems in the herd of daemons that make it up, and that a few of 'em have to be "byte-compiled" into berkeleyDB format to improve access speed before the daemons proper will read 'em. getting used to these is no harder than getting used to djb's, shall we generously call it, unusual mindset on what makes a config file good.
and, frankly, several of djb's config files look a lot more like sendmail.cf to me than any of postfix's ones. it's the same machine-readability-über-alles principle in 'em both, if you ask me. postfix generally doesn't play that mindgame on you, certainly not nearly as much.
i don't think the situation is all that analogous with DNS servers, though. sendmail is and always was an unbelievable mess to set up and maintain; the mere fact that a bunch of m4 macros was considered an improvement on the config system that preceded them should tell you something. (if it doesn't, you haven't had much exposure to m4. count that a blessing and keep away from the thing.)
by comparison, BIND versions >= 8 are simple, straightforward and eminently sensible both to configure and to keep running. as well, BIND's had its share of security problems, but nothing has nearly as awful a security track record as sendmail, not by a long shot.
finally, the cricket book is about half the size of the bat book, maybe less. i don't know about you, but that tells me BIND is a smaller, easier to learn system than sendmail.
that speed can't just disappear. you can point at the sun and fire, but when you fire, you'd still be going sideways at those 30 klicks per sec. after you fired, you'd also be going forward at some other speed - whatever your engine gave you - but the sideways speed'd still be there.
your forward speed would be getting you closer to the sun, at least at first, but unless it was absolutely insanely huge a forward speed, it wouldn't be enough - the sideways speed would still make you miss the sun. you'd still be orbiting it, just more elliptically than before you lit your candle.
the way to break orbit is to eliminate that original, orbital velocity you started out with. just "point at the sun and shoot" isn't the best way of doing this. you want to point sideways to the sun, in the opposite direction from where you're already heading, and shoot.
this is completely true, and it applies to every single thing we ever do or can do. however, it is not relevant to the debate at hand, precisely because it is universally applicable.
the only way this argument would matter would be if there was something magically special about nuclear power that set it apart from every other remotely dangerous thing we do or might do. for example, if there was no way to control, mitigate and manage the risks inherent in it, like we manage the risks involved in every other undertaking; or, for another, if the risks inherent in nuclear power were somehow magically different from the risks we take in other undertakings, not just in magnitude but in kind, such that we couldn't use the same decision tree on it as we do on other risky things.
yes, there are risks in nuclear power. yes, it is possible to screw it up. but so too are there risks in anything else that's worth doing - would you like us to just stay huddled under our blankets for fear of stubbing our toes? every other risk we mitigate as best we can, and then we make a value judgement as to whether or not the benefit is worth the marginal risk remaining. are you trying to claim that this method doesn't work when dealing with nuclear power, for some reason?
or are you claiming to have a good argument - supported by objective evidence - that the benefit of nuclear power, even after you figure in the best job we can do at managing and mitigating its inherent risks, is not at the end of the day worth the marginal risk remaining? i would like to see that argument and its evidence, if so. most people who try to claim this last just make blatant assertions without backing their judgement up with anything.
nope, grandparent is right.
think of it this way: if you could ignore the gravity of the sun, then cancelling out the earth's orbital velocity would leave you stationary in space. you'd be sitting where the earth was when you fired your rocket, and one year later you'd get hit head-on by the planet at a godawful speed.
since you can't ignore the sun's gravity, you'd actually end up accelerating towards the sun at whatever rate the sun exerts out here; some time after you finished your engine burn, you'd hit the star head-on at an even more mindboggling speed. (well, technically we're already accelerating towards the sun that way, that's what keeps the planet's orbit curved into an ellipse... but ignore that for now, we don't want to get that egg-headed.)
if you cancelled out only part of the earth's orbital velocity, you'd go into a more-or-less elliptical orbit around the sun. if it was elliptical enough, you might get dragged in due to to aerodynamic drag by the outer parts of the corona, but it'd take a while.
i don't have a back yard, so no. however, if i had to choose between storing the nuclear waste a gigawatt plant puts out in a year on my property and storing the waste put out by a gigawatt fossil-burning plant over the same year in the same place, i'd pick the nuclear waste in a red-hot second. there'd be a lot less of it, even after you figure in the shielding and protection the stuff'd need.
plus, the low-level waste would be decayed down to safe levels in my lifetime, at which point i could start looking into finding some way to maybe recycle at least part of it somehow. i'd just love to see you find any use for most of what comes out of a coal-burner's backside, ever. CO2, mercury and sulfur don't sell for very much these days.
you are one of:
- male and homosexual;
- female and heterosexual; or,
- just plain beyond all help.
HTH. HAND.that's because you live under a government that can actually be trusted.
i didn't use to understand americans either, then i moved here. now i'm amazed they aren't even more paranoid and distrustful of the corrupt egomaniacal idiots they've got running the place. of course, their paranoia and fear don't actually do anything to help the situation, but at least i can understand the impulse.
so, you set up SPF to fix the problem with SMTP; and you set up SRS to fix the problem with SPF; and now you're telling me to set up something called SES to fix the problem with SRS ...
can you at least see why this progression doesn't give me a whole lot of confidence?
all you're basically saying is that you don't forward any of your mail, and you're too arrogant to give a good goddamn about anybody who does, so screw 'em. only you don't seem to have the balls to come right out and say that, so you make up statistics to lend some make-believe credence to your prejudices.
i forward quite a lot of my mail. if any better options were available to me, i'd use them. none of the options actually are any better than forwarding, though, so any "solution" that breaks forwarding is not going to get my time of day.
there - you've publicized your arrogance on slashdot, and i have publicized mine. i maintain that my dick is bigger than yours, therefore i win. what say you?
there are stack-based (and RxRS-compliant) Scheme implementations out there? i thought it was tricky at best to implement continuations in a stack-based system, don't you have to allocate them on the heap? (or have i just proven how clueless i really am about Scheme compiler design...?)
i wish people would learn LISP before claiming LISP is impossible.
the trick is to have a runtime system that includes a parser and compiler for your language; it can then compile any newly created functions on the fly for you. it's not as grotty as it sounds - we've got several decades of experience with it already, most of the bugs got ironed out back fifteen years ago or so.
of course, an alternative method is to not have your language be compiled, or be at most bytecode-compiled; interpreters and byte-code compilers are often a bit lighter-weight than a "full" native-language compiler, so don't burden you with quite as large a runtime library. whether the gain is worth it is a bit debatable, though.
in all fairness, that probably wasn't nearly so obvious to people back than (what was it, forty or fifty years ago now?) as it is to us today. the sample she had to judge from was machine code, probably assembly, maybe FORTRAN, and not a whole lot else, after all.
even so, the more i learn about COBOL, the more certain i am that the good admiral is probably still in purgatory for it. let's hope the language will finally up and die sometime soon.
besides, SQL doesn't have the needs for abstraction that Turing-complete programming languages do; that lets it completely avoid several other ways in which Cobol screws the pooch. most of scoping, for example. or anything to help you do procedural abstraction. and nobody can claim SQL's grammar is anywhere nearly as badly FUBAR as Cobol's, not while sober they can't. and...
(i'm taking a mandatory Cobol class this semester; does it show?)
what's wrong with OO, for me, is that it doesn't read and write Visio files. Visio gets used quite a lot in the classes i'm currently taking, and it's a surprisingly good vector graphics package; it certainly beats the stuffing out of OOo Draw. i'd still love to dump it, if only so i wouldn't have to keep rebooting into win2k to run MSOffice, but i can't just ignore my instructors' charts - or turn in certain assignments without good charts of my own - so Visio on 'doze it is.
surely you must mean to say you've heard two different rumors there.
music notation programs don't seem like trivial exercises[*]; if one (or even the engine of one) were written in assembly, you'd very likely have a behemoth of an assembly language program. such a thing would not be easy to port between operating systems, even operating systems on the same hardware platform - i wouldn't want to think about porting one across both hardware and OS lines.
OTOH, the core engine of a music scorer doesn't seem like it would need to be any inherently platform-dependent beast. i bet it probably could be written very portably if someone wanted to do so - just not in assembly.
[*] by my own personal standard for determining triviality in programming - how many teenage geeks just learning to program write one for fun. ergo: IRC clients are very trivial indeed, ICQ clients are not much less so, but RDBMSs are likely even harder than OS kernels.
i think that might be more a feature than a bug, actually.
i thought the usual punishment for confusing rifles and guns was to get the privilege of cleaning out every gun on base with a cleaning kit made for rifles...
the DLLs are on the CD, just not in the directory the installer goes looking for them - and, naturally, it won't let me tell it to look elsewhere. argh! plus, this is an academic edition install, using CDs that probably hundreds of people have used before me; the division computer expert hasn't heard of any of them getting this problem.
what i'm gonna do is copy the whole thing to harddisk, then move the files around as needed every time it complains - since, luckily, the complaint dialog boxes all seem to have "retry" buttons. they don't all have "ignore" buttons, only some of them do, at some point i get stuck having to cancel and roll back the whole install... for no reason i can think of.
over ten years of using it, i cannot remember linux ever doing such a thing to me. not once.
LILO on a floppy.
floppy in, boots to linux; floppy out, boots to XP. XP never even knows LILO or Linux is there. keep a couple extra copies of the magical LILO boot floppy just in case, and keep 'em all write protected of course. not really any slower on bootup, since all that's on the floppy is LILO itself; kernel, initrd and so on get loaded from the root fs just like in a normal install.
learned this when my wife got an XP box (a HP OEM machine, as it happens, they're not much less FUBAR than what you're describing as it turns out) and i didn't dare mess with her MBR lest i bring down the wrath of you-broke-my-brand-new-windows-you-brute on my head. has worked fine ever since - that floppy is constantly in the drive, just ejected if she wants to go to XP. she never uses the floppy drive for anything else anyway, so this way at least it's good for something.
'course, i've been too lazy to make any spare copies of the disk (though i know i should). so if the floppy ever dies on me, i'll boot from the mandrake CD and use its rescue mode to LILO another one.