This is a good article that showcases pain points I’m currently having developping with Python (along with my sympathetic teammates). The following sentence synthesizes how I feel about it now:
It’s great to be implicit when you just want to pump out some code to get a prototype working, but especially when building larger applications it can bring a lot of trouble.
Having done dynamic languages and static ones, nominal versus structural, professional and hobby, academic and enterprise, anything static trumps dynamic when you want to be able to grow and maintain a project past the prototype stage.
You don’t have any guarantee that “paid_date” is available in the dictionary.
There is no guarantee indeed. Even with type annotations, they are suggestions. On the plus side, typing is explicit and helps a lot understanding code.
That is not to say that Python is all bad in my opinion. I love its modern improvements, and just being able to whip out a dataclass in a few seconds does 80% of the job. Also, working with pytest is a charm.
Next step: convincing my team that rewriting in Rust is a good idea…
anything static trumps dynamic when you want to be able to grow and maintain a project past the prototype stage.
I wouldn’t go that far. I still very much love Python, especially for projects where requirements change often, where you need a diverse feature set or many integrations to different tools and platforms. E.g. tools to automate internal tasks.
Short development cycles and the vast ecosystem guarantee that you can deliver something useful before it becomes obsolete. And an application with occasional hiccups or bugs is still far better than people manually working in excel files on repetitive tasks ;)
We use(d) Elm at the company I work at. (A start-up.) Elm is great. All of the positive rumors about it are true.
The issue we’ve had with Elm isn’t typically discussed: My CTO doesn’t seem to see the value of it+. So we recently replaced our Elm code with JavaScript.
I wonder if anyone else finds themselves in a similar situation.
+It’s a bit more nuanced. We’re in a very “MVP” stage; the line of thinking is to use something everyone’s more familiar with so we can move fast.
Your CTO is right. Elm-isms should be translatable to JS, and honestly, you can make simple webapps today with JS and React only.
Sure, maybe Elm forces a style onto the programmers. But when you join a project, you’re supposed to follow the project’s style anyway. If you started the project “Elm style” it should continue on this style with new hires.
This simply doesn’t happen. New hires will expand the team past the ability of the initial developers to control, “Elm-isms” (e.g., good practice) will be abandoned, and it’ll become a typical JavaScript project. After a few months you’ll never know that it started as an Elm project at all. After all, there’s no backup from above to maintain the Elm-isms because the “CTO doesn’t seem to see the value of it.”
Indeed. Whats more, I think Elm should be everyone’s first programming language. Just learning Elm is way easier than learning JavaScript and all its ridiculous thorns, and Angular, and React, and Redux, and Gulp, and Ramda, and Immutable, and and ad infinitum.
My CTO doesn’t seem to see the value of it
That’s a shame. I disagree with their assessment, but then usurping that person wouldn’t work either (I’ve tried a few times).
The good news is that us programmers are in an amazing position to start our own businesses the way we see fit.
the line of thinking is to use something everyone’s more familiar with so we can move fast
That sounds reasonable superficially, but how familiar is everyone really with the current JavaScript landscape? It’s the part of the industry with by far the most NIH and churn.
I can imagine it’s hard to stick with elm in the beginning because you spend a lot of time on issues you could resolve easily/quickly in JS as you’re more familiar with it. I think the benefits of elm can pay off though (rather sooner than later). But only, if your product stays somewhat similar.
In an MVP stage though, it happens all too often, that you pivot your business model a few times. Spending a lot of time on code that you’ll eventually throw away doesn’t help anyone (except for you as a developer, because you get to learn a lot and don’t have to suffer from your past mistakes ;))
Your story reminded me of this article: Move fast and don’t break things. They share a more positive perspective on using elm in a startup environment.
I thought the goal of Elm was to have a very simple language/framework, with the main point of moving fast with it (no shiny new features every month).
This is a good article that showcases pain points I’m currently having developping with Python (along with my sympathetic teammates). The following sentence synthesizes how I feel about it now:
Having done dynamic languages and static ones, nominal versus structural, professional and hobby, academic and enterprise, anything static trumps dynamic when you want to be able to grow and maintain a project past the prototype stage.
There is no guarantee indeed. Even with type annotations, they are suggestions. On the plus side, typing is explicit and helps a lot understanding code.
That is not to say that Python is all bad in my opinion. I love its modern improvements, and just being able to whip out a dataclass in a few seconds does 80% of the job. Also, working with pytest is a charm.
Next step: convincing my team that rewriting in Rust is a good idea…
I wouldn’t go that far. I still very much love Python, especially for projects where requirements change often, where you need a diverse feature set or many integrations to different tools and platforms. E.g. tools to automate internal tasks.
Short development cycles and the vast ecosystem guarantee that you can deliver something useful before it becomes obsolete. And an application with occasional hiccups or bugs is still far better than people manually working in excel files on repetitive tasks ;)
We use(d) Elm at the company I work at. (A start-up.) Elm is great. All of the positive rumors about it are true.
The issue we’ve had with Elm isn’t typically discussed: My CTO doesn’t seem to see the value of it+. So we recently replaced our Elm code with JavaScript.
I wonder if anyone else finds themselves in a similar situation.
+It’s a bit more nuanced. We’re in a very “MVP” stage; the line of thinking is to use something everyone’s more familiar with so we can move fast.
Your CTO is right. Elm-isms should be translatable to JS, and honestly, you can make simple webapps today with JS and React only.
Sure, maybe Elm forces a style onto the programmers. But when you join a project, you’re supposed to follow the project’s style anyway. If you started the project “Elm style” it should continue on this style with new hires.
+1 to your CTO.
This simply doesn’t happen. New hires will expand the team past the ability of the initial developers to control, “Elm-isms” (e.g., good practice) will be abandoned, and it’ll become a typical JavaScript project. After a few months you’ll never know that it started as an Elm project at all. After all, there’s no backup from above to maintain the Elm-isms because the “CTO doesn’t seem to see the value of it.”
Indeed. Whats more, I think Elm should be everyone’s first programming language. Just learning Elm is way easier than learning JavaScript and all its ridiculous thorns, and Angular, and React, and Redux, and Gulp, and Ramda, and Immutable, and and ad infinitum.
That’s a shame. I disagree with their assessment, but then usurping that person wouldn’t work either (I’ve tried a few times).
The good news is that us programmers are in an amazing position to start our own businesses the way we see fit.
That sounds reasonable superficially, but how familiar is everyone really with the current JavaScript landscape? It’s the part of the industry with by far the most NIH and churn.
I can imagine it’s hard to stick with elm in the beginning because you spend a lot of time on issues you could resolve easily/quickly in JS as you’re more familiar with it. I think the benefits of elm can pay off though (rather sooner than later). But only, if your product stays somewhat similar.
In an MVP stage though, it happens all too often, that you pivot your business model a few times. Spending a lot of time on code that you’ll eventually throw away doesn’t help anyone (except for you as a developer, because you get to learn a lot and don’t have to suffer from your past mistakes ;))
Your story reminded me of this article: Move fast and don’t break things. They share a more positive perspective on using elm in a startup environment.
I thought the goal of Elm was to have a very simple language/framework, with the main point of moving fast with it (no shiny new features every month).
I’ve only tried it briefly about 4 years ago but to me it was basically haskell without typeclasses.