5 ms·

Awesome. When I saw all the things it could do in so little code, I assumed a higher level language would be used. But, nope...plain old C with the usual standa

Awesome. When I saw all the things it could do in so little code, I assumed a higher level language would be used. But, nope...plain old C with the usual standard libraries. The parser for the syntax highlighting is super cool. Concise and declarative definition of the syntax (well, the keywords, anyway), in HL_keywords, and then maybe 150 lines of code for the parser. I doubt it would work well for a much more complex language than C (say, JavaScript, or Perl), without a lot more smarts. But, it works really well on the C I looked at. Colors are handled in a cute way, too. All around, I'm just astounded at how concise this is, while still being entirely readable and comprehensible. This isn't clever/tricky golfing code, this is actually human-readable C code. Edit: Also, I'm struck by how nice/simple the editorProcessKeypress handling is. Trying to do something like this in JavaScript/HTML5 is crazily more complex and verbose. Seeing something like this reminds me how messy user interaction still is in the browser, compared to old CLI and desktop paradigms.

groovy2shoes 10y ago
The syntax highlighter isn't really a parser, per se. It's just a lexer / tokenizer / scanner / what-have-you, which tend to be fairly compact state machines. As an aside, I agree with your edit. As someone who started programming back in the DOS days, whenever I do Web development, I'm always floored by how much it feels like one step forward and two steps back. So many simple things just aren't simple when it comes to the browser, and even certain protocols on the backend like FastCGI seem way more complicated than they need to be (SCGI seems pretty nice, though I feel it's missing a way to signal out-of-band information to the Web server, the way you'd use stderr in CGI, for example (though perhaps I'm missing something there)). As much as I love the idea of sending semantic markup over the wire for document transfer, I can't help but wonder if a more terminal-like protocol would be better for application "delivery", the way we used to do with telnet and BBSs in the 90s, with an upgrade for multimedia. But I digress...
- nostrademons 10y ago
  FastCGI/SCGI were obsoleted by having app servers simply speak HTTP; the web gateway just needs to function as a simple reverse proxy. HTTP is about as simple as it gets to parse - you can write a passable (not quite production quality, but works) parser in about 10 minutes. A lot of the difficulty in webapps is because every webapp is inherently a distributed system, which are always hard. Single-page apps with no connection to a server are actually quite simple, but they're also about as commercially viable as DOS programming (i.e. not at all).
  - voltagex_ 10y ago
    A while back I'm sure I saw a HTTP state diagram posted here that showed writing a HTTP parser is anything but simple. I guess if you only have to be a (reverse) proxy you might get away with it.
    - niftich 10y ago
      You're thinking of https://github.com/for-GET/http-decision-diagram https://github.com/for-GET/http-decision-diagram
      - jahewson 10y ago
        That's the state diagram for processing the full complement of HTTP requests. Nothing to do with parsing. The parsing bit is trivial.
        niftich 10y ago
        While you're correct that it's a state diagram processing HTTP semantics and not parsing; parsing a text-based protocol is far from trivial. In fact, the HTTP2 FAQ explicitly mentions [1] that reducing parsing complexity was a motivation for going binary with HTTP2. [1] https://http2.github.io/faq/#why-is-http2-binary https://http2.github.io/faq/#why-is-http2-binary
        nostrademons 10y ago
        I've done perfectly adequate HTTP parsing with this Python 4-liner: headerText, body = text.split('\r\n\r\n', 1) headerLines = headerText.split('\r\n') method, path, protocol = headerLines[1].split(' ') headers = dict(line.split(':').map(str.strip) for line in lines[1:]) For production use you'd probably want something a bit faster & more robust like Mongrel's HTTP parser (itself only 166 lines of Ragel), which powers several million websites out there: https://github.com/mongrel/mongrel/blob/master/ext/http11/http11_parser.rl https://github.com/mongrel/mongrel/blob/master/ext/http11/ht...
- icedchai 10y ago
  I started programming in the same era, and feel the same way about "web apps" being a step backwards. The problem is we're building apps on top of a platform originally intended as a document viewer, with kludge upon kludge piled on...
  - stillworks 10y ago
    If only we can take out HTTP and only use JSON (or something even simpler) end-to-end.
erlehmann_ 10y ago
> I doubt it would work well for a much more complex language than C (say, JavaScript, or Perl), without a lot more smarts. Perl can not be parsed, making accurate synthax highlighting impossible: http://www.perlmonks.org/?node_id=663393 http://www.perlmonks.org/?node_id=663393

groovy2shoes 10y ago

The syntax highlighter isn't really a parser, per se. It's just a lexer / tokenizer / scanner / what-have-you, which tend to be fairly compact state machines. As an aside, I agree with your edit. As someone who started programming back in the DOS days, whenever I do Web development, I'm always floored by how much it feels like one step forward and two steps back. So many simple things just aren't simple when it comes to the browser, and even certain protocols on the backend like FastCGI seem way more complicated than they need to be (SCGI seems pretty nice, though I feel it's missing a way to signal out-of-band information to the Web server, the way you'd use stderr in CGI, for example (though perhaps I'm missing something there)). As much as I love the idea of sending semantic markup over the wire for document transfer, I can't help but wonder if a more terminal-like protocol would be better for application "delivery", the way we used to do with telnet and BBSs in the 90s, with an upgrade for multimedia. But I digress...

nostrademons 10y ago
FastCGI/SCGI were obsoleted by having app servers simply speak HTTP; the web gateway just needs to function as a simple reverse proxy. HTTP is about as simple as it gets to parse - you can write a passable (not quite production quality, but works) parser in about 10 minutes. A lot of the difficulty in webapps is because every webapp is inherently a distributed system, which are always hard. Single-page apps with no connection to a server are actually quite simple, but they're also about as commercially viable as DOS programming (i.e. not at all).
- voltagex_ 10y ago
  A while back I'm sure I saw a HTTP state diagram posted here that showed writing a HTTP parser is anything but simple. I guess if you only have to be a (reverse) proxy you might get away with it.
  - niftich 10y ago
    You're thinking of https://github.com/for-GET/http-decision-diagram https://github.com/for-GET/http-decision-diagram
    - jahewson 10y ago
      That's the state diagram for processing the full complement of HTTP requests. Nothing to do with parsing. The parsing bit is trivial.
      - niftich 10y ago
        While you're correct that it's a state diagram processing HTTP semantics and not parsing; parsing a text-based protocol is far from trivial. In fact, the HTTP2 FAQ explicitly mentions [1] that reducing parsing complexity was a motivation for going binary with HTTP2. [1] https://http2.github.io/faq/#why-is-http2-binary https://http2.github.io/faq/#why-is-http2-binary
        nostrademons 10y ago
        I've done perfectly adequate HTTP parsing with this Python 4-liner: headerText, body = text.split('\r\n\r\n', 1) headerLines = headerText.split('\r\n') method, path, protocol = headerLines[1].split(' ') headers = dict(line.split(':').map(str.strip) for line in lines[1:]) For production use you'd probably want something a bit faster & more robust like Mongrel's HTTP parser (itself only 166 lines of Ragel), which powers several million websites out there: https://github.com/mongrel/mongrel/blob/master/ext/http11/http11_parser.rl https://github.com/mongrel/mongrel/blob/master/ext/http11/ht...
icedchai 10y ago
I started programming in the same era, and feel the same way about "web apps" being a step backwards. The problem is we're building apps on top of a platform originally intended as a document viewer, with kludge upon kludge piled on...
- stillworks 10y ago
  If only we can take out HTTP and only use JSON (or something even simpler) end-to-end.

erlehmann_ 10y ago

> I doubt it would work well for a much more complex language than C (say, JavaScript, or Perl), without a lot more smarts. Perl can not be parsed, making accurate synthax highlighting impossible: http://www.perlmonks.org/?node_id=663393 http://www.perlmonks.org/?node_id=663393