4 ms·

> We have lots of mature, debuggable languages to process text... You mean like sed? Sed was written in the 70s and has been in mission critical stuff for dec

by esmi 6y ago

> We have lots of mature, debuggable languages to process text... You mean like sed? Sed was written in the 70s and has been in mission critical stuff for decades on many platforms. What are you recommending that is more mature than that?

archgoon 6y ago
Sed does not have a debugger that is 50 years old. The author was not saying that sed is a bad tool; he's saying it doesn't have a debugger. If there is a desire to have a debugger for the tool, that has existed for 50 years without having one, perhaps the tool is not being used in the way it has been used for the last 50 years. This would seem to make the argument that the tool has been tried and tested less relevant.
- zwischenzug 6y ago
  sd is 24 years old: http://sed.sourceforge.net/grabbag/scripts/sd.sh.txt http://sed.sourceforge.net/grabbag/scripts/sd.sh.txt
smt88 6y ago
COBOL was written in the 60s and has been in mission critical stuff for decades. Neither of those factors means it's the right tool for the job now. The things I'm recommending that are more mature are Go, Python, D, Rust, or any other language that is more verbose and maintainable than regular expressions. Anything with a full debugger, IDE support, and useful error messages is a better choice.
- kjs3 6y ago
  Except COBOL often is the right answer for text processing now, meets all your criteria (debugger, IDE, maintainable, etc) and far more mature than Go, Python, Rust or D (really...D?).
  - smt88 6y ago
    COBOL is the wrong tool for any new job now because hardly anyone knows it.
    - kjs3 6y ago
      Which could be said about any newly fashionable language. Or any niche language. And in the case of COBOL, it's not even true. Here's a little hint: just because you don't know any COBOL programmers, doesn't mean they don't exist. My own company has a couple of hundred, and we have an outsourcing partner that has a several thousand. We are not unique.

by esmi 6y ago

archgoon 6y ago

Sed does not have a debugger that is 50 years old. The author was not saying that sed is a bad tool; he's saying it doesn't have a debugger. If there is a desire to have a debugger for the tool, that has existed for 50 years without having one, perhaps the tool is not being used in the way it has been used for the last 50 years. This would seem to make the argument that the tool has been tried and tested less relevant.

zwischenzug 6y ago
sd is 24 years old: http://sed.sourceforge.net/grabbag/scripts/sd.sh.txt http://sed.sourceforge.net/grabbag/scripts/sd.sh.txt

smt88 6y ago

COBOL was written in the 60s and has been in mission critical stuff for decades. Neither of those factors means it's the right tool for the job now. The things I'm recommending that are more mature are Go, Python, D, Rust, or any other language that is more verbose and maintainable than regular expressions. Anything with a full debugger, IDE support, and useful error messages is a better choice.

kjs3 6y ago
Except COBOL often is the right answer for text processing now, meets all your criteria (debugger, IDE, maintainable, etc) and far more mature than Go, Python, Rust or D (really...D?).
- smt88 6y ago
  COBOL is the wrong tool for any new job now because hardly anyone knows it.
  - kjs3 6y ago
    Which could be said about any newly fashionable language. Or any niche language. And in the case of COBOL, it's not even true. Here's a little hint: just because you don't know any COBOL programmers, doesn't mean they don't exist. My own company has a couple of hundred, and we have an outsourcing partner that has a several thousand. We are not unique.