4 ms·

PL/SQL is an abomination of a language. It’s easily the worst example you could have given.

pjmlp 2y ago
Actually it is my favourite stored procedured programming language, nothing else comes close to it in capabilities, or tooling. Transact SQL is a close second, thanks to the tooling, but not as great as language, still better than the alternatives. pgSQL has the plus of being similar to PL/SQL, but it is neither as feature rich, nor in tooling. Everything else is even worse.
- hnlmorg 2y ago
  Do you actually mean that sincerely or is this just another occasion that you’re taking an opposing view just for giggles? Because given your past comments favouring Java and my experience with both those languages, I’m very surprised you’d pick PL/SQL over SQL/JRT.
  - pjmlp 2y ago
    I really mean that, all those approaches using Perl, Java, .NET as stored procedures never gained much love among DBAs or the market in general, and I always favour approaches where I am not the only person on the building that can change something. Also those approaches lack the end to end tooling, so you're basically back at printf debugging.
    - hnlmorg 2y ago
      That’s a fair point though it’s more of a practical argument when the topic was more academic discussion with regards to language design. But I do agree that practical considerations are important when making architectural decisions.
      - pjmlp 2y ago
        This is actually quite relevant to language design, too many people still get lost on discussing about grammar and language semantics, forgeting about everything else that is quite relevant why chose language A over language B.
        deleted 2y ago
        [deleted]
        hnlmorg 2y ago
        Ironic you say that because usually we have the opposite positions with me asking you to have a little pragmatism. I’ll save this post and share it with you the next time a Go thread comes up. ;)
        pjmlp 2y ago
        Share at will, as professional, I am the first to chose C or Go if that is what the customer requires. It is the customer and their happiness to the service that matters, not what programming languages I enjoy using. Something that more people should actually think about, instead of proposing rewrites and then leaving when it isn't fun any longer.
        hnlmorg 2y ago
        On that much we do agree
  - mike_hearn 2y ago
    The issue with stuff like SQL/JRT is that often stored procs are just running a few SQL statements in a row, the stored procs are being used for security or latency optimization but not because there's some truly complex logic. And if you want a language that has the basics like variables, loops, conditionals, data structures etc but which also makes issuing SQL statements natural, then it's hard to beat PL/SQL.

Actually it is my favourite stored procedured programming language, nothing else comes close to it in capabilities, or tooling. Transact SQL is a close second, thanks to the tooling, but not as great as language, still better than the alternatives. pgSQL has the plus of being similar to PL/SQL, but it is neither as feature rich, nor in tooling. Everything else is even worse.

hnlmorg 2y ago
Do you actually mean that sincerely or is this just another occasion that you’re taking an opposing view just for giggles? Because given your past comments favouring Java and my experience with both those languages, I’m very surprised you’d pick PL/SQL over SQL/JRT.
- pjmlp 2y ago
  I really mean that, all those approaches using Perl, Java, .NET as stored procedures never gained much love among DBAs or the market in general, and I always favour approaches where I am not the only person on the building that can change something. Also those approaches lack the end to end tooling, so you're basically back at printf debugging.
  - hnlmorg 2y ago
    That’s a fair point though it’s more of a practical argument when the topic was more academic discussion with regards to language design. But I do agree that practical considerations are important when making architectural decisions.
    - pjmlp 2y ago
      This is actually quite relevant to language design, too many people still get lost on discussing about grammar and language semantics, forgeting about everything else that is quite relevant why chose language A over language B.
      - deleted 2y ago
        [deleted]
      - hnlmorg 2y ago
        Ironic you say that because usually we have the opposite positions with me asking you to have a little pragmatism. I’ll save this post and share it with you the next time a Go thread comes up. ;)
        pjmlp 2y ago
        Share at will, as professional, I am the first to chose C or Go if that is what the customer requires. It is the customer and their happiness to the service that matters, not what programming languages I enjoy using. Something that more people should actually think about, instead of proposing rewrites and then leaving when it isn't fun any longer.
        hnlmorg 2y ago
        On that much we do agree
- mike_hearn 2y ago
  The issue with stuff like SQL/JRT is that often stored procs are just running a few SQL statements in a row, the stored procs are being used for security or latency optimization but not because there's some truly complex logic. And if you want a language that has the basics like variables, loops, conditionals, data structures etc but which also makes issuing SQL statements natural, then it's hard to beat PL/SQL.