8 ms·

Most of what I do involves loading text files with fixed width records. A file is between 500M and 4Gb. Then I do things with these records. So far I have not

• mkohlmyr 13y ago
  Well that's great... For your very narrow use case.. It is not however an effective rebuttal to the points brought up in a more general case.
  • VLM 13y ago
    "It is not however an effective rebuttal to the points brought up in a more general case." Where is this general case? I clicked thru the presentation and it boils down to here are some obscure yet interesting and trendy corners of the computational world where Perl doesn't work well, therefore we have to change everything. We could have had the same presentation 20 years ago, just the trendy weird corners would have to change to match the times. Doesn't mean those trendy corners are useless, just not required to write 'good code'. Not that the goals are inherently awful. I don't do anything requiring UTF-8 at work. Someday I probably will, and it'll probably be a PITA. I tend to see this kind of presentation as rabble rousing. "Here's some stuff that other languages care about, although you don't care, but it obviously doesn't prevent any of you from being profitable and gainfully employed writing good code so its obviously not required, which is why Perl doesn't have it. If I can convince you to care about it, Perl would gain it or more likely you'd just leave Perl. Hope you feel uplifted, here's some internet meme pictures, k thx bye" I'm not sure other languages consider it "insightful" when they get a cut and paste rephrasing of the same presentation, which is possibly the most interesting part of the whole story.
  • mhurron 13y ago
    Wait, you think opening and reading files of various sizes is a narrow case for a language named Practical Extraction and Report Language?
    • TylerE 13y ago
      In the case of arguing for general relevance, yes. It's like saying: Hey, all I do is bang in nails! The hammer is only tool anyone ever needs!
• Arnor 13y ago
  C?
• jingo 13y ago
  "So far I have not found..." What else have you tried?
  • Mithaldu 13y ago
    I think it's important to note that there is an implication in his question of the code of the alternative being as easy to read and write as Perl. One could of course write a much faster text processing tool in Assembler, but well ...
    • TylerE 13y ago
      > easy to read as Perl. So, that rules out Brainf--k I guess
      • Mithaldu 13y ago
        Yes that is correct. Brainfuck is not as readable as Perl. (I think you need to train more with your witty comebacks. Also drop the meme that Perl is not very readable, when it has lately improved a LOT [1] in that regard.) [1] https://metacpan.org/module/Moo#SYNOPSIS https://metacpan.org/module/Moo#SYNOPSIS
        • TylerE 13y ago
          But actually look at the SOURCE of Moo instead of a toy example, and I see plenty of stuff that's exactly the kind of suboptimal readability I associate with perl....sigils all over the place, @_, the lack of proper function argument handling, etc. Any toy example can be made to look clean.
          • Mithaldu 13y ago
            Yeah, sorry man, at the point where you complain about sigils you've disqualified yourself from the discussion for lack of thinking things through far enough. Thanks for playing, bub.
• VLM 13y ago
  "However, a 10x improvement would be very interesting to me." I managed to optimize a similar problem as yours until it was I/O limited. 1/10th the CPU would not change anything in the overall system.