I recently found and fixed a 5 1/2 year old bug that was caused by a caller assuming that an integer parameter is an absolute quantity, but the function treated it as a delta. (The really funny thing is that the commit which introduced this bug introduced both that function and the incorrect call to it; and then, for the next 5 1/2 years after that, subsequent new uses of the function elsewhere in the code all correc…
This is why we should really push for automatic logic checkers and proper support of programming by contract.
Yes, time to market is important. However, you don't need to compromise convenience of development for the sake of performance. If you twist your Python code to get performance it takes time. If you need performance, and like the syntax of Python then you should take a look at Nim [1]. With Nim I develop as quickly as in Python while I get the performance of C. [1] https://nim-lang.org I believe application performan…
Nim seems really good, but does it have a decent REPL these days? I'm not sure if it would be as convenient with a statically typed language, but I like the incremental development approach so much that I only use C if I absolutely have to.
It doesn't. But you can grab Aporia (or some other tool) to quickly compile and run some code, it replaces a REPL very well in my experience.
"the idea that dynamic languages are more productive than static languages are laughable." -- being statically typed or dynamically typed comes with its own set of tradeoffs and what a person is more productive in is a highly subjective matter. Lispers are more productive in Lisp than Haskell and vice versa. "Statically type languages prevent a lot of bugs and allow for a lot of automated provably correct refactoring…
Clojure is trying to do that with Clojure.spec and specifications being checked at runtime can get you closer to things you could have automatically proved correct only with languages with dependent types, nothing against statically typed languages but I feel that your sweeping generalizations hurt the point you are trying to make. "Checking at runtime* is exactly the problem. Why would checking at runtime be more re…
In addition to the points flavio81 made, checking at runtime because unless the language is dependently typed i.e. has types as first class citizens(for example Idris) a lot of the information about your code you want to prove to be correct is not available at compile time(for example, you have an integer but is it a non-negative integer, a list but is it sorted). It is not about being reliable, it is about being possible.
It's still expensive on client machines because most of the persons in the world are NOT software engineers with 6-digit salaries. They run cheap computers with HDDs and Windows polluted by a ton of 3rd party crap. They don't know how to fix it and silently suffer. I was cleaning a local vet clinic's devices recently – they were literally switching between two computers to not wait 5 minutes of non-responsiveness bec…
A lot of businesses these days prefer web apps. It's not hard to understand why - all the hassle of system maintenance falls to the people who host the app and can afford to know their stuff. If your Windows PC is suffering from rot just replace it with a Chromebook.
"Just get money for a new device out of thin air and just replace all your paid or even cracked Windows software with subscription-based alternatives that will not work without Internet. Ah, also just relearn all your workflows."
Sorry, but that's how being in a bubble looks like.
> Yes, it can! Ok, how? Other than an Ada example, or dependently-typed languages that aren't use in production, can you offer an example?
Perl 6, for instance, supports subset types such as: subset Positive of Int where * > -1 OTOH, while some Perl 6 supports some static type checking, subsets of this kind seem to support only dynamic, not static, enforcement.
Such subsets are readily available in all dynamic languages I've used. But the issue here is really about compile-time checking these things, and that's a different animal.
A static type system doesn't protect you from choosing the wrong abstraction, and all the bugs that result from it. But if used properly I think it does help.
How? I don't think I've ever gotten a type I wasn't expecting in any of my python code. It's just not a problem for me. That is, past the first time I run it. I've been known to pass something an x when it wanted a y, but that's a "fail early, fail loud" bug and not an actual problem.
Unfortunately in my experience I don't know what type of x I'm supposed pass into to. I either have to guess what x is out of a infinite search space or I have to look at the implementation but unfortunately it also calls some other functions so I need to determine the possible inputs for that function and repeat this until I've read 100s of lines of code just to use a single function because someone thought that documentation is uneccessary and 10 seconds of less typing were worth the tradeoff. Static typing is statically enforced documentation. Sure you might be lucky and already have voluntary documentation available but I am not. I'm getting sick of randomly being stuck for 10 hours on some trivial problem caused by wrong incentives.
> "Python is inherently harder to optimize than JS since it has " Python is not a very dynamic language in the sense that you actually can't change a lot of stuff (and a number of the things you can change just segfault CPython). I think JS is more dynamic, for example. Or Ruby.
These are not my arguments, mind you; I don't know enough to make them. You've piqued my interest, though: can you give me an example of those things that you can't change or that break CPython?
Things like the Carlo Verre hack (also a thing you can't change —any more— in Python: builtins), editing objects during their construction (via e.g. gc)... generally, the gc module allows other ways as well to crash your interpreter.
A lot of businesses these days prefer web apps. It's not hard to understand why - all the hassle of system maintenance falls to the people who host the app and can afford to know their stuff. If your Windows PC is suffering from rot just replace it with a Chromebook.
"Just get money for a new device out of thin air and just replace all your paid or even cracked Windows software with subscription-based alternatives that will not work without Internet. Ah, also just relearn all your workflows." Sorry, but that's how being in a bubble looks like.
I wasn't suggesting that businesses were anxious to replace things that already work, I'm suggesting that as they acquire new software it's more likely to be web-based.
Devices are often replaced on a schedule anyway, especially if they're leased.
I recently found and fixed a 5 1/2 year old bug that was caused by a caller assuming that an integer parameter is an absolute quantity, but the function treated it as a delta. (The really funny thing is that the commit which introduced this bug introduced both that function and the incorrect call to it; and then, for the next 5 1/2 years after that, subsequent new uses of the function elsewhere in the code all correc…
This is why we should really push for automatic logic checkers and proper support of programming by contract.
"Just get money for a new device out of thin air and just replace all your paid or even cracked Windows software with subscription-based alternatives that will not work without Internet. Ah, also just relearn all your workflows." Sorry, but that's how being in a bubble looks like.
I wasn't suggesting that businesses were anxious to replace things that already work, I'm suggesting that as they acquire new software it's more likely to be web-based. Devices are often replaced on a schedule anyway, especially if they're leased.
I wasn't talking only about businesses in my previous reply. But most businesses on the planet aren't bathing in money either.
You are speaking as a citizen of a rich country where devices are relatively cheap and stable Internet is available everywhere.