PHP: Cracks in the foundation(phpadvent.org)
phpadvent.org
PHP: Cracks in the foundation
http://phpadvent.org/2011/cracks-in-the-foundation-by-gwynne-raskind
76 comments
> A real dev can pick up a new language and syntax in a week
No, that's complete bull. A real dev can pick up syntax in a week (or a day), but integrating concepts and techniques he's never seen so far and building up new instincts which correctly fit the new language, that does not happen in a week unless the guy is in the "genius" category.
What you really have after a week is a guy who writes $previous_language code in a new syntax. In the way "Real Programmers" can write Fortran in any language.
No, that's complete bull. A real dev can pick up syntax in a week (or a day), but integrating concepts and techniques he's never seen so far and building up new instincts which correctly fit the new language, that does not happen in a week unless the guy is in the "genius" category.
What you really have after a week is a guy who writes $previous_language code in a new syntax. In the way "Real Programmers" can write Fortran in any language.
It's totally true that it takes time for your idioms to catch up with the capability of the syntax. Maybe the big (and common) mistake the parent is talking about, though, is assuming that because a given programmer knows Blub but doesn't know Blam (generic language with some semantics either not supported, under-supported, or not often used in Blub), they will find the concepts in Blam strange and difficult to adapt to. They may already be familiar with a similar concept or even writing something like Blam-flavored Blub.
I'm a latecomer to the Ruby game, and have done a lot of PHP and JavaScript over the last 10 years (though those are far from the only languages I know and have worked in). It's been funny to see what kind of assumptions that means other devs make about what Ruby concepts are going to be big steps for me. I was told by some people that blocks would be a revelation and that metaclass manipulation would melt my brain. But blocks map pretty directly to the familiar concept of passing around functions, and metaclass hacking onto things present in Perl and JavaScript that I'd sometimes wished I'd had in PHP.
Similarly, Haskell and Erlang -- while significantly different from the languages I've used most of my professional life -- both feel pretty familiar after a long-ago stay in the land of Prolog.
I understand the impulse to assume you know something about a developer from the languages they claim proficiency in -- and the impulse to assume that devs who don't know the languages your revelations have come in haven't had those revelations. Generally, for example, I don't think particularly well of a lot of my fellow PHP devs. But when it comes time to make serious judgments like hiring, rather than asking them which languages they know, I want to look at whether they understand certain semantics at a language-independent level, I want to know what they like about the languages they know, what they'd add to the language if they could, and what they'd take away.
I'm a latecomer to the Ruby game, and have done a lot of PHP and JavaScript over the last 10 years (though those are far from the only languages I know and have worked in). It's been funny to see what kind of assumptions that means other devs make about what Ruby concepts are going to be big steps for me. I was told by some people that blocks would be a revelation and that metaclass manipulation would melt my brain. But blocks map pretty directly to the familiar concept of passing around functions, and metaclass hacking onto things present in Perl and JavaScript that I'd sometimes wished I'd had in PHP.
Similarly, Haskell and Erlang -- while significantly different from the languages I've used most of my professional life -- both feel pretty familiar after a long-ago stay in the land of Prolog.
I understand the impulse to assume you know something about a developer from the languages they claim proficiency in -- and the impulse to assume that devs who don't know the languages your revelations have come in haven't had those revelations. Generally, for example, I don't think particularly well of a lot of my fellow PHP devs. But when it comes time to make serious judgments like hiring, rather than asking them which languages they know, I want to look at whether they understand certain semantics at a language-independent level, I want to know what they like about the languages they know, what they'd add to the language if they could, and what they'd take away.
blocks may map onto function passing in JavaScript at a high level, but they also do some things that are different in important ways.
Most notably, all code in Ruby blocks, including return, super, and yield, execute as if in the original context. This means that you can return from inside a block, and it will return from the original method the block was created in.
This is especially useful for custom iterators. In contrast, code inside a "built-in iterator" (for and while loops) in JavaScript is executed in the original scope, while code in a custom iterator (forEach, map, etc) is executed in a new scope.
This makes custom iterators in JavaScript clumsier to use than the same in Ruby. ES6 adds a way to implement custom iteration in JavaScript that hooks into the for construct, but the benefit of this feature is not limited to iterators.
Further, the new JavaScript iterators cannot be used to implement functionality like map and reduce (take a look at Ruby's Enumerable module for other examples), they essentially hardcode a forEach construct into the language, which is useful, but is not the same.
Edit: Just to be clear, the point of this comment is to illustrate that even in a case like functions/blocks, the mapping that people do can stick them in the idiomatic mindset of another language. Ruby's compliance with Tennet's correspondence principle (x ~ lambda x) creates many new opportunities for block use that may be missed by people familiar with function passing in a non-correspondence language like JavaScript.
Most notably, all code in Ruby blocks, including return, super, and yield, execute as if in the original context. This means that you can return from inside a block, and it will return from the original method the block was created in.
This is especially useful for custom iterators. In contrast, code inside a "built-in iterator" (for and while loops) in JavaScript is executed in the original scope, while code in a custom iterator (forEach, map, etc) is executed in a new scope.
This makes custom iterators in JavaScript clumsier to use than the same in Ruby. ES6 adds a way to implement custom iteration in JavaScript that hooks into the for construct, but the benefit of this feature is not limited to iterators.
Further, the new JavaScript iterators cannot be used to implement functionality like map and reduce (take a look at Ruby's Enumerable module for other examples), they essentially hardcode a forEach construct into the language, which is useful, but is not the same.
Edit: Just to be clear, the point of this comment is to illustrate that even in a case like functions/blocks, the mapping that people do can stick them in the idiomatic mindset of another language. Ruby's compliance with Tennet's correspondence principle (x ~ lambda x) creates many new opportunities for block use that may be missed by people familiar with function passing in a non-correspondence language like JavaScript.
"blocks may map onto function passing in JavaScript at a high level, but they also do some things that are different in important ways."
Didn't mean to imply they're in every way analogous anymore than I meant to imply that Haskell and Prolog are virtually identical. :)
Mostly I was looking for an example of a concept where other programmers seemed to think it was likely I'd've had limited exposure to and perhaps even trouble wrapping my head around (passing code) until I'd done it the same language where they'd come to understand/use it (Ruby).
"the point of this comment is to illustrate that even in a case like functions/blocks, the mapping that people do can stick them in the idiomatic mindset of another language."
If the keyword there is can, I don't disagree, both in the specific and general case. I know that even subtle differences between semantics can be important to both expressiveness and idiomatic constructs, I think it's credible that habit often results in trying to carry idioms over, and that a programmer who is only taught the syntax of Blam could be writing Blub in it for a while.
What I don't agree with some developers on is that this is a matter of constraint instead of trajectory -- that the languages a programmer already knows necessarily indicate the difficulty they'll have with adapting to differences and wielding them effectively.
To work with your example, it may be a decent guess that it might never occur to someone who hasn't worked in a purely TCP language to return or yield from inside a passed block, but I have my doubts that it'd be any kind of reliable predictor of how quickly they could wield the concept after explaining that it's kosher and showing an example where it's advantageous.
Didn't mean to imply they're in every way analogous anymore than I meant to imply that Haskell and Prolog are virtually identical. :)
Mostly I was looking for an example of a concept where other programmers seemed to think it was likely I'd've had limited exposure to and perhaps even trouble wrapping my head around (passing code) until I'd done it the same language where they'd come to understand/use it (Ruby).
"the point of this comment is to illustrate that even in a case like functions/blocks, the mapping that people do can stick them in the idiomatic mindset of another language."
If the keyword there is can, I don't disagree, both in the specific and general case. I know that even subtle differences between semantics can be important to both expressiveness and idiomatic constructs, I think it's credible that habit often results in trying to carry idioms over, and that a programmer who is only taught the syntax of Blam could be writing Blub in it for a while.
What I don't agree with some developers on is that this is a matter of constraint instead of trajectory -- that the languages a programmer already knows necessarily indicate the difficulty they'll have with adapting to differences and wielding them effectively.
To work with your example, it may be a decent guess that it might never occur to someone who hasn't worked in a purely TCP language to return or yield from inside a passed block, but I have my doubts that it'd be any kind of reliable predictor of how quickly they could wield the concept after explaining that it's kosher and showing an example where it's advantageous.
I totally agree - there's also the point about a language's eco-system. For example, Perl has CPAN and CPAN brings with it conventions, issues and quirks that take a good few months to (gradually) learn.
It does depend which other languages they've previously been exposed to. I'd argue that once you've seen Haskell, common lisp, APL and Forth, there aren't many new concepts that any language is going to throw at you that you can't relate back to something you've seen before. It doesn't take a genius to get that much exposure, just curiosity, patience and time.
So far in my limited experience the rule still holds: If you drop a Haskell programmer into Blub they may well try to write Haskell-flavored Blub for a while. I've seen it happen.
I think you're misapprehending the problem. It's not that Haskell programmers can't understand the structure of Blub. Gods, no. It's that it takes time and tolerance to be able to immerse oneself in the Blub culture. Blub has its way of doing things, much of which is more accidental than logical, and alas, much of what passes for colloquial Blub is probably stuff that Haskell was specifically designed to avoid like the plague. There's an initial tendency to either run around waving one's arms like Jeremiah, trying to convert the Blub programmers to the side of Light, or to take to drink in despair at the sheer Rabelaisian sloppiness of the Blub universe. To work through this takes time, and possibly therapy.
It's like anthropology. It's one thing to be a linguist and work your way through library books about the syntactic structure of a family of languages from New Guinea, but it's another thing to be airdropped into New Guinea itself, insinuate yourself into a local village, pray you don't die of any tropical diseases, learn which compliments in your native language are actually mortal insults in your new host culture, try to laugh along with the natives when they convince you to lean against a tree filled with stinging ants, and simulate exquisite happiness when your host offers up a delicious sample of the local insects. It's a cultural problem. Not everyone is up for that experience. One may have to work through a certain amount of shock.
I think you're misapprehending the problem. It's not that Haskell programmers can't understand the structure of Blub. Gods, no. It's that it takes time and tolerance to be able to immerse oneself in the Blub culture. Blub has its way of doing things, much of which is more accidental than logical, and alas, much of what passes for colloquial Blub is probably stuff that Haskell was specifically designed to avoid like the plague. There's an initial tendency to either run around waving one's arms like Jeremiah, trying to convert the Blub programmers to the side of Light, or to take to drink in despair at the sheer Rabelaisian sloppiness of the Blub universe. To work through this takes time, and possibly therapy.
It's like anthropology. It's one thing to be a linguist and work your way through library books about the syntactic structure of a family of languages from New Guinea, but it's another thing to be airdropped into New Guinea itself, insinuate yourself into a local village, pray you don't die of any tropical diseases, learn which compliments in your native language are actually mortal insults in your new host culture, try to laugh along with the natives when they convince you to lean against a tree filled with stinging ants, and simulate exquisite happiness when your host offers up a delicious sample of the local insects. It's a cultural problem. Not everyone is up for that experience. One may have to work through a certain amount of shock.
I agree it's largely culture, but I think there are some technical issues that go with the culture as well (which are sometimes the reason for some cultural elements). Even someone who solidly understands OOP, for example, may not know all the many specific gotchas and possible pain points of C++ if they haven't written a lot of it, and some of the cultural conventions common in C++-land were developed because of awareness of those gotchas, and in an attempt to minimize them. C++ is probably a limit case because it's so large and has so many interacting features that there's a lot of accidental complexity, so just knowing the PLs concepts only takes you so far, but I think many languages have some similar things.
Heck, even ye olde C has a whole litany of detailed spec edge cases you need to know about if you want to understand the finer points and avoid some nasty pitfalls (and an even bigger list if you go to C+POSIX).
Heck, even ye olde C has a whole litany of detailed spec edge cases you need to know about if you want to understand the finer points and avoid some nasty pitfalls (and an even bigger list if you go to C+POSIX).
Oh, I agree, and we're actually talking about the same thing. We're just defining the word culture with different scopes. My scope was, approximately, "anything about C++ that you really need to know to write idiomatic C++ code and interact productively with your C++ coworkers and community, but which you didn't learn from that Introduction to C++ for Lisp Nerds book that you skimmed last weekend."
Clearly not a hard-and-fast definition. The more "proper" scope of the word culture is, of course, ultimately a giant philosophical issue which I intend to blithely handwave away. ;)
(I suppose one could try to argue that all of C++ is a cultural artifact, and C and assembly for that matter, but sooner or later you'll reach the Turing machine, which if you chip away at it you'll soon discover is just the tip of an iceberg which consists of all of mathematics, and then folks like Plato will turn up on the battlefield looking for a fight and holy cow, look at the time, gotta run.)
Clearly not a hard-and-fast definition. The more "proper" scope of the word culture is, of course, ultimately a giant philosophical issue which I intend to blithely handwave away. ;)
(I suppose one could try to argue that all of C++ is a cultural artifact, and C and assembly for that matter, but sooner or later you'll reach the Turing machine, which if you chip away at it you'll soon discover is just the tip of an iceberg which consists of all of mathematics, and then folks like Plato will turn up on the battlefield looking for a fight and holy cow, look at the time, gotta run.)
I'd say the APL experience alone also requires a significant bit of masochism. And while you'll be able to relate to things you've seen before, concepts alone are not sufficient to be proficient in the language, as I noted:
> concepts and techniques he's never seen so far and building up new instincts
"techniques" and "instincts" have to do with the language's idioms, tools and ecosystems. The tools (libraries) and part of the ecosystem may be similar to ones you knew, but you'll still need to learn the new ones. The idioms may very well be brand new.
To use a real-world example, while they're fundamentally based on the same concepts (class-based OO, dynamic single dispatch) Python is not Java [http://dirtsimple.org/2004/12/python-is-not-java.html]. And acquiring Python "instincts" after a significant time of Java is not easy. It's not hard either, but it's not the "5 days to complete proficiency" necro asserts. And those are ultimately very similar languages.
> concepts and techniques he's never seen so far and building up new instincts
"techniques" and "instincts" have to do with the language's idioms, tools and ecosystems. The tools (libraries) and part of the ecosystem may be similar to ones you knew, but you'll still need to learn the new ones. The idioms may very well be brand new.
To use a real-world example, while they're fundamentally based on the same concepts (class-based OO, dynamic single dispatch) Python is not Java [http://dirtsimple.org/2004/12/python-is-not-java.html]. And acquiring Python "instincts" after a significant time of Java is not easy. It's not hard either, but it's not the "5 days to complete proficiency" necro asserts. And those are ultimately very similar languages.
There's definitely some truth to this and I've seen it myself. Nonetheless, there is a point where these languages begin to have more similarities then differences. By the time I felt comfortable with C, Java, PHP and Ruby it only took me a couple of weeks to feel like I had a decent handle on Python.
That said, I'm sure there are a lot of Python specific techniques that still elude me and I continue to read through the source for libraries I'm using.
That said, I'm sure there are a lot of Python specific techniques that still elude me and I continue to read through the source for libraries I'm using.
So you are on the side of those relativist who think that all languages are equals or have their own fields of use where they are better than others, and that syntax doesn't matter, that indented or bracketed blocks are just a matter of taste, that cleanliness and homogeneity of syntax and grammar is subjective?
I dare to differ. Hiring a dev for things web, I could ask what language they prefer and why. Someone saying he prefers PHP because it is clean and well organised would get a downvote. If he says it is because it is fast, and that the dirtiness can be avoid by proper training, that would be better. To someone who'd say Ruby, I'd ask what he dislikes about it, or is there any pitfalls. If he knows of no pitfalls, I would have a downvote. Someone saying he don't care at all, would have a double downvote. A good answer would probably be "I'm happy to work with any language but if I have to build something new and can choose the technology I would consider python because I like this tool very much and I'm quite seasoned with it".
Same with code editor: Engineers, developers are using tools and if they have a little bit of a love affair with their job, which is necessary if one want to work hard creating a nice product, they probably have some strong feelings about these tools, which are not all made equal before God.
I dare to differ. Hiring a dev for things web, I could ask what language they prefer and why. Someone saying he prefers PHP because it is clean and well organised would get a downvote. If he says it is because it is fast, and that the dirtiness can be avoid by proper training, that would be better. To someone who'd say Ruby, I'd ask what he dislikes about it, or is there any pitfalls. If he knows of no pitfalls, I would have a downvote. Someone saying he don't care at all, would have a double downvote. A good answer would probably be "I'm happy to work with any language but if I have to build something new and can choose the technology I would consider python because I like this tool very much and I'm quite seasoned with it".
Same with code editor: Engineers, developers are using tools and if they have a little bit of a love affair with their job, which is necessary if one want to work hard creating a nice product, they probably have some strong feelings about these tools, which are not all made equal before God.
I regret I have but one upvote to give to your comment. :)
Instead I'll add this:
"Whenever I interview a candidate I always work in some variation of a very simple question: 'How would you change your favorite programming language to make it better?'
"I don’t really care what the answer is (that is, I don’t mind if we disagree). However, I care very much that people think critically about the tools that they use and love."
http://blog.fogus.me/2011/04/26/my-favorite-interview-questi...
Instead I'll add this:
"Whenever I interview a candidate I always work in some variation of a very simple question: 'How would you change your favorite programming language to make it better?'
"I don’t really care what the answer is (that is, I don’t mind if we disagree). However, I care very much that people think critically about the tools that they use and love."
http://blog.fogus.me/2011/04/26/my-favorite-interview-questi...
You don't need 5 years of experience in any single language to have a solid understanding of the fundamentals of computing and programming.
I'd rather hire someone that can give you an approximate assembly of a C function (as executed by a CPU), understand how XML documents are stored in memory for efficient querying and parsing, know how to avoid cross-domain browser security problems, have an understanding of multithreading (locks, semaphores, race conditions, etc) and an application of recursion in some other language. I wouldn't care what the knowledge is, as long as it is well rounded and demonstrates that the candidate is capable of pulling apart complex systems to gain a deep understanding in a short period of time. The ability to reason (with passion and authority) about which language or pattern is best suited to a given scenario is also vital.
Time is a terrible measure, partly because it fails to recognise that 5 years of bad/shallow/incorrect experience is worse than 2 weeks of gaining a deep understanding of a new language/pattern.
I'd rather hire someone that can give you an approximate assembly of a C function (as executed by a CPU), understand how XML documents are stored in memory for efficient querying and parsing, know how to avoid cross-domain browser security problems, have an understanding of multithreading (locks, semaphores, race conditions, etc) and an application of recursion in some other language. I wouldn't care what the knowledge is, as long as it is well rounded and demonstrates that the candidate is capable of pulling apart complex systems to gain a deep understanding in a short period of time. The ability to reason (with passion and authority) about which language or pattern is best suited to a given scenario is also vital.
Time is a terrible measure, partly because it fails to recognise that 5 years of bad/shallow/incorrect experience is worse than 2 weeks of gaining a deep understanding of a new language/pattern.
To echo your sentiment, It's a bit like measuring writers not by the books they have written, but how long they've sat in front of a keyboard.
Anecdotally, Not only is time a a poor measure of ability, those who use it as such demonstrate a lack of accomplishment. Compare those who write "N years of Language X" vs "Wrote A,B,C in Z using ...".
I find "I've used X for N years" to mean "I've done one year of X over and over and over" :-)
Anecdotally, Not only is time a a poor measure of ability, those who use it as such demonstrate a lack of accomplishment. Compare those who write "N years of Language X" vs "Wrote A,B,C in Z using ...".
I find "I've used X for N years" to mean "I've done one year of X over and over and over" :-)
I think we're getting at the same thing. The time example is used as a comparative generalization that there is a need to focus and understand the fundamentals. The point being that given some period of time, if an average individual chooses to learn 10 languages at once, they probably wont master the fundamentals, compared to mastering those in one language. Of course there is the side case that comparing different languages and their patterns will actually be even more valuable in overall understanding, I would have to side that one first needs a deep enough understanding for that to be an advantage.
"A real dev can pick up a new language and syntax in a week,"
This sentiment is true for many languages, as the difference between them is not conceptual, merely syntax and some details.
Learning a programming language that uses different concepts and not just different syntax (e.g: Haskell, Ocaml) will take significantly longer (and IMO will be worth it).
This sentiment is true for many languages, as the difference between them is not conceptual, merely syntax and some details.
Learning a programming language that uses different concepts and not just different syntax (e.g: Haskell, Ocaml) will take significantly longer (and IMO will be worth it).
> This sentiment is true for many languages, as the difference between them is not conceptual, merely syntax and some details.
Even when the core conceptual difference is small and looks like "merely syntax and some details", different languages use different idioms, different standard tools and different methods, usually with reasons (stated or not) behind that. It's the idea behind PJE's (fairly old by now) "Python is not Java": going from Java to Python, the differences look superficial. You declare classes differently, names don't have types and methods are preceded by `def`.
Yet if you just translate your Java code into Python 1:1, you usually end up with an unmaintainable and slow morass, and although the core abstractions are the same Python and Java offer different toolsets to deal with actual problems.
Even when the core conceptual difference is small and looks like "merely syntax and some details", different languages use different idioms, different standard tools and different methods, usually with reasons (stated or not) behind that. It's the idea behind PJE's (fairly old by now) "Python is not Java": going from Java to Python, the differences look superficial. You declare classes differently, names don't have types and methods are preceded by `def`.
Yet if you just translate your Java code into Python 1:1, you usually end up with an unmaintainable and slow morass, and although the core abstractions are the same Python and Java offer different toolsets to deal with actual problems.
> A real dev can pick up a new language and syntax in a week ...
So am I not a real developer because it took me longer than a week to get a hang of Haskell? Hell, it even took me many months before I understood JavaScript well enough to find the right mix of patterns and practices to write solid code in it.
So am I not a real developer because it took me longer than a week to get a hang of Haskell? Hell, it even took me many months before I understood JavaScript well enough to find the right mix of patterns and practices to write solid code in it.
There's a definite difference between "pick up the syntax" of a language that doesn't have (m)any new concepts to wrap your head around versus learning new concepts embedded in a language.
Javascript has closures and functions-as-first-class-objects. Haskell has monads and all that jazz (I haven't used it yet). I'm guessing you didn't take months to learn the syntax of javascript, but to think in javascript.
It's similar to the difference between being functional in a natural language versus being fluent in said language.
Javascript has closures and functions-as-first-class-objects. Haskell has monads and all that jazz (I haven't used it yet). I'm guessing you didn't take months to learn the syntax of javascript, but to think in javascript.
It's similar to the difference between being functional in a natural language versus being fluent in said language.
necro said pick up the language and syntax -- I took "the language" part to mean the concepts of the language outside of the explicitly mentioned syntax. With that said, I felt addressing his comment was necessary since writing idiomatic code is not something that should be expected from a weeks worth of experience in a language.
In essence, I'm agreeing with everything you said, just wanted to clarify the reason for my post.
In essence, I'm agreeing with everything you said, just wanted to clarify the reason for my post.
"Pick up the syntax in a week" is a huge black flag in my book because it indicates the developer doesn't really understand why his paycheck shows up every 2 weeks. Expertise is learning an environment's vernacular, gotchas, and detailed ins-and-outs of the frameworks/apis. It has nothing to do with passing a Programming Language 101 class.
It took me months to feel like I wasn't doing something dumb every time I coded in Clojure. There are exceptions to every rule!
It;s funny. I get asked what language requirements people should have about hiring LedgerSMB developers. And I say this:
1) If you can, find someone with good, demonstrable SQL and PL/PGSQL experience.
2) If you can't find that, get someone who is competent in developing on Oracle.
"What?" comes the reply, "Don't they need to know Perl?"
I tell them that the use of Perl we have is getting more minimalistic and simpler, and that we are trying to make it so any competent developer can pick it up quickly.
The same would go if I was writing something similar in PHP. The issue is what sorts of fundamentally different technologies you can address, and the extent to which you feel comfortable working in both declarative, set-oriented worlds and object oriented approaches. The syntax on top of that is really less of an issue.
1) If you can, find someone with good, demonstrable SQL and PL/PGSQL experience.
2) If you can't find that, get someone who is competent in developing on Oracle.
"What?" comes the reply, "Don't they need to know Perl?"
I tell them that the use of Perl we have is getting more minimalistic and simpler, and that we are trying to make it so any competent developer can pick it up quickly.
The same would go if I was writing something similar in PHP. The issue is what sorts of fundamentally different technologies you can address, and the extent to which you feel comfortable working in both declarative, set-oriented worlds and object oriented approaches. The syntax on top of that is really less of an issue.
Well yeah, if you're moving all of your business logic into the database you're going to want DB-centered people.
EDIT: login -> logic
EDIT: login -> logic
We don't move all logic into the database. Presentation logic, for example, is certainly not there. Also there are things like sales tax which cannot reasonably be put there.
The thing though is that one can always get a consultant to do sales tax logic. The big thing is if you know SQL and HTML the rest can come easily enough.
The thing though is that one can always get a consultant to do sales tax logic. The big thing is if you know SQL and HTML the rest can come easily enough.
Didn't know Rails was a language... interesting. I'll take someone that writes down ruby on their resume over the same rails experience any time!
By the same token, someone who writes "ruby" with only Rails experience is not off to a good start.
That is the scary part isn't it. I'm sure only ruby users exist and that's awesome, but I would wager that most ruby users in the web field are rails users, and many blur where one starts and the other begins.
> PHP, being a language intended for beginners,
I've never heard this before. PHP is certainly very easily picked up by beginners, and in my own opinion makes it easy for said beginners to spend years and years not moving very far beyond beginner-level architectural patterns (just look at the source of Wordpress for an example), but do the creators of PHP really consider it to be "a language for beginners" ?
I have an entirely selfish agenda here. The next time some know-nothing manager promises his client "we have the top programmers with years of experience who will write the highest quality code you can get", then demands that we do everything in PHP because that's all he knows, we can say, "really? You're going to charge the client all that money, then give the client an app written in a "beginner" programming language ?"
I've never heard this before. PHP is certainly very easily picked up by beginners, and in my own opinion makes it easy for said beginners to spend years and years not moving very far beyond beginner-level architectural patterns (just look at the source of Wordpress for an example), but do the creators of PHP really consider it to be "a language for beginners" ?
I have an entirely selfish agenda here. The next time some know-nothing manager promises his client "we have the top programmers with years of experience who will write the highest quality code you can get", then demands that we do everything in PHP because that's all he knows, we can say, "really? You're going to charge the client all that money, then give the client an app written in a "beginner" programming language ?"
All else being equal (i.e. assuming equal functionality and performance), customers would prefer code that's written in "beginner" programming languages. Customers don't always know many things about code, but every single one of them knows how to count money, and they fantasize about replacing their maintenance staff with a bunch of beginners. Hiring competent beginners is difficult enough.
An important aspect of this problem: Even if the overall system is too complicated for beginners to understand, beginners may be able to usefully tinker with the system if it is built out of parts that they understand. The problem with PHP-based systems is that their most complicated parts may need to be built out of PHP, but the bonus is that all their simple parts are also built out of PHP, and often the bulk of the maintenance boils down to tinkering with the simple parts.
An important aspect of this problem: Even if the overall system is too complicated for beginners to understand, beginners may be able to usefully tinker with the system if it is built out of parts that they understand. The problem with PHP-based systems is that their most complicated parts may need to be built out of PHP, but the bonus is that all their simple parts are also built out of PHP, and often the bulk of the maintenance boils down to tinkering with the simple parts.
This is very important.
Code that is simple is easy to maintain. This is not to say that simplicity wins over the use of complex design patterns and abstractions in every scenario. It's a trade-off that needs to be considered on a case-by-case basis.
This is especially true in the open source arena where it is critical that new developers can come along and read, understand and improve existing code. Code that is too complex will not be understood and will almost certainly lead to errors.
Code that is simple is easy to maintain. This is not to say that simplicity wins over the use of complex design patterns and abstractions in every scenario. It's a trade-off that needs to be considered on a case-by-case basis.
This is especially true in the open source arena where it is critical that new developers can come along and read, understand and improve existing code. Code that is too complex will not be understood and will almost certainly lead to errors.
> do the creators of PHP really consider it to be "a language for beginners" ?
Yes. Andi Gutmans, Zend co-founder and PHP developer says:
“the right way to think about PHP is as Visual Basic for the Web.”
http://www.tbray.org/ongoing/When/200x/2006/10/31/Zend-PHP-C...
Yes. Andi Gutmans, Zend co-founder and PHP developer says:
“the right way to think about PHP is as Visual Basic for the Web.”
http://www.tbray.org/ongoing/When/200x/2006/10/31/Zend-PHP-C...
Personally I think there are better languages for beginners than PHP. I think Javascript, Perl, Python, and more are fundamentally better in this regard. There are some fundamental, lexical problems with PHP in this regard. I think by a "language intended for beginners" I think it is meant as "a language intended to allow HTML/SGML authors to cross over into programming."
PHP is in essence a fairly narrow tool, much like a chasing hammer (which really isn't that good for driving nails but is extremely important in some kinds of metal work). It is a preprocessor for SGML files (and this is why all programming logic is typically put in SGML PI tags). I call it a "templating system turned on its head" because whatever you do with PHP, every file is lexically part of the template even those which have no other SGML tags other than the PI tag which is indicating programming logic.
But what this means is it works very well in its own specific domain (namely preprocessing HTML, XML, and other SGML files), but degrades quite a bit as one gets out of this area. This limits code reuse basically to web apps (yes, I know you can write GTK apps in PHP, but really? why on earth would you want to?) and thus locks one into essentially one set of technologies. So there are drawbacks as well as advantages.
PHP is in essence a fairly narrow tool, much like a chasing hammer (which really isn't that good for driving nails but is extremely important in some kinds of metal work). It is a preprocessor for SGML files (and this is why all programming logic is typically put in SGML PI tags). I call it a "templating system turned on its head" because whatever you do with PHP, every file is lexically part of the template even those which have no other SGML tags other than the PI tag which is indicating programming logic.
But what this means is it works very well in its own specific domain (namely preprocessing HTML, XML, and other SGML files), but degrades quite a bit as one gets out of this area. This limits code reuse basically to web apps (yes, I know you can write GTK apps in PHP, but really? why on earth would you want to?) and thus locks one into essentially one set of technologies. So there are drawbacks as well as advantages.
Totally agree. In addition, PHP is a freely available, incredibly pervasive language that can be installed and run on even the most inexpensive web hosts. There is almost no messy configuration or server setup to be done.
So for a beginner web developer, all they need is a GoDaddy account and a couple tutorial guides.
The sad thing is that many developers stop here. They don't go on to figure out how PHP and Apache work together, how memory gets used and how to manage it effectively. They don't get exposure to proper coding standards (PHP's common standards are horrible IMO). And more often then not, a PHP developer learns how to code in isolation.
Coding should be developed as a mentored skill.
So for a beginner web developer, all they need is a GoDaddy account and a couple tutorial guides.
The sad thing is that many developers stop here. They don't go on to figure out how PHP and Apache work together, how memory gets used and how to manage it effectively. They don't get exposure to proper coding standards (PHP's common standards are horrible IMO). And more often then not, a PHP developer learns how to code in isolation.
Coding should be developed as a mentored skill.
PHP is indeed a "templating system turned on its head" (according to second-hand reports from a talk by Rasmus Lerdorf, PHP was originally designed as a bare-bones templating system for C programmers, but then more and more stuff migrated into the templating system...). And it is, indeed (or was, anyway) tied strongly to a single domain, and a limited set of architectural patterns.
But every design choice cuts both ways. These features are not merely drawbacks. These are PHP's strengths, the things that make it so delicious for "HTML authors who need to cross over into programming".
You can learn PHP with Google. My understanding is that most people do. [1] Just Google all your problems and up will pop some code that you can mimic. This works because, to first order, all PHP code is solving the same problem in the same way. You will probably not accidentally Google up some PHP-based physics simulation. You will probably not Google up some PHP code used by sysadmins to parse the output of pipes on the command line. You will certainly not Google up any PHP-based graphics algorithms or device drivers or client-side DOM manipulations or Android system functions. No, when you Google "how to do X in PHP" you'll get some code that you can paste into a template with a .php extension and then execute on your cheap shared host. Until fairly recently there wasn't even any danger of encountering object-oriented PHP.
You can argue that programmers trained in this way are useless for anything but cobbling together Web pages, and you're right, but 90% of them don't care. Web pages are a killer app. People build whole businesses out of cheesy web pages.
My suspicion is that many PHP tinkerers don't want more "architectural flexibility"; that translates into "decisions that we have to make but don't know how to make", "knobs that we have to set carefully but which we don't even know how to turn", and "oodles of online documentation for use cases that we don't have, which chaffs up the search results for the use cases that we do have."
The irony, of course, is that PHP's maintainers have been hard at work bolting features from other languages onto PHP, which as a side effect threatens to destroy the narrow domain-specificity that was its most unique feature. [2] Objects, namespaces, closures have all been welded onto the superstructure. One wonders what happens next. Maybe the folks who embrace all these things will drag the entire PHP community closer to Java, Python, Ruby, or some oddball superposition of these things. But I think it more likely that the community will continue to balkanize, with the bulk of users rejecting all these transplants but certain segments embracing one or another of them.
---
[1] I learned PHP via reading and hacking on Drupal modules, which is a much better plan, but also definitely not the beginner-friendly choice. Drupal has a steep learning curve.
[2] Though don't blame the maintainers too much: These features are in fact in demand, from the people who took up PHP without realizing that it was a narrow domain-specific language and pushed it right up to the limits of the available hacks.
But every design choice cuts both ways. These features are not merely drawbacks. These are PHP's strengths, the things that make it so delicious for "HTML authors who need to cross over into programming".
You can learn PHP with Google. My understanding is that most people do. [1] Just Google all your problems and up will pop some code that you can mimic. This works because, to first order, all PHP code is solving the same problem in the same way. You will probably not accidentally Google up some PHP-based physics simulation. You will probably not Google up some PHP code used by sysadmins to parse the output of pipes on the command line. You will certainly not Google up any PHP-based graphics algorithms or device drivers or client-side DOM manipulations or Android system functions. No, when you Google "how to do X in PHP" you'll get some code that you can paste into a template with a .php extension and then execute on your cheap shared host. Until fairly recently there wasn't even any danger of encountering object-oriented PHP.
You can argue that programmers trained in this way are useless for anything but cobbling together Web pages, and you're right, but 90% of them don't care. Web pages are a killer app. People build whole businesses out of cheesy web pages.
My suspicion is that many PHP tinkerers don't want more "architectural flexibility"; that translates into "decisions that we have to make but don't know how to make", "knobs that we have to set carefully but which we don't even know how to turn", and "oodles of online documentation for use cases that we don't have, which chaffs up the search results for the use cases that we do have."
The irony, of course, is that PHP's maintainers have been hard at work bolting features from other languages onto PHP, which as a side effect threatens to destroy the narrow domain-specificity that was its most unique feature. [2] Objects, namespaces, closures have all been welded onto the superstructure. One wonders what happens next. Maybe the folks who embrace all these things will drag the entire PHP community closer to Java, Python, Ruby, or some oddball superposition of these things. But I think it more likely that the community will continue to balkanize, with the bulk of users rejecting all these transplants but certain segments embracing one or another of them.
---
[1] I learned PHP via reading and hacking on Drupal modules, which is a much better plan, but also definitely not the beginner-friendly choice. Drupal has a steep learning curve.
[2] Though don't blame the maintainers too much: These features are in fact in demand, from the people who took up PHP without realizing that it was a narrow domain-specific language and pushed it right up to the limits of the available hacks.
Completely agreed. Hence the chasing hammer metaphor. You wouldn't use a chasing hammer to drive nails, but you wouldn't use a carpenter's hammer for chasing either. These are strengths, but they ensure that PHP is a relatively specialized tool.
A language used by beginners is not the same as one designed for beginners.
I would wager that a language designed for beginners wouldn't have so much inconsistency, nor dump the user in a world of security issues with little or no support (XSS, CSRF, SQL injection).
Other people have worked around these issues, but that demonstrates the lack of support within the language.
I would wager that a language designed for beginners wouldn't have so much inconsistency, nor dump the user in a world of security issues with little or no support (XSS, CSRF, SQL injection).
Other people have worked around these issues, but that demonstrates the lack of support within the language.
Agreed, PHP is not beginner friendly even if it might seem so at first.
The lack of built-in XSS prevention in PHP makes it quite terrible as templating language, especially for beginners who probably have never heard of XSS. The same applies to the simplciity of string interpolation combined with the terrible built-in MySQL driver which makes parametrized queries harder than they should be. All this used to be even more confused by the Magic Quotes in previous versions of PHP.
With so many security traps it is not a language I would recommend for beginners who just want to build something that works.
The lack of built-in XSS prevention in PHP makes it quite terrible as templating language, especially for beginners who probably have never heard of XSS. The same applies to the simplciity of string interpolation combined with the terrible built-in MySQL driver which makes parametrized queries harder than they should be. All this used to be even more confused by the Magic Quotes in previous versions of PHP.
With so many security traps it is not a language I would recommend for beginners who just want to build something that works.
...beyond beginner-level architectural patterns (just look at the source of Wordpress for an example)...
Can you expand on this, specifically as it relates to WordPress? I work with WordPress, so I'm curious as to what about it you'd consider beginner-level architectural patterns.
(And FWIW, I'm not trying to start an argument - I'm actually genuinely wanting to learn, thus my question)
Can you expand on this, specifically as it relates to WordPress? I work with WordPress, so I'm curious as to what about it you'd consider beginner-level architectural patterns.
(And FWIW, I'm not trying to start an argument - I'm actually genuinely wanting to learn, thus my question)
Not having worked with WP in a couple of years, I actually downloaded the latest wordpress to see what the code looks like these days just to see if it had been improved much (edit: before I posted my original post). For each line of code, you can roll the dice - is this line part of the presentation, is it part of application logic, or is it part of the scaffolding ? It's essentially random on a line by line basis.
Example ? Check out this file:
http://core.svn.wordpress.org/trunk/wp-admin/edit-comments.p...
there, you will see SQL statements, tons of application logic, as well as HTML output rendering. A large amount of the HTML rendering is additionally not templated but rather a long line of imperative string concatenation calls. It's all the worst examples of what PHP has encouraged, all in one file. The enormous quantity of source files present in Wordpress, most of them non-self-explanatory, is a product of this style of design.
Example ? Check out this file:
http://core.svn.wordpress.org/trunk/wp-admin/edit-comments.p...
there, you will see SQL statements, tons of application logic, as well as HTML output rendering. A large amount of the HTML rendering is additionally not templated but rather a long line of imperative string concatenation calls. It's all the worst examples of what PHP has encouraged, all in one file. The enormous quantity of source files present in Wordpress, most of them non-self-explanatory, is a product of this style of design.
wow.. that's hideous.. thanks for that link!
This list seems a bit tired.
There are a couple of things in here that are actual issues, but they seem small in scope, and easy to work around.
As for the is_a changes, I think it's probably for the better, as they say, you have to break some eggs to make an omlette. Also, the article first complains about not having Unit Tests to catch this, and then later complains about it being ignored on release. Ultimately unit tests are great for refactoring, but when code is actually being changed, some sort of process needs to be followed for that (dictatorship, consensus building, anarchy?)
I program in PHP, and we don't depend on too many outside libraries. And for cases where we do, we will simply fix these issues.
It used to be that upgrading PHP was much 'easier' to do, meaning you'd just go out and do it, and would hardly breaking anything (at least in my experience). However lately it seems that the risk is higher. However I welcome this, because it means the language is progressing and we're getting a lot of additional things. For all the projects I've worked on, we make sure the code works with that version of PHP. Unit/integration/regression/selenium/using it on development for awhile/whatever are all valid things to do, if you have issues you fix them and move on.
5.3 was great, excited for 5.4 with traits as well. It's a great time to be writing PHP.
There are a couple of things in here that are actual issues, but they seem small in scope, and easy to work around.
As for the is_a changes, I think it's probably for the better, as they say, you have to break some eggs to make an omlette. Also, the article first complains about not having Unit Tests to catch this, and then later complains about it being ignored on release. Ultimately unit tests are great for refactoring, but when code is actually being changed, some sort of process needs to be followed for that (dictatorship, consensus building, anarchy?)
I program in PHP, and we don't depend on too many outside libraries. And for cases where we do, we will simply fix these issues.
It used to be that upgrading PHP was much 'easier' to do, meaning you'd just go out and do it, and would hardly breaking anything (at least in my experience). However lately it seems that the risk is higher. However I welcome this, because it means the language is progressing and we're getting a lot of additional things. For all the projects I've worked on, we make sure the code works with that version of PHP. Unit/integration/regression/selenium/using it on development for awhile/whatever are all valid things to do, if you have issues you fix them and move on.
5.3 was great, excited for 5.4 with traits as well. It's a great time to be writing PHP.
The array/sorting things are sometimes just things developers will have to deal with until someone makes new methods and deprecates the old ones.
I used to think that the code base needed to be perfect, no extra cruft, only code that's necessary, switch parameter order just to make things match. However in doing so it adds a tremendous amount of pain and risk. My OCD does't want to handle it, and it's always good to strive to get to that point, but ultimately nothing is perfect, so might as well deal.
I used to think that the code base needed to be perfect, no extra cruft, only code that's necessary, switch parameter order just to make things match. However in doing so it adds a tremendous amount of pain and risk. My OCD does't want to handle it, and it's always good to strive to get to that point, but ultimately nothing is perfect, so might as well deal.
PHP has already proven itself time and time again. There are lots of high-traffic websites running PHP successfully. Yes, it's easy to make a simple script and get it running fast, but you can also engineer complex OO applications.
One of the reasons I've stayed away from things like rails is because it puts too many layers on top of things like the database.
I've known a few developers that use Django or Rails and have no idea how things work underneath. This is a disadvantage. Especially if you need to do something like optimize a database query and to do so, you have to actually change the framework that maps SQL to an object.
One of the reasons I've stayed away from things like rails is because it puts too many layers on top of things like the database.
I've known a few developers that use Django or Rails and have no idea how things work underneath. This is a disadvantage. Especially if you need to do something like optimize a database query and to do so, you have to actually change the framework that maps SQL to an object.
The problem with your statement is the equivalent developer is extremely common in the PHP world. There's tons of people who hack on WordPress or Drupal and 'have no idea how things work underneath'. It's probably the majority of people with "PHP" on their resume.
As a "Drupal Developer" I can verify this is so true. It makes hiring competent developers in this space nearly impossible. Most of the people that I compete against know how to barely cobble together a couple modules and think that putting some hackey PHP code into a view field (which is stored in a database) is "coding".
Or that coding of any sort is some how not "The Drupal Way". I despise these people.
I would counter, however, that any developer who can accurately explain from start to finish how Drupal handles a request is worth their salt.
Or that coding of any sort is some how not "The Drupal Way". I despise these people.
I would counter, however, that any developer who can accurately explain from start to finish how Drupal handles a request is worth their salt.
I call bullshit on your Drupal FUD. You can't code effectively for Drupal without a robust grasp on basic PHP, SQL and the Drupal suite of hooks. You better have some serious OO chops too or integration with stuff like Views is going to eat your face.
Yeah, but mainly because Drupal is a pile. CCK & custom forms seems about four times more complicated than just doing it in raw PHP. So that is not necessarily taking anything away from the intelligence of the developers, only pointing out they are coding against the abstraction, not the plumbing.
Still I'd bet the majority of 'Drupal developers' are just folks who know what the right modules are & some customization tricks.
Still I'd bet the majority of 'Drupal developers' are just folks who know what the right modules are & some customization tricks.
"Still I'd bet the majority of 'Drupal developers' are just folks who know what the right modules are & some customization tricks."
My anecdotal evidence based on five years of working with the CMS indicates you'd lose that bet, but whatever.
My anecdotal evidence based on five years of working with the CMS indicates you'd lose that bet, but whatever.
Woah. You're not arguing his point. He's saying there are people that hack at drupal without having a clue as to what's going on. He's not suggesting that is coding effectively at all. But that doesn't mean they aren't there, searching for specific strings, and spending 5 hours with trial and error before stumbling on a correct solution.
I've known a few developers that use Django or Rails and have no idea how things work underneath. This is a disadvantage.
Seriously, that's not even an argument, it's an anecdote of dubious validity.
My personal experience as a rails developer has been that most of the people I've worked with know SQL quite well, and are fully capable of writing straight SQL when required.
Really though, I'm only offering a counter-point. If you truly want to make the case that NOT_YOUR_FRAMEWORK_DEVELOPERS are ignorant, please prove it statistically or find a forum other than hacker news to flame on.
Seriously, that's not even an argument, it's an anecdote of dubious validity.
My personal experience as a rails developer has been that most of the people I've worked with know SQL quite well, and are fully capable of writing straight SQL when required.
Really though, I'm only offering a counter-point. If you truly want to make the case that NOT_YOUR_FRAMEWORK_DEVELOPERS are ignorant, please prove it statistically or find a forum other than hacker news to flame on.
"Seriously, that's not even an argument, it's an anecdote of dubious validity."
I don't have to prove anything. This is why I started it out with "I've know a few developers".
"NOT_YOUR_FRAMEWORK_DEVELOPERS are ignorant, please prove it statistically or find a forum other than hacker news to flame on."
You are one of the problems with hacker news right now. I was merely stating my opinion. Nowhere did I say "all developers". Just because my opinions is different than yours doesn't mean I am trolling or flaming.
Also, when assembly went out of style and c became popular, less and less developers knew how things worked at a lower level. It makes sense that the same thing will happen with frameworks and libraries that are at a higher level.
I don't have to prove anything. This is why I started it out with "I've know a few developers".
"NOT_YOUR_FRAMEWORK_DEVELOPERS are ignorant, please prove it statistically or find a forum other than hacker news to flame on."
You are one of the problems with hacker news right now. I was merely stating my opinion. Nowhere did I say "all developers". Just because my opinions is different than yours doesn't mean I am trolling or flaming.
Also, when assembly went out of style and c became popular, less and less developers knew how things worked at a lower level. It makes sense that the same thing will happen with frameworks and libraries that are at a higher level.
Okay what is the point of your comment then? The thing you cite as a problem has nothing to do with any framework. It's just stating that ignorant developers are a problem.
There could be a discussion about the distribution of ignorant developers but you claim not to want to get into that. So what were you trying to say?
There could be a discussion about the distribution of ignorant developers but you claim not to want to get into that. So what were you trying to say?
How to Disagree: http://www.paulgraham.com/disagree.html
I've never really understood this argument. Yes, it's a disadvantage to "have no idea how things work underneath". But why can't you know how things work underneath and still use the abstraction layer? You can even log the SQL queries it generates, and drop down to custom SQL queries if necessary. If you're paying attention to what's going on "underneath", what is the problem with using abstractions that remove some boilerplate?
"You can even log the SQL queries it generates, and drop down to custom SQL queries if necessary. If you're paying attention to what's going on "underneath", what is the problem with using abstractions that remove some boilerplate?"
In most of the frameworks I've seen, to do so means to hack around the base framework. It's also much faster to just write the correct query in the first place rather than logging every query from the framework and trying to change them for each situation that requires optimization.
In most of the frameworks I've seen, to do so means to hack around the base framework. It's also much faster to just write the correct query in the first place rather than logging every query from the framework and trying to change them for each situation that requires optimization.
> In most of the frameworks I've seen, to do so means to hack around the base framework.
ActiveRecord [1][2] and Django [3][4] both feature logging sql and dropping down to custom sql out of the box, so I'm not sure which frameworks you had to hack around to accomplish that but those are the two examples you used in your OP.
> It's also much faster to just write the correct query in the first place rather than logging every query from the framework and trying to change them for each situation that requires optimization.
In my experience, 90% or more of the generated queries are fine, there's just a few that need rewriting. And it's not like it takes a lot of cognitive overhead to glance at a console to see what queries are being executed while you're testing that new feature you just added. For me, it's certainly less overhead than writing all of them myself.
[1] http://weblog.jamisbuck.org/2007/1/8/watching-activerecord-d...
[2] http://api.rubyonrails.org/classes/ActiveRecord/Base.html#me...
[3] https://docs.djangoproject.com/en/dev/topics/logging/#django...
[4] https://docs.djangoproject.com/en/dev/topics/db/sql/#django....
ActiveRecord [1][2] and Django [3][4] both feature logging sql and dropping down to custom sql out of the box, so I'm not sure which frameworks you had to hack around to accomplish that but those are the two examples you used in your OP.
> It's also much faster to just write the correct query in the first place rather than logging every query from the framework and trying to change them for each situation that requires optimization.
In my experience, 90% or more of the generated queries are fine, there's just a few that need rewriting. And it's not like it takes a lot of cognitive overhead to glance at a console to see what queries are being executed while you're testing that new feature you just added. For me, it's certainly less overhead than writing all of them myself.
[1] http://weblog.jamisbuck.org/2007/1/8/watching-activerecord-d...
[2] http://api.rubyonrails.org/classes/ActiveRecord/Base.html#me...
[3] https://docs.djangoproject.com/en/dev/topics/logging/#django...
[4] https://docs.djangoproject.com/en/dev/topics/db/sql/#django....
Well, RoR is living on Mysql defaults turd planet and therefore thinks Foreign Keys are a DRY thing and not a database optimization. So I'm pretty sure anybody with more than a trivial Rails app is manually indexing those columns. Either that or they are spending way more on their database than they should be.
I think the fundamental problem is that Rails is based on active hostility towards database engineering. It's the same thing that MySQL did early on. It works very well in some cases but has a serious cost attached that few people want to talk about, namely the fact that things suddenly become problematic when you want to use the RDBMS to effectively share data between diverse applications. The thing is that once you make this tradeoff, I wonder whether it is really that helpful to stick with an RDBMS at all, or whether NoSQL is a better option.
Good point, however at least ActiveRecord doesn't make the mistake of trying to utterly hide SQL from the user. Since moving to arel in Rails 3.0 things are very clean, logical, and not trying to do to much. It's not particularly hostile to serious SQL developers even if it doesn't have proper language-level tooling for advanced SQL.
I think it's still a clear win over NoSQL where a one-size-fits-all solution is simply impossible and would send Rails off into the weeds.
I think it's still a clear win over NoSQL where a one-size-fits-all solution is simply impossible and would send Rails off into the weeds.
But you have an inherent tradeoff in ORM-land., You can either essentially build your database as an object store around your ORM or you can build your database and do real SQL coding. But at that point why use an ORM like Active Record at all?
> But at that point why use an ORM like Active Record at all?
Automatic type conversion and packaging of "rows" into hashes or objects, so you don't have to handle date parsing or integer conversions by hand and can call your utility methods or return your instances to whoever needs them.
That's basically all Rails's `ActiveRecord::Base.find_by_sql` or Django's `Manager.raw` (linked to by murz) do.
That's also the core/most basic layer of SQLAlchemy, and it's perfectly possible to use only that: SQLAlchemy has an Expression Language which is a direct translation of SQL into Python expressions[0] and an ORM built on top of that[1], and using just the expression language is perfectly OK if that's what you want.
[0] http://www.sqlalchemy.org/docs/core/tutorial.html
[1] http://www.sqlalchemy.org/docs/orm/tutorial.html
Automatic type conversion and packaging of "rows" into hashes or objects, so you don't have to handle date parsing or integer conversions by hand and can call your utility methods or return your instances to whoever needs them.
That's basically all Rails's `ActiveRecord::Base.find_by_sql` or Django's `Manager.raw` (linked to by murz) do.
That's also the core/most basic layer of SQLAlchemy, and it's perfectly possible to use only that: SQLAlchemy has an Expression Language which is a direct translation of SQL into Python expressions[0] and an ORM built on top of that[1], and using just the expression language is perfectly OK if that's what you want.
[0] http://www.sqlalchemy.org/docs/core/tutorial.html
[1] http://www.sqlalchemy.org/docs/orm/tutorial.html
Replying to Masklinn below:
> But at that point why use an ORM like Active Record at all?
Automatic type conversion and packaging of "rows" into hashes or objects, so you don't have to handle date parsing or integer conversions by hand and can call your utility methods or return your instances to whoever needs them.
But this isn't really what I am getting at.
Once you go down the ORM route and that means sacrificing database engineering for use of the ORM (and thus largely making your database into a single application part of the stack), then what benefit do you get from using an RDBMS? Wouldn't NoSQL be better?
And if all you are getting is type conversion and hash<->relation conversion, why not use NoSQL?
The issue is a specific one about a design tradeoff. You can do real db engineering (as high normalization of data as possible based on inherent functional dependencies of the data itself) or you can build your db schema around the object model of your app. If you do the latter, I am not sure you have a compelling reason to use an RDBMS, and if you don't have a compelling reason to use an RDBMS, you don't have a compelling reason to use an ORM at all. After all if I use MongoDB and simply serialize my objects into JSON or the like, then I get the same benefit but with better performance and less opacity.
It seems to me that for an ORM to work the relational structure must be designed around what the ORM expects. Applying an ORM to something like a 5NF database designed for a very different application strikes me as fundamentally problematic.
Is it just that you have the ability to hopefully put in some ad hoc reporting functionality later? What is the benefit?
> But at that point why use an ORM like Active Record at all?
Automatic type conversion and packaging of "rows" into hashes or objects, so you don't have to handle date parsing or integer conversions by hand and can call your utility methods or return your instances to whoever needs them.
But this isn't really what I am getting at.
Once you go down the ORM route and that means sacrificing database engineering for use of the ORM (and thus largely making your database into a single application part of the stack), then what benefit do you get from using an RDBMS? Wouldn't NoSQL be better?
And if all you are getting is type conversion and hash<->relation conversion, why not use NoSQL?
The issue is a specific one about a design tradeoff. You can do real db engineering (as high normalization of data as possible based on inherent functional dependencies of the data itself) or you can build your db schema around the object model of your app. If you do the latter, I am not sure you have a compelling reason to use an RDBMS, and if you don't have a compelling reason to use an RDBMS, you don't have a compelling reason to use an ORM at all. After all if I use MongoDB and simply serialize my objects into JSON or the like, then I get the same benefit but with better performance and less opacity.
It seems to me that for an ORM to work the relational structure must be designed around what the ORM expects. Applying an ORM to something like a 5NF database designed for a very different application strikes me as fundamentally problematic.
Is it just that you have the ability to hopefully put in some ad hoc reporting functionality later? What is the benefit?
Note: If you click the link button you can reply directly even to new posts.
> Once you go down the ORM route and that means sacrificing database engineering for use of the ORM
This is where you're wrong. This is an all-or-nothing argument that isn't based in reality. The reality is you make choices at every level, and an ORM like ActiveRecord doesn't do much to prevent you from using the full database feature set at your disposal. Granted, if you do everything with stored procedures and foreign keys then you won't be able to use all of ActiveRecord's features, but you really can do things any way you want.
> then what benefit do you get from using an RDBMS? Wouldn't NoSQL be better?
Now assuming you lean more in the ActiveRecord direction and don't do much heavy database engineering, why no use NoSQL? Well, take your pick from the usual reasons. RDBMS systems are mature, performant, extremely rich for ad-hoc querying and, easy to administer, etc, etc. Just because ActiveRecord only explicitly uses 20% of the features of the typical RDBMS doesn't mean those features aren't extremely useful per se.
The way I look at it is that using an RDBMS for almost any new project is a smart hedge, because an RDBMS is the most type of flexible data store. It will allow you to pivot more easily compared to a NoSQL store where things may be extremely scalable in the dimension that you foresee, but if you need to pivot your data model you are in for a massive rewrite. People complain about adding columns and indices to SQL databases vs the "agility" of just adding keys to Mongo or whatever, but honestly it's just a little busy work most of the time, it doesn't really hurt until your data gets huge, at which point you are going to be running into unanticipated bottlenecks anyway.
> Once you go down the ORM route and that means sacrificing database engineering for use of the ORM
This is where you're wrong. This is an all-or-nothing argument that isn't based in reality. The reality is you make choices at every level, and an ORM like ActiveRecord doesn't do much to prevent you from using the full database feature set at your disposal. Granted, if you do everything with stored procedures and foreign keys then you won't be able to use all of ActiveRecord's features, but you really can do things any way you want.
> then what benefit do you get from using an RDBMS? Wouldn't NoSQL be better?
Now assuming you lean more in the ActiveRecord direction and don't do much heavy database engineering, why no use NoSQL? Well, take your pick from the usual reasons. RDBMS systems are mature, performant, extremely rich for ad-hoc querying and, easy to administer, etc, etc. Just because ActiveRecord only explicitly uses 20% of the features of the typical RDBMS doesn't mean those features aren't extremely useful per se.
The way I look at it is that using an RDBMS for almost any new project is a smart hedge, because an RDBMS is the most type of flexible data store. It will allow you to pivot more easily compared to a NoSQL store where things may be extremely scalable in the dimension that you foresee, but if you need to pivot your data model you are in for a massive rewrite. People complain about adding columns and indices to SQL databases vs the "agility" of just adding keys to Mongo or whatever, but honestly it's just a little busy work most of the time, it doesn't really hurt until your data gets huge, at which point you are going to be running into unanticipated bottlenecks anyway.
I guess the way I look at it is this:
The relational model excels at exactly one thing: presenting your data in multiple ways for multiple uses. As you start to sacrifice this, the RDBMS starts becoming less useful, fast. A good case in point is something like an LDAP server. Not really a good use case for relational database, though you can export the data into a relational system or even store your master copy there and push out changes. But here you have a protocol that lends itself reasonably well to integration anyway and ad hoc reporting really isn't likely to be an issue.
The way I look at it is that using an RDBMS for almost any new project is a smart hedge, because an RDBMS is the most type of flexible data store. It will allow you to pivot more easily compared to a NoSQL store where things may be extremely scalable in the dimension that you foresee, but if you need to pivot your data model you are in for a massive rewrite. People complain about adding columns and indices to SQL databases vs the "agility" of just adding keys to Mongo or whatever, but honestly it's just a little busy work most of the time, it doesn't really hurt until your data gets huge, at which point you are going to be running into unanticipated bottlenecks anyway.
I am not sure either the cost of this is as great as people suggest, and adding/dropping columns on large tables in PostgreSQL is fast. Rather I think the fundamental issue is that a relational model requires more engineering to leverage than agile folks are usually comfortable with. I am referring of course to the N word (Normalization). The thing about normalization is that the goal is to organize your data based on functional dependencies (relational algebra-wise) within the data model, not functional dependencies (execution-wise) within the application. This means stopping and looking at the data and asking "which values are dependent on which values?" and normalizing that way. The thing is that this means larger numbers of joins and that tables are unlikely to represent the data model of the application directly.
The advantage is then that you can then take your data and use it in a few other applications. The disadvantage is it is very hard to do this in an agile way.
So it seems to me that where RDBMS's are concerned, the smart thing to do is put engineering effort into the database and then try to ensure that agile applications can be built on top of it.
The way I look at it is that using an RDBMS for almost any new project is a smart hedge, because an RDBMS is the most type of flexible data store.
But this takes a willingness to ensure your data is modelled in the db in an application-neutral way (or at least an approximation of application neutrality).
The relational model excels at exactly one thing: presenting your data in multiple ways for multiple uses. As you start to sacrifice this, the RDBMS starts becoming less useful, fast. A good case in point is something like an LDAP server. Not really a good use case for relational database, though you can export the data into a relational system or even store your master copy there and push out changes. But here you have a protocol that lends itself reasonably well to integration anyway and ad hoc reporting really isn't likely to be an issue.
The way I look at it is that using an RDBMS for almost any new project is a smart hedge, because an RDBMS is the most type of flexible data store. It will allow you to pivot more easily compared to a NoSQL store where things may be extremely scalable in the dimension that you foresee, but if you need to pivot your data model you are in for a massive rewrite. People complain about adding columns and indices to SQL databases vs the "agility" of just adding keys to Mongo or whatever, but honestly it's just a little busy work most of the time, it doesn't really hurt until your data gets huge, at which point you are going to be running into unanticipated bottlenecks anyway.
I am not sure either the cost of this is as great as people suggest, and adding/dropping columns on large tables in PostgreSQL is fast. Rather I think the fundamental issue is that a relational model requires more engineering to leverage than agile folks are usually comfortable with. I am referring of course to the N word (Normalization). The thing about normalization is that the goal is to organize your data based on functional dependencies (relational algebra-wise) within the data model, not functional dependencies (execution-wise) within the application. This means stopping and looking at the data and asking "which values are dependent on which values?" and normalizing that way. The thing is that this means larger numbers of joins and that tables are unlikely to represent the data model of the application directly.
The advantage is then that you can then take your data and use it in a few other applications. The disadvantage is it is very hard to do this in an agile way.
So it seems to me that where RDBMS's are concerned, the smart thing to do is put engineering effort into the database and then try to ensure that agile applications can be built on top of it.
The way I look at it is that using an RDBMS for almost any new project is a smart hedge, because an RDBMS is the most type of flexible data store.
But this takes a willingness to ensure your data is modelled in the db in an application-neutral way (or at least an approximation of application neutrality).
I would argue that you're painting "agile" with one brush, except I hate how it's become yet another meaningless buzzword wielded by incompetent management, so I won't.
Also next version of RoR is likely to have auto EXPLAIN for slow queries.
And I use PHP in the same way Django and Rails developers do: with frameworks, ORM's and other libraries that do put abstract layers on top of things like the database.
PHP fully supports these use cases and everything in between. The same is true for Python and Ruby, but their web development ecosystem gravitates much more towards single solutions (Django, Rails).
Yes, that means many Django or Rails developers have a hard time developing outside the box of their framework. However, on the PHP end you often see a lack of knowledge of the tools available and a strong tendency towards "not invented here".
It all comes down to making informed choices. The language doesn't make that much of a difference. Every language allows you to optimize db-access to the point of writing raw SQL queries, and no framework can stop you from leveraging the raw power of the language.
PHP fully supports these use cases and everything in between. The same is true for Python and Ruby, but their web development ecosystem gravitates much more towards single solutions (Django, Rails).
Yes, that means many Django or Rails developers have a hard time developing outside the box of their framework. However, on the PHP end you often see a lack of knowledge of the tools available and a strong tendency towards "not invented here".
It all comes down to making informed choices. The language doesn't make that much of a difference. Every language allows you to optimize db-access to the point of writing raw SQL queries, and no framework can stop you from leveraging the raw power of the language.
However, on the PHP end you often see a lack of knowledge
of the tools available and a strong tendency towards "not
invented here".
In most cases some of these would be covered by half-baked in-house "solutions", and others wouldn't even be dealt with at all. In other cases the current (knowledgeable) team would still be suffering from the sins made by developers past. I eventually gave up and moved to the Ruby world where most of this stuff is taken for granted.
I don't mind PHP's quirks so much anymore; it's more the ecosystem that comes with it that infuriates me.
I think Symfony2 may solve this issue for PHP.
Learning PHP is how I got into web programming, and for that I'll be eternally grateful. Since starting to explore languages like Ruby and Python however, I've been reluctant to use PHP in situations where others are an option, so I'm really glad to hear things are picking up in PHP's development—it can only mean good things for the development community.
But it can be fixed.
Rather than specify a grammer in BISON and generating C code,
write your parser as a recursive descent parser.
Then add some annotations and auto-generate grammar files from the C code.
This is the same principle as generating document using DOXYGEN, the closer the annotation is to the code, the more chance there is of the annotation being correct.
Also, its something you can incrementally.
This is the same principle as generating document using DOXYGEN, the closer the annotation is to the code, the more chance there is of the annotation being correct.
Also, its something you can incrementally.
I havent developed in php in years, but here is my tale on it from my current point of view.
Of this whole article the one thing that jumped out at me was "broken and ignored tests". Being an open source developer myself, I greatly value the tests in every open source project. Nevermind the fact that this is PHP which warrants the use of tests even further because of the various points the author makes.
I hope that going forward the maintainers of the PHP core ensure that every bug fix has a passing unit test along with it. That would at least keep the dam holding back the flood intact.
Of this whole article the one thing that jumped out at me was "broken and ignored tests". Being an open source developer myself, I greatly value the tests in every open source project. Nevermind the fact that this is PHP which warrants the use of tests even further because of the various points the author makes.
I hope that going forward the maintainers of the PHP core ensure that every bug fix has a passing unit test along with it. That would at least keep the dam holding back the flood intact.
Adding tests for bug fixes doesnt necessarily help when your code is in that state. I think you are better off looking for coverage on tests, and trying to write specs eg formalize the parser as mentioned. Probably a lot of tests now are from previous bugs, but the code has drifted and they have not been maintained.
It's all starting to take me back to my youth watching Robotech and remembering the Zentradi, an advanced race with awesome technology and tools that were developed for them generations ago, but none of the understood how any of it worked or how to fix it, they could only use it. If it broke, they just start over with a new copy instead of debugging it. I hope that the our new generation wont end up like that.
I recently interviewed a recent CS grad that had no idea of the correlation of array of characters and pointers to those characters. You know that it's all just addresses to memory, right?
Anyway, of course there are those who truly dissect and get all the languages and their benefits but are few and between.
Give me a dev that "gets it" in one language any day, instead of someone who thinks remembering the function call or some syntax in 10 languages is of value.
If I hire someone here is how I rank them... 1. 5 years experience in C 2. 5 years experience in PHP 3. 5 years experience in Rails 4. 5 years experience in Rails, Python, erlang, java, php, c, other languages dujour.
Ok, there are people that are just picking up PHP and don't know squat, but at least they know they are beginners and are teachable.