Threads for sunshine

  1. 1

    I’m going to try to write a markdown parser in my toy language and then use it to generate a static website with a mini tutorial + some examples showing off the language itself. I briefly considered porting Marked from JS but it doesn’t map quite as cleanly to my language as I thought it might and besides, it’ll probably be more fun and educational to write one from scratch.

    1. 8

      Nothing wrong with cat a b | c. Piping cat’s output into another process is only an “anti-pattern” if you invoke it with a single argument.

      1. 7

        I have modified the README to clarify this is meant to make fun of not liking cat-into-pipe.

        1. 4

          Should be tagged satire in that case.

          1. 2


      1. 3

        One of my resolutions for 2022 is to read more, and I bought a few books to get started. This weekend I’m hoping to get through Desert Solitaire.

        1. 1

          It was an audacious goal, especially for a language released in 1995.

          Is it just the baggage that’s implied? Or that newer things are necessarily better/faster?

          1. 25

            Maybe the implication is that the language has already been incrementally improving for 25 years, so a 3x speed-up at this point in its development would be quite remarkable.

            1. 4

              The last time I looked at Ruby, it was significantly slower than Squeak, which at the time was a fairly faithful reimplementation of a Blue Book Smalltalk-80 bytecode interpreter and what I’d consider to be minimal baseline performance for a new dynamic language implementation that learned anything from prior work. I believe Squeak has since added JITs and other more modern features but at the time it was focused aggressively on being easy to understand and hack on at the expense of performance. Being slower than Smalltalk when your language is Smalltalk minus several of the bits of Smalltalk that are hardest to implement efficiently was pretty depressing.

              There was definitely a lot of room for improvement.

              1. 3

                I think it’s worth pointing out that Ruby is a much larger language with a huge core library. Surface area matters a lot when it comes to optimizing language performance. A typical Ruby application will touch a lot of language features, so if any part is left unoptimized, that loss may easily dwarf the gains made in other areas. You have to optimize the whole enchilada, and that can be cost-prohibitive for teams without deep pockets.

                I can’t find the links now, but I recall one of the people on PyPy saying Python is harder to optimize than JS just because Python’s core lib surface area is so large. Mike Pall said something similar about why LuaJIT was feasible as a mainly single-person project: the language and libs are tiny.

            2. 1

              Maybe they are saying older things are faster because they were designed for slower computers, making it hard improve on performance?