4 ms·
Would it be possible that there are no blind spot on the Python side and a "semantic golden hammer" (for the lack of a better term) on the Haskell side? I'm no
by p4bl0 15y ago
Would it be possible that there are no blind spot on the Python side and a "semantic golden hammer" (for the lack of a better term) on the Haskell side?
I'm not being sarcastic or anything, I'm really wondering: are Python programmers using monads without knowing it? Or is it that monads are a good tool at giving a semantic (or "mathematical meaning") to what they are coding?
I think the distinction between the two points of view isn't relevant, but my point is that when you know something and like it, you easily see it everywhere: if you want it, all your code is just lambda-calculus, all your control structure are some kinds of monads, all for loops are just tail-recursive functions, all objects are just closures…
- klodolph 15y agoWell, that's the idea of monads -- you can see them everywhere because their original purpose is to express imperative programming mathematically. It's like thinking that all numbers can be represented with digits; of course -- digits were invented to represent all numbers. But the thing that makes Haskell unique is not that you have explicit monads. It's that you can (1) use monads other than the IO monad (like Maybe, [], STM, ST), and (2) that you can choose to use no monads at all in a given function. To put it another way, Haskell is unique because it allows you write functions without using monads, but in other languages you can't turn them off. Like nullable types, which can't be turned off in Java (ever debug NullPointerExceptions?) or Python, but which have to be enabled on a case-by-case basis in Haskell.
- hythloday 15y agoI'm not disputing that Haskell makes it easier, but from a practical perspective I'd challenge the idea that nullability can't be turned off in Java with @NotNull annotations (and nullability inference tools like JastAdd[0]), or with decorators in Python. Do you see an essential difference in kind, or just a spectrum of ease of reasoning? [0] http://jastadd.org/web/jastaddj/extensions.php http://jastadd.org/web/jastaddj/extensions.php
- yew 15y agoWould you mind expounding on that use of decorators? I'm not making the connection and it sounds like an interesting one.
- hythloday 15y agoSure, it's just a specific kind of type-checking decorator in the same vein as the ones you can see at e.g. [0]. Obviously it can be made a lot more sophisticated to only pick up certain arguments. You can do a similar thing with metaclasses to prevent object attributes being set as None, too. def isnotnone(fn): def decorator(*args, **kwargs): for arg in args: if arg is None: raise TypeError("{0} does not accept None".format(fn.func_name)) for arg in kwargs.values(): if arg is None: raise TypeError("{0} does not accept None".format(fn.func_name)) return fn(*args,**kwargs) return decorator @isnotnone def f(a, b=dict): return a(), b() >>> f(None) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 5, in decorator TypeError: f does not accept None >>> f(b=None) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 8, in decorator TypeError: f does not accept None >>> f() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 9, in decorator TypeError: f() takes at least 1 argument (0 given) >>> f(str) ('', {}) >>> [0]http://code.activestate.com/recipes/454322-type-checking-decorator/ http://code.activestate.com/recipes/454322-type-checking-dec...
- yew 15y agoThanks!