Threads for thedevelopnik

  1. 6

    Programming can be a fine goal if you are interested in just tinkering. But implementing yet another TODO-list app is just busywork (unless, of course, you enjoy writing TODO-list apps. In that case, carry on and more power to you). Why do people do this? Resume padding? Learning some framework? You don’t actually know a new library or framework unless you’ve used it for a couple of months. It makes more sense to learn a framework by actually trying it out in a project you want to implement. That way, you are “forced” to learn the less smooth bits of the framework.

    Often, implementing some toy project in a framework goes smoothly, because you’re just using the basics. That’s barely scratching the surface. If you really want to get a good feel for how useful a framework is, a real project will force you to do nasty things, actually hit into performance bottlenecks and basically expose you to so much pain that you definitely will notice where the framework’s weak spots are. I don’t care how good a framework’s strong suits are, the weak spots can be deal breakers when using it in an actual project.

    You can learn a framework on the job, and any hiring manager who is just playing resume technology bingo should be fired. You can typically learn the basics like the syntax and terminology (exactly that stuff you learn with a toy project) in a few days, on a real project.

    1. 1

      I think the thing for me is I want to be building rea projects using tools I already know and am productive with, unless I don’t have any tools already that fit a project.

      It also helps me when evaluating something to have a comparative experience. Does this tool make a task easier or harder? That’s more difficult to gauge on a novel task. But I agree it shouldn’t just be a toy like a todo list. I have a failed non-trivial project from a few tears back that implements OAuth, talks to document and relational databases, etc that I’ve rebuilt 6 times now in various frameworks/tools because I know the project logic like the back of my hand, but it gives me a good sense of “does this ecosystem have good pre-existing packages,” “how nice are various data structures to work with,” etc.

      Even something like Dave Thomas writes a markdown parser in any new language he’s learning. It’s not huge but it’s not trivial.

      1. 1

        Do you have the source for that project anywhere?

    1. 4

      This is the kind of content that I love seeing here. It resonates so much with me and the mood I’ve been lately. Thanks a lot for sharing it.

      It has been some years that I’ve been talking to my friends that as a developer I’ve been feeling like a “chef that doesn’t cook at home”, we’ve been using this analogy to explain the situation of developers who spend their day job coding stuff that they won’t use, while the stuff they use outside of their job doesn’t contain any piece of software that they made. As if they were chefs that at home only eat ready-made meals. I understand that people are not required to write their own software, that is not the argument I’m making. What I believe is that some people actually want to do that and are not doing it, and that causes some subconscious frustration. Or, that is my own personal case only and no one feels like that.

      Seeing this post and others that were in a similar vein in the last months is pushing me forward to work on my own stuff regardless of business plans or anything similar. Just for the fun of it and for my own personal use. Thanks OP for inspiring me.

      1. 3

        Same. I’ve had this idea for an app to help me in my day to day work visualizing our private ipv4 network space. What is used, and whats available, and where gaps are between CIDRs. I keep trying to build it as a potential SaaS and lose motivation. This has inspired me to just start as an electron app for myself and go from there.

      1. 18

        The bit about how hard it is to store all that plastic fruit and get it ready on demand for your mock store is just one of the most on-point comments about testing at scale ever. Instantly shared with several teams at my job.

        1. 4

          I can’t say I love this article. It makes a number of sadly unjustified assumptions.

          The first useful property Python has is that you can’t misplace the source code for your deployed Python programs. Unless you do something very peculiar, what you deploy is the source code (well, a version of it). With Go you deploy a compiled artifact, which means that you may someday have to find the source code and then try to match your compiled binary up against some version of it.

          This is not exactly a problem unique to Python and Go, but rather to compiled vs interpreted languages in general.

          Either way, you really should be taking care of your source code in some safe version control repository (with additional backups as needed) and not staking your continuity on “whoops I lost my code but I left it on this production server so it’s all fine”.

          Also, for what it’s worth, Go tools make it very easy to imprint build-time variables into the compiled artifact using -ldflags=-X which could just as easily contain a commit ID or some other useful version identifier. Then it is very easy to cross-reference a build artifact with a snapshot of the source.

          I further feel that for people who’re only mildly familiar with the language, Python code is easier to make minor modifications to. Python’s dynamic typing makes for a relatively forgiving environment for many quick things or small changes.

          I’m not sure that I agree with this either. Dynamic typing can feel “easier” to write but it’s also easier to end up with unexpected results through type coercion. The time you gain in writing the code, you inevitably lose testing it.

          1. 4

            I think it depends on how small. The last thing I wrote in Python was a script that opened a yaml file, removed part of the contents and saved it, then ran an outside cli against it, then opened and replaced the contents with the part it originally removed, then saved and ran the same cli against it. This all happens as part of a CI process. I’m pretty much a Python novice and it took me 20 min to write and run manual tests. It has not needed to change in 6 months. It doesn’t really need automated tests. Writing that in Go would have been harder and taken more time, and would have taken just as much time to test.

            That’s the kind of tooling I like Python for, and overall I don’t really like Python, and I love Go.

          1. 2

            This is my preferred modeling system, and we pay for Structurizr.com at work, with our whole system diagram kept in Kotlin (because we’re a hip startup and Java turned people off so I used the Kotlin plugin so it sounded new and hip), so as new services come into the system devs can just open a PR with their documentation of how they fit in overall. It’s really great.

            1. 7

              It’s not a majority opinion, but I believe some things should just be kept forever.

              Sometimes they were deprecated in Python 2 like using Threading.is_alive in favour of Threading.isAlive to be removed in Python 3

              Like this, for example. Is changing the spelling of something really worth breaking this for everyone?

              1. 6

                Yeah or just provide an alias and in the docs note that the snake case version is preferred or something.

                I really really want to like Python. From a sys admin perspective its a fantastic language. One file scripts where you don’t have to deal with virtual env and its not gonna change much.

                From a DevOps perspective (package creation and management, versioning, virtualenv, C based packages not playing well with cloud-oriented distros, stuff like this in doing language version upgrades) I’ve always found it to be a nightmare, and this kind of thing is just another example of that. I tried to install Ansible and am basically unable to do it on a Mac because no version of Python or Pip can agree that I have installed it and it should be in my path.

                I don’t begrudge anyone who uses it or think it’s a bad language, that would be pretty obtuse, but I always avoid it when I can personally.

                1. 7

                  This is what we do in Mercurial. Aliases stay forever but are removed from the documentation.

                  Git does this too. git diff --cached is now a perpetual alias for git diff --staged because the staging area has been variously called the cache and the index. Who cares. Aliases are cheap. Just keep them forever.

                  1. 2

                    I didn’t even realize --cached was deprecated, I use that all the time.

                    1. 3

                      And that’s how it should be. You shouldn’t even notice it changed.

                  2. 4

                    Yeah or just provide an alias and in the docs note that the snake case version is preferred or something.

                    That’s exactly what was done: https://docs.python.org/2.7/library/threading.html - unfortunately, not everybody spots this stuff, and people often ignore deprecation notices.

                    The real problem is that it’s difficult to write a reliable tool to flag and fix this stuff is you can’t reliably do type inference to figure out the provenance of stuff.

                    I tried to install Ansible and am basically unable to do it on a Mac because no version of Python or Pip can agree that I have installed it and it should be in my path.

                    Some of the things Homebrew does makes that difficult. You’re right: it’s a real pain. :-( I’ve used pipx in the past to manage this a bit better, but upgrades of Python can break the symlinks, sometimes for no good reason at all.

                    As far as Ansible goes, I stick to the version installed by Homebrew and avoid any dependencies on any of Ansible’s internals.

                    1. 1

                      From someone who uses Ansible on a daily basis: the best way to use it is by creating a virtualenv for your Ansible project and keeping everything you need in there. My ‘infra’ project has a requirements.txt and a boostrap.sh that creates the virtualenv and install all dependencies. If you try to install Ansible at the system level, you are going to hate your life.

                    2. 6

                      Yeah, or at least bring in some compatibility libraries. Deprecating and removing things that aren’t actually harmful seems like churn for the sake of it.

                      1. 3

                        That (removing cruft, even if not harmful) was basically the reason for Python 3. And everyone agreed with it 10 years ago. And most people using the language now came to it probably after all these decisions have been made, and the need to upgrade to Python 3 was talked about for all this time. Now is simply not the time to question it. Also, making most of those fixes is easy (yes, even if you have to formally fork a library to do a sed over it).

                        1. 1

                          Those breaking changes came with a major version bump. Why not just wait until Python 4 to remove the cruft?

                          1. 3

                            There should ideally never be a Python 4: none of those deprecated bits are meant to be used in Python 3 code. They were only present to ease transition in the short term, and it’s been a decade.

                            1. 2

                              While there are people who prefer a semver-esque approach of bumping the major every time a deprecation cycle finishes, AFAIK Python has no plans to adopt such a process, and intends to just continue doing long deprecation cycles where something gets marked for deprecation with a target release (years in the future) for actually removing it.

                              1. 1

                                Python’s releases are never perfectly backwards compatible. Like most programming languages, old crufty things that have been deprecated for years are sometimes removed.

                                1. 1

                                  That’s a shame. A lot of languages provide some mechanism for backwards compatibility, either by preserving it either at the source or ABI level, or allowing some kind of indication as to what language version or features the code expects. It’s nice to be able pick up a library from years ago without having to worry about bit rot.

                                  1. 2

                                    It’s a library compatibility issue not a language compatibility issue. It’s been deprecated for a decade honestly there’s been plenty of time to fix it

                                    1. 1

                                      This particular library is part of the language. A decade is an awfully short time for a language.

                                      1. 2

                                        Python has never promised that it will eternally support every thing that’s ever been in the language or the standard library. Aside from the extended support period of Python 2.7, it’s never even promised to maintain something as-is on a time scale of a decade.

                                        Python remains a popular and widely-adopted language despite this, which suggests that while you personally may find it a turn-off that the language deprecates things and removes them over time, there are other people who either do not, or are willing to put up with it for sake of having access to a supported version of the language.

                                        This is, incidentally, the opposite of what happens in, say, Java, where the extreme backward-compatibility policy and glacial pace of adding even backwards-compatible new features tends to split people exactly the same way.

                                        1. 2

                                          In a semver-esque world, anything deprecated in 2 is fair game for removal in 3, of course (and if this particular thing was, then I concede). In that way Python 3 is a different language to Python 2, which I believe is how most folks consider it anyway. It’s just a shame that, apparently, you can’t write a Python 3 program and expect it to work with Python 3 in 10 years with no programmatic way of specifying which Python 3 it works in. Nobody would be any worse off if they just waited for Python 4 to clean up.

                                          1. 2

                                            If I write something today, that raises deprecation warnings today, I don’t expect to be able to walk away from it for ten years and then have it continue to work on the latest version. I expect that those deprecation warnings really do mean “this is going to change in the future”, and that I either should clean it up now to get rid of the warnings, or I’ll have to clean it up later if I want it to keep working.

                                            That’s the kind of situation being discussed here – people who wrote code that already raised deprecation warnings at time of writing, and are surprised to find out that those warnings really did mean “this is going to change in the future”.

                                          2. 1

                                            Everyone who wants a Python that doesn’t change has been (and probably still is) using Python 2.7. I expect that we will see more pushback in the community against these sorts of changes as that becomes less tenable.

                                          3. 2
                              2. 4

                                It would be nice if Python had an equivalent of go fix. It’s just a pity things like that are difficult with dynamic languages.