1. 5

    +1 to the idea that it was hard to read because of the personal animosity to a single individual and their specific claims. I’m no stranger to passion, but it can get hard to find the meat of things when every statement is prefaced with bile.

    My understanding has always been that most of the mining is happening from underutilized, already-built hydro plants in China. However, even if it’s 60% (or 75%, or 80%; it kind of jumps around) of mining happening via renewable sources, we still have to account for the rest. 40% (or 25%, or 20%) of an increasing energy cost per transaction is still something to monitor! Each of those numbers that say something like “every transaction costs more energy than [some city]” may be way off-base, but even if it were “every transaction costs 20% of [some city]” I still think it’s worth putting attention towards.

    1. 3

      This is increasingly not the case - as those plants are hooked to the national grid, the People’s Bank of China - which really doesn’t like crypto, they thnk it’s useless speculation that risks damaging the productive economiy - has been pushing miners out.

    1. 25

      I liked a Bob Martin talk once, and in retrospect, I realize the key thing I took away from it was a Ward Cunningham citation 😛

      I find his politics repugnant, I don’t find his technical insights great either. This is a good explanation of a class of shortsightedness he preaches. I feel that he conflates whether something feels good or bad to him with objective properties of correctness and righteousness. I feel like he did this in tech without much alarm, but we’re noticing the habit when we see him apply it to politics.

      On his politics, I speculate he values order, civility, and structure in his worldview, and has a model that people are generally well-intentioned and competent. In this framework, the real villains are the people who threaten his mental model of this. The people who compare living ICE Agents (who look like him, maintain order) to Nazis in the 1940s (at this point an abstract concept to him and very clearly Evil) are making a false equivalence. He hears about policies and likely Shirley Exceptions them in his mind as being designed and executed by reasonable people, so the folks complaining must be exaggerating, and because it bothers him to consider that maybe they’re right (because what a horrible world that would be!) he’s angry at them for making him even consider it.

      In a similar way, he devalues any tools or methodologies that are outside his immediate strike zone, but doesn’t recognize it as “outside my strike zone” but as “not useful to software.” Unit tests? I use them and like them, so they’re Good Code! Static types? I don’t like them, so they’re Actually Bad, because you can write tests! Formal verification? I don’t use it, so it’s Academic Wankery. And so on.

      My relationship to clean code is that I enjoy designing it, like tending a garden, but I can’t prove that it’s helped me write software more effectively beyond that endorphin rush I get when I pat myself on the back. In practice, every codebase that served customer needs I’ve ever touched has had a lot of mess, and I became a lot happier when I embraced that it was probably just part of the game. tef articulates some thoughts I like and experiences I share ,and Sandi Metz talks about duplication in the same way I currently think of Clean Code: not Bad, but probably not worth optimizing for.

      (and frankly, I can’t get inside the mind of a person who looks at a diagram like this and feels anything positive)

      Anyway, I hope he gets of Twitter for a bit; meltdowns can be a nightmare.

      1. 3

        I think that diagram is pretty neat even if it is overkill for some things. What don’t you like?

        TBH, I found my way to these architectural sensibilities after a lot of makework, err, Rails major version upgrades. I realized there are probably lots of devs who really don’t mind. Personally I hate the idea of delegating my architecture to DHH because The Community prefers fungible devs to higher skill ceilings.

        1. 3

          “QuickCheck is older than JUnit. TLA+ is almost a decade older than popular TDD. MDE is almost a decade older than TLA+. Z-specification is older than C++ and Smalltalk-80. If anything, unit testing is the “new and shiny” thing! “

          I like that part. I overlooked it the first time I read it.

          1. 1

            Yeah Uncle Bob definitely likes kicking the hornets nest. I think his TLD views are a bit dogmatic and I don’t really like that he’s fully unwilling to even consider the merits of static typing. I also find it a bit silly that he’s unwilling to even weight that someone can refer to the Nazis not to indicate that someone is “cartoonishly evil” but rather actually relating to actual Nazi policies of Nationalism and populism.

            We like to think that Nazi policies are universally hated but the reality is they aren’t, and to the right public they can be quite enticing. Your wages can double over night, and you won’t have to deal with pesky outsiders. People will simply follow the rules and if they don’t they go away. All you have to do is not worry about those who aren’t there tomorrow.

            People are genuinely afraid of real Nazi ideals taking hold, not just “the other guys”. I have yet to talk to any actual republicans support the separation of families. It stands to reason then to at least have some mild fear that power seeking radicals might be attempting to co-opt American ideals for the sake of a power grab through the vehicle of nationalism, populism, and racial tension. Maybe that fear is just a fear, but it’s not just a way to paint the other team as bad guys.

          1. 5

            I’m glad the author has an environment they like, and I absolutely adore many things built in the worldwide JavaScript community. I don’t want to yuck anyone’s yum!

            That said, as far as “a language is good/bad” can have any meaning, I don’t think this is a persuasive defense of the language. Most of the points have comparables in other languages that are far superior, and the history of working with JavaScript is a lot richer than what the author describes here.

            The syntax section uses cutting-edge features of JavaScript syntax (async/await, let/const, fat arrow functions) which is far from most of the JavaScript code much active maintenance happens in. Most of us still have to understand var and deal with its weird function-scoping, and have to use callbacks or promises instead of async/await. When you take that code sample and backport it to how it’s almost always looked, it’s certainly a tangled nest of weeds that few would call a fun time.

            It also elides what language features could enable something better, like preemptive scheduling or proper lexical scoping. My experience has been that, no matter what version of JS you’re writing, you have to know 4 meanings of this and the minor differences between function() { and () => { to maintain most codebases.

            This also doesn’t go into the various abstractions one can use: in Ruby or Java, you have Objects. In OCaml, you have modules and functions (some folks use the OO features but it’s rare). In my experience, JS has far less consensus: some use objects like Lua tables, some use them to create class hierarchies, some write something like Scheme and largely rely on functions.

            When the author gets to toolchains, which is mostly backporting other language features. Static type checking is great, but it’s a far cry away from something like Reason or Rust. It’s still opt-in. Are all those linters really a world above gofmt? How about the complexity of picking one, then integrating it with grunt/gulp/webpack/Make? And with Jamine/Chai/other test frameworks?

            When you stitch something together, it is very impressive, but I don’t think the language helped us here, it was more the sheer number of bodies and amount of investment by the world’s wealthiest companies.

            I do most of my programming interviews in JS because I’ve learned to be fast with it, and again, I highly appreciate a ton about it. I also think there are many people who hate on JS in an over-the-top, performative way that’s probably them just trying to feel important. But when people criticize a language that was designed in 10 days for looking like it was designed in 10 days, I think it’s valid.

            1. 3

              I’ll be giving my first conference talk at Deconstruct in a few weeks, May 21-22 in Seattle. It’ll also be my first conference as an attendee! 😄

              Hope folks come out, I’m very excited!

              1. 23

                Electron is not flash.

                JavaScript is flash.

                Electron is the Adobe Air and that’s far worse than being a modern flash.

                1. 5

                  Well, with Air you had to have the Air runtime. Electron apps are self contained, right? That makes them at least somewhat better…

                  1. 23

                    You surely mean worse? That means each Electron app potentially packages an old, unpatched runtime with similar complexity to the Chrome browser.

                    1. 12

                      This is the new world.

                      Developers actually think JavaScript is “low level” (I’ve seen multiple people call it ‘the new assembly’) because other languages transpile to it.

                      Electron developers are essentially front-end web developers and/or nodejs developers.

                      NodeJS developers by-and-large think npm is “good”. NPM’s dependency management were (and maybe still be, I don’t know) a joke. Every package got a copy of all the packages it depends on.

                      The authors who create NPM packages are just as guilty. Depending on a hard version of a library seems to be very fucking common.

                      The last time I bothered to check on this stuff, I posted about it: https://news.ycombinator.com/item?id=11092772

                      1. 13

                        NPM’s dependency management were (and maybe still be, I don’t know) a joke.

                        It still is. I work on a small node.js project at work. I was explaining npm to some Haskell programmers. They were horrified when showed the project’s node_modules directory, which contained:

                        • 8 copies of esprima, a JavaScript parser
                        • 11 copies of glob, a glob implementation
                        • 12 copies of readable-stream, which is an implementation of something that’s also in node.js…

                        I probably shouldn’t say “copies” because for each there’s at least 4 different versions.

                        npm’s installation is also non-deterministic. You can install the same dependencies twice and get a different layout of packages in your node_modules directory.

                        1. 1

                          npm’s installation is also non-deterministic. You can install the same dependencies twice and get a different layout of packages in your node_modules directory.

                          That should be fixed with Yarn. It’s just amazing that the JavaScript community took this long to build a solution.

                          1. 1

                            There’s also ied, which does a pretty good job.

                        2. 1

                          Yeah, npm isn’t so good, that’s why Facebook came up with Yarn, which seems to solve a lot of the shortcomings of npm. We’re transitioning to it at my company and its working great. With npm, we intermittently saw builds fail because of non-deterministic package resolution, which yarn solved.

                        3. 2

                          It’s hard to argue with you. You’re right, but I feel there’s maybe a bit of nuance here.

                          In the case of Air, one vuln definitely takes out all of the Air apps on the system. A vuln in Chrome / Electron, is likely targetting one specific version, or a small range of them. In the event all Electron apps have a slightly different version, you might actually get lucky from time to time!

                          1. 1

                            A vuln in Chrome / Electron, is likely targetting one specific version, or a small range of them. In the event all Electron apps have a slightly different version, you might actually get lucky from time to time!

                            Unfortunately life shows it’s the other way around.

                            Take the recent Linux remote UDP vulnerability as a perfect depiction of what usually happens.

                            1. You have a ton of systems, devices shipping a different version of the Linux kernel
                            2. Not all of them receive security patches
                            3. Someone finds a flaw and it happens to impact every kernel from 2.6 up to version 4.5

                            The situation you are depicting would only work if every security flaw was contained to a single version of the bundled runtime - in reality it’s more likely that it will impact a range of versions and bundled software is less likely to receive security updates.

                            The only thing that changes is having to patch each and every copy of the runtime in case of a security issue instead of patching the single system wide shared runtime.

                            1. 1

                              Unfortunately life shows it’s the other way around.

                              It happens both ways. Some versions of Red Hat Enterprise Linux, for instance, weren’t affected by this UDP vulnerability, but your point is taken.

                              Maybe the thing to agree on is that shipping any software results in some sort of security risk.

                              1. 1

                                Maybe the thing to agree on is that shipping any software results in some sort of security risk.

                                I would lean towards: “any shipped software that is not actively maintained and doesn’t receive security patches”.

                                1. 1

                                  Between the time the patch is identified, fixed, and release there is a window of non-zero time. An active maintainer can reduce this time, but in many cases, the user isn’t forced to update, nor is this time 0. Even worse is if the vuln is actively exploited before being disclosed.

                            2. 1

                              Given that taking over one app lets you control all the others (you’re now running with users privs) I’d have to say this is a worse position.

                              1. 1

                                It’s bad anyway you look at it. Maybe the Electron model is worse because the number of different versions possible for the runtime increases the likelihood of one being vulnerable. But maybe, just maybe, the track record of Adobe is so bad that the chances of Air having vulnerabilities far exceeds the likelihood of Chrome having vulnerabilities, even when many different versions are installed on the system?

                                But, I don’t disagree here!

                          2. 2

                            In 2011 AIR shipped an embedded runtime feature, so you could do the “self-contained” route if you wanted to.

                            1. 2

                              I was not aware of this!

                          3. 2

                            I am reading this while listening to Spotify, whose desktop app is Adobe Air. Tool to task people, all this vitriol is misplaced.

                            1. 5

                              Spotify is only good because they have a huge selection of music. Both their iOS and Mac app is the worst app I have installed on either platform, except maybe iTunes.

                              1. 2

                                So, if you judge the apps in terms of the native Apple ecosystem, sure, I’m with you. But at least for me there is a sense of Good Enough and spotify for me personally at least is Good Enough. I can play my music, I can browse music my friends are listening to, I can enjoy the myriad playlists Spotify and my friends create. It Is Good Enough.

                                1. 2

                                  Sure but in that sense, CDs are good enough too. Luckily, most aim for better, not just good enough. If they didn’t, the world wouldn’t improve.

                                  1. 2

                                    Totally agree. However this is a case where in an ideal world, everyone would develop native clients for every platform and life would be grand.

                                    But, in the real world, every development man hour has to be justified to the bean counters, and for my needs, I would much MUCH rather have a Good Enough client that runs on my Mac, my Linux desktop, my phone, my FireTV, etc etc etc than a deliciously smooth native client that’s Windows only and to heck with everyone else :)

                                    1. 1

                                      Well yeah, but for someone huge like Spotify, Slack, Github and so on, I don’t think it’s justified at all. And I’d rather use something else. Only problem is that apples native music player is even worse in this particular case :p

                          1. 6

                            This might be a good companion read http://dev.stephendiehl.com/hask/ A lot of us used Haskell 6-7 years ago and my perception is that it’s a lot different now.

                            Also, some Haskell humor https://twitter.com/gabrielg439/status/701871069607505921

                            1. 3

                              I like Stephen’s work. Quite different, of course, in that he’s offering positive advice on what to do. We’re just mapping out the trapdoors and deadfalls.

                            1. 3

                              I’m primarily an application engineer, and don’t touch much ops/networking/infrastructure, so the Current Project is “simple” but causing me to learn: I’m hosting my blog on a proper Cloud Engine (Google, in this case) using Docker, and trying to get SSL via certbot. I’ve more or less got containers and Kubernetes down enough to host the thing, I’m just bumping my head on Let’s Encrypt in a Dockerized setting, ideally automatically.

                              Other thinking is to ssh into the instance, get the certs from there manually, and copy out the files to use in future deploys. Basically http://www.evolveyourweddingbusiness.com/wp-content/uploads/2014/12/0842421504b474e9ba1adb650f17996a145ff1290de6596821915c3ea53218af.jpg