Wow, what an amazing story! Except that is very possible in basically any dynamic language worth half of two shits. In fact, I did exactly the same thing in a Perl IRC bot about two months ago; well, almost exactly the same. The difference is that in Perl we call a dict a hash. (Don't worry, Forth programmers will understand you just fine.)
Anyway, all command handlers and message handlers were separated into two hashes, %CmdHandlers and %MsgHandlers, which could be reloaded on the fly. I even got away with keying the command handlers by their command code, so I could do something like $CmdHandlers{$cmd_code}->($message) and it Just Worked.
I see so much "...and I never could have done it without Python!!" stuff that is 100% available in Perl, Ruby, JavaScript, Lua, Smalltalk, Lisp... Think of that. You're psyched over something that you could do on a mainframe 40 years ago, and you're willing to chalk it all up to Guido!
Ada, though revolting, is a good (enough) language to teach many software design concepts. Its fascist strong typing, encapsulation, interface vs. implementation separation, and perverse verbosity are a great introduction to a life as a replaceable Java programmer.
Lisp, on the other hand, teaches not the concept of software design, but of language design and computation itself. Limitations of syntax disappear. All software design patterns are equally possible, yet not forced upon the programmer. Lisp isn't the most practical language around, but its consistency and possibility can make a programmer consider other languages in much more detail. The whole "code == data" concept is worth the price of admission alone.
Fortran is relevant today mainly because mathematicians and physicists have spent the last 20 years not wanting to rewrite the code they wrote for the 20 years before that. From a software design or computation theory standpoint, Fortran is useless in the 21st Century. (The only remotely palatable bits of modern Fortran come from other languages anyway.)
Allow me to pre-emptively affirm every other Unix GUI choice I didn't mention. GNOME and KDE are the kings, everyone knows it, and other Unix GUIs are hardly worth mentioning in comparison.
(WMaker is my favorite X wm, fwiw. In general, I don't like a desktop GUI on X.)
Mac OS X is the success of Unix on the desktop, period.
There are a lot of geeks who are reluctant to admit it, though. Most people pinned their hope on Linux + GNOME/KDE for delivering us from evil. While GNOME and KDE brought Unix miles ahead in terms of GUI usability, neither matched the elegance and power of the NeXTSTEP interface developed years before; the evolution from NeXTSTEP to OS X has further secured this lead.
The defeat of their favorite candidate for Unix GUI Savior left many geeks unwilling to even consider or support the idea of OS X as a real Unix, as an improvement to Windows or existing Unix GUIs, etc. Sour grapes, basically. The whole experiment goes to show that in software, as in government, in the ideal case you want a well-backed tyrant with his head screwed on straight. That's Steve Jobs.
The "Waiting in line for the big-box store to open for the day so I can maybe snag a Wii" seems to be a popular title this year. No supply shortages either.
That wasn't me, above. I know what dithering is, and it's great, but all it does is swap one kind of noise (periodic stuff, like sampling and quantization error) for another (non-periodic noise) which we as humans don't care about quite as much. It's not a magic bullet. It will not magically make 16 bits able to hold the information of 24. It just makes those 16 bits sound better.
Once, when my band was recording to a digital medium (a RADAR 24-track hard disk recorder, for those keeping score), we captured some tracks at 16bit, and some at 24bit. All other parameters in the signal chain were held constant.
I did not expect to hear as big a difference as I did. 24b absolutely crushed 16b in the oh-so-unscientific terms of listening enjoyment. Everything, especially the cymbals, sounded clearer, less harsh and brittle, more defined. We had to throw away some good 16b takes because they sounded so much worse than the 24b recordings.
Don't be so quick to discount the difference that a little extra dynamic range can make. Sure, you might not notice when you're listening to your iPod in your 89 Chevy Cavalier with the burned out left rear speaker, but it's not as hard to tell as you might think.
Nyquist's theorem states that a wave of frequency f must be sampled at the rate of at least 2f in order for information not to be lost. So, yes, a 44.1kHz sampling rate can accurately reproduce signals up to 22kHz without loss of information, and since that's all we can hear, we should be fine. Right?
Well, not entirely. You see, if the source material contains frequencies above 22.05kHz, they will end up "aliased" onto another part of the frequency spectrum. In short, the extra high-end becomes noise. Information is lost.
Here is the important part, in practical terms. In order to prevent aliasing, the source material must be low-passed to remove the unrepresentable high frequencies. Low-pass filters are not perfect; in order to toss out the frequencies we don't want, we end up attenuating some of the frequencies we do want. Thus it is not uncommon for high-frequency rolloff to begin in the mid-teens of kilohertz, even though we're aiming for 22kHz as the corner frequency.
This causes a real, human-audible difference in the finished product, and it is practically impossible to avoid.
Now, with a 96kHz sample rate, we aim to squash all frequencies above 48kHz, and our non-ideal low-pass filter starts to work in the 30kHz range. The imperfections in the low-pass filter are only apparent at frequencies humans can't hear. The finished audio ends up sounding like the source material, with no human-detectable loss in fidelity.
And it made me recall earning detention in 4th grade by putting the Apple//e I was working on into graphics mode. Didn't matter that I'd finished my work (some BASIC program, probably about ten lines) about 40min early...
Spoken like someone who's never had to use it. Here's a sample application:
Spend a few days writing a discrete wavelet transform algorithm and grapher in C,
OR
Wire three LabVIEW modules together in two minutes, then drink beer until your mom starts crying.
Re:Perl 6: The Language of the Future (... Forever
on
State of the Onion 11
·
· Score: 1
No, you need to know the whole language to reliably know that you can work with anyone else who also "knows Perl". Having two or more people who can apparently know the same language and yet be unable to effectively work with each other's code can only be a bad thing.
Where do people get the idea that a programmer should be able to work on code -- professionally -- without learning the damn language? And that if this condition is not met, it's the language's fault?
You say that as if that's a good thing. Perl prides itself so much on "there's more than one way to do it", why is it apparently so closed to the idea that some of those ways might mean using another language.
This is not lost on the designers of Perl 6. One of the design goals of Parrot (the bytecode backend to Perl 6) is that it should be able to support many dynamic languages (including Python, Ruby, JavaScript, etc) and that it should be easy to share data and code among them. So for those cases when using another language is the right call, Parrot is on the scene. (Or will be. Someday. Hopefully.)
Instead of trying to be all things to all men and getting an abhorration of a language, why not accept that Perl is not, and never will be, the One True Language and that multiple languages is the appropriate and practical way to express multiple programming paradigms.
That is worse-is-better thinking, and like it or not, Perl 6 is an attempt at a better-is-better language. (It sounds so much more eloquent when Larry Wall says it.)
Re:Perl 6: The Language of the Future (... Forever
on
State of the Onion 11
·
· Score: 1
You need to know the whole of the language to use it with someone who knows, and uses, the whole of the language. This is to be expected. However, if you are in your boxer shorts and you just want to pump out a short file-diddling script before bedtime, no one is going to tell you that it can't look like C.
Perl will let you approach a problem however you want. Imperative, functional, OO programming all works out of the box; constraint, logic, aspect programming are possible. This liberates many programmers, and intimidates many others.
Re:Perl 6: The Language of the Future (... Forever
on
State of the Onion 11
·
· Score: 1, Insightful
Or, conversely, you could blame yourself for not knowing the language you're trying to work on, rather than blaming your colleague for knowing it.
I'm not saying that ugly Perl doesn't exist, because it sure as hell does. Perl does not enforce any coding standards at all on its programmers, so undisciplined coders will write undisciplined code, but I'd rather be in Perl's side of the enforcement continuum than, say, Java's or Python's side.
Re:Yup... and he doesn't apologize for it
on
State of the Onion 11
·
· Score: -1, Flamebait
Like I said elsewhere, if you can't keep your head afloat in choppy waters, you're free to use whichever kiddie-pool language you want. You can shit out your ten-minute Rails apps to your heart's content, and I shall continue to write concise, higher-order Perl which will fuck you and leave you in an alley.
Slashdot Mirror
did you really need to ask?
Yes, and procmail still sucks.
In the 21st Century, procmail syntax just doesn't cut it anymore. It's just like Sendmail... works great, but a complete bear to configure.
Wow, what an amazing story! Except that is very possible in basically any dynamic language worth half of two shits. In fact, I did exactly the same thing in a Perl IRC bot about two months ago; well, almost exactly the same. The difference is that in Perl we call a dict a hash. (Don't worry, Forth programmers will understand you just fine.)
Anyway, all command handlers and message handlers were separated into two hashes, %CmdHandlers and %MsgHandlers, which could be reloaded on the fly. I even got away with keying the command handlers by their command code, so I could do something like $CmdHandlers{$cmd_code}->($message) and it Just Worked.
I see so much "...and I never could have done it without Python!!" stuff that is 100% available in Perl, Ruby, JavaScript, Lua, Smalltalk, Lisp... Think of that. You're psyched over something that you could do on a mainframe 40 years ago, and you're willing to chalk it all up to Guido!
It leads me to wonder if Perl will be 2020's COBOL. No one likes to break running code...
as is every fucking variable, subroutine name, and pun in every Python program, site and text
Ada, though revolting, is a good (enough) language to teach many software design concepts. Its fascist strong typing, encapsulation, interface vs. implementation separation, and perverse verbosity are a great introduction to a life as a replaceable Java programmer.
Lisp, on the other hand, teaches not the concept of software design, but of language design and computation itself. Limitations of syntax disappear. All software design patterns are equally possible, yet not forced upon the programmer. Lisp isn't the most practical language around, but its consistency and possibility can make a programmer consider other languages in much more detail. The whole "code == data" concept is worth the price of admission alone.
Fortran is relevant today mainly because mathematicians and physicists have spent the last 20 years not wanting to rewrite the code they wrote for the 20 years before that. From a software design or computation theory standpoint, Fortran is useless in the 21st Century. (The only remotely palatable bits of modern Fortran come from other languages anyway.)
A well-played D&D campaign is just one house rule after another.
Will your next version support DirectX?
Allow me to pre-emptively affirm every other Unix GUI choice I didn't mention. GNOME and KDE are the kings, everyone knows it, and other Unix GUIs are hardly worth mentioning in comparison.
(WMaker is my favorite X wm, fwiw. In general, I don't like a desktop GUI on X.)
Mac OS X is the success of Unix on the desktop, period.
There are a lot of geeks who are reluctant to admit it, though. Most people pinned their hope on Linux + GNOME/KDE for delivering us from evil. While GNOME and KDE brought Unix miles ahead in terms of GUI usability, neither matched the elegance and power of the NeXTSTEP interface developed years before; the evolution from NeXTSTEP to OS X has further secured this lead.
The defeat of their favorite candidate for Unix GUI Savior left many geeks unwilling to even consider or support the idea of OS X as a real Unix, as an improvement to Windows or existing Unix GUIs, etc. Sour grapes, basically. The whole experiment goes to show that in software, as in government, in the ideal case you want a well-backed tyrant with his head screwed on straight. That's Steve Jobs.
The "Waiting in line for the big-box store to open for the day so I can maybe snag a Wii" seems to be a popular title this year. No supply shortages either.
Next you'll be complaining when I say that 4.4 > 5.4.
Anyway, the formal version number is 5.010_000.
Lisp includes a version of the lambda calculus, but pure lambda calculus is about as useful as a Turing machine.
That wasn't me, above. I know what dithering is, and it's great, but all it does is swap one kind of noise (periodic stuff, like sampling and quantization error) for another (non-periodic noise) which we as humans don't care about quite as much. It's not a magic bullet. It will not magically make 16 bits able to hold the information of 24. It just makes those 16 bits sound better.
Once, when my band was recording to a digital medium (a RADAR 24-track hard disk recorder, for those keeping score), we captured some tracks at 16bit, and some at 24bit. All other parameters in the signal chain were held constant.
I did not expect to hear as big a difference as I did. 24b absolutely crushed 16b in the oh-so-unscientific terms of listening enjoyment. Everything, especially the cymbals, sounded clearer, less harsh and brittle, more defined. We had to throw away some good 16b takes because they sounded so much worse than the 24b recordings.
Don't be so quick to discount the difference that a little extra dynamic range can make. Sure, you might not notice when you're listening to your iPod in your 89 Chevy Cavalier with the burned out left rear speaker, but it's not as hard to tell as you might think.
You're hearing the horizontal scan, which is usually around 15kHz -- quite high, within an octave of our upper limit.
Nyquist's theorem states that a wave of frequency f must be sampled at the rate of at least 2f in order for information not to be lost. So, yes, a 44.1kHz sampling rate can accurately reproduce signals up to 22kHz without loss of information, and since that's all we can hear, we should be fine. Right?
Well, not entirely. You see, if the source material contains frequencies above 22.05kHz, they will end up "aliased" onto another part of the frequency spectrum. In short, the extra high-end becomes noise. Information is lost.
Here is the important part, in practical terms. In order to prevent aliasing, the source material must be low-passed to remove the unrepresentable high frequencies. Low-pass filters are not perfect; in order to toss out the frequencies we don't want, we end up attenuating some of the frequencies we do want. Thus it is not uncommon for high-frequency rolloff to begin in the mid-teens of kilohertz, even though we're aiming for 22kHz as the corner frequency.
This causes a real, human-audible difference in the finished product, and it is practically impossible to avoid.
Now, with a 96kHz sample rate, we aim to squash all frequencies above 48kHz, and our non-ideal low-pass filter starts to work in the 30kHz range. The imperfections in the low-pass filter are only apparent at frequencies humans can't hear. The finished audio ends up sounding like the source material, with no human-detectable loss in fidelity.
This is why 96kHz is a good idea.
No, I'd say the phrase "natural language" is just about perfect at describing what natural language is.
Nothing for you to see here. Please move along.
And it made me recall earning detention in 4th grade by putting the Apple //e I was working on into graphics mode. Didn't matter that I'd finished my work (some BASIC program, probably about ten lines) about 40min early...
Spoken like someone who's never had to use it. Here's a sample application:
Spend a few days writing a discrete wavelet transform algorithm and grapher in C,
OR
Wire three LabVIEW modules together in two minutes, then drink beer until your mom starts crying.
No, you need to know the whole language to reliably know that you can work with anyone else who also "knows Perl". Having two or more people who can apparently know the same language and yet be unable to effectively work with each other's code can only be a bad thing.
Where do people get the idea that a programmer should be able to work on code -- professionally -- without learning the damn language? And that if this condition is not met, it's the language's fault?
You say that as if that's a good thing. Perl prides itself so much on "there's more than one way to do it", why is it apparently so closed to the idea that some of those ways might mean using another language.
This is not lost on the designers of Perl 6. One of the design goals of Parrot (the bytecode backend to Perl 6) is that it should be able to support many dynamic languages (including Python, Ruby, JavaScript, etc) and that it should be easy to share data and code among them. So for those cases when using another language is the right call, Parrot is on the scene. (Or will be. Someday. Hopefully.)
Instead of trying to be all things to all men and getting an abhorration of a language, why not accept that Perl is not, and never will be, the One True Language and that multiple languages is the appropriate and practical way to express multiple programming paradigms.
That is worse-is-better thinking, and like it or not, Perl 6 is an attempt at a better-is-better language. (It sounds so much more eloquent when Larry Wall says it.)
You need to know the whole of the language to use it with someone who knows, and uses, the whole of the language. This is to be expected. However, if you are in your boxer shorts and you just want to pump out a short file-diddling script before bedtime, no one is going to tell you that it can't look like C.
Perl will let you approach a problem however you want. Imperative, functional, OO programming all works out of the box; constraint, logic, aspect programming are possible. This liberates many programmers, and intimidates many others.
Or, conversely, you could blame yourself for not knowing the language you're trying to work on, rather than blaming your colleague for knowing it.
I'm not saying that ugly Perl doesn't exist, because it sure as hell does. Perl does not enforce any coding standards at all on its programmers, so undisciplined coders will write undisciplined code, but I'd rather be in Perl's side of the enforcement continuum than, say, Java's or Python's side.
Like I said elsewhere, if you can't keep your head afloat in choppy waters, you're free to use whichever kiddie-pool language you want. You can shit out your ten-minute Rails apps to your heart's content, and I shall continue to write concise, higher-order Perl which will fuck you and leave you in an alley.