A better analog than fixing a literal car might be changing the tire of a car which doesn't have any tires when it is parked but which instantiates some with the help of an instance of ITireFactory. Obviously it makes no sense for a car to use a tire factory instead of just having tires. That is exactly how everyone who prefers PHP feels about everything.
There are far better solutions to this ITireFactory problem than PHP, which puts the tires directly onto the car, but forces you to buy a new car as soon every time you get a flat.
Also, the tires are likely to explode every 16 left turns unless you know about the secret tire fixing button under the dash.
It is true that PHP may save people a few hours in the beginning, but at what expense? How longer does it really take to get a noob running a Sinatra, web.py, dancer or something similar?
I don't think that those problems are really independent, but rather, share a common cause with some of the things that made PHP a success. PHP evolved as it did in large part because its benevolent dictator refused to think about more than one problem at a time. I don't argue that that's the optimal way to do things, but it did provide a unique experiment for us all to learn from.
I confess to making the mistake many times of thinking that I was capturing a value when I was capturing a variable, but the author has me confused and concerned that the semantics of lambdas have been changed such that a lambda always captures the value and not the variable. Capturing variables is darn useful and more general than capturing values. It would be totally unlike MS to break all of my code as much as I wish they would in other cases, so I'm going to assume that they've done something more clever than that.
They haven't actually changes the lambda code at all, they have only changed the fact that previously the foreach variable was declared outside the loop, now it is declared inside the scope. The lambda still closes over the loop variable. If you code your own loop, feel free to declare the loop entities anywhere you like.
Exactly, I also find it a bit confusing. I assume they are capturing variables (it would be crazy otherwise!) but they treat loop variables differently (as if a new variable was created every time).
I'd also be afraid they'd put lobbying efforts into state legislatures to make home grown text books illegal or set standards that are difficult to meet for teachers and which are easy for big publishers.
And the only "classic" mentioned was "War and Peace". I haven't read that one but I've read Anna Karenina, also by Tolstoy, and a few of Dostoevsky's books. Yeah they're long, but they're long like concept albums are long. They're classics 'cause they're awesome, not 'cause some imaginary egghead wants to bore you with them!
I find this deliciously ironic. I can hear myself arguing as a sophomore CS student, "but whatever is going on that constitutes the mind is observably a process on information that happens entirely inside your skull, of course we can model it with software," to which I would today answer "you can model any phenomena with software, stating as such doesn't constitute a model."
The global namespace in PHP is awesome. I don't have to learn a framework to solve a problem, there's a function for it.
Namespace qualifiers in names are a fine solution to the collision problem. That's effectively what's there already except every darn function has to be in a module.
Names don't have to be treated like property, you can invoke policy on them and change bad names. His dreams about rich metadata probably include version tags and hashes that would prevent this from silently breaking anything or in a way that couldn't be repaired by a tool.
Modules don't solve the problem you think they do, they just make the name of all functions longer and harder to figure out. They're not hierarchical.
He addressed issues of visibility/encapsulation and gave a great example of where modules fail to solve the problem. Though I don't quite follow his suggested fix, it looks like using lexical scope to encapsulate fib/3 but my Erlang is actually a bit rusty.
> Names don't have to be treated like property, you can invoke policy on them and change bad names.
A lot of PHP projects involve working with existing components or apps. Some of these use the global namespace with very obvious names, eg. phpBB's User, CodeIgniter's Session. Try and combine two components that use the same obvious names, and everything explodes in a giant mess of E_ERROR.
(It's the same deal with globally-scoped constants:
He is probably imagining that the name of that function would be "nameofproject_assign_user_activity/2", and that you would typically use it along with some others from the same source, following some conventions. Seems that obviates modules to me. In Erlang you give the name of the module with a function anyway, so names like that harm nothing. It would be real nice to type "map" instead of "lists:map" though.
Sure . . . I mean, C doesn't exactly have namespaces, and neither did PHP at first, and you can write code in them, so it's not that it's somehow not possible to uniquely name functions. But it's pretty annoying, and I'd say that many people who are used to modules and namespaces miss them when they move to a world that doesn't have those things. They exist as A) syntactic sugar, so that you can just say assign_user_activity() instead of my_company_my_project_assign_user_activity and B) as a strong organizing principle (potentially that has tooling around it). The former point is just annoying; my argument was that the latter is really the point of modules or namespaces.
Maybe I want to find all the functions related to assignment: how do I do that? Do I just look on disk? Do I use tags or metadata? Do I assume some naming convention? It's a problem you have to solve somehow, and solving it requires effort, because it's an explicit organizational effort. Modules or namespaces or packages or classes give you a way to say "this stuff goes together" and to encapsulate and abstract large units of related functionality, and to do so in a way that tools and programs understand. In a Java IDE, my IDE will auto-complete all the functions on a class; in a REPL I can just print out all the methods on an object. That's a useful organizing principle, and it's one that you lose if you totally flatten the namespace.
You could argue that organization isn't one-dimensional or hierarchical, which is what namespaces and such force on you, and it's a reasonable statement. But replacing it with nothing explicit and relying on extensive developer metadata and documentation so you can search for things? That seems even more idealistic. When was the last time you saw every single function, even private ones, documented and tagged so correctly and up-to-date on a real-world, large-scale project that you'd rely on them to serve as the only organizing principle in your application?
I use both .NET and the LAMP stack everyday. I love .NET and C# is a beautiful language. But I have to use Windows to use .NET. There is nothing wrong with Windows, except it doesn't have a very good shell; it doesn't come with the GNU user land; I can't just grep and sed and awk on one line to solve problems and answer questions; when I google for help with stuff like mysql I don't find near as many answers that would apply to windows; I can't just type "apt-get install ..." somewhere to try out a new programming language or other large program for free; I can't solve problems with SSH. All of these problems can be solved to a large extent, but not in a well known, well documented and Free way. Maybe that's just a matter of culture, but until the not-artificially-limited version of Windows can be downloaded for free, I can't give it a fair try.
I don't think that strong typing is bad, but I would like to point out that from his point of view, arguments FOR strong typing are based on the premise that "everyone is stupid."
Orthogonally, you don't have assume that everyone is stupid for it to be a good idea to design things as though everyone is stupid, because the fractional slice of attention and working memory that the user can easily spare is effectively a moron. This argument applies easy to issues of usability, but for programming, it may equate to driving a car with blinders on. I don't really know.
From my point of view, the main arguments for strong typing are that everyone makes mistakes, and that your tests might not be as complete as you would like (due to time pressure, or whatever else).
