5 votes

How and why GraphQL will influence the SourceHut alpha

3 comments

  1. [3]
    Bauke
    Link
    @Deimos, is the same true for you? You've been using Python (from what I can figure out in 2 minutes) for almost a decade, and also chose Python for Tildes. Do you think Python is up to the task...

    [...] My work on SourceHut has, on the whole, really soured my opinion of Python as a serious language for large projects.

    @Deimos, is the same true for you? You've been using Python (from what I can figure out in 2 minutes) for almost a decade, and also chose Python for Tildes. Do you think Python is up to the task in the long run for large projects?

    4 votes
    1. [2]
      Deimos
      Link Parent
      I don't know much about Sourcehut or its code, but my general impression would be that Drew chose to build it with Flask, which is about the most minimal framework available and difficult to use...

      I don't know much about Sourcehut or its code, but my general impression would be that Drew chose to build it with Flask, which is about the most minimal framework available and difficult to use for large projects, and now is running into issues with using it for a large project. Other options like Django or Pyramid (which is what Tildes uses) probably would have been more suitable. It also sounds like he's not using mypy or some of the other tooling that would help. I'm not sure how much Python experience he had before this either, so some of it might just be that this is the first large Python project he's ever built.

      To go off on a more general but kinda-related rant, the longer I work in programming, the more I recognize how quickly people leap to blaming language/tools/paradigm/etc. for difficulties. No matter what choices someone made, someone else will insist that it was clearly the wrong one, and that everything would have been so much simpler if they had picked something different.

      Someone comes into a complicated system, has trouble understanding it, and decides that means it needs to be rewritten. If they actually get to do it (which isn't too uncommon in companies), by the time the rewrite is finished the new system is a mess in its own ways too, and the next people that come into that will want to do another rewrite into whatever language/paradigm they favor. Most of the complexity comes from the system needing to handle complicated problems, not the specific technology.

      I think too much weight is put on technical choices, and not enough on other "soft" factors like familiarity. If a complex system has been built up over years, it's just not realistic to expect to be able to get a solid understanding of it in a couple of days. I think it's better to put effort into gaining that understanding and cleaning up rough edges of an existing system than always jumping to wanting to rewrite with different fundamental choices.

      6 votes
      1. blitz
        Link Parent
        I think you have some good points here, but I've been loosely holding the opinion that dynamically typed languages are really just an awful idea for any serious work. Python is getting better with...

        I think you have some good points here, but I've been loosely holding the opinion that dynamically typed languages are really just an awful idea for any serious work. Python is getting better with MyPy and their other type checkers, but it's still "optional", the libraries you use might not support it, you might forget to add type annotations and you might not catch them.

        I think statically typed languages with good type systems are really the only way forward for any major software project, and type systems in general are one of the strongest tools we have for keeping a handle on software complexity as it continues to increase.

        Unfortunately I'm still a python dev for my day job, so I have to deal with all the troubles of dynamic typing, or spend a herculean amount of effort to get us to start using type hints.

        1 vote