Maybe this comes from a non-typed language perspective… As someone who learned in Java, I do not like it because yeah, type is way more important. If someone was coming from Python, I can see why they might think this…
I learned C++ first, have been using python for the last decade almost daily for various one off tasks. I like python, but if I had to build something that will be used even hundred of thousand times, I wouldn’t do it in python.
Anyway point being, despite me using for decades, I still yearn for C++.
I tried to use C++ in 1991 but the Borland Turbo C++ compiler was too buggy, so we used C instead. By 1996 C++ was “ready for primetime” on IBM-compatible PCs (yes, they still called them that, sometimes in 1996) and I switched - for 30 years.
I just spent 10 days building a proof of concept in Python, all the “common wisdom” says that was the fast way to get it done. Now that the prototype is done and the (initial) user feedback is addressed, I’m running a port to something better for lightweight, performant, easy deployment… sadly, C++ isn’t even on the radar for potential targets - top 3 candidates were Go, Rust and C#. I can’t abide the C# ecosystem, and Rust is just a little too rigid and immature for my tastes, so here we Go… anticipated to take 50% longer to port from Python than the Python took to develop in the first place… we shall see…
My perception is one of a treadmill. My fellow developers in C# are much more frequently analyzing migration from one incarnation to the next, updating and installing their license files, evaluating compatibility between versions, and generally spinning their wheels on things not required for getting work done on other platforms.
Back in the day, I was getting a new “99% compatible” DOS version every 6 months (until we transitioned to the PharLap 32 bit extender, got more memory to work with AND stopped the perpetual upgrade treadmill.)
That “99% compatible” thing means: in a 10,000 LOC codebase, you’ve got 100 things to fix before it works on the new DOS.
I really liked working with Qt from 2006-2024 or so, the only major break was 4-5 (must admit, I never migrated to 6, and nobody forced me to…) and the migration from 4-5 was less painful than a DOS version bump. Also, Qt fully insulated our code from garbage changes happening at lower layers.
Most of my version-upgrade woes seem comparatively recent, lol
Nullable contexts. It’s “easy” to update this with a setting in your project file! … but it adds warnings to basically every file in the project :( You could break it up by adding a preprocessor directive, but it still added a lot of noise at the time.
File-scoped namespaces. I like this feature for new code, but OUCH does it mess up code reviews when it’s an incidental change. I really grew to love Github’s “ignore whitespace” setting in the PR diff view because of this.
Migrating from 4.6 to .NET Core. There were a few times when a deploy just … stopped. It worked on our desktops, and it worked on our test server, but the prod deploy just choked. We might have finally gotten a clue about what was wrong from the event viewer, but it’s been a while. I do recall that our usual troubleshooting path was useless in this case!
I learned Java first. I think type should come second as well, like in TypeScript et al.
If you’re ever looking for the variable manually for some reason, by searching with your eyes, it’s easier to find it by searching in the first character column.
Otherwise, if you ever need to see the type of something, which… should be obvious from the context in quality code, your LSP should just be able to tell you directly, by some mechanism (hover with mouse, or some keyboard action).
Maybe this comes from a non-typed language perspective… As someone who learned in Java, I do not like it because yeah, type is way more important. If someone was coming from Python, I can see why they might think this…
I learned C++ first, have been using python for the last decade almost daily for various one off tasks. I like python, but if I had to build something that will be used even hundred of thousand times, I wouldn’t do it in python.
Anyway point being, despite me using for decades, I still yearn for C++.
I tried to use C++ in 1991 but the Borland Turbo C++ compiler was too buggy, so we used C instead. By 1996 C++ was “ready for primetime” on IBM-compatible PCs (yes, they still called them that, sometimes in 1996) and I switched - for 30 years.
I just spent 10 days building a proof of concept in Python, all the “common wisdom” says that was the fast way to get it done. Now that the prototype is done and the (initial) user feedback is addressed, I’m running a port to something better for lightweight, performant, easy deployment… sadly, C++ isn’t even on the radar for potential targets - top 3 candidates were Go, Rust and C#. I can’t abide the C# ecosystem, and Rust is just a little too rigid and immature for my tastes, so here we Go… anticipated to take 50% longer to port from Python than the Python took to develop in the first place… we shall see…
Why not? I like working in C#, so I’m curious what about the ecosystem bothers you.
My perception is one of a treadmill. My fellow developers in C# are much more frequently analyzing migration from one incarnation to the next, updating and installing their license files, evaluating compatibility between versions, and generally spinning their wheels on things not required for getting work done on other platforms.
Yeah, fair. New versions release every year. It’s usually good stuff, but it does add some toil to existing codebases.
Back in the day, I was getting a new “99% compatible” DOS version every 6 months (until we transitioned to the PharLap 32 bit extender, got more memory to work with AND stopped the perpetual upgrade treadmill.)
That “99% compatible” thing means: in a 10,000 LOC codebase, you’ve got 100 things to fix before it works on the new DOS.
I really liked working with Qt from 2006-2024 or so, the only major break was 4-5 (must admit, I never migrated to 6, and nobody forced me to…) and the migration from 4-5 was less painful than a DOS version bump. Also, Qt fully insulated our code from garbage changes happening at lower layers.
Most of my version-upgrade woes seem comparatively recent, lol
I learned Java first. I think type should come second as well, like in TypeScript et al.
If you’re ever looking for the variable manually for some reason, by searching with your eyes, it’s easier to find it by searching in the first character column.
Otherwise, if you ever need to see the type of something, which… should be obvious from the context in quality code, your LSP should just be able to tell you directly, by some mechanism (hover with mouse, or some keyboard action).
I only use python and I don’t understand why someone might think that. The order in python’s type hints is wrong too.
Script languages are quick and dirty (but slow), I hate it when they try to shoehorn every high level concept into them.