4 ms·
> It's the only language I've ever used that tended to produce programs that worked correctly on their first run From my experience that is generally true with
by bibyte 8y ago
> It's the only language I've ever used that tended to produce programs that worked correctly on their first run
From my experience that is generally true with languages that have strong static type systems (like Haskell and Rust).
- syrrim 8y agoFrom my experience it's true in python (ie not a static type system). Removing the distinction between compiling and running makes this point even stronger.
- 59nadir 8y agoThis is not at all my experience, neither with my own code or code other people produce. Unless the problem is extremely trivial the solution is very unlikely to work without a few test runs. The bigger point in all of this is that statically typed languages at least have some kind of check mark they can put on your code to say "Yeah, at least the types make sense". They also encourage designing with types in order to enforce business logic, which is something you don't get in any of the dynamic languages.
- randomsearch 8y agoAgreed. Have written a lot of code in Ada and Python, I have taught both of them. The fact that Ada code often works first time is something almost every student notices at some point. I have far more experience in Python, and I don’t think I’ve ever made non-trivial code work the first time.
- j88439h84 8y agoIn python this can be true, if you invest in the various protections like pylint, mypy, and full test coverage. Python doesn't force you to do those things if you dont need the reliability for a prototype or one-off code. But if you want to make a reliable system, even convert your prototype into a reliable system, you can.
- kazinator 8y agoThe trick is to produce programs that also run correctly on their second and third run, and multiple other runs where the user is someone other than the creator with different ideas for the inputs. There isn't anything special about the first run, other than emotionally. Also, if we define "run" as everything that happens when you feed that source program to the machine, then your first run actually bombed with compile errors. You can't sit there pretending that the compile errors are the only mistakes you made, such that your first compile-error-free run that made it all the way to program startup and through to successful termination is also bug-free. If you were that good, you wouldn't be making trivial errors flagged by a compiler.
- eeZah7Ux 8y agoScientific research on the source of bugs shows that type-related bugs are a minority.
- OneWingedShark 8y agoWell, there's a bit of a problem in how you're qualifying things. For example, certain things that aren't obviously handled by the type-system might be. One example would be loops and off-by-one errors. For the case of For-loops on arrays Ada's solution arguably does so via the type-system; in Ada arrays "know" their own length, start- and stop-index and these are query-able via attributes. So, given Function Sum( Input : Integer_Array ) return Long_Long_Integer you could for-loop on the parameter, querying the 'Range attribute -- yielding a possible implementation of: Function Sum( Input : Integer_Array ) return Long_Long_Integer is Begin Return Result : Long_Long_Integer := 0 do For Index in Input'Range loop Sum:= Sum + Long_Long_Integer( Input(Index) ); End Loop; end return; End Sum; And the entire problem is avoided via the type-system.
- kqr 8y agoThat is a reflection on which language you use. I prefer a language where a large majority of bugs are type-related. How about you?