1. 5

    The continuing popularity of AVR is baffling to me. Is Arduino to blame?

    1. 4

      There are better chips (even from Atmel) with proper I2C controllers, but this chip has just a simple offload unit that’s at least a little better than bit-banging in pure software.

      1. 3

        I’m not all that baffled.

        They are cheap (especially the attiny line), relatively simple to understand and well documented (good datasheets), and have great open toolchain support, with gcc, avr-libc and yes, arduino. I personally am fond of msp430 and find they should be more popular than they are.

        It was quite odd when Microchip (of PIC fame) bought the competing Atmel. It didn’t feel right when I learned about it.

        1. 2

          I personally am fond of msp430 and find they should be more popular than they are.

          Yes, MSP430 is one of the default LLVM backends.

          In GCC the support is also pretty up-to-date: https://www.ti.com/tool/download/MSP430-GCC-OPENSOURCE

        2. 3

          I quite liked the AVR32 chips. I even still have an active product being built with an AVR32, though I imagine it’s only a matter of time until those go EOL. I’m not planning on building a new version of it, but I imagine that a new version of it would just use some sort of ARM Cortex-M chip these days.

          I’ve never liked AVR8, though that might be because I’ve only used AVR8 through an inherited Arduino-based project that is absolutely horrific.

        1. 4

          Wow. My first thought was: “who does this?” Then I realized how easy it is to do by accident: mock up some code with hard coded secret, read it from elsewhere later, and accidentally commit the older bytecode.

          This is really a study in sane defaults. Putting .pyc files alongside source is not a sane default. Why not stuff them into a profile dir controlled by Python?

          1. 2

            This is really a study in sane defaults. Putting .pyc files alongside source is not a sane default. Why not stuff them into a profile dir controlled by Python?

            Maybe because that’s traditionally where compilers put binaries built from source?

            I’d argue that it’s on the developer to understand the tools they are using (source control) and properly use features in that tool (e.g. .gitignore) to prevent leaking secrets.

            1. 3

              I think it’s hard to argue that it’s both convention and not a problem when C and C++ projects have largely moved on from doing this (and most encourage completely out of tree builds), and that Python 3.x moved .pyc files to a separate __pycache__ folder.

              1. 2

                Maybe because that’s traditionally where compilers put binaries built from source?

                In the case of a compiler, the user is explicitly requesting to generate an executable to run. In the case of Python, the interpreter just spits them out alongside source, and we have to tell users to ignore them. Intent makes all the difference here.

                I’d argue that it’s on the developer to understand the tools they are using (source control) and properly use features in that tool (e.g. .gitignore) to prevent leaking secrets.

                Agree, though I see Python’s .pyc files as incidental complexity which shouldn’t be foisted on users.

                1. 2

                  I think you could just as easily blame git for not having sensible defaults for excluding compiled files by default.

                  1. 1

                    The problem with this is that git doesn’t (and arguably shouldn’t) know what a compiled file looks like for every single language in existence. It’s up to somebody to tell git that using .gitignore.

                    I don’t know whether there is a common way to set up a new python project (like rust’s cargo init or Haskell’s cabal init) which could be modified to (offer to) create a sensible python .gitignore as part of the process.

                    Btw, you can have a global .gitignore if you know you never want to accidentally commit a certain file pattern:

                    git config --global core.excludesfile '~/.gitignore'

                    This might allow you to have a “sensible default” on your machine at least.

                    1. 2

                      I don’t know whether there is a common way to set up a new python project

                      There’s nothing built in to the language’s packaging toolchain to do this. There are popular third-party options like cookiecutter. GitHub itself also provides stock .gitignore files for many languages, including Python, and supports creating a repository structure from a template.

                      1. 1

                        The global .gitignore is what I’m talking about. I’m sure there’s a reason, but why isn’t that set up with “common” (as defined by whoever makes a PR) compiled filename wildcards? Seems like the problem here is git is overly eager to commit everything (which makes sense!), but should it also not be git’s responsibility to make a reasonable effort to protect users from themselves?

                        Isn’t there something about how with great power comes great responsibility?

                        1. 1

                          Git is a tool, and it assumes that the user knows what they’re doing. To me, what you’re suggesting sounds like a request for a hammer which refuses to hit screws. Git offers many ways to stage and commit changes, most of which aren’t overly eager to commit everything. If users are learning to use things like git add -A by default, that’s more of an education problem. Yes, git could try to make it harder to do the wrong thing, but at a cost of removing features that can be useful. A better option could be to encourage new users to use one of the many git GUIs or TUIs, which make it more obvious what’s being committed and how to pick and choose which changes to commit.

                          To expand on this a bit, not excluding any files (except .git) by default is the “least surprising” option. If you ask git to add all files, it adds all files. If you asked it to add all files and it missed out one or two because it thought they looked like build artefacts from some obscure language you’ve never heard of, that would be confusing and frustrating.

                          1. 1

                            I agree with all of that, but I also find it strange that you put the onus on setting up a proper .gitignore file on python (or any other language’s tooling).

                            I’d argue that since git is not designed to hold build artifacts it is surprising that it does not, by default, attempt to prevent them from being committed. Sure, you can then argue about common vs obscure but that’s a bit of a silly argument since you could just say it’ll only cover languages that are popular enough by some arbitrary metric.

              1. 2

                If you’re familiar with Flask but want websockets I’d highly recommend FastAPI. I have a project that started off with Flask, but I really wanted a websocket for one silly, stupid thing. I wound up using it an excuse to learn FastAPI, and by extension Python’s asyncio ecosystem. FastAPI has been a joy to work with, the community is incredibly friendly and helpful and the documentation is great.

                1. 1

                  I was considering using FastAPI but I was worried about how new it is. Have you ran into any hurdles?

                  1. 1

                    None at all, I’ve found the FastAPI documents to be a lot easier to understand than Flask, but I think a lot of that may have been from increased domain knowledge by the time I got around to working with FastAPI.

                  2. 1

                    If you want websockets and you’re coming from Flask, use Quart instead. It is literally Flask but rewritten from scratch, supporting asyncio.

                    FastAPI is geared towards developing a REST API (which it is absolutely great at).

                    1. 1

                      I see - so it would depend on if you want to use server side rendering or not?

                      1. 1

                        Yeah, pretty much.

                  1. 1

                    I’ve personally found Poetry + Docker to be a really effective combination for building and deploying “web apps”. My audience is small, myself & a few other engineers, so I haven’t had to worry at all about scale, but I’ve found it incredibly easy to maintain my application. Need to update a dependency (poetry show -o)? Just change pyproject.toml and run poetry update. If you want to be fancy with your docker caching do poetry export -f requirements.txt. Don’t forget your docker build afterwards (or commit and let CI build for you).

                    As a bonus, Poetry makes it easy to install into a virtual environment on my development machine, which VSCode (my current editor of choice) can easily pick up and use for type completion and other utilities (formatters, linting, etc), so long as those dependencies are specified as dev-dependencies in pyproject.toml.

                    Previously I had been hand maintaining virtual environments and requirements.txt files and pulling my hair out trying to manage dependencies. Poetry has been an absolute game changer.

                    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. 4

                          A Turin turambar turún’ ambartanen. Another shell that isn’t shell, shells that aren’t shells aren’t worth using because shell’s value is it’s ubiquity. Still, interesting ideas.

                          This brought to you with no small apology to Tolkien.

                          1. 13

                            I’ve used the Fish shell daily for 3-4 years and find it very much worth using, even though it isn’t POSIX compatible. I think there’s great value in alternative shells, even if you’re limited in copy/pasting shell snippets.

                            1. 12

                              So it really depends on the nature of your work. If you’re an individual contributor, NEVER have to do devops type work or actually operate a production service, you can absolutely roll this way and enjoy your highly customized awesomely powerful alternative shell experience.

                              However, if you’re like me, and work in environments where being able to execute standardized runbooks is absolutely critical to getting the job done, running anything but bash is buying yourself a fairly steady diet of thankless, grinding, and ultimately pointless pain.

                              I’ve thought about running an alternative shell at home on my systems that are totally unconnected with work, but the cognitive dissonance of using anything other than bash keeps me from going that way even though I’d love to be using Xonsh by the amazing Anthony Scopatz :)

                              1. 5

                                I’d definitely say so – I’d probably use something else if I were an IC – and ICs should! ICs should be in the habit of trying lots of things, even stuff they don’t necessarily like.

                                I’m a big proponent of Design for Manufacturing, an idea I borrow from the widgety world of making actual things. The idea, as defined by an MFE I know, is that one should build things such that: “The design lends itself to being easily reproduced identically in a reliable, cost-effective manner.”

                                For a delivery-ops guy like me, working in a tightly regulated, safety-critical world of Healthcare, having reproducible, reliable architecture, that’s cheap to replace and repair is critical. Adding a new shell doesn’t move in that needle towards reproducibility, so it’s value has to come from reliability or cheapness, and once you add the fact that most architectures are not totally homogeneous, the cost goes up even more.

                                That’s the hill new shells have to climb, they have to get over ‘sh is just easier to use, it’s already there.’ That’s a very big hill.

                                1. 2

                                  “The design lends itself to being easily reproduced identically in a reliable, cost-effective manner.” “That’s the hill new shells have to climb,”

                                  Or, like with the similar problem posed by C compilers, they just provide a method to extract to whatever the legacy shell is for widespread, standard usage.

                                  EDIT: Just read comment by @ac which suggested same thing. He beat me to it. :)

                                  1. 2

                                    I’ve pondered about transpilers a bit before, for me personally, I’ve learned enough shell that it doesn’t really provide much benefit, but I like that idea a lot more then a distinct, non-compatible shell.

                                    I very much prefer a two-way transpiler. Let me make my old code into new code, so I can run the new code everywhere and convert my existing stuff to the new thing, and let me go back to old code for the machines where I can’t afford to figure out how to get new thing working. That’s a really big ask though.

                                    The way we solve this at $work is basically by writing lots of very small amounts of shell, orchestrated by another tool (ansible and Ansible Tower, in our case). This covers about 90% of the infrastructure, with the remaining bits being so old and crufty (and so resource-poor from an organization perspective) that bugs are often tolerated rather than fixed.

                                2. 4

                                  The counter to alternative shells sounds more like a reason to develop and use alternative shells that coexist with a standard shell. Maybe even with some state synchronized so your playbooks don’t cause effects the preferred shell can’t see and vice versa. I think a shell like newlisp supporting a powerful language with metaprogramming sounds way better than bash. Likewise, one that supports automated checking that it’s working correctly in isolation and/or how it uses the environment. Also maybe something on isolation for security, high availability, or extraction to C for optimization.

                                  There’s lots of possibilities. Needing to use stuff in a standard shell shouldn’t stop them. So, they should replace the standard shell somehow in a way that still lets it be used. I’m a GUI guy whose been away from shell scripting for a long time. So, I can’t say if people can do this easily, already are, or whatever. I’m sure experts here can weigh in on that.

                                3. 7

                                  I work primarily in devops/application architecture – having alternative shells is just a big ol’ no – tbh I’m trying to ween myself off bash 4 and onto pure sh because I have to deal with some pretty old machines for some of our legacy products. Alternative shells are cool, but don’t scale well. They also present increased attack surface for potential hackers to privesc through.

                                  I’m also an odd case, I think shell is a pretty okay language, wart-y, sure, but not as bad as people make it out to be. It’s nice having a tool that I can rely on being everywhere.

                                  1. 14

                                    I work primarily in devops/application architecture

                                    Alternative shells are cool, but don’t scale well.

                                    Non-ubiquitous shells are a little harder to scale, but the cost should be controllable. It depends on what kind of devops you are doing:

                                    • If you are dealing with a limited number of machines (machines that you probably pick names yourself), you can simply install Elvish on each of those machines. The website offers static binaries ready to download, and Elvish is packaged in a lot of Linux distributions. It is going to be a very small part of the process of provisioning a new machine.

                                    • If you are managing some kind of cluster, then you should already be doing most devops work via some kind of cluster management system (e.g. Kubernetes), instead of ssh’ing directly into the cluster nodes. Most of your job involves calling into some API of the cluster manager, from your local workstation. In this case, the number of Elvish instances you need to install is one: that on your workstation.

                                    • If you are running some script in a cluster, then again, your cluster management system should already have a way of pulling in external dependencies - for instance, a Python installation to run Python apps. Elvish has static binaries, which is the easiest kind of external dependency to deal with.

                                    Of course, these are ideal scenarios - maybe you are managing a cluster but it is painful to teach whatever cluster management system to pull in just a single static binary, or you are managing some old machines with an obscure CPU architecture that Elvish doesn’t even cross-compile to. However, those difficulties are by no means absolute, and when the benefit of using Elvish (or any other alternative shell) far outweighs the overheads, large-scale adoption is possible.

                                    Remember that bash – or every shell other than the original bourne shell - also started out as an “alternative shell” and it still hasn’t reached 100% adoption, but that doesn’t prevent people from using it on their workstation, servers, or whatever computer they work with.

                                    1. 4

                                      All good points. I operate on a couple different architectures at various scales (all relatively small, Xe3 or so). Most of the shell I write is traditional, POSIX-only bourne shell, and that’s simply because it’s everywhere without any issue. I could certainly install fish or whatever, or even standardized version of bash, but it’s an added dependency that only provides moderate convenience at the cost of another ansible script to maintain, and increased attack surface.

                                      The other issue is that ~1000 servers or so have very little in common with each other, about 300 of them support one application, that’s the biggest chunk, 4 environments of ~75 machines each, all more or less identical.

                                      The other 700 are a mish mash of versions of different distros, different OSes, different everything, that’s where /bin/sh comes in handy. These are all legacy applications, none of them get any money for new work, they’re all total maintenance mode, any time I spend on them is basically time lost from the business perspective. I definitely don’t want to knock alternative shells as a tool for an individual contributor, but it’s ultimately a much simpler problem for me to say, “I’m just going to write sh” then “I’m going to install elvish across a gagillion arches and hope I don’t break anything”

                                      We drive most cross-cutting work with ansible (that Xe3 is all vms, basically – not quite all, but like 98%), bash really comes in as a tool for debugging more than managing/maintaining. If there is an issue across the infra – say like meltdown/spectre, and I want to see what hosts are vulnerable, it’s really fast for me (and I have to emphasize – for me – I’ve been writing shell for a lot of years, so that tweaks things a lot) to whip up a shell script that’ll send a ping to Prometheus with a 1 or 0 as to whether it’s vulnerable, deploy that across the infra with ansible and set a cronjob to run it. If I wanted to do that with elvish or w/e, I’d need to get that installed on that heterogenous architecture, most of which my boss looks at as ‘why isn’t Joe working on something that makes us money.’

                                      I definitely wouldn’t mind a better sh becoming the norm, and I don’t want to knock elvish, but from my perspective, that ship has sailed till it ports, sh is ubiquitous, bash is functionally ubiquitous, trying to get other stuff working is just a time sink. In 10 years, if elvish or fish or whatever is the most common thing, I’ll probably use that.

                                      1. 1

                                        The other 700 are a mish mash of versions of different distros, different OSes, different everything, that’s where /bin/sh comes in handy.

                                        So, essentially, whatever alternative is built needs to use cross-platform design or techniques to run on about anything. Maybe using cross-platform libraries that facilitate that. That or extraction in my other comment should address this problem, eh?

                                        Far as debugging, alternative shells would bring both a cost and potential benefits. The cost is unfamiliarity might make you less productive since it doesn’t leverage your long experience with existing shell. The potential benefits are features that make debugging a lot easier. They could even outweigh cost depending on how much time they save you. Learning cost might also be minimized if the new shell is based on a language you already know. Maybe actually uses it or a subset of it that’s still better than bash.

                                    2. 6

                                      My only real beef with bash is its array syntax. Other than that, it’s pretty amazing actually, especially as compared with pre bash Bourne Shells.

                                      1. 4

                                        Would you use a better language that compiles to sh?

                                        1. 1

                                          Eh, maybe? Depends on your definition of ‘better.’ I don’t think bash or pure sh are all that bad, but I’ve also been using them for a very long time as a daily driver (I write more shell scripts then virtually anything else, ansible is maybe a close second); so I’m definitely not the target audience.

                                          I could see if I wanted to do a bunch of math, I might need use something else, but if I’m going to use something else, I’m probably jumping to a whole other language. Shell is in a weird place, if the complexity is high enough to need a transpiler, it’s probably high enough to warrant writing something and installing dependencies.

                                          I could see a transpiler being interesting for raising that ceiling, but I don’t know how much value it’d bring.

                                    3. 10

                                      Could not disagree more. POSIX shell is unpleasant to work with and crufty; my shell scripting went through the roof when I realized that: nearly every script I write is designed to be launched by myself; shebangs are a thing; therefore, the specific language that an executable file is written in is very, very often immaterial. I write all my shell scripts in es and I use them everywhere. Almost nothing in my system cares because they’re executable files with the path to their interpreter baked in.

                                      I am really pleased to see alternative non-POSIX shells popping up. In my experience and I suspect the experience of many, the bulk of the sort of scripting that can make someone’s everyday usage smoother need not look anything like bash.

                                      1. 5

                                        Truth; limiting yourself to POSIX sh is a sure way to write terribly verbose and slow scripts. I’d rather put everything into a “POSIX awk” that generates shell code for eval when necessary than ever be forced to write semi-complex pure sh scripts.

                                        bash is a godsend for so many reasons, one of the biggest being process substitution feature.

                                        1. 1

                                          For my part, I agree – I try to generally write “Mostly sh compatible bash” – defaulting to sh-compatible stuff until performance or maintainability warrant using the other thing. Most of the time this works.

                                          The other mitigation is that I write lots of very small scripts and really push the worse-is-better / lots of small tools approach. Lots of the scripting pain can be mitigated by progressively combining small scripts that abstract over all the details and just do a simple, logical thing.

                                          One of the other things we do to mitigate the slowness problem is to design for asynchrony – almost all of the scripts I write are not time-sensitive and run as crons or ats or whatever. We kick ‘em out to the servers and wait the X hours/days/whatever for them to all phone home w/ data about what they did, work on other stuff in the meantime. It really makes it more comfortable to be sh compatible if you can just build things in a way such that you don’t care if it takes a long time.

                                          All that said, most of my job has been “How do we get rid of the pile of ancient servers over there and get our assess to a disposable infrastructure?” Where I can just expect bash 4+ to be available and not have to worry about sh compatibility.

                                        2. 1

                                          A fair cop, I work on a pretty heterogenous group of machines, /bin/sh works consistently on all of them, AIX, IRIX, BSD, Linux, all basically the same.

                                          Despite our (perfectly reasonable) disagreement, I am also generally happy to see new shells pop up. I think they have a nearly impossible task of ousting sh and bash, but it’s still nice to see people playing in my backyard.

                                        3. 6

                                          I don’t think you can disqualify a shell just because it’s not POSIX (or “the same”, or whatever your definition of “shell” is). The shell is a tool, and like all tools, its value depends on the nature of your work and how you decide to use it.

                                          I’ve been using Elvish for more than a year now. I don’t directly manage large numbers of systems by logging into them, but I do interact quite a bit with services through their APIs. Elvish’s native support for complex data structures, and the built-in ability to convert to/from JSON, makes it extremely easy to interact with them, and has allowed me to build very powerful toolkits for doing my work. Having a proper programming language in the shell is very handy for me.

                                          Also, Elvish’s interactive experience is very customizable and friendly. Not much that you cannot do with bash or zsh, but much cleaner/easier to set up.

                                          1. 4

                                            I’ve replied a bunch elsewhere, I don’t mean to necessarily disqualify the work – it definitely looks interesting, and for an individual contributor somewhere who doesn’t have to manage tools at scale, or interact with tools that don’t speak the JSON-y api it offers, etc – that’s where it starts to get tricky.

                                            I said elsewhere in thread, “That’s [the ubiquity of sh-alikes] the hill new shells have to climb, they have to get over ‘sh is just easier to use, it’s already there.’ That’s a very big hill.”

                                            I’d be much more interested if elvish was a superset of sh or bash. I think that part of the reason bash managed to work was that sh was embedded underneath, it was a drop-in replacement. If you’re a guy who, like me, uses a lot of shell to interact with systems, adding new features to that set is valuable, removing old ones is devastating. I’m really disqualifying (as much as I am) on that ground, not just that it’s not POSIX, but that it is less-than-POSIX with the same functionality. That keeps it out of my realm.

                                            Now this may be biased, but I think I’m the target audience in terms of adoption – you convince a guy like me that your shell is worth it, and I’m going to go drop it on my big pile of servers where-ever I’m working. Convincing ICs who deal with their one machine gets you enough adoption to be a curiousity, convince a DevOps/Delivery guy and you get shoved out to every new machine I make and suddenly you’ve got a lot of footprint that someone is going to have to deal with long after I’m gone and onto Johhny Appleshelling the thing at whatever poor schmuck hires me next.

                                            Here’s what I’d really like to see, a shell that offers some of these JSON features as an alternative pipe (maybe ||| is the operator, IDK), adds some better numbercrunching support, and maybe some OO features. All while remaining a superset of POSIX. That’d make the cost of using it very low, which would make it easy to justify adding to my VM building scripts. It’d make the value very high (not having to dip out to another tool to do some basic math would be fucking sweet,), having OO features so I could operate on real ‘shell objects’ and JSON to do easier IO would be really nice as well. Ultimately though you’re fighting uphill against a lot of adoption and a lot of known solutions to these problems (there are patterns for writing shell to be OOish, there’s awk for output processing, these are things which are unpleasant to learn, but once you do, the problem JSON solves drops to a pretty low priority).

                                            I’m really not trying to dismiss the work. Fixing POSIX shell is good work, it’s just not likely to be successful by replacing. Improving (like bash did) is a much better route, IMO.

                                          2. 2

                                            I’d say you’re half right. You’ll always need to use sh, or maybe bash, they’re unlikely to disappear anytime soon. However, why limit yourself to just sh when you’re working on your local machine? You could even take it a step further and ask why are you using curl locally when you could use something like HTTPie instead? Or any of the other “alternative tools” that make things easier, but are hard to justify installing everywhere. Just because a tool is ubiquitous does not mean it’s actually good, it just means that it’s good enough.

                                            I personally enjoy using Elvish on my local machines, it makes me faster and more efficient to get things done. When I have to log into a remote system though I’m forced to use Bash, it’s fine and totally functional, but there’s a lot of stupid things that I hate. For the most ridiculous and trivial example, bash doesn’t actually save it’s history until the user logs out, unlike Elvish (or even IPython) which saves it after each input. While it’s a really minor thing, it’s really, really, really useful when you’re testing low level hardware things that might force an unexpected reboot or power cycle on a server.

                                            I can’t fault you if you want to stay POSIX, that’s a personal choice, but I don’t think it’s fair to write off something new just because there’s something old that works. With that mindset we’d still be smashing two rocks together and painting on cave walls.