Threads for ahuth
-
I just see a single sentence? Is this intended? sigint is talking about Twitter? What? I’m confused.
-
-
This idea of the “Twitter feed but via RSS on it’s own site” is an interesting one. Do you find yourself missing being on the platform itself?
-
Just a random thought I put on my crappy blog.
At work I come across the idea a lot that we’d be “accessible” or “WCAG compliant” if we fix the backlog of accessibility bugs. But I don’t think that’s right.
Sometimes I write stuff to work through my own thought process. And occasionally submit these thoughts to this site.
-
-
-
I know this is off topic a little, but I always hated the term ‘Social Distance’. It is simply incorrect. What it refers to is physical distance. Social distance is when you stop answering your phone and emails and just ghost everyone. That behaviour is to be avoided during a pandemic not encouraged. Not a criticism of the article though, the common usage is clear.
-
-
This is basically what I want out of Firefox:
- No telemetry
- Runs the extensions I want (1password and uBlock origin)
- Option to pay directly for it
Not sure if it is or isn’t a loss to move away from Gecko. Anyone have thoughts on that?
-
Until or unless another option appears, Gecko is the last existing independent web engine that you can use for day-to-day. Supporting Gecko is the most important thing anyone can do for the web right now, IMO.
-
Unfortunately, the reality is that Mozilla’s main competitor is paying for its development (90% of Mozilla revenue comes from Google). So it would be inadequate to classify Firefox/Gecko as “independent” because it obviously operates in a conflict of interest scenario (where user != customer).
Once Mozilla Firefox makes a switch to a fully user-centric business model (meaning being directly supported by its users, and thus user=customer) we can really call it independent.
If you do not accept this as an argument, then it would be only fair to also call WebKit independent too, because like Gecko it is open-source, and like Gecko its development is primarily sponsored by funding from a big tech company (in this case Apple and to some extent Sony).
I hope that while the dust settles you can give an alternative browser like Orion, with a truly independent business model, a chance!
-
-
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!
-
There are three levels of frontend interaction complexity:
- Up to
form action=foo method=postandbutton 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…
-
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.)
-
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.
-
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.
-
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.
-
- Up to
-
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.
-
ahuth
edited
1 year ago
|
link
| on:
Conway's game of life in TypeScript, with optimizations from Graphics Programming Black Book
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.
-
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.
-
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!
-
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.
-
-
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?
-
-
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.
-
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!
-
-
-
-
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?
-
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.
-
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
-
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.
-
-
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.
-
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.
-
-
-
-
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.
-
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!
-
-
-
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.
-
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.
-
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.
-
Thank you for writing this. I’m sick of how much culture is warped by toxic social media sites.
-
-
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”
-
-
-
-
-
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,
-
-
-
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.
-
-
ahuth
1 year ago
|
link
| on:
Keep It Local, or: (part of) what “reasoning about your code” really means
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.
-
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.
-
-
-
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.
-
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).
-
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.
-
-
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.
-
-
-
-
-
-
-
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.
-
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.
-
-
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.
-
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.
-
You wouldn’t stack overflow with an explicit stack. Heap size is much larger than the max call stack size.
-
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)
-
-
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.
-
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.
-
-
-
-
-
-
-
Ok. With the risk of sounding stupid, What is a staff engineer?
-
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 🤔
-
-
SICP brings wonders. The rest I don’t know.
-
SICP is vastly overrated.
-
-
-
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)
-
-
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.
-
-
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.
-
-
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.
-
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.
-
-
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.
-
Being transcendental is just another word for being Thoreau.
Well played
I can’t take credit for it, it’s from dialog in Fallout 4…
Nice 😂