Cython might also be worth considering. It lets you add static type declarations to Python and produces compiled code. You could avoid a big-bang rewrite, migrating the slower operations first. I don't know whether it would meet all your cross-platform requirements though.
Replacing Python
11–20 of 144 posts
Re: Replacing Python
#12> A major benefit of OCaml and Haskell is the ease of refactoring. In Python, once the code is working it’s best not to change things, in case you break something that isn’t covered by the unit-tests. In OCaml and Haskell, you can rename a function, delete old code or change a data structure and rely on the compiler to check that everything’s still OK. These sort of statement always bothers me when I encounter it. If…
If you're not testing the code you are refactoring how do you know it still works or even worked in the first place?
There are other ways, different than testing, to convince yourself and others that a program does what it is meant to do. They complement testing. You use them already while constructing the deterministic parts of your program: much of what the machine does for you is predictable, and good languages and libraries are designed to make it so.
In fact, tests won't tell you that the program works, only that it doesn't fail the test cases. You then use the predictable aspects of your domain to convince yourself that the program works if it doesn't fail those test cases.
In the same way that programmatically renaming a variable does not usually warrant the writing of a test case, many forms of automatic refactoring are theoretically guaranteed to not break your program. If they involve type renames, you might be able to deduce that any resulting errors will be caught by the type checker.
(Please don't take this as an argument against testing, but against always requiring test coverage)
Re: Replacing Python
#13> You still have classes, objects, functions, mutable data and low-level access to the OS, all with an easy and concise syntax, but you gain type checking, much better data structures and a huge amount of speed for no additional effort. Why aren’t more people using it?
I think it is a community issue actually. Not the language. It is just not converging. Just think of how many distinct OCaml code styles you have seen. Some use hardcore math notation, some not; some use recursions everywhere; some use imperative syntax; some use pseudo-OOP approach. Some even try to fork the language syntax. And a result. Well. Even with the language itself providing easy and concise syntax, ocaml code is not very readable. And not very popular.
Re: Replacing Python
#14> A major benefit of OCaml and Haskell is the ease of refactoring. In Python, once the code is working it’s best not to change things, in case you break something that isn’t covered by the unit-tests. In OCaml and Haskell, you can rename a function, delete old code or change a data structure and rely on the compiler to check that everything’s still OK. These sort of statement always bothers me when I encounter it. If…
Of course it's possible to write non-working code in a typed language. But with a good type system you don't have to write the code in a way that can be wrong (or at least, that can be wrong in a way that unit tests would help with - if you've misunderstood the requirements then nothing can save you).
Re: Replacing Python
#15Cython might also be worth considering. It lets you add static type declarations to Python and produces compiled code. You could avoid a big-bang rewrite, migrating the slower operations first. I don't know whether it would meet all your cross-platform requirements though. http://cython.org/
Isn't Cython a solution that frequently requires significant code changes (refactoring to C-like code) beyond adding typing?
Re: Replacing Python
#16python is nice
Re: Replacing Python
#17The first Python example throws up a big red flag: manually parsing command line arguments instead of using argparse. Why reinvent the wheel when there is a standard library to handle it? Likewise, asserting that "For storing general records, Python provides a choice of classes and tuples" completely ignores one of Python's fastest and most powerful data types: dictionaries. Lastly, in get_value, the nest of ifs is u…
In his defense, the author makes the following disclaimer:
"As before, note that I’m a beginner in these languages."
Re: Replacing Python
#18Cython might also be worth considering. It lets you add static type declarations to Python and produces compiled code. You could avoid a big-bang rewrite, migrating the slower operations first. I don't know whether it would meet all your cross-platform requirements though. http://cython.org/
Isn't Cython a solution that frequently requires significant code changes (refactoring to C-like code) beyond adding typing?
It's selectively adding C-like type declarations to Python code speed up the slow bits. C code is then generated and compiled into a Python extension module. This is similar to adding type information to Common Lisp code to allow the compiler to optimise it.
Re: Replacing Python
#19I like articles like this one, but this doesn't really bode well for 0install.
Re: Replacing Python
#20The first Python example throws up a big red flag: manually parsing command line arguments instead of using argparse. Why reinvent the wheel when there is a standard library to handle it? Likewise, asserting that "For storing general records, Python provides a choice of classes and tuples" completely ignores one of Python's fastest and most powerful data types: dictionaries. Lastly, in get_value, the nest of ifs is u…
In his defense, the author makes the following disclaimer: "As before, note that I’m a beginner in these languages."
He was referring to all of the other languages. In his previous article, he writes:
"I’m not an expert in these languages (except Python)."