This was once unthinkable — now I find myself having to defend one of the Monastery's more infamous users.

I could name a few things that aren't purely interpreted and aren't interpreted at every run, such as [a list of XS-based modules]

I am fairly sure that this misses his point: Perl programs are compiled only to an in-memory form; there are no binary artifacts that remain usable even if they cannot be regenerated, as with languages like C. (C is a bad example here because backwards compatibility is maintained, but I do not know of any examples of compiled languages that did what PHP did — or any language other than PHP that did that.)

If your latest C compiler cannot compile your old sources, the old binaries still work; Perl programs have no such binaries. If current perl can no longer load the version of Perl your programs need, your only solution other than rewriting your code is to keep an old version of perl itself around that can load your code.

Put DBI in that list for your previous point too.

You are both correct here. DBI is an XS module, but his argument was centered on Perl's modularity: DBI only exists in your program if you ask for it, while in PHP all available extensions are effectively statically-linked into the interpreter and register their symbols in the single global namespace, a limitation that even Tcl moved beyond years ago.

The Perl language has largely avoided such snares because, as a language, it is minimal.

Compared to PHP maybe, but if you read the grammar it's really not and if you read the Camel it's really, really not.

Perl probably has the most complex grammar of any programming language I know, complex enough that full syntax highlighting in Emacs actually requires a fair amount of Lisp code to fix up what the syntax tables cannot express. As a language, Perl has very, very, vary far from a minimal grammar, but his point seems to have been that the set of builtins is small compared to PHP, where everything that Perl does with XS modules instead has to be provided by yet more builtins.

unless you truly believe that using a platform that's supported for things like bug fixes and security improvements represents no measurable business gain

I have worked in places like that. Managers often do not see that value; they see only "we have to spend all this money 'fixing' something that is not broken why again?" because you are changing a large amount of code for the same feature set.

No, managers do not always see security as "business value", either. There was one system, written in an old PHP4 framework, that kept getting cracked and various bots installed. Management preferred to routinely clean the intrusions off of the server instead of replacing the system with something reasonably secure. Yes, that is insane. No, that was not my call. I no longer work there.

Perl created a lightweight and flexible way to interface with the standard binary libraries upon which we all ultimately depend, without embedding this directly into the compiler/interpreter.

I have no idea what this means.

He seems to be describing XS in that sentence.

Lisp or a Scheme or a Forth or Smalltalk

Arguably, Common Lisp macros are a preprocessor, itself written in Lisp; consider the MACROEXPAND and MACROEXPAND-1 builtins from this perspective. Forth grammar is simple enough that defining procedures can make interesting quasi-syntax that ultimately relies on the Eliza effect, and I do not know enough about Smalltalk to comment. Raku is also notable here; if I understand correctly, there are metaclass-like entities in Raku that can define their own parsing rules, distinct from the main Raku grammar.

If your latest C compiler cannot compile your old sources, the old binaries still work

That's not always true, especially if they use dynamic linking. Sometimes it's not even true with static linking. (Try to run an old proprietary Linux game from before 2000 on a recent system, for example.)

No, managers do not always see security as "business value", either. There was one system, written in an old PHP4 framework, that kept getting cracked and various bots installed. Management preferred to routinely clean the intrusions off of the server instead of replacing the system with something reasonably secure. Yes, that is insane. No, that was not my call. I no longer work there.

I've seen that too, but you're reading into sundial's comment something he never said. He explicitly argued that there was no business value to moving from PHP 5 to PHP 7 and tried to convince people of that.

That's not an argument I expect to hear from a developer of his purported experience. Running a public-facing project with a dependency that's out of support from its maintainers as well as long-term support from its distribution is ignorant and best and, more likely, malicious malfeasance.

That's why I respond. I am 100% in favor of asking "What's the business value of this technical change?", but anyone who claims to be a senior developer but snidely brushes away the idea of security updates as an annoyance and hindrance is doing something very wrong.

That's not always true, especially if they use dynamic linking.

That is a fair caveat after a system upgrade, but I was thinking of a scenario where the compiler has been upgraded specifically.

argued that there was no business value to moving from PHP 5 to PHP 7

From the perspective of a manager who is looking only at the feature lists, what is gained by that change? The "after" feature list looks just like the "before" feature list.

I see his perspective and I have seen managers apparently make decisions with that kind of thought process. I have had to very carefully firewall Windows servers partially from the Internet, so their services were still available, but the wandering malware could not reach the SMB listener. There was no upgrade path because another piece of proprietary software relied on that specific version of Windows and the newer version would have required a large chain-reaction upgrade (including replacing some very expensive long-life-span equipment that was actually still supported by its manufacturer but not by the other vendor) to continue to support a small part of the business that brought in enough revenue to keep operating but not enough to justify that much expense.

The problem is what PHP did — breaking backwards compatibility and dropping maintenance on the older version. That Perl 5 remained maintained is why the Perl 6 fiasco did not kill all of Perl.

PHP was able to drag its userbase along because most of them barely understand what they are doing and have no real alternative to PHP. A few well-run projects happen to be in PHP because their early prototypes were made in PHP and incrementally grew complex enough that migration away from PHP is very difficult for them. As an example, last I checked, MediaWiki has an ongoing long-term effort to migrate to Python. The typical small PHP "app" does not have anything close to the level of developers available to MediaWiki. They are stuck with PHP, and the PHP runtime developers learned this after pushing PHP 5 on their community and have continued to abuse this power.

The perl developers do not have this power — mastering Perl in the first place requires developing a level of skill sufficient to easily branch out into other languages; I actually learned C after learning Perl. Perl developers can jump to other languages much more easily, and breaking backwards compatibility to the point of needing significant rewrites has a much lower threshold for those rewrites to go to some other language if there is the slightest hint that it could happen again. Put simply, Perl is a far better language than PHP, with a far more skilled community that, unlike most PHP developers, can already go elsewhere.

Accordingly, I argue that backwards compatibility must not be broken without very, very, very good reasons — and the advice in PBP does not meet that threshold for a language that famously touts TIMTOWTDI.

> Arguably, Common Lisp macros are a preprocessor, itself written in Lisp; consider the MACROEXPAND and MACROEXPAND-1 builtins from this perspective

Nope. Syntactic macros are lightyears ahead of preprocessor stuff.

Source filters are fancy preprocessors and failed to deliver because they require an extra parsing phase and understanding of the grammar at a distance.

Lisp macros look like functions but expand in the very same parsing phase, no confusion here. Eg a macro in a comment will never be expandend!

And they get their arguments as code before it's evaluated and can reconfigure it. Eg a deeply nested peace of syntax.

That's incredibly powerful.

Switch.pm (and so many things more) as syntactic macro would actually really work.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

To me, the only difference is that the Lisp macro facility does not actually print its result for the next stage to read back in, but it could do that and still work. The difference from a preprocessor seems to me to be an implementation detail.

I am currently up late drafting a Meditation on the broader topic. I hope to have it posted soon.

Like practically the whole language?

• interpreter

  Strictly speaking, a program that reads a second program and does what the second program says directly without turning the program into a different form first, which is what compilers do. Perl is not an interpreter by this definition, because it contains a kind of compiler that takes a program and turns it into a more executable form (syntax trees) within the perl process itself, which the Perl runtime system then interprets.

Update

Wikipedia lists laxer definitions for Interpreter_(computing)

But since modern languages have multiple layers of "compilation" and processors are loading machine commands into a register for "interpretation", these are quite fuzzy definitions.

update

corrected WP link

Unless and until his comments are wiped from this site before anyone who doesn't know better has the chance to read them, it's better to counter his harmful nonsense than to ignore it and let it infect someone who doesn't deserve it.

> before anyone who doesn't know better has the chance to read them, it's better to counter his harmful nonsense than to ignore it

Fighting a troll is akin to an asymmetric war, which is aimed at exhausting the oponent.

This "guérillero" keeps repeating the same dangerous drivel.

There is no need to counter it again and again, if it was already done.

Just linking is efficient and helps those who "don't know better". This is best done in a clinical and unemotional way.

Please see ...

• Don't feed, but link! (Sundial)
• All you need to know about SundialSvc4
More from eyepopslikemosquito:
• BUK vs Sundial
• reasons why I often downvote your posts
• see the "Other" section on eyepop's homenode for more
• more at LanX#Sundial

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

Indeed. It is why we implemented this.

Please, don't feed the troll

You're calling chromatic a troll ??

Correction - I thought AM was replying to jcb, but now I see the reply was directed at chromatic.
My mistake.

Cheers,
Rob

I believe asking chromatic not to feed a troll.