http://qs321.pair.com?node_id=11119334


in reply to Amicable divorce

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re^2: Amicable divorce
by chromatic (Archbishop) on Jul 15, 2020 at 01:14 UTC
    based solely on 'who I am,'

    No, it's based upon the signal to noise ratio of your comment, as usual. For example:

    Since Perl is a "pure interpreter," it is entirely dependent upon the language system's re-interpretation of the entire code body ... every single time that it is run. There is no "executable code" resource

    Not true. I could name a few things that aren't purely interpreted and aren't interpreted at every run, such as POSIX or Encode or almost any crypto library or a speedy JSON or XML or YAML parser or....

    You have no niceties such as use DBI; in that language.

    Oh, good point. Put DBI in that list for your previous point too.

    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. You might be thinking of Forth or Smalltalk or Scheme if you're thinking of a minimal language. Even K&R C.

    For one – and, only one – of my clients, this amounted to almost a quarter-million dollars of labor cost, spread among a number of people, to move the system to PHP-7 from PHP-5 while otherwise remaining almost exactly where it was. (No business-value gained ...) I taught the others how to continue using the PHP-5 system even as their (Linux ...) distributors "moved on."

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

    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.

    This language is actually so flexible that it can re-invent itself on the fly. No other language that I have ever been aware of has ever been able to approach this level of magick without a preprocessor.

    You should really learn something about a Lisp or a Scheme or a Forth or Smalltalk.

      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.

        > 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

      > I could name a few things that aren't purely interpreted and aren't interpreted at every run

      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.

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

      update

      corrected WP link

      Please, don't feed the troll.

        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.

        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
Just feeding the bin (Trolls)
by LanX (Saint) on Jul 16, 2020 at 16:06 UTC
    To all monks who replied to this parent node or below.

    Please be aware that with currently -10 accumulated votes the whole sub-thread is now hidden from the public.

    This means visitors which are not logged-in and search engines won't find your contributions.

    You are most likely reiterating arguments for regulars knowing them already by heart...

    Please consider just linking to older discussions, if you really think you need to inform some monks again.

    I suppose most of you don't wanna spend energy writing for the bin. ;-)

    For more links please see the collection in LanX#Sundial

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

      I suppose most of you don't wanna spend energy writing for the bin. ;-)

      Speak for yourself! The roundfile is my #1 fan!!!

Re^2: Amicable divorce
by Your Mother (Archbishop) on Jul 15, 2020 at 16:35 UTC
    The possibility of having his inanities, lies, and blundering as an attachment to his professional résumé seems to be the closest thing to a deterrent…Re^4: Perl and MongoDB

    You really should be taking that more seriously… unless you have a trust fund or something, then… lucky you, power on, I suppose. The only thing that stops me from spending a three-day weekend assembling a director’s cut of it to ref="follow" link to you is your total and unconditional cessation of being a general irritant here.

Re^2: Amicable divorce
by Anonymous Monk on Jul 15, 2020 at 19:06 UTC
    be excommunicated once again

    Coming up on two years since you posted My last post on PerlMonks .... lol.

    based solely on 'who I am,'

    Only if the garbage you routinely spew here is identical with your person. You're a dipshit, but I don't believe you're a bot.

    The fact is, you've never been excommunicated from here, for that nor for any other reason. Sometimes I think you are, through your persistently trollish behavior, daring the gods to do it, though.

      I am not going to tell you what to post but shouldn't we concentrate on the subject?

      However, on using vulgarities and anonymously and not in the context of literature I will tell you my opinion: it is bad form. It degrades the level of content for the rest of the thread, which is unfair.

      scripta manent and electronic scripta manent foreva: it will haunt this thread for the future: someone reading it and suddenly finding that more than once it branches to bullying.

      I also find that it gives a bad name to the Monastery and me (or us Monks) who do not participate in this troll-hunt.

      I was never an apple producer to know first-hand the "one bad apple" syndrome but I would think that, nowadays, given the alledged progress we made since the "Caves", to be able to communicate on the basis of logical arguments to demonstrate the correctness or incorrectness of someone's point. There is no alternative to that no matter how painful it is or how high the deja-vu level rises. OK there is one, just do not respond.

      1' Edit: the level and technical accuracy of content must be preserved also - we can not allow wrong content to float. But I think a visible warning, as a comment, underneath from a "technical accuracy team" member will settle it.

      Another edit: please feel free to downvote if you disagree with the overall approach and suggestions. It will be a guide to me.

      Another edit: banning someone because he is spreading wrong solutions/advice etc. it is valid in my own opinion and could be exercised perhaps with a vote. Protecting PM's standing is legitimate.

      bw, bliako (je suis dipshit)