4 ms·

The language is only easy if you have basically learned the language already. Java, C#, C++, Python, Go etc. all differ but fundamentally they are all the same

The language is only easy if you have basically learned the language already. Java, C#, C++, Python, Go etc. all differ but fundamentally they are all the same language with different amounts of window dressing. So yeah if you know one of them it's easy to "learn" the others. But I wouldn't really call this learning a new language. It's a fundamentally different ask to learn Haskell, datalog, SaC. You are actually learning a new language instead of just the flavour of the week imperative programming.

AstralStorm 4y ago
If the language is the hard part, something is wrong with it. Usually. I've seen and user a whole slew of opinionated languages, and they almost always have a big chunk of problems they will be awkward to use for, or even almost insoluble. Every succesful one supports multiple programming paradigms, better or worse, usually decently. Now the real stuff that can cause problems is bad tooling and lack of support. You cannot code your things when you're trying to fix the compiler, build tools or the debugger.
scarface74 4y ago
The last time I had a job where I only had to learn “the language” to be effective was 1999 programming in C and FORTRAN on VAX and Stratus mainframes. By 2000, “knowing C or C++” didn’t do any good without knowing MFC, COM, etc. What good is a language in 2022 without a complete ecosystem of frameworks for most jobs?
- rowanG077 4y ago
  Even esoteric languages have a relative complete ecosystem of frameworks. I use Haskell in my day job and I never had issues finding a library.
  - AstralStorm 4y ago
    Haskell is not particularly esoteric, but heavily opinionated. Libraries cannot change that basic fact - there are just problems it will be extremely unsuited for. Java has some of the same problem by the way in reverse. (Package handling, forced garbage collection and unknown real time and memory usage characteristics.) The difference being that Java's core has much less important opinions about algorithms, while Haskell tries to make everything functional or it is awkward. So, while Haskell will be hard to use for problems best described in an imperative way (in addition to other issues say Java has), Java will only have serious problems where memory and runtime determinism are paramount. It so happens that a lot of the programming is done in imperative way. Including the libraries.
  - scarface74 4y ago
    Say I’m developing an application that needs to interact with cloud services. The last time the third party Haskell SDK for AWS was updated was in 2014. I do see a third party GCP SDK. But if GCP and Azure works like AWS, as soon as a new API is released by a service team, all of the officially supported SDKs automatically get updated. I am sure there are other service providers that have SDKs and code samples for popular languages.
    - rowanG077 4y ago
      I would assume it's just a REST service which has an openapi spec. Then you can just generate the client.
      - scarface74 4y ago
        How much more “productive” do you think they would be just by being able to import a module in any of the supported languages? https://aws.amazon.com/developer/tools/ https://aws.amazon.com/developer/tools/ I believe the list for GCP and Azure are about the same. What are the chances that your problem is such a special snowflake that it can’t be solved with one of those languages? What are the chances that any new developer could ramp up faster or already knows Boto3 (the AWS SDK for Python)? If they have an issue, they can go to StackOverflow or raise a ticket with their TAM. Which would have more assurances are designed correctly, the one from the vendor or yours? I was able to take advantage of new APIS for one of AWS services the day it was introduced, no need to waste cycles on creating my own wrapper. Creating a wrapper around my cloud providers APIS, “doesn’t make the beer taste better” AWS’s SDKs automatically take care of retries, exponential back offs, wrapping the APIs to be idiomatic including logical exceptions being thrown, any underlying changes, etc.
        rowanG077 4y ago
        > How much more “productive” do you think they would be just by being able to import a module in any of the supported languages? The same language? Maybe a few % considering a client is a small part of what you need to create. A different language? Depends on the comparison. I would be tens to hundreds % more efficient in Haskell then in Go or Python. > I believe the list for GCP and Azure are about the same. What are the chances that your problem is such a special snowflake that it can’t be solved with one of those languages? Of course it can be solved in those languages. I can also solve it in Assembly or brainfuck with enough elbow grease. What matters is speed of implementation and correctness. With the exception of Rust all these language have debilitating flaws. > Which would have more assurances are designed correctly, the one from the vendor or yours? I was able to take advantage of new APIS for one of AWS services the day it was introduced, no need to waste cycles on creating my own wrapper. Creating a wrapper around my cloud providers APIS, “doesn’t make the beer taste better” > AWS’s SDKs automatically take care of retries, exponential back offs, wrapping the APIs to be idiomatic including logical exceptions being thrown, any underlying changes, etc. Did you ever try openapi generated clients? They can handle retries and exponential backoffs as well. There is no design to be done here. It just exposes the API as designed.

AstralStorm 4y ago

If the language is the hard part, something is wrong with it. Usually. I've seen and user a whole slew of opinionated languages, and they almost always have a big chunk of problems they will be awkward to use for, or even almost insoluble. Every succesful one supports multiple programming paradigms, better or worse, usually decently. Now the real stuff that can cause problems is bad tooling and lack of support. You cannot code your things when you're trying to fix the compiler, build tools or the debugger.

scarface74 4y ago

The last time I had a job where I only had to learn “the language” to be effective was 1999 programming in C and FORTRAN on VAX and Stratus mainframes. By 2000, “knowing C or C++” didn’t do any good without knowing MFC, COM, etc. What good is a language in 2022 without a complete ecosystem of frameworks for most jobs?

rowanG077 4y ago
Even esoteric languages have a relative complete ecosystem of frameworks. I use Haskell in my day job and I never had issues finding a library.
- AstralStorm 4y ago
  Haskell is not particularly esoteric, but heavily opinionated. Libraries cannot change that basic fact - there are just problems it will be extremely unsuited for. Java has some of the same problem by the way in reverse. (Package handling, forced garbage collection and unknown real time and memory usage characteristics.) The difference being that Java's core has much less important opinions about algorithms, while Haskell tries to make everything functional or it is awkward. So, while Haskell will be hard to use for problems best described in an imperative way (in addition to other issues say Java has), Java will only have serious problems where memory and runtime determinism are paramount. It so happens that a lot of the programming is done in imperative way. Including the libraries.
- scarface74 4y ago
  Say I’m developing an application that needs to interact with cloud services. The last time the third party Haskell SDK for AWS was updated was in 2014. I do see a third party GCP SDK. But if GCP and Azure works like AWS, as soon as a new API is released by a service team, all of the officially supported SDKs automatically get updated. I am sure there are other service providers that have SDKs and code samples for popular languages.
  - rowanG077 4y ago
    I would assume it's just a REST service which has an openapi spec. Then you can just generate the client.
    - scarface74 4y ago
      How much more “productive” do you think they would be just by being able to import a module in any of the supported languages? https://aws.amazon.com/developer/tools/ https://aws.amazon.com/developer/tools/ I believe the list for GCP and Azure are about the same. What are the chances that your problem is such a special snowflake that it can’t be solved with one of those languages? What are the chances that any new developer could ramp up faster or already knows Boto3 (the AWS SDK for Python)? If they have an issue, they can go to StackOverflow or raise a ticket with their TAM. Which would have more assurances are designed correctly, the one from the vendor or yours? I was able to take advantage of new APIS for one of AWS services the day it was introduced, no need to waste cycles on creating my own wrapper. Creating a wrapper around my cloud providers APIS, “doesn’t make the beer taste better” AWS’s SDKs automatically take care of retries, exponential back offs, wrapping the APIs to be idiomatic including logical exceptions being thrown, any underlying changes, etc.
      - rowanG077 4y ago
        > How much more “productive” do you think they would be just by being able to import a module in any of the supported languages? The same language? Maybe a few % considering a client is a small part of what you need to create. A different language? Depends on the comparison. I would be tens to hundreds % more efficient in Haskell then in Go or Python. > I believe the list for GCP and Azure are about the same. What are the chances that your problem is such a special snowflake that it can’t be solved with one of those languages? Of course it can be solved in those languages. I can also solve it in Assembly or brainfuck with enough elbow grease. What matters is speed of implementation and correctness. With the exception of Rust all these language have debilitating flaws. > Which would have more assurances are designed correctly, the one from the vendor or yours? I was able to take advantage of new APIS for one of AWS services the day it was introduced, no need to waste cycles on creating my own wrapper. Creating a wrapper around my cloud providers APIS, “doesn’t make the beer taste better” > AWS’s SDKs automatically take care of retries, exponential back offs, wrapping the APIs to be idiomatic including logical exceptions being thrown, any underlying changes, etc. Did you ever try openapi generated clients? They can handle retries and exponential backoffs as well. There is no design to be done here. It just exposes the API as designed.