Nope - there are 1) Far more J1772 combo connector charging stations than there are Tesla charging stations, and 2) Roughly 9 times more J1772 equipped electric vehicles being sold than Teslas.
Currying doesn't violate referential transparency. curry is a function that accepts a multiple argument function, and returns a one argument function. It always returns the same function when it's given the same function as an argument. That's referentially transparent.
The difference isn't about being "full of state" it's about accessing state external to you. Again - if a function relies only on its arguments to determine its result, then it is referentially transparent, aka "purely functional".
Actually, pure functional behaviour is exactly what *gives* you scalability.
By removing state, you make it possible to run things on thousands and thousands of servers without having some shared memory bottleneck that everything needs to talk to.
The one core concept that makes functional programming different from anything else is "referential transparency". Referential Transparency is the property that you can substitute a call to a function with a given set of arguments with the result of that function in the program, and the behavior won't change at all.
To put it another way - when you call a function, its result has to be determined based *only* on the arguments you pass in, not any external state that might be floating about. It's not allowed to go and fetch an instance variable; it's not allowed to poke a singleton and grab state out of it; it's not allowed to print something; and it's not allowed to launch missiles.
What that gives you is:
1) It's very easy to test those functions - you define a set of arguments, you define a correct result, and you say 'call this, and you should get this result'.
2) It's very easy to parallelise these functions - since they're not affecting any outside state, no locking is necessary, you just run them side by side, and you're done.
3) It's very easy to debug these functions, since you have a defined input, and a defined correct output, you can sit there and easily understand what's going on.
4) it's very easy to reason about these functions, since you never read a chunk of code in them and go "god, what could all the values of this external state be?"
5) It makes code clearer, since you can easily document exactly what that bit of code is doing, without any reference to any external parts of the system, or any prerequisites.
You do realise that "objects" are not the only way to encapsulate data, right?
The thing that makes OOP OOP is inheritence, not the fact that you have a structure that represents some object - all programming languages have encapsulated data, whether they're OO or not.
You're right - it is orthogonal. But it's something that comes with the territory. Almost every single functional programming language out there uses some variant on ADTs to model data, not inheritance hierarchies. People start realizing that there are other (better) ways to model concepts when they're temporarily forced to think that way.
Games dev actually avoids OOP like the plague these days. Anything that runs on the GPU is purely functional, much of what runs on the CPU is purely functional, and data oriented rather than object oriented. Games devs care more about whether you can keep everything in cache, and crunch through it, rather than whether its modeled nicely.
There's two big things that have come out of the recent move towards more functional programming which are really important.
1) People are understanding that reducing the amount of state that any particular bit of code carries reduces the complexity of working with it. Less state means more testability, more easy reasoning about the code, more clarity, more easy debugging, and fewer edge cases to consider. That's not to say that you should never has state, as pure functional programming would have you believe, but reducing state dependance pretty much helps make your code better universally.
2) People are realising that inheritance is not the be-all and end-all of modelling code that the OOP world would have you believe. They're realising that inheritance is what screws up type systems, and makes them hard to work with. They're realising that deep inheritance hierarchies often lead to complex code which is tricky to understand exactly what code is going to execute when, and where you're going to jump to when you're reading it. Again - this isn't to say you should never use inheritance, but people are realising that composition can work equally well, or better, and that using it over inheritance has some substantial benefits.
As to the bandwagon of "write javascript, it's a functional language, that makes it brilliant". Fuck off... That's just yet another of the latest fads towards pascal on trains; nodeHaskell; and reactMonkey. I'll happily sit here continuing to write ancient languages, but trying to apply some of the concepts from FP to make my code simpler and more readable.
I mean sure - for me, that's fine. For the average American, the idea of "putting a few months worth of pay checks into savings" is just ludicrous. It would take them several years to be able to save that much, since everything has to be spent on the basic necessities of food, shelter, clothes and bills.
The US's bi-weekly pay cycle was one of the things that surprised me most when I first moved here. In Europe, monthly pay cycles are the norm, meaning that you can neatly line up getting paid on the 1st, rent coming out on the 2nd, and bills getting paid on the 3rd, rather than constantly juggling "which pay packet does rent/mortgage need to come out of this time?"
Which is kinda my point. If you're going to end up with a legalised monopoly, I'd rather have a non-profit one run for the benefit of the people, than a for-profit one run for the benefit of the shareholders.
The whole point is to make the competition somewhat unfair. You should what someone who doesn't have a profit motive, but instead a public service motive would do. That forces all the guys with profit motives to show them how to run the thing efficiently, and *still* make a profit while providing all those good services.
Not at all. You create a municipal internet, and you still allow everyone else to compete with it. You just use the government option as a method of making sure competition actually works in the public's interest.
If you think about it, you'll realize how stupid this whole thing is. Regardless of the form of taxation, the net result is the same - money diverted from the productivity generator (employee, company) to the government. So why do we need so many taxes?
This makes a base assumption that services provided by the government are not productivity generators.
According to you:
*Roads are not productivity generators
* People who are not sick don't generate productivity
* Educated people don't generate productivity
* People who don't live in fear of crime don't generate productivity...
VAT in the UK accumulated along the way, and then passed to the customer:.2 * 100 (when the produced item was sold to the first step executer).2 * 125 -.2 * 100 (when the modified item was sold to the second step executer).2 * 156.25 -.2 * 125 (when the modified item was sold to the third step executer).2 * 195.3125 -.2 * 156.25 (when the modified item was sold to the customer) = 39.0625 Total price in the UK = 234.375
Sales tax in the US assuming 6%:.06 * 195.3125 = 11.71875 Total price in the US = 207.03125
The end result of VAT and sales tax is effectively identical.
VAT: at each stage VAT is applied on the value added, and then passed along as a cost to the next person. Effectively the customer ends up paying VAT on all of the value that was ever added (the total value of the end result) Sales: at each stage, 0% tax is applied, then when it gets to the customer, they pay sales tax on the total value.
They'e calculated in different ways, but the end result is that the customer pays the tax on the total value of the product.
By the time you take all that stuff into account the US is likely to be *way* further down the list. Property tax isn't high in the US (typically around 1.5% of the value of the property, which is similar to, or lower than council tax rates in the UK). Sales tax is typically extremely low (typically less than 6%), compared to the UK's 20% VAT. Taxes on fuel are typically extremely low 18.4/gal, compared to the UK's £2.19/gal (273/gal).
No - that's a fucking terrible idea. If you want to start a company, rule 1 is be fucking squeaky clean making sure that your current work has *no* way to claim that this stuff belongs to them.
Slashdot Mirror
Nope - there are
1) Far more J1772 combo connector charging stations than there are Tesla charging stations,
and
2) Roughly 9 times more J1772 equipped electric vehicles being sold than Teslas.
Especially given that the entire rest of the world (barring Nissan) has standardised on J1772 + combo connectors.
Currying doesn't violate referential transparency. curry is a function that accepts a multiple argument function, and returns a one argument function. It always returns the same function when it's given the same function as an argument. That's referentially transparent.
The difference isn't about being "full of state" it's about accessing state external to you. Again - if a function relies only on its arguments to determine its result, then it is referentially transparent, aka "purely functional".
Actually, pure functional behaviour is exactly what *gives* you scalability.
By removing state, you make it possible to run things on thousands and thousands of servers without having some shared memory bottleneck that everything needs to talk to.
The one core concept that makes functional programming different from anything else is "referential transparency". Referential Transparency is the property that you can substitute a call to a function with a given set of arguments with the result of that function in the program, and the behavior won't change at all.
To put it another way - when you call a function, its result has to be determined based *only* on the arguments you pass in, not any external state that might be floating about. It's not allowed to go and fetch an instance variable; it's not allowed to poke a singleton and grab state out of it; it's not allowed to print something; and it's not allowed to launch missiles.
What that gives you is:
1) It's very easy to test those functions - you define a set of arguments, you define a correct result, and you say 'call this, and you should get this result'.
2) It's very easy to parallelise these functions - since they're not affecting any outside state, no locking is necessary, you just run them side by side, and you're done.
3) It's very easy to debug these functions, since you have a defined input, and a defined correct output, you can sit there and easily understand what's going on.
4) it's very easy to reason about these functions, since you never read a chunk of code in them and go "god, what could all the values of this external state be?"
5) It makes code clearer, since you can easily document exactly what that bit of code is doing, without any reference to any external parts of the system, or any prerequisites.
You do realise that "objects" are not the only way to encapsulate data, right?
The thing that makes OOP OOP is inheritence, not the fact that you have a structure that represents some object - all programming languages have encapsulated data, whether they're OO or not.
You're right - it is orthogonal. But it's something that comes with the territory. Almost every single functional programming language out there uses some variant on ADTs to model data, not inheritance hierarchies. People start realizing that there are other (better) ways to model concepts when they're temporarily forced to think that way.
Games dev actually avoids OOP like the plague these days. Anything that runs on the GPU is purely functional, much of what runs on the CPU is purely functional, and data oriented rather than object oriented. Games devs care more about whether you can keep everything in cache, and crunch through it, rather than whether its modeled nicely.
The same problem they solve in any other language - they allow you to easily express a function that captures values from a dynamic scope.
There's two big things that have come out of the recent move towards more functional programming which are really important.
1) People are understanding that reducing the amount of state that any particular bit of code carries reduces the complexity of working with it. Less state means more testability, more easy reasoning about the code, more clarity, more easy debugging, and fewer edge cases to consider. That's not to say that you should never has state, as pure functional programming would have you believe, but reducing state dependance pretty much helps make your code better universally.
2) People are realising that inheritance is not the be-all and end-all of modelling code that the OOP world would have you believe. They're realising that inheritance is what screws up type systems, and makes them hard to work with. They're realising that deep inheritance hierarchies often lead to complex code which is tricky to understand exactly what code is going to execute when, and where you're going to jump to when you're reading it. Again - this isn't to say you should never use inheritance, but people are realising that composition can work equally well, or better, and that using it over inheritance has some substantial benefits.
As to the bandwagon of "write javascript, it's a functional language, that makes it brilliant". Fuck off... That's just yet another of the latest fads towards pascal on trains; nodeHaskell; and reactMonkey. I'll happily sit here continuing to write ancient languages, but trying to apply some of the concepts from FP to make my code simpler and more readable.
They get so much press because:
1) They're an outlier in terms of unicorn funding, and also unicorn like losses.
2) Everyone wants to watch a slow motion train wreck.
Corporate espionage
I mean sure - for me, that's fine. For the average American, the idea of "putting a few months worth of pay checks into savings" is just ludicrous. It would take them several years to be able to save that much, since everything has to be spent on the basic necessities of food, shelter, clothes and bills.
The US's bi-weekly pay cycle was one of the things that surprised me most when I first moved here. In Europe, monthly pay cycles are the norm, meaning that you can neatly line up getting paid on the 1st, rent coming out on the 2nd, and bills getting paid on the 3rd, rather than constantly juggling "which pay packet does rent/mortgage need to come out of this time?"
Which is kinda my point. If you're going to end up with a legalised monopoly, I'd rather have a non-profit one run for the benefit of the people, than a for-profit one run for the benefit of the shareholders.
The whole point is to make the competition somewhat unfair. You should what someone who doesn't have a profit motive, but instead a public service motive would do. That forces all the guys with profit motives to show them how to run the thing efficiently, and *still* make a profit while providing all those good services.
Not at all. You create a municipal internet, and you still allow everyone else to compete with it. You just use the government option as a method of making sure competition actually works in the public's interest.
If you think about it, you'll realize how stupid this whole thing is. Regardless of the form of taxation, the net result is the same - money diverted from the productivity generator (employee, company) to the government. So why do we need so many taxes?
This makes a base assumption that services provided by the government are not productivity generators.
According to you:
*Roads are not productivity generators
* People who are not sick don't generate productivity
* Educated people don't generate productivity
* People who don't live in fear of crime don't generate productivity ...
You missed that sales tax is not paid by companies buying and then reselling products in the US. It is only paid by the final customer.
Untaxed price in both countries: .25 * 100 + .25 * 1.25 * 100 + .25 * 1.25 * 1.25 * 100
100 +
= 195.3125
VAT in the UK accumulated along the way, and then passed to the customer: .2 * 100 (when the produced item was sold to the first step executer) .2 * 125 - .2 * 100 (when the modified item was sold to the second step executer) .2 * 156.25 - .2 * 125 (when the modified item was sold to the third step executer) .2 * 195.3125 - .2 * 156.25 (when the modified item was sold to the customer)
= 39.0625
Total price in the UK = 234.375
Sales tax in the US assuming 6%: .06 * 195.3125 = 11.71875
Total price in the US = 207.03125
The end result of VAT and sales tax is effectively identical.
VAT: at each stage VAT is applied on the value added, and then passed along as a cost to the next person. Effectively the customer ends up paying VAT on all of the value that was ever added (the total value of the end result)
Sales: at each stage, 0% tax is applied, then when it gets to the customer, they pay sales tax on the total value.
They'e calculated in different ways, but the end result is that the customer pays the tax on the total value of the product.
Capital gains in the US (15%) is typically substantially lower than in Europe (where it's usually around the 25% mark).
So is sales tax (typically around 6% depending on state), compared to somewhere around 20% VAT (depending on exact country) in Europe.
And... slashdot ate my cent symbols. Assume that 18.4 and 273 are followed by cent signs)
By the time you take all that stuff into account the US is likely to be *way* further down the list. Property tax isn't high in the US (typically around 1.5% of the value of the property, which is similar to, or lower than council tax rates in the UK). Sales tax is typically extremely low (typically less than 6%), compared to the UK's 20% VAT. Taxes on fuel are typically extremely low 18.4/gal, compared to the UK's £2.19/gal (273/gal).
No - that's a fucking terrible idea. If you want to start a company, rule 1 is be fucking squeaky clean making sure that your current work has *no* way to claim that this stuff belongs to them.
The best gas turbine engines are around 40% efficient. F1 engines are around 51% efficient.