I don't think this is correct? Concatenative languages have the property that if a and b are both valid programs, that the program a || b is valid (where || means "concatenate"). But that property doesn't imply that every sequence of tokens is valid.

For example, in Cat,

  [1 2

    empty  0  1  00  01  10  11  000  001  ...
        0  1  2   3   4   5   6    7    8  ...

Otherwise, wouldn't any language assigning a valid meaning to any sequence of 0 and 1 be a Gödel numbering, even if only by saying that "an unrecognised sequence is a noop"?

> To encode an entire formula, which is a sequence of symbols, Gödel used the following system. Given a sequence (x_1, x_2, x_3, ..., x_n) of positive integers, the Gödel encoding of the sequence is the product of the first n primes raised to their corresponding values in the sequence

https://en.wikipedia.org/wiki/Gödel_numbering

"easily" is arguable. Sure, I could multiply/factor an enormous number and count how many copies of each prime it has, but I'd much rather concatenate/split some digits.

If you have a quantity in mind but you're not sure what its digits are, it can be a lot of work to learn.

If you mean what base to represent the number in, that's no more arbitrary than knowing the exact way Gödel numbers use primes.

⁵ This feature does enable a neat quine: the Perl program “Illegal division by zero at /tmp/quine.pl line 1.”, when saved in the appropriate location, outputs “Illegal division by zero at /tmp/quine.pl line 1.” The reason for this behavior is left as an exercise for the reader.

I tried it in the REPL and found that "Illegal division" can't locate method "illegal" in package "division", so presumably that gets ignored, same with method "by" in package "zero", and that "at /tmp" is the simplest version of the string that produces the error message, which apparently is more severe than the missing package warnings and terminates the program?

I'd guess the / is the operator for division, and the "tmp" is getting initialized as a variable and coerced into an integer? But "/tmp" doesn't do it, and "/tmp/" does something with regex, so I'm not sure why the parser would split it there.

    Figure 6 represents the string “gggijgziifiiffif”, which by pure
    coincidence happens to accurately represent the authors’ verbal reaction
    upon learning that “unquoted strings” were a feature intentionally
    included in the Perl language.⁵

See the sibling comment about the actual parse — "at" and "tmp" are seen as strings.

The strings get coerced into numbers due to being used with the numeric "/" operator (that's normal Perl behavor). Since the strings can't be parsed as numbers, they become "0". So, you get division by 0.

[1] https://perlmaven.com/barewords-in-perl

(Actually, implicit unquoted strings sound so nightmarish it's comical, but let's do one question at a time...)

I used to think the solution was static typing, but then I found none of the same infuriating bugs in Python, which has dynamic but strong typing, forcing you to be explicit about type conversions.

Edit: I think I've hit the nesting limit, so please reply to parent comment and I will find it.

Possible effects: People that must use Javascript, but don't want to (only choice, only framework). People that use Javascript because it's hyped or hot, not because of personal interest. Larger volume of talk, so more opportunities for griping. Much larger perception of griping (blogs, HN links, news. You almost have to work to find the Perl griping locations). The talk tends to more work issues (stuck on project, annoyed at issue), and not discussing a language you write with because you enjoy the features.

[1] https://stackoverflow.com/questions/tagged/javascript

[2] https://stackoverflow.com/questions/tagged/perl

I think the people that love perl love its expressiveness. It has a little bit of functional programming here, and a system for making an object-oriented language, and all of these handy tools and you choose which ones you need or find most readable. I've heard Ruby called a better Perl, and - as someone whose day job is largely those two things - that's completely fair.

Eg. putting "use v5.14.0;" or similar on top of your file (or compilation unit/scope) will indeed turn on strict mode for you, along with adding a number of features as well.

At the time, also auto-toggling warnings was considered unacceptable because technically, using the warnings pragma anywhere had some edge case action at a distance. This has been remedied in some later release after I wasn't involved in the language development anymore, and from some more recent version, warnings are also part of the standard import.

I imagine you (TheDauthi) already know that, though.

Huh, that's an odd failure of Perl's normal ethic of doing things that appear to make sense in context. A number should be 0 by default in additive contexts and 1 by default in multiplicative contexts.

    $ perl -MO=Deparse tp.pl 
    'division'->Illegal('zero'->by('at' / 'tmp' / 'quine' . 'line'->pl(1)));
    tp.pl syntax OK

    $ perl -e 'at / tmp'
    Illegal division by zero at -e line 1.

But yes, it converts the strings to integers and divides them, as shown in the sibling comment.

With warnings, it runs, but tells you about all of the mistakes you made. With strict, it doesn't run.

LLMs help here. From my own experiments chatGPT is pretty good "smart, context-aware" OCR agent.

However, it did give me the initial impression about other possible ways to do this, such as taking patches of color and empty space as 0s and 1s, and the totality of it as a program. I think the vast majority of those cases would be pointless noise.

So there's two extremes, one with mostly noise, one with mostly meaning. I suppose the game-within-the-game here is to find what form of interpretation does the most to credit paint splatters with the most possible meaning where, to the greatest extent possible, the meaning truly comes from the structure and not from how aggressive the rules are at choosing to see meaning.

(For those who weren't frequently exposed to "line noise"... Imagine an ASCII character video terminal that's interpreting a stream of bytes, to display meaningful text. Now imagine that the communication channel gets corrupted somehow (say, someone picks up the phone handset while modem is online, or there's interference on the cable), and there's no error correction or checksumming, so the bytes being interpreted are effectively become randomized. So random letters, digits, punctuation, control characters, etc., are being interpreted and displayed, and this is familiar, and you know it's random and why... but the joke is that it's still actually a valid Perl program.)

Many scripting languages will tolerate meaningless input.

Instead of these extremely non-character-istic splatters, I think scribbles or random raster bitmaps would be better input.

I've done this many times, trying to use the search bar and then having the debugger suddenly plop my cursor into a file....

I get what people are going for, but I don't think I would enjoy coding in Perl!

2. When intentionally writing perl, half the time my "perl -c foo.pl" complains about syntax or badly used names (usu. misspellings), with the typo to correct being obvious. As a practical matter, it's not a problem.

I see a lot of semicolons in that ocr output, which might be cheating.

A lot of fun I had with a language called Elm, in which runtime errors are nearly impossible to express.

    $ cat ~/.signature
    --

    raku -e 'try { not :2(.fear) } and do not die'
    perl -e 'do not $fear and do not die'
    raku -e 'say „The Road to Wisdom“; $*ERR and $*ERR and $*ERR but Less and Less and Less'

This is just a matter of syntax, right? So could it be determined by a stack machine? Unfortunately, the answer is no. Perl is not context free!

https://perlmonks.org/?node_id=663393

As just a guess, this question maps to the Halting Problem. (EDIT: That would have to be the question where the input is a programming language, not just for Perl. That question has been answered empirically.)

This is not about the kids who love to learn things that end up being useful skills. By all means, let them learn. But don't stop the kids who like to run around in the woods or fingerprint or pop wheelies on their bike for the sake of their future career prospects.

The fact that the tweet specifically calls out schools "teaching vocational skills so young" makes me interpret the tweet as a generic luddite response - as if Montessori schools don't make working with hand tools an explicit part of their early childhood curriculum! This does seem like she is opposed to her kid learning and not an anti-Tiger Mom take.

At that age? Daycare. Sending all kids to government-run schools freed up the parents to work longer/harder jobs. But I would never argue for kids not to get schooling. I know too many adults who cannot read properly, who cannot write a cohesive paragraph, who don't know affect from effect. Kids need more reading, not less.

TO this day, writing code, feels like play. I get the same child like satisfaction that building something out of lego would give me, that sense of "Look what I did".

Work harder, not smarter. /s

Jokes aside, I still agree with GP, in that there are more practical skills that are left out of education that would be far more useful in day to day life. The Dewey Decimal System has been replaced with search engines.

I don't need to know how a search engine works in order to type in "how to use a drill press" and read the results. But that's because the knowledge and understanding of how computers work at a high level circumvents the need to do that - a search engine is a form, give it something to search and hit the submit button. Easy.

Being taught by someone to use machining tools helps build an understanding of how every day items are made using those tools, so you have a more fundamental understanding of the items could be combined together into other more interesting things, repair them, take them apart and service them.

It's almost the opposite problem of maths in schools. We're taught maths in various incresasingly complex ways, all the way up to calculus. Those methods teach us how to use maths to do clever things. But every day maths doesn't need that. We're taught compound interest, but we have to use that to figure out how to do our taxes by ourselves without any help. Wouldn't it be nice to have an overlap there, hit two birds with one stone and we all walk away with a stronger understanding of the world?

If we're not taught how to make things, we struggle to learn how things are made, which means less things get made. Learning how to make things early, and embedding the knowledge of how things are made, enables more things to be made in future.

Follow up: where do you see it going.

Full disclosure: never implemented anything useful in perl in my personal or professional capacity for the last decade, except for debugging a few scripts here and there.

I've used Python when it was convenient, but I dislike it. So Perl remains my go to when I need to process data for more than a shell script.

Things I've written in Perl that I've run recently (or are croned so they run frequently) include: scripts to monitor shared directories for changes (kqueue) and publish the changes to a remote server so my spouse can drop images or other files to be shared on a share and get a link to send, or edit a recipe and check it from the web while shopping; my monitoring script that checks if my computers are working and emails me if not, it also reboots my dsl modem when it needs it; (for work) a tool to grab stats files from production, compute a summary, and then upload it so clients can be routed to the servers that are best for them.

I've done all sorts of stuff with Perl in the past, it's a very capable language.

Then I discovered one of Perl's best kept secrets: it allows you to write real code, if you want to.

Now I'm back to being a regular programmer again but I just happen to be more productive with Perl than anything else.

I have written about it before[1] but it boils down to one thing: it runs anywhere with no modification or installation, even 20 years from now.

[1]: https://two-wrongs.com/why-perl.html

My most recent task using it was writing a backup script that connects to various systems, archives stuff, then copies it to a NAS and then updates a backup log.

Before that I created a demo site for a business idea using Mojolicious (Perl web framework) + DBIx::Class (Perl ORM), and I believe we could have completed the project using them. But due to concerns that we couldn't find or pay Perl programmers when we scale we abandoned it for a rewrite in C#/ASP.NET. A heart vs mind decision, but business needs came first. I'm aware that I'm the only one of my age (early 30s) in my circles who has learnt Perl.

And that previous sentence is why I fear for its future.

I don't see Perl going anywhere. Neither back towards popularity, nor further into obscurity.

Making Debian possible. Allegedly, the German banking system is held together by Perl scripts. Which is good. Perl got 0 bitrot. And you don't want your bank account to rot, do you?

I wrote a different Perl script as a Sysadmin 20 years ago and used it last year. Still works.

Another time I was doing something and wanted to grok some horrid DSL (cough HCL cough) and in 20 minutes wrote a script to parse thousands of files give me what I wanted. Still use that script.

Where's it going? No idea, don't care, I'll probably keep using it for the next 25 years.

I used it as my primary language for several years and it's extremely capable and intuitive. The learning curve of it's syntax is really only slightly longer than any other language. And I have the very strong opinion that syntax contributes less than 5% of readability and the rest is up to the developer to factor smartly and name things well.

With the light syntax and giant, well-documented community repos, it feels a lot like Python With References to me, which is honestly pretty great imo. I wish more people respected Perl.

I wish we could leave them behind as a fun phase of mass adoption of programming and fully switch to strongly typed languages alone. One can dream.

The other options built into your UNIX (maybe Linux) machine were:

- C

- C++

- tcsh/ksh/bash

- awk

- TCL

What would you have chosen?

golang/rust/c doesn't fit well the kind of tasks you would use Perl to do. There is simply too much verbosity and at some point in time you will bail out of the sisyphean nature of the task. Kotlin etc are more for mobile apps.

To me, back end work is-

1. Any serious application, that needs to run for years with performance - Java.

2. Glue work- Python/Perl.

Pretty much anything that has to run on Unix(or unix like machines). Its special niche is glue code and automation related work. Use case for that happens quite frequently than one imagines.

There is a also a 'blub' nature to it as well. Many times unless you have used a tool, it can be hard to see what use case it fits in. Last two weeks I had to do a fairly heavy automation related thing at work. Bash was not suitable because the code would get big as the situation evolved. The tool has to be something using which is present everywhere(rules out things like golang, java), something in which you can rapidly prototype, something that is very good at manipulating text and something that works very well with Linux utils(Rules out python, golang). Over two weeks its size grew to something like 3K lines, and I have used it to automate hours of boring manual work, overall I think I ran it like 30 times or so.

Perl is also good at generating text which has some structure. So I have used in the past like a macro utility in languages that don't have macros. Basically I generate code using Perl. I have used this to generate python, pig and even java code many times.

Other types of work are for glue, like cron scripts, clean up, regular test scripts, rapid prototyping etc.

CPAN makes the whole experience awesome. Its still the fastest evolving library base compared to any language, only competition may be is js. You will find a library for nearly anything you want. And for something that you can't find, Perl is good at rapid prototyping. Compare this with something like Clojure, where even language goes without maintenance for months. Perl is still actively developed.

Another big factor can be commitment to backwards compatibility, you can be sure your scripts from years back will run on newer versions of Perl.

>>Follow up: where do you see it going.

Perl is here to stay. Its installed on nearly every machine you can put your hands on, and even teams don't use it, Over the years I have seen individuals use it as some sort of a personal automation and productivity language. Like a secret tool.

I guess a lot of banks, telecommunications, manufacturing and early internet companies use it heavily till date.

Basically so as long need for automation exists, Perl would exist.