[leoc]

Reposting my old comment https://news.ycombinator.com/item?id=10774245 :

> People seem to have forgotten that when Perl evolved from being a better AWK to the paradigm example of the modern "scripting language", Larry Wall explicitly described this as a rejection of the Unix small-tools philosophy. http://www.linux-mag.com/id/322/ ("But Perl was actually much more countercultural than you might think. It was intended to subvert the Unix philosophy. More specifically, it was intended to subvert that part of Unix philosophy that said that every tool should do only one thing and do that one thing well.") http://www.wall.org/~larry/pm.html The fact that getting things done with a Perlesque scripting language is now seen as the height of purist Unix propriety only shows how far gone the original Unix ideal now is. But moving to the scripting-glue model doesn't really get rid of small tools that endeavour to do one thing well, it just reimplements them inside the scripting-language universe as functions/objects, though with a more expressive and less burdensome common language that makes it easier for them to stay small while being correct and effective. The more expressive their shared language, the smaller [the individual tools in] a set of tools can be.

>> Text just isn't a great medium for IPC.

> Yes, in retrospect Unix's determination to know about nothing but binary or plaintext blobs and streams looks like an adolescent rebellion against the (apparently - I haven't used them) clunky record structures of '60s operating systems.

[Extra text] added for clarification.

[simonh]

I think Unix's refusal to impose arbitrary structure on data is what has enabled a lot of the innovation and experimentation with alternative ways of organising and accessing data. Binary blob, SQL, NoSQL, key/value, column oriented, etc, etc Unix doesn't care. It just gets out of your way and lets you do your thing.

A lot of projects tried to implement opinionated OSes to the point that the OS was really an application. I'm thinking of Sprite and Amoeba, which attempted to abstract out the network and present a unified interface to accessing resources, and fancy storage systems, but in doing so impose opinionated interfaces on that access.

That's half way between an OS and an application like Hadoop, or Kafka, but you couldn't effectively develop something like Hadoop or Kafka, with your own optimisations and implementation tradeoffs on one of these things because the implementations or access models would clash.

[nmfisher]

Interesting take, but as someone who still works regularly with the shell, I'd say there is still a place for small core utils connected together with pipes/textual streams.

If we're talking parsing and chopping up text files, I can usually whip up something with awk/jq/cut/whatever in far less time than writing an equivalent Python script. There's a threshold where you prefer to switch to the scripting language for maintainability/testing, but the shell won't be going anywhere any time soon.

[hedora]

Most awk/cut/whatever commands can be done with perl -ne in about 2x the keystrokes, but you don't need to learn the other tools.

In Python, the multiplier is much higher, and I could never get the oneliner stuff to work.

[cutler]

I don't understand why Python is touted as some kind of replacement for Perl when there are many things Perl does better and faster. Python isn't even optimised for one-liners so how can it be compared with Perl?

[collyw]

I moved from Perl to Python around 2011, mainly for Django.

Perl is a more expressive, "cleverer" language. But I noticed when I moved to Python that I write better code. Too often in Perl I would try something clever and terse, then two days later it would bite me in the bum and cause more problems than it solved.

I would still pull out Perl for some quick bash replacement type script, regular expressions are so much nicer in Perl, but for larger scale long term projects where maintenance is important, I would go for Python.

[biomcgary]

I use cut, grep, uniq, etc. a lot for processing largish files (multiple GB), but also use perl oneliners generously. Never took to awk for some reason. These days I write Go for anything larger than a oneliner, but I've added a lot of smallish Go CLI commands to use in pipes, too.

[peelle]

I agree with this threshold idea, and I would argue that Perl and probably Ruby also have a lower threshold for switching than Python. Nothing against Python.

[collyw]

Having moved from Perl to Python, there isn't really anything difficult in switching. I looked at Ruby too, which felt like a tidied up version of Perl, especially regarding

[dhosek]

Having dealt with the clunky record structures of 60s operating systems, they did have their advantages, but the spread of cross-platform tools in the 80s and 90s killed them since Unix only knew byte streams. There are, I think some vestiges of it in the distinction between text and binary files on Windows (assuming that this still exists), but otherwise Unix’s everything is a stream of bytes has won. I kind of miss knowing that I had a file consisting of, e.g., 256-byte blocks.

[tenebrisalietum]

I'd have to look into it, but I think the whole reason for text vs. binary demarcation is the fact that ASCII text (not Unicode, old-school ASCII with valid characters 0x01-0x7F) could be sent over a 7-bit serial interface and binary needed that extra bit so you had to introduce overhead to make sure everything reached the other side. Because you might have had actual 7-bit serial (or less) teletypewriters connected in the 60's.

[dhosek]

On DOS it also came into play in how line endings were handled.

[chasil]

It went further down than the OS. COBOL implements ISAM databases right in the language as part of the standard. GnuCOBOL has a few DBM options for this when building the compiler.

[hedora]

The CODASYL vs relational calculus thing certainly had an impact too.

Navigational databases had gotten incredibly complicated, allowing the relational people to lap them.

[twic]

> Perl evolved from being a better AWK

awk has named parameters! Perl was a step backwards!

[ecef9-8c0f-4374]

Well it's your lucky day. Named parameters are perl since 5.20 ... as an "experimental" feature ...

Now you can write.

use v5.20; use feature 'signatures';

sub print_text( $param1 , $language = "perl", $years = 10 ) { say "I would have loved this $language $param1 more then $years years ago"; }

print_text "feature"

[matthewpersico]

And I believe that with the next release, a simple

    use v5.36;

will enable the feature.

[bmn__]

This already was available more than ten years ago, you simply had to install a module.

[ecef9-8c0f-4374]

I used to use perl5i for scripting, which had func().

Point is. As soon as I tell someone "you have to use tarball/cpan/cpanplus/cpanminus to install the feature "named parameters" they leave.

But now it's here

[mjd]

"Not guilty, Your Honor. Perl users build small tools all day long." (L. Wall)

[ngcc_hk]

It fit well with the network code where the other side is never be sure. Text interaction is a good initial way out of it. From old ftp, http, telnet … Xml and even json even if they are “structured” or fsm at least they are text. We can read the log.

I prefer text. Binary is too early optimisation and record oriented is too restricted.

[andi999]

Sounds like powershell.

[thesuperbigfrog]

Powershell takes heavy inspiration and some syntax from Perl.

[pmoriarty]

Incidentally, so does Ruby.

[tenebrisalietum]

Only because Perl takes heavy inspiration and syntax from Unix shells.

[thesuperbigfrog]

It's actually a bit more than that.

In "Windows Powershell in Action", Bruce Payette (one of the co-designers of Powershell) states:

"NOTE PowerShell uses the at symbol (@) in a few places, has $_ as a default variable, and uses & as the function call operator. These elements lead people to say that PowerShell looks like Perl."

"In practice, at one point, we did use Perl as a root language, and these elements stem from that period. Later on, the syntax was changed to align more with C#, but we kept these elements because they worked well. In Perl terminology, they contributed significantly to the 'whipupitude quotient' of the language."

[anthk]

Perl had an amazing Win32 support back in the day, and still does.

https://perldoc.perl.org/Win32

https://metacpan.org/search?size=20&q=win32

RAS, OLE, COM, ODBC. Perl did magick on NT/2K/XP.

[HeckFeck]

And it was (may still be) used in the Windows build environment!

[singingfish]

VMS too!

[bmn__]

> whipupitude quotient

That's an axis, not a quotient. See page 2/slide 3&4: <https://www.shlomifish.org/lecture/Perl/Newbies/vhll-slides....>

[melling]

Perl: 1988

Powershell: 2006