4 ms·
I nticd ur nt tping lk ths. Sentences are much easier to understand if you use words, even if the abbreviated forms can be parsed out to the same meaning. If y
by aston 20y ago
I nticd ur nt tping lk ths. Sentences are much easier to understand if you use words, even if the abbreviated forms can be parsed out to the same meaning.
If your aim is to save yourself a couple characters per line, fine. But it does come at a cost.
- SwellJoe 20y agoThe interesting thing for me is that the K programs are fewer lines...a lot fewer. 9 in K vs. 96 in Perl in one example. When one remembers that perl is historically the king of one-liners, this is pretty impressive. I'd probably be willing to learn how to interpret line noise if I only have to parse 9 lines for every 96 I'm parsing now (I'm primarily a Perl programmer). I, obviously, don't believe this is representative--a large number of programming tasks aren't reduce-able beyond a certain level. But for a 50% LoC reduction, I might consider it. There's a lot of other considerations, and right now Haskell and Erlang are leading my "what'll my next back end projects use" list (after Perl 6...which I'm getting excited about after seeing Audrey Tang's talk about it from a few days ago, as it appears it will fix every single major problem with Perl, by my reckoning)...but I'm not going to rule out a language merely because my first glance at it makes me uncomfortable or confused (if that were the case, I would have never used Perl, Python, Ruby, and I would be avoiding messing with Erlang and Haskell...I might have even continued trying to figure out Java, since it seemed comfortably familiar based on my C experience, but I believe that would have been a very bad instinct).
- ralph 20y agoI'd probably be willing to learn how to interpret line noise if I only have to parse 9 lines for every 96 I'm parsing now bzip2 -9 <hellow.c | uuencode hellow.c.bz2