1. 1

    I encountered this issue when Qt switched to using getrandom() by default. A simple upgrade to a newer version of Qt, and suddenly this small embedded device would hang on boot. It turned out that Qt’s text streaming file IO operators were using QHash (Qt’s hash table) under the hood, which needs some random data to initialize itself.

    The decisions (Using their own hash table internally, QHash using a secure algorithm, defaulting to a proper source of random data) make some sense, but it struck me as slightly absurd that as a result it needed a good source of random data to be able to read a text file.

    1. 3

      Someone correct me if I’m wrong but it seems that in the absence of a hardware RNG, getrandom() can never be expected to work well. Collecting randomness based on interrupts is never guaranteed to unblock in any sort of reasonable time. Also it’s just a software heuristic that may not even meet the application’s criteria for randomness. Soap box here, but IMO ideally getrandom() should return EINVAL simply in the absence of a reliable hardware RNG and user-space can then take that as a signal to employ their own heuristics.

      1. 2

        I believe you can employ two tricks to achieve sufficient entropy in the situation where you do not have a hardware RNG:

        1. You can save the entropy pool at shutdown and restore it at boot.
        2. For the first boot of a device, I think you can pre-seed it with entropy from somewhere else.
        1. 1

          I think in a case where user-space seeded the kernel with randomness like that, I would support that also being a situation where getrandom() didn’t return EINVAL. At the same time, it may not even be necessary for the kernel to be involved unless it needed randomness itself (which I guess it often does).

        2. 1

          I hit this problem with a custom GCE image, for whatever reason they sometimes gave me a VM without rng. I had to send some extra randomness encrypted with the boot metadata.

        1. 5

          Do folks using ligatures not incur the cognitive cost of wondering what two (or more) keys were pressed to create a given ligature? Especially when reading other peoples’ code. This is a nice customizable font, but I’m set in my ways w/ source code pro.

          1. 5

            Iosevka has the term variant for people who don’t want ligatures.

            Agree on Source Code Pro, an amazing font.

            1. 4

              Not really–the ligatures are just stylized combinations of the keys in most cases. >=, <=, !=, and == all become one syntactic element when reading, and in practice I have no trouble typing them. And they are especially nice in closures and lambdas.

              1. 1

                As an Emacs user, it sounds like everything prettify-symbols-mode does. Is there any real benefit, giving that one seems to give up dynamic reprogrammability, that ligatures have to offer?

                1. 2

                  For reference, vim has something similar called conceal that people use for rendering latex in unicode and so on.

                  1. 2

                    I haven’t used prettify-symbols-mode specifically, so this may not apply, but when I tried similar things in the past, the problem was that it was generally replacing two or three characters with one character, meaning that either it messed with alignment, or it had to try and do weird things like surrounding the symbol with two half-width spaces.

                    Personally, I use the Hasklig font, and find that the ligatures look good, but it’s also unobtrusive enough that I just set it as my terminal font (I use Konsole, which supports ligatures) and use it everywhere, rather than trying to only use it with certain files (When I’m using a GUI editor or IDE, I usually use Hasklig as my font there too).

                    1. 1

                      I hadn’t run across prettify-symbols-mode, thanks for mentioning it! I’ll take a look at it.

                      1. 1

                        giving that one seems to give up dynamic reprogrammability

                        Can you expand on this? As I understand it, nothing is changing in the actual textual content when using ligatures, so I’m not sure what you’re referring to.

                        Is it just in comparison to prettify-symbols-mode where you create your own mappings?

                        1. 2

                          My understanding is that you can’t (easily?) turn specific mappings or as you say add ones by manipulating a variable (i.e. dynamically reprogramming), but it’s kind of “set” in the font.

                          1. 2

                            Ah, I see, thank you.

                            I had never considered changing ligature mappings dynamically, though the fact that this release has different ligature sets for different languages presents a usecase I hadn’t thought of before.

                            I wonder if doing these mappings in opentype rendering vs in the “editorspace” so to speak would make a difference performance-wise, sort of like what’s happened recently with bringing linum-mode into C.

                      2. 1

                        But what if say you’re reading some code in OCaml with <> or Fortran with .NE. and /= While those would probably not be ligatured, if they were it could be super confusing. I agree that there’s a certain elegance to the look, the ergonomics of not knowing what was typed to create something means you could conceivably half erase something and not know how to retype it.

                      3. 1

                        Ligatures in code listings sound like a nightmare to me.

                        Is it just a display thing? I.e. my code has “>=” while I see ‘≥’ in the editor? [1]

                        1. 2

                          That’s right. In editors like Sublime or VSCode, you can turn off ligatures if you don’t like them; in the case of Iosevka, you can also download a version that does not have ligatures (the term variant).

                          1. 2

                            Yeah it’s just that, your code still lives on disk as >= but the font does a ligature like it might do with fine or flare (the fi and fl merging) in a wysiwyg word processor. The difference is fine and flare still preserve the 2 characters visually, many of these ligatures toss them completely and sometimes go from 2 fixed width chars to 1 which makes alignment a bit strange as well. Though in some cases it could be much nicer.

                        1. 2

                          Newer languages are not more likely to have CRs

                          This surprised me. The median age of a language with a CR is 24 (1995)

                          Looking at the table, it is worth noting that in many cases the “appeared” date used is the date the language appeared, not the date at which the package manager appeared. For example, javascript is listed as appearing in 1995, but the npm package manager which the stats refer to didn’t appear until 2010 (according to wikipedia). It would be interesting to have a plot with the year the package manager appeared instead of the year the language appeared.

                          Also, I’d prefer if the y-axis scale was kept logarithmic, but labelled with numbers of packages, not log of number of packages.

                          1. 5

                            I just started using Python in earnest this year and I was constantly infuriated by examples and modules that were Python 2 but had no indication until you started using them. Over and over I’d find a neat module that did exactly what I wanted but then I’d find out it was Python 2. Absolutely maddening.

                            1. 1

                              Can you give some examples? I found that years ago there was a lot of this, but many libraries I use now are Python3-only, and many of them even explicitly Python3.6+ (probably to use f-strings).

                              1. 1

                                These were very hardware-oriented modules for doing robotic related things. The primary one that I needed was an interface for iRobot’s open platform: https://github.com/pomeroyb/Create2Control. I gave up and made two separate scripts because I needed Bluetooth from Python 3 libraries.

                                1. 2

                                  I’ve had a very similar experience with various Raspberry Pi hardware add-ons. The vendors typically provide a python library to interface with the hardware, but it’s often not updated after it’s released. Try to build something with 2 or more bits of hardware and you find a horrible mess of mismatched python versions and mismatched dependency versions. Worst of all, you don’t find out until runtime whether two versions are incompatible.

                              2. 1

                                This year? I’m not disputing your experience, but that’s surprising to me since the the community as a whole has been firmly on Python 3 for years now. http://py3readiness.org/ is all green, etc.

                                1. 3

                                  These were very hardware-oriented modules for doing robotic related things.

                                  1. 2

                                    I for one am not surprised. The long tail is pretty long still. We’ll be dealing with infrequently maintained domain specific Py2 codebases and docs for many years to come.

                                    1. 1

                                      I wish I’d known about the “Can I Use Python 3?” tool that is on the page @kbd linked to. That would have saved me some frustrating moments. https://github.com/brettcannon/caniusepython3

                              1. 2

                                I thought it would all be worse, but it really doesn’t matter - I don’t need to look at what I’m typing as I type it, only after it’s been written, as to proofread.

                                1. 2

                                  I think it makes a massive difference whether you’re typing lots of text (and don’t really need the feedback from the screen), or editing, where you need to move the cursor about and wait for the feedback that the cursor is in the correct position (There may be exceptions, e.g. if you’re familiar with an editor like vim, you can type a sequence of commands with the confidence that it will move to the desired position and perform the required edit. However, a single mistake can completely alter the whole sequence of commands).

                                  1. 0

                                    Even when editing I know what I should be typing before I type it; else it’s extra work for no reason.

                                1. 25

                                  With respect to email, don’t forget that pull requests were once intimidating too - as anyone who frequently works with onboarding new developers to its workflow can attest. To help make onboarding users with email easier, I wrote this tutorial:

                                  https://git-send-email.io

                                  I also wrote a rebase guide which applies to both workflows for making your changes more consistent and easier to review:

                                  https://git-rebase.io

                                  1. 26

                                    https://git-send-email.io

                                    That nicely outlines how to send patches, but I think people have far more difficulty receiving patches via email. Not everyone uses mutt, aerc, or runs a patchwork instance. Many mail clients, that people are otherwise generally fairly happy using, are just super not great at handling emailed patches. Emailed patches also generally don’t show a CI status that you can view ahead of time (I have heard of some, but I don’t ever remember seeing it firsthand in the wild).

                                    It’s great that it (an email patch workflow) works well with your workflows and tooling, but for some people it just… doesn’t work as well.

                                    1. 4

                                      I mean, those people who don’t have such a mail client are missing out. It’s like arguing that we should use SVN because not everyone has git installed, in my opinion. And testing your patches against SourceHut CI is pretty easy, before or after it’s sent.

                                      1. 26

                                        I think one issue is that for most of us, sending and receiving patches is a very small part of what we do with email, so choosing a mail client on that basis doesn’t make sense.

                                        1. 1

                                          But we aren’t forced to use only one mail client. I use several depending on context / the task at hand.

                                          1. 1

                                            I am curious about your multiclient workflow. Do you use multiple addresses, or use filters and one shared address? Or just all the mail in all of them?

                                            1. 4

                                              Whether you use local maildir or imap, mail stores are designed for concurrent access. How many people check email on their phone and not their phone?

                                              1. 1

                                                Sure, but my question was specifically about their workflow with it.

                                              2. 2

                                                As it happens I do use multiple accounts for multiple “hats”, but that’s slightly orthogonal to multiple clients, which I use even for a single account. My daily driver is mutt; I use thunderbird for rare occasions when I need to see rendered html properly or perform a search (still haven’t got mairix or not much etc set up) and I often use ios mail app but mostly read only.

                                                At work we use Gmail. I do check that from ios mail app too. I recently started configuring mutt to read my work mail too but it’s a work in progress so I still regularly open the Gmail website.

                                          2. 23

                                            I mean, those people who don’t have such a mail client are missing out. It’s like arguing that we should use SVN because not everyone has git installed, in my opinion.

                                            To me it sounds a bit more like arguing “anyone who doesn’t ride a penny-farthing to work every day is totally missing out”.
                                            Well…maybe.. I do find it unlikely that is going to convince very many people who weren’t already riding them, or weren’t already inclined to do so. Even if it is amazing.

                                            Sidenote1: I may be wrong, but it even appears that Mutt itself uses gitlab instead of email based patches. If true, I find that oddly humorous.

                                            Sidenote2: I have nothing against email based patch flows, and if I am going to contribute to a project, I generally contribute in whatever form a project requires (within reason). But for my own projects, I do not desire an emailed patches based workflow (EPBW), nor do I desire to run/manage/admin/moderate(remove spam) a mailing list. That’s just me though.

                                            1. 7

                                              To me it sounds a bit more like arguing “anyone who doesn’t ride a penny-farthing to work every day is totally missing out”.

                                              I don’t really like this take. Having sunk thousands of hours into the GitHub, Gerrit, and email-driven workflows, I can confidently assert that the email-driven workflow, even setting aside the many respects in which it is politically and technically superior, is simply the most efficient for both contributors and maintainers. The penny farthing comparison is unfair.

                                              Sidenote1: I may be wrong, but it even appears that Mutt itself uses gitlab instead of email based patches. If true, I find the humorous.

                                              Mutt uses Gitlab and mailing lists and Sourcehut, actually. The dominant avenue of contributions to mutt is through its hosted mailing list. They use Sourcehut CI, however.

                                              Sidenote2: I have nothing against email based patch flows, and if I am going to contribute to a project, I generally contribute in whatever form a project requires (within reason). But for my own projects, I do not desire an emailed patches based workflow (EPBW), nor do I desire to run/manage/admin/moderate(remove spam) a mailing list. That’s just me though.

                                              That’s why Sourcehut can do it for you.

                                              1. 9

                                                I don’t really like this take. Having sunk thousands of hours into the GitHub, Gerrit, and email-driven workflows, I can confidently assert that the email-driven workflow, even setting aside the many respects in which it is politically and technically superior, is simply the most efficient for both contributors and maintainers. The penny farthing comparison is unfair.

                                                A bit of an “Ipse dixit”, but I’ll take it at face value anyway. To be clear, my comment was in response to your statement:

                                                I mean, those people who don’t have such a mail client are missing out.

                                                Which is what I made the comparison against. You have now pulled in other concerns in your response, and attributed them to the comment I made. I find that a bit uncharitable. I guess at this point we can just agree to disagree.

                                                Mutt uses Gitlab and mailing lists and Sourcehut, actually. The dominant avenue of contributions to mutt is through its hosted mailing list. They use Sourcehut CI, however.

                                                That’s odd. I looked through the last 2 months of their mutt-dev mailing list, and saw no mailed patches, but several gitlab PRs. Maybe I saw the wrong mailing list? Maybe I didn’t go back far enough? Overlooked it?
                                                It doesn’t really matter, and I’ll take your word for it that they predominantly use emailed patches.

                                                1. 2

                                                  The last 2 months have only seen one patch on Gitlab:

                                                  https://gitlab.com/muttmua/mutt/merge_requests?scope=all&utf8=%E2%9C%93&state=merged

                                                  After reviewing it myself I have to correct myself, I reckon that Gitlab and the mailing lists are at about an even pace these days.

                                                  1. 2

                                                    Do note: that was merged PRs. There were a couple of more (not many though!) in All which is what I looked at.

                                            2. 5

                                              Not everyone is productive using such mail client. Personally, I just plainly cannot remember more than a few shortcuts, which is already a massive roadblock for effectively using CLI tools as for most of them rely on shortcuts to increase productivity, they also do not provide me with options of what I can do, and I cannot for my life remember what can I do for all the possible contexts, cause of course options on what you can do are dependent on the context which you are currently in. Some people just aren’t productive using CLI tools, and saying that they “are missing out” because they plainly cannot effectively use the tool is simply gatekeeping.

                                              1. 3

                                                saying that they “are missing out” because they plainly cannot effectively use the tool is simply gatekeeping.

                                                This is absurd. If a mechanic decides that he “is not a ratchet person” and will only ever use open-end wrenches, then I will question his professionalism just as I would question a software developer that “is not a CLI person” and will not learn to use a CLI mail client.

                                                He doesn’t need to use the CLI mail client for his day-to-day email, but he should be capable of learning how to use it to handle the occasional emailed patches.

                                                1. 5

                                                  Or this person will work with whatever, when paid for (professionals are paid for their work by definition!), but will only work with tools he/she finds enjoyable when doing charity. Thus FLOSS projects forcing inconvenient, last century methods with arrogant communication are missing contribution.

                                                  I thing the FLOSS community should focus on this kind of openness more, instead of CoCs.

                                                  1. 3

                                                    Good point. For work I’ll use whatever tools get the job done, no matter how gruesome. But for FOSS contributions, I agree that if the tool is difficult or simply frustrating to use, then it may as well not exist.

                                                  2. 1

                                                    Wrong assumption. Difference between using GUI and CLI clients is not like between open-end and ratcheted wrenches. Using those wrenches is basically the same. Meanwhile the experience between using CLI and GUI mail client is a lot bigger. I’d compare it to using automatic and manual wood planes. You can work with higher precision and similar speed with manual hand plane, but most carpenters would choose automatic hand plane, as it “just works” and doesn’t require that much skill and learning to do.

                                                    And why should you care what kind of wrench does your car mechanic uses, if he does the job well? This isn’t a problem not using better tools, but a problem of tool abilities. The tools that an average developer uses does not represent the tools that are created for that workflow. And that is a problem.

                                                    1. 2

                                                      I’ll entertain the analogy to a wood plane, though I’m unfamiliar with the devices. You say it yourself: the manual wood plane is useful in certain circumstances but requires skill. So does the CLI mail client. Use the automatic wood plane where it fits, but at least learn the skill to use the manual wood plane where the higher precision is necessary.

                                                      A developer that refuses to acquire a skill is simply not professional.

                                                      1. 1

                                                        It’s not like it requires much skill. It is the basically the same skill. The difference is, you need to move the manual wood plane along the plank 10 times, while with automatic you only need to move it once and the motor does its job. Some people just don’t have the patience and/or physical stamina to use manual wood plane. Manual hand plane is in fact more configurable, and can be used in more specialized scenarios. So enthusiasts use hand planes. Your average carpenter does not.

                                                        1. 2

                                                          The analogy was not mine.

                                                  3. 0

                                                    Consider acme?

                                                    1. 2

                                                      I am unable to find such email client. And the point is, for a workflow to be usable by a wide range of people, it should require as little new tools that do the same as the ones they use. And in case of email clients, most people probably like their current email client, and they do not want to change it. So they, in turn, do not want to switch to this new workflow, which, while potentially increases productivity, requires them to switch to tools they do not like.

                                                      1. 4

                                                        acme is a text editor which can be easily coaxed into being a mail client.

                                                        Consider as well that you needn’t discard your daily mail client in order to adopt another. What difference does it make if some technology is backed by email or by some other protocol? Just because you already have an HTTP client (e.g. your web browser) doesn’t mean another isn’t useful (e.g. curl).

                                                        1. 7

                                                          Acme does not seem like general user friendly. My colleagues all use JetBrains IDE’s and use Thunderbird as their mail client. And acme would be a downgrade for their experience. I might use it, but they wouldn’t. If I cannot offer them a good GUI email interface, there is no way they would switch to email-based workflow.

                                                          1. 0

                                                            I was recommending acme particularly for you, given the following:

                                                            I just plainly cannot remember more than a few shortcuts

                                                            If your colleagues won’t join you I consider your colleagues to be in the wrong, not the software. A bicycle is easier to use than a car but it’s not going to get you to the other end of town in time for the movie.

                                                            1. 14

                                                              If your colleagues won’t join you I consider your colleagues to be in the wrong, not the software.

                                                              Don’t you think peace within a team is more important than any particular software or workflow? Or, to put it another way, the feelings of people are more important than any workflow, so if a large group of people reject a workflow, it’s better to conclude that the workflow is wrong for those people than to say that those people are wrong.

                                                              1. 7

                                                                My colleagues wouldn’t join me because the workflow is bad, but because there is no tooling suitable for them and the workflow. If tooling for a specific workflow just isn’t comfortable for me, I’m just not going to use it.

                                                                1. -8

                                                                  Then you ought to be coding in basic. Good things often require effort.

                                                                  Edit: this comment seems to be being misinterpreted, so a clarification: I’m not earnestly suggesting that he should use basic. I’m extending his logic to an incorrect conclusion to demonstrate the flaw in his argument. Most languages are harder than Basic, therefore Basic is more comfortable, therefore why ever learn anything else? Obviously it doesn’t make sense.

                                                                  1. 18

                                                                    You are literally making the exact same argument that @ignaloidas’ colleagues are. The only difference is that the tooling you find suitable and the tooling they find suitable is a null set. They want to be in JetBrains’ IDEs, you want to be in email. You built tooling that demands email-based workflow because it’s what you want and then tell them they have to change; they’ve got tooling that demands GitHub (or a workalike) and then tell their colleagues that they have to change.

                                                                    As an aside, I pay for and generally enjoy using Sourcehut, and I respect your diehard allegiance to email, but you’ve got to quit acting like this in the threads. I get that you love an email-based workflow, and find it superior for your use cases. Having used Git and Mercurial since, what, early 2006 I guess—certainly before GitHub and Bitbucket existed—I disagree (especially when your workflow starts to involve binary assets, so most websites, games, mobile apps, and so on), but I’m also comfy in that workflow, and happy to support an SCM that fully supports that flow. But if you insist that people who do not use your workflow are wrong, and do so in this offensive manner, you’re going to start losing customers.

                                                                    And as an aside to that aside, you need to do what you want with Sourcehut, but the fighting against this on principles to me, as a former SCM lead, looks a bit forced: looking at this whole thread, and thinking back to a very early comment, all you’d have to do to satisfy him is to make temporary branch names that can be pulled in some mechanism based on the patch series. That’s it. It’s not trivial, but it’s also not that difficult, since you’re already doing 90% of that with the patch view. If you don’t want to do it, that’s fine, but it seems like that’d still mandate patch-accessible workflows, while also meeting the PR crowd a bit.

                                                                    1. 2

                                                                      Note about the JetBrains’ IDEs. It’s not like they are incompatible with with email driven workflow, they just have tools that are better suited for pull-request workflow. I gave JetBrains IDEs as an example of what an “average” developer as I know it uses from day to day, as it seems that many bloggers have a distorted view of “average” developer. Average developer actually doesn’t want to fiddle with settings and try 10 different variants before deciding to use one. They want tools that “just work” without massive setup. Average carpenter wants a table saw that simply does the job they want to, they do not fiddle around it to make it the best saw for them.

                                                                    2. 14

                                                                      Hi this is not a very nice tone, please try to argue in good faith.

                                                                      1. 13

                                                                        Is insulting prospective customers really the best way to grow your business?

                                                                        1. 0

                                                                          That was no insult, it was a logical extension of his logic. I didn’t mean it sincerely, I was using it to explain his error.

                                                                        2. 2

                                                                          Ok, in simpler terms. I would probably still use an SUV instead of Smart even if Smart can go through some shorter paths, because I feel cramped when driving it. Same with software. Some software is in fact more useful than other, but is harder/inconvenient to use for some than software which doesn’t have those fancy features.

                                                                          1. -5

                                                                            This isn’t such a case. This is a case where you (or your colleagues, I’m not sure at this point) are refusing to try unfamiliar things and, being ignorant of the experience, asserting it’s worse.

                                                                            1. 3

                                                                              It is. The thing is, I have tried mutt and aerc, and the problem is that I just plainly am not comfortable using bigger CLI programs, that is, those, whose scope goes out of pipes and command line rguments. About the only programs that of such style that I can use is nano and htop, only because they have a handy shortcut guide in the bottom at all times. Acme is also not the kind of editor I would like to use casually. It is easy to blame the people that don’t use it, without understanding the reasons why they don’t use it.

                                                                              1. 0

                                                                                You didn’t know anything of acme not even 2 hours ago. You’ve evaluated it in that time?

                                                                                Herein lies my point. I have a vision and I must at some point exercise my creative authority over the project to secure that vision. Yes, it’s different from what you’re used to. You can construct reasons to excuse this away, but I fundamentally believe that being unwilling to learn something new is the underlying problem. As evidence, I submit that there’s no way you could have given acme a fair evaluation since my suggestion of it. I don’t consider this sort of behavior acceptable cause for changing my system’s design to accomodate.

                                                                                1. 12

                                                                                  As someone who used Acme for two years, @ignaloidas does not sound like someone for whom Acme would even be worth trying. It’s great, but incredibly dependent on how you want to use your editor. You can’t disable word wrap, or use any shortcut to move the cursor down a column, for Christ’s sake. It’s really not for everybody (perhaps not even most people).

                                                                2. 2

                                                                  So they, in turn, do not want to switch to this new workflow, which, while potentially increases productivity, requires them to switch to tools they do not like.

                                                                  What happened to using the right tool for the job?

                                                                  1. 1

                                                                    The question here is not about “the right tool for the job” but about the usability of those tools for the wider audience. Currently I do not see the majority of the developers switching to email-based workflow purely because of the usability of tools. “Rockstar developers” think that CLI’s are very usable and productive, but that is not the case for the average programmer.

                                                                    1. 3

                                                                      “Rockstar developers” think that CLI’s are very usable and productive, but that is not the case for the average programmer.

                                                                      Good to know that we were all rockstars for decades without realizing it!

                                                                      This is probably just an age thing but I don’t know any professional programmers who aren’t comfortable with CLIs.

                                                                      1. 3

                                                                        There is CLI, and there is CLI application. Git is used through CLI. Vim is a CLI application. Surely you know at least one professional programmer that isn’t comfortable with Vim and alike.

                                                            2. 3

                                                              I am not particularly experienced at using git with email. One problem I have had in the past is when I want to pull in a patchset from a mailinglist archive, where either I am not subscribed to the mailinglist, or wasn’t subscribed at the time when the patches were sent. Can these mail clients help me with this problem? (By contrast, I find it very easy to add a branch / PR as a remote and pull or cherry-pick commits that way)

                                                              1. 3

                                                                lists.sr.ht, the sourcehut web archive for mailing lists, has a little copy+paste command line thing you can use to import any patch (or patchset) into your local git repo. Here’s an example:

                                                                https://lists.sr.ht/~sircmpwn/aerc/patches/7471

                                                                On the right, expand the “how do I use this” box and a short command is given there.

                                                                Integration directly with your mail client would require more development but isn’t necessarily out of the question.

                                                                1. 3

                                                                  That’s good to see, but presumably doesn’t help for non-sourcehut mailinglists?

                                                                  1. 3

                                                                    No, I’m afraid that there are fewer good solutions for non-sourcehut mailing lists. Patchworks has a similar feature, if the list in question has that set up. You could also ask someone else for a copy of the mail. I don’t think this damns the idea, it just shows that we need better software to support the idea - which is what sourcehut tries to be.

                                                          2. 2

                                                            I am still trying to find some time to check out Sourcehut. My only concern is how to configure it to run CI builds on mailing list patches as I couldn’t find it anywhere in the docs.

                                                            1. 1

                                                              This hasn’t been implemented yet, but it will be soon.

                                                              1. 1

                                                                Great. If that happens I will think about migrating some of my personal projects to the Sourcehut as it seems pretty as a pretty nice solution.

                                                          1. 5

                                                            I think the issue is that SV is driving a certain level of pay. But as remote work becomes more and more accepted companies outside of SV are having to compete at wages that are close to SV prices. I live in a medium sized urban American city and our tech wages used to be some of the lowest in the country. Like 40-50k a year. Due to the acceptance of remote work I was able to force a local company to pay me a wage in the mid six figures because I could point to remote wages and say I can get a remote job making x living here why would I work for you for less? So now I’m in the top 0.5% of my states wages because I used the remote market to drive a much higher wage.

                                                            1. 2

                                                              I’m a little surprised that the Silicon Valley companies are offering the same or similar (Is this what you’re implying?) wages for remote work as on-site: I would expect them to offer a lower wage on the basis that you don’t need to cover the cost of living in Silicon Valley (while still offering a little more than any company local to you).

                                                              1. 2

                                                                The wage they offer you is based on what you can convince them you are worth to someone. If you’re a senior engineer and want to work remote, get multiple offers, find a company willing to pay Bay Area compensation for remote work. The other companies then have to compete with that.

                                                                I know of several remote engineers who have that arrangement.

                                                                1. 1

                                                                  I’ve seen a few friends get offers in the mid to upper 100k’s from SV companies. I was first offered below 100k at my current job and the pressure of those remote salaries allowed me to push for a significantly higher rate then they would have offered me otherwise.

                                                              1. 3

                                                                This looks pretty great! Moving to CMake seems like the smart move, and I’m super psyched at their continued level of investment in Python.

                                                                Kinda sad about their intent to move away from OpenGL and to Vulcan, Metal and Direct3D though. I guess the idea of one 3D graphics API to rule them all is dead?

                                                                1. 4

                                                                  Apple claims that they’re going to remove opengl support from MacOS at some unknown point in the future, Qt is just preparing for that I guess.

                                                                  1. 4

                                                                    Apple is super annoying these days :) (I mean, I know they always have been, but lately I feel like they’ve turned it to 11, or maybe just in areas I care about!)

                                                                    I wonder if Vulcan is a possibility on OSX. Betcha it will be once all the game studios start writing for Google Stadia (Ungh.)

                                                                    1. 10

                                                                      There is moltenvk, which implements (a subset of) vulkan on top of metal.

                                                                      1. 8

                                                                        And gfx-portability too.

                                                                  2. 2

                                                                    My understanding is that OpenGL is a pain to use in general, not just cuz of driver stuff but that the API itself is not something that (notably) game developers enjoy using.

                                                                    So there aren’t too many people going to bat for OpenGL

                                                                    1. 1

                                                                      I thought that Vulcan is supposed to be the new “one 3D graphics API to rule them all”?

                                                                      1. 3

                                                                        Not without Apple’s buy-in it won’t be.

                                                                      2. 1

                                                                        Moving to CMake seems like the smart move

                                                                        I’m a little disappointed that they’re dumping QBS development on the “community”. My impression is they went straight from “Technology preview” to “We’re not going to continue developing QBS because noone’s using it” without any sort of “QBS is ready now, please try it” announcement.

                                                                        1. 1

                                                                          Aren’t you supposed to be able to throw away prototypes?

                                                                          1. 1

                                                                            Absolutely, but not with the justification that customers weren’t using them.

                                                                            Edit: “details” can be found in this mailing list thread if you’re interested: https://lists.qt-project.org/pipermail/development/2018-October/thread.html#34023

                                                                      1. 8

                                                                        Wow, that is a very unusual introduction to Haskell — going straight into imperative programs (everything’s a do!) and concurrency. And then it just…stops!

                                                                        1. 6

                                                                          It’s a phrasebook. It gives a way to do something in a language you don’t really know.

                                                                          It isn’t idiomatic, it’s just getting you to have something to show for it as quickly as possible.

                                                                          1. 6

                                                                            It’s a work in progress:

                                                                            We have launched the Phrasebook with 14 demonstrations of topics ranging from if-then-else expressions to transactional concurrency, and there is a lot more to come.

                                                                            1. 2

                                                                              In… a good way? Bad way?

                                                                              1. 5

                                                                                I don’t know! Well, it’s not good that it just stops. But I wonder what a Haskell book would be like that started with the imperative and concurrent stuff like “normal” languages have, and ended with the higher-order functions and so on, instead of the other way around, as a Haskell book normally does.

                                                                                Like, you would start off thinking it was like Go or something, just with weird syntax. You’d get sucked in that way, but then things would start getting more abstract and powerful, and by the end you’d be using pure functions and GADTs and free monads before you knew what hit you.

                                                                                1. 3

                                                                                  Like, you would start off thinking it was like Go or something, just with weird syntax. You’d get sucked in that way, but then things would start getting more abstract and powerful, and by the end you’d be using pure functions and GADTs and free monads before you knew what hit you.

                                                                                  I suspect you might give up, thinking, “what’s the point of this weirdness” before you got to any real motivation or reason to keep learning.

                                                                                2. 4

                                                                                  I like it. And I am waiting for it to provide more examples. I went through several books, still reading and still trying to learn. But did already write programs that I am using for my work and that are helpful for me. Still mostly reaching out for shell scripting, because the shell scripts naturally grow by combining commands and I wish I would use some Haskell Shell in which I would do my daily stuff and that would easily allow me at some point to put together the Haskell programs.

                                                                                  I like how they are showing ghcid early (how long did it take me to find settle on ghcid, how many editor/IDE tools did I try), and I like that ghci is introduced. It’s pragmatic.

                                                                                  I hope it will go on with many examples.

                                                                                  1. 0

                                                                                    In… a good way? Bad way?

                                                                                    Definitely a bad way.

                                                                                    All the weirdness and higher order stuff is there to give you all kinds of guarantees which can be extremely useful.

                                                                                    In fact: If you are not using the higher-order stuff, you might just as well use another language which requires you to jump though less hoops, because you are missing the whole point of what Haskell is about.

                                                                                    You should start with the higher-order stuff and then bolt this phrasebook on as an afterthought, not the other way around. If you start with this phrasebook, you will essentially be writing a bad code base.

                                                                                    Please keep in mind that I have actually reviewed assignments from a “Functional Programming” course, which used Haskell as it’s primary subject of study.

                                                                                    1. 9

                                                                                      You are gate-keeping, and this behaviour is definitely worse for the community.

                                                                                      I’m one of those developers who had no computer science education, and started programming essentially by banging rocks together, trying to pay the bills with WordPress and jQuery.

                                                                                      I learned Haskell the trial-and-error way, and the imperative way. My first foray into Haskell was from the book Seven Languages in Seven Weeks, which necessarily doesn’t go very deep into the languages it exhibits. I got some of the basics there, but otherwise trial-and-error, Google, IRC, etc. My first web apps in Haskell were pretty terrible, but I needed to just get something working for me to be more invested in the technology. Everyone sucks at something before they’re good at it anyway. There’s still an enormous amount of Haskell for me to learn. I see that as compelling, not a hurdle.

                                                                                      This has not “destroyed my reputation”, as you asserted. If anything it’s only improved it, especially among people who are interested in Haskell but are discouraged by people like you.

                                                                                      Now I run three businesses on Haskell, and employ other Haskellers who have worked at Haskell companies you have heard of.

                                                                                      1. -1

                                                                                        Do you have an argument that is not based on anecdotal evidence?

                                                                                        If so, then I am interested. If not, then my own experience (and the experience of those before me) of what has been seen in the trenches of teaching people things applies. That experience can be summarized into the following statement: “Bad examples tend to stick around until they’ve become the norm”.

                                                                                        This phrasebook is one of those “bad examples”. It’s perfectly fine to use it after you have some basic understanding of types, lazy evaluation, recursion, pattern-matching, folds, foldable data structures and monads. But please, make the upfront investment. Otherwise you are fooling yourself into thinking you are competent, while you really aren’t.

                                                                                        This has nothing to do with gate-keeping. It’s about putting a big warning sign in front of a minefield and my posts should be read as such. Please remember that most people who enter a minefield come out unscathed.

                                                                                        1. 6

                                                                                          Do you have an argument that is not based on anecdotal evidence?

                                                                                          You know that I don’t, and I also know that you don’t either. There’s a logical fallacy in your opening statement, but I can’t pick exactly which it is.

                                                                                          Bad examples tend to stick around until they’ve become the norm

                                                                                          This to me sounds like you are afraid the unwashed masses will begin to congregate in your cool-kids-only programmer club.

                                                                                          My outlook is less pessimistic — I believe if someone is curious enough to be interested in how Haskell works, they’ll also be interested in continuing their learning and not just hacking things together poorly. Building software better is the primary motivator for many people adopting Haskell.

                                                                                          It’s about putting a big warning sign in front of a minefield and my posts should be read as such. Please remember that most people who enter a minefield come out unscathed.

                                                                                          For a supposed educator, your analogies are suspiciously shaky. In what way is a buggy web application akin to a literal minefield — the potential for improper traversal of which is loss of life and limb?

                                                                                          Spoiler Alert: It isn’t.

                                                                                          1. -1

                                                                                            This to me sounds like you are afraid the unwashed masses will begin to congregate in your cool-kids-only programmer club.

                                                                                            Not at all.

                                                                                            What I am afraid of is that the ecosystem will go the same way as python’s or npm’s went, because the people using it do not have the required skills or knowledge. There is a reason why we explicitly forbid anyone who did not pass the bar-exam from practicing medicine or law without supervision. It’s because they do not only hurt themselves or their patients/clients when they deliver shoddy work. They hurt their peers too! The same logic applies here.

                                                                                            In what way is a buggy web application akin to a literal minefield — the potential for improper traversal of which is loss of life and limb?

                                                                                            Spoiler Alert: It isn’t.

                                                                                            My path of reasoning:

                                                                                            1. Codebases written in this fashion cause unnecessary stress in developers.
                                                                                            2. Stress accelerates burnouts.
                                                                                            3. Burn-outs of programmers are one of the main reasons they become unfit for or unable to work.
                                                                                            4. Some of them never recover.
                                                                                            5. If your whole livelihood is gone and you’ve accumulated psychological problems because of the profession you once loved, that’s just about as problematic as losing a limb in my opinion.

                                                                                            I’ve seen it happen nearby and in fact Lobste.rs has seen it happen too. In that regard it is akin to loss of life and limb.

                                                                                            1. 6

                                                                                              I think you’re being a bit melodramatic with this comparison to the loss of life. Beginners will write beginner code and that’s okay. Sometimes the best training is experience; the language will teach them how to use it better. And with more experience – considering one of Haskell’s biggest strengths is how easy it is to refactor – developers will be able to rewrite their old, inefficient code without issue.

                                                                                              The ecosystem is not in any danger. The tooling is solid as a rock. The community is really helpful (if you ignore the gatekeepers). In fact, I think having to pass some kind of theory exam before you’re allowed to write any code would kill off the ecosystem pretty quickly.

                                                                                              Anyway. Just let people learn Haskell how they want to. If that means following this guide and learning the syntax and other superficial basics in a dialect of programming they’re already comfortable with, so be it. Monads can come later.

                                                                                      2. 6

                                                                                        you will essentially be writing a bad code base.

                                                                                        But you WILL be writing a code base.

                                                                                        1. 1

                                                                                          But you WILL be writing a code base.

                                                                                          You will be writing a codebase that will force the next competent Haskell developer, to throw out all your work and start over. Also: It will destroy your reputation.

                                                                                          Honestly, it’s better to not write anything at all if this is your starting point. Just use something else like python, C/C++, Java or C#. This is simply not how Haskell should be written and I will probably also perform worse than the alternatives.

                                                                                          Why? Because if you use Haskell the right way, the compiler can throw in all kinds of optimizations, like lazy evaluation and memoization for free. If you are writing Haskell in the way that is proposed in the Phrasebook, you essentially loose all those perks without gaining anything. In fact your code will be much, much, (about a factor 10 actually) slower than it would be if you’d just started out by using a different language.

                                                                                          For an elaborate example, you can look at The evolution of a Haskell programmer. Note that the Juniors and the first Senior developer’s solutions are in fact perfectly valid and viable.

                                                                                          However, the second senior (which uses foldl) makes a critical mistake which costs him the “lazy evaluation perk”, which means that his best-case and worst-case performance are both O(n), whereas the senior that uses foldr will have O(1) as best case and O(n) as worst case performance.

                                                                                          And it goes downhill from there. However the Haskell code I see in the Phrasebook is similar to what the “Beginning graduate Haskell programmer” would do.

                                                                                          The “right” way to do it, is the “Tenured professor”-way all at the bottom. It doesn’t matter that product uses foldl’ internally in this case, which also sacrifices lazy evaluation. It’s about a way of doing things and in general, where you rely upon the implementation of libraries getting better. This phrasebook also throws a lot of those perks out by manually taking control over nearly the entire control flow (which is something you should do as little as possible when you are writing Haskell).

                                                                                          That is the kind of “bad codebase you would be writing” we are talking about here. If you find yourself in the situation where you need this phrasebook to get started, you are simply out of your league. The situation is really not unlike the software engineering team that programmed the flight computers of the 737 MAX 8. You should step away and say: “No, I am not up to this task right now. I need at least 120 hours (but 240 hours is a more reasonable estimate) of study before I can do this”.

                                                                                          But if you did invest the hours upfront and are using this Phrasebook as an afterthought… sure; Sure! Go ahead! You should now know where the pitfalls in these examples are.

                                                                                          1. 7

                                                                                            One of the authors of this Phrasebook is also an author of Haskell Programming from First Principles, which starts from the lambda calculus. I think she’s deliberately exploring as different an approach as possible. There’s isn’t a single Right way to teach, the readers’ varied backgrounds and motivations lead them to really different results.

                                                                                            1. 1

                                                                                              One of the authors of this Phrasebook is also an author of Haskell Programming from First Principles, which starts from the lambda calculus. I think she’s deliberately exploring as different an approach as possible. There’s isn’t a single Right way to teach, the readers’ varied backgrounds and motivations lead them to really different results.

                                                                                              The approach the author is taking now, is an approach which defeats the main purpose of Haskell: It’s type-system and a relatively smart compiler that exploits this through lazy evaluation. Because of this, I simply do not agree with this statement.

                                                                                              A pilot needs to learn at least some basic meteorology and aerodynamics, the same applies here, because if you don’t take the time to properly understand the type system and lazy evaluation, you are basically an unlicensed pilot that knows how to get an airplane off the ground, keep in in the air and land it again, but without any contact with air traffic control.

                                                                                              I would not want to fly with such a pilot, neither do I want to use an aircraft he/she has flown in. In reality we have systems in place to stop this from happening and the pilot will be told to stay on the ground and “pilot” something (like a car for example) he/she knows how to pilot. In the software world, we do not have a system, other than our own sound judgement, in place to prevent this from happening.

                                                                                              So please: Learn Haskell’s fundamentals first and then add this phrasebook to the mix afterwards or choose an entirely different technology. Everyone who is currently next to you or whom comes after you, will thank you for it.

                                                                                              1. 3

                                                                                                Hopefully Haskell can be many things to many people. I think it makes for a pretty good imperative language.

                                                                                            2. 6

                                                                                              I’m currently training a team of engineers to write Scala. We’re experiencing the “no code” problem right now. I prefer people write bad (but functional) code than no code.

                                                                                              1. 1

                                                                                                I’m currently training a team of engineers to write Scala. We’re experiencing the “no code” problem right now. I prefer people write bad (but functional) code than no code.

                                                                                                I would agree with you if this was about any other programming language, but Haskell really is a different beast in this regard.

                                                                                                I pose you this question: Would you rather spend some time training your engineers or would you rather have them dive in without them knowing what they are doing?

                                                                                                Since you are training a team, you’ve probably chosen the first approach, which is exactly what I am proposing you should do with Haskell as well. You do not hand a pilot the keys to an airplane without making sure they’ve had some proper training. The same applies here (see below). Most other programming languages are like cars or trucks, but Haskell really is more of an aircraft.

                                                                                                1. 8

                                                                                                  I think this type of elitist gate keeping dissuades people trying to learn Haskell and reflects poorly on the community. Furthermore the creators of the Haskell Phrasebook clearly know a lot about Haskell and have built a business around teaching it to people. Do you think it’s possible for them to have a compelling reason to create a resource like this?

                                                                                                  @argumatronic: I’ve seen people do similar with Haskell, starting with very imperative-style Haskell, but in the meantime: I can understand you, thank you for making effort to learn a new language, welcome.

                                                                                                  1. 0

                                                                                                    I think this type of elitist gate keeping dissuades people trying to learn Haskell and reflects poorly on the community.

                                                                                                    Actually I digress. There is nothing elitist about it. It’s about using a hammer to turn a screw in.

                                                                                                    Furthermore the creators of the Haskell Phrasebook clearly know a lot about Haskell and have built a business around teaching it to people.

                                                                                                    The fact that someone builds a business around something, doesn’t mean they are doing things the right way. Teaching people things the wrong way, has a tendency to stick around. Oh and btw, I also earned money teaching Haskell (and cryptography and security) to people during my studies at an accredited university with the oversight of a professor leading in the development of the language…. So I am no lightweight either…. And what I see here makes me cringe and would have awarded any student a non-passing grade with approval.

                                                                                                    Do you think it’s possible for them to have a compelling reason to create a resource like this?

                                                                                                    Yes I do. In fact, they state the same reason as I suspected on the Twitter feed you mention:

                                                                                                    IME, people start to write more Haskelly Haskell as they get comfortable with it, but we have the tools to write imperative-style Haskell as a bridge, no shame in using them.

                                                                                                    And:

                                                                                                    Eventually, by doing that a lot, I became quite fluent in Japanese. And I’ve seen people do similar with Haskell, starting with very imperative-style Haskell, but in the meantime: I can understand you, thank you for making effort to learn a new language, welcome.

                                                                                                    And like I said, there is nothing wrong with using the phrasebook, but you have to use it after you at least have a firm grasp op the basic concepts. Doing it the other way around will give the community and the language itself a bad name. If nothing else, the Haskell ecosystem will turn into a hack fest similar to python or nodejs with the decrease in quality and performance of everything that comes with it.

                                                                                                    That’s what I am worried about and it’s also why I disagree: You want people that write Haskell, to write it in a completely different way than you’d write an imperative language.

                                                                                    1. 1
                                                                                      • 2nd July, 2019: CVE-2019-13143 reserved
                                                                                      • No response from vendor
                                                                                      • 2nd August 2019: Public disclosure

                                                                                      So… This is essentially an invitation to start using the exploit in the wild?

                                                                                      1. 3

                                                                                        No? What about it reads that way to you?

                                                                                        1. 2

                                                                                          Nothing (and of course you don’t mean it that way), but I’m just not sure if it’s a good idea to disclose an exploit if it’s not fixed yet. At the same time, I’m not in security and I don’t know the common accepted practices. I was hoping that someone would patronizingly explain why it’s OK to do so in response to my deliberately provoking comment ;)

                                                                                          1. 8

                                                                                            I believe the general idea is that you give the vendor time to fix it before you disclose it publicly, but if the vendor does nothing at all, then it is better for the user to know about the vulnerability, so they can attempt to mitigate it (e.g. in this case by not using the ‘smart’ ‘lock’).

                                                                                            1. 5

                                                                                              u/Thra11 has answered this, but to add to that, public disclosure acts as a ditch effort to get the vendor to notice the issue and hopefully, address it. It’s a hard choice to make, especially when releasing exploits that could compromise thousands of user accounts. But at the same time, the users (at least a few) will learn of it and stop using the lock.

                                                                                              1. 3

                                                                                                There’s a good likelihood for any vulnerability that’s disclosed that there are people who already are aware of it and are presently exploiting it. Disclosure allows people to avoid being exploited and takes power away from those who hope to use it.

                                                                                          1. 9

                                                                                            I think the author misses a critical point about VPN providers and why some of us use them: You choose and control who could potentially snoop on you.

                                                                                            Would you rather trust coffee shop wifi or a provider whom you’ve researched, feel is “good enough” for your needs, and are in a customer/service provider relationship with? Do you trust your ISP to shield you from p2p nastygrams or do you trust a foreign vpn provider who has a track record of not caring?

                                                                                            Its about choice and trust. Trust isn’t all or nothing, you should know how much you trust your provider and with what.

                                                                                            1. 3

                                                                                              Would you rather trust coffee shop wifi or a provider whom you’ve researched

                                                                                              I trust my local coffee shop more than any tech company!

                                                                                              1. 1

                                                                                                But, do you trust people accessed your local coffee shop network?

                                                                                                1. 1

                                                                                                  It was a joke, but yeah, that’s what SSHing into my home computer is for.

                                                                                                  1. 2

                                                                                                    I was thinking “is he making jokes?” and just looked into your comments, and you seem serious to me. So, sorry about lack of sense of humour.

                                                                                                    That’s what SSHing into my home computer is for.

                                                                                                    Seems like not a huge problem because SSH warns you when fingerprints changed.

                                                                                                    1. 2

                                                                                                      Hehe, no worries. I enjoyed the article; thanks for posting it.

                                                                                                      A while back I quipped that “VPN is just SSH for suits”; I have honestly never used a VPN because I still can’t figure out what the point is if you already know how to use SSH.

                                                                                                      1. 2

                                                                                                        Reason to use a VPN like ipsec rather than openssh’s SOCKS proxy: better compatibility, lower overhead.

                                                                                                        Compatibility: ipsec or similar VPNs are mostly transparent to applications. Not every program is happy out of the box to talk over a SOCKS proxy. Offhand I’m not sure if ssh’s SOCKS proxy can be used for UDP protocols. (You can use socksify or something to shove all TCP sockets over a particular SOCKS proxy but IME it isn’t reliable.)

                                                                                                        Overhead: not all that bad but just mentioning it for completeness: you can get some head-of-line blocking delays if there’s any packet loss between you and the sshd. Something like ipsec won’t unduly delay packets if some arrive out of order. (Also, not sure if this is accurate but I’ve read somewhere that openssh has some throughout limitation on long fast networks. You probably don’t run into that though.)

                                                                                                        Btw not picking on openssh here, just mentioning it by name because it’s the ssh impl you’re most likely to use these data and the only ssh impl I’m happy to trust.

                                                                                                        This isn’t to say don’t use ssh SOCKS as if it were a tiny vpn, I have done that plenty times myself, just outlining valid reasons one might want the more complicated solution instead.

                                                                                                        1. 2

                                                                                                          Thanks for the technically correct answer. =)

                                                                                                          I guess what I really meant was more like “I’ve never wanted to tunnel a network connection made from a program that isn’t a browser or running over an SSH connection” which is slightly different.

                                                                                                          Now I’m having trouble thinking of any such networked program I use at all other than games. I guess VLC, but apparently that supports SOCKS too. I’m sure they exist; I just don’t have any use for them. =)

                                                                                              2. 2

                                                                                                You choose and control who could potentially snoop on you

                                                                                                I think this is a very good point. Your ISP generally has to be in your country, and as such may be bound by laws requiring them censor certain sites or to log data or metadata. You can’t choose a foreign ISP, but you can choose to use a VPN provider in a different jurisdiction.

                                                                                                1. 1

                                                                                                  Yep, and those are exactly the two use cases where the author says a VPN is reasonable. It’s too bad the author chose to be dogmatic and pooh-pooh those two cases instead of just admitting that their advice isn’t universal.

                                                                                                1. 2

                                                                                                  mirrors will reflect IR, so a hot spot on a mirror may be from a ceiling light not from a camera behind it

                                                                                                  I would have thought that this should be fairly easy to distinguish by moving the IR camera: an IR reflection should move around the mirror like a visible reflection would, while a hotspot behind the mirror should stay put.

                                                                                                  1. 16

                                                                                                    I’ve been doing tabs for indent and spaces for alignment for a similar reason: some people like a tabwidth of 2, some of 4, some of 8. Also, using tabs makes parsing slightly easier, and provides visual guides when you represent tabs with glyphs in your editor. But nothing beats this accessibility argument, it makes the choice much more obvious.

                                                                                                    1. 6

                                                                                                      The problem with tabs is that lots of people use tabs in such a way, that it looks sane only when you’re using their tabwidth, and looks confusing if you’re using a different tabwidth. So not only this defeats the purpose of tabs, but you also need to know their tabwidth in order to even read the source code, let alone modifying it.

                                                                                                      1. 1

                                                                                                        Can you elaborate on this? It should only be an issue if different lines in the same file use spaces on one line, tabs on another.

                                                                                                        1. 4

                                                                                                          Here is an example of what I have in mind:

                                                                                                          http://anadoxin.org/blog/youre-using-tabs-in-a-wrong-way.html

                                                                                                      2. 2

                                                                                                        Seems reasonable. I still have one problem, though: in the editors I have used to date (emacs, QtCreator, VisualStudio, XCode), I haven’t found an easy way to actually do that.

                                                                                                        Emacs has the best UI when you agree with the mode’s settings: hitting [tab] will instantly indent and align the current line of code. If you are using tabs however, emacs will use as much tabs as possible, then fill the remainder with spaces. Which is hell with variable width tabs.

                                                                                                        The other editors, by default would just add one tab character (or 4-8 spaces) when I hit [tab]. No more easy alignment, that’s a drag.

                                                                                                        It’s been a while since I used a modern IDE, though, and I never tried to have Emacs do the right thing (I only used it on spaces projects) Can we now easily set up our editors to help us indent with tabs and align with spaces correctly?

                                                                                                        1. 2

                                                                                                          I just had a quick look in the QtCreator settings (Tools menu > Options > C++ > Edit… > General), and it looks like if you select these options, you will get tabs for indent and spaces for alignment within the indentation level:

                                                                                                          • Tab policy: “Tabs Only”
                                                                                                          • Align continuation lines: “With Spaces”

                                                                                                          I haven’t tested it thoroughly, but it appears to do the right thing in the example code next to the settings.

                                                                                                      1. 3

                                                                                                        I’ve tried SSB before - the frontends are hit and miss and the mobile app, Manyverse, is an unresponsive buggy handwarmer most of the time. It’s the same problems as decentralized tech we’ve seen so far (log sizes, processing power, chattiness and thus power consumption) and no one is addressing any of them, instead being content that it works…? I don’t get how it’ll get to a mass usable state. Mind you, lots of people like how underground it is, but it makes you think how much of what made the Web a success was the commercial aspect most neckbeards think killed it :(

                                                                                                        1. 1

                                                                                                          Last time I ‘tried’ SSB, it was x86 only, the main implementation depended on a single specific version of node, and the implementations in other languages which I looked at were incomplete because they weren’t able to tell whether an odd quirk of said node version was a bug or part of the protocol.

                                                                                                          1. 1

                                                                                                            I agree with the usability issues. My main gripe is the amount of data SSB uses. Manyverse will happily use a gigabyte of your precious mobile data bootstrapping itself without warning you that it’s going to.

                                                                                                            The other problem is the level of complexity. SSB really doesn’t do anything that Usenet News-over-UUCP didn’t do, other than having digital signatures on every message, but it’s built on top of an append-only cryptographic log, implemented in node.js, exchanging messages in JSON, and because of the complexity there are very few independent implementations. I’m really not sure it needs to be this way.

                                                                                                            1. 1

                                                                                                              I think the complexity is inherent if you want to have a decentralized system in which impersonation is impossible. Not sure about other languages, but the core components of SSB are libraries that are easy to incorporate into your own nodejs projects. I just wish some I could see more progress on the usability and data consumption front.

                                                                                                          1. 12

                                                                                                            I don’t work in Go, but I’ve looked at it just for general knowledge. I’m sorry, but at the level of nitpickiness in the article I wouldn’t like any language except perhaps ACL. Every language feature, even those that are “just missing” such as exceptions in Go, is a point of contention. We learn the idiosyncrasies of each language and devise patterns (or frameworks) to work around them.

                                                                                                            1. 12

                                                                                                              I’m sorry, but at the level of nitpickiness in the article I wouldn’t like any language

                                                                                                              I imagine the author would be happy to work around a few small issues. After all, no language is perfect. However, pile up too many small irritations and you end up with a language which people don’t want to use, and this is a list of the myriad large and small ‘idiosyncrasies’ which have put this person off using Go.

                                                                                                              1. 0

                                                                                                                However, pile up too many small irritations and you end up with a language which people don’t want to use

                                                                                                                The fact that many important production/ops codebases (Hashi stack, Kubernetes, Docker, etc.) are written in Go has to be evidence that Go’s “pile of irritations” doesn’t overshadow its benefits.

                                                                                                                1. 7

                                                                                                                  How irritating things are is subjective to each user.

                                                                                                              2. 10

                                                                                                                I think you’re slightly misrepresenting the point about exceptions. The issue isn’t that Go doesn’t have exceptions, but that Go doesn’t have any system for making sure you don’t accidentally ignore errors. If Go either had noisy exceptions which blow up your program unless you catch them, or if it produced an error when you don’t assign a function’s error return value to a variable, or if it had some other clever solution, it wouldn’t have been an issue. It’s just ignoring errors by default that’s problematic.

                                                                                                                In general I mostly agree with you though, that there are idiosyncrasies in all languages, and you just have to learn to live with them. I have written a bit of Go code myself (some professionally), and it’s fairly nice to work with in spite of its flaws. Being someone who mostly writes C, using interface{} all over the place instead of generics doesn’t even feel wrong.

                                                                                                                My biggest complaint about Go would probably be how it adds a reference all over the source code on where a package happens to be hosted. I’m also not a big fan of the GOPATH stuff, but that’s being phased out (though the transition is a bit weird, where I find some commands require my package to be inside of GOPATH, while others require my package to not be inside of GOPATH).

                                                                                                                1. 6

                                                                                                                  I’m sorry, but at the level of nitpickiness in the article I wouldn’t like any language except perhaps ACL.

                                                                                                                  I agree. Furthermore, these points have been raised in articles since Go was publicly announced. Each of these points are well-known, there is no use in hearing them the umpteenth time,

                                                                                                                  Secondly, some of these points are really in the eye of the beholder, and a Go programmer would see them as strengths. E.g. (not necessarily my opinion):

                                                                                                                  Go uses capitalization to determine identifier visibility.

                                                                                                                  Great. Now I don’t have to look at the definition to know its visibility.

                                                                                                                  Structs do not explicitly declare which interfaces they implement. It’s free to do that – it never promised anything.

                                                                                                                  Which is nice, because one can make ad-hoc interfaces that the author of the package did not define. If the author wants to make a guarantee, they could assert that :

                                                                                                                  // foo.go
                                                                                                                  
                                                                                                                  type Foo struct { //... }
                                                                                                                  
                                                                                                                  type Bar interface { //... }
                                                                                                                  
                                                                                                                  var _ Bar = NewFoo()
                                                                                                                  

                                                                                                                  There’s no ternary (?:) operator.

                                                                                                                  (Over)use of the ternary operator leads to unreadable code.

                                                                                                                  1. 6

                                                                                                                    Which is nice, because one can make ad-hoc interfaces that the author of the package did not define

                                                                                                                    Yes. This is called structural typing and we’ve had it since at least C++ added templates. I don’t think the article argues against this, it brings up problems with it. My issue with it in most implementations (that I know of, every one except for Haskell and Rust) is that when you want to implement an interface but haven’t because of a programming error. I’d like the compiler to tell me what I did wrong. To me, that’s the advantage of explicitly declaring an interface/trait/type class and akin to declaring variables before use.

                                                                                                                    (Over)use of the ternary operator leads to unreadable code.

                                                                                                                    Overuse of anything, including goroutines, leads to unreadable code. That’s not an argument for or against any feature. I thought the article made a perfectly good case for how the ternary operator makes the code more readable.

                                                                                                                    1. 3

                                                                                                                      My issue with it in most implementations (that I know of, every one except for Haskell and Rust)

                                                                                                                      Haskell and Rust do not use structural typing. Both are nominative type systems, since traits/type classes are explicitly implemented for named types.

                                                                                                                      that when you want to implement an interface but haven’t because of a programming error. I’d like the compiler to tell me what I did wrong.

                                                                                                                      As my example showed, you can do this in Go as well. When I used Go (as a stop gap between not wanting to go back to C++ and until Rust 1.0 was released), I used this approach to assert that types implement the interfaces that I wanted them to.

                                                                                                                      Go’s approach has different problems – you can’t implement interface methods externally for a data type that is not under your control. E.g. in Rust or Haskell, one can define a trait/type class and implement it for various ‘external’ types. In such cases, you have to wrap the data type in Go, so that you can define your own methods.

                                                                                                                      Overuse of anything, including goroutines, leads to unreadable code. That’s not an argument for or against any feature.

                                                                                                                      Not all language constructs are equal in obfuscating readability. Many modern languages choose to omit the ternary operator (e.g. Rust), because their designers believe that it leads to worse understandably.

                                                                                                                      1. 2

                                                                                                                        Rust has a ternary operator. It’s not spelled ? :, but since every if statement is an expression, it’s there: https://doc.rust-lang.org/reference/expressions/if-expr.html#if-expressions

                                                                                                                        1. 1

                                                                                                                          I know that if is an expression in Rust, use it daily :). And still people ask for ? :, because it is more terse. But a nested if expression is much easier to read than nested use of the ternary ? : operator.

                                                                                                                    2. 1

                                                                                                                      While the structural typing thing is (IMO) not a problem (it means you need to write your code in a style suited to structural typing rather than nominative typing, which everybody used to duck typing already does), other points made here are both new to me (as someone who has not written any non-trivial go code but has been casually following it since its release) and sort of shocking.

                                                                                                                      Capitalization for identifier visibility is, as you mentioned, sometimes a time-saver when reading code, but as OP mentioned, both less expressive than multi-tier scoping rules & a potential source of enormous diffs when refactoring. This is a case where, fairly unambiguously, something that seems like a clever idea on first blush has massive knock-on effects that large projects need to work around & that affect iteration speed (because you sometimes need to search & replace identifiers in a whole module, & if you’re not careful to write your code in a style where private identifiers that you think might need to become public in the future are rarely referenced directly, you’re liable to have a diff on nearly every line). I’m generally in favor of capitalization having semantic meaning (I like how, in prolog-influenced languages, capitalization distinguishes identifiers from atoms), but nothing indicated by part of an identifier name ought to be something that changes during implementation unless most uses of that identifier will also already need to change to match.

                                                                                                                      The absence of a ternary operator is sort of shocking. It’s not the compiler’s job to paternalistically enforce good style, and using the ternary operator judiciously is often better style than avoiding it entirely (especially when what is conceptually a single expression – say, an assignment – needs a default case). Languages that lack a ternary operator tend to support || in expressions in order to handle the most common case – handling defaults in the case of a null or nullish value. Leaving out the ternary operator feels philosophically out of line in go, and more in line with paternalistic languages like Java. (Although Java has a ternary operator, it does all sorts of other things at the compiler level to enforce an idea of ‘good style’ that, because it lacks nuance, often makes code substantially worse & harder to read.)

                                                                                                                      Go’s error handling (or lack thereof) is familiar & has been covered before, so I don’t think it surprises anybody. It’s basically like C’s. OP seems to mention it for the sake of completeness – since, yes, it’s easier to silently ignore errors when you don’t have an exception-like sytem, and the tendency of C code to accidentally ignore important errors is precisely why most modern languages have exceptions.

                                                                                                                  1. 13

                                                                                                                    Some of the psychology you cite is very pertinent and interesting but I really disagree with some of your conclusions.

                                                                                                                    I think that if you as a candidate freeze up when asked to perform a basic example of what you’d be doing for your job, then that’s an interview skill you should consider building rather than advocating doing away with that class of interview question.

                                                                                                                    I know a LOT of talented people who have great trouble with whiteboarding, and I get it. I REALLY do because I used to be in that category.

                                                                                                                    But like any other fight / flight response where no actual mortal peril is involved, you can work through the anxiety and learn to process the situation differently, and once you do, it’s incredibly empowering!

                                                                                                                    When I’m doing an interview and I can tell that my candidate is freaking out, I typically ask them to talk me through what they think a solution would flow like, without any of the syntax involved.

                                                                                                                    And honestly, what job anywhere is free of this kind of pressure?

                                                                                                                    [Full Disclosure: I work for a Major Cloud Company and our interview process is highly data driven and also includes some whiteboarding. I think this hiring strategy has been extremely successful, but obviously YMMV and different companies are different.]

                                                                                                                    1. 15

                                                                                                                      The problem is, its not only about anxiety. It could be, and is, any number of things, like active stressors (disease, divorce etc.), biochemical stuff (low sugar, hormones), meteorology (too hot/cold) etc. I remember, 10y ago that when I had an interview @booking.com, my head hurt so strong that I could hardly speak.

                                                                                                                      And honestly, what job anywhere is free of this kind of pressure?

                                                                                                                      Almost any job is without that kind of pressure. Its totally artificial.

                                                                                                                      When you measure people this way, you have no option but to ask academic stuff. For example, local Microsoft tech interview I was part of were created by assistants of local faculty of Mathematics, and had questions such as what is the probability that frog will survive the road run and other crap like that. I finished the same math university 5 years before and I still couldn’t manage many questions. Not to mention, just finished students nailed it, with 0 practical experience (it was 0). So, this type of interview is biased toward fresh graduates and academy itself has entirely different goals and agenda far removed from usual everyday IT reality (since then I had number of professors working in my team and each time with disappointing results). Or, member the interview of author of brew for Google ?

                                                                                                                      I used exclusively lets-speak-about-random-IT-stuff type of interview and I think it worked OK. I also ask for online profiles - Github, Gitlab, etc… there is no substitute for seeing (or not seeing!) code itself. There are few persons that were great in that while sucked on job a lot, but overall, the initial feeling after the conversation was at least 90% on the spot.

                                                                                                                      1. 2
                                                                                                                        And honestly, what job anywhere is free of this kind of pressure?
                                                                                                                        

                                                                                                                        Almost any job is without that kind of pressure. Its totally artificial.

                                                                                                                        Couldn’t disagree more. I’ve worked in this industry for 30 years, admittedly only 5 or so of those years as an actual ‘software developer’ (mostly release engineer, devops, and before that highly code-centric sysadmin).

                                                                                                                        I can’t think of a single job I’ve ever worked that didn’t have “OK. We need you to produce. NOW” moments.

                                                                                                                        If you’ve worked jobs that don’t have that kind of pressure, I envy you, but I’m unsure whether or not your experience is one that many others share.

                                                                                                                        1. 15

                                                                                                                          Certainly many jobs require deploying a patch, developing a new schema, reacting to a fire in the moment on deadline, etc., but I think few require you to be able to converse about it to strangers who can fire you, in those circumstances. ;)

                                                                                                                          My work is not complicated. My experience with whiteboard interviewing has been with insignificant companies that do not do hard engineering. When I froze up and couldn’t think of the name for modulo after having just used the operator, the interviewer decided I wasn’t a good fit… I think less technical or complicated jobs use whiteboard just as much as Google, and that’s frustrating.

                                                                                                                          1. 11

                                                                                                                            Most of them won’t then stare at you while you do your job on an unfamiliar tool you’re only using so they can decide whether to promote or fire you.

                                                                                                                            Instead, they give you some requirements, you leave, you work alone on them at a computer, maybe talk to team members, maybe status reports (mostly typed), and eventually deliver the results to then.

                                                                                                                            These are the skills the interview process should assess. That’s why a lot of shops do take-home assignments or just not whiteboarding. Now, whiteboarding in non-hostile environment can be great for testing presentation and collaboration skills.

                                                                                                                            1. 4

                                                                                                                              Exactly.

                                                                                                                              When multiple people STARE AT ME while working (even in familiar environment), I can’t work productively.

                                                                                                                              Also, nobody ever comes with the random problem and ask you to solve it yesterday in 1 hour. You always have some context, some continuancy.

                                                                                                                              1. 2

                                                                                                                                I can appreciate where you’re coming from here and I’ve done take home assignments in the past. I stand by my comments around whiteboarding as a valuable interviewing tool. I think if interviewers are getting hung up on details they’re missing the point, and I also think that as a prospective interviewee having the expectation that you won’t be asked to give a sample of your work on the spot doesn’t seem realistic to me.

                                                                                                                                However, if all of you can restrict your job search to companies that never do whiteboarding, good on you!

                                                                                                                                1. 2

                                                                                                                                  The problem with whiteboarding is that while it measures something, the something it measures is not the thing you’ll care about if you hire them. Which in turn is why there are books out there that teach whiteboard interview coding as a separate skill from actual programming, and why even prestigious universities now include a unit on interview coding as a separate skill from programming.

                                                                                                                                  Which raises the inevitable question: why not actually test for the skills you’ll care about on the job? If you don’t test for the job skills you’ll hire people who don’t have the job skills.

                                                                                                                                  1. 3

                                                                                                                                    why not actually test for the skills you’ll care about on the job?

                                                                                                                                    That is what they’re trying to do. It takes a lot of time to find out if someone can actually do a good job as part of your team, and the only way to really test it is to employ them for a few months (A few months of probation is quite common for this). Given that you can’t afford to make that sort of investment in every candidate that applies, companies use whiteboarding and other forms of technical interview to try and guess whether a candidate might have suitable skills before investing more time in them.

                                                                                                                                    1. 0

                                                                                                                                      That is what they’re trying to do.

                                                                                                                                      Well, no. What they’re trying to do is cargo-cult what they think Google is doing, because they think “Google is big and successful, so if our company does what Google does, our company will be big and successful too”.

                                                                                                                                      Of course, Google openly admits their process has a high false-negative rate (it flunks qualified people), but they get enough applicants that they can afford to reject some qualified people. The average company isn’t in that position and can’t afford it.

                                                                                                                                      And Peter Norvig has explained that Google found a negative correlation between doing well on competitive programming tasks and performance on the job, which throws a wrench in any argument that on-the-spot coding under pressure measures something useful.

                                                                                                                                      Interviewing as typically practiced in tech is fundamentally broken. It measures the wrong things, draws the wrong conclusions from what it does measure, and is more or less random. I think it’s long past time to stop defending that.

                                                                                                                                      1. 2

                                                                                                                                        I never said that the processes were effective, nor am I defending them. I am merely pointing out that they are ultimately an attempt (however ineffective) to select candidates with relevant skills and reject those without.

                                                                                                                                        “Why not actually test for the skills you’ll care about on the job?” is unhelpful in that the intention is blatantly obvious, but offers absolutely no suggestion of how to achieve it.

                                                                                                                                        1. 5

                                                                                                                                          “Why not actually test for the skills you’ll care about on the job?” is unhelpful in that the intention is blatantly obvious, but offers absolutely no suggestion of how to achieve it.

                                                                                                                                          Tthere are a ton of articles and talks floating around on how to do better tech interviews – I’ve even written/presented some of them, based on my own experience helping to rebuild interview processes at various places I’ve worked – and people could quite easily find them if they wanted to.

                                                                                                                                          But here goes. Again.

                                                                                                                                          As I see it, there are several fundamental problems, and various ways to avoid them.

                                                                                                                                          Problem #1 is playing follow-the-leader. People implement processes based on what they think bigger/more successful companies are doing, without considering the tradeoffs involved or indeed whether those processes had anything to do with the size/success of those companies. Google’s admitted high false-negative rate is the quintessential example: they really can afford to throw away qualified applicants, because tomorrow another hundred will have submitted applications. The typical tech company can’t afford this, or can’t afford other unquestioned assumptions baked into large-company interview processes.

                                                                                                                                          The solution here is to question the assumptions and expose the tradeoffs. The extremes are “Never hire an unqualified person” and “Never pass on a qualified person”. Google optimizes for the former at basically all costs. Many companies, on the other hand, need to push the needle further toward the latter, which means a more forgiving process that doesn’t flunk people as quickly or for reasons as minor as large companies do. True story: I know one person who flunked Google because they had to write and then read out a bash script over the phone and the interviewer mistranscribed it. I know another person who flunked at Twitter because they provided one of two textbook algorithms for the problem posed, but the interviewer only knew the other and didn’t bother looking more deeply than just “that’s not the answer I know”.

                                                                                                                                          Those should be unforgivable interviewer errors at any company, but are especially unforgivable at companies which can’t afford to just throw qualified applicants into the trash can.

                                                                                                                                          Problem #2 is poor targeting. A lot of interview processes, especially at BigTech, explicitly or implicitly target fresh graduates, by quizzing on the sorts of things fresh graduates will have top-of-mind. Many of those things are not top-of-mind for working programmers who’ve been in the industry a while, since they’re rarely used in actual day-to-day programming (this includes a lot of algorithm and data-structure questions, since most working programmers don’t implement those from scratch on a routine basis). This biases away from experienced programmers, and creates a self-reinforcing cycle: you hire a bunch of recent grads, and they come in and start interviewing people which pushes even more toward preferring recent grads, so you hire even more of them, and… then one day you look around and wonder why it’s so hard to find experienced people. This is especially bad in the places that do algorithm challenges, because usually they’re posing things that want you to come up with a solution that took top people in the field decades to come up with while not under any particular pressure, and they want it from you in 20 minutes. On a whiteboard. While they watch. The only way to pass these is to “cheat” by already knowing the answers in advance, which you do either by reading a book about interview problems, or by being a recent grad who just passed a bunch of exams on the material.

                                                                                                                                          The solution here is to interview based on things that are actually relevant to day-to-day programming. You can, if you want to, find out about someone’s problem-solving skill while using questions and problems that involve things real working programmers actually do.

                                                                                                                                          Speaking of which, problem #3: far too many interview problems are contrived and unrealistic.

                                                                                                                                          You can do interviews based on real-world practical problems. Two of the best interview processes I’ve ever gone through did exactly this: one had a work-sample test where they gave you a simplified version of an actual problem from the domain they worked in, the other did a collaborative session where you had to debug a piece of code extracted from their real system and find the real problems in it. Putting together an interview based on these kinds of problems doesn’t take a ton of time, and gives you a much more realistic idea of how someone will perform in your company than the million and first shibboleth problem that tries to test for “fundamentals” but really only checks whether someone was taught the test.

                                                                                                                                          Problem #4 is measuring things that don’t matter. Whiteboard design can be useful, but whiteboard coding isn’t. Algorithm regurgitation isn’t. Trivia isn’t. Having open-source contributions on GitHub isn’t. Having lots of free time to do competitive “challenges” isn’t. And a lot of “soft” factors like confidence aren’t.

                                                                                                                                          Measure the things that matter. Measure how well someone can ask questions about a problem or communicate ideas on how to solve it. Measure how well someone works with others (pair programming can make a great interview session if you do it right). Measure how well someone finds and uses resources to help them work through a problem. Measure how well someone interacts with non-engineer colleagues. We’ve all worked with people who were good and people who weren’t so good; figure out what the good ones had in common and measure for that. It’s almost never going to be things like “they were really good at writing linked-list implementations on a whiteboard”.

                                                                                                                                          Here are some concrete ideas for more useful interviews.

                                                                                                                                          First, always let the candidate use a real computer with real programming tools and access to references, Google, and Stack Overflow. I make a point of telling people that I’ve written significant chunks of Django’s documentation but I still have that documentation open in tabs when I’m working; it’s outright nonsense to forbid that while also claiming you measure realistic performance.

                                                                                                                                          Second, use technical sessions that avoid the problems outlined above. Here are ideas:

                                                                                                                                          • Code review. Bring a piece of code (as realistic as possible) and have the candidate work through it with you. Have them demonstrate that they can read and understand it, ask productive questions about it, and offer constructive and useful feedback on it.
                                                                                                                                          • Pair programming. Bring something with a known bug, have them debug and fix it with you. Have them demonstrate that they understand how to approach it, search for and identify the problem, and work up a fix.
                                                                                                                                          • Give them notes from a real problem, and be prepared to answer questions about it, and have them write a brief post-mortem for it. Have them demonstrate they can take in the information you’re giving them, usefully probe for anything missing, and synthesize it all into an explanation of what happened.
                                                                                                                                          • Bring them a rough feature spec and ask them to refine it and break it down into assignable units of work. Have them demonstrate they can ask good questions about it, figure out the needs and the tradeoffs involved, and come up with a sensible plan for how to go after it.

                                                                                                                                          Third, use non-technical sessions! And not just a “culture fit” lunch with the team. Have them do a session with a PM or designer or other non-engineer colleagues to see how they interact and watch for signs of whether they’ll have productive working relationships with those folks.

                                                                                                                                          Finally, standardize your evaluations. It’s OK if there are different possible combinations of sessions (some people may prefer to do a take-home work sample, others may prefer to pair live and in person, etc.), but it’s not OK if interviewers have different rubrics for grading. Write out, explicitly, the qualities you’re looking for, in specific terms (i.e., not “confidence” or “professionalism” – those are vague weasel words that shouldn’t be allowed anywhere near an interview scorecard). Write out how interviewers are supposed to look for and evaluate those qualities. Set explicit baseline and exceeds-expectations bars for each session. Write scripts for interviewers to practice on and follow when presenting problems. Have interviewers practice running the sessions with current employees, and have some of your acting “candidates” try to pull sessions off-script or fail, to make sure interviewers know how to handle those cases gracefully.

                                                                                                                                          And finally, treat candidates like people. Someone you’re interviewing should be seen as a colleague you just haven’t worked with yet. Designing a process to be adversarial and to treat everyone as a con man will yield miserable and unproductive interviews.

                                                                                                                                          Now, I got voted “-2, troll” in my previous comment for citing sources that the typical coding interview doesn’t measure things that actually matter and in fact selects for things that correlate negatively to on-the-job performance. But I could cite plenty more. This video, for example, is a former Google employee who at one point recounts the story of a frustrated recruiter who revealed to a hiring committee he served on that they’d all just voted “no hire” on slightly-anonymized versions of their own interview packets and how it exposed the brokenness that was going on there. This article from a company that provides interviewing tools goes into detail on just how unreliable it is to use something that seems like it might be a proxy for real on-the-job skills (key takeaway: scores assigned to candidates by interviewers were all over the place, and inconsistent even for the candidates with the highest mean performances, fully one-third of whom outright bombed at least one interview).

                                                                                                                                          Interviewing is broken. It can be fixed. Both of these should be uncontroversial facts, but the fact that multiple people here saw them as “trolling” is indicative of the real problem.

                                                                                                                                          1. 2

                                                                                                                                            I regret I have but one upvote to give for your comment.

                                                                                                                                            1. 1

                                                                                                                                              Excellent comment. I particularly like the part that goes from practices focusing on recent grads that becomes self-sustaining. That could be actionable under anti-discrimination laws. I’ll try to remember that.

                                                                                                                                              If -2 was what I think it was, then that might be how intro had a tone that looked aggressive, dismissive, or something else. People here are more sensitive to that than most places both in terms of most of us wanting civility and what a large group deems as inclusive speech. Your comments will get better reception if you present your counterpoints without any rhetoric that comes off as a personal attack or dismissal.

                                                                                                                                    2. 0

                                                                                                                                      In my CV you can see that I have created number of large services to be used by entire countries, 24/7. This can easily be checked even real time (I have admin access to all of them which I can demonstrate immediately ). You want me to whiteboard ? No!

                                                                                                                                      Furthermore, I will make sure all of my senior IT friends and colleagues know how much you suck as a company (in this land, you can count seniors on fingers ATM) so good luck for you finding one.

                                                                                                                                      It looks to me that many people do not get it - senior developers are celebrities today.

                                                                                                                                      Me? I’ll rather collect peanuts then make somebody else rich(er) on my work without fair compensation, respect and professionalism.

                                                                                                                                      1. 6

                                                                                                                                        Me? I’ll rather collect peanuts then make somebody else rich(er) on my work without fair compensation, respect and professionalism.

                                                                                                                                        Your response made me take a step back and think about what we’ve all been saying here, and I came to a couple of conclusions.

                                                                                                                                        1. I am not a software developer per se. I work in the devops space. I do write software, but it’s nothing even remotely on the order of magnitude that the average Crustacean does. I write simple process automation scripts in Python and occasionally Ruby or Bash. This informs both my world view and the kinds of things I would ask people to whiteboard. As in, they are not at all algorithmically hard, things like “Print the duplicates in this list of numbers” and the like.

                                                                                                                                        2. Reading all of you express such vehement opposition to the idea certainly has me questioning its wisdom when interviewing software devs, and also wondering if the experiences you’ve all had were at the hand of people who weren’t very mindful of candidate experience in how they were conducting their interviews in general.

                                                                                                                                        In any case, it’s all very good food for thought, and I will now shut up on this topic and think on all of this.

                                                                                                                                        1. 5

                                                                                                                                          Based on my own experience, it is not that uncommon to find someone with “years of programming experience” on their resume, but has trouble solving basic programming tasks. This is because experience comes in a ton of different shapes and sizes. For that reason, before I can be okay with hiring someone in a technical capacity, I really need some kind of evidence that they can write code well. Whether that’s looking at code they wrote previously, giving them a new coding assignment, a white board interview, a presentation or maybe just prior experience working with them, I don’t really care. But there needs to be something. If I just took peoples’ word for it, the results would be pretty bad.

                                                                                                                                          I think people in this thread generally underestimate just how many people are out there that claim coding experience but fail to meet some really minimal standards. I’m talking about things like Fizz Buzz. Some kind of evaluation process is necessary in my experience.

                                                                                                                                          Personally, I think the person you’re talking too is being way too unreasonable.

                                                                                                                                          Everyone gets way too hung up on this shit. There’s a saying that goes something like, “all models are wrong, but some are useful.” It applies just as well to hiring practices. You can’t get it right all of the time, and some of your techniques might indeed yield false negatives. This is basically impossible to measure, but since a false positive is generally perceived as being much more costly than a false negative, you wind up trying to bias toward rejecting folks that might be otherwise qualified in favor of avoiding false positives.

                                                                                                                                          The whole thing is super hand wavy. People just seem to get obsessed with the fact that Hiring Practice X is wrong one dimension or another. And they’re probably right. But so what? All hiring practices are wrong in some dimension. And even this differs by experience. For example, a lot of people love to poo-poo whiteboard interviewing because that’s not reflective of what the job is actually like. But that’s not true for me. I use the whiteboard all the time. It’s a pretty useful skill to be able to go up to a whiteboard and communicate your ideas. Obviously, the pressure of evaluation isn’t there when you’re on the job, but I don’t see how to relieve that other than by limiting yourself to hiring people you already know.

                                                                                                                                        2. 1

                                                                                                                                          In my CV you can see that I have created number of large services to be used by entire countries, 24/7.

                                                                                                                                          I want to remind you that this doesn’t matter at all in terms of good, software engineering. There’s both lots of crap tech out there with high usage and countries that demand even crappier tech. High uptake doesn’t mean anything except you worked on something that had high uptake due to you or more likely someone else given how businesses/governments decide what to use. If you doubt this, I hit you with my COBOL argument: why not hire someone how knows what billions of lines of mission-critical code are written in? Must be better than almost everything else if argument by uptake and net worth in critical areas is meaningful.

                                                                                                                                          Or that’s just social-economic forces making that happen in a world where we need to consider other things. ;)

                                                                                                                                      2. 1

                                                                                                                                        I think the whole point of the article here is that there is no one best type of interview. Some candidates have anxiety attacks when mild pressure is applied, and do much better in a lower-pressure situation like a take-home assignment, and don’t mind spending the time on it. Some candidates have families or other obligations and can’t spend (unpaid) hours outside of their normal job writing up a solution to somebody’s take-home assignment, but do just fine solving problems on whiteboards. Probably some others have issues with both of those and need something else again.

                                                                                                                                      3. 9

                                                                                                                                        I think that’s a very different situation when you’re already comfortable with your environment.

                                                                                                                                        1. 9

                                                                                                                                          Couldn’t disagree more with you, either. I’ve also been in this industry for 30 years with almost all of them being an actual ‘software developer’ and I can count on one hand the number of times that I’ve had “produce now!” moments. Perhaps I’ve been lucky, but in my experience, these are rare, 1% times, when there’s a demo or something the next day and you’re trying to get something out the door. Given that, why exactly should we measure this? Even given those high pressure situations, you’re not standing alone, at a whiteboard or in front of a panel, with no resources ( google, library, other engineers ), no context ( mystery problem… you don’t get to know until you have 2 hours to solve! ) and no backup plan. Even with all of those caveats, I have NEVER had to cough up a random data structure with no reference material/resources/etc. in less than an hour or two EXCEPT in an interview.

                                                                                                                                          1. 1

                                                                                                                                            What I’m hearing is that a lot of people have had really bad experiences with whiteboard interviewing.

                                                                                                                                            If the interviewer is hung up on syntax, they’re IMO doing it wrong.

                                                                                                                                            1. 2

                                                                                                                                              If someone presents a problem for you, do you immediately recall all algorithms you’ve learned and start whiteboarding that? That’s generally what happens in these whiteboarding sessions that I’ve been in. I don’t remember a ton of stuff off-hand and search for it all the time. Should that count against me? If it does, I don’t really want to work at that place anyway.

                                                                                                                                              1. 1

                                                                                                                                                I realized (as I wrote in another reply to someone else) that there’s a disconnect here.

                                                                                                                                                I’m not a software developer. I do devops work which means I write a lot of VERY simple process oriented automation scripts in Python and occasionally Ruby or Bash.

                                                                                                                                                When I do whiteboarding with candidates, the most algorithmically complex I get is “print the duplicates in this list of numbers” but mostly it’s things like “Here’s a json blob that lives on an http server. Write code that grabs the blob and connects to each host in a group given on the command line” type things.

                                                                                                                                                But even so I certainly see where you’re all coming from, and can appreciate the idea that there are definitely better tools out there, especially for cases where you’re not doing hiring at scale.

                                                                                                                                                Which makes me wonder, how might one apply all this anti-whiteboarding sentiment in a large corporate environment? How do you get take home exams, pairing, or whatever to be effective when you need to hire 50 people in a month?

                                                                                                                                                1. 2

                                                                                                                                                  I used to work at Capital One and we were always trying to hire people. Each team largely handled its own hiring, though, and we had .. so many teams. Some teams do a whiteboarding session, some do a take home assignment, some do a little pair programming exercise. It really depends on the team and the people.

                                                                                                                                                  I’m not anti-whiteboarding for things like what you mentioned, but if someone is asking me to regurgitate a CS algorithm that I haven’t touched in decades, I don’t really get the point.

                                                                                                                                          2. 3

                                                                                                                                            Hmm. I’m not up to 30 years experience at this point (closer to 20), but I’ve never had this happen to me. Even when production bugs hit, it’s not a “We need you to produce. NOW” scenario, but an all-of-us circling the wagons type of deal to track it down. Even in startups where I was the only person writing code, it was never like that. That seems really unusual to me. I don’t know what country you’re in, but for context, I’m in the US.

                                                                                                                                            1. 4

                                                                                                                                              OK. We need you to produce. NOW

                                                                                                                                              Oh, you work for those type of guys who think programming is like manufacture so you can measure it by the number of bricks in the wall, LOC, or something. I don’t accept that kind of job. I know better. I witnessed it dozens of times for other companies I consult for and that kind of job is always substandard.

                                                                                                                                              I envy you

                                                                                                                                              Its better idea to fight for your rights (our rights, really).

                                                                                                                                              but I’m unsure whether or not your experience is one that many others share

                                                                                                                                              I am sure its not. I am sure its opposite. But that is where I draw the line. I don’t mind fixing simple things here and there ASAP, but designing entire/parts of app/service without adequate time is no bueno.

                                                                                                                                              1. 4

                                                                                                                                                Oh, you work for those type of guys who think programming is like manufacture so you can measure it by the number of bricks in the wall, LOC, or something. I don’t accept that kind of job. I know better. I witnessed it dozens of times for other companies I consult for and that kind of job is always substandard.

                                                                                                                                                This is kind of a cheap shot and also? It’s not true.

                                                                                                                                                But even if it was, people work for different reasons. I live in a society that doesn’t provide much of a net if you fall, and I have some medical conditions which require some fairly expensive care.

                                                                                                                                                So, yes I work for a company that pays well. I put a LOT of blood, sweat and tears into my job, and I won’t apologize for that.

                                                                                                                                                Might it not be the kind of place you’d want to work? I don’t doubt that, and I’m glad you’ve been able to find work that suits your particular needs and wants, but please consider that not everyone is you before making broad statements about people and workplaces when you have zero information.

                                                                                                                                                1. 4

                                                                                                                                                  Besides the broad generalizations, I find myself between both of you. majkinetor strikes a cord when he says one must fight for their rights. I’d add that once one finds ones self (if ever) in a position wherein one can enlighten the company masses than one should do what one can. But, feoh, isn’t incorrect either. Sometimes you just gotta play the game. I have only worked for places that tend to think of programming in terms of lines of code. It’s really why I am always looking for a new place to work. And, yes, I hate interviewing as well, which makes my conundrum annoying.

                                                                                                                                                  1. 1

                                                                                                                                                    But even if it was, people work for different reasons. I live in a society that doesn’t provide much of a net if you fall, and I have some medical conditions which require some fairly expensive care.

                                                                                                                                                    We do generalization here, any kind of behavior may be adequate in specific context.

                                                                                                                                                    So, yes I work for a company that pays well. I put a LOT of blood, sweat and tears into my job, and I won’t apologize for that.

                                                                                                                                                    Who asked you to do this ? When I speak, I speak about myself and what I think, I am not giving lectures or judgement.

                                                                                                                                                    when you have zero information

                                                                                                                                                    Not zero, I am in this business more then 30 years (also with medical conditions). Don’t be angry :)

                                                                                                                                                    1. 2

                                                                                                                                                      Not zero, I am in this business more then 30 years (also with medical conditions). Don’t be angry :)

                                                                                                                                                      I can see where I came off as defensive there. I’m not angry, I’m just surprised at the expectations some folks have around the interview process.

                                                                                                                                                      If you can find work with those expectations, that’s fantastic.

                                                                                                                                              2. 1

                                                                                                                                                I think you’re combining two different things here - having a candidate write things on a whiteboard in an interview, and interviewing a candidate based on solving highly abstract problems that have little relation to the actual day-to-day work of building software, stuff like writing binary tree manipulation algorithms.

                                                                                                                                                I think the second is a ridiculous thing to judge candidates based on almost all of the time, unless of course you’re doing one of the few jobs that actually involves doing stuff like that.

                                                                                                                                                The first though, is a perfectly good way to determine whether candidates can actually produce code.

                                                                                                                                                1. 0

                                                                                                                                                  The first though, is a perfectly good way to determine whether candidates can actually produce code.

                                                                                                                                                  Producing code on whiteboard? I had that on university on exams and many “programmers” came out of it without using a computer single time during the entire studies (I know, my sister was one of them, never turned a computer on until she finished computer studies! and got a job). Doesn’t inspire…

                                                                                                                                              3. 4

                                                                                                                                                Mine is kind of like the protagonist’s job in Office Space, but with more SIP trunking.

                                                                                                                                                1. 3

                                                                                                                                                  At most places I’ve worked pressure was 99% of the simmering kind. Less than 1% I’ve had that flashpoint pressure but frequently it was artificially created to “increase productivity”. Basically the only time when you have to deliver NOW is during major production incidents.

                                                                                                                                                  I’d bet that even at your “Major Cloud Company” the percentage of people involved in solving a major production incident are in the low double digits.

                                                                                                                                                  I have frozen during whiteboard interviews and I’m far from a shy person. Day to day I’m more likely to be the kind of person that makes others freeze - and I don’t say that as some sort of self-praise, quite frequently it’s not a good trait.

                                                                                                                                                  In my opinion, even with your highly data driven process, if you work for a “Major Cloud Company” you can just ask for a painting competition among your candidates and you’d get the same results. Your company probably pays a very high salary compared to the market so competition would be fierce and people willing to train for 6 months on the intricate details of painting while holding a full-time job at the same time would probably make at least half-decent coders :)

                                                                                                                                                  TL;DR: It’s the high salaries and very competitive recruitment pipeline that produce results, not necessarily the actual interviewing details, in my opinion.

                                                                                                                                                  1. 1

                                                                                                                                                    I share your opinion - note that, in my mind, the “increase productivity” methods actually are very harmful in the long run

                                                                                                                                                  2. 1

                                                                                                                                                    But like any other fight / flight response where no actual mortal peril is involved, you can work through the anxiety and learn to process the situation differently, and once you do, it’s incredibly empowering!

                                                                                                                                                    I’ve been thinking about this point for several days now.

                                                                                                                                                    I haven’t been in the habit of thinking about interviewing in terms of a set of skills one can acquire/improve. However, perhaps if I can get myself into this mindset, it will help me to do something other than just walk into a new place and fly by the seat of my pants :)

                                                                                                                                                    1. 1

                                                                                                                                                      I’ve been thinking about this point for several days now.

                                                                                                                                                      I haven’t been in the habit of thinking about interviewing in terms of a set of skills one can acquire/improve. However, perhaps if I can get myself into this mindset, it will help me to do something other than just walk into a new place and fly by the seat of my pants :)

                                                                                                                                                      I am sincerely grateful for the fact that at least one person took the advice I was giving in the spirit in which it was meant :)

                                                                                                                                                      It most definitely is a skill, and here’s how I know that:

                                                                                                                                                      There was a period in my career when I was much better at interviewing than actually doing the work. My work ethic has never been in question, I will work to the point of stupidity at times, but I had made some rather near sighted choices around which skills to build (learning new technologies in a very shallow way VERY quickly) over skills I should have focused on (attaining mastery in a few key tools and subject areas)>.

                                                                                                                                                  1. 3

                                                                                                                                                    Regarding a more detailed feedback and code review. I’ve had bad experiences before.

                                                                                                                                                    I did a code review for a candidate applying for dev. He asked for more detailed code review and then didn’t take the feedback well. I suspected something like this could happen so I actually asked a very Senior dev to check my feedback before sending it.

                                                                                                                                                    After a couple similar cases, HR stopped sending detailed feedback

                                                                                                                                                    1. 1

                                                                                                                                                      While it’s a nice idea that even when you don’t get the job, the company can still give you feedback to help you learn something from the experience, I can’t imagine it ever really working out:

                                                                                                                                                      1. Can you be sure that the person reviewing your code is suitably experienced? You’re potentially just getting a random employee’s opinions.
                                                                                                                                                      2. Do you expect a thorough code review, given that it requires the company to continue investing employee time in a candidate they have decided not to hire?
                                                                                                                                                      3. Besides the waste of time, there are potential legal pitfalls for a company giving any sort of feedback: Better for them to say nothing or quote an HR-approved response than to risk anything that could even suggest discrimination in their hiring process.
                                                                                                                                                      4. Assuming you get some feedback, at least part of the feedback will be focussed on why you/your code aren’t a good fit for that particular company, and won’t necessarily apply anywhere else.

                                                                                                                                                      Put all this together and I can’t see why you’d even bother asking for feedback. I would, however, be interested to hear from anyone who has received useful feedback after an interview or similar.

                                                                                                                                                      1. 1

                                                                                                                                                        I agree that this isn’t a great idea. There are too many things that can be used against you as a company. On the flip side, I’ve been in scenarios where I wanted to know why they passed and wished they would’ve provided information. It ended up making me seek out help outside of my own circle though, and got me involved (briefly) with some open source stuff.

                                                                                                                                                      1. 1

                                                                                                                                                        While I agree that a longer name which explains exactly what it is is usually better, I find that excessively long names are often (though not always) a “code smell”, where either:

                                                                                                                                                        • The code is excessively specific and a more general function could be abstracted out: addOneToSix() instead of add(1, 6)
                                                                                                                                                        • The code doesn’t make proper use of context/namespacing, so repeats the context unnecessarily, e.g. Triangle::areaOfTriangle instead of Triangle::area.
                                                                                                                                                        1. 1

                                                                                                                                                          Write throwValidationError and not throwVE

                                                                                                                                                          Slightly irrelevant, but I believe the Germans actually quite like abbreviating their compound nouns. e.g. WG (Wohngemeinschaft), GmbH (Gesellschaft mit beschränkter Haftung), U-Bahn, S-Bahn, and so on.