1. 1

    “Technical debt” is a metaphor for all software design choices that turn out to be suboptimal, no longer valid, or just plain wrong. They incur a cost on future development. The shortcuts taken today will later slow you down, until you “pay back” the debt by fixing the problems. And it’s not just code: artifacts like architecture, documentation, tests, and domain models, can all suffer from technical debt.

    Do people actually categorize technical debt this way? I’m stuck in a rut with my org because the technical debt definition is too broad. Since we measure and allocate a specific amount to technical debt, it’s important IMO.

    One that I heard that I prefer is “Did we knowingly create that technical debt?” If so it’s tech debt, otherwise it’s not. Any opinions?

    1. 1

      Good point. I have the same quibble with that definition (though I liked the article a lot).

      I don’t think it matters at all if we knowingly created the debt … it only matters that there is something that slows us down that we know we could improve.

      In other words, “debt” is too limiting. Technical “opportunities” also exist, and you’d want to manage them pretty much in the same way – by identifying them, trying to size the potential benefit, and then pitching them to whoever controls the roadmap.

      1. 1

        I’ve rarely run into technical debt that was created knowingly. I don’t think most development is that self-aware, or able to predict the future. Often the decisions are perfectly reasonable at the time. This is where I think the “debt” word in “technical debt” is misleading: when you take on debt in the real world you know you’re doing it. I would best most technical debt in the software world was never taken on intentionally. And wasn’t even debt at the time - it only became debt maybe years later.

        My personal definition is any previous technical decisions - whether it’s code that was written or choices of technologies - that are now burdensome through producing more bugs, having extra complexity compared to alternatives, creating greater mental load or annoyance, or just plain slowing us down.

        Here are some examples of things I consider tech debt, at my current employer. Some or all of these decisions made sense at the time (all of them precede me, though I suspect if I would have made the same call on at least some of them)

        1. One of our teams chose Storm way back in the day. I expect that at the time it was a good decision, and it’s generally served us well, but Storm has been superseded, and is looking pretty long in the tooth, and now it’s holding us back and we want to get off it (or, so I’m told).

        2. The first developer they hired didn’t know what they were doing re: databases and now we’re stuck with Mongo. It’s a mess, but we’re essentially locked in at this point and I can’t see us ever getting off it

        3. A lot of our major application is written in Coffeescript. At the time this was probably a reasonable choice, but it’s now a dead language whose best features have been rolled into Javascript. We have tens of thousands of lines of coffee code, with no tests, that no-one wants to work on. New developers don’t want to learn Coffeescript (even though it’s fairly easy).

        4. We have an application built with NWjs. At the time this was chosen it was probably not at all obvious that Electron would become the clear winner, and that in 2020 would be leagues ahead in terms of features. NWjs putters on (barely) but we (and probably no-one else) would choose it over Electron today.

        1. 1

          That makes sense to me. Thanks for those examples. I guess my definition is a bit limited.

          I want to ask you another question though based on your definition - do you consider bugs technical debt?

          1. 2

            do you consider bugs technical debt?

            Not usually, though I might consider the root cause to be technical debt. For example, we might have a bug because we have a document in Mongo that’s missing a field that our application code is expecting to exist. The top-level cause is the missing field, but the root cause (at least, in my mind) is that Mongo doesn’t support schemas or constraints and if we were using a DB appropriate to the application we wouldn’t be able to have this kind of error at all.

            1. 2

              Got it. Thanks for the conversation!

      1. 6

        Get some good work done on OpenParlour.

        I’ve decided to use TinyDB as the storage layer. The whole point of this is to be a small, downscale community so I love the idea of keeping it to something that has zero external dependencies and has an interface I really like.

        Part of what I’m really enjoying about working on this is that I can take the time to really understand things.

        For instance I wasn’t clear on exactly what Flask was doing with request.get_json and jsonify() and the like, so I was able to write some code to see what’s coming into the route / API endpoint I have defined and play with curl until I really grokked it.

        As I said at the outset, nobody may ever want to run one of these, but I’m learning a ton and keeping my head immersed in code so it’s all good no matter what in my book.

        1. 2

          Hey ! As I understand reading TinyDB documentation it is not suited for concurrent access. I am curious about the way you plan to deal with it in OpenParlour ? :o

          1. 1

            Hi thanks for asking!

            I’m thinking that synchronous operations should be fine for this use case, as most traditional Python servers use WSGI which is a synchronous paradigm.

            So, I don’t think concurrency comes into play here, since we don’t need async and one of the main points behind Open Parlous is to enable individual users with whatever hardware they happen to have on hand to create small, narrow band communities.

            1. 3

              most traditional Python servers use WSGI which is a synchronous paradigm.

              Most people setup their servers so there are multiple WSGI threads / processes (this is the first thing the uwsgi quickstart recommends doing), so you still end up with concurrency. Maybe you won’t do that, but if you don’t you really will only be able to serve a single HTTP request at a time. Perhaps this fits your definition of narrow band :) If so, I’d recommend at least serving static assets in a different, concurrent way.

              Also, as someone who maintains a production Mongo database I’ll throw in my usual recommendation to avoid non-relational / schemaless databases for anything but throwaway of projects. There’s some extra initial overhead to setting up Sqlite with SqlAlchemy but I think it’s worth it.

              1. 1

                Thank you very much for the advice. You’re right. My initial rationale was “Well some high profile projects like Quokka use it. How did they get around that?”

                Turns out they didn’t. They use the TinyDB MongoDB compat layer so you can transparently switch to MongoDB if you need the capability for multiple users accessing the admin UI at once.

                Back to sqlite and SQLAlchemy :) I appreciate learning about this now before I got too far along.

        1. 17

          The more and more I read about it and think about it, the change to the way we’ve operated our economies over the last 30 years is appalling. Outsourcing millions of jobs to China and India for the profit of the rich has decimated the working and middle class, and outsourcing critical infrastructure and critical privacy-sensitive data handling as explained in the article should simply be illegal.

          Communication networks are critical infrastructure. They should be manufactured, owned, operated and serviced by the government like any other critical infrastructure.

          1. 13

            Outsourcing millions of jobs to China and India for the profit of the rich has decimated the working and middle class

            Outsourcing millions of jobs to China and India has also pulled hundreds of millions of people out of abject poverty. The “decimated“ working classes in the West haven’t fallen nearly as far as the poor in China have risen. We ought to be cheering, if we value all human life and opportunity equally.

            To quote the Wikipedia article on poverty in China:

            decades of economic growth have largely eradicated urban poverty.[1][2][3] The dramatic progress in reducing poverty over the past three decades in China is well known. According to the World Bank, more than 850 million Chinese people have been lifted out of extreme poverty; China’s poverty rate fell from 88 percent in 1981 to 0.7 percent in 2015

            Don’t disagree on the national security part of your comment: we ought to be very concerned about the Chinese government and their influence

            1. 4

              China could have industralised without us outsourcing jobs to them. Who was outsourcing jobs to the UK when it industralised? Nobody. China didn’t even have to invent the bloody technology. It was already well documented. The idea that without outsourcing, India and China wouldn’t have industralised is just silly.

              1. 11

                The UK industrialised on the backs of its colonial possessions. It extracted great wealth from them, wrecked their native industries and forced them into being captive markets for British goods.

                1. 2

                  The UK would still have industrialised with that. Germany industralised without having any significant colonial possessions.

                  1. 8

                    Togo, Namibia, Ghana, Tanzania, Cameroon, and Papua New Guinea would probably dispute the significance of the genocides and resource theft that Germany committed during colonialism.

                    https://en.wikipedia.org/wiki/Shark_Island_Concentration_Camp

                    1. 1

                      Perhaps. And I do agree that China and India could have industrialised without western outsourcing.

              2. 4

                Communication networks are critical infrastructure. They should be manufactured, owned, operated and serviced by the government like any other critical infrastructure.

                Right on. It will take a major event to shift this mindset. Unfortunately the security industry is split between snake oil solutions and black hat mentalities. I believe there’s more to it; specifically, robust, trustworthy infrastructure that is rigorously verified, free of unnecessary dependencies, and as user-friendly as possible. It’s not glamorous but it is necessary.

                1. 1

                  They should be manufactured, owned, operated and serviced by the government like any other critical infrastructure.

                  Yes. Let Flint, Michigan be responsible for their Telecom hardware. They definitely have not made any mistakes with their infrastructure that lead to major problems for their citizens. That they are not the only responsible party is not adequate defense.

                  1. 3

                    They aren’t a responsible party. There’s no reason I can think of to make that kind of infrastructure locally controlled. The whole advantage of being America is you have the best and biggest economy of scale the world has ever seen. Infrastructure is a national security issue and should be a national concern.

                    1. 1

                      Infrastructure might be a national concern, but it’s a local problem. You can’t possibly have a single contractor do all the work to maintain a system, there is no way for the government to afford to maintain such a system, and it will end up coming down to local municipalities no matter what.

                      1. 3

                        Why would a contractor do it? That’s what the government is for.

                        there is no way for the government to afford to maintain such a system, and it will end up coming down to local municipalities no matter what.

                        Two things.

                        Firstly, how you allocate resources between national and local governments is totally up to the national government, which is sovereign. Allocating all the national resources to local governments and then saying ‘the national government can’t afford to do infrastructure’ is silly.

                        Secondly, if any first world national government can afford to maintain infrastructure, the USA can. People that say ‘oh but the USA is huge so it’s different’ really annoy me. Yeah, it’s huge. There’s 325 million people to provide infrastructure for, sure. There’s also 325 million people to pay taxes. It scales linearly…

                        1. 1

                          sublinearly actually

                    2. 2

                      and the private interests in flint get a pass?

                      1. 1

                        whoosh

                        1. 1

                          what your entire comment was sarcastic?

                  1. 19

                    Soundness is definitely a thing that can come up, though in handling tens of thousands of lines I don’t feel like I’ve hit it directly.

                    On the other hand, Typescript’s type system is still the most useful typesystem I have ever used. The way unions, “everything is a dictionary”, being able to filter out keys and the like, and everything else work together mean that I can write business logic that handles really dynamic data shapes, and still get guarantees that are basically impossible in other languages without generating loads of wrapper types.

                    For example just being able to inline declare a variable of having “type A and type B” is such a great way of allowing for new APIs.

                    Ultimately Typescript not seeing typing as a mechanism for implementing the language execution semantics, but really as a checker of code validity, opened it up to really practical advantages.

                    1. -2

                      On the other hand, Typescript’s type system is still the most useful typesystem I have ever used.

                      I have a canary of sorts which I use to guess whether I will appreciate a type system.

                      1 == "1"
                      

                      The correct way to handle this is to issue a type error at compile time (or at least runtime if the language doesn’t have a significant check phase in the compiler). The two ways to fail this are:

                      • typecheck, return false (python2, python3, ruby, crystal do this)
                      • typecheck, return true (typescript, javascript, php do this)

                      I haven’t made final decisions which of these is scarier.

                      Interestingly, some of the above languages do fine if we use inequality instead:

                      1 >= "1"
                      

                      Some languages from the top of my head that do this the way I like it: Haskell (and I assume many of the other strongly typed functional languages as well), Common Lisp (at least sbcl, dunno if it’s standard), Rust, Zig, Nim.

                      1. 9

                        To be fair you should always use === in TypeScript, then it works as expected.

                        1. 6

                          To be fair you should always use === in TypeScript

                          To be even fairer, this is not even a Typescript thing, it’s a Javascript thing? A linter on a JS project will complain about the use of ==, without going near Typescript.

                          1. 3

                            Throwing my 2-cents in here, PHP is the same. Using === will enforce type checking on the comparison.

                            1. 3

                              I don’t think it “type checks” per se in PHP, but rather avoids doing an implicit conversion.

                              1 == "1" evaluates to true, while 1 === "1" evaluates to false. It won’t error out, like a type checker will typically do for you.

                            2. 1

                              To be fairest, Typescript actually does this the way I want. See https://lobste.rs/s/qfpbk9/is_typescript_worth_it#c_hs0olb

                            3. 2

                              Does it error, or does it return false like python, ruby, crystal (and js with ===)?

                              1. 2

                                It does error at compile time.

                                1. 1

                                  Yeah, seems like both == and === work as I want in Typescript. See https://lobste.rs/s/qfpbk9/is_typescript_worth_it#c_hs0olb

                                  I’m liking Typescript right now.

                              2. 1

                                Ah, forgot about that. Do ts linters warn about ==?

                                1. 2

                                  Yeah they do.

                              3. 2

                                I don’t understand why a typecheck of the integer numeral 1 and a string happening to contain the numeral one returning false is scary.

                                I know nearly zero about type theory. Could you please explain?

                                1. 6

                                  Because it’s a category mistake – it’s a nonsensical question.

                                  1. 5

                                    Ah I think I see, so that’s what demands that the response be an exception rather than false.

                                    It’s not just “Is a number equal to a string?” “No.” it’s “That’s not even a sensical question to ask.”

                                    I guess I feel like that’s a bit counter intuitive, since I generally want boolean operators to provide answers in boolean form, but then I don’t know anything about category theory either.

                                    sigh clearly I have a lot to learn :)

                                    1. 9

                                      Well, it depends. Mathematically there’s nothing “wrong” with it, but it raises some uncomfortable questions. Like “what’s the domain of the == function?” Turns out, equality is not a mathematical function! If it was, everything would be in its domain, aka the forbidden Set Of All Sets. There’s a couple ways around this: the type way is to say that == is actually a collection of functions, one for each type. This ends up working out, and makes comparing different types impossible.

                                      But there are other formulations! Like there’s nothing wrong with saying int and str always compare false, you just have to be clear what your mathematical axioms are.

                                      1. 4

                                        I think it might help to look at the Haskell signature for ==:

                                        (==) :: a -> a -> Bool

                                        It makes it clear that you can only compare two values of the same type.

                                        1. 4

                                          In Lisps, you typically have = and equal?/equalp. With = you’re asking “are these two things numerically equal”, which is a nonsensical thing to ask about a string and an integer (or a vector and a list, or a character and a boolean, or two other non-number objects). With equal? you’re asking “are these two objects structurally the same thing?”, which makes sense and “false” would be the obvious answer for objects of different types.

                                          So presumably in many languages, == is the equal? in the above description, but there’s no separate = predicate.

                                          And then there’s eq?/eqp, which asks “are these things the same object?”, which is a question of identity, not equality. That’s similar to what the is operator does in Python, for example. But yeah, this stuff is confusing if you’ve only been exposed to languages that conflate these different ways of comparing because you’re not used to having to make the choice of which kind of comparison to use in different situations.

                                          1. 1

                                            so that’s what demands that the response be an exception rather than false

                                            I think no one wants it to throw an exception, but to simply not compile.

                                      2. 2

                                        1 == "1" is a classic JS gotcha (double equals is not “check for equality” but “check for equality and if it fails check for toString equality”) and 1 === "1" does what you expect.

                                        I have decently used “fancy type” languages like Haskell, Purescript and Rust. Their type systems still make me somewhat unhappy compared to TS for “enterprise apps” (the one thing that I kinda wish that TS had but would bef impossible given soundness and how stuff works is the return type polymorphism).

                                        1. 2

                                          1 == "1" is a classic JS gotcha

                                          I call it a classic maldesign, but ok :)

                                          1. 3

                                            I mean it’s not good, and there’s a reason you don’t see == anywhere in most codebases.

                                            I guess it’s just not an issue that one hits in practice if you’re an experienced practitioner (compare to…. array bounds errors that even experienced C programmers will hit often). It’s a thing you set your linter to notice, and then never do it.

                                        2. 1

                                          Couldn’t edit this any longer, so will make an errata to my comment and mark it incorrect:

                                          Contrary to what I stated, Typescript does this exactly as I think is best, i.e. signal an error at compile time.

                                          vegai@Vesas-iMac ~/tmp> cat derp.ts
                                          
                                          let derp1 = 1 == "1";
                                          let derp2 = 1 === "1";
                                          
                                          
                                          vegai@Vesas-iMac ~/tmp> tsc derp.ts
                                          derp.ts:2:13 - error TS2367: This condition will always return 'false' since the types 'number' and 'string' have no overlap.
                                          
                                          2 let derp1 = 1 == "1";
                                                        ~~~~~~~~
                                          
                                          derp.ts:3:13 - error TS2367: This condition will always return 'false' since the types 'number' and 'string' have no overlap.
                                          
                                          3 let derp2 = 1 === "1";
                                                        ~~~~~~~~~
                                          
                                          
                                          Found 2 errors.
                                          

                                          Don’t even need the strict mode. So apologies to everyone for that bit of bullshitting – I went to check the behaviour in the first typescript playground I found, which for some reason did not behave like this.

                                      1. 4

                                        In my experience, learning to get used to asking dumb questions in public (and the skill of being able to know what you want to ask) was also a big part of attaining success during internships. In a 3-4 month time span, there’s not a ton of time to get acclimatized to all of the nuances of who on the team knows what, so the most time-effective way of getting all the knowledge I needed was to put myself out there early and ask whatever stupid questions I needed to early on. It was initially very difficult, especially when having to ask a question to someone else in person. However, I have been fortunate enough to be placed on teams where people in general don’t mind receiving basic questions, which really helped me get over the sense of embarrassment and just focus on being able to retrieve the answers and get unstuck.

                                        1. 8

                                          learning to get used to asking dumb questions in public

                                          Of all the times people I’ve been in a meeting or a one-to-one conversation and someone’s said “can I ask a dumb question” and I’ve thought the following question was actually dumb… hardly ever? People who think they’re asking dumb questions very rarely are.

                                          I’d really hope that your experience is more common than it seems like you think it is. The idea that interns are being put on teams where people don’t have time for their questions just kinda makes me sad. We were all beginners once.

                                          https://xkcd.com/1053/

                                        1. 11

                                          Here’s a much more intuitive explanation that doesn’t require any fancy math. Since there’s a 50% chance each time, for any sequence of 2 tosses you can expect to get 1 of each. As it happens, regardless of the order (because multiplication is commutative), you end up with 90% of what you had before at the end of 2 tosses: 0.6 * 1.5 = 0.9. if you lose 10% every 2 tosses, you eventually end up with roughly zilch.

                                          1. 4

                                            In this case the wealth converges to a scalar, but that might not be the case and there you need a little bit more complicated math. What we are trying to show is that it is important to calculate the time average instead of the ensemble average. In many social sciences the ensemble average is used instead of the time average. Obviously this has enormous consequences.

                                            If you liked the post I recommend you read this post by Taleb: https://medium.com/incerto/the-logic-of-risk-taking-107bf41029d3

                                            1. 1

                                              0.6 * 1.5 = 0.9

                                              I didn’t understand from the article (because I didn’t really understand the article) where the values 0.6 and 1.5 come from. Could you (or @unbalancedparentheses) please explain that?

                                              1. 2

                                                You either win 50% (i.e. multiply your current wealth by 1.5) or lose 40% (i.e. multiply your current wealth by 0.6).

                                                1. 1

                                                  Thank you, that makes sense :)

                                            1. 4

                                              If your laptop is not sufficiently powerful to run Pycharm or Visual Studio Code, I would respectfully submit that the only thing you’ll find acceptable for speed is either emacs or vim. Both are excellent choices and offer simple code completion and refactoring facilities. Neither will be at feature parity with a full featured IDE however. (Before the Faithful rise up to smite me, I eschewed IDEs and ran fully tricked out Vim and Emacs for YEARS. The refactoring facilities available amount to the ‘rope’ library which can’t hold a candle to an IDE.)

                                              Barring that however, have you considered doing a bit of investigation to see why Pycharm and Visual Studio Code run unacceptably slow?

                                              • What platform are you using?
                                              • Is your laptop memory, IO, or CPU constrained?
                                              1. 2

                                                Barring that however, have you considered doing a bit of investigation to see why Pycharm and Visual Studio Code run unacceptably slow?

                                                Check that you don’t have any plugins enabled that you aren’t using. I haven’t had too many bad experiences with plugins for Jetbrains products, either first or third party, but it’s probably work checking.

                                                Also, make sure you are excluding folders that don’t need to be indexed / covered in search results. Typically you only want your own code to be included. In Node projects this would be the node_modules folder, for Python it’ll be wherever pip is installing to (this may be excluded already). You may also want to exclude any build / output / data folders that you have, too. This can really impact indexing speed (system load) and the responsiveness of search.

                                              1. 3

                                                Implementing the visitor pattern for the Inko compiler, which is needed for various compiler passes (e.g. type checking the code). I don’t like the visitor pattern much, but without pattern matching (lots of work to implement this) and multimethods (also a lot of work, and can be confusing while debugging) I am not left with many options. Fortunately, I don’t anticipate the AST types to change much, so most of the visitors setup cost is a one-time cost.

                                                1. 1

                                                  I’m not sure if you have any involvement with the Inko website, but I like the little code snippets on the front page, and the dropdown that lets me select examples. It’s a simple way to give me a feeling of how the language looks in different scenarios.

                                                  1. 1

                                                    I do, I’m the author of said website/language. Thanks for the feedback! :)

                                                1. 4

                                                  Work:

                                                  • chewing through a bunch of small bugs in our new editor that are collectively driving our users up a wall
                                                  • trying to further the use of Immer in our code base

                                                  Hobby:

                                                  • trying to land some actual improvements to Factor, since I’ve basically been absent for months
                                                  • getting a Nebula VPN up so I can hit my home network on my upcoming road trip
                                                  • finishing a blog post I’ve been working on about CouchDB/PouchDB being a great tool to use for the personal web
                                                  • figuring out whether one of my DeLorean’s lights is actually burnt out, or the circuit board went bad again (I replaced a bunch of physical bulbs with LEDs, which required a custom circuit board due to the lower voltages; this is my second circuit board already)

                                                  Personal:

                                                  • go the entire week while never having my phone out while playing with my son
                                                  1. 2

                                                    trying to further the use of Immer in our code base

                                                    Check this out! https://github.com/tc39/proposal-record-tuple

                                                    1. 2

                                                      I’ve complained in other threads about more and more features being added to JS, but this one I can get behind :)

                                                  1. 2

                                                    I see this is marked as a show. Does that mean you wrote magic wormhole?

                                                    If so, could you talk a little bit about what it was like to design and deploy the system? Not how it works, but more along the lines of how it came into being, when/why you decided to do it, and how you got the resources to deploy it.

                                                    1. 2

                                                      No. The description never said that it needed to be (that’s what the author bit is for). Did I misunderstand the tag?

                                                      1. 11

                                                        IIUC “author” typically means “I wrote this [article/blog/prose]” whereas “show” means “I created this [usually software]”. It’s generally understood that applying the “show” tag means you’re the creator.

                                                    1. 25

                                                      This is why I’ve given up on Haskell a few times, a few hundred pages into a book like Haskell Programming from First Principals and I still can’t really understand open source projects or blog posts. So I (and I bet plenty of other devs) said “ehh, guess I’ll try Rust”.

                                                      1. 13

                                                        The most common kind of blog post about Haskell (and the most common kind of Haskell blogger) are the ones who want to push the type system to absurd extremes in the pursuit of mathematical masturbation. Not being able to follow all of those means nothing.

                                                        Here’s a small calculator project I wrote in Haskell. Aside from parser combinators, there’s nothing fancy in there that shouldn’t be covered in a Haskell introduction.

                                                        https://github.com/ninedotnine/happy-space

                                                        1. 6

                                                          The world would be better if people writing those posts modelled them upon notable papers like https://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf and http://gallium.inria.fr/~huet/PUBLIC/zip.pdf that always start with motivating examples and describe the solution clearly.

                                                          1. 3

                                                            The most common kind of blog post about Haskell (and the most common kind of Haskell blogger) are the ones who want to push the type system to absurd extremes in the pursuit of mathematical masturbation.

                                                            This is what the original link is getting at, but my personal feeling is that there is a much deeper cultural issue at the heart of this. My experience is that Haskell specifically attracts people who have an interest in mathematics, or get enjoyment from mathematics.

                                                            When it comes to programming there are many people like me, who some might say are at the software engineering end of the spectrum (versus the computer science end.) I appreciate the importance of mathematics and the enjoyment others can get from it, but Haskell is very much more compatible with these people than me. This isn’t a bad thing, but it means that there is a low likelihood that community and language will have broad appeal. Your contribution is a good example of what the community could aim for, but you are only one contributor.

                                                            Not being able to follow all of those means nothing.

                                                            This is all well and good, except that it means people will decide to do other things with their time which may be limited. Returning to where people are on the love for mathematics, or computer science to software engineering spectrums, they may find that Rust is a more productive experience.

                                                            1. 2

                                                              Haskell specifically attracts people who have an interest in mathematics, or get enjoyment from mathematics.

                                                              I think this is almost certainly true.

                                                              …which raises a question about both articles: what is the point of telling Haskell aficionados to write “simple Haskell”? Why would you advise somebody to “exit their ivory tower” if the “ivory tower” is exactly the reason to use Haskell in the first place?

                                                              1. 1

                                                                I think you highlighted that in your post. You talk about absurd extremes and provide a less fancy example. A good contingent of the folks coming to the community with the appropriate background are still probably not interested in the fancy stuff initially. I think the advice is reasonable because it’s really talking about creating material for others as opposed to the demonstrating the upper bounds of the language. Both have a place, but there probably isn’t a lot of overlap.

                                                            2. 2

                                                              Here’s a small calculator project I wrote in Haskell.

                                                              BTW: why is the C code (shunting_yard.c) needed? How would it look in pure Haskell? Or does that repository contain equivalent implementations in both C and Haskell?

                                                              1. 1

                                                                That’s a relic from a first implementation. I ended up not going with it and rewriting everything in Haskell. Apparently I forgot to delete it, thanks.

                                                            3. -5

                                                              If you find typical open source Haskell code confusing I’d stay well clear of Rust.

                                                              1. 0

                                                                This is a toxic comment.

                                                                1. 11

                                                                  It is? Can you explain why? I think I must be missing something. “Toxic” is quite a strong term.

                                                                  1. 7

                                                                    Here’s the different perspectives in which it can function (be read) in my opinion:

                                                                    • Bashing people who struggle with Haskell and discouraging them from learning something else in the process
                                                                    • Substance-less bashing of how approachable Rust is. Of course, critique is great, but just randomly bashing things without context or substance is simply toxic. It promotes a culture of pessimism, a culture which is extremely discouraging for a lot of people.

                                                                    I’m not saying the person intended to be toxic, but the comment, even if accidentally, functions as such.

                                                                    1. 1

                                                                      Thanks, I see now where you’re coming from.

                                                                      Substance-less bashing of how approachable Rust is. Of course, critique is great, but just randomly bashing things without context or substance is simply toxic.

                                                                      Not being a dick, but I think a similar criticism could be applied to your original comment, which labeled something as toxic without explaining why 🙂

                                                                      1. 1

                                                                        I believe making people think about the things they’ve said on their own is important. If I just said “this is toxic because X” the poster would just go “oh ok I see why you’d say that” and be done with it, but if I just say that I think a comment is toxic, it forces the poster to think more deeply about what they posted. In this case, it was not at all too vague what the problem was with the comment and you can see this in the poster’s own, independent and thoughtful reply here.

                                                                  2. 5

                                                                    I hope it isn’t interpreted that way. What I am saying is that Rust is a horrendously complicated language, so if Haskell is confusing then switching to Rust isn’t going to help.

                                                                    I see now that it could be interpreted as ‘If something as simple as typical open source Haskell code confuses you, then Rust is definitely going to be hard for you, peabrain’ but I can assure you that’s not what I meant!

                                                                    1. 5

                                                                      For example C++ is also a very complicated language (and much more „dirty“ than Rust) and despite that, it is more accessible/acceptable for more people than Haskell. In the TIOBE Index, C++ is at 4. position while Haskell is at 41. with 0,240 %. The first one is Java, just for record. Or in the Stack Overflow survey, the most loved is Rust with 83,5 %, while Haskell is completely missing (which is really weird – or I missed something? Ctrl+F has not found any occurrence).

                                                                      It has probably more dimensions that just complexity. Besides the complexity there is something like „mental compatibility“ or how to call it. And it seems that more people are compatible rather with „imperative recipes“ that with „pure math“. And they would rather deal with complexity than switch to a different paradigm.

                                                                      Or what are other explanations, why there are not more Haskell projects and why more companies are not using Haskell? If this technology would provide more developer performance (implement more useful features in lesser time), less bugs or better maintenance, why would they not use Haskell? It would mean profit for them! One explanation is in the article above, it is about the learning curve and friendliness and accessibility of the community to the newcomers. But is it the main reason? Would it be enough to write simpler code and articles friendly to novices… and Haskell would then magically rise in the statistics or even become prevalent? Or are there other reasons? How to deal with them?

                                                                      1. 1

                                                                        No worries, I didn’t think that the comment was meant that way, but I think it’s worth the reminder that subtleties in tone don’t carry well over the internet, and many junior devs may read these threads and take comments like that to heart, eventually internalizing a sense of negativity/pessimism, either about other peoples projects or their own. And imo this is something that is very common.

                                                                1. 5

                                                                  Trying to create a wind rose for a town I’m interested in moving to, because some of my family are concerned that it will be super windy and that it will “drive you mad”. So I have got hold of the raw weather station data from NIWA (NZ weather data org) and I’m going to try and compare it to where I currently live.

                                                                  My personal theory is that it matters less how windy it is overall, and more how many days the wind is strong enough to make being outside less/no fun. So I’ll try to figure that out, too.

                                                                  1. 1

                                                                    Write in Typescript, use from JS (obvi), Python, Java, or .Net. It’s an interesting idea - is this an experiment from AWS, an indicator of future direction, or something else?

                                                                    1. 1

                                                                      Note that let won’t work in about 95% of browsers, never mind that the IE11 behaviour is broken enough that it most likely will cause bugs.

                                                                      A lot of devs consider these kind of numbers insignificant, and sneer at users for not using a “modern” browser. I don’t necessarily disagree that it’s annoying that people keep using really old browsers, but at the end of the day it’s a reality we’ll have to deal with. To me it seems somewhat akin to rejecting 5% of your customer base because you don’t like their backwards wearing baseball caps.

                                                                      1. 4

                                                                        Based on what I’m seeing on that site, (using the Usage Relative graphs), it does work in 95% of browsers. Granted, I suspect that most people using “let” are using it along with Babel, or they are explicitly targeting webapps that require a “modern” browser. Anymore, modern Line of Business webapps should have a pretty good feel for what their users are using.

                                                                        Personally, though, I try to write code that is at least compatible with Edge/IE11. That makes it eaiser to do things like host a website in a C# WebBrowser control.

                                                                        1. 2

                                                                          It all depends on what you’re making, of course, and “never use let” is clearly simplistic and wrong advice. But I almost never see this listed as a consideration at all, including on this otherwise resonable article.

                                                                          I always feel that “it does work for 95% of users” is the wrong way to look at it, and “it doesn’t work for 5%” is much more useful. I’ve been intending to make a version of caniuse.com which lists the browsers in which a feature won’t work, instead of the browsers in which it does work (edit: I actually went ahead and created this: https://github.com/arp242/cantuse)

                                                                          There are a number of other features which won’t work for (IMHO often significant) number of people, like arrow functions (~7%).

                                                                          Babel is nice, but also a complex build step, which has quite a few downsides. Especially for sites/apps with a limited amount of JS (which are most sites/apps), I don’t find the minor convenience that some of these newer JS features offer to be worth adding complex build steps.

                                                                          1. 1

                                                                            Well, realize that there are other developers that do check caniuse and co, and definitely try to consider less than mainstream browsers.

                                                                            I’ve definitely asked for consideration of less-than-mainstream browser in the past. It’s not something that I do all the time, however.

                                                                        2. 3

                                                                          The obvious solution (which you’ve already stated you don’t like) is to use Babel to transform to whatever browsers you want to support. Many people already do this.

                                                                          But quite frankly, the last 5% isn’t important unless it’s a business-critical segment, which seems increasingly unlikely. Edge was introduced nearly 5 years ago now. With its upcoming switch to blink, there’s even less incentive to cater to these old browsers.

                                                                          I think many of us operate on the 80/20 rule, and I’m extremely confident in saying the last 5% of users are an edge case that would only hurt productivity, developer happiness, and feature progress.

                                                                          If you want to cater to 100%, you probably shouldn’t use any JavaScript.

                                                                          1. 2

                                                                            I find those some bold statements: who says those users aren’t important for your business? Businesses reguarly make some fairly significant investments in e.g. advertising, rebrands, etc. to get 5% increase in their user base.

                                                                            I don’t think that there would be a massive loss in “productivity, developer happiness, and feature progress” by simply using var. Is let a bit better? Sure. Does it make a large difference? Not really.

                                                                            If you want to cater to 100%, you probably shouldn’t use any JavaScript.

                                                                            Surely 99.5% is better than 90% or 95%.

                                                                            1. 2

                                                                              who says those users aren’t important for your business?

                                                                              […] the last 5% isn’t important unless it’s a business-critical segment

                                                                              I think the person you’re replying to covered that concern? 🙂

                                                                              I have that 5%-but-critical-users case at my job: one customer, with only a handful of users, but they pay us a lot, so our app still works with IE11. I suspect, with knowing the details, that one of the reasons they pay us well is that we do continue to support them.

                                                                              1. 1

                                                                                About 10% of the users at $work are using IE11, representing over half our paying users.

                                                                                Medical sector :/

                                                                              2. 2

                                                                                I’ve spent a number of years working in the health-care space, and that’s a world that’s notorious for horrid outdated tech – think ancient versions of Windows, IE6, the whole nine yards. Which means it’s not even a question of modern JavaScript being available, it’s a question of basic modern HTML/CSS.

                                                                                And as strange as it may sound, I’ve seen multiple companies in that space adopt a strategy of “tell us your mailing address, we’ll send you a Chromebook”. Often that works out to be cheaper than figuring out some doctor’s office’s ancient operating system + browser and trying to cater to it.

                                                                                1. 1

                                                                                  The difference between getting from 50% to 55% is vastly different than going from 90% to 95%, or even worse (in this case) 95%-100%.

                                                                                  It’s not a matter of “simply using var.” There is a lot of stuff in modern javascript that makes life miles better than it used to be.

                                                                                  1. 1

                                                                                    Yeah, but you can use all that stuff and still compile to es3 quite easily.

                                                                                    1. 1

                                                                                      They were talking about NOT wanting to compile things. If you’re adding a compile step, it really doesn’t matter at all obviously. You can target whatever you want.

                                                                              3. 2

                                                                                That link says the exact opposite of what you just said.

                                                                                1. 1

                                                                                  You can use a transpiler to sort that out. No need to manually use var.

                                                                                1. 2

                                                                                  I wrote six pages last night of reflections on the composition and breakdown of systems based on my experience for my eventual website.

                                                                                  Previously undiscovered moisture damage in my new home is looking like it’s going to $10k+ to fix, so I’m working on vacation days for extra money and applying as an adjunct professor at a local college for extra money. I have no idea how much an adjunct professor would make or if the money is worth the hours. I’ve already talked to them and they’re interested and my boss is OK with part-time work, but I need to write a “CV” and I’m not entirely sure what’s supposed to go into that since I’ve only ever done resumes.

                                                                                  1. 1

                                                                                    but I need to write a “CV” and I’m not entirely sure what’s supposed to go into that since I’ve only ever done resumes.

                                                                                    Where I’m from CV and resumé are interchangeable terms.

                                                                                  1. 1

                                                                                    Can this affect plain Docker containers, too, outside of k8s or Mesos? From a quick Google it looks like Docker does use CFS (completely fair scheduler)

                                                                                    1. 2

                                                                                      Yes, it can. Docker supports both cpu limiting mechanisms so it depends on how you are setting up your containers.

                                                                                      1. 1

                                                                                        As far as I can tell we’re not setting any of the --cpu-* flags when we’re starting our Elasticsearch containers (the application I was worried about) so I think we’re probably not affected. Also, docker inspect is showing 0 for the various CPU options, which I assume means “not set”.

                                                                                    1. 2

                                                                                      another interesting one that’s not mentioned there, that I only learned recently. Instead of the “try…except: pass” anti pattern - use with contextlib.suppress when you want to ignore a possible exception.

                                                                                      1. 1

                                                                                        What makes try ... except: pass an anti pattern? Is it that except is supposed to be used for handling exceptions, and by passing you’re not actually doing it? Because I would probably find contextlib.suppress less obvious, unless I was familiar with the function already (suppress? suppress what?) than try ... except: pass.

                                                                                        (I’m assuming that in either case you will want to comment on why you’re supressing / passing on the exception)

                                                                                        1. 2
                                                                                          1. While I don’t find suppress less obvious I get that it might seem so to some. You’re asking “suppress what” - well you call suppress with the exception type you want to suppress just like the except clause you’d write. is with contextlib.suppress(OSError):... less obvious than try...except OSError:pass.
                                                                                            Also consider that the op’s link mentions for..else. One of the least obvious things that you need to know about this somewhat obscure language feature. But I agree with them that it’s better than the alternative, and for idiomatic python code it should be that not using them is an anti-pattern.

                                                                                          2. I think try...except:pass as an anti-pattern because it defines an error-handling clause without any error handling in it. Instead it means “there’s no error to handle, this shouldn’t be considered an error”. And “suppressing an error” is a logical term for it and is a much cleaner solution.

                                                                                          3. Sometimes you’ll want to comment on what you are suppressing. sometimes it should be obvious. The documentation of suppress brings up the case of trying to open a file and suppressing FileNotFoundError as an example of use. I wouldn’t feel the need to comment about that (either when using suppress or in an empty except clause). What do you do when the file wasn’t found and why you don’t handle that error case is up to your program’s logic, sometimes it would make obvious sense. Other times it won’t.

                                                                                          1. 1

                                                                                            Thanks for the explanation, that all makes sense to me 🙂

                                                                                      1. 3

                                                                                        I discovered that creating a backend API and rich client side single page app (SPA) came with a ton of overhead.

                                                                                        My flow with Ember was like:

                                                                                        1. Figure out the data model for the next feature.
                                                                                        2. Create models in Django.
                                                                                        3. Create JSON APIs in Django.
                                                                                        4. Create models again on the client side with Ember Data.
                                                                                        5. Decide on the routes and controllers to finish the user interface for the feature.

                                                                                        I’ve been working on a personal project, and I’ve chosen Postgres, Hasura (GraphQL) and Typescript. My API creation (actually, I don’t have to create APIs anymore) looks like this:

                                                                                        1. Create Postgres schema for new feature
                                                                                        2. Develop GraphQL query in GraphiQL, copy into Typescript code.

                                                                                        I get my Typescript types automatically constructed from the query, and the GraphQL schema is automatically created by Hasura. It’s such a fast development process, and it’s also type-checked! It’s been a complete revelation for me, coming from a background akin to what the author experienced with their API development.

                                                                                        Granted, I haven’t got much in the way of business logic - my app is very CRUDy.

                                                                                        1. 3

                                                                                          Why take on building out a backend api and SPA at all if your goal is to keep maintenance minimal and simple? Server rendered or hybrid both seem like dramatically simpler choices than full blown api/spa. Especially given author’s django experience.

                                                                                          Also (having done my fair share of CRUD apps) if you’re doing largely CRUD/form-over-data work, then how necessary is a SPA really? Personally, if I was the sole-developer on a project that could potentially be more than a hobby, then I’d consider refactoring to a richer UI if, and only after, I had a product with legs (and paying customers).

                                                                                          1. 4

                                                                                            In general I’ve never understood the point in building SPAs for things that are inherently multi-page, like web apps with lots of CRUD and the like. SPAs are good for interactive things like dashboards and so on, in my opinion. Otherwise they’re just a maintenance overhead, useless code.

                                                                                            1. 1

                                                                                              In my case I omitted that I’m using Next, so I am actually building a server-rendered app. But I get to do it with React - which I am very familiar with, and I vastly prefer JSX to Jinja or Handlebars (also: type-checked).

                                                                                              For small, CRUDy apps there’s a good chance even a small cheap VPS instance will execute database queries and render HTML more than quickly enough.

                                                                                              1. 1

                                                                                                I haven’t seen NextJS yet, but I agree that react/jsx are a lot more pleasant to work with than the templating offered by most server-side frameworks. I can definitely see the appeal of rendering react server-side. I’m also on the fence regarding graphql, but my experience with it is limited. But, like NestJS, Hasura is another one I haven’t encountered yet. Great info - two items I need to check out!

                                                                                              2. 1

                                                                                                I don’t find building a sever rendered thing to be particularly easier than building an SPA if there’s going to be at anything interactive on the front end, which has been the case for like 80%+ of the things I’ve made.

                                                                                                1. 3

                                                                                                  It depends on the app. As mentioned above, inherently interactive apps like dashboards readily lend themselves to SPAs. In my experience CRUD apps generally don’t, but that’s probably debatable. However, I would argue that for the moment anyway, server-rendered is likely the simplest solution for this class of app. The tooling is more straightforward, frameworks less prone to breakage, and maintenance is easier (i.e., it’s boring). Experience is a prominent factor, though, and the TFA describes not being intimately familiar with at least two critical pieces of the stack chosen.

                                                                                            1. 5

                                                                                              On my team of software engineers, we rotate the project lead role. I thought it would be interesting to share the approach we came up with.

                                                                                              I’d be interested to hear: how do you run projects on your team and what role do you play, as an engineer/developer?

                                                                                              1. 1

                                                                                                Thanks for posting this, as an engineering manager it’s always useful to learn about how other people are doing it (better than I do, I suspect)

                                                                                              1. 4

                                                                                                The premise of the linked article, An Engineering Team where Everyone is a Leader, actually reminds of The Tyranny of Structurelessness.

                                                                                                Freeman described how “this apparent lack of structure too often disguised an informal, unacknowledged and unaccountable leadership that was all the more pernicious because its very existence was denied”

                                                                                                1. 3

                                                                                                  It’s a little different, I think? I read the “An Engineering Team where Everyone is a Leader” as about having everyone in the team at some point be the designated and announced leader on a project. That doesn’t seem like structurelessness to me, it’s more that the structure doesn’t stay fixed such that the same person is the leader for every project.