1. 2

    Where the hell do you keep an IBM mainframe? His power bill must be astronomical. I guess if you can afford to buy a 23k computer just for fun you can afford to house and power it

    1. 7

      My estimate is that the continuous consumption will be 1.7 kW

      Author appears to be in Zürich, 0.163 CHF/kWh. About 120CHF per month. ($120USD, €107)

      1.  

        Author has specific numbers here. The host uses “99.9%* hydropower from the Alps.” So, the owner appears to be going out of their way to both cover the energy costs and reduce environmental damage.

        1.  

          It looks like they paid to have it located in a datacenter.

        1. 3

          At Datadog we do something similar to this, but with golang. We use go-python to talk with Python with CGo. It’s pretty cool! We run on so many machines, this is a battle tested approach.

          1. 2

            Don’t all VCSs have tools to modify history? I think svnadmin does: http://oliverguenther.de/2016/01/rewriting-subversion-history/ (assuming there aren’t any blockchain-based VCSs. I daren’t look)

            If the distinction being drawn is ‘admin’ vs ‘user’ tooling, I guess - like workflow - git punts that to the surrounding culture and environment (as it does “which version is the ‘master’” - which is the same feature/bug of any DVCS).

            I admit I like being able to say “v234” but really, what that means is “v234 of the (single) upstream repo which can change any time the upstream repo manager runs svnadmin”.

            There’s nothing to stop github putting a sequential “v1, v2, v3, …” on commits to master or otherwise blessing some workflow.

            I think the differences aren’t so much about features + capability and tooling as culture.

            1. 2

              git is a merkle-tree-based system, which is what I assume you meant by “blockchain-based” in this context

              1. 1

                Yes it is, but no - that’s not what I meant. I mean that I expect every VCS to be able to rewrite history since the data files are under control of the admin. git can do it, svn can do it. You can edit RCS files by hand if you want to (unsure if there is tooling to do it).

                i.e. linus can rewrite his git history. It will be out of sync with other people, but that is then a social issue, not a technical one (I admit this is a fine point).

                The only time you can’t rewrite history is in the “public immutable” world of blockchain - since the data files aren’t under your control. I don’t know if someone has built a vcs like that and my comment was really just a side swipe at blockchain hype.

                1. 1

                  you can if you get 51%

                  1. 1

                    https://github.com/clehner/git-ssb not exactly blockchain, but immutable history just the same.

              1. 1

                Interesting architecture, but not impressed by the 25M API calls per month.

                1. 2

                  It’s always confused me when “queries per month” is used as a headline. That’s an indicator of the user base, not the technical infrastructure. On average it’s about 10 qps, which for this feature requires possibly a large Arduino. :) BTW, no idea why a web site owner would accept a paid dependency just to do a btree lookup “as a service”.

                  1. 1

                    Because they’re solving hard problems that will change the world through ip geolocation as a service.

                1. 5

                  The post in question Big-O: how code slows as data grows

                  The comment by ‘pyon’:

                  You should be ashamed of this post. How dare you mislead your readers? In amortized analysis, earlier cheap operations pay the cost of later expensive ones. By the time you need to perform an expensive operation, you will have performed enough cheap ones, so that the cost of the entire sequence of operations is bounded above by the sum of their amortized costs. To fix your list example: a sequence of cheap list inserts pays the cost of the expensive one that comes next.

                  If you discard the emotion, he gives out a fairly interesting additional note about what amortized analysis means. Instead of giving the information value, Ned reacts on the part that questions his authority. Such a brittle ego that puts you to writing a small novel worth’s of rhetoric instead of shrugging it off. Childish.

                  1. 52

                    If @pyon had just phrased the first part of the comment like “You’re making a number of simpliications regarding “amortization” here that I believe are important…” this would probably not have escalated. This is what Ned means with being toxic - being correct, and being a douche about it.

                    1. 10

                      Indeed; the original article appeared on Lobsters and featured a thoughtful discussion on amortization.

                      1. 2

                        I wonder whether better word choice without changing the meaning would help one step earlier: the original post did include «you may see the word “amortized” thrown around. That’s a fancy word for “average”», which sounds a bit dismissive towards the actual theory. Something like «Notions of ‘‘amortized’’ and ‘‘average’’ complexity are close enough for most applications» would sound much more friendly.

                        (And then the follow-up paints the previous post as if it was a decision to omit a detail, instead of a minor incorrectness in the text as written, which can be (maybe unconsciously) used to paint the situation as «correctness versus politeness», and then options get represented as if they were mutually exclusive)

                        1. 4

                          I feel like that would have put the author in a more defensible position on this specific point, yes. Being clear about where additional nuance exists and where it doesn’t is something that anyone writing about technical subjects should strive for, simply because it’s useful to the reader.

                          I don’t think it’s likely that that clarification would have much of an effect on most readers, since the hypothetical reader who’s mislead would have to study complexity theory for some years to get to the point where it’s relevant, and by that time they’ll probably have figured it out some other way. We should all be so lucky as to write things that need several years of study before their imperfections become clear. :)

                          But more to the point, while I can’t know anything about this specific commenter’s intent, somebody who’s determined to find fault can always do so. Nobody is perfect, and any piece of writing can be nit-picked.

                          1. 1

                            Several years sounds like an upper bound for an eventually succesful attempt. A couple months can be enough to reach the point in a good algorithms textbook where this difference becomes relevant and clear (and I do not mean that someone would do nothing but read the textbook).

                            I would hope that the best-case effect on the readers could be a strong hint that there is something to go find in a textbook. If someone has just found out that big-O notation exists and liked how it allows to explain the practical difference between some algorithms, it is exactly the time to tell them «there is much more of this topic to learn».

                            These two posts together theoretically could — as a background to the things actually discussed in them — create an opposite impression, but hopefully it is just my view as a person who already knows the actual details and no newbie will actually get the feeling that the details of the theory are useless and not interesting.

                            As for finding something to nitpick — my question was whether the tone of the original paragraph could have made it not «finding» but «noticing the obvious». And whether the tone may have changed — but probably nobody will ever know, even the participants of the exchange — the desire to put a «well, actually…» comment into the desire to complain.

                            1. 3

                              Not having previous familiarity with this subject matter, I was guessing at how advanced the material was. :)

                              I agree about your best case, and that it’s worth trying for whenever we write.

                              I’ve never found anything that avoids the occasional “well, actually”, and not for want of trying. This is not an invitation to tell me how to; I think it’s best for everyone if we leave the topic there. :)

                              1. 1

                                I consider a polite «well, actually» a positive outcome… (Anything starting with a personal attack is not that, of course)

                      2. 25

                        It’s possible to share a fairly interesting additional note without also yelling at people. Regardless of what Pyon had to say, he was saying it in a very toxic manner. That’s also childish.

                        1. 5

                          Correct. But I don’t just care about the emotion. I care about the message.

                          Instead of trying to change web into a safe haven of some kind, why not admire it in its colors? Colors of mud and excrete among the colors of flowers and warmth, madness and clarity. You have very little power over having people get angry or aggressive about petty things. Though you can change a lot yourself and not take up about everything that’s said. Teaching your community this skill is also a pretty valuable in life overall.

                          1. 32

                            I don’t want my community to be defined by anger and aggression. I want beginners to feel like they can openly ask questions without being raged or laughed at. I want people to be able to share their knowledge without being told they don’t deserve to program. I want things to be better than they currently are.

                            Maintaining a welcoming, respectful community is hard work and depends on every member being committed to it. Part of that hard work is calling out toxic behavior.

                            1. 5

                              I want beginners to feel like they can openly ask questions without being raged or laughed at.

                              While I agree this is critically important, it’s not entirely fair to conflate “beginners asking questions” and “people writing authoritative blog posts”.

                            2. 10

                              Yeah. That kind of self-regulation and dedication to finding signal in noise are endlessly rewarding traits worth practicing. And to extend your metaphor, we weed the garden because otherwise they’ll choke out some of the flowers.

                              1. 5

                                But I don’t just care about the emotion. I care about the message.

                                I’m with you unless the message includes clear harm. I’ll try to resist its affect on me but advocate such messages are gone. That commenter was being an asshole on top of delivering some useful information. Discouraging the personal attacks increases number of people who will want to participate and share information. As Ned notes, such comment sections or forums also get more beginner friendly. I’m always fine with a general rule for civility in comments for such proven benefits.

                                Edit: While this is about a toxic @pyon comment, I think I should also illustrate one like I’m advocating for that delivers great information without any attacks. pyon has delivered quite a lot of them in discussions on programming language theory. Here’s one on hypergraphs:

                                https://lobste.rs/s/cfugqa/modelling_data_with_hypergraphs#c_bovmhr

                                1. 5

                                  I personally always care about the emotion (as an individual, not as a site moderator), it’s an important component of any communication between humans. But I understand your perspective as well.

                                  1. 3

                                    I may have been unclear. I do too. I was just looking at it from other commenters’ perspective of how Id think if I didnt care about it but wanted good info and opportunities in programming sphere. Id still have to reduce harm/toxicity to other people by ground rules to foster good discussion and bring more people in.

                                    So, whether emotional or not, still cant discount the emotional effect of comments on others. Still should put some thought into that with reducing personal attacks being among easiest compromise as they add nothing to discussions.

                                    1. 2

                                      Ah! Okay. I misunderstood then, and it sounds like we’re in agreement.

                                2. 4

                                  It’s ridiculous to say that if someone cannot ignore personal attacks, they have a brittle ego and are childish. While also defending personal attacks and vitriol as being the thing that we should celebrate about the internet. Rather, we should critique people for being assholes. The comment was critiquing the manner and tone in which he explained amortized analysis, but he’s not allowed to say that the comment’s manner and tone was bad? It’s ridiculous. The comment was bad, not because of the point it made, but because it made the point badly.

                              2. 22

                                Compare this approach:

                                I believe this post simplifies the idea incorrectly. In amortized analysis, earlier (cheap) operations pay the cost of later (expensive) ones. When you need to perform an expensive operation, you will have performed enough cheap ones that the cost of the entire sequence of operations is bounded by the sum of their amortized costs. In the context of your list example, a sequence of cheap list inserts would pay the cost of the expensive one that comes next.

                                This is the same content, free of “shame” and accusations of “misleading.” The original comment is a perfect example of the terrible tone that people take, as discussed in this post and in my previous post of Simon Peyton-Jones’ email.

                                1. 4

                                  Instead of giving the information value, Ned reacts on the part that questions his authority.

                                  The author does give it value. You’ve missed the point. The author isn’t saying it’s incorrect or not valuable; he’s saying that this attitude from experts (who use their expertise as a tool to put others down) is highly toxic.

                                  1. 4

                                    If you discard the emotion, he gives out a fairly interesting additional note about what amortized analysis means. Instead of giving the information value, Ned reacts on the part that questions his authority.

                                    It’s not clear that Ned interprets pyon as questioning his authority. His criticism is of pyon‘s tone, which is histrionic. The cutting intro isn’t bad if we discard it; but what is the effect if we include it? It would be more balanced for Ned to discuss the details and value of pyon’s post, but that does not invalidate Ned’s point.

                                  1. 13

                                    As an aside, I never get why writing documentation is considered a good job for a junior. It took me probably about 15 years to become good at it, and I still feel I have much room for improvement. Good documentation requires not only understanding things to the deep level but also enough empathy to put yourself in your reader’s shoes and explain in a way so they understand it.

                                    1. 2

                                      I really cloudn’t agree more. This is such a hard job.

                                    1. 6

                                      They sometimes are, and sometimes aren’t. It really strongly depends on the logic of the application in question. I don’t think this is a very well formulated argument, it’s just saying that you should have smaller functions. It could be true, but sometimes you cannot disentangle the logic of a function like that. For example if you have a dry_run flag, you’re saying run the function but do not actually make the request (or do whatever the function does). It would only be possible to make it into two functions if you duplicate the logic, something that would not be DRY at all.

                                      1. 6

                                        The author says it’s a code smell, not a code travesty. And in the example they provided, the code change was certainly a readability win. I often think about how I can clean up functions that have flag-guarded blocks interleaved together. Those get hairy fast.

                                        1. 1

                                          Yea, it definitely can be, and I’ve definitely written functions which do this badly and had to clean them up before–or had to clean up someone else’s before. But I think the article is making a point that’s not necessarily universalizable. In many cases, as a comment on the article says, you’d just be moving the conditional somewhere else.

                                          I think the general Ruby obsession with functions that are very small is a bit silly. While I do prefer smaller functions, it’s not always a reasonable choice and can easily create unnecessary complication and indirection in applications.

                                        2. 2

                                          It would only be possible to make it into two functions if you duplicate the logic, something that would not be DRY at all.

                                          Disagree. What’s the simplest way to achieve a dry run capability? I’d say split the code into:

                                          someAction(bool dryRun) {
                                            var state = prepare();
                                            if (!dryRun) {
                                              run(state);
                                            } else {
                                               dryrun(state);
                                            }
                                          }
                                          

                                          Don’t you find the following simpler:

                                          someAction() {
                                            var state = prepare();
                                            run(state);
                                          }
                                          
                                          someDryRun() {
                                            var state = prepare();
                                            dryRun(state);
                                          }
                                          

                                          Often the dry-run part is often as simple as return state, and the someDryRun method actually is the prepare method simplifying even further.

                                          1. 2

                                            You’re omitting the important part where dry run and run are basically the same, but ok

                                            1. 2

                                              You can use Free Monads to express this and then one would run it in different contexts.

                                              Another thing I often do is for anything with side effects toss that under an interface so the flow is always the same but it offloads side-effectful work to a value it gets as input. Then you can have the dry-run version of the interface and the real-version of the interface.

                                              1. 2

                                                So, how do I do this in C++ or Java or JS?

                                                EDIT: Talking about the free monads thing, not the interface thing.

                                                1. 1

                                                  You can get pretty close with something like https://en.wikipedia.org/wiki/Interpreter_pattern

                                                2. 1

                                                  That actually sounds kinda neat, I suppose that you could do something simple in C# like

                                                  private void visitDeletableItems(List<Item> items, Action<Item> action)
                                                  {
                                                    foreach (var item in items) // matching criteria or whatever
                                                    {
                                                      action(item)
                                                    }
                                                  }
                                                  public void deleteDryRun(List<item> items) { visitDeletableItems(items, item => {}); }
                                                  public void delete(List<Item> items) { visitDeletableItems(items, item => { delete(item); }); }
                                                  private void delete(Item item) { ... }
                                                  
                                          1. 1

                                            This model isn’t scalable. Even a moderate size tech startup has hundreds of thousands of lines of code. The startup I work at has ~400 people and probably 2m LOC. This model would be impossible to do for almost any moderately sized technology shop.

                                            It made sense when your average codebase was measured in thousands, or even maybe tens of thousands. But once gets above that, it’s impossible for any given person to understand the whole system, much less maintain it along with just a small handful of other people.

                                            1. 2

                                              Plenty of hospitals have more than 400 employees.

                                              Presumably within that group there are (many) teams of 5-20 people working on neatly separated parts of the problem, no?

                                              1. 1

                                                I think the idea was developed for teams who build OS’s, though, so that suggests it’s supposed to be scalable in practice.