The free market is built on the principles of property ownership and the transfer of ownership. At the same time, those principles are foundational to government. In a free market, it is illegal to steal, which contradicts your statement.
So I would say that one of the primary roles of government is to enable the free market.
I don't know about you, but if I'm going to throw $100K toward a thrill ride that could easily end in my death, I'm not inclined to do so with a company that chooses to operate outside of an established government regulatory authority.
In today's world, other than Microsoft there's no one else who charges for an operating system.
Apple keeps all hardware in-house. They certainly do charge for the OS, they just build it into the price of the full system.
Google is an advertising company. They don't seem to care much about anything except getting people to use their services to display their ads. If that means working on an OS they don't charge for, so be it.
So Microsoft is the only one of these three whose business model is primarily software. And, as it turns out, Microsoft is becoming a devices-and-services company in order to more effectively compete with the above two... but only a fool (or a hater) would assume that such a large company can or should make that full transition overnight.
And then again, I don't know if public libraries actually kick you out if you are talking.
The librarian may request you to stop talking or to go outside to talk, and others may give you an evil eye, but I'm not sure I've heard of the police dragging someone out. Even if that happened, I would think it would be on grounds of disturbing the peace.
But I'm not sure that is banning "speech" as it is about banning "speaking". The first is the expression of thought which aligns more with the interpretation of speech in the first amendment. The second is an act of producing sounds from your mouth, which is banned without regard to content.
Those are one and the same to me. Of course, the definition of "what is" may be different between you and I. Some feel that the articles they read in a science magazine are "what is". Some feel that their relationship with God is "what is". Some feel that the understanding they have which is not shared by others is "what is".
So in this case, do we go with majority rule? The majority believes in something, therefore that's what counts for public education? This could work well, and it could also backfire if it turns out you are in the minority.
I would argue that the problem isn't with transitivity, but with assuming that value is fixed around objects. In reality, value fluctuates according to circumstances.
I might give you $100 for your bar of dark chocolate because I love it that much and I don't have any. But if I have 5 tons of delicious dark chocolate in my basement, I'm not going to give you even $1 for your bar.
In programming parlance, it's the difference between
It depends on the situation. The primary use may not exist 20 years from now. The building may not exist or may be remodeled in the next 20 years.
Considering both bulbs should last hundreds of years under that much usage, I calculate that I wouldn't break even with an LED setup for around 227 years. So unless I plan for my great-great-great-great-great-grandkids to use these bulbs, I don't think it's worth it.
And I didn't include CFLs because they aren't equivalent (especially for rare use, it takes too long for them to brighten) and for several reasons that have been posted in these comments that I won't repeat.
Ok, let's do some math: I need to use a 60W light weekly for about 5 minutes. Assume $0.20/KWH, 20 years of use,
- A $1 incandescent will use 5.2 KWH total use over its lifespan. The cost is $1.04 over its lifetime in energy costs, for a total of $2.04 including the bulb. - Compare to a 60W equivalent LED (9.5W @ $10/bulb). It will use 0.82 KWH over its lifespan. $0.16 in lifetime energy costs for a total of $10.16.
Why would I want to pay 5 times the cost in this situation? And what if I were talking about the same pattern of use with 10 or 20 bulbs, or in an industrial setting a few hundred or thousands of these?
If this were a completely uncommon case I wouldn't care, but it happens a lot for me and I imagine for others as well.
Again, when you resolve types at runtime, that's called duck typing. The statement I replied to:
Most functional languages are rather a way of expressing multiple function signatures and having the run-time decide which is the best match based on the parameters at run-time, not compile-time
is simply wrong. There is nothing, absolutely nothing, about functional languages that requires duck typing. And like I said, many functional languages discourage or even eliminate runtime type resolution.
And if your hangup is on the fact that I use the term "type" instead of "function", remember that in functional languages, functions are first class. When you create a function, it has a static type. That static type is typically evaluated by the compiler.
Most functional languages are rather a way of expressing multiple function signatures and having the run-time decide which is the best match based on the parameters at run-time, not compile-time.
You should be stripped of your 5-digit ID for that statement.
You just described duck typing, while the opposite (static typing) is typically encouraged in functional languages.
Don't kid yourself that it isn't fundamentally a style implemented with events.
I suppose that's why I said:
... you really could do the same exact thing with events or triggers than you can do with reactive programming. But events and triggers are very basic compared to what is meant by reactive programming.
Your filesystem notifications or DB reactions are either coming from a polling loop in the FS/DB engine, or from an event processing loop in the FS/DB engine.
The system calls you use isn't the question. It's about how your implementation works, not about external implementations you don't control.
Let's think hierarchically. Make is smart and will check all intermediate output, all the way down to the leaves of its target tree, to see if it needs to do anything. If all the leaves are older than the final output, make doesn't do anything. If a level 5 leaf is younger than the final output file, make reevaluates that leaf and its level 4 parent, its level 3 grandparent, etc. to the top. It will use any intermediate outputs that were already generated where possible.
Here's where reactive is different: true reactive programming would being at the level 5 leaf that changed, as a direct result of it being changed. No continuous polling loop would be used in your implementation (again, the OS implementation is external to this). Such a "make" would not even need to make any check on the file modification date/time. It would know that the file it is notified about will always be the direct reason for causing a recompile, and it would go up the tree to produce its intermediate outputs as well as the final output, just like normal make.
Ok, there are a lot of people commenting on this below who have absolutely no idea what reactive programming is about. So I'll try to clear it up a bit.
Reactive programming is not polling.
If you call a function and wait for it to return a result, you aren't doing reactive programming.
If you are working in a REPL or command-line environment, and you have to type a command every time you want to obtain a result, your system is not reactive.
Reactive programming is not events and triggers. Well... let's say it this way: reactive programming is to events/triggers as writing in [C/C++/Java/C#/Haskell/etc.] is to writing in assembly. In other words, you really could do the same exact thing with events or triggers than you can do with reactive programming. But events and triggers are very basic compared to what is meant by reactive programming.
Events and triggers are typically used when a little reactivity is needed. When you build your system around reactivity, using events and triggers quickly becomes inefficient and you need something built for the task. You would pick a reactive programming language or framework for such a complex job, just like (most of) you would choose high-level languages and frameworks over assembly for building a social media website.
Reactive programming isn't an agile framework. It's not some new way of describing object-oriented programming. And it's not the right tool for every job, but for some jobs, it's the perfect tool.
Yeah, that's "reactive programming" at the file level. I do it all the time, with Makefiles. Lots of people do. A nice thing about a Makefile is that you can easily control when the calculation of derivative files happens. You (re)create some sets of primary data, then use a simple "make" command to rebuild everything that depends on any of them.
But that isn't reactive; it's still polling.
Reactive is the opposite of polling. E.g. if you wanted Makefiles to be reactive, your filesystem would need to notify when a change occurs, and then that change would immediately cause a compile (or whatever it is in your data calculation case) of only the pieces that are directly affected by that, and so on up the chain until the final result is produced.
If you have to type "make [...]" or set up a cron job, you aren't doing reactive.
Not entirely. Of course you can model A=B+C as a function A which, when evaluated, returns the sum of B and C. And sure, you can evaluate A() several times and get different results if B or C have changed.
Reactive programming is about the future and expecting change. When B or C changes, notification of that change is pushed up to the eventual recipient.
But it's more than just simple event handling. For example, what if you wrote a complex SQL query against a few dozen tables located on a hierarchy of servers that might only return a handful of joined records out of millions or billions? And what if that data rarely changes, but you need to know almost immediately? Polling would use too many resources, too much bandwidth, and may never give you the results in a timely manner. But if the system is reactive, the change starts at the leaf server and only gets propagated up its part of the server hierarchy to the final listener. And if that record is filtered out somewhere along the way? The remaining part of the server hierarchy (including the end listener) never has to know or worry about it.
Still, reactive programming is a hammer but not everything is a nail. Use it when it helps.
Different options, not less. The Start menu doesn't show how many emails you have unread, or your local temperature and weather, or the latest news, or calendar events, or social media updates you care about, or whatever.
Not to say they couldn't merge the two and come up with an even better concept, but it's unfair to say that the Start screen is 100% a subset of the Start menu when it obviously isn't.
If everything about that story were identical except that the white kids were the majority, the NAACP would have shut it down. (Even though clearly white people make up a majority with 72.4% of the US population).
You don't see anyone calling foul on the underrepresentation of white children.
Isn't the whole point of this discussion that it is worth billions of dollars per year to provide nutrition for the poor? Good foods will help their nutrition much more than Cheetos and ice cream, and single-point-of-sale is much easier to monitor than allowing them to do what they want. (It is also easier to enforce that the kids receive the proper allotment and that it isn't sold for drug money.)
I'm late getting back to this, but in case you still see it... we can't have open voting because that would invite corruption.
With closed voting, if someone tries to force me to vote a certain way, they can never confirm or deny my actual vote. But if there is any way for you to confirm your vote, then someone might be able to force you to prove it to them.
Slashdot Mirror
Oblig: http://xkcd.com/927/
In a free market, nothing is illegal.
Huh?
The free market is built on the principles of property ownership and the transfer of ownership. At the same time, those principles are foundational to government. In a free market, it is illegal to steal, which contradicts your statement.
So I would say that one of the primary roles of government is to enable the free market.
I don't know about you, but if I'm going to throw $100K toward a thrill ride that could easily end in my death, I'm not inclined to do so with a company that chooses to operate outside of an established government regulatory authority.
In today's world, other than Microsoft there's no one else who charges for an operating system.
Apple keeps all hardware in-house. They certainly do charge for the OS, they just build it into the price of the full system.
Google is an advertising company. They don't seem to care much about anything except getting people to use their services to display their ads. If that means working on an OS they don't charge for, so be it.
So Microsoft is the only one of these three whose business model is primarily software. And, as it turns out, Microsoft is becoming a devices-and-services company in order to more effectively compete with the above two... but only a fool (or a hater) would assume that such a large company can or should make that full transition overnight.
And then again, I don't know if public libraries actually kick you out if you are talking.
The librarian may request you to stop talking or to go outside to talk, and others may give you an evil eye, but I'm not sure I've heard of the police dragging someone out. Even if that happened, I would think it would be on grounds of disturbing the peace.
But I'm not sure that is banning "speech" as it is about banning "speaking". The first is the expression of thought which aligns more with the interpretation of speech in the first amendment. The second is an act of producing sounds from your mouth, which is banned without regard to content.
Those are one and the same to me. Of course, the definition of "what is" may be different between you and I. Some feel that the articles they read in a science magazine are "what is". Some feel that their relationship with God is "what is". Some feel that the understanding they have which is not shared by others is "what is".
So in this case, do we go with majority rule? The majority believes in something, therefore that's what counts for public education? This could work well, and it could also backfire if it turns out you are in the minority.
I would argue that the problem isn't with transitivity, but with assuming that value is fixed around objects. In reality, value fluctuates according to circumstances.
I might give you $100 for your bar of dark chocolate because I love it that much and I don't have any. But if I have 5 tons of delicious dark chocolate in my basement, I'm not going to give you even $1 for your bar.
In programming parlance, it's the difference between
int value = darkChoc.Deliciousness();
and
int value() { return darkChoc.Deliciousness(); }
It depends on the situation. The primary use may not exist 20 years from now. The building may not exist or may be remodeled in the next 20 years.
Considering both bulbs should last hundreds of years under that much usage, I calculate that I wouldn't break even with an LED setup for around 227 years. So unless I plan for my great-great-great-great-great-grandkids to use these bulbs, I don't think it's worth it.
And I didn't include CFLs because they aren't equivalent (especially for rare use, it takes too long for them to brighten) and for several reasons that have been posted in these comments that I won't repeat.
Ok, let's do some math: I need to use a 60W light weekly for about 5 minutes. Assume $0.20/KWH, 20 years of use,
- A $1 incandescent will use 5.2 KWH total use over its lifespan. The cost is $1.04 over its lifetime in energy costs, for a total of $2.04 including the bulb.
- Compare to a 60W equivalent LED (9.5W @ $10/bulb). It will use 0.82 KWH over its lifespan. $0.16 in lifetime energy costs for a total of $10.16.
Why would I want to pay 5 times the cost in this situation? And what if I were talking about the same pattern of use with 10 or 20 bulbs, or in an industrial setting a few hundred or thousands of these?
If this were a completely uncommon case I wouldn't care, but it happens a lot for me and I imagine for others as well.
Again, when you resolve types at runtime, that's called duck typing. The statement I replied to:
Most functional languages are rather a way of expressing multiple function signatures and having the run-time decide which is the best match based on the parameters at run-time, not compile-time
is simply wrong. There is nothing, absolutely nothing, about functional languages that requires duck typing. And like I said, many functional languages discourage or even eliminate runtime type resolution.
And if your hangup is on the fact that I use the term "type" instead of "function", remember that in functional languages, functions are first class. When you create a function, it has a static type. That static type is typically evaluated by the compiler.
It seems, though, that most comments here are calling strawberries yellow and flat.
If you want to know everything about reactive programming, Google is your friend. I'm just attempting to dispel the myths that seem prominent here.
When the government decided its job was to redistribute wealth.
At least if redistribution is going to occur, we should do it efficiently, effectively, and in a way that doesn't invite abuse.
Most functional languages are rather a way of expressing multiple function signatures and having the run-time decide which is the best match based on the parameters at run-time, not compile-time.
You should be stripped of your 5-digit ID for that statement.
You just described duck typing, while the opposite (static typing) is typically encouraged in functional languages.
Don't kid yourself that it isn't fundamentally a style implemented with events.
I suppose that's why I said:
... you really could do the same exact thing with events or triggers than you can do with reactive programming. But events and triggers are very basic compared to what is meant by reactive programming.
Your filesystem notifications or DB reactions are either coming from a polling loop in the FS/DB engine, or from an event processing loop in the FS/DB engine.
The system calls you use isn't the question. It's about how your implementation works, not about external implementations you don't control.
Let's think hierarchically. Make is smart and will check all intermediate output, all the way down to the leaves of its target tree, to see if it needs to do anything. If all the leaves are older than the final output, make doesn't do anything. If a level 5 leaf is younger than the final output file, make reevaluates that leaf and its level 4 parent, its level 3 grandparent, etc. to the top. It will use any intermediate outputs that were already generated where possible.
Here's where reactive is different: true reactive programming would being at the level 5 leaf that changed, as a direct result of it being changed. No continuous polling loop would be used in your implementation (again, the OS implementation is external to this). Such a "make" would not even need to make any check on the file modification date/time. It would know that the file it is notified about will always be the direct reason for causing a recompile, and it would go up the tree to produce its intermediate outputs as well as the final output, just like normal make.
Ok, there are a lot of people commenting on this below who have absolutely no idea what reactive programming is about. So I'll try to clear it up a bit.
Reactive programming is not polling.
If you call a function and wait for it to return a result, you aren't doing reactive programming.
If you are working in a REPL or command-line environment, and you have to type a command every time you want to obtain a result, your system is not reactive.
Reactive programming is not events and triggers. Well... let's say it this way: reactive programming is to events/triggers as writing in [C/C++/Java/C#/Haskell/etc.] is to writing in assembly. In other words, you really could do the same exact thing with events or triggers than you can do with reactive programming. But events and triggers are very basic compared to what is meant by reactive programming.
Events and triggers are typically used when a little reactivity is needed. When you build your system around reactivity, using events and triggers quickly becomes inefficient and you need something built for the task. You would pick a reactive programming language or framework for such a complex job, just like (most of) you would choose high-level languages and frameworks over assembly for building a social media website.
Reactive programming isn't an agile framework. It's not some new way of describing object-oriented programming. And it's not the right tool for every job, but for some jobs, it's the perfect tool.
Yeah, that's "reactive programming" at the file level. I do it all the time, with Makefiles. Lots of people do. A nice thing about a Makefile is that you can easily control when the calculation of derivative files happens. You (re)create some sets of primary data, then use a simple "make" command to rebuild everything that depends on any of them.
But that isn't reactive; it's still polling.
Reactive is the opposite of polling. E.g. if you wanted Makefiles to be reactive, your filesystem would need to notify when a change occurs, and then that change would immediately cause a compile (or whatever it is in your data calculation case) of only the pieces that are directly affected by that, and so on up the chain until the final result is produced.
If you have to type "make [...]" or set up a cron job, you aren't doing reactive.
Not entirely. Of course you can model A=B+C as a function A which, when evaluated, returns the sum of B and C. And sure, you can evaluate A() several times and get different results if B or C have changed.
Reactive programming is about the future and expecting change. When B or C changes, notification of that change is pushed up to the eventual recipient.
But it's more than just simple event handling. For example, what if you wrote a complex SQL query against a few dozen tables located on a hierarchy of servers that might only return a handful of joined records out of millions or billions? And what if that data rarely changes, but you need to know almost immediately? Polling would use too many resources, too much bandwidth, and may never give you the results in a timely manner. But if the system is reactive, the change starts at the leaf server and only gets propagated up its part of the server hierarchy to the final listener. And if that record is filtered out somewhere along the way? The remaining part of the server hierarchy (including the end listener) never has to know or worry about it.
Still, reactive programming is a hammer but not everything is a nail. Use it when it helps.
The point of [Company X doing something] is to generate revenue for [Company X]. Hope this helps.
FTFY
Different options, not less. The Start menu doesn't show how many emails you have unread, or your local temperature and weather, or the latest news, or calendar events, or social media updates you care about, or whatever.
Not to say they couldn't merge the two and come up with an even better concept, but it's unfair to say that the Start screen is 100% a subset of the Start menu when it obviously isn't.
If everything about that story were identical except that the white kids were the majority, the NAACP would have shut it down. (Even though clearly white people make up a majority with 72.4% of the US population).
You don't see anyone calling foul on the underrepresentation of white children.
Isn't the whole point of this discussion that it is worth billions of dollars per year to provide nutrition for the poor? Good foods will help their nutrition much more than Cheetos and ice cream, and single-point-of-sale is much easier to monitor than allowing them to do what they want. (It is also easier to enforce that the kids receive the proper allotment and that it isn't sold for drug money.)
I'm late getting back to this, but in case you still see it... we can't have open voting because that would invite corruption.
With closed voting, if someone tries to force me to vote a certain way, they can never confirm or deny my actual vote. But if there is any way for you to confirm your vote, then someone might be able to force you to prove it to them.