4 ms·

Just stop with the sarcasm, it doesnt belong here.

Joel_Mckay 2y ago
The talk covers how polyglot projects tend to fail. Most folks can disagree on things, and remain respectful. Have a glorious day =3
- SR2Z 2y ago
  Except... Most companies offer products built in multiple languages. Google notoriously has a multilingual monorepo and a uniform build system. Every company of non-trivial size uses multiple languages. Even Asahi Linux does! Polyglot projects are harder, but definitely not as hard as OS development in C.
  - Joel_Mckay 2y ago
    Not sure employee attrition rates and canceled project metrics are a positive aspect of Google. https://en.wikipedia.org/wiki/List_of_Google_products#Discontinued_products_and_services https://en.wikipedia.org/wiki/List_of_Google_products#Discon... "definitely not as hard as OS development in C" Depends what you are doing, as complexity is often a sign of poor communication. https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law The talk pokes fun at the excuses folks make when kludging something they intended to replace later. =3
    - SR2Z 2y ago
      Google does not cancel projects because they're technically unwieldy, and if you ask pretty much any ex-Google engineer what they think about internal tooling they will generally praise it because it's very good. Complexity is a consequence of dealing with the real world. An OS talks to hardware, which might have errata or just straight up random faults.
      - Joel_Mckay 2y ago
        Googles initial technological success was due to the design assumption individual systems were never reliable, and should fail back gracefully. It was and still is considered a safe assumption... Indeed, on average 52% of all IT projects at any firm end up failing, or were never used as designed. What exactly does a glorified marketing company have to do with successful OS design? The internal Android OS they planned to replace Linux with was canceled too. "All software is terrible, but some of it is useful" =3
        SR2Z 2y ago
        I would suggest actually reading what engineers who have worked at the company say about it. Many of these statements you've just made are irrelevant or factually incorrect (e.g. Fuschia might be cancelled, but Google remains one of the major contributors to Linux and is certainly not a "marketing company.") Have a good day!
        Joel_Mckay 2y ago
        'certainly not a "marketing company."' So you think they publish free services out of charity? Perhaps the technology business is not for you... Best of luck =3
  - whstl 2y ago
    Yep. Even small companies. The majority of companies doing web is doing "something plus Javascript". And then if there's some AI in the mix, there's also almost always Python. Often maintained by a super small team. What about apps? Java and Swift. The migration to Swift included a lot of Obj-C and Swift living side by side for a while. Same with some apps migrating to Kotlin.
    - Joel_Mckay 2y ago
      In general... it is often a skill issue with labor pools, as firms accepted Java/JavaScript is almost universally known by juniors. Apps are in user space, and are often disposable-code after 18 months in most cases. Projects like https://quasar.dev/ https://quasar.dev/ offer iPhone/Android/iOS/MacOS/Win11 single code base auto-generated App publishing options, but most people never hear of it given a MacOS build host is required for coverage. The talk pokes fun at the Ivory tower phenomena, and how small-firm logical assumptions halt-and-catch-fire at scale. =3 https://en.wikipedia.org/wiki/Ivory_tower https://en.wikipedia.org/wiki/Ivory_tower
      - SR2Z 2y ago
        How the can it possibly be an issue with the labor pool when JS is the only truly supported web language and Python is the main language for ML tooling? I think that you are handwaving away differences in runtime environments. All languages (almost) are Turing-conplete. Many of them, if used in the wrong context, will get you stuck in a Turing tarpit. Languages succeed or fail on the strength of their runtimes. If you seriously think that mixed-code codebases are trash after 18 months, then I think I'm wasting my time - that statement is so fundamentally detached from reality that I don't even know how to start.
        Joel_Mckay 2y ago
        "that statement is so fundamentally detached from reality that I don't even know how to start." It is the statistical average for Android, but again it depends on the use-case situation. Apps are a saturated long-tail business that fragmented decades ago. Python sits on top of layers of C++ wrappers for most ML libraries, and doesn't do the majority of the heavy computation in Python itself (that would be silly). Anyone dealing with the CUDA SDK for Pytorch installs can tell you how bad it is to setup due to versioning. That is why most projects simply give up to use a docker image to keep the poor design dependencies operational on a per project basis. "then I think I'm wasting my time" Than just let the community handle the hard part, and avoid having to figure it out yourself: https://github.com/dambergn/ai-stack https://github.com/dambergn/ai-stack I think you are confusing ML work with end users playing with other peoples algorithms. Best of luck =3

The talk covers how polyglot projects tend to fail. Most folks can disagree on things, and remain respectful. Have a glorious day =3

SR2Z 2y ago
Except... Most companies offer products built in multiple languages. Google notoriously has a multilingual monorepo and a uniform build system. Every company of non-trivial size uses multiple languages. Even Asahi Linux does! Polyglot projects are harder, but definitely not as hard as OS development in C.
- Joel_Mckay 2y ago
  Not sure employee attrition rates and canceled project metrics are a positive aspect of Google. https://en.wikipedia.org/wiki/List_of_Google_products#Discontinued_products_and_services https://en.wikipedia.org/wiki/List_of_Google_products#Discon... "definitely not as hard as OS development in C" Depends what you are doing, as complexity is often a sign of poor communication. https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law The talk pokes fun at the excuses folks make when kludging something they intended to replace later. =3
  - SR2Z 2y ago
    Google does not cancel projects because they're technically unwieldy, and if you ask pretty much any ex-Google engineer what they think about internal tooling they will generally praise it because it's very good. Complexity is a consequence of dealing with the real world. An OS talks to hardware, which might have errata or just straight up random faults.
    - Joel_Mckay 2y ago
      Googles initial technological success was due to the design assumption individual systems were never reliable, and should fail back gracefully. It was and still is considered a safe assumption... Indeed, on average 52% of all IT projects at any firm end up failing, or were never used as designed. What exactly does a glorified marketing company have to do with successful OS design? The internal Android OS they planned to replace Linux with was canceled too. "All software is terrible, but some of it is useful" =3
      - SR2Z 2y ago
        I would suggest actually reading what engineers who have worked at the company say about it. Many of these statements you've just made are irrelevant or factually incorrect (e.g. Fuschia might be cancelled, but Google remains one of the major contributors to Linux and is certainly not a "marketing company.") Have a good day!
        Joel_Mckay 2y ago
        'certainly not a "marketing company."' So you think they publish free services out of charity? Perhaps the technology business is not for you... Best of luck =3
- whstl 2y ago
  Yep. Even small companies. The majority of companies doing web is doing "something plus Javascript". And then if there's some AI in the mix, there's also almost always Python. Often maintained by a super small team. What about apps? Java and Swift. The migration to Swift included a lot of Obj-C and Swift living side by side for a while. Same with some apps migrating to Kotlin.
  - Joel_Mckay 2y ago
    In general... it is often a skill issue with labor pools, as firms accepted Java/JavaScript is almost universally known by juniors. Apps are in user space, and are often disposable-code after 18 months in most cases. Projects like https://quasar.dev/ https://quasar.dev/ offer iPhone/Android/iOS/MacOS/Win11 single code base auto-generated App publishing options, but most people never hear of it given a MacOS build host is required for coverage. The talk pokes fun at the Ivory tower phenomena, and how small-firm logical assumptions halt-and-catch-fire at scale. =3 https://en.wikipedia.org/wiki/Ivory_tower https://en.wikipedia.org/wiki/Ivory_tower
    - SR2Z 2y ago
      How the can it possibly be an issue with the labor pool when JS is the only truly supported web language and Python is the main language for ML tooling? I think that you are handwaving away differences in runtime environments. All languages (almost) are Turing-conplete. Many of them, if used in the wrong context, will get you stuck in a Turing tarpit. Languages succeed or fail on the strength of their runtimes. If you seriously think that mixed-code codebases are trash after 18 months, then I think I'm wasting my time - that statement is so fundamentally detached from reality that I don't even know how to start.
      - Joel_Mckay 2y ago
        "that statement is so fundamentally detached from reality that I don't even know how to start." It is the statistical average for Android, but again it depends on the use-case situation. Apps are a saturated long-tail business that fragmented decades ago. Python sits on top of layers of C++ wrappers for most ML libraries, and doesn't do the majority of the heavy computation in Python itself (that would be silly). Anyone dealing with the CUDA SDK for Pytorch installs can tell you how bad it is to setup due to versioning. That is why most projects simply give up to use a docker image to keep the poor design dependencies operational on a per project basis. "then I think I'm wasting my time" Than just let the community handle the hard part, and avoid having to figure it out yourself: https://github.com/dambergn/ai-stack https://github.com/dambergn/ai-stack I think you are confusing ML work with end users playing with other peoples algorithms. Best of luck =3