For the record, Simula appeared in 1967, so "the 1960s" is accurate.
OOP became mainstream in 1991. We know it to the year, because that was when OOAD by Booch was published. Between 1967 and 1991, there was a steady trickle of new programming languages with Simula-style objects. After 1991, they almost all did, or had support for emulating them. We're talking 25 years of lead time between initial research and adoption.
Functional programming, in a sense, predates computers, but as far as programming languages go, it does go back to Lisp in 1958. There has been a steady trickle of functional programming languages since then, but the time in history when almost all languages are getting language support is right about now. C# got lambdas in 2007, C++ in 2011, and Java in 2014.
Of course, these aren't fundamentalist functional languages, but they're not fundamentalist OO languages either.
Of course at the same time the academics where also pushing LIsp as the end all and be all of computer programming.
Name three, with actual quotations please.
What I think you'll actually find is that a number of academics were pushing symbolic computing as an important future trend, and at the time, Lisp was the only game in town.
OOP worked out Lisp is still around but not really mainstream.
...and yet Greenspun's tenth rule and Morris's corollary are as true as they've always been.
Map-reduce as implemented in practice today uses storage which breaks the purely functional paradigm.
I think you're using a different sense of "uses storage" than I am. The map and reduce phases of map-reduce transform abstract data into abstract data, and it is the framework which turns this into a process which transforms storage into storage. The whole point of map-reduce is that it's cheaper to move code around cluster than to move data. As soon as the map and reduce tasks share data, performance is lost.
Out of a zillion things that were touted as "the next big thing", only a handful, like OOP, actually made it to the mainstream. So, by any reasonable reckoning "real world business software developers" were right 99.9% of the time and the academics weren't.
First off, you're assuming that it's academics who make the unsubstantiated bold claims about the "next big thing". In my experience, a few academics are like that, but most aren't. Academics generally know their own limitations, especially when it comes to predicting the future.
I'm sorry, truly big like.. what? [...] What successful pure-functional projects operate at this scale (pick your metric: lines of codes, number of users*time,...)?
But you have to agree that 'functional programming is the next big thing' has been said for so long now [...]
Well... I kind of have to agree, in that it's true that it has been said. However, it's not true that this means anything either way.
I remember when transputers were the next big thing. People older than I probably remember when perceptrons were the next big thing. People talk crap, and functional programming has been around for a while, so it's inevitable that some subculture has considered it "the next big thing" for a while, along with everyone else who thinks that something else is "the next big thing".
I don't know who those people are, because I don't listen to them, but Erik Meijer is not one of them. Actually he's making a sort-of opposite point, namely, that in the world of many-core and big-data, "almost" pure functional programming (which is almost all functional programming) is useless.
Yes, I think that the main lasting contribution of NBG is the language. Today we would talk about the "category of all sets" or the "category of all locally small categories", rather than "proper classes".
But it doesn't scale to the truly big, which is kind of Meijer's point. Those responsible for the NSA mass surveillance system have been reassuring you of its "mostly secure" nature for almost a year now, but I think we know that doesn't work in practice.
One thing I was going to mention but didn't (because it would have confused things) is that this is true but slightly misleading:
a "type" can be thought of as a set of values
Sets are unstructured, but programming language types have structure. This is part of the reason why modern thinking is to ground programming language semantics in the language of category theory. If nothing else, the "carrier sets" of types must be computable sets, and the mappings between them must be computable functions.
My impression of "pure" functional programming is that it's roughly like having only static classes and no static members in OOP.
If you got that impression from TFA, then I can actually understand how you got it. Meijer's article was written for people already using not-fully-pure functional languages, where "class" means something slightly different than it does in a Simula-style OO language.
The term "class" comes from von Neumann–Bernays–Gödel set theory. Naive set theory had issues like Russell's Paradox, which relies on notions like the "set of all sets". To remove this paradox, NBG set theory distinguishes between a "set" and a "class" (i.e. a collection of sets defined by a property they have in common). Some classes are sets, and some are not. A set is a collection of values, but a "class" is a collection of sets.
In programming language theory, a "type" can be thought of as a set of values (e.g. "boolean" might be the set {true, false}). A "class" is a collection of types.
When you write class Foo in (say) Java, you're actually doing three separate things.
You are declaring a new type, called Foo.
You are declaring a new collection of types (also confusingly called Foo), which will turn out to be the type Foo and all its subtypes.
You are declaring that the type Foo is a member of the collection Foo.
In the Haskell class system, these three things are separated. This is why Haskell classes look more restrictive than classes that you might find in Java: a Haskell class only contains the parts that make it a class, not the parts that make it a type.
Real world business software developers just don't talk that way.
"Real world business software developers" are those whose code ends up on The Daily WTF.
But seriously, welcome to the future. In the 1960s, "real world business software developers" thought that all this "object" stuff was a bunch of academic gobbeldygook at worst, or niche tool for people doing scientific simulations at best, rather than anything that would be useful with their hard-nosed COBOL. And in a sense, they were right. How would it help you speed up the overnight bank transaction updates? It probably wouldn't.
This "academic rambling" probably won't help you write your business software today, but it just might help you avoid becoming obsolete tomorrow. Thankfully, you probably won't need to learn it until tomorrow.
Am I the only person whose first thought on reading the headline was that Erik Meijer (of all people) should know that the law of the excluded middle is not a theorem in the type theories that he advocates?
Actually, it uses a 10-ary tree, which has O(log n) lookup, update, etc with a pretty low constant factor. Or, at least, that's what it does now.
It doesn't have to be this way. Haskell has O(1) arrays, but they live in a monad (either ST or IO) if they're not read-only. Plus, of course, Haskell has lazy evaluation, so read-only arrays are not necessarily as read-only as you might think.
Without knowing more details (and since I'm just some random guy on the Internet, you probably don't care enough to give details, so that's cool) it's difficult to say if you really needed imperative arrays for your algorithm, or you only thought you did because that's what the Visual Basic prototype used. Most people don't learn pure functional data structures in their undergrad classes, so they not always the solution which springs to mind when you have a problem to solve.
NEVER EVER try to build an editor in a structured language. Functional languages are a poor fit for procedural tasks.
This is good advice, right up to the point where you need to implement "undo". At that moment, you learn why non-destructive data structure manipulation is an excellent idea.
But have you ever tried to express an n-length array and process it in a functional language?
You're going to need to expand on this. Pretty much every functional language I know (and I know a lot of them) has support for arrays, either in the language or in a library.
Just look at "modern art" - it's hideous, silly, or both. No modern artist could hold a candle to any of the old masters or even the Neo-impressionists.
Do you know how many "old masters" there were in any given century? The answer is: roughly the same as the number of "masters" in the 20th century, per capita. The only reason you're saying this is that most of the crap from the Renaissance has been culled and forgotten. For every Caravaggio, there are a dozen or more painters that you've never heard of whose work nobody preserved, or it languishes in a vault, or sits on the wall next to the Caravaggio where nobody gives it a second look, because there's a Caravaggio right next to it.
On the other hand, it's true that if you look at the stuff in a modern art gallery, much of it is not recognisable as art to someone who has not studied art. If you look at the stuff going down a catwalk in Milan, much of it is not recognisable as clothes to someone not immersed in the world of fashion. If you listen to the stuff in the 21st century classical section of your favourite music outlet, much of it is not recognisable as music if you have no grounding in 20th century classical music. Pop over to Terry Tao's blog, and much of it is not recognisable as maths from the point of view of somebody who has not studied maths beyond the high school level. Hell, programs in Haskell or Agda are not recognisable as "programs" if your education and career consists of doing CRM systems in C# or Java.
Do you know why this is the case? Because this the nature of innovation. This is how we get great new things. People must try a lot of new ideas, and most of them must fail utterly. History and failing memory culls the crap for us, and we end up with both a lot of good old stuff, and a sense of nostalgia which increasingly diverges from reality-as-it-was.
A preferable alternative might be to ask registered voters to take a knowledge test that apportions a greater/lesser weight to their vote in proportion to their score.
That always seems like a good idea, but every time it's been tried in the United States, it's basically been a tool for minority voter suppression.
Slashdot Mirror
+1, Good taste
I don't know if you saw the photo, but credited is "writer Lawrence Kasdan". That detail pushed my optimism level up by quite a bit.
The open source community didn't find it either. If it's any consolation, the NSA is probably about as competent as we are.
Uhm... where did you get that I didn't know this?
For the record, Simula appeared in 1967, so "the 1960s" is accurate.
OOP became mainstream in 1991. We know it to the year, because that was when OOAD by Booch was published. Between 1967 and 1991, there was a steady trickle of new programming languages with Simula-style objects. After 1991, they almost all did, or had support for emulating them. We're talking 25 years of lead time between initial research and adoption.
Functional programming, in a sense, predates computers, but as far as programming languages go, it does go back to Lisp in 1958. There has been a steady trickle of functional programming languages since then, but the time in history when almost all languages are getting language support is right about now. C# got lambdas in 2007, C++ in 2011, and Java in 2014.
Of course, these aren't fundamentalist functional languages, but they're not fundamentalist OO languages either.
Name three, with actual quotations please.
What I think you'll actually find is that a number of academics were pushing symbolic computing as an important future trend, and at the time, Lisp was the only game in town.
I think you're using a different sense of "uses storage" than I am. The map and reduce phases of map-reduce transform abstract data into abstract data, and it is the framework which turns this into a process which transforms storage into storage. The whole point of map-reduce is that it's cheaper to move code around cluster than to move data. As soon as the map and reduce tasks share data, performance is lost.
First off, you're assuming that it's academics who make the unsubstantiated bold claims about the "next big thing". In my experience, a few academics are like that, but most aren't. Academics generally know their own limitations, especially when it comes to predicting the future.
But more crucially, when it does come to predicting the future, academics are wrong at about the same rate as entrepreneurs are. This is the nature of innovation: You must try a lot of things, knowing that most of them will fail.
Like map/reduce at Google.
Well... I kind of have to agree, in that it's true that it has been said. However, it's not true that this means anything either way.
I remember when transputers were the next big thing. People older than I probably remember when perceptrons were the next big thing. People talk crap, and functional programming has been around for a while, so it's inevitable that some subculture has considered it "the next big thing" for a while, along with everyone else who thinks that something else is "the next big thing".
I don't know who those people are, because I don't listen to them, but Erik Meijer is not one of them. Actually he's making a sort-of opposite point, namely, that in the world of many-core and big-data, "almost" pure functional programming (which is almost all functional programming) is useless.
Yes, I think that the main lasting contribution of NBG is the language. Today we would talk about the "category of all sets" or the "category of all locally small categories", rather than "proper classes".
But it doesn't scale to the truly big, which is kind of Meijer's point. Those responsible for the NSA mass surveillance system have been reassuring you of its "mostly secure" nature for almost a year now, but I think we know that doesn't work in practice.
One thing I was going to mention but didn't (because it would have confused things) is that this is true but slightly misleading:
Sets are unstructured, but programming language types have structure. This is part of the reason why modern thinking is to ground programming language semantics in the language of category theory. If nothing else, the "carrier sets" of types must be computable sets, and the mappings between them must be computable functions.
You are not expected to understand this.
If you got that impression from TFA, then I can actually understand how you got it. Meijer's article was written for people already using not-fully-pure functional languages, where "class" means something slightly different than it does in a Simula-style OO language.
The term "class" comes from von Neumann–Bernays–Gödel set theory. Naive set theory had issues like Russell's Paradox, which relies on notions like the "set of all sets". To remove this paradox, NBG set theory distinguishes between a "set" and a "class" (i.e. a collection of sets defined by a property they have in common). Some classes are sets, and some are not. A set is a collection of values, but a "class" is a collection of sets.
In programming language theory, a "type" can be thought of as a set of values (e.g. "boolean" might be the set {true, false}). A "class" is a collection of types.
When you write class Foo in (say) Java, you're actually doing three separate things.
In the Haskell class system, these three things are separated. This is why Haskell classes look more restrictive than classes that you might find in Java: a Haskell class only contains the parts that make it a class, not the parts that make it a type.
Did that help?
So you didn't read TFA either, then?
"Real world business software developers" are those whose code ends up on The Daily WTF.
But seriously, welcome to the future. In the 1960s, "real world business software developers" thought that all this "object" stuff was a bunch of academic gobbeldygook at worst, or niche tool for people doing scientific simulations at best, rather than anything that would be useful with their hard-nosed COBOL. And in a sense, they were right. How would it help you speed up the overnight bank transaction updates? It probably wouldn't.
This "academic rambling" probably won't help you write your business software today, but it just might help you avoid becoming obsolete tomorrow. Thankfully, you probably won't need to learn it until tomorrow.
Am I the only person whose first thought on reading the headline was that Erik Meijer (of all people) should know that the law of the excluded middle is not a theorem in the type theories that he advocates?
Actually, it uses a 10-ary tree, which has O(log n) lookup, update, etc with a pretty low constant factor. Or, at least, that's what it does now.
It doesn't have to be this way. Haskell has O(1) arrays, but they live in a monad (either ST or IO) if they're not read-only. Plus, of course, Haskell has lazy evaluation, so read-only arrays are not necessarily as read-only as you might think.
Without knowing more details (and since I'm just some random guy on the Internet, you probably don't care enough to give details, so that's cool) it's difficult to say if you really needed imperative arrays for your algorithm, or you only thought you did because that's what the Visual Basic prototype used. Most people don't learn pure functional data structures in their undergrad classes, so they not always the solution which springs to mind when you have a problem to solve.
This is good advice, right up to the point where you need to implement "undo". At that moment, you learn why non-destructive data structure manipulation is an excellent idea.
You're going to need to expand on this. Pretty much every functional language I know (and I know a lot of them) has support for arrays, either in the language or in a library.
[citation needed]
Do you know how many "old masters" there were in any given century? The answer is: roughly the same as the number of "masters" in the 20th century, per capita. The only reason you're saying this is that most of the crap from the Renaissance has been culled and forgotten. For every Caravaggio, there are a dozen or more painters that you've never heard of whose work nobody preserved, or it languishes in a vault, or sits on the wall next to the Caravaggio where nobody gives it a second look, because there's a Caravaggio right next to it.
On the other hand, it's true that if you look at the stuff in a modern art gallery, much of it is not recognisable as art to someone who has not studied art. If you look at the stuff going down a catwalk in Milan, much of it is not recognisable as clothes to someone not immersed in the world of fashion. If you listen to the stuff in the 21st century classical section of your favourite music outlet, much of it is not recognisable as music if you have no grounding in 20th century classical music. Pop over to Terry Tao's blog, and much of it is not recognisable as maths from the point of view of somebody who has not studied maths beyond the high school level. Hell, programs in Haskell or Agda are not recognisable as "programs" if your education and career consists of doing CRM systems in C# or Java.
Do you know why this is the case? Because this the nature of innovation. This is how we get great new things. People must try a lot of new ideas, and most of them must fail utterly. History and failing memory culls the crap for us, and we end up with both a lot of good old stuff, and a sense of nostalgia which increasingly diverges from reality-as-it-was.
That always seems like a good idea, but every time it's been tried in the United States, it's basically been a tool for minority voter suppression.
It's generally known today that anthropogenic climate change is a thing (and a bad thing at that).
So you mean the first film will be an awesome fresh take on the franchise, and the second will be a ham-fisted sexist attempt at fan service?
Right now the US spends the highest proportion of GDP on health care of any developed country, and in return gets consistently mediocre outcomes. I bloody well hope costs will be reduced.