Hacker News Reader

Hacker News

Comment by seanmcdirmid | Hacker News Reader

Parent Full thread

seanmcdirmid

I don't think there is a PL that is harder to parse than C++.

View on HN

Perl [1] (at least pre-6) and Ruby [2] have good claims too.

* [1]: http://www.jeffreykegler.com/Home/perl-and-undecidability

* [2]: https://programmingisterrible.com/post/42432568185/how-to-pa...

I don’t know whether it is really hard to parse for a computer, but PL/1 may be a good candidate. Its idea that you can’t expect programmers to know every keyword of the language and, hence, the language cannot have reserved words can lead to programs that humans have trouble parsing. A simple example:

  IF x THEN y = z; ELSE = w;

Here, the parser can’t know that ELSE is a variable until it sees the second equal sign. For a more involved example, take a look at http://multicians.org/proc-proc.html

(the idea that one cannot expect programmers to know all keywords isn’t a bad one; http://www.cs.vu.nl/grammarware/browsable/os-pli-v2r3/, which claims to be incomplete, has 310 keywords. Drawing the conclusion that one should not have reserved words _is_ a bad idea)

Older language designers seem to have held natural language as their ultimate syntax, so reserving keywords would be anathema to that goal. It's probably also in direct conflict with efficient parsing. And you still see some people thinking along the same lines when they obsessively over-value "DSL"s and

    like().writing(all.their.code()).like(*this)

In which case, the programmer doesn't have to memorize keywords, but they do have to memorize these obscure, unpredictable, and noncommunicable features of where to properly put their dots and parens. Which is far worse, in my opinion.

That is called a fluent interface (https://en.wikipedia.org/wiki/Fluent_interface) and is generally frowned on by experienced language and API designers (even of the OO variety).

It has nothing to do with language keywords, it is just too far away from operational behavior to be very readable or debuggable.

It looks like "fluent interface" resembles "point-free" programming:

https://en.wikipedia.org/wiki/Tacit_programming

However, there seems to be a key difference. Under "fluent interface", it looks like the object context is pointlessly being chained and the operations are just side-effecting on it, whereas "point free" programming implements a transformation pipeline by chaining side-effect-free operations.

E.g.

  turtle.rotate(90).pen_down().forward(5);

Kind of thing which isn't a pipeline at all, and could be written:

  turtle.rotate(90);
  turtle.pen_down();
  turtle.forward(5);

and arguably should.

I think using some sort of construct that topicallizes the object is a good middle ground between the two.

For example this Perl 6 code:

  with turtle {     # store in topic variable $_ (if it's defined)

    .rotate(90);    # implicit method call on $_
    .pen_down();
    .forward(5);

  }

No it's not about keywords, but about jumping through fiery hoops to create code that sounds like natural language when you read it out loud.

I can imagine that parsing Coq is pretty dang difficult since the user is able to essentially define and use their own syntax in the code. Also parsing Agda seems non-trivial, though likely not as hard as C++.

Not yet, but the C++ committee is hard at work at creating the next C++ revision.

Reply on news.ycombinator.com