Yes, I'm a Ruby fanboy, but this is ridiculous. These days, Ruby and Python are the lingue franche of quick web development. PHP had its heyday, and it's still terribly useful for Drupal-y and MediaWiki-y things... but building something from scratch?
"The only difference is that today it's organized, tested and validated." Unbelievable. Those are the three reasons developing in PHP was such a pain back in 2000: procedural web code was a pain to keep organized, don't even get me started about testing PHP code back then, and at least the projects I was working on suffered from horrible unvalidated feature creep.
Yes, I would say that's the "only" difference. ಠ_ಠ
People bag on PHP a lot (was a truer sentence ever written?). But the fact is that it's fast to prototype with, it has a number of mature frameworks available, and time-to-productivity is quick. That's what business people want -- quick and cheap.
With proper engineering, PHP can be quick, cheap, AND good (see: Facebook. You want to argue the point, fine, but I don't see you becoming a billionaire on the back of your Haskell application).
Like every language, there is an appropriate place for it -- I would probably not write code for the Space Shuttle or a medical device in PHP. But, a great place for a language like PHP is web applications, especially for businesses who have to consider things like hiring people.
> With proper engineering, PHP can be quick, cheap, AND good
This is true for any language. It is also true for any language that poor engineering can make things really bad. PHP is in a unique position, though - it is so easily accessible to non-engineers that they begin writing applications without the slightest idea what they're getting themselves into.
This results in lots of improper engineering, and people blaming the language for the world's problems.
Javascript and Actionscript have this problem too. They get a lot less flack, though, because I think client-side scripting isn't held to the same standards.
I agree with all that, and I think the logical question is - isn't the accessibility a good thing? A lower barrier to entry for programming... that sounds like a great thing to me. Like in any industry, some people will improve with time and some will stay n00bish and produce weak code -- but lowering the barrier to entry seems like a good thing to me.
...yeah, it's got its warts (see wtfjs.com), but it's built on a very solid foundation. It does get a bad rap because of the poor (and inconsistent) design of the DOM, but if you play within its rules it can be very expressive and powerful.
Well, that was a language inconsistency, not an issue with the DOM.
I like working with JS but I don't know why the two operands aren't commutative in my example.
The DOM is a headache but luckily smart people have made plenty of libraries to abstract that away. What we're left with is a language with a very expressive and powerful core like you said, but there are still some oddities.
Having lambda expressions, closures, and being able to construct higher-order functions makes it pretty "functional" in my book. Having to be careful about recursion is a negative, and TCO would be a welcome addition.
It's really a hybrid language. You can do a lot functional stuff with it if you'd like. You can also do a lot of the OO thing with it. Neither is perfect, but if you stick to the "good parts", it's a strong language.
Lambda expressions implies currying because lambdas take only a single argument unless you think of function application as implicitly constructing a tuple of arguments (but JS lacks tuples and only offers maps and arrays). Javascript has first-class anonymous functions, not lambdas.
Closures in JS are broken due to everything being a reference cell by default. This causes closures to be annoying to construct correctly and more expensive than they should be. "Functional" languages typically treat mutation as a side-effect and require reference cells to be explicitly declared. This helps enforce function purity and referential transparency -- functional-ness.
"Being careful about recursion" is like being careful about looping except recursive expressions are a superset of succinct iterative expressions making Javascript weak when it comes to, say, describing state machines. Lack of TCO makes Javascript a terrible compile target as CPS is impossible.
Javascript is an ambiguous, unsafe, difficult-to-analyze language. It supports some constructs that look like constructs in functional languages but because it does not enforce any functional or type systemic restrictions, these features are mostly cargo.
If you write a recursive algorithm in Javascript, you pay like O(n) for stack frames. The same iterative algorithm costs O(1) for stack frames. Thus, many developers eschew recursion in favor of iteration. This means that the logical code that developers write could be both mathematically sound and run efficiently on the machine but instead developers must either resort to temporal reasoning or perform recursion -> iteration transforms in their heads. This is broken.
Just because Javascript is ubiquitous doesn't mean it's good. I don't understand Javascript evangelists -- they seem to be spreading half-truths.
I'm not a Javascript evangelist. I'm the first to admit that it has flaws. Some (like recursion) are fundamentally broken and a trap to unknowing programmers. I think you'd be hard pressed to find anyone with any real javascript experience who says the entire language is perfect.
There are good parts though, and if you stick with them, it's not bad. In fact, it can be a pleasant experience to work with. Just because it's ubiquitous doesn't mean it's all bad.
These debates are always silly at best, and painfully indicative at worst.
Indicative of what exactly? A certain type of nerd (emphasis that I mean a sub group) that is likely to never accumulate wealth or create anything particularly successful on their own because they're too anal-retentive to understand that success in building a Web app or business is not defined by whether you use PHP or Ruby or Python or even ColdFusion.
Unless you think you're the next Facebook or Tumblr, then extreme optimization is necessary. Otherwise, the rest of the discussion is bullshit stacked on top of bullshit.
If the common wisdom were followed, Plenty of Fish should have never existed, given their infrastructure and development approach. And Stack Exchange should have never existed with their 'lame' Win stack (popular opinion of the Windows development environment among a certain class of developers =) ).
There are a lot of ways to 'skin a cat'. The only thing that matters is whether you can get to the finish line, build something people want to use, and perhaps monetize it so you can keep putting resources into making it better. Who gives a shit what you use to get there, just so long as you get there.
> The only thing that matters is whether you can get to the finish line, build something people want to use, and perhaps monetize it so you can keep putting resources into making it better.
Except there is no finish line. I currently work on an application that is 10 years old, where's the finish line? Its not done in PHP, anyways it has parts that were done very sloppily and "against the grain" and the organization is still paying for it with a higher cost of maintenance.
But did it bring the organization more revenue? In the past I've done some things in PHP that were horrible hacks but did help the whole company forward. Doing them right in the existing code base would mean rewriting a lot. Especially one of those hacks has gotten it's revenge on me when making it more flexible later, but in the meantime it did bring us substantial rewards.
To this day i'm still not sure what would be better: telling my boss "sorry, but if we want feature y, it will take 2 months (but it will we done right)" or "yes we can do that in 2 days but don't expect the code to be pretty"
All code is an exercise in living with imperfection. The trick is finding the sweet spots in the scale of imperfection vs. time, which aren't linearly correlated (eg. you can spend a lot of time gold-plating something and make only small gains in reducing imperfection, while on the other end of the spectrum, sometimes investing a little bit of extra time can yield large gains in reducing imperfection).
I'm sure some programming book somewhere has said that in a much more elegant fashion.
There absolutely is a finish line: as in, launch the product.
In fact, there are countless finish lines in business and product development. You're constantly running a new race every development cycle. Trends change, competitors change, the entire landscape can change. Sometimes you're going to find yourself flat footed, and you're going to have to start a whole new race to launch a radically altered product.
It'd be like saying there was no finish line for the iPhone version 1. Of course there was, they had to actually ship it. And every product iteration has a new race to run and a finish line to meet to put the product on a shelf somewhere to be purchased. The same is true with iterating software of any sort, whether you're talking a micro level finish line (adding a feature to Gmail or Firefox 10.1), or a macro level finish line (shipping a completely revamped Firefox version or launching a radically new email concept with GMail beta). Getting from point A (inspiration, idea, task) to point Z (task completed) = finish line.
Try never having a finish line on any task, product, business, etc, and see what happens.
What a pleasant attitude painfully indicative of a certain kind of entrepreneur that can only see green in the world.
You see, what you call a "certain type of nerd" are actually craftsmen who enjoy things done well. You can be all the IKEA you want, and you're surely gonna rack up some interesting profits. But if I'm the kind of furniture maker who enjoys taking 6 months to build the perfect cabinet, you can be sure I'll pay special attention to selecting tools that I love. And none of your monetization arguments are going to count really.
So the bottom line is that PHP vs Ruby vs Python etc is a craftsmen's discussion. (If it's a serious discussion at all, that is - comparing it to Lean Startups isn't a serious discussion.) Bringing arguments like yours to such a setting just makes you look silly (especially when you think it's about "extreme optimization", then you just look like you really have no idea what you're talking about).
It's not a craftsmen's discussion. A craftsman picks the tools they feel the most comfortable with to get the job done.
Sure, craftsmen like to discuss their tools, but as an open exchange about their experiences in order to learn from it, or maybe even simply out of professional curiosity.
The whole "my stack is better than your stack", and the "PHP sucks" thing that is commonplace on HN, proggit and other forums is not a craftsmen's discussion. It's a juvenile playground pissing contest that has nothing to do with craftsmanship.
By the way, anybody who thinks that real crafsmen typically use the "best" tools available has never seen neither an artist nor a plumber at work.
<blink>By the way, anybody who thinks that real craftsmen typically use the "best" tools available has never seen neither an artist nor a plumber at work.</blink>
Should go on top of proggit/hn (yes, including blinking tags :).
By the way, anybody who thinks that real crafsmen typically use the "best" tools available has never seen neither an artist nor a plumber at work.
You are correct that they do not pick the "best" tools, but they will deliberately choose the best tools for the job, as opposed to the most convenient tools to aquire and learn.
"It's a juvenile playground pissing contest that has nothing to do with craftsmanship." Sadly, you've got me there. There's rich conversation to be had on the topic though, could we come up with ways to make that surface out of the current swamp of language debates?
Although they might not use them, they'll talk endlessly about them. I mention in another comment how I've witnessed very long discussions among my photography and cinema friends about the "nerdy" details of their work. But you're right, there's a lot less emotion than in our community :/
You can be all the IKEA you want....selecting tools that I love
Beautiful analogy, expect that it doesn't work here. You could be a craftsman and build an extremely solid and well designed backend. In the end consumers cannot appreciate your backend. A good example is I have no freaking clue what HN is built on. PHP? LISP? RUBBY?
LOL. A broke craftsman ain't no craftsman, he's just an unemployed dude posturing as the real deal. I know plenty of real craftsmen, and none of them waste time bickering on the 'right' shape of chisel or optimal mix of cement and sand, they all judge their peers on the results they produce.
they all judge their peers on the results they produce.
There's a little bit of a mismatch here:
* Posters above are arguing that the end result that programmers are judged upon is revenue.
* You're arguing that the end result that craftsmen are judged upon is quality.
If a plumber is doing a terrible job but is doing well business-wise, I'd expect other plumbers to not look upon them so favourably
I really don't think the issue is judging something based on revenue at all.
There are numerous ways to measure the success of a product. It depends on what it is meant to accomplish.
The real point is: it does not matter what tools you use, so long as you are able to reach success (in any number of ways a person may choose to define it).
You can obviously argue about which tools will best get you there, or give you the best chance to succeed.
I've seen plenty of entrepreneurs or developers, use a tool 85% good enough, to hit a homerun. It's little different than a good plan executed today being better than a perfect plan tomorrow. I believe there are exceptionally few cases in life or business where the '85% good enough' won't do the job. I've yet to see the 100% perfection set actually exist anyway.
It's true that the ultimate judgement comes on the result, but a lot of the arguments around tools have an element of "this allows you to give better results". I've witnessed very long discussions with my photography and cinema friends about the varieties of cameras and other tools they like to use, so I doubt the validity of your statement. I do have to agree that it sounds a lot more intelligent and a lot less like the language bickering we're seeing.
The reason for that brings me back to my original point that there are too many people jumping in the language debates who really have no business being there. It's the equivalent of me trolling my photography friends saying that Sony makes amazing cameras because when I go on vacation I can just whip one out and take a decent shot, whereas the girl who didn't have her 4000$ SLR with her totally missed out on the opportunity. While 100% true, I'm really just derailing their conversation on the relative benefits of their cameras with something completely besides the point.
I didn't say anything about it being bad to enjoy your craft or what tools you use.
I've been dirt poor. Painfully, not actually scratching by, live off of ketchup packets poor. Let's talk about only seeing green some time eh. No matter the cost, I've always chose to do what I loved, and I've paid a helluva price for it at times. I've been an entrepreneur since I was 15. I know a thing or two about the extreme ends of both success and failure.
What I'm saying is: get the job done, whatever it takes. Use whatever tool will accomplish the job for you personally. Don't waste time turning yourself inside out over pedantic debates over 5% efficiencies, while opportunity escapes out the back door.
I wish you had any clue what an entrepreneur actually is. A money making scheme? That's laughable. Spoken like someone that is definitely not an entrepreneur and will never be.
I've been quite successful, thanks. =) Currently I'm sitting on a seven figure net worth, and I'm in my early 30's. How about you? I've also failed plenty, like anybody that has ever attempted anything difficult.
What I've done since I was 15 is build and create web applications that I thought were useful or that I wanted to see exist. Some of them I hoped would become successful businesses, some of them I created for the hell of it. Out of six web businesses I've started, three of those businesses have been successful and both paid for themselves and paid me a healthy income.
I built what is, per Quantcast, likely the world's #1200x largest web site, starting from $50 on a terrible virtual server, using nothing but an 8 year computer, notepad, and a 12 year old FTP program, on a very slow Verizon DSL line. Gee, if only I had used the right tools, lol!
I just closed an investment round with one of the most successful business people on the planet. Unsuccessful indeed eh. As the agreements I've signed permit it, I'll come back here and update on the progress of my new enterprise. We can compare notes, and see how wildly successful you are too.
I wish you had any clue what an entrepreneur actually is. A money making scheme? That's laughable. Spoken like someone that is definitely not an entrepreneur and will never be.
Actually I've started my first company while in university, back in 1999. I sold my share in 2003. The company is still going strong today, and has around 30 employees nowadays (which might not sound much, but I'm from an entirely different country/IT environment). I also work for a startup the last two years, although not as a founder. I'm in my early 30s too, thanks for asking.
The whole "entrepreneur" thing, from the very word "entrepreneur", I find pretentious and silly, sort of like the "hipsterism" of the programming world. Oh, I did this and that, ramen, bla, MVP, bla, Rails, bla, exit, bla, VC round, bla, etc. Just build the thing, and STFU.
I admire people building things, from Steve Jobs to Bill Joy, who didn't run around selling the entrepreneur vibe.
Which, as I see it, is a rather recent fad, maybe a decade old at least in this particular form.
I wish you had any clue what an entrepreneur actually is. A money making scheme? That's laughable. Spoken like someone that is definitely not an entrepreneur and will never be.
Actually I've started my first company while in university, back in 1999. I sold my share in 2003. The company is still going strong today, and has around 30 employees nowadays (which might not sound much, but I'm from an entirely different country/IT environment). I also work for a startup the last two years, although not as a founder. I'm in my early 30s too, thanks for asking.
The whole "entrepreneur" thing, from the very word "entrepreneur", I find pretentious and silly, sort of like the "hipsterism" of the programming world. Oh, I did this and that, ramen, bla, MVP, bla, Rails, bla, exit, bla, VC round, bla, etc. Just build the thing, and STFU.
I admire people building things, from Steve Jobs to Bill Joy, who didn't run around selling the entrepreneur vibe.
Which, as I see it, is a rather recent fad, maybe a decade old at least in this particular form.
Except you called it "bullshit stacked on bullshit". Debates over languages go much deeper than "5% efficiencies", and what I was trying to get at is that depth is beyond an entrepreneur. Not because of an implied hierarchy, but because you have other concerns in life than learning about the intricacies of computer science. It takes real computer scientists and engineers (i.e. the craftsmen) to understand why it's so bad PHP didn't have first-class functions until whatever version.
For you, as an entrepreneur whipping out MVP after MVP until you strike gold, that couldn't matter less, but for those interested it's a big deal. To jump in the middle of their discussion as an uneducated outsider and judge the whole thing as "bs stacked on bs" is... inconsiderate at best.
I don't see how the unstructured development of the past has anything to do with using PHP in startups today. It's not about the language capabilities (90% of business aren't doing anything special in code), but developer speed and happiness. If you're happy with PHP then so be it, but that doesn't make it better.
The part that bugs me the most about the post is when it says "that's what we PHP guys do well: fail fast, fail cheap". Basically what he is stating is:
1) PHP developers are going to hit a wall earlier than other developers
2) PHP developers are cheap in general. How is that a positive statement, I don't know.
There's this stupid belief that by paying less for someone who does "a quick job" you can test a feature and then "build from there". It's bullshit.
From my own experience, I've regretted time and again hiring a cowboy (the fact that he was a PHP dev is not unrelated) developer just because we needed something "quick". What was supposed to be a 10-day deliverable turned into a 4-month mess of a codebase that I couldn't wait to rewrite. We ended up being hostage to our own code.
Maybe it's just me, but I don't think having a crappy development environment is a very good way to build things quickly. Perhaps in the days when there were few stable alternatives, this may have made some sense, but there are so many easy alternatives these days.
Perhaps the PHP community is different now from when I left it a few years ago. I'd never go back to that.
Honest question to the downvoters: All the libraries available at the time I was coding required a day or two of getting lost in documentation before I could use them. Has this changed in the past couple of years?
I'm not a downvoter, but as a Django dev who was forced to grab a quick project in PHP after almost 3yrs not touching it - no, it hasn't changed much. Doc comments and discussion boards are still filled with one gazillion solutions to every simple task, of which most is crap (even when it comes to fresh frameworks). Language features aside, what makes me stay away from PHP is the low quality of it's ecosystem (no offence to the good guys who put quality code out there), especially when you get used to the level of Python solutions and community engagement.
I've just moved from years of PHP to RoR. And there's a lot that I miss about PHP. Deploying Rails Apps is still a motherfucking nightmare - I hanker for the days of just git pulling and changing a couple of config vars. I can google any error message in PHP and find dozens of answers - not so with Rails, where I end up really have to scrabble around for a solution.
But there's also a lot to love about RoR. I just needed to calculate the number of business days between two dates - step forward the business_time gem. Five mins later and I've got a stable, tested solution.
I've built and sold businesses on PHP, I run some sites on it still. But I've never got into testing with PHP, it just isn't seamless. And because of that, I've always hated going back into the code and improving things later - projects have tended to stagnate. With RoR you have to make an effort NOT to write tests, and making minor tweaks isn't like moonwalking across a minefield.
If you just want to whack up a prototype right fucking now then PHP and a Framework are for you. But if you think that you're working on something more than a punt then either put in the effort to write decent tests in PHP, or use a framework that will force you to do so.
In summary - PHP and Yii Framework do almost all of what Rails do. It's fast, stable, clean and easily deployed. But the weight of the developer community is now behind Rails. And Ruby is a neat language that I enjoy working with.
It feels like the longer you develop web applications the less it matters what language you use. I highly recommend experimenting with as many languages as you can because each one has something unique to offer. You are often able to take lessons you learned using one language while using another.
This seems to go a long way with frameworks as well.
I hate Rails. Why? Because of the type of people that make up the community. They defend Rails to the death and won't admit it has any faults. It reminds me of the people that are pro-universal health care. Because of this, I won't use it for any of my projects. I will only start using it when there is no other choice.
I use PHP for almost all web development. However, I'm not against using other languages.
I admit, PHP has its faults, but it's still a great web dev language. PHP 5+ has really added some great OO functionality.
Well, it's the truth in my experience. Very rarely will I ever see anyone that is pro UHC tell me the the things that are wrong with it. Same with the people that love ruby.
I love PHP, but I freely admit there are issues. I love private care, but I also admit it has problems.
It's this sort of intelligent discussions that we need for me to take those sides seriously.
PHP's biggest strength is also it's greatest weakness: flexibility. For a beginning programmer it is great because you can just do simple stuff in minimal number of lines. For advanced programmers it is great because you can build a flexible framework that fits your unique business situations. However, for intermediate programers there is enough flexibility to really write terrible code that somehow works, but could never be maintained.
The key point of the article seems to be embodied in this quote:
So we PHP people are good at failing early, fast and cheap. If you want enterprise grade fail, ask the java guys, if you want scalable fail, ask the c guys. If you want smart fail, ask the clojure guys. But early and cheap, ask us.
The claim here is that one can get to a working product using PHP substantially faster than with other languages. However, the article has no data to back this claim up. Indeed, one of the big goals of newer languages like Clojure, Python, and Ruby (the latter two not being explicitly mentioned) is to write code faster and with fewer errors. Java, while verbose, also has strengths: a great many excellent frameworks and libraries. This is also true for web development (e.g. http://www.playframework.org/). Including C in the argument is a little strange. As far as I've seen, it's one of the least used languages for deploying web applications these days!
In summary, I am wholly unconvinced by the claim of this article. And I say claim as it's missing any substantial argument. Does anyone have any actual data here? There are certainly many case studies for the newer languages and frameworks if you dig a bit. It's an interesting topic.
Articles like this really make it seem like PHP developers have a big chip on their shoulders from all the trash talking that goes on about PHP. I'm a PHP dev and I have to admit, PHP isn't cool. It's thought of as a language for bad programmers because it's so easy for beginners to pick up. That's precisely the reason why I'm a PHP developer to begin with! And boy have I given ammunition to the side that argues that PHP is a "bad programmers language". But oh well. That's really a good thing that total newbies can pick it up in a week like I did some years back.
But really no one cares about your language except other people with chips on their shoulders too. When people use a product they really don't care about the tech specs no matter what the product may be. They care about what it does for them. I can clone Facebook in Runy or Twitter in PHP with both clones being more "optimized" than the original but no one cares. They just want to write on their friend's wall or retweet something so they'll tell me to go to hell with my .235ms improvements in page load times, DB queries, whatever.
A truly good developer doesn't waste time convincing people his stack is best. He proves his skill instead by shipping and iterating no matter what the language. The rest is just too-cool-for-PHP bragging (looking your way Ruby guys) and sour grapes (looking at you PHP).
56 comments
[ 4.2 ms ] story [ 119 ms ] threadNot a chance.
Yes, I would say that's the "only" difference. ಠ_ಠ
With proper engineering, PHP can be quick, cheap, AND good (see: Facebook. You want to argue the point, fine, but I don't see you becoming a billionaire on the back of your Haskell application).
Like every language, there is an appropriate place for it -- I would probably not write code for the Space Shuttle or a medical device in PHP. But, a great place for a language like PHP is web applications, especially for businesses who have to consider things like hiring people.
This is true for any language. It is also true for any language that poor engineering can make things really bad. PHP is in a unique position, though - it is so easily accessible to non-engineers that they begin writing applications without the slightest idea what they're getting themselves into.
This results in lots of improper engineering, and people blaming the language for the world's problems.
Javascript and Actionscript have this problem too. They get a lot less flack, though, because I think client-side scripting isn't held to the same standards.
Also, we're stuck with JS for the time being. PHP is easy to ditch by comparison.
I like working with JS but I don't know why the two operands aren't commutative in my example.
The DOM is a headache but luckily smart people have made plenty of libraries to abstract that away. What we're left with is a language with a very expressive and powerful core like you said, but there are still some oddities.
It's really a hybrid language. You can do a lot functional stuff with it if you'd like. You can also do a lot of the OO thing with it. Neither is perfect, but if you stick to the "good parts", it's a strong language.
Closures in JS are broken due to everything being a reference cell by default. This causes closures to be annoying to construct correctly and more expensive than they should be. "Functional" languages typically treat mutation as a side-effect and require reference cells to be explicitly declared. This helps enforce function purity and referential transparency -- functional-ness.
"Being careful about recursion" is like being careful about looping except recursive expressions are a superset of succinct iterative expressions making Javascript weak when it comes to, say, describing state machines. Lack of TCO makes Javascript a terrible compile target as CPS is impossible.
Javascript is an ambiguous, unsafe, difficult-to-analyze language. It supports some constructs that look like constructs in functional languages but because it does not enforce any functional or type systemic restrictions, these features are mostly cargo.
If you write a recursive algorithm in Javascript, you pay like O(n) for stack frames. The same iterative algorithm costs O(1) for stack frames. Thus, many developers eschew recursion in favor of iteration. This means that the logical code that developers write could be both mathematically sound and run efficiently on the machine but instead developers must either resort to temporal reasoning or perform recursion -> iteration transforms in their heads. This is broken.
Just because Javascript is ubiquitous doesn't mean it's good. I don't understand Javascript evangelists -- they seem to be spreading half-truths.
There are good parts though, and if you stick with them, it's not bad. In fact, it can be a pleasant experience to work with. Just because it's ubiquitous doesn't mean it's all bad.
Indicative of what exactly? A certain type of nerd (emphasis that I mean a sub group) that is likely to never accumulate wealth or create anything particularly successful on their own because they're too anal-retentive to understand that success in building a Web app or business is not defined by whether you use PHP or Ruby or Python or even ColdFusion.
Unless you think you're the next Facebook or Tumblr, then extreme optimization is necessary. Otherwise, the rest of the discussion is bullshit stacked on top of bullshit.
If the common wisdom were followed, Plenty of Fish should have never existed, given their infrastructure and development approach. And Stack Exchange should have never existed with their 'lame' Win stack (popular opinion of the Windows development environment among a certain class of developers =) ).
There are a lot of ways to 'skin a cat'. The only thing that matters is whether you can get to the finish line, build something people want to use, and perhaps monetize it so you can keep putting resources into making it better. Who gives a shit what you use to get there, just so long as you get there.
Bingo. Everything else is just navel-gazing.
To this day i'm still not sure what would be better: telling my boss "sorry, but if we want feature y, it will take 2 months (but it will we done right)" or "yes we can do that in 2 days but don't expect the code to be pretty"
I'm sure some programming book somewhere has said that in a much more elegant fashion.
In fact, there are countless finish lines in business and product development. You're constantly running a new race every development cycle. Trends change, competitors change, the entire landscape can change. Sometimes you're going to find yourself flat footed, and you're going to have to start a whole new race to launch a radically altered product.
It'd be like saying there was no finish line for the iPhone version 1. Of course there was, they had to actually ship it. And every product iteration has a new race to run and a finish line to meet to put the product on a shelf somewhere to be purchased. The same is true with iterating software of any sort, whether you're talking a micro level finish line (adding a feature to Gmail or Firefox 10.1), or a macro level finish line (shipping a completely revamped Firefox version or launching a radically new email concept with GMail beta). Getting from point A (inspiration, idea, task) to point Z (task completed) = finish line.
Try never having a finish line on any task, product, business, etc, and see what happens.
You see, what you call a "certain type of nerd" are actually craftsmen who enjoy things done well. You can be all the IKEA you want, and you're surely gonna rack up some interesting profits. But if I'm the kind of furniture maker who enjoys taking 6 months to build the perfect cabinet, you can be sure I'll pay special attention to selecting tools that I love. And none of your monetization arguments are going to count really.
So the bottom line is that PHP vs Ruby vs Python etc is a craftsmen's discussion. (If it's a serious discussion at all, that is - comparing it to Lean Startups isn't a serious discussion.) Bringing arguments like yours to such a setting just makes you look silly (especially when you think it's about "extreme optimization", then you just look like you really have no idea what you're talking about).
Sure, craftsmen like to discuss their tools, but as an open exchange about their experiences in order to learn from it, or maybe even simply out of professional curiosity.
The whole "my stack is better than your stack", and the "PHP sucks" thing that is commonplace on HN, proggit and other forums is not a craftsmen's discussion. It's a juvenile playground pissing contest that has nothing to do with craftsmanship.
By the way, anybody who thinks that real crafsmen typically use the "best" tools available has never seen neither an artist nor a plumber at work.
Should go on top of proggit/hn (yes, including blinking tags :).
You are correct that they do not pick the "best" tools, but they will deliberately choose the best tools for the job, as opposed to the most convenient tools to aquire and learn.
Although they might not use them, they'll talk endlessly about them. I mention in another comment how I've witnessed very long discussions among my photography and cinema friends about the "nerdy" details of their work. But you're right, there's a lot less emotion than in our community :/
Beautiful analogy, expect that it doesn't work here. You could be a craftsman and build an extremely solid and well designed backend. In the end consumers cannot appreciate your backend. A good example is I have no freaking clue what HN is built on. PHP? LISP? RUBBY?
* Posters above are arguing that the end result that programmers are judged upon is revenue. * You're arguing that the end result that craftsmen are judged upon is quality.
If a plumber is doing a terrible job but is doing well business-wise, I'd expect other plumbers to not look upon them so favourably
There are numerous ways to measure the success of a product. It depends on what it is meant to accomplish.
The real point is: it does not matter what tools you use, so long as you are able to reach success (in any number of ways a person may choose to define it).
You can obviously argue about which tools will best get you there, or give you the best chance to succeed.
I've seen plenty of entrepreneurs or developers, use a tool 85% good enough, to hit a homerun. It's little different than a good plan executed today being better than a perfect plan tomorrow. I believe there are exceptionally few cases in life or business where the '85% good enough' won't do the job. I've yet to see the 100% perfection set actually exist anyway.
The reason for that brings me back to my original point that there are too many people jumping in the language debates who really have no business being there. It's the equivalent of me trolling my photography friends saying that Sony makes amazing cameras because when I go on vacation I can just whip one out and take a decent shot, whereas the girl who didn't have her 4000$ SLR with her totally missed out on the opportunity. While 100% true, I'm really just derailing their conversation on the relative benefits of their cameras with something completely besides the point.
I've been dirt poor. Painfully, not actually scratching by, live off of ketchup packets poor. Let's talk about only seeing green some time eh. No matter the cost, I've always chose to do what I loved, and I've paid a helluva price for it at times. I've been an entrepreneur since I was 15. I know a thing or two about the extreme ends of both success and failure.
What I'm saying is: get the job done, whatever it takes. Use whatever tool will accomplish the job for you personally. Don't waste time turning yourself inside out over pedantic debates over 5% efficiencies, while opportunity escapes out the back door.
I wish we could kill the "entrepreneur" meme.
What you did since you were 15 was try (unsuccessfully from what I read) to launch some money making scheme or company.
I've been quite successful, thanks. =) Currently I'm sitting on a seven figure net worth, and I'm in my early 30's. How about you? I've also failed plenty, like anybody that has ever attempted anything difficult.
What I've done since I was 15 is build and create web applications that I thought were useful or that I wanted to see exist. Some of them I hoped would become successful businesses, some of them I created for the hell of it. Out of six web businesses I've started, three of those businesses have been successful and both paid for themselves and paid me a healthy income.
I built what is, per Quantcast, likely the world's #1200x largest web site, starting from $50 on a terrible virtual server, using nothing but an 8 year computer, notepad, and a 12 year old FTP program, on a very slow Verizon DSL line. Gee, if only I had used the right tools, lol!
I just closed an investment round with one of the most successful business people on the planet. Unsuccessful indeed eh. As the agreements I've signed permit it, I'll come back here and update on the progress of my new enterprise. We can compare notes, and see how wildly successful you are too.
Actually I've started my first company while in university, back in 1999. I sold my share in 2003. The company is still going strong today, and has around 30 employees nowadays (which might not sound much, but I'm from an entirely different country/IT environment). I also work for a startup the last two years, although not as a founder. I'm in my early 30s too, thanks for asking.
The whole "entrepreneur" thing, from the very word "entrepreneur", I find pretentious and silly, sort of like the "hipsterism" of the programming world. Oh, I did this and that, ramen, bla, MVP, bla, Rails, bla, exit, bla, VC round, bla, etc. Just build the thing, and STFU.
I admire people building things, from Steve Jobs to Bill Joy, who didn't run around selling the entrepreneur vibe.
Which, as I see it, is a rather recent fad, maybe a decade old at least in this particular form.
Actually I've started my first company while in university, back in 1999. I sold my share in 2003. The company is still going strong today, and has around 30 employees nowadays (which might not sound much, but I'm from an entirely different country/IT environment). I also work for a startup the last two years, although not as a founder. I'm in my early 30s too, thanks for asking.
The whole "entrepreneur" thing, from the very word "entrepreneur", I find pretentious and silly, sort of like the "hipsterism" of the programming world. Oh, I did this and that, ramen, bla, MVP, bla, Rails, bla, exit, bla, VC round, bla, etc. Just build the thing, and STFU.
I admire people building things, from Steve Jobs to Bill Joy, who didn't run around selling the entrepreneur vibe.
Which, as I see it, is a rather recent fad, maybe a decade old at least in this particular form.
For you, as an entrepreneur whipping out MVP after MVP until you strike gold, that couldn't matter less, but for those interested it's a big deal. To jump in the middle of their discussion as an uneducated outsider and judge the whole thing as "bs stacked on bs" is... inconsiderate at best.
I don't see how the unstructured development of the past has anything to do with using PHP in startups today. It's not about the language capabilities (90% of business aren't doing anything special in code), but developer speed and happiness. If you're happy with PHP then so be it, but that doesn't make it better.
The part that bugs me the most about the post is when it says "that's what we PHP guys do well: fail fast, fail cheap". Basically what he is stating is:
1) PHP developers are going to hit a wall earlier than other developers 2) PHP developers are cheap in general. How is that a positive statement, I don't know.
There's this stupid belief that by paying less for someone who does "a quick job" you can test a feature and then "build from there". It's bullshit.
From my own experience, I've regretted time and again hiring a cowboy (the fact that he was a PHP dev is not unrelated) developer just because we needed something "quick". What was supposed to be a 10-day deliverable turned into a 4-month mess of a codebase that I couldn't wait to rewrite. We ended up being hostage to our own code.
Perhaps the PHP community is different now from when I left it a few years ago. I'd never go back to that.
But there's also a lot to love about RoR. I just needed to calculate the number of business days between two dates - step forward the business_time gem. Five mins later and I've got a stable, tested solution.
I've built and sold businesses on PHP, I run some sites on it still. But I've never got into testing with PHP, it just isn't seamless. And because of that, I've always hated going back into the code and improving things later - projects have tended to stagnate. With RoR you have to make an effort NOT to write tests, and making minor tweaks isn't like moonwalking across a minefield.
If you just want to whack up a prototype right fucking now then PHP and a Framework are for you. But if you think that you're working on something more than a punt then either put in the effort to write decent tests in PHP, or use a framework that will force you to do so.
In summary - PHP and Yii Framework do almost all of what Rails do. It's fast, stable, clean and easily deployed. But the weight of the developer community is now behind Rails. And Ruby is a neat language that I enjoy working with.
This seems to go a long way with frameworks as well.
I use PHP for almost all web development. However, I'm not against using other languages.
I admit, PHP has its faults, but it's still a great web dev language. PHP 5+ has really added some great OO functionality.
Thank you for lumping all of them together.
I love PHP, but I freely admit there are issues. I love private care, but I also admit it has problems.
It's this sort of intelligent discussions that we need for me to take those sides seriously.
So we PHP people are good at failing early, fast and cheap. If you want enterprise grade fail, ask the java guys, if you want scalable fail, ask the c guys. If you want smart fail, ask the clojure guys. But early and cheap, ask us.
The claim here is that one can get to a working product using PHP substantially faster than with other languages. However, the article has no data to back this claim up. Indeed, one of the big goals of newer languages like Clojure, Python, and Ruby (the latter two not being explicitly mentioned) is to write code faster and with fewer errors. Java, while verbose, also has strengths: a great many excellent frameworks and libraries. This is also true for web development (e.g. http://www.playframework.org/). Including C in the argument is a little strange. As far as I've seen, it's one of the least used languages for deploying web applications these days!
In summary, I am wholly unconvinced by the claim of this article. And I say claim as it's missing any substantial argument. Does anyone have any actual data here? There are certainly many case studies for the newer languages and frameworks if you dig a bit. It's an interesting topic.
But really no one cares about your language except other people with chips on their shoulders too. When people use a product they really don't care about the tech specs no matter what the product may be. They care about what it does for them. I can clone Facebook in Runy or Twitter in PHP with both clones being more "optimized" than the original but no one cares. They just want to write on their friend's wall or retweet something so they'll tell me to go to hell with my .235ms improvements in page load times, DB queries, whatever.
A truly good developer doesn't waste time convincing people his stack is best. He proves his skill instead by shipping and iterating no matter what the language. The rest is just too-cool-for-PHP bragging (looking your way Ruby guys) and sour grapes (looking at you PHP).