266 karma · joined December 26, 2011
You misunderstand how non-blocking works. In this case, it -most definitely- waits for get_username() to return before continuing. If get_username itself does some asynchronous calls (like db.query), that's its problem, but execution absolutely waits for your own functions to finish.
I'd recommend reading up more on event-driven programming.
Similarly, programming is the ability to control computation. It's very hard for us to understand just how a society would behave when 90% of the population has the power to create any software tool it needs, to compute sophisticated statistics, and so on.
You'd be hard-pressed to find anyone today who disagrees it was a good thing that (almost) everyone learns how to read and write. I'm also convinced 100 years from now, you won't find anyone complaining about widespread programming ability.
Well, that means you have zero experience with the majority of concerns expressed in this thread, and so are not qualified to opine on them. You work in a happy bubble and I envy you for it, but in the real world you very very rarely get the go-ahead to refactor old code. So in the real world, you very very rarely get to see a quality code base. In any language, really, but PHP compounds this problem with its idiosyncrasies. But you wouldn't know about that.
> I refactor all external PHP code before I place it inside of mine
> You don't like a feature of PHP? Don't use that feature. Simple as that.
I don't know anything about you, but judging from that attitude you haven't worked in many teams. Of course it's not as simple as that. If I had a penny for every time I had to fix someone not checking that strpos() === FALSE, well, I could fund my own startup. You may have the luxury of refactoring all over the place, but the reality out there is that horrible code like this is left to fester until it causes real business damage.
Not to mention that I have no idea why the original commenter picked on this. It was listed as one of the 7 or so things that can go wrong with that one single, not unusual line of code. It's not like he had a whole paragraph about why @ is bad.
As long as PHP will have all these warts, people will condemn it, Get over that.
If I really enjoy dealing with complexity and you give me something really simple to do, well I'm gonna go ahead and have some fun with it. It's not a matter of justifying, it's just that simple stuff is boring to somebody who enjoys complexity.
That being said, LulzSec et. al. were more about social activism than about accomplished hacking. For a mission like that you really need some mainstream appeal, and for that purpose the newage digital messiah fit the bill.
Unlike the unreasonable bible and Moby Dick codes, this has practical applications in image manipulation and compression.
The idea is that as parents, we send subtle signals to our young children about how adult life should be. A father spending 6h a day at work and the rest with their child is preparing a personality potentially lacking a builtin discipline derived subconsciously from observing the parental example.
This has nothing to do with your worries about your death bed regrets. They're valid too, but besides the point the PP was making.
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 :/
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.
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.
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).
Yes, I would say that's the "only" difference. ಠ_ಠ
"The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. [...] In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request."
So if you want to create the user Foo and you somehow know about the URI example.com/users/Foo, then you can directly PUT your information to that URI. This URI points directly to the enclosed entity, the user. If you only know the URI of the enclosing resource (aka collection), then you MUST do a POST to example.com/users/.
So that's the semantics of it, PUT deals directly with the resource that the URI points to, while POST deals with a collection of subordinate resources.
However, the REST catch is that if you follow the HATEOAS principle, there's (almost+) no way you would know about example.com/users/Foo. In the REST world, you would (almost) never use PUT for creating, because if that resource doesn't already exist, you would (almost) never get a URI to it by traversing the hypertext representation of the application state.
+ I say almost because you could have something like a GET example.com/users?name=Foo that would return 404 with the URL where to PUT to create this user. Not sure how HATEOAS proposes you get to a URL like example.com/users?name=Foo though, perhaps someone more knowledgeable can pitch in.
This is HTTP not REST. You need to understand this even if you're against REST.
(edited to remove tl;dr. It looked much longer in my text box)
At the same time we can do our part to make that real. We can start with more novice-friendly frameworks, better documentation for things that already exist, and maybe even more specialized languages that are geared towards casual coders.