4 ms·

This isn't just a problem with Web standards. Think of how few complete implementations of C, C++, Python, Java there are. So yeah the web is complex but so ar

• corndoge 9y ago
  The difference is that the web was originally designed to show documents, not build applications. The failings of the web are entirely a result of turning the browser into a VM for Javascript applivations.
  • bobajeff 9y ago
    I like the idea of having the web just being a static document format with hyperlinks and embeddable objects. No DOM just a tag for some narrowly defined supported formats (eg. .form, .game, .social, .store)
• mattgreenrocks 9y ago
  Size is not a requirement of a programming language: look at Lisp, Smalltalk, Lua, etc to see simple systems that can be fully comprehended and are quite powerful. If anything, the monstrosities produced by committees are less powerful and less beautiful. (That we put up with them says more about us.)
  • wbl 9y ago
    Have you seen the Common Lisp specification?
    • erikj 9y ago
      Common Lisp is big because it's a bridge between MacLisp and InterLisp communities of the 80s. There are much smaller (and just as powerful) Lisps like Scheme or ISLISP.
      • kazinator 9y ago
        Scheme is poorly expressive for daily programming and it's because of its small size. The documentation quantity for a useful Scheme like Racket is much larger. Also, do we count all the pages expended on SRFI's? Or not?
    • flavio81 9y ago
      >Have you seen the Common Lisp specification? Yes, it is huge and gigantic, but worth it's weight in gold. The stuff "just works" and has almost no limits. I'd say that spec is a masterpiece.
• userbinator 9y ago
  Think of how few complete implementations of C, C++, Python, Java there are. C++ is at least an order of magnitude more complex, but there have been plenty of C implementations, some even entirely the work of a single person[1]. "I wrote my own C (subset) compiler" seems to be a reasonably common thing on HN too.[2][3][4][5][6][7] On the other hand, I haven't see very many "truly independent" webpage rendering engine implementations (e.g. HTML4 or HTML5-subset, CSS2.x), so if anyone wants to give it a go (or Go, if you like...), they are more than welcome to, if only to increase the diversity of available implementations --- something that could probably handle HTML4/CSS2 might not be all that difficult, and especially so if you don't care for 100% identical results to the mainstream browsers (which often differ slightly too.) [1] https://en.wikipedia.org/wiki/Tiny_C_Compiler https://en.wikipedia.org/wiki/Tiny_C_Compiler [2] https://news.ycombinator.com/item?id=13914137 https://news.ycombinator.com/item?id=13914137 [3] https://news.ycombinator.com/item?id=15463738 https://news.ycombinator.com/item?id=15463738 [4] https://news.ycombinator.com/item?id=13778353 https://news.ycombinator.com/item?id=13778353 [5] https://news.ycombinator.com/item?id=8558822 https://news.ycombinator.com/item?id=8558822 [6] https://news.ycombinator.com/item?id=11903674 https://news.ycombinator.com/item?id=11903674 [7] https://news.ycombinator.com/item?id=9125912 https://news.ycombinator.com/item?id=9125912
  • pcwalton 9y ago
    > something that could probably handle HTML4/CSS2 might not be all that difficult As someone who did a lot of the work to implement a from-scratch HTML4/CSS2 engine, I struggle to come up with words that would adequately express to you just how much you are underestimating the difficulty of this.