Comment by srpablo | Hacker News Reader

Comment by srpablo | Hacker News Reader

I have a few ideas, but the main one is that: independent of the language/semantics, languages only really take off because of a "killer app" use case where they are required. Once that's in place, tooling is built to make it much easier to complete projects in.

As a few examples: Objective-C was only popular for years because it was required to write iOS apps. Ditto JavaScript being the only way to write for web. Ruby only got popular after Rails. C++ was the blessed way to write for Windows in the 90's. Java had a giant marketing budget, "write once, run everywhere," and was looking to be the best way to write for the web (lol applets). This isn't a perfect explanation, but in many of these cases, it wasn't about eager-vs-lazy, control flow constructs, variations in type systems, or anything related to what the language offered you, it was primarily necessity to be on the platform of your choice.

After that, tooling evolved, and they became easier to write major projects in. Why write a web app in Erlang when the JVM has every major templating system, an implementation of CommonMark, several high-performance JSON libraries, model validation, several mature build systems, and thousands of Stack Overflow answers?

This makes it hard for languages like Crystal or Nim to take off, but ON TOP OF THAT Prolog is asking its devs to completely change how they approach programming.

What would it take to make Prolog take off? A killer app. Which, in the 80's, looked like it was AI :-p

PHP's killer app was that it was easy for a System Admin to install on Apache and easy for a programmer to upload something that worked.

... for a quite generous definition of "worked".

In comparison, writing web applications with SWI-Prolog is quite safe also thanks to the powerful quasi-quotation mechanism.

"... for a quite generous definition of "worked"."

Barely. All kinds of people learned it quickly. They built web applications. It became a dominant web, application language. The momentum led to many improvements in its ecosystem and deficiencies. Prolog failed to do... any of that at PHP's scale.

A language like PHP greatly increases the chance of security problems. There is ample evidence of such issues in practice. This is one consequence of the quite low-level way to reason about the available data, and a class of problems that does not arise so easily in Prolog.

This is just one of many instances where barely working solutions are used, partly stemming from a lack of alternatives at that time. Robust web frameworks are only now becoming gradually available in Prolog!

PHP wasn't designed for secure web applications. Most of its users don't care about that. It thrives anyway. So, this isn't a failure of PHP. On contrary, the author cranking it out quickly might have been a reason for success.

Now, someone wanting secure apps might not want PHP. They traditionally went with "safe" languages such as C# or Java whose runtimes were full of 0-days. They might find Ada, Component Pascal, or Rust with a web framework helpful. Even enterprise sector hasn't been writing most web pages is Ada, though. ;)

Why are you downvoting what I wrote? You are arguing against statements I did not make.

PHP worked for many people in what I can only consider a quite generous definition of "worked", in tandem with countless security problems that arise almost necessarily from its low-level data representation. I am not arguing that this has impeded its adoption, that most users care about this, or that it does not "thrive". These are not signs that it works in the way I prefer software and languages to work. In particular, for writing secure web applications, I cannot recommend PHP.

In the future, I expect to see more and more Prolog web applications. The necessary frameworks are now becoming available, with much better safety properties.

You just repeated the statement Im arguing against: "generous definition of worked." The goal of PHP was to help people, esp non-experts, quickly build web sites. People off all skill levels managed to build web sites that did what they intended in the intended use case. As in, PHP worked for the exact thing it was designed for. It also went beyond that by getting massive adoption by people cranking out too many sites go count. Its success at its goal is legendary in a good or bad way depending on who you ask.

Next, you talk about the preference for secure, web apps. Being a high-assurance, security engineer, I'd expect you to immediately start talking about Ada, Opa w/ modified back end, SWIFT on SIF, Ur/Web, Haskell with secure framework... languages that are systematically dedigned to either make classes of vulnerabilities impossible or reduce them greatly. Also, esp Ada or SPARK whose low-level libraries are written in same language for as much safety as possible. Instead, you counter insecurity of PHP use by recommending a Prolog not designed for security with low-level components probably written in C or C++ since most Prologs are. It's probably gotten almist no pentesting to knock out low-hanging fruit either. If those are true, then that's highly hypocritical that you'd smear PHP while recommending something so insecure or uncertain in its security.

Far as downvotes, it was because you made a bogus claim about PHP's success with no substantiation. I certainly didnt downvote you cuz Im anti-censorship, voted to eliminate downvotes on Lobsters, and it's impossible to downvote a person replying to you. Check that claim by looking for downvote option next to my name. I instead prefer to counter bullshit with facts in actual comments. Also, with citations when I have time. As is clear by this one.

Thank you for your explanation! I do not in the least dispute that the goal of PHP was to help people, or that people managed to build web sites for the intended use cases. In fact, if one of PHP's goals was to allow a great number of unintended security flaws in user programs, then this was also splendidly achieved. Personally, I only cannot bring myself to call a site with security flaws "working", and when using PHP, these flaws are simply more easily made than with Prolog in my experience. Note that I need not even go as far as making any statements about particular implementations of Prolog or PHP, only about user programs written in the two languages.

Please also note that I cited quasiquotations as one important advantage of Prolog. As for citations, the most relevant publication for this feature is:

Wielemaker, J., and Hendricks, M., Why It’s Nice to be Quoted: Quasiquoting for Prolog https://arxiv.org/pdf/1308.3941.pdf

This feature lets you easily build safe template engines in Prolog. Please let me know what you think, if you have time. I am in fact frequently looking for a pentester when building Prolog-based websites, are you interested in such a project?

Wow. Im impressed with how well you handled that reply. (Thumbs up)

Although not interested in pentests, I do collect info on Prolog and logic programming in general as I think they can be a nice cheat on doing specs and code with no mismatch. Specs are the code (sort of). Additionally, verified systems use theorem provers with some using first-order logic. One can do the tool or reference imementation in those. A high-performance Prolog can iterate it quickly or be used before slower, verified provers to knock out bugs faster. It's also interesting in making apps more maintainable maybe.

So, I appreciate the link and offer. I'll definitely read it tonight. I'm sure the capability you describe can knock out web errors despite risks in underlying TCB. In return, I offer you two that are high-performance and high-assurance respectively with a bonus that's practical.

https://www.mercurylang.org

http://www.cs.utexas.edu/users/jared/milawa/Web/

https://github.com/triska/letswicrypt/blob/master/README.md

You should seriously check out Mercury if you havent. It's Prolog plus strengths from functional programming. It's also used by Mission Critical IT for business software. If you don't need Prolog's libraries, then it should (Im speculating) be superior based on features and performance alone. Just going with second hand data here cuz Im not a logic programmer. :)

Having done some work on static analysis of PHP applications, I agree that the language is very poorly designed. It seems the designers add any feature that they think will make it easier to write code, regardless of its effects on readability or security. It's an ongoing problem, too. One might have had some sympathy for an inexperienced language designer who pushed something out into the world because he thought it was cool, but then when people pointed out the problems with it, studied language design and learned to make better decisions. That's not happening with PHP; even some relatively recent design decisions are just mind-bogglingly bad. I am particularly frustrated by the choice, a few years ago, to remove the requirement that arguments being passed by reference be marked with an '&' at the call site (as well as on the function parameter receiving the reference). Since in general you don't know until runtime what function is called at a variable call site (e.g. '$f(...)'), you can't tell by looking at such a call which arguments, if any, are being passed by reference!

But, all that said, I think you can write an unsafe library or framework or app in any language. In fact I recall a vulnerability in a widely-used Ruby library in which one of the API functions normally expected some kind of object, but if you passed it a string instead, it would call 'eval' on it for you and use the result. This "helpful" behavior was not documented.

My point is that there's more to educating the masses about writing secure code than just telling them not to use PHP.

Thank you for this! Interestingly, the cases you mention cannot arise in Prolog, because Prolog terms are never evaluated implicitly. They are just terms, and you write predicates that reason over them. In pure Prolog, there is no way to pass something "by reference" either.

If you are determined enough, you can definitely write an unsafe library or app also in Prolog, and security mistakes are also routinely found in Prolog implementations, just as in PHP or Java implementations. The main point is still though that a large class of security issues that easily arise in PHP user programs by one of the ways you mention is far, far less likely to occur in Prolog programs, due to the more direct, symbolic way you reason about data in Prolog, and additional mechanisms such as the mentioned quasiquotations which allow safe embeddings.

" The main point is still though that a large class of security issues that easily arise in PHP user programs by one of the ways you mention is far, far less likely to occur in Prolog programs"

This is true. While we're at it, I think it's worth bringing up that the most powerful use of Prolog is embedding it in a LISP that is "batteries included." One like Racket. That way, one can use a safe, easy-to-analyze, functional style for most of the application, one or more DSL's for the templating (esp HTML), and Prolog operating on LISP structures when Prolog is best thing to handle it with. Alternatively, Shen uses something like Prolog as its type system so you can hand-roll a custom, type system for each component which might include security properties.

Far as good design, web, and security-oriented, the best I've seen is Opa language for doing that plus being productive.

http://opalang.org/

Too bad they moved the backend to Node. Probably to latch onto an ecosystem getting momentum which is a lesson from Worse is Better philosophy. Most IT tech that didn't disappeared into history at some point. I'd have preferred it be Go if one of the new, popular things given its fast, simpler, and safe enough. Hell, if libraries aren't a concern, they can even output safe subset of C with all the checks enabled like Pieter Hintjens did with iMatix DSL's.

I thought Opa looked very interesting when I first heard about it, but I don't see much recent activity on the GitHub repo. Is it still alive?

I didn't even realize the last blog post as Sep 2013:

http://blog.opalang.org/

Hell, it might be dead. I'll have to email them some time this week to find out what's up. Fortunately, it's open-source so others can pick up where they left off if they want. Or do a clean-slate work with similar capabilities.

Got word from a developer that the project is on hold. He claimed no residual vulnerabilities since it extracts to Node.js which is maintained. He said dome are using it in production. They still welcome contributors.

Yeah, it seems dead for now.

"I agree that the language is very poorly designed. It seems the designers add any feature that they think will make it easier to write code, regardless of its effects on readability or security. "

That's exactly what they do. It's why it succeeded at original goal, got popular, and is currently a mess for folks who've seen better-designed things. Further, I'll add that it doesn't appear to have been designed at all so much as a hacked together pile of features that were useful to the author at the time then extended over time. Just like C was when I researched it.

It's even worse than the two of you think. It gets worse during the times they tried to "design" some aspect of it. The hashing of names was worth bookmarking:

http://news.php.net/php.internals/70691

re static analysis

I had one project on that saved back in the PHP 5 days. What's the current state-of-the-art in static analysis tools for PHP in both commercial and FOSS? And does that sub-field have any that can prove the absence of common, severe errors like Astree Analyzer does for C and SPARK for Ada? The PHP equivalent of severe errors anyway. Especially anything allowing code injection.

"widely-used Ruby library in which one of the API functions normally expected some kind of object, but if you passed it a string instead, it would call 'eval' on it for you and use the result. This "helpful" behavior was not documented."

When eval will happen or whether risky constructs like that are used at all is one of the things that would be on my list of requirements for static analysis tools. I should be able to spot those kinds of issues in one pass before using a library. In theory anyway.

"My point is that there's more to educating the masses about writing secure code than just telling them not to use PHP."

It takes some books and practice. Also, you can get pretty far telling them to use Airship CMS since it was designed for security. I don't know anything else about it, though, since I don't do web apps or PHP.

> What's the current state-of-the-art in static analysis tools for PHP in both commercial and FOSS?

I don't know, sorry. I pay very little attention to PHP.

> And does that sub-field have any that can prove the absence of common, severe errors like Astree Analyzer does for C and SPARK for Ada?

Not to my knowledge.

Why the downvotes to the parent?

The evidence is there. https://www.cvedetails.com/top-50-vendors.php

I think sometimes you don't even need the "killer app" when the language itself is "pure tooling" and there is a sufficient demand for tooling in a given market, see TypeScript that basically is "JavaScript with tooling".

Reply on news.ycombinator.com