| |||||||||||||
Hmm...Hmm...Posted Dec 19, 2011 10:32 UTC (Mon) by khim (subscriber, #9252)In reply to: Why is it a mess? by HelloWorld Parent article: Cracks in the Foundation (PHP Advent)
I don't see the point in allowing anything that isn't either true or false in an if statement/expression. The point is expressiveness, as usual. You can do anything you want without such things (see Turing tarpit), but this kind of misses the point. I happen to like the way the STL solved this problem in std::find. If an element is found, return an iterator to it. If it's not found, return a past-the-end iterator. This is good kludge for the statically typed language with a lot of limitations. They could not use just plain NULL because they wanted to make sure iterators may be anything, so they invented this scheme. Still not sure why you think it's better then simple "iterator or #f": in C++ case you often need to process iterator somehow (if caller which needs the iterator does not want to know about your map), in case of LISP you can just return result as is. In Haskell, one would typically return a 'Maybe' value, which is either "Nothing" or "Just x", where x is the number you're looking for. One then uses pattern matching to distinguish the cases. And all thus additional unneeded manipulations are good exactly why? I dislike languages without static typing because they leave too much to the runtime, but then if we are already in realm of dynamic languages it's stupid not to use the fact that you can return objects of different types to your advantage: why do you use language with dynamic typing or duck typing if you only use things available in statically typed language???
(Log in to post comments)
Hmm... Posted Dec 19, 2011 12:15 UTC (Mon) by alankila (subscriber, #47141) [Link]
In general it's acceptable to return different types, I guess, as long as it is driven by some kind of compelling necessity or resulting convenience. This FALSE is just not convenient because of the confusion with 0; I think it just shows remarkably poor taste. When designing an API, the designer should take full responsibility about the anguish the API's hapless user must endure.
Hmm... Posted Dec 19, 2011 12:45 UTC (Mon) by HelloWorld (guest, #56129) [Link] The point is expressiveness, as usual.[...] And all thus additional unneeded manipulations are good exactly why?I don't see any gain in expressiveness here, nor do I see any "unneeded manipulations". PHP: $z = strpos($x, $y); if ($z === false) do_something(); else do_something_else($z);C++: auto z = boost::search(x, y); if (it == x.end()) do_something(); else do_something_else(z); I dislike languages without static typing because they leave too much to the runtime, but then if we are already in realm of dynamic languages it's stupid not to use the fact that you can return objects of different types to your advantage: why do you use language with dynamic typing or duck typing if you only use things available in statically typed language???Well, you're raising a good point, and the answer is that one just shouldn't use a dynamically typed language for anything but throw-away stuff. Doing stuff like returning either an int or a boolean spoils the way people think. They start to think that in order to obtain a convenient solution to this problem they need dynamic typing, even though that isn't so.
Hmm... Posted Dec 19, 2011 12:49 UTC (Mon) by HelloWorld (guest, #56129) [Link] Oh by the way, that reminds me of an old quote by Dijkstra:It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.Needless to say, the same applies to PHP.
Hmm... Posted Dec 19, 2011 13:00 UTC (Mon) by mpr22 (subscriber, #60784) [Link] I'm inclined to think that that particular Dijkstra quote probably says at least as much about Dijkstra's ability to teach as it does about BASIC.
Hmm... Posted Dec 19, 2011 13:27 UTC (Mon) by nix (subscriber, #2304) [Link]
I think it has more to say about what Dijkstra wanted to teach. Once you've been exposed to a language that just lets you get simple stuff done without much effort, the preferred Dijkstra way of formally proving as much as possible starts to seem incredibly long-winded, even if in theory it does eventually produce better results. (It is, of course, a good idea in some domains -- just not everywhere, as Dijkstra sometimes seems to have wished.)
For very large programs, particularly in safety-critical domains, formal proof, particularly of core components, starts to seem reasonable -- but when you're teaching you're going to be using small examples, because you have to. And those small examples are typically too small to need formal methods of any kind. Expose someone to BASIC, or another similar language which is good for quickly whipping up something small that works but that falls apart on larger scales, and they are likely to think 'why bother with formal methods?' when exposed to little teaching examples of their use, for which, to be blunt, any random language would often suffice with no use of formal methods at all.
|
|||||||||||||