Today I realized an important and probably very obvious fact: we all change. Of course, you will say. Surely most of us will agree to that, but the important thing about that is also realizing that we drift away from things we loved. Okay, so what am I actually talking about? :)
I talk about software development, specifically development of and with PHP. We've seen some radical proposals in the nearer past and in deed are still seeing those for PHP, the language. Often, I was inclined to think "cool, that's a great idea, let's improve in that direction."
PHP was and is a huge success, it attracts a lot of awesome people, sometimes becoming unhappy with the language's principles and resulting limitiations, like its simplicity, its forgiving nature and the enigne's effort to come to an end for this request, i.e. to die. Looking at the larger frameworks which have evolved the last few years, they head into a clear direction: strictly object oriented programming with RidiculouslyLongClassNamesLikeFoundInOtherStrictlyObjectOrientedLanguages. Anything non object oriented seems to be verboten. But this is not of what PHP was meant to be and it is very hard to change something that late in the game in such drastical ways. I don't think PHP can change as fast as we do, it's actually much longer around than most of us call ourself programmers.
What I mean to say is, don't be angry with PHP the language, don't force it to change in a way it's not supposed to survive, stop proposing language level changes in a weekly manner, don't be afraid to change yourself. Don't be afraid to advance yourself. Don't be afraid to change the language you program in. BOOM, I said it. Yes, don't be afraid to explore other possibilities that better support your principles instead of fighting them.
I'm not saying go away, I'm saying go ahead, or at least I mean to.
Sorry for the fast write-up, all the typos and errors. Have a nice start into your week!
Monday, December 9, 2013
Tuesday, June 18, 2013
Hear, hear
I was about to write "in early February" but actually it already was in late January that I stumbled over this tweet:
Fast-forward five months – now I am very excited to be able to announce that the Awesomes over at SmugMug, Inc. have hired me to work full-time on the core of PHP.
Hide bugs.php.net, expect massive amounts of commits, sleep well. Thank you for reading the simple words of the proudest man alive. Thank you SmugMug!
I'm still ready & willing to hire a #PHP internals coder to work on PHP fulltime. Amazing place to work: http://t.co/GX4wtPSc
— Don MacAskill (@DonMacAskill) January 18, 2013
Fast-forward five months – now I am very excited to be able to announce that the Awesomes over at SmugMug, Inc. have hired me to work full-time on the core of PHP.
Hide bugs.php.net, expect massive amounts of commits, sleep well. Thank you for reading the simple words of the proudest man alive. Thank you SmugMug!
Sunday, March 3, 2013
pecl_http-1.7.5
pecl_http-1.7.5 has been released today.
Nearly a year and 170k downloads after the last release (1.7.4 was released April 2nd 2012).
It fixes a single bug:
Nearly a year and 170k downloads after the last release (1.7.4 was released April 2nd 2012).
It fixes a single bug:
- Bug #64310 (weak etags W/"abc" are quoted as "W/"abc"")
The same user (thanks Niko), discovered a peculiarity of libcurl:
- If you utilize libcurl's TIMECOND feature through pecl_http's lastmodified request option, libcurl ignores response bodies from servers that do not closely follow the RFC and send a 200 OK response instead of a 304 Not Modified when the condition is unmet.
Slightly more background information is available at the relevant bug report.
Please leave a comment, if you have an opinion about which component's behavior is arguable here.
Tuesday, February 19, 2013
pecl_http-v2 - http2 or httpi or http-*
I'm pondering to release v2 of pecl_http with a different extension name than "http", but I cannot agree with myself what's worse:
http2
This might be confused with HTTP/2.0httpi
There's mysqli following this approach, but I think this is pretty odd.Split it up
Split the package up in several smaller sub-packages, like:
- http-common
- http-env
- http-client
- http-client-curl
- etc.
If you have an opinion, or maybe even a better idea, please leave a comment.
Subscribe to:
Posts (Atom)