Okay, I apoligize for an extra long post here, but I still see people mischaracterizing functional programming. So I'm going to take a few excerpts from "Why Functional Programming Matters" by John Hughes. It's a short paper, worth your time if you're new to the functional paradigm.
No Side Effects: Functional programs contain no side-effects at all. A function call can
have no effect other than to compute its result. This eliminates a major source
of bugs, and also makes the order of execution irrelevant - since no side-effect
can change the value of an expression, it can be evaluated at any time. This
relieves the programmer of the burden of prescribing the flow of control. Since
expressions can be evaluated at any time, one can freely replace variables by
their values and vice versa - that is, programs are "referentially transparent".
This freedom helps make functional programs more tractable mathematically
than their conventional counterparts.
Higher Order Functions: Functional languages allow functions which are
indivisible in conventional programming languages to be expressed as a combi-nation
of parts - a general higher order function and some particular specialising
functions. Once defined, such higher order functions allow many operations to
be programmed very easily. Whenever a new datatype is defined higher order
functions should be written for processing it. This makes manipulating the
datatype easy, and also localises knowledge about the details of its represen-tation.
The best analogy with conventional programming is with extensible
languages - it is as though the programming language can be extended with
new control structures whenever desired.
Lazy Evaluation: A complete functional program is
just a function from its input to its output. If f and g are such programs, then
(g . f ) is a program which, when applied to its input, computes g (f input). The program f computes its output which is used as the input to program g.
This might be implemented conventionally by storing the output from f in a
temporary file. The problem with this is that the temporary file might occupy
so much memory that it is impractical to glue the programs together in this way.
Functional languages provide a solution to this problem. The two programs f
and g are run together in strict synchronisation. F is only started once g tries
to read some input, and only runs for long enough to deliver the output g is
trying to read. Then f is suspended and g is run until it tries to read another
input. As an added bonus, if g terminates without reading all of f 's output then
f is aborted. F can even be a non-terminating program, producing an infinite
amount of output, since it will be terminated forcibly as soon as g is finished.
This allows termination conditions to be separated from loop bodies - a powerful
modularisation.
Since this method of evaluation runs f as little as possible, it is called "lazy
evaluation". It makes it practical to modularise a program as a generator which
constructs a large number of possible answers, and a selector which chooses the
appropriate one. While some other systems allow programs to be run together in
this manner, only functional languages use lazy evaluation uniformly for every
function call, allowing any part of a program to be modularised in this way.
Lazy evaluation is perhaps the most powerful tool for modularisation in the
functional programmer's repertoire.
Why you might care: Modularity is the key to successful programming.
Languages which aim to improve productivity must support modular
programming well. But new scope rules and mechanisms for separate compilation
are not enough - modularity means more than modules. Our ability to
decompose a problem into parts depends directly on our ability to glue solutions
together. To assist modular programming, a language must provide good glue.
Functional programming languages provide two new kinds of glue - higher-order
functions and lazy evaluation. Using these glues one can modularise programs
in new and exciting ways... Smaller
and more general modules can be re-used more widely, easing subsequent programming.
This explains why functional programs are so much smaller and
easier to write than conventional ones. It also provides a target for functional
programmers to aim at. If any part of a program is messy or complicated, the
programmer should attempt to modularise it and to generalise the parts. He
should expect to use higher-order functions and lazy evaluation as his tools for
doing this.
Ebooks suck, I do not like them, especially when I'm working on a downed server and have 4 Terminal.app's open, and I have to find a spot for Acrobat to fit.
There are so many good reasons to get a second or third monitor on your desktop. Having an always-open "reference" monitor for google searches, help-files, and e-books is a great idea. While I don't personally know any home users with 3 displays, I've had this type of setup for office purposes on several occasions and it's wonderful. Three 17" monitors helps keep the cost down a lot, but if you can throw at least one 21" into the mix, even better.
Yes, you should compare 80 gigs of HD versus 80 gigs of DRAM. First of all, you'll usually detect any DRAM faults upon your first powerup test (while it's still under warranty and, more importantly, no data has been trusted to it yet). Okay, so down the road now, DRAM really isn't very sensitive to wear-and-tear. It is, but not nearly to the degree of stepping motors, spinning platters, and crashing heads that need cooling and lubrication. And consider this benefit... if a fault is detected on one chip of an 80 gig cluster of DRAM, you can swap one chip, not the whole 80 gigs. (Either way, it'll likely require a power-cycle and data restore from backup though.)
BTW, I know my reasoning doesn't apply at the device driver level, but I'm assuming the Agenda VR3 is losing Linux application developers. Which is sad/surprising.
From the article...
some developers have now switched to other projects such as the Sharp Zaurus
"Switching" from one Linux platform to another? It's a little ironic that part of the demise of this Linux PDA is something that can't/doesn't really happen to Linux on the desktop and is actually something that keeps the community together -- developers don't usually have to pick and choose which distribution/hardware/etc their Linux apps will run on.
I would really appreciate someone who understands the subtle nuances to explain.
Bruce Eckel explains some different approaches to GC, pros and cons, etc., especially as it relates to Java. Check out Thinking In Java 2nd Edition, pp. 207-219. You can download it here.
Dallas Semi makes the TINI, a Java implementation in hardware packaged as a 72-pin SIMM stick. I have one and it's cheap and fun to program. Built-in ethernet, general purpose IO pins, etc.
Nobel himself (in his will, I think) simply stated that prizes be given to those who, during the preceding year, "shall have conferred the greatest benefit on mankind" and that one part be given to the person who "shall have made the most important discovery within the domain of physiology or medicine."
Incidentally, it is correct to refer to Nash as a "Nobel Laureate" for winning his prize, the same as prize winners in Physics Chemistry, Medicine, etc.
think logically about it... The less money they have, the more draconian they become.
This doesn't necessarily follow. Draconian measures are only one possible response to less money (revenues or profits, whichever you were measuring). I nitpick this only because you started your post with the request to "think logically about it", and followed with a chain of assertions containing at least one false one. (Unless you care to prove that all companies must become draconian when they have less money!);-)
Well! Actually, something that tends to run better than a port is a game originally written for that platform to start with! But, baby steps first... and marketing-wise, I do think ports are a good place to start, since the Window version of a game creates buzz, awareness, and desire for a port on the Linux side. Well, in theory it should... Sorry, Loki.
The porting was to create a market, a need for Linux gaming.
OMFG, that philosophy reeks of soul-less corporate product shovelling! "There's not really any current need or market for our products, so we'll try to create one!" Personally, I love Linux for programming, administration, deploy-and-forget Oracle installs, etc., but there's clearly just no desire amongst gamers to switch from Windows.
Re:WMA 8 is the way
on
Non-MP3 Codecs?
·
· Score: 4, Insightful
If you compare a good mp3 encoding... to a WMA8 encoding of the same bit-rate and with the volume levels matched, mp3 will win out
I didn't realize WMA8 was compressing levels, but once levels have been compressed, it won't be possible to "match volume levels" and compare with original source or an MP3 as you suggest. (ie, either loud passages won't match or soft passages won't match)
Can anyone honestly think of any real improvements made to any of these pieces of software since AOL bought them out?
Improving a company isn't always about adding features. Buying a smaller company can be about ensuring R&D funding is there to get through the current (impossible) financing climate for small techs. It can ensure salaries get paid. It can fund marketing efforts. It can find ways to save the company money. Etc.
Notice how a lot of tech companies with neat products that they didn't charge for went out of business? Maybe they would have made it in the long run, but they couldn't keep their burn down long enough to fire up their revenue-producing plans.
I have a question/theory about nonuniform sampling rates. Okay, sticking with a 44kHz sample rate, will you hear the differeces between 8, 16, and 24 bit samples? Yes, of course. It's common in digital audio to use 16 bit samples to save space, not because it's the ultimate sample size. (While it's arguable the 44kHz rate side of the equation is pretty darn good.) It's subjective and some ears don't need any "more" audio information to be happy, but I see the choice of sample size as more of a variable than the "provable" sufficient rate for 20kHz audio cutoff behing 44kHz. All I'm saying is that there is potentially audible information below 20kHz that isn't getting encoded and recreated not because of sample rate, but because of sample size. For example, if my source material didn't "need" 44kHz througout a song, could the sample rate be trimmed back in places while the sample size was increased? In the end, it's all just a stream of x samples per second, y bits deep. So if a new sampling technique allows us to reproportion (optimize) those two dimensionons in the same amount of overall space, it's possible that better audio will result. Thoughts?
can't handle one of those fancy new processors we all want
Well, not all of us. I don't care if my office and high-end gaming machine makes a lot of noise. Some of us want a DVD and MP3 machine in the bedroom or AV room where noise matters and CPU speed doesn't.
That (American) case sucks. Well, maybe it cools effectively, but the distinguishing feature of the Korean case is that it uses no fans or motors. Less moving parts and less noise is a good thing. The American one has 3 freaking fans on the top.
Well, presumably a bit more complicated, as according to the story the airplane had Chinese guards present while it was in the US.
I'll bet you could buy off a guard from China with less cash than a Boeing employee. Throw in an offer to import the guard's family over to Prosperous America(tm), and it's a done deal.
See how fascist governments control the flow of information?
I'll admit to not being up to date on what's going on in China right now, but am I the only one surprised to hear China now labelled as "fascist"? Sure, they've had some serious Communist totalitarianism going on a while back, but when did it shift over to the extreme right-wing?
Whether or not America is fascist is left as an excercise to the paranoid.
Slashdot Mirror
Okay, I apoligize for an extra long post here, but I still see people mischaracterizing functional programming. So I'm going to take a few excerpts from "Why Functional Programming Matters" by John Hughes. It's a short paper, worth your time if you're new to the functional paradigm.
No Side Effects:
Functional programs contain no side-effects at all. A function call can have no effect other than to compute its result. This eliminates a major source of bugs, and also makes the order of execution irrelevant - since no side-effect can change the value of an expression, it can be evaluated at any time. This relieves the programmer of the burden of prescribing the flow of control. Since expressions can be evaluated at any time, one can freely replace variables by their values and vice versa - that is, programs are "referentially transparent". This freedom helps make functional programs more tractable mathematically than their conventional counterparts.
Higher Order Functions:
Functional languages allow functions which are indivisible in conventional programming languages to be expressed as a combi-nation of parts - a general higher order function and some particular specialising functions. Once defined, such higher order functions allow many operations to be programmed very easily. Whenever a new datatype is defined higher order functions should be written for processing it. This makes manipulating the datatype easy, and also localises knowledge about the details of its represen-tation. The best analogy with conventional programming is with extensible languages - it is as though the programming language can be extended with new control structures whenever desired.
Lazy Evaluation:
A complete functional program is just a function from its input to its output. If f and g are such programs, then (g . f ) is a program which, when applied to its input, computes g (f input). The program f computes its output which is used as the input to program g. This might be implemented conventionally by storing the output from f in a temporary file. The problem with this is that the temporary file might occupy so much memory that it is impractical to glue the programs together in this way. Functional languages provide a solution to this problem. The two programs f and g are run together in strict synchronisation. F is only started once g tries to read some input, and only runs for long enough to deliver the output g is trying to read. Then f is suspended and g is run until it tries to read another input. As an added bonus, if g terminates without reading all of f 's output then f is aborted. F can even be a non-terminating program, producing an infinite amount of output, since it will be terminated forcibly as soon as g is finished. This allows termination conditions to be separated from loop bodies - a powerful modularisation. Since this method of evaluation runs f as little as possible, it is called "lazy evaluation". It makes it practical to modularise a program as a generator which constructs a large number of possible answers, and a selector which chooses the appropriate one. While some other systems allow programs to be run together in this manner, only functional languages use lazy evaluation uniformly for every function call, allowing any part of a program to be modularised in this way. Lazy evaluation is perhaps the most powerful tool for modularisation in the functional programmer's repertoire.
Why you might care:
Modularity is the key to successful programming. Languages which aim to improve productivity must support modular programming well. But new scope rules and mechanisms for separate compilation are not enough - modularity means more than modules. Our ability to decompose a problem into parts depends directly on our ability to glue solutions together. To assist modular programming, a language must provide good glue. Functional programming languages provide two new kinds of glue - higher-order functions and lazy evaluation. Using these glues one can modularise programs in new and exciting ways... Smaller and more general modules can be re-used more widely, easing subsequent programming. This explains why functional programs are so much smaller and easier to write than conventional ones. It also provides a target for functional programmers to aim at. If any part of a program is messy or complicated, the programmer should attempt to modularise it and to generalise the parts. He should expect to use higher-order functions and lazy evaluation as his tools for doing this.
Ebooks suck, I do not like them, especially when I'm working on a downed server and have 4 Terminal.app's open, and I have to find a spot for Acrobat to fit.
There are so many good reasons to get a second or third monitor on your desktop. Having an always-open "reference" monitor for google searches, help-files, and e-books is a great idea. While I don't personally know any home users with 3 displays, I've had this type of setup for office purposes on several occasions and it's wonderful. Three 17" monitors helps keep the cost down a lot, but if you can throw at least one 21" into the mix, even better.
Yes, you should compare 80 gigs of HD versus 80 gigs of DRAM. First of all, you'll usually detect any DRAM faults upon your first powerup test (while it's still under warranty and, more importantly, no data has been trusted to it yet). Okay, so down the road now, DRAM really isn't very sensitive to wear-and-tear. It is, but not nearly to the degree of stepping motors, spinning platters, and crashing heads that need cooling and lubrication. And consider this benefit... if a fault is detected on one chip of an 80 gig cluster of DRAM, you can swap one chip, not the whole 80 gigs. (Either way, it'll likely require a power-cycle and data restore from backup though.)
BTW, I know my reasoning doesn't apply at the device driver level, but I'm assuming the Agenda VR3 is losing Linux application developers. Which is sad/surprising.
From the article...
some developers have now switched to other projects such as the Sharp Zaurus
"Switching" from one Linux platform to another? It's a little ironic that part of the demise of this Linux PDA is something that can't/doesn't really happen to Linux on the desktop and is actually something that keeps the community together -- developers don't usually have to pick and choose which distribution/hardware/etc their Linux apps will run on.
I would really appreciate someone who understands the subtle nuances to explain.
Bruce Eckel explains some different approaches to GC, pros and cons, etc., especially as it relates to Java. Check out Thinking In Java 2nd Edition, pp. 207-219. You can download it here.
Dallas Semi makes the TINI, a Java implementation in hardware packaged as a 72-pin SIMM stick. I have one and it's cheap and fun to program. Built-in ethernet, general purpose IO pins, etc.
Go here for more info.
2181. 2181. 2181.
It's not free software.
So? Neither is anything by Microsoft and they have taken over. I'm not saying it's right, but it's true and it ain't free.
Semantically, you're correct, but for more details, people should check out The Official Web Site of The Nobel Foundation...
Nobel himself (in his will, I think) simply stated that prizes be given to those who, during the preceding year, "shall have conferred the greatest benefit on mankind" and that one part be given to the person who "shall have made the most important discovery within the domain of physiology or medicine."
John Nash is mentioned here.
Incidentally, it is correct to refer to Nash as a "Nobel Laureate" for winning his prize, the same as prize winners in Physics Chemistry, Medicine, etc.
think logically about it ... The less money they have, the more draconian they become.
;-)
This doesn't necessarily follow. Draconian measures are only one possible response to less money (revenues or profits, whichever you were measuring). I nitpick this only because you started your post with the request to "think logically about it", and followed with a chain of assertions containing at least one false one. (Unless you care to prove that all companies must become draconian when they have less money!)
However nothing runs better than a pure port
Well! Actually, something that tends to run better than a port is a game originally written for that platform to start with! But, baby steps first... and marketing-wise, I do think ports are a good place to start, since the Window version of a game creates buzz, awareness, and desire for a port on the Linux side. Well, in theory it should... Sorry, Loki.
The porting was to create a market, a need for Linux gaming.
OMFG, that philosophy reeks of soul-less corporate product shovelling! "There's not really any current need or market for our products, so we'll try to create one!" Personally, I love Linux for programming, administration, deploy-and-forget Oracle installs, etc., but there's clearly just no desire amongst gamers to switch from Windows.
If you compare a good mp3 encoding ... to a WMA8 encoding of the same bit-rate and with the volume levels matched, mp3 will win out
I didn't realize WMA8 was compressing levels, but once levels have been compressed, it won't be possible to "match volume levels" and compare with original source or an MP3 as you suggest. (ie, either loud passages won't match or soft passages won't match)
Can't someone submit "prior use"? ;-)
Flag info
"The maple leaf flag was raised for the first time at noon, February 15, 1965 during special ceremonies on Parliament Hill in Ottawa."
Can anyone honestly think of any real improvements made to any of these pieces of software since AOL bought them out?
Improving a company isn't always about adding features. Buying a smaller company can be about ensuring R&D funding is there to get through the current (impossible) financing climate for small techs. It can ensure salaries get paid. It can fund marketing efforts. It can find ways to save the company money. Etc.
Notice how a lot of tech companies with neat products that they didn't charge for went out of business? Maybe they would have made it in the long run, but they couldn't keep their burn down long enough to fire up their revenue-producing plans.
How small will these be in 5 years?
Like every other gadget... small enough to lose in the couch.
It doesn't have that satisfaction of dealing with other people, using them for your own means.
Ahhh yes, the satisfaction of using other people for your own means!
Nah chess is too lonely and quiet for me.
Keep using people for your own means and you'll tasting loneliness soon enough...
I have a question/theory about nonuniform sampling rates. Okay, sticking with a 44kHz sample rate, will you hear the differeces between 8, 16, and 24 bit samples? Yes, of course. It's common in digital audio to use 16 bit samples to save space, not because it's the ultimate sample size. (While it's arguable the 44kHz rate side of the equation is pretty darn good.) It's subjective and some ears don't need any "more" audio information to be happy, but I see the choice of sample size as more of a variable than the "provable" sufficient rate for 20kHz audio cutoff behing 44kHz. All I'm saying is that there is potentially audible information below 20kHz that isn't getting encoded and recreated not because of sample rate, but because of sample size. For example, if my source material didn't "need" 44kHz througout a song, could the sample rate be trimmed back in places while the sample size was increased? In the end, it's all just a stream of x samples per second, y bits deep. So if a new sampling technique allows us to reproportion (optimize) those two dimensionons in the same amount of overall space, it's possible that better audio will result. Thoughts?
You're reading /. and you're conforming to DVD Region Controls? Intruder! Intruder!
can't handle one of those fancy new processors we all want
Well, not all of us. I don't care if my office and high-end gaming machine makes a lot of noise. Some of us want a DVD and MP3 machine in the bedroom or AV room where noise matters and CPU speed doesn't.
That (American) case sucks. Well, maybe it cools effectively, but the distinguishing feature of the Korean case is that it uses no fans or motors. Less moving parts and less noise is a good thing. The American one has 3 freaking fans on the top.
Well, presumably a bit more complicated, as according to the story the airplane had Chinese guards present while it was in the US.
I'll bet you could buy off a guard from China with less cash than a Boeing employee. Throw in an offer to import the guard's family over to Prosperous America(tm), and it's a done deal.
See how fascist governments control the flow of information?
I'll admit to not being up to date on what's going on in China right now, but am I the only one surprised to hear China now labelled as "fascist"? Sure, they've had some serious Communist totalitarianism going on a while back, but when did it shift over to the extreme right-wing?
Whether or not America is fascist is left as an excercise to the paranoid.
IF it's true, it would cost a lot to keep this info from leaking to the plumbers' union, the hotel staff, media, etc. etc. etc.
Heheh, I said "leaking" in a plumbing post. Heheh.