3 ms·
The reason why I think that this will not thrive, as other projects have not thrived, is because (at least initially) it adds to the mental burden. Scanning a c
by fao_ 9y ago
The reason why I think that this will not thrive, as other projects have not thrived, is because (at least initially) it adds to the mental burden. Scanning a cond for me is almost instantaneous. It took me a couple of very long seconds for me to figure out what was happening within that table, and even though I recognized it as a truth table, it was not easy to read. The information was too separate on screen to easily compare.
I think that were programming initially presented as such, this would not be a problem, but I expect that many developers are so finely attuned and specialized to text that other methods will not take off purely because of the learning curve.
- ppog 9y ago"Scanning a cond for me is almost instantaneous." This is a very subjective concern though. Consider the subtype example. For me, reading that 3x3 table, especially with the grouping of blocks, was a lot easier than mentally parsing a big pile of 'and/or' expressions, or nested switches, etc. And my impression is that a lot of programmers do initially visualise some parts of their work as tables or diagrams. Our tools on the other hand are indeed 'so finely attuned and specialised to text' that other methods of representation have and will struggle to get traction...
- asdfaoeu 9y agoI feel like most of these complicated if else statements can generally be written much better for example. SUPERTYPES = {'Real': ['Integer'], 'Complex': ['Real'], 'Integer': []} def is_subtype(a, b): if a == b: return True return any(is_subtype(x, b) for x in SUPERTYPES[a]) Which better expresses the intention of the code and is more flexible.
- lallysingh 9y agoI think developers would figure this out in roughly 10 minutes. And they'd use it where it made more sense than a single cond.