Live data from Hacker News

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

jwgoerlich.com

111–120 of 130 posts

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

#111

Earlier quoted context omitted.

I offered to help out with the Perl 6 logo, as I had both experience writing Perl as a career and having gone to art and design school - while also running a printing studio of my own. I joined the Perl6 dev mailing lists, listened in on them, offered my support, gave a broad stroke on design ideas, backed them up with reasonable arguments and asked for comments. Larry chimed in basically saying, "no, because this su…

That cheap logo did serious brand damage...

"Perl 6" in a monotype typeface would have been worlds better.

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

#112
post #98

Earlier quoted context omitted.

It is! Modern macOS, fresh install: no Python, no Ruby, but Perl is there. Git for Windows adds Bash with Perl in it. Every linux server has it. You probably can come up with some Docker image that doesn't have it installed, but it comes in as a dependency to a lot of linux software. The cool thing is that Perl is compatible, and maintaining compatibility is the top priority for Perl developers. so, many distros keep…

> It took them years and years, but all this time Perl has been a notable exception. If we take Apple at their word then it's an exception only in that they haven't got round to it yet , not that it isn't also going to be culled -- the Catalina release notes mentioned Perl explicitly alongside the other two: Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy…

Yep, Ruby and Python got removed very quickly from the system following this announcement. Perl, however, stays. It seems like some components of macOS depend on it and the dependency is hard to remove. It will likely happen but huge kudos to Apple for keeping it up to date meanwhile.

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

#113

Earlier quoted context omitted.

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.

Perl did have a 5.6/5.8 split over unicode, but it wasn't nearly so bad. By the time 5.10 came out, I think everything had been sorted. Or my work changed and I stopped running into code that I needed to patch 'use bytes' into.

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

#114

Earlier quoted context omitted.

That cheap logo did serious brand damage...

"Perl 6" in a monotype typeface would have been worlds better.

An elegant logo having "Camellia" is straightforward to design. They could even have some fun, use the fact that Camellia is the Tea plant and lampoon Java (with a flower floating on a cup for example, Japanese style). That would had sent the correct message of "we are back, unafraid to comparisons, and want our throne returned". And would be perfectly inclusive for both men and women.

We all ask the children to name the pets. Is cute, but often we live to regret it. With logos is the same.

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

#115

Earlier quoted context omitted.

"Perl 6" in a monotype typeface would have been worlds better.

An elegant logo having "Camellia" is straightforward to design. They could even have some fun, use the fact that Camellia is the Tea plant and lampoon Java (with a flower floating on a cup for example, Japanese style). That would had sent the correct message of "we are back, unafraid to comparisons, and want our throne returned". And would be perfectly inclusive for both men and women. We all ask the children to name…

I love it - these are really good, fun ideas.

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

#116
post #19

Earlier quoted context omitted.

Bashing Perl is a meme precisely because of the mentality of the creators of Perl (who set the culture). This "Forward to Learning Perl" epitomizes the mentality: Imagery of wizards, alchemy, breaking all the stuffy rules that quashed creative thought, etc. He even says "bowing down at the Temple of Orthogonality" like orthogonality a bad thing! It hearkens back to the days when motor cars were curiosities that requi…

> Perl was rightly bashed because it was the poster child of cowboy coding, which flies in the face of good engineering practices: Understandability, predictability, reproducibility, measurability, safety. That’s the meme, but it’s simply not true. I’m going to use Python as a basis of comparison because that’s the language which, from my perspective at least, seemed to replace Perl. > understandability A lot has bee…

Some of the arguments about Perl and bad engineering practice are not entirely without merit. Neglecting 'use strict;' or 'use warnings;' in your script typically makes this more apparent. The language itself however does not attempt to constrain developers in the same way modern languages do, instead the burden of responsible engineering is placed on the developer. The result is people that deal with badly engineered Perl typically become sour to the language itself.

I reserved my criticisms of Perl for things like signal handling and it's implementation OOP(to name a few), but overall it's a good language.

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

#117
post #92

Perl was the first programming language I worked with at a real, paying job. I don’t miss that job, but it did teach me a lot about how to deliver value quickly (Perl is still better at smashing 400 million lines of text than most other languages), and some of the impediments to that (Perl’s “write only” syntactic approach). For all of Perl’s shortcomings, I’ve always felt that no other language came with Larry and R…

Now thanks to Devin, anyone can have that skill!

But AI can never replace the human dorkiness I bring to a project.

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

#118

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…

regarding 2., are you sure you're referring to the Camel book and not the Llama book? To me, Programming Perl (Wall, Camel) is closer in spirit to K&R than Learning Perl (Schwartz, Llama)

Ah.. I'm not sure now.. It was a long time ago and i can't really remember which it was. The name Schwarz is familiar. Maybe it was that.

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

#119
post #84

Earlier quoted context omitted.

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.

That split was terrible and it took over a decade to fully resolve, but it's behind us now.

...for those lucky enough to be able to do so. I've been promised the Red Hat Enterprise Linux 3 systems will be replaced in two years. 10 years ago, they were to be replaced in one year.

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

#120
post #34

Earlier quoted context omitted.

Higher Order Perl is such a gem, one of the best programming books in general.

While Higher Order Perl had a lot of neat tricks, they were quite useless in production because they would slow things down significantly with all the subcalls.

Becouse that's like functional programming work :) It is liked by Academia peoples and those that can't be bothered by implementation design.

But in reality it is how reality works: more complicated things consume execution time: a is Int.range(1..3) IS NOT THE SAME AS: "load 1 to register A" - it contains 'if' or few on every single use. Or function call(s).

We need CPU's that support such things natively (or via cooprocesor or something, with atomics and full transactions :) ) or need to accept slow code or layer like OS for "rich types" and "type safety"...

Post reply on HN