181–190 of 261 posts
Perl is/was fantastic and awful. An excellent alternative to grep, awk, sed, ls, test. A lot of the greatness of Perl came from writings of Larry Wall, Mark Jason Dominus, Randal Schwartz, Tom Christiansen. There is so much wisdom to be gained from all their code and documentation.
Unpopular opinion, but I think we'd be so much better off if Netscape had just embedded a Perl interpreter instead of creating JavaScript. Perl CGI was already the dominant server side technology at the time and it has incredible string manipulation capabilities that would be beneficial for browser scripting.
JavaScript being some kind of Lisp dialect with a C syntax is good IMHO. You also get some Perl inspired features in JavaScript, like the regular expression engine, and the not so user friendly array methods like slice and splice. The DOM API is also a bit more robust than string manipulation.
Earlier quoted context omitted.
JavaScript being some kind of Lisp dialect with a C syntax is good IMHO. You also get some Perl inspired features in JavaScript, like the regular expression engine, and the not so user friendly array methods like slice and splice. The DOM API is also a bit more robust than string manipulation.
I know its history but Javascript is not in any meaningful sense a "Lisp dialect". Code is not data, code is not even an object, you have to define a function, closure or object to manipulate the code itself.
Earlier quoted context omitted.
I remember capturing every password at my university via "methods". Because we had a printer quota. In the summer when everyone was gone I printed out all the man pages (all the mans, the system libraries, etc) so I'd have a nice reference book. I made sure to make it so no one was charged any money. The one thing people can't possibly fathom if they started coding after the mid-late 90s was how much we relied on the…
I still remember when we measured the documentation IBM shipped with the mainframes not in pages but in yards it occupied on the shelves. It was a lot .
Rather Waite-y.
Earlier quoted context omitted.
It works because they both get shit on unfairly today. There’s still no substitute for either of them.
As I said above, there are dozens if not hundreds of substitutes for Perl (as a general-purpose scripting language) now.
Earlier quoted context omitted.
> Perl had a really, really strong sweet spot in text processing. Still does.
Since Ruby took the best bits of Perl what advantage does Perl retain?
Ubiquity, speed, and conciseness.
Perl is usually installed by default on Linux and Unix systems. Ruby might be there, it depends.
Perl is faster than Ruby. Ruby has been one of the slower scripting languages. But Ruby has been working on performance improvements in the past few releases. I have not seen any benchmarks of the current Perl versus the current Ruby, so this may have changed.
Perl is more concise than Ruby allowing more functionality for less code.
Earlier quoted context omitted.
> Perl had a really, really strong sweet spot in text processing. Still does.
Since Ruby took the best bits of Perl what advantage does Perl retain?
Earlier quoted context omitted.
> Automation was glued together in one of these with a series of grep, awk, sed, ls, test, commands glued together. Anything more complicated was written in C and called from one of these things. This doesn't sound that horrific to me. It's the classic Unix approach of building small tools that do one thing well, and composing them in novel ways to solve problems. For any problem that can't be solved this way you wri…
> This doesn't sound that horrific to me. It's the classic Unix approach of building small tools that do one thing well, and composing them in novel ways to solve problems. This works really well if your problem can be solved in one or two liners. It go bad very quickly when, say, you have two CSV files and want to join them the sql-way. In sed, you have to use positional variables and think about shell escaping. In…
That sounds like a perfect use case for `join`.
Earlier quoted context omitted.
I don’t think you’ve seen the kind of scripts the person you are responding to is talking about. I have, and mentioned one lower down in the comments. Unix philosophy was great but does not scale well in terms of maintainability or efficiency. Invoking processes over and over again loops is godawful slow. And the horror of complicated shell scripts is legendary.
As a self-taught coder, I've experienced many times how highly skilled software engineers groan and sweat when they encounter shell scripts. I don't understand why, but it seems like people with a CS background are never really taught shell scripts and have come to irrationally fear them. It's sort of taboo. This results in weird behavior, such as writing a groovy (Java?) script for Jenkins to execute bazel in order…
* often times, it's not just the third column I want. Sometimes it becomes "third column unless the first column is 'b' then instead grab the fourth column". Having a good data representation makes sure that I'm not mixing logic code with representation parsing code
* I don't have to care about CSV parsing edge cases. Escaped comma? Quotes? I don't care, the library will either handle it or throw an explicit error. With custom parsing code, instead of an error, I'll get some mangled result in the middle of the file that I won't even catch / notice until later down the line
* when working with CSVs, in my area (ML / scientific compute), Python is often the right context to be in.