1. 2

    Author here. I wrote this a couple years ago, and chose JavaScript because it’s the language I know best. And I used React as a convenient way to display and manipulate the DOM, but of course it’s not strictly necessary.

    This started after reading Masters of Doom and deciding that I could probably create a raycasting engine (like Wolfenstein 3D uses). Overall this was a fun project that stretched the limits of my math knowledge (haven’t done any trigonometry since high school). Was really satisfying when it finally started working right!

    1. 23

      There are three levels of frontend interaction complexity:

      • Up to form action=foo method=post and button type=submit. For this, HTML + CSS is the easiest solution.
      • Up to buttons with simple animations. Jquery or vanilla is the easiest solution.
      • Anything over it. React with potentially extra state management libraries is the easiest solution.

      Yes, you don’t need React for websites with minimal interactivity requirements, but as soon as you have to add just a few of those requirements, you quickly regret not having React.

      Also, things like GatsbyJS or NextJS can be configured to output static sites. This may look like totally overkill, except for a tiny detail. You get to use all the module management and import semantics from Javascript to manage your components, which is way better than plain old CSS files and copy-pasta for HTML snippets. Add in Typescript and you have a strong proposition. Though WebComponents may do something similar here…

      1. 4

        There’s a level past React too though. React can’t really do high performance things, so for those you need to turn to Canvas or something and handroll it. Tom MacWright made this point in the now classic “Rethinking the Modern Web”.

        Here’s one way to think of it:

        • Google search: can be handled as HTML, CSS, sprinkles of JS animation
        • Gmail: you’ll want some kind of JS framework to handle all the zillions of screens
        • Google maps: you don’t want a framework doing the map because it will be too slow. The map is canvas or some other smart layer that can load tiles on the fly. (Nav buttons can be whatever.)
        1. 3

          It’s extremely easy to migrate from a simple HTML + CSS site to a site with JQuery or vanilla JavaScript, because JavaScript is basically just a layer over the HTML page that’s already there. React wants to have the center stage, and most knowledge about the underlying technology is useless at best and sometimes even harmful, as React wants everything done in a very specific way.

          1. 15

            See this line of code? https://github.com/manirul41/react-mvc-app/blob/master/src/index.js#L7 It tells React to do its thing on the id=“root” element in the page. What tends to happen is https://github.com/manirul41/react-mvc-app/blob/master/src/index.html#L15 - I/E the only element in the page is that id=“root”.

            It doesn’t have to be like this. You can tell React to render on any subsection of the page, and manage the rest of the page in a different way. (This is the big secret behind all that microframeworks hipe we saw a few months ago). When you do React this way, it becomes another layer of the system. It becomes just an element with incredibly advanced functionality. And you can delete the element with node.parent.removeChild(node) and the React node goes away and the React runtime stops.

            React doesn’t want to have the center stage. People put React in the center stage.

            1. 4

              most knowledge about the underlying technology is useless at best and sometimes even harmful, as React wants everything done in a very specific way

              In my experience, this hasn’t been the case. React outputs some HTML, and you still have to know what HTML to use and how to use it.

          1. 4

            Not 100% sure if it was released in this release or not, but it looks like there’s a new 2-tone focus indicator. Love those because they show up on light and dark backgrounds. The old dotted line indicator could be hard to see.

            1. 6

              Author here. This is the 4th in a series of Conway’s Game of Life implementations I’ve done over the years. See the live demo here.

              This one uses some ideas from Michael Abrash’s Graphics Programming Black Book. Specifically:

              • Maintains a count of “on” neighbors for each cell. Updating this count is cheaper than brute-force counting them for each cell whenever computing the next generation.
              • Representing the state (on/off and the neighbor count) with bits in a byte. Not sure how much of a performance impact there is in this case. But it was interesting using bit operations like that for the first time.

              Haven’t done any of the other optimizations from the book, yet.

              1. 2

                Good callout to not fall into the trap of being too confident in your code. I haven’t thought of this before, but imagine it could be easy to forget that there may still be pockets of unsafety or logic errors present.

                1. 31

                  If the author is here and open to changing the post title, Rust is for everyone, and good for professionals too! The title as is sounds like it may be exclusionary toward people who don’t identity as professionals, or feel intimidated by Rust, which is contrary to Rust’s core goal of opening up systems programming to everyone!

                  1. 39

                    I, the author, am here.

                    I appreciate the constructive feedback and can see your point. Choosing titles is hard. I too was concerned about the exclusionary potential for the title. However, I thought I had it sufficiently mitigated by the introduction paragraphs. Apparently I could have done better.

                    I’m not going to change the title of this post because I don’t want to deal with the hassle of rewriting URLs. However, I will try to consider your feedback for future posts I author.

                    1. 6

                      I appreciated the way you took the feedback. Just wanted to say thanks for listening and considering it.

                      1. 3

                        I’ve programmed in the following languages: C, C++ (only until C++11), C#, Erlang, Go, JavaScript, Java, Lua, Perl, PHP, Python, Ruby, Rust, shell, SQL, and Verilog.

                        To me, Rust introduced a number of new concepts, like match for control flow, enums as algebraic types, the borrow checker, the Option and Result types/enums and more.

                        How did you use Erlang without pattern matching?

                        1. 2

                          I think the order is alphabetical so its possible that author used Erlang after he learned Rust.

                          Have a nice day!

                          1. 1

                            Doesn’t add up, he says that Rust introduced pattern matching to him :-)

                        2. 3

                          My usual way of framing it is “Rust is an industrial programming language”. That leaves the door open for practitioners of all kinds. It’s more like a cars are (in general) a utility and not a plaything or research endeavor, but are open to enthusiasts and amateur practitioners as well.

                          1. 2

                            Thanks! I liked the disclaimer, and think predicting how people will respond can be tough. Appreciate you putting in the time to write this, and agree that Rust can be used in professional / production environments successfully, and that it can feel like a breath of fresh air for many!

                          2. 22

                            Or, alternately, when someone writes 13,000 words about how nice Rust is, how ergonomic and human-centric and welcoming and humane the language and tooling and community are, they can keep the title without someone telling them they’re maybe being exclusionary.

                            1. 16

                              It’s constructive criticism. If you post something on the public web, it’s fair game to criticize it- especially if done in a polite manner.

                              1. 23

                                It’s criticism, but just because it’s delivered politely does not mean it is constructive. There is a cost to spending the effort to write a thirteen thousand word love letter to a language, just to have someone nipping at your ankles about how the first four words might exclude someone. Objectively speaking, this is a blogger that Rust would benefit from sticking around – but what is the signal they’ve received here?

                                1. 11

                                  Agree 💯.

                                  Recently a friend submitted his static site generator which is optimised for math heavy sites on HN.

                                  He made the fatal mistake of calling it “beautiful” in the description and the amount of hangups that people had. It was done in a mostly polite manner, but the amount of time and energy wasted in discussing just the first sentence with barely any technical discussion of the internals, was a form of pathological bikeshedding that I was surprised to see. It was just that “nipping at his ankles” as you’ve described, which can take its toll.

                                  Vowed to never take that site seriously again.

                                  1. 1

                                    It was done in a mostly polite manner, but the amount of time and energy wasted in discussing just the first sentence with barely any technical discussion of the internals, was a form of pathological bikeshedding that I was surprised to see. It was just that “nipping at his ankles” as you’ve described, which can take its toll.

                                    Agreed. Yet here we are- arguing about arguing. I need a life… xD

                                    1. 1

                                      Right, in my experience, HN often attracts uninteresting, unhelpful, or even mean-spirited commentary. Sometimes I am surprised by the opposite, though. In any case, understanding the dynamic really helps. A lot of commentary, seems to me, are upset at some level in some way and take it out in their commentary.

                                    2. 3

                                      The author thanked them and described the feedback as constructive. So if they feel like they’ve taken something away from it, who are we to decide otherwise? My own hopefully constructive feedback here is that this subthread strikes me as projecting conflict into an interaction between two parties who themselves seem to have had a positive experience with it.

                                      1. 2

                                        Yeah, I get where you’re coming from and I don’t really disagree.

                                        But I also think that the person who offered the criticism is just trying to help the author get more views.

                                        It’s fair to suggest that we all should consider our criticisms carefully, though. Because you’re right- if the criticism isn’t that important, we may just be disincentivizing someone from future contributions.

                                        I also wonder if you’re maybe reading a little too hard into the choice of the word “exclude” used by the criticizer, though… I think that term has a little bit of extra charge and connotation in today’s social environment and I don’t believe the criticizer meant it in that way. I think they simply meant that a person who isn’t writing enterprise software might pass over the article because they believe they aren’t the target audience. I agree with that conclusion as well, because I do write enterprisey software and I thought the article was going to be about that specific point of view- I thought I would see arguments about productivity and developer costs and cross-platform support and other less-sexy stuff. But, it was really- as you said, just a love letter to everything about Rust.

                                    3. 8

                                      I felt this lead-in made it a friendly suggestion and not harsh:

                                      If the author is here and open to changing the post title

                                      1. 4

                                        FWIW first third of those thousands of words is irellevant chitchat. The First actual claim on why is rust good is rust makes me giddy. I’m not sure “giddy” describes profesionals. It’s not no, but for me definitely not a yes either - giddy is just…giddy. Then all the technical points, borrow checkers, race conditions and whatnot - none of that tells me why is it a thing for professionals.

                                        What I mean is, I don’t know if rust is for pros or not, I just think that the title is a bit click-baity, and “rust is good for everyone, even pros” like alilleybrinker suggested would work much better.

                                        1. 7

                                          The First actual claim on why is rust good is rust makes me giddy. I’m not sure “giddy” describes profesionals.

                                          There’s a layer of extra irony here in that the word “amateur” comes from a root meaning “love”; in other words, amateurs are people who do something because they love it. So taken literally, this is very unprofessional!

                                      2. 18

                                        It seems relevant to note that the author does address this in the post itself:

                                        The statement Rust is for Professionals does not imply any logical variant thereof. e.g. I am not implying Rust is not for non-professionals. Rather, the subject/thesis merely defines the audience I want to speak to: people who spend a lot of time authoring, maintaining, and supporting software and are invested in its longer-term outcomes.

                                        1. 10

                                          Yes, except the title doesn’t have a disclaimer, and will be taken in the way they say they don’t want. Rather than leaving it ambiguous, they could change the title to remove the ambiguity.

                                          1. 28

                                            This side-steps the issue “people don’t read past the title” - which is the real problem. It’s bad, and unrealistic, to expect every person who writes on the internet to tailor each individual sub-part of an article (including the title) to an audience that is refusing to read the (whole) article itself before making judgements or assumptions. That’s purely the fault of the audience, not the writer, and changing the article title is merely addressing the symptoms, instead of the root problem, which will allow it to just become worse.

                                            We have an expression “judging a book by its cover” specifically for this scenario, and in addition to that, any reasonably-thoughtful reader is aware that, once a sufficient amount of context has been stripped away, any statement loses its meaning - which logically implies that full context must be absorbed before the reader has any chance of understanding the author’s intended meaning.

                                            People should not have to write hyper-defensively on the internet, or anywhere, because civil discussion collapses when your audience isn’t acting honestly.

                                            Reading the title and judging before reading the content itself is not acting honestly.

                                            1. 4

                                              Thank you for writing this. I’m sick of how much culture is warped by toxic social media sites.

                                            2. 7

                                              Agreed. It’s a poor choice for a title, even with a disclaimer. In fact, that he knew he needed a disclaimer should have been a big clue that it wasn’t a good title.

                                              A better title would be: “Professional devs should love Rust”, or “Rust isn’t just for enthusiasts and hipsters”

                                              1. 0

                                                I don’t disagree.

                                            3. 18

                                              Responses like this make me hesitant to try Rust, because they make me feel that I’d have to tiptoe around every word I put into a chat room, issue tracker, or mailing list.

                                              1. 10

                                                I’m not sure this is a Rust issue as much as a general issue of recent years. Be delicate and excessively sensitive about everything because everyone’s an egg shell. It’s contrary to anti-fragility which I would suggest is a far better approach; and the opposite approach. “Rust is for professionals” would have had me targeting Rust so that I could level up, not scare me away. Show me a challenge,

                                              2. 5

                                                I used rust for three years outside of work, but I’m afraid I stopped last year because I find it too big for a hobbyist. If I used it all day every day - no problem. It’s a great language, but I agree with the title.

                                                1. 2

                                                  This was my first thought, as well, before even reading the article. Obviously I should read before judging, but the author may want to consider that the title could turn away potential readers.

                                                  I made the same mistake in my own My staff engineering reading list. There was no reason for me to needlessly exclude people earlier in their careers from my list.

                                                  And it’s good feedback that the author of this piece may not want to unintentionally exclude people from their article.

                                                1. 1

                                                  The anecdote about the challenge of converting GOTO statements to functions and loops made me think of something I’m working on - refactoring a large amount of global Sass and CSS in an old Rails app. You can’t change one part without breaking other places, or even add new styles without countering the existing.

                                                  Maybe many problems that make large codebases hard to work with come down to (the lack of) local reasoning, whether that’s CSS styles, global data, etc.

                                                  1. 1

                                                    I think that’s exactly right, and it matches my own experience with large, old CSS codebases as well. I am grateful that there are a bunch of things landing in CSS lately and in the years ahead which will help with that, because it is a real, and difficult problem. I think it is also the fruit of very reasonable design choices: the cascade is, at least in theory, designed to enable you to do minimal work in the smallest number of places… but in practice it often ends up having the opposite effect because of how organically design tends to evolve over time in an app or site.

                                                    1. 2

                                                      Good point! The cascade means CSS is non-local by design, and probably made a lot of sense when the web was intended to be small documents with a little bit of styling.

                                                  1. 1

                                                    I never really got the understanding of why the usage of recursive functions (instead of loops). Sure, with proper tail recursion you won’t get stack overflow, but you are still pushing new stack frames for each iteration. Even if that is not so expensive, staying in the same frame is cheaper. My limited experience of using debuggers also point to keeping away from recursive functions.

                                                    1. 7

                                                      Sure, with proper tail recursion you won’t get stack overflow, but you are still pushing new stack frames for each iteration

                                                      Isn’t that the point of tail recursion, to re-use the stack frame?

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

                                                      Tail calls can be implemented without adding a new stack frame to the call stack.

                                                      As I understand it, the main downside is that in debugging you don’t see the recursion (because the frames aren’t there).

                                                      1. 5

                                                        As I understand it, the main downside is that in debugging you don’t see the recursion (because the frames aren’t there

                                                        In which case you’re in exactly the same situation as if you’d used iteration, right? If you wrote the code as recursive then you have the option to turn off the tail-call elimination temporarily if it helps your debugging.

                                                        1. 1

                                                          Yes, I think the main difficulty more comes in when you have tail calls which are not necessarily recursive (same function), A calls B calls C, all in tail position and you won’t see B on the stack if you break in C.

                                                          1. 1

                                                            In that case A, B, and C could all have been labels in the same function, and the calls gotos. That’s what the generated machine code effectively is – which is more efficient than the CPU executing call/return each time.

                                                            Yeah, it’s harder to understand in that optimised form. But with optimised tail-calls it’s possible to tell the compiler not to optimise temporarily, if you want.

                                                        2. 2

                                                          As I understand it, the main downside is that in debugging you don’t see the recursion (because the frames aren’t there).

                                                          Yet you see the arguments to the call, thus showing you exactly how to replicate your bug without any extra steps

                                                          1. 1

                                                            Yes, but see comment above about non-recursive tail calls.

                                                        3. 3

                                                          It can be a fun and interesting puzzle, not something I’d normally do (unless it fit the problem). Also, some languages (such as Erlang, I believe) don’t have loops.

                                                          1. 3

                                                            Like someone else already mentioned, there are languages without iteration constructs (Erlang/Elixir are both entirely reliant upon recursion to express iterative constructs like loops, for/foreach, do/while, etc. This is intentional in those languages because there is no support for mutation (there are some ways to work around that, but at the syntax level mutation doesn’t exist), and the runtime provides tail-call optimization, so there is no runtime cost to tail recursive calls, even mutually recursive functions.

                                                            On top of that, some algorithms are more elegantly expressed recursively, which can make reading the code much easier to understand. In Erlang/Elixir, which have rich pattern matching capabilities, the ability to break up a function into multiple clauses, each of which pattern match on the function arguments directly in the function head, mean you can neatly express the different cases of a recursive algorithm across a few clauses. For example, in Elixir the following expresses the algorithm for summing a list of integers:

                                                            def sum(list) when is_list(list), do: sum(list, 0)
                                                            
                                                            # Base case, empty list
                                                            defp sum([], acc), do: acc
                                                            # List consisting of at least one element
                                                            defp sum([n | rest], acc) when is_integer(n), do: sum(rest, acc + n)
                                                            

                                                            This is obviously a trivial case, but as you can see, each case of the recursive algorithm can be expressed in its own clause, which are pattern matched against the input in top-down order.

                                                            1. 2

                                                              There is no difference between tail-recursion and iteration wth respect to debugging. Recursion that is not tail-call optimised gives you more information for debugging than iteration.

                                                              1. 1

                                                                This sounds like premature optimization. I can’t think of a case when (even non-tail) recursion bit me wrt performance.

                                                                1. 3

                                                                  The performance of non-TCO can be fine, until it suddenly isn’t. For example, if you don’t control the input you may encounter StackOverflow errors. Last week my team tried to implement a max limit to the number of nodes a tree could have, and one of our test cases was a very, very deep tree that caused a StackOverflow in our initial (naive, non-tail-call optimised) recursive solution.

                                                                  1. 1

                                                                    Your problem is not that you used recursive code, it’s that you used a non-balanced tree.

                                                                    If you’d used iterative code with a an explicit stack to keep track of your position in the tree you’d have exactly the same problem.

                                                                    1. 1

                                                                      You wouldn’t stack overflow with an explicit stack. Heap size is much larger than the max call stack size.

                                                                      1. 1

                                                                        You actually can, fairly easily. Say your graph has a loop, and you don’t detect that. Try putting the below YAML into http://www.yamllint.com and hit “Go” for example. (Please note I’m not criticising that site in particular. My point is that failing to detect loops is an easy mistake to make: I only had to try 3 online YAML parsers before I found one that doesn’t.)

                                                                        a: &a [*a]
                                                                        

                                                                        I don’t know if that site uses a recursive or non-recursive solution, but I’d put good money on some kind of stack overflow happening with that input. And no amount of heap space will help your code avoid a stack overflow (eventually!) if you use the stack to track visited nodes in an infinitely deep tree.

                                                                        (Edit: extract YAML to its own code block for clarity)

                                                                      2. 1

                                                                        I think you missed the point of my comment: I was trying to give a concrete example of where a TCO recursion would be preferable (performance wise) vs a non-TCO one. You should have used a balanced tree isn’t always an option; especially when the input is user-defined, as I already mentioned it was. As it happens we didn’t really need a stack, as we were only counting nodes to verify the tree didn’t have more nodes than we wanted to allow. And as we’re using lisp, a recursive solution would be the most idiomatic.

                                                                        1. 2

                                                                          You can’t TCO a tree walk – at least not both subtrees.

                                                                          If you know in advance which subtree is bigger then you can recurse on the smaller one and then TCO on the bigger one, and this limits max stack depth to less than log2(N). But you often don’t know that in advance.

                                                                          1. 1

                                                                            You can’t TCO a tree walk – at least not both subtrees.

                                                                            Ah, dang. Thanks for pointing this out.

                                                                1. 2

                                                                  Ok. With the risk of sounding stupid, What is a staff engineer?

                                                                  1. 1

                                                                    That’s not a stupid question, and I should’ve just titled this “my software engineering reading list”.

                                                                    Staff engineer is a level in many engineering career ladders, above senior engineer. I titled the reading list with “staff engineer” because I tended to read a different set of books than these earlier in my career, but now these seem to be the most impactful.

                                                                    But others in this thread rightfully pointed out that these books are useful for all experience levels.

                                                                    I would rename the post, but then that would change the url to the article 🤔

                                                                  1. 5

                                                                    SICP brings wonders. The rest I don’t know.

                                                                    SICP: https://github.com/sarabander/sicp

                                                                    1. 6

                                                                      SICP is vastly overrated.

                                                                      1. 6

                                                                        Ok, I’ll bite. Why do you say that?

                                                                        1. 1

                                                                          I understand it doesn’t resonate with everybody, which is why I included it in the section of books good for specific interests.

                                                                      1. 1

                                                                        I can really recommend „The Pyramid Principle“. It will change the way you structure your thoughts (and write better e-mails, if you are into that)

                                                                        1. 1

                                                                          Without a doubt! I’ve been using it a lot for proposals and presentations, as well.

                                                                        1. 2

                                                                          My take away is that you don’t need to read any book in particular to reach the ‘staff’ level. There’s nothing on this list that isn’t accessible to a junior with a year of experience.

                                                                          1. 2

                                                                            Definitely. Guess what I meant (and poorly explained) was that many people don’t think a lot about non-technical aspects of engineering until they get to senior levels. Or at least I didn’t 😬.

                                                                            Will update the article to reflect that. Thanks for the feedback!

                                                                            1. 1

                                                                              You’re welcome! I might pick up “The Pyramid Principle” based on this and JulianWgs’ comment

                                                                          1. 1

                                                                            Thanks for putting this together! We went over Structure and Interpretation of Computer Programs in my programming languages course, but I’ll definitely add some of these others to my list of “eventually” books.

                                                                            Also wanted to note that the ISBN for the first book is off. It looks like it may have been copied from the second in the list.

                                                                            1. 1

                                                                              Thanks for catching the ISBN error! Fixed.

                                                                            1. 4

                                                                              C’mon, these are great books even for the entry level grunt.

                                                                              And I struggle with “An Elegant Puzzle,” it is not a book I would recommend.

                                                                              1. 1

                                                                                That’s fair. Wasn’t sure if the “staff engineering” label made sense, but I went with it because

                                                                                • These books generally aren’t about actually coding
                                                                                • When I was getting started, the most useful books I found were the specifics of writing code (for Rails, HTML, CSS, etc)

                                                                                But agreed that these are probably great choices for anybody. Updated some wording in the article to account for this.

                                                                              1. 4

                                                                                React really is an encoding of incremental computation into JS, and useRef is its implementation of mutation. Maybe it’d be easier to explain React by comparing it to a spreadsheet, where the results are recomputed only when its dependencies change.

                                                                                1. 1

                                                                                  That’s fair. And refs are a way of controlling when certain values are viewed as “changed” or not.

                                                                                1. 7

                                                                                  I share some of the author’s skepticism about React’s Concurrent Mode.

                                                                                  I have personally shipped schedulers for complex, interactive JavaScript apps. I think it’s a useful technique, but it’s going to be extremely difficult to build something that doesn’t have easily accessible terrifying edge cases.

                                                                                  I think a relevant piece of precedent is the introduction of Hooks to React. Hooks are a completely unsound abstraction that will break if the order of your hook calls change. To mitigate this, the React team recommends using a lint rule that prevents hook calls in asynchronous code or closures, among other places.

                                                                                  However, this lint rule itself still has edgecases, most notably around module boundaries.

                                                                                  In the past, it seems like the React team’s desire to ship shiny new features has outweighed their desire to produce sound abstractions. It wouldn’t surprise me if Concurrent Mode is released alongside a bizarre hack that enables it to function at all, like a babel transform that restructures your render functions into smaller units to enable interruption.

                                                                                  In any case, I wish them all the best. Maybe they have some tricks up their sleeves, like authoring the hard parts in a language with a more useful type system.

                                                                                  1. 3

                                                                                    Hooks are a completely unsound abstraction that will break if the order of your hook calls change.

                                                                                    this!!! I was so confused when hooks were announced. I suppose a pro of hooks is that it consildated the API for bad decisions™ compared to the plethora of state management libraries. but then we just ended up with more plethora on top of hooks!!!

                                                                                    1. 3

                                                                                      I don’t know. Hooks have nuances, but so do class-based components. And I imagine any UI framework does.

                                                                                  1. 1

                                                                                    URL for this has changed to https://ahuth.github.io/articles/what-are-unit-tests-for.html

                                                                                    Sorry about that!

                                                                                    1. 11

                                                                                      I agree: the biggest advantage from my experience is that unit testing gives you much more confidence in refactoring the code, that is, changing the underlying implementation while maintaining the relevant characteristics constant.

                                                                                      Furthermore, making code amenable to unit testing often simplifies it and improves its design.

                                                                                      I can also see the appeal of well-crafted tests as documentation on the usage of the module, but my tests haven’t really attained that proud to have my name attached to it status — usually they’re a grab bag of boilerplate and ad-hoc, totally contrived, examples.

                                                                                      What I can’t get behind is test-driven development. I’ll echo John Ousterhout (whose book “A Philosophy of Software Design” OP might find interesting, if they haven’t already read it):

                                                                                      Although I am a strong advocate of unit testing, I am not a fan of test-driven development. The problem with test-driven development is that it focuses attention on getting specific features working, rather than the best design.

                                                                                      1. 3

                                                                                        Thanks for the book recommendation, and I’ve indeed read it. It’s really good, although I forgot that it had that take on test-driven development.

                                                                                        If you haven’t seen https://8thlight.com/blog/thomas-countz/2019/02/19/essential-and-relevant-unit-tests.html, it shaped my thoughts around writing tests that I’m proud of.

                                                                                        1. 1

                                                                                          Yeah, in the chapter devoted to Software trends he goes underrated/overrated on a bunch of things, which I love. Thank you for the link!

                                                                                        2. 2

                                                                                          That reminds me of Ron Jefferies’ attempt to solve sudoku:

                                                                                          The punchline? It’s not satire.

                                                                                        1. 1

                                                                                          This is a nice solution given how hard this problem can be. Does it actually work for things like SR NOR latches?

                                                                                          1. 2

                                                                                            Great question. Even though supporting stuff like that is what I set out to do, I’d actually never tested it. :/

                                                                                            Just now I tried creating an R-S (reset-set) flip flop, since that’s what the book I was working from when the idea came to me implements (Code, by Charles Petzold).

                                                                                            And it works! Sort of.

                                                                                            I think the right things are happening, but there are 2 things making it hard to work with.

                                                                                            1. Because the event emitters feedback on themselves, there’s an infinite amount of output. Adding more delay helps make it manageable, and only outputing values that are changes is probably a good idea.

                                                                                            2. When a gate feeds a single input into multiple internal gates, changes to the input causes the overall gate to “fire” multiple times. The answer is “right”, but it’s annoying seeing multiple values being emitted for a single input event.

                                                                                            1. 1

                                                                                              Fixed #2 by debouncing the emitting of events/signals for both AND and OR gates.

                                                                                              Also, it’s not a flip flop or latches, but I have now implemented an Oscillator, which isn’t possible with simple pure function implementations.

                                                                                          1. 1

                                                                                            I wonder how these functions compare to combinations of javascript logic operands like && and ||

                                                                                            1. 1

                                                                                              Those would work, as well! I was trying to get closer to the actual hardware implementation of logic gates, but they’re equivalent.