Live data from Hacker News

We were wizards – a foreword to Learning Perl (1993)

jwgoerlich.com

61–70 of 130 posts

Re: We were wizards – a foreword to Learning Perl (1993)

#61
post #14

We were indeed, and sadly like many true wizards - we were grumpy and too smart and too weird for the world. And we had too many sigyls and weird symbols and we didn’t see farther than our nose, so we weren’t that good with foretelling things, but only with practical magic. Even though wizards foretold nPm by inventing CJAN - like Cpan for JavaScript. And also IO::Async and Lehman’s work was very much ahead of NodeJS…

> We were indeed, and sadly like many true wizards - we were grumpy and too smart and too weird for the world. The submitted post exemplifies the worst characteristics of what we can call coding culture . Larry Wall was a polarising character. He could be witty but also tiresome. The C and C++ coding cultures have had their problems too. Python has been successful as a language and as a coding culture. I don't like t…

>> Python has its own TIMTOWDI at this point.

It's Python's dependency management, and there is more than one way to do it:

pip, pipenv, poetry, conda, setuptools, hatch, micropipenv, PDM, pip-tools, egg, ActiveState platform, homebrew, or your operating system's package manager.

Relevant xkcd: https://xkcd.com/1987/

Re: We were wizards – a foreword to Learning Perl (1993)

#62
So I was doing Perl at this time on Wall Street, basically using it to replace shell-based abominations with something faster and easier to maintain. Perl 4.

Being in-process certainly sped things up. And it was easier to understand than the shell based solution.

But it would have been easier to write and read in just about any other language.

Perl 4 at the time only had very primitive data structures. Most of the time you were concatenating and splitting strings together to mimic real data types. The baroque way file handles were a first class data structure made abstracting over them painful and hacky.

That $foo and @foo and %foo were different variables caused innumerable bugs.

The exposure of function arguments as a stack directly in the language made for weirdness all its own.

The mimicry of shell expressions brought its own pain.

And finally, Perl’s greatest strength and horrific weakness: the regular expressions. One liners that would bring tears to your eyes the next time you had to debug it.

I get where Wall was going with Perl, but the emphasis on beautiful natural language for various idioms really crippled the language horrifically from the start. Going into Perl was forgetting nearly everything you knew from other languages and entering this unreal fantasy forest of code, with monsters lurking behind every rock and twist in the road.

Re: We were wizards – a foreword to Learning Perl (1993)

#63

Bashing Perl is now a meme, but I can never get over what could have been… Python 3000 and Perl 6 had the community all abuzz. CPAN was the amazing Wild West where people were sharing amazing libraries in such a simple way compared to how every other language was still using the likes of Source Forge and possibly even Fresh Meat (GitHub didn’t exist yet). Don’t fall into the meme trap of hating on Perl. Although it’s…

I'm bashing Perl because I'm using it daily today . I have the moral right. People waxing poetic about their time using Perl back in the late 1990s/early 2000s don't have a vote because they clung onto good bits and have long forgotten the ugly. > it really makes Stream-of-Conscious programming the norm Are you sure it's a Good Thing? Really sure? What if you have teammates? What if you have a life? What if you need…

I have written Perl solo, and then migrated that Perl into a team setting, and the mindset shift needed is HUGE. I agree with you.

The happy medium is to write your program twice: Write it solo in Perl for rapid thought-to-code, figuring out architectural issues along the way. Then, write it again in Python for scalable collaboration using the revised architecture. This gives you a working solution for the problem FAST and adheres to "Do it, then do it right".

Unfortunately, this doesn't scale to systems. I do hope LLM-driven transmogrification becomes a real thing.

Re: We were wizards – a foreword to Learning Perl (1993)

#64

About 5-6 years ago I found a new niche for Perl in my day-to-day work. I did a lot of shell scripting at the time and was constantly getting annoyed by subtle differences between macOS and Linux. Sed is especially difficult, because the flags in BSD version and GNU version for in-place search and replace do not match. Plus, sed regexes are more primitive compared to most other languages. I decided to switch from sed…

I wonder, is Perl more ubiquitous than Python for these cases?

Perl gets installed wherever `git` CLI is available, generally. I'd say it's more ubiquitous. And it doesn't suffer from the python2/3 split.

Re: We were wizards – a foreword to Learning Perl (1993)

#65
post #4
post #3

Earlier quoted context omitted.

Stream of consciousness programming?

Perl has a weird way of letting you go from thought to code, and disappearing in between, unlike any other language I've ever used. You really can go from idea to functioning system as fast as you type without a lot of pre-planning. It's hard to describe, and the style has fallen out of fashion for more formal, easier to share between humans languages like Java or python, which feel like they introduce an inherent fr…

I love this subthread; I've tried to explain this for years and I've concluded it's simply impossible to convey to someone who never experienced it. It's sad, and really frustrating, to just hear the same clueless comments and memes repeated. So I'm glad to see there are still people around who know what it was like to work with a truly expressive language.

About 15 years ago I was put on a Java project that ran for a year with half a dozen developers toiling away (along with an outsourced team that management eventually added to write unit tests). I spent half that time fighting with Eclipse and the other half divided between tearing my hair out trying to wade through the AbstractSpringFactoryInterfaceAbstractFrameworkInjectorAbstractionBuilder nightmare, being lectured at by people who learned everything they know about computers from in-flight magazines that this is the way professional software development is done, waiting for the one person who could actually build the application (which he did partly by unzipping the jar files and manually tweaking their contents), and actually coding.

To my complete lack of surprise, the project never achieved a working milestone and was cancelled. What did surprise me was that a coworker who was sympathetic to my grumbling persuaded the CTO who was trying to rescue the project to let me try it my way. On my own (using Perl and PostgreSQL), in a couple of weeks, I had a fully working prototype. We got the green light to proceed and built the company's flagship product on that stack. It was not my brilliant engineering as much as Perl's extraordinary ability to connect mind and machine (coupled of course with my brilliant engineering) that made it possible. I owe Larry Wall for a huge career boost.

Re: We were wizards – a foreword to Learning Perl (1993)

#66
post #51

Earlier quoted context omitted.

For anyone who cares, sed -i'' should be compatible on both mac and linux.

I install gnutils in mac, gsed on mac is compatible with sed on linux.

If you ever use "grep" on mac, it's also worth installing gnutils and switching to ggrep instead as it is significantly faster.

Re: We were wizards – a foreword to Learning Perl (1993)

#67
post #32
post #31

Earlier quoted context omitted.

About Python, are there practical situations outside IRC where you can't include a newline in there? This .. python -c ' import re, sys for line in sys.stdin: print(line.lower().count("foo")) ' works in shell interactively (both bash and zsh support multiline history entries well), or in shell scripts, and also in slack/mattermost/matrix/email.

You can do that as a one-liner (I have kept the unused “re” module import, to keep it as close to your code as possible): python -c 'import re, sys; print("\n".join(str(line.lower().count("foo")) for line in sys.stdin))' or if you want to avoid building one large output string: python -c 'import re, sys; print(*(line.lower().count("foo") for line in sys.stdin), sep="\n")' if memory consumption is still an issue: pyth…

[deleted]

Re: We were wizards – a foreword to Learning Perl (1993)

#68
post #14

We were indeed, and sadly like many true wizards - we were grumpy and too smart and too weird for the world. And we had too many sigyls and weird symbols and we didn’t see farther than our nose, so we weren’t that good with foretelling things, but only with practical magic. Even though wizards foretold nPm by inventing CJAN - like Cpan for JavaScript. And also IO::Async and Lehman’s work was very much ahead of NodeJS…

> We were indeed, and sadly like many true wizards - we were grumpy and too smart and too weird for the world. The submitted post exemplifies the worst characteristics of what we can call coding culture . Larry Wall was a polarising character. He could be witty but also tiresome. The C and C++ coding cultures have had their problems too. Python has been successful as a language and as a coding culture. I don't like t…

"Larry Wall was a polarising character. He could be witty but also tiresome."

Yes. This. Thank you for calling this out.

Re: We were wizards – a foreword to Learning Perl (1993)

#69

About 5-6 years ago I found a new niche for Perl in my day-to-day work. I did a lot of shell scripting at the time and was constantly getting annoyed by subtle differences between macOS and Linux. Sed is especially difficult, because the flags in BSD version and GNU version for in-place search and replace do not match. Plus, sed regexes are more primitive compared to most other languages. I decided to switch from sed…

Not to mention Write-Only nature of Perl is a nice added job security.

Re: We were wizards – a foreword to Learning Perl (1993)

#70

I liked Perl for text parsing and that kind of work.. Used it professionally for about 3 years. Two things i didn't like about it which i still don't 1. It's a conceptually huge language. There are several things to learn to be effective or you fall into the problem when the 10% that you use is different from the 10% that your teammates use. I found python attractive because of this. 2. I disliked Walls book. It was…

There's always Perl Cookbook if you need somewhere to look up solutions.
Post reply on HN