Why would anyone writing a PHP app need those? The page just calls it a missing feature without explaining why this is a bad thing.
These are things in PHP which make me sad
211–217 of 217 posts
Re: These are things in PHP which make me sad
#212Earlier quoted context omitted.
An artist can make great art without knowing the details of how the dyes in their paint are manufactured. The same is true for development.
Can an artist make great art without knowing to use oil paint on canvas, instead of watercolor (or whatever - I'm not an artist)? How about knowing the difference between types of brushes and what effect they have on the canvas? Is it 'great art' if it's accidental?
That said, this is more like arguing that you can't be a great artist if you don't know how to make the canvas yourself.
Re: These are things in PHP which make me sad
#213http://www.jwz.org/blog/2011/05/computational-feces/#comment...
Re: These are things in PHP which make me sad
#214Earlier quoted context omitted.
Is PHP that different from other platforms in this regard? Any Java programmer knows ins and out of Tomcat, any ASP programmer is MSSQL expert?
* > Any Java programmer knows ins and out of Tomcat, any ASP programmer is MSSQL expert?* I'd hope they are experts, or at least have no trouble learning quickly. If they can't manage MSSQL or Tomcat, how do they set up their local development environment, implement automated integration tests, etc?
I work on Java every day. I probably have a better grasp of Tomcat than many people at my company. If we somehow magically lost all our Apache/Tomcat configuration files, there's no way in hell I could build it from scratch.
(I can, however, build a scalable system based around PHP web apps with my eyes closed. I'm not super proud of that.)
Re: These are things in PHP which make me sad
#215Earlier quoted context omitted.
I wasn't aware of that implementation detail. Hey, now I respect PHP even less than I did before. Your solution makes for some good boilerplate, but things like that are exactly why I use Python for everything it makes sense for: these things are baked into the language (in Python it would be array.get(key, default) ).
Yeah, it's part of Scala's type system, too - (Option, and Some or None. Better language designers go to great lengths to make simple things like null values well covered). Python will throw a fatal error and exits on reference to a nonexistent Dictionary key, but PHP blithely fills in the value with something falsy and continues. I'd rather be using Python too, but for some apps we have to work with a lot of PHP leg…
Scala borrows the option types from SML (or, at least, SML has them and is much older). I love SML for its strict semantics (if something passes through the type system it most likely works as expected), but sadly design really doesn't inform platform choice (case in point: C++ is still common. I don't hate it as much as some people do, but it can't be said to be particularly well designed).
Re: These are things in PHP which make me sad
#216Earlier quoted context omitted.
What aspect of PHP is "very very good"? Genuinely curious to know.
It's bad for language purists, but it's very, very good for getting stuff done fast, easy and good-enough. See Facebook etc. A lot of programmers don't believe that a shoddy language (in terms of language design) can be effective, but it is. I also happen to think that PHP scales really, really well the range that most sites need (say, from 1 to 50 servers). In that range, PHP is almost never the bottleneck.
You're saying PHP facilitates a faster development process than most other popular web development platforms? This was probably true, ten years ago.
Today, we have several platforms that facilitates a fast development process without the language weaknesses and inconsistencies that PHP is burdened with.
Re: These are things in PHP which make me sad
#217Earlier quoted context omitted.
How does scala make this more confusing? Either the types that are returned are scala collections, or they're java collections. If you want to treat java collections like scala collections you can always `import JavaConversions._` and huzzah, shallow conversions and collection uniformity. Finally, if something has the possibility of being null, you can use the option construct, e.g. if (Option(someListThatMightBeNull…
Option[X] is a crock. It's forcing you to write same bulky if-statements that you need to write for null checks. I want something like NOT NULL in SQL. Can't static typing make it completely impossible that I'll get a null in a situation where it should be completely impossible? For instance if something is typed as a collection, I'd like to never see null, I'd rather always get an empty collection. If I have to test…
Option[X] is only a crock if you haven't understood it. Stop thinking of it as a "null check", start as thinking of it as a collection which can either hold 0 or 1 elements and then you are on the right track.
null in Scala mostly exists for Java compatibility.
Re: Collections ... you haven't looked even _once_ at it. All collections return an empty collection or None, based on the operation. There are maybe 2 methods in the whole Scala standard library which return null, and both are _not_ in the collection framework.
This is so unbelievable misinformed... I can't believe it you have no problem showing this level of ignorance publicly.
"type inference system in Scala is always doing strange things behind my back" ... Example please.
"Automatic conversions" WTF?
"The trouble I see [...]" this is so much pure bullshit.