That's not how engineering works. Engineers are always looking for new ways to do things more productively and cheaply. You seem to think that matters of style are analogous to engineering "best practices". But engineering best practices are very simple: design something cheaper to build and maintain than the next guy, and prove that it works.
Actually there is only ONE such way -- does not meet spec. The rest you have mentioned are in a subset of it.
Which does not contradict what I said. You are not as clever as you think.
Ah, a "Systems" programmer. The kind of programmer who missed out on 5,000 years of mathematics before the invention of C, and 40 years of languages converging to the mathematical method since the invention of C.
Re:Clojure's LISP does not enforce abstraction
on
Programming Clojure
·
· Score: 1
In my experience with functional languages, the trouble isn't remembering what you coded, but where you put it. Reading functional programming is really easy. You barely even have to understand the operators, as long as you understand that a (mathematical) function is a certain type of relation (a many-to-one relation). Equivalently, a function is the same as a set of ordered pairs with the property that if (x,y) and (x', y') are in the set, and x = x', then y = y'. Equivalently a (computable) function is a state machine. Etc.
Notice that I put "mathematical" in there. There are plenty of levels of abstraction in a language like Haskell, but the point of them is to let you define (mathematical) functions at various points of the computation cycle: before compile time, at compile time, at run time; or on different "kinds" of objects. As long as you find the two key types at are being joined into a functional relation, you can read the code.
Re:Asynchronous and self modifying code.
on
Programming Clojure
·
· Score: 1
This is the equivalent of saying lamda functions have nothing to do with functional programming.
No it's not. The whole point of functional programming is to maintain referential transparency. It is literally impossible to modify a named value, including functions.
Self-modifying code is what you get when you make your imperative, referentially opaque code modify itself. You CANNOT do that in a pure language. Although purity isn't the gold standard in functional programming, it is a goal functional programmers strive for unless it is absolutely necessary to break that very important (and conceptually clarifying) assumption.
Let's turn your ridiculous car analogy around. Go to a car lot, and tell them you want to buy a red Totoya Prius. Ask them for a test drive. Guess what: they have Priuses on the lot for you to drive. AND IT MIGHT NOT BE RED.
That's not the right kind of "variable bit rate". The kind of VBR you're describing is merely varying the bit rate within a stream for compression efficiency. Hulu dynamically switches between streams at different bit rates, depending on the speed of your connection.
There are three ways in which software can go wrong:
1) Segfaults (or otherwise "crashes") 2) Blows up in time or space (poor algorithm choice, or just plain old necessity. Some problems really do require slow/big algorithms) 3) Doesn't meet spec.
Guess what: any software that doesn't do any of these is right. You don't have to know C to write software that doesn't do these.
There isn't much difference between a logic language and a functional language. The only "real" difference is the evaluation model: logical languages use unification, and functional languages use some kind of beta reduction. Well, unification is what you get if you take a function in extension form (that is, as a set of ordered pairs) and apply beta reduction to this syntactic form.
Functions are proofs. Proofs in a "constructive" logic.
BP will never go bankrupt over this, unless their assets are nationalized. The elasticity of demand completely outstrips the elasticity of supply. Therefore, any fees levied against BP will be paid for by the consumer of their products. Oil is a fungible good, but it is also an oligopoly at this level. Every oil user will pay for BP's spill, even if they avoid BP.
They are lying threw their teeth if they say nothing unusual happened. I watched it on fold on my trading platform and it was like 1/2 the market just turned off while computerized trades relentlessly sold to the nonexistent buy side. In the end its likely that the only people who got hurt by this were retail investors who trade with stop-loss or trailing stop-loss orders.
If they put an order in, they do not have my sympathy. They missed out on an opportunity, but they got what they asked for in order to do it.
How is that anybody's fault but their own? Sales don't happen unless the bid and ask prices match.
This calculation was NOT done by one molecule, it was done by a whole bunch of other stuff that led to that molecule being in the states that it was in.
This is exactly wrong.
Compare this to a drum stick hitting a drum head. Does the drum stick do any calculations? Of course not. The drum head performs a spectral analysis on the result of a strike.
If you're interested, check out "The Elements of Typographic Style" from your local library. Very interesting stuff. I used it as a source when designing a LaTeX style for my senior thesis.
Cauchy sequence is a function from the Naturals into a metric space for which there is "Cauchy convergence": for every epsilon, there is an N such that if m and n are large enough, |f(m) - f(n)| < epsilon. f IS the number to which the sequence converges. f is not an approximation.
Slashdot Mirror
How so?
That's not how engineering works. Engineers are always looking for new ways to do things more productively and cheaply. You seem to think that matters of style are analogous to engineering "best practices". But engineering best practices are very simple: design something cheaper to build and maintain than the next guy, and prove that it works.
Actually there is only ONE such way -- does not meet spec. The rest you have mentioned are in a subset of it.
Which does not contradict what I said. You are not as clever as you think.
Ah, a "Systems" programmer. The kind of programmer who missed out on 5,000 years of mathematics before the invention of C, and 40 years of languages converging to the mathematical method since the invention of C.
In my experience with functional languages, the trouble isn't remembering what you coded, but where you put it. Reading functional programming is really easy. You barely even have to understand the operators, as long as you understand that a (mathematical) function is a certain type of relation (a many-to-one relation). Equivalently, a function is the same as a set of ordered pairs with the property that if (x,y) and (x', y') are in the set, and x = x', then y = y'. Equivalently a (computable) function is a state machine. Etc.
Notice that I put "mathematical" in there. There are plenty of levels of abstraction in a language like Haskell, but the point of them is to let you define (mathematical) functions at various points of the computation cycle: before compile time, at compile time, at run time; or on different "kinds" of objects. As long as you find the two key types at are being joined into a functional relation, you can read the code.
This is the equivalent of saying lamda functions have nothing to do with functional programming.
No it's not. The whole point of functional programming is to maintain referential transparency. It is literally impossible to modify a named value, including functions.
Self-modifying code is what you get when you make your imperative, referentially opaque code modify itself. You CANNOT do that in a pure language. Although purity isn't the gold standard in functional programming, it is a goal functional programmers strive for unless it is absolutely necessary to break that very important (and conceptually clarifying) assumption.
He's Australian.
How big of a USB stick? I've seen 32GB sticks out there...
No, you're clearly talking about ordinals. It's the FIRST post, not "1 post"
Let's turn your ridiculous car analogy around. Go to a car lot, and tell them you want to buy a red Totoya Prius. Ask them for a test drive. Guess what: they have Priuses on the lot for you to drive. AND IT MIGHT NOT BE RED.
Does it matter? No.
Until you show them how to block ads. Then they wonder why they haven't been doing it for years.
That's not the right kind of "variable bit rate". The kind of VBR you're describing is merely varying the bit rate within a stream for compression efficiency. Hulu dynamically switches between streams at different bit rates, depending on the speed of your connection.
There's no such thing as "the free market". There are markets, and each of them is either free or not free.
This is a poor analogy.
There are three ways in which software can go wrong:
1) Segfaults (or otherwise "crashes")
2) Blows up in time or space (poor algorithm choice, or just plain old necessity. Some problems really do require slow/big algorithms)
3) Doesn't meet spec.
Guess what: any software that doesn't do any of these is right. You don't have to know C to write software that doesn't do these.
There isn't much difference between a logic language and a functional language. The only "real" difference is the evaluation model: logical languages use unification, and functional languages use some kind of beta reduction. Well, unification is what you get if you take a function in extension form (that is, as a set of ordered pairs) and apply beta reduction to this syntactic form.
Functions are proofs. Proofs in a "constructive" logic.
Unless you have some weird hardware, you don't need an xorg.conf on Arch (or any distro that uses HAL + a bleeding edge xorg)
The most memorable part of the review for me was the wall paper.
Thanks for the heads up. I'll check it out.
I'm not a ham, but would be willing to learn, and share my multi terabyte video collection.
A BSOD is a much better user interface than a screen that merely does not respond. I don't see your point.
Folders are files. That contain other files. What's so hard about that?
BP will never go bankrupt over this, unless their assets are nationalized. The elasticity of demand completely outstrips the elasticity of supply. Therefore, any fees levied against BP will be paid for by the consumer of their products. Oil is a fungible good, but it is also an oligopoly at this level. Every oil user will pay for BP's spill, even if they avoid BP.
They are lying threw their teeth if they say nothing unusual happened. I watched it on fold on my trading platform and it was like 1/2 the market just turned off while computerized trades relentlessly sold to the nonexistent buy side. In the end its likely that the only people who got hurt by this were retail investors who trade with stop-loss or trailing stop-loss orders.
If they put an order in, they do not have my sympathy. They missed out on an opportunity, but they got what they asked for in order to do it.
How is that anybody's fault but their own? Sales don't happen unless the bid and ask prices match.
This calculation was NOT done by one molecule, it was done by a whole bunch of other stuff that led to that molecule being in the states that it was in.
This is exactly wrong.
Compare this to a drum stick hitting a drum head. Does the drum stick do any calculations? Of course not. The drum head performs a spectral analysis on the result of a strike.
Do you know what a "technology" is? It is the usage of tools, technique, or craft in order to solve a problem.
If you're interested, check out "The Elements of Typographic Style" from your local library. Very interesting stuff. I used it as a source when designing a LaTeX style for my senior thesis.
Like Battletoads?
Argh. That should read:
Cauchy sequence is a function from the Naturals into a metric space for which there is "Cauchy convergence": for every epsilon, there is an N such that if m and n are large enough, |f(m) - f(n)| < epsilon. f IS the number to which the sequence converges. f is not an approximation.