Threads for cdo

  1. 1

    I have a lil home server which (among other things) hosts NFS, which I keep most of my code, documents, music etc on. If I’m away from home I’ll either just copy stuff to/from the NFS mount ahead-of-time or VPN into my home network and continue using the NFS, depending on whether I’m expecting to have decent internet access.

    1. 13

      This makes me very happy, crypto is a life-destroying scam and it’s always great to see it treated as such.

      1. 3

        I completely agree this is a downside of defer, but I do think there are a few (contingent on the task in hand) reasons to prefer it over RAII. One thing that’s pretty nice about Zig code is that it’s really easy to reason about its performance due to things being pretty explicit, and RAII does erode this slightly as there is (if I understand correctly) potentially arbitrary amounts of code being executed when exiting some scope, so you have to read a lot more code before fully understanding the performance of a leaf function. I admit this is not really a real issue for most programmers most of the time though. Another more common case where defer is really nice is when calling C libraries, which there are of course a huge number of. defer in Zig lets you use those libraries and have fairly nice resource clean-up happening without needing to build and maintain any wrappers. RAII also seems like it pushes you down the exceptions route for handling errors during initialisation and clean-up, and exceptions certainly have their downsides.

        1. 4

          It would be intetto have a language with “explicit RAII”. You can define a destructor, but instead of calling it for you the compiler just complains if you forget to call it. This way it would be visible in your code (likely with a defer statement) but hard to forget.

          when calling C libraries

          When interfacing with a C library in C++ or Rust one of the first things I tend to do is make small wrappers for resources that implement RAII for them. I find they pays off very quickly in terms of productivity and correctness. Even if I don’t wrap much else this is very useful.

          1. 1

            Heyyy, similar idea! See above.

            1. 2

              I read that comment difficulty. I read that comment as code such as:

              autoclose File f = open(...)
              

              I am talking about “regular” RAII as seen in C++ or Rust except that it fails to compile if you forget it. It isn’t opt-in because it is required but the caller still needs to write cleanup code (well call the cleanup function). For example.

              f = open(...)
              f.write("foo")
              // Error here: "f implements Drop and must be cleaned up.
              

              Of course you could combine these ideas because something like an autoclose attribute would manage the cleanup and prevent the error from firing.

        1. 17

          On the one hand, I totally get the value of a lack of a build step. Build steps are annoying. On the other hand, authoring directly in HTML is something I am perfectly happy to do as little of as possible. It’s just not a pleasant language to write in for any extended amount of time!

          1. 20

            I’m pretty convinced that Markdown is the local maxima for the “low effort, nice looking content” market.

            1. 10

              Agreed. ASCIIDoc, reStructuredText, LaTeX, and other more-robust-than-Markdown syntaxes all have significantly more power but also require a great deal more from you as a result. For just put words out, Markdown is impressively “good enough”.

              1. 4

                I can never remember Markdown syntax (or any other wiki syntax for that matter), while I’m fairly fluent in HTML, and I’m not even a frontend dev. HTML also has the advantage that if some sort of exotic markup is necessary, you know it’s expressble, given time and effort.

                1. 7

                  That’s fine, because Markdown allows embedded HTML [1]

                  About the only thing that’s a bit obtuse is the link syntax, and I’ve gladly learned that to not have to manually enclose every damn list with or tags.

                  [1] at least Gruber’s OG Markdown allowed it by default, and I recently learned CommonMark has an “unsafe” mode to allow it too.

                  1. 11

                    The trick to remember how to do links in Markdown is to remember that there are brackets and parentheses involved, then think what syntax would make sense, then do the opposite.

                    1. 4

                      For reference: a Markdown [link](https://example.com)

                      Elaboration on the mnemonic you describe

                      I thought like you when I first started learning Markdown:

                      • Parentheses () are normal English punctuation, so you would intuitively expect them to surround the text, but they don’t.
                      • Square brackets [] are technical symbols, so you would intuitively expect them to surround the URL, but they don’t.

                      However, I find “don’t do this” mnemonics easy to accidentally negate, so I don’t recommend trying to remember the order that way.

                      Another mnemonic

                      I think Markdown’s order of brackets and parentheses is easier to remember once one recognizes the following benefit:

                      When you read the first character in […](…), it’s clear that you’re reading a link. ‘[’ is a technical symbol, so you know you’re not reading a parenthetical, which would start with ‘(’. Demonstration:

                      In this Markdown, parentheticals (which are everywhere) and
                      [links like these](https://example.com) can quickly be told
                      apart when reading from left to right.
                      
                      Why not URL first?

                      Since you wrote that Markdown does “the opposite”, I wonder if you also intuitively expect the syntax to put the URL before the text, like in [https://www.mediawiki.org/wiki/Help:Links MediaWiki’s syntax] (actual link: MediaWiki’s syntax). I never found that order intuitive, but I can explain why I prefer text first:

                      When trying to read only the text and skip over the URLs, it’s easier to skip URLs if they come between grammatical phrases of the text (here), rather than interrupting a (here) phrase. And links are usually written at the end of phrases, rather than at the beginning.

                      1. 2

                        Well I’ll be dammed. That completely makes sense.

                        I do, however, wonder whether this is a post-hoc rationalization and the real reason for the syntax is much dumber.

                      2. 3

                        Hah. The mnemonic I use is everyone gets the ) on the end of their wiki URLs fucked up by markdown… because the () goes around the URL. therefore it is s []().

                        1. 2

                          This is exactly what I do. Parens are for humans, square brackets are for computers, so obviously it’s the other way around in markdown.

                        2. 3

                          A wiki also implies a social contract about editability. If my fellow editors have expressed that they’re uncomfortable with HTML, it’s not very polite of me to use it whenever I find Markdown inconvenient.

                          1. 1

                            Of course. I was replying in context of someone writing for themselves.

                        3. 3

                          This is interesting: I’ve heard that same experience report from a number of people over the years so I believe it’s a real phenomenon (the sibling comment about links especially being the most common) but Markdown clicked instantly for me so I always find it a little surprising!

                          I have hypothesized that it’s a case of (a) not doing it in a sustained way, which of course is the baseline, and (b) something like syntactical cross-talk from having multiple markup languages floating around; I took longer to learn Confluence’s wiki markup both because it’s worse than Markdown but also because I already had Markdown, rST, and Textile floating around in my head.

                          I’m curious if either or both of those ring true, or if you think there are other reasons those kinds of markup languages don’t stick for you while HTML has?

                          1. 2

                            I’m not Michiel, but for me, it’s because HTML is consistent (even if it’s tedious). In my opinion, Gruber developed Markdown to make it easier for him to write HTML, and to use conventions that made sense to him for some shortcuts (the fact that you could include HTML in his Markdown says to me that he wasn’t looking to replace HTML). Markdown was to avoid having to type common tags like <P> or <EM>.

                            For years I hand wrote the HTML for my blog (and for the record, I still have to click the “Markdown formatting available” link to see how to make links here). A few years ago I implemented my own markup language [1] that suits me. [2] My entries are still stored as HTML. That is a deliberate decision so I don’t get stuck with a subpar markup syntax I late come to hate. I can change the markup language (I’ve done it a few times already) and if I need to edit past entries, I can deal with the HTML.

                            [1] Sample input file

                            [2] For instance, a section for quoting email, which I do quite often. Or to include pictures in my own particular way. Or tabular data with a very light syntax and some smarts to generate the right class on <TD> elements consisting of numeric data (so they’re flush right). Stuff like that.

                            1. 2

                              Yeah, with markdown, I often accidentally trigger some of its weird syntax. It needs a bunch of arbitrary escapes, whereas HTML you can get away with just using &lt;. Otherwise, it is primarily just those <p> tags that get you; the rest are simple or infrequent enough to not worry about.

                              whereas again, with the markdown, it is too easy to accidentally write something it thinks is syntax and break your whole thing.

                              1. 1

                                Yes, I’ve found that with mine as well.

                              2. 1

                                I don’t mean this as an offense, but I did a quick look at your custom markup sample and I hated pretty much everything about it.

                                Since we’re all commenting under a post from someone that is handwriting HTML, I think it goes without saying that personal preferences can vary enormously.

                                Updated: I don’t hate the tables syntax, and, although I don’t particularly like que quote syntax, having a specific syntax for it is cool and a good idea.

                                1. 1

                                  Don’t worry about hating it—even I hate parts of it. It started out as a mash up of Markdown or Org mode. The current version I’m using replaces the #+BEGIN_blah #+END_blah with #+blah #-blah. I’m still working on the quote syntax. But that’s the thing—I can change the syntax of the markup, because I don’t store the posts in said markup format.

                              3. 2

                                You’re absolutely right, and so is spc476; HTML has a regular syntax. Even if I’ve never seen the <aside> tag, I can reason about what it does. Escaping rules are known and well-defined. If you want to read the text, you know you can just ignore anything inside the angular brackets.

                                Quick: in Markdown, if I want to use a backtick in a fixed-width span, do I have to escape it? How about an italic block?

                                This would all be excusable if Markdown was a WYSIWYG plain-text format (as per Gruber’s later rationalisation in the CommonMark debate). Then I could mix Markdown, Mediawiki, rST and email syntax freely, because it’s intended for humans to read, and humans tend to be very flexible.

                                But people do expect to render it to HTML, and then the ambiguities and flexibility become weaknesses, rather than strengths.

                            2. 2

                              ASCIIDoc

                              While I agree about the others, I fairly strongly disagree about AsciiDoc (in asciidoctor dialect). When I converted my blog from md to adoc, the only frequent change was the syntax of links (in adoc, URL goes first). Otherwise, markdown is pretty much valid asciidoc.

                              Going in the opposite direction would be hard though — adoc has a bunch of stuff inexpressible in markdown.

                              I am fairly certain in my opinion that, purely as a language, adoc is far superior for authoring html-shaped documents. But it does have some quality of implementation issues. I am hopeful that, after it gets a standard, things in that front would improve.

                              1. 1

                                That’s helpful feedback! It’s limped with the others in my head because I had such an unhappy time trying to use it when working with a publisher[1] a few years back; it’s possible the problem was the clumsiness of the tools more than the syntax. I’ll have to give it another look at some point!

                                [1] on a contract they ultimately dropped after an editor change, alas

                            3. 4

                              Agree, I’ve been using it a ton since 2016 and it has served me well. I think it’s very “Huffman coded” by people who have written a lot. In other words, the common constructs are short, and the rare constructs are possible with embedded HTML.


                              However I have to add that I started with the original markdown.pl (written ~2004) and it had some serious bugs.

                              Now I’m using the CommonMark reference implementation and it is a lot better.

                              CommonMark is a Useful, High-Quality Project (2018)

                              It has additionally standardized markdown with HTML within markdown, which is useful, e.g.

                              <div class="">
                              
                              this is *markdown*
                              
                              </div>
                              

                              I’ve used both ASCIIDoc and reStructuredText and prefer markdown + embedded HTML.

                              1. 3

                                I tend to agree, but there’s a very sharp usability cliff in Markdown if you go beyond the core syntax. With GitHub-flavoured Markdown, I can specify the language for a code block, but if I write virtual then there’s no consistent syntax to specify that it’s a C++ code snippet and not something else where the word ‘virtual’ is an identifier and not a keyword. I end up falling back to things like liquid or plain HTML. In contrast, in LaTeX I’d write \cxx{virtual} and define a macro elsewhere.

                                I wish Markdown had some kind of generic macro definition syntax like this, which I could use to provide inline domain-specific semantic markup that was easier to type (and use) than <cxx>virtual</cxx> and an XSLT to convert it into <code style="cxx">virtual</code> or whatever.

                                1. 3

                                  I agree. What sometimes makes me a bit sad is that markdown had a feature compared to others that you can write it to make a nice looking text document as well that you might just output on the terminal for example.

                                  It kind of has that nicely formated plain text email style. Also with the alternative syntax for headings.

                                  Yet when looking at READMEs in many projects it is really ugly and hard to read for various reasons.

                                  1. 4

                                    The biggest contributor there in my experience (and I’m certainly “guilty” here!) is unwrapped lines. That has other upsides in that editing it doesn’t produce horrible diffs when rewrapping, but that in turn highlights how poor most of our code-oriented tools are at working with text. Some people work around the poor diff experience by doing a hard break after every sentence so that diffs are constrained and that makes reading as plain text even worse.

                                    A place I do wrap carefully while using Markdown is git commit messages, which are basically a perfect use case for the plain text syntax of Markdown.

                                    1. 1

                                      I honestly don’t care that much about the diffs? I always wrap at around 88/90 (Python’s black’s default max line length), and diffs be dammed.

                                      I also pretty much NEVER have auto wrap enabled, specially for code. I’d rather suffer the horizontal scroll than have the editor lie about where the new lines are

                                2. 4

                                  It’s not just that they’re annoying, computing has largely been about coping with annoyances ever since the Amiga became a vintage computer :-). But in the context of maintaining a support site, which is what the article is about, you also have to deal with keeping up with whatever’s building the static websites, the kind of website that easily sits around for like 10-15 years. The technology that powers many popular static site generators today is… remarkably fluid. Unless you want to write your own static site generator using tools you trust to stay sane, there’s a good chance that you’re signing up for a bunch of tech churn that you really don’t want to deal with for a support site.

                                  Support sites tend to be built by migrating a bunch of old pages in the first two weeks, writing a bunch of new ones for the first two months, and then infrequently editing existing pages and writing maybe two new pages each year for another fifteen years. With most tools today, after those first two or three honeymoon years, you end up spending more time just keeping the stupid thing buildable than actually writing the support pages.

                                  Not that writing HTML is fun, mind you :(.

                                  (Please don’t take this as a “back in my day” lament. A static site generator that lasts 10 years is doable today and really not bad at all – how many tools written in 1992 could you still use in 2002, with good results, not as an exercise in retrocomputing? It’s not really a case of “kids these days ruined it” – it’s just time scales are like that ¯\(ツ)/¯ )

                                  1. 1

                                    Heh. I was using an editor written in 1981 in 2002! [1] But more seriously, I wrote a static site generator in 2002 that I’m still using (I had to update it once in 2009 due to a language change). On the down side, the 22 year old codebase requires the site to be stored in XML, and uses XSLT (via xsltproc) to convert it to HTML. On the plus side, it generates all the cross-site links automatically.

                                    [1] Okay, it was to edit text files on MS-DOS/Windows.

                                  2. 2

                                    I find that writing and edititing XML or HTML isn’t so much of a pain if you use some kind of structural editor. I use tagedit in Emacs along with a few snippets / templates and imo it’s pretty nice once you get used to it.

                                  1. 2

                                    The current data points used for generating fingerprints are: user agent, screen print, color depth, current resolution, available resolution, device XDPI, device YDPI, plugin list, font list, local storage, session storage, timezone, language, system language, cookies, canvas print

                                    Curious if a browser plugin that randomizes or obfuscates these exists.

                                    1. 5

                                      The tor browser (which is a set of firefox configurations + extensions) blocked this successfully for me.

                                      1. 5

                                        The Tor browser does the best possible thing: it gives everyone the same UA, resolution, etc. And more importantly, it picks the most common values that are observed on the web for those. Every Tor browser user looks like the most statistically average web user in the world.

                                      2. 5

                                        Firefox has privacy.resistFingerprinting, which I’ve used reasonably successfully. Sometimes it breaks sites that display time e.g. Gmail other times it breaks in bigger ways e.g. when writing to a <canvas> element. So it’s not uncommon for me to need to temporarily disable it for a one-off basis.

                                        1. 3

                                          I’m running Firefox from the Debian repos with essentially all the privacy settings enabled as well as a bunch of extensions for fingerprint blocking, tracker blocking etc and it seems to have stopped this site from doing its tricks :)

                                          1. 1

                                            Brave has something builtin AFAIK

                                            1. 2

                                              I temporarily installed brave just to test this, then removed it because I find other things about it worrisome. But it did successfully block this specific site from identifying me. Vanilla firefox did not block it. tor browser successfully blocked it. So did vivaldi.

                                              1. 1

                                                What were worrisome parts? May be I can evaluate too.

                                                1. 5

                                                  They have, in the past, decided it was OK to inject content into websites for their own financial gain. Here’s an example. This is related. Their administration of the “Brave Rewards” program (stripping ads from sites, showing their own stuff, and holding payments until the sites step up and ask for them) is also a little disturbing if less likely to be privacy-violating.

                                                  In short, if I want an alternate blink-based thing, I think Vivaldi is less likely to have a profit motive where they benefit from compromising my interests. And If I want something really privacy focused, I don’t think a blink thing is likely the smart play anyway. So there’s no upside to make me want to keep Brave around given what they’ve shown me.

                                          1. 4

                                            I would go further and add that the essentialist view of categories underlying questions like “is X part of category A or B?” is not a useful model. Categories are better thought of as something acted out between a person or community and a thing rather than as a property of a thing. Different people or communities (or the same person or community in different contexts) may (and probably should) categorize a thing differently – this is expected and appropriate.

                                            1. 4

                                              See also, The Categories Were Made For Man, and the post it’s based on, How An Algorithm Feels From Inside.

                                              tl;dr We mentally use (semi-)binary classifiers to decide group membership, and that means we vacuously believe there’s “a state of a thing being a member of a group” that’s independent from all the individual factors playing into the question. This drives approximately every categorization debate ever.

                                              1. 1

                                                They both look super interesting, thanks for the links! :)

                                            1. 1

                                              Oh man this was so much fun

                                              1. 18

                                                It’s down to licensing.

                                                If specifications are open and there’s no restriction (e.g. patent licensing) so that everybody can freely design, make and sell specification-compliant modules (including the container/shell itself), welcome.

                                                Otherwise, good riddance.

                                                I am not optimistic, as I couldn’t easily find the information on licensing in the website.

                                                1. 9

                                                  The ars writeup of this makes promising sounds like

                                                  The company also pledges to open up its hardware ecosystem to third parties, which will be able to design, build, and sell compatible modules via a Framework Marketplace.

                                                  But as you point out, there’s no information on licensing, etc. in that handwaving. I’m optimistic that it’s at least on their radar as something they think is good for them. That said, I’ll be waiting to see what evolves once things are shipping before I get excited.

                                                  I do hope a system with field repairability by its owner becomes available. Because the ones I liked (Thinkpads) are going away from that lately.

                                                  1. 8

                                                    FWIW they did say on Twitter:

                                                    We’ll be publishing specifications and reference designs for the Expansion Card system under open licenses, and releasing documentation around the internal interfaces. Our focus is on building a hardware ecosystem around the Framework Laptop.

                                                    1. 5

                                                      Without this there’s a solid chance that new parts will cost more than a new laptop, which in the real world will kill the idea off.

                                                      1. 4

                                                        Good point about licensing. This needs to be open. It would be cool to see something like this but similar to Pine64 openness

                                                        1. 1

                                                          I’m pretty optimistic about this. It sounds like they paid enough attention to everything that techies were talking about. I think they’ll come up with reasonable licensing as well… at least in the beginning. I don’t think they’ll do a worse job than Apple regarding hardware lockdown.

                                                        1. 10

                                                          I’m always happy to see Racket going forward. It’s the best language (I know of) for learning about languages, especially with How to Design Programs. I write Clojure at $dayjob but find Racket more enjoyable and cleaner as a Lisp.

                                                          AFAICT Racket is a reasonable choice for real-world applications, but it’s not very commonly used. Common Lisp is more common (no pun intended) though still rare. (Anyone else hate how no pun intended is always a lie?)

                                                          1. 14

                                                            Oh, I’m cons-tantly making lisp puns.

                                                            1. 6

                                                              ☝️ Yes, officer, this is the criminal right here.

                                                              1. 4

                                                                Perhaps you meant to say: “Yes, cons-table…”

                                                                1. 3

                                                                  criminal? cdo?

                                                                  explain!

                                                            1. 18

                                                              People who stress over code style, linting rules, or other minutia are insane weirdos

                                                              Having an automatic clang-format filter on git check-in solves so many of these pointless arguments.

                                                              1. 20

                                                                Oh, the insane weirdos will find things to bicker about even if you pass every linter rule there is.

                                                                I wish I were kidding but you’ll find, for example, that if you do something like this:

                                                                buffer.append("\r\n");
                                                                buffer_len += 2;
                                                                

                                                                in a single place, as part of a completely non-essential function in a 2,000-line program, they’ll complain about the magic number on the second line. Rewrite it like this:

                                                                buffer.append("\r\n");
                                                                buffer_len += len("\r\n");
                                                                

                                                                yep, you’ve got it, they’ll complain about the magic string on both lines, plus what happens if someone changes the first one and forgets to update the second one (“yes I know the spec says lines are always terminated with \r\n but it’s not good programming practice!”)

                                                                No problem, you say – ironically, they’re kindda right this time, so okay:

                                                                buffer.append(CR_LF);
                                                                buffer_len += len(CR_LF);
                                                                

                                                                …but the meaning of CR_LF is very opaque, it doesn’t emphasize that this is meant as a line terminator and it may not be obvious to people who come from a Unix background, rather than Windows (oh yeah, totally, I always wondered what those weird ^M signs were in my files, yeah, it’s not obvious at all). Perhaps we should call it CR_LF_TERMINATE_LINE instead?

                                                                Sure,

                                                                buffer.append(CR_LF_TERMINATE_LINE);
                                                                buffer._len += len(CR_LF_TERMINATE_LINE);
                                                                

                                                                Okay, you say to yourself, clearly this is the end of the line? Nope, they’ll get back to you with something like:

                                                                “I think it’s okay in terms of variable names but the code as it is right now is inelegant to the point where it’s unmaintainable. It’s bad programming practice to repeat yourself (links to DRY entry on Wikipedia) – you should refactor this into a single, general function that appends a user-defined sequence to the original buffer and modifies its length accordingly.”

                                                                When you do that, the problem, of course, will be that the function is too general now, and you’ll really want is to add a separate, buffer_terminate_line function that calls the more general “append” function with "\r\n". Of course, you’ll now have two functions, both called from just one place: one is called by the other function, the other one is called in your code above. You got a longer, probably buggier program, but it’s so much more readable now. Assuming you named the functions correctly, that is ;-).

                                                                The example above is fictional for obvious reasons but I ran into it regularly throughout my career.

                                                                It’s a little better now that I’m a contractor – I no longer fuss about these things and will happily bill companies that don’t keep their “well ackshually” developers in check, unless they want something that’s literally wrong.

                                                                Edit: some of the comments around here are… like, so blissful, like y’all think these are just things that you read about on The Daily WTF but surely nobody encounters this all the time, right? You have no idea how lucky you are and I have no nice words to say to you, your happiness fills me with dread and the fact that there are programmers who don’t experience these things on a weekly basis is so foreign to me I just hate you all right now and I’m going to go to bed and hate you all while I’m waiting to fall sleep! Did I say how much I hate you, lobste.rs? Ugh!

                                                                Okay, no, seriously, these things are just so common that, with every year that passes, I find myself spending more and more time wondering why I still put up with it instead of, I dunno, anything?

                                                                1. 4
                                                                  buffer.append("\r\n");
                                                                  buffer_len += 2;
                                                                  

                                                                  Dumb question but, ah, is there some reason why buffer_len isn’t a field on buffer which is updated for you by the .append() call? ;)

                                                                  weirdos will find things to bicker about even if you pass every linter rule there is

                                                                  The inverse of this is finding weird people who go to elaborate lengths to defeat a linter a rule that is pointing out a genuine bug in software, rather than just fixing it.

                                                                  (This is not an accusation towards you, just that sentence reminded me of it.)

                                                                  1. 7

                                                                    Dumb question but, ah, is there some reason why buffer_len isn’t a field on buffer which is updated for you by the .append() call? ;)

                                                                    The fictional code example above is written in a fictional language that doesn’t allow integer fields for objects called “buffer” :-P

                                                                    The inverse of this is finding weird people who go to elaborate lengths to defeat a linter a rule that is pointing out a genuine bug in software, rather than just fixing it.

                                                                    Oooh, I have a collection of stories about this one, too :(. Way back when I was working for $megacorp, I was more or less the chief intern herder in the worst internship program you’ve ever seen. They’d hire a bunch of interns over the summer and the only plan about what to have them do was “something easy because we don’t have anyone to supervise them”. I was in one of the few teams that wasn’t ran by morons and I had some idle cycles to spare once in a while, so I’d try to help the poor souls who ended up there over the summer.

                                                                    One of the things they regularly ended up doing was run Coverity scans, fix the trivial bugs and report the more complex ones (super easy to quantify, right?). This would roughly go as follows:

                                                                    1. Ian Intern would report a bug to Grumpy Senior

                                                                    2. Grumpy Senior would close it without even looking at it because he had no idea who Ian Intern was, probably an intern

                                                                    3. I’d reopen the bug, ask them to at least confirm it before closing it.

                                                                    4. Grumpy Senior would close the bug immediately saying there’s nothing to confirm, it’s just a linter warning

                                                                    5. Ian Intern would reopen the bug with a crash dump

                                                                    6. Grumpy Senior would close the bug as unreproducible, Ian Intern probably did something wrong

                                                                    7. I’d reopen the bug because it’s a fuckin’ crash and we can’t tell our users they’re holding it wrong (this is usually where I started bringing out the tiny guns, i.e. Cc-ing managers in bug reports).

                                                                    8. Grumpy Senior would reluctantly look at it but it’s definitely not that, that’s just a linter warning.

                                                                    Now comes the beautiful part:

                                                                    1. Three days later, Grumpy Senior would push a bullshit fix and close the bug.

                                                                    2. That same day, they’d push the actual fix, with a commit message saying “Misc. style and Coverity warnings fixes”

                                                                    And so on – multiplied by about 40 Grumpy Seniors all over the organisation, and about six months’ worth of bad code because Coverity fixes took a lot of work so they only ran the scan once every six months :-D.

                                                                    1. 1

                                                                      The fictional code example above is…

                                                                      Heh. ♥️

                                                                      the worst internship program

                                                                      Oh the poor little darlings. The way the org behaved to them sounds toxic. Good on you for trying to improve it. (But alas maybe Sisyphean.)

                                                                      1. 2

                                                                        Sisyphus the game (for the Atari 2600 no less!).

                                                                2. 7

                                                                  found the weirdo! (I’m only poking fun at you)

                                                                  I have 100% grown to appreciate “deciding once” with automatic formatters, and resisting urges to “re-decide” as much as possible. I have ALSO realized that it can be a HUGE pain to “decide once” after you’ve already scaled to many teams + lots of code. You want to do that up front, early-on, and stick with it.

                                                                  1. 4

                                                                    :)

                                                                    The big advantage of having settled on a particular clang-format is that it’s not someone else’s choices that annoy, but just the arbitrary decisions of the formatter & that seems to defang the drive to nit-pick over formatting choices.

                                                                    I agree that it’s a huge pain to enforce a format late into a project though.

                                                                    1. 3

                                                                      My biggest gripe with many automatic formatting tools is that they pointlessly frob with line endings: clang-format will enthusiastically add or remove them by default, leading to code that I can describe as nothing short of butt-ugly by any standard. Luckily you can disable this with ColumnLimit: 0, but it’s a horrible default that too many projects use IMO. Splitting a 81-column sting over two lines is silly, and forcibly put all the arguments for XCreateWindow() on 1 or 2 lines “just because there is space” is even worse.

                                                                      1. 2

                                                                        Personally, I find working with a column limit set to around 120 nice and comfy, so I set clang-format to that & if it occasionally does something a bit odd I decide not to care about it. I save more time by never having to hand format code than I do obsessing over the odd corner case where it doesn’t make the “perfect” aesthetic choice.

                                                                        1. 1

                                                                          yep, or messing with vertically aligned code

                                                                        2. 2

                                                                          It’s not even that, I think. Not that the automation makes it so you’re not mad about the choices, but rather that you’re not forced for manually reformat a fuckload of code to please some arbitrary whinging program as the final step of every change.

                                                                          1. 6

                                                                            I often just write stuff like if x==y{return 42} now and just let gofmt deal with all of that. A small but measurable productivity boost.

                                                                            1. 1

                                                                              Exactly. Code formatters let you get on with with the actual job of writing code.

                                                                              I setup emacs to invoke the formatter on every enter, or with a key-binding when I want to invoke it directly. Why waste time inserting spaces / carriage returns when the formatter does a perfectly good job?

                                                                      2. 1

                                                                        Tried that in the last place I worked and people just started complaining about the formatter configuration ahaha

                                                                        1. 1

                                                                          That probably depends on the team. We have a clang-format style that isn’t my preferred style but it’s consistent and I’d much rather use a consistent style that is not quite my ideal than argue about style. Because everything is consistently formatted, if I cared enough, I could apply a different style, modify the code, and then format it back. I actually supervised a student building a tool designed for exactly that workflow (which he presented at EuroLLVM some years back; CELS: Code Editing in Local Style). I wish GitHub would integrate something like that into their code view. Don’t like the style of the project? Render it in a different style in code reviews and when you browse their code.

                                                                          1. 1

                                                                            I’m kind of okay with that in theory as long as the result is (possibly rejected) patches to the repo containing the formatter config.

                                                                            It might be helpful if the formatter config looks scary so people are hesitant to frob it unnecessarily.

                                                                        1. 2

                                                                          If anyone else finds themselves looking for a decent calculator program - I recommend giving frink a try.

                                                                          It’s a units-aware calculator - that is, if you multiply 3 meters / 5 seconds you get 15 meters per second.

                                                                          In my experience using it, this wipes out a substantial class of bugs - if the final result is not in the expected units (whether that be US dollars or kg/m^2), you know you’ve made an error.

                                                                          1. 1

                                                                            Frink looks awesome, definitely going to give it a spin :)

                                                                          1. 3

                                                                            In my view, the reason to learn “fancy” stuff like Haskell, Prolog, Idris, what have you is not to use them in production, it’s for the exposure to a new approach to system design. I think it can be very easy to get caught in a local minimum if all you focus on is pure pragmatism and getting the job done; building something in an entirely novel and perhaps quite bizarre way can be a good way to explore the landscape. Of course, there is a time and a place for all that – if you are building some safety-critical system that might kill someone or cost millions if it goes wrong then of course you stick to the tried and tested solutions, but only ever doing that I think is losing out in the long term.

                                                                            1. 2

                                                                              One thing sorely missing from Nest in order to bootstrap is the ability to download a tarball/zipfile/etc.

                                                                              I see a nix file, so eager to try it out but I cannot get anu without having anu…

                                                                              1. 3

                                                                                Here you go:

                                                                                $ curl https://static.crates.io/crates/anu/anu-1.0.0-alpha.crate | tar -tzvf -
                                                                                
                                                                                1. 2

                                                                                  Here’s a nix expression (that delegates to cargo): https://github.com/NixOS/nixpkgs/pull/102968

                                                                                  1. 1
                                                                                  1. 6

                                                                                    Gonna learn some Forth, because it seems very cool :)

                                                                                    1. 2

                                                                                      A great way to learn forth is to either implement a forth, or read through the implementation of a forth. Jones’ Forth is pretty good for this if you’re familiar with 32-bit x86 assembly.

                                                                                    1. 8

                                                                                      I did try out using dark-on-light a while ago, mostly because it allows me to have the brightness of my screen much lower while still being able to read text clearly without eye strain. However, I feel like “Light colour schemes are better, based on science” is really quite a stretch – the evidence for this is sparse and in as complicated a topic as human perception I’d want to see a big meta-analysis, or at least a decent number of papers finding similar results before making any conclusions. Though perhaps there is more evidence than they cited here.

                                                                                      1. 1

                                                                                        Working on an ordering website for a local food cooperative (at the moment they’re using google sheets), learning more about RISC-V and reading Programming Algorithms by Vsevolod Domkin! Also been learning Korean slowly but surely over the past month or so, I’ll be doing some of that too :)

                                                                                          1. 3

                                                                                            I’ve played around working like this with Git but I feel like this kind of workflow is so much better served by VCSs like Darcs and the more recent Pijul. You can often end up fixing a lot of trivial conflicts when doing things like reordering commits due to their snapshot nature in Git.

                                                                                            1. 37

                                                                                              How do i stop the cube from spinning

                                                                                              no

                                                                                              the best part in my book

                                                                                              1. 4

                                                                                                My favourite is the how do I exit vim issue :)

                                                                                                1. 5

                                                                                                  My favorite is the “vim³ isn’t for quitters” response to that issue

                                                                                                2. 4

                                                                                                  That had me giggling as well

                                                                                                  1. 7

                                                                                                    Reminds me of one of my favorite FAQ items a grabbed from some README, long ago:

                                                                                                    Q: Why is it written in Mono/C#?

                                                                                                    A: Because I hate freedom.

                                                                                                    1. 5

                                                                                                      I think my favourite comes from the zlib FAQ:

                                                                                                      Can you please sign these lengthy legal documents and fax them back to us so that we can use your software in our product?

                                                                                                      No. Go away. Shoo.

                                                                                                      1. 3