3 ms·
> 7. Astonishingly complete set of implicit data conversions. E.g. if X is floating-point and S is a string, the assignment X = S works when S = "2" and raises
by bigbillheck 5y ago
> 7. Astonishingly complete set of implicit data conversions. E.g. if X
is floating-point and S is a string, the assignment X = S works when S
= "2" and raises an exception (not PL/I terminology) when S = "A".
This seems like an extraordinarily bad idea.
- jrd259 5y agoPerhaps a bad idea, but at least it was rigorously specified. I note that that Javascript and perl have same ability. See also https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
- layer8 5y agoJavascript and Perl are different in that they allow a variable to change it’s type by reassignment (i.e. they would allow the X = S assignment for S == "A"), which PL/1 apparently doesn’t. Weak/strong typing and dynamic/static typing are different axes.
- masklinn 5y ago> Javascript and Perl are different in that they allow a variable to change it’s type by reassignment That is orthogonal to the issue at hand. > Weak/strong typing and dynamic/static typing are different axes. And perl and javascript have both, and the weak typing is what gets criticised the most, and what causes the most issues.
- layer8 5y agoYes, the weak typing is what (rightfully) gets criticized, but the PL/1 design here is IMO closer to C with its implicit conversions but typed variables than to Perl and Javascript.
- masklinn 5y ago> the PL/1 design here is IMO closer to C with its implicit conversions but typed variables than to Perl and Javascript. So in your opinion, the PL/1 design here is closer to a trainwreck than an other trainwreck? Furthermore C's implicit conversions come nowhere near parsing a string to get a float, that's squarely on the Perl/JS side of the board.
- layer8 5y agoLook, I wasn’t expressing any value judgment, and I’m not advocating for implicit conversions. My point was that the implicit conversions in PL/1 have a different context in PL/1 than they have in Perl and Javascript, more akin to the one in C. One effect of that is that the type of a variable remains fixed in PL/1 where it doesn’t in Perl and Javascript. This places it at a different point in design space and changes the dynamics to some extent, which is just a nuance that I find interesting. It wasn’t expressed in the original comment I was replying to, so I thought it would be worth pointing it out so that he distinction isn’t being missed.
- masklinn 5y ago> I note that that Javascript and perl have same ability. And it’s widely considered horrible.
- drfuchs 5y agoAnd all the implicit conversion rules between pairs of types couldn’t fit on a single-page chart; the official IBM manual included an honest-to-goodness fold-out bound right in. Fun times.
- ptx 5y agoIt does. It sounds like the Unicode handling in Python 2, where your program would still appear to work if it confused bytes with codepoints (through implicit decoding/encoding), until you get a non-ASCII input somewhere and everything blows up with a UnicodeDecodeError somewhere far from where the problem is.
- layer8 5y agoIt’s like implicit numeric conversions in C, just extended to string types.
- zokier 5y agoIts not like the implicit numeric conversions in C were particularly good idea either
- emmelaich 5y agoIt was a mistake in C++ too, fixed with the explicit keyword.
- masklinn 5y agoIt’s not fixed since it still occurs by default. That you can work around it if you remember to is not a fix.
- layer8 5y agoIndeed. My point was that it’s something also found in other widely used languages, and not a PL/1 pecularity.
- masklinn 5y ago> My point was that it’s something also found in other widely used language where it is also generally considered > an extraordinarily bad idea. so it seems like a rather useless point?