28 ms·
I wasn't going to wade into the object-level CRUD app discussion because it seems beside the point, but I can't possibly disagree more about Python somehow bein
by nbouscal 12y ago
I wasn't going to wade into the object-level CRUD app discussion because it seems beside the point, but I can't possibly disagree more about Python somehow being better suited for the domain because of "flexibility". Python is not more flexible than Haskell in any meaningful way.
The only possible argument against static typing comes in the form of a program that won't typecheck, but should. This is the only type of "flexibility" that Python could win at, with regard to type systems. Please, show me a practical example of such a program. I've asked a dozen people for one, and nobody has ever followed through.
The only other argument against Haskell's "flexibility" I can think of would be against purity, but that argument doesn't fly either. Any competent Haskell programmer can work easily with state, IO, etc, and I've never run into an effectful task in practice that takes meaningfully longer to do in Haskell than in Python.
People are often quick to typecast languages into some role that seems to fit. Haskell is rigid and mathematical, Python is flexible and readable, etc. These impressions rarely come close to capturing the reality, and in this case end up being downright misleading.
If I'm starting developing a web application from scratch, with zero libraries available to me, I'm picking Haskell without a shadow of a doubt.
- marcosdumay 12y agoEvery single value in Python is weakly defined, and can change at runtime. Functions can accept any set of parameters, objects do not need to conform to a class, the entire namespace can be replaced during the execution of a function. If you have a better name than "flexibility", please tell me, because I can't think of any. Haskell is in the oposite extreme of that dimension. Anyway, that has no relation to readability. Python's flexibility leads too easily to metaprogramming, for example, what's extremely powerfull, but a nightmare to read. And classifying a language as "mathematical" is borderline nonsensical - it only carries some slight meaning because people that say that normaly want to say "algebrical", in oposition to, maybe, "logic-temporal".
- nbouscal 12y agoMaybe reread my post - I wasn't saying that those typecasts of the languages were accurate, I was doing exactly the opposite. The characteristics of Python you just mentioned are only specific to it in cases when they are erroneous. They basically all evaluate to "Python isn't type-safe." So again, show me a program that is best represented in a non-type-safe way, and I will concede the point. If you can't, then this flexibility you're praising isn't a feature, it's a bug.
- marcosdumay 12y ago> The characteristics of Python you just mentioned are only specific to it in cases when they are erroneous. They are explicit at the official documentation, if they got there by error, they are official features now. > They basically all evaluate to "Python isn't type-safe." Yes, they do. They are at the opposite extreme from type-safety. That's why I used them to exemplify how it's the languages that apply better to some problems. > So again, show me a program that is best represented in a non-type-safe way, and I will concede the point. Well, any Django[1] CRUD would do. They are quite trivial, in there's little meaning in specifying exactly the manipulated data. Yes, Haskell has tools for displaying data at the web, and querying a database; no they are simply not as powerful when applied to that problem. [1] In other frameworks they are about as simple, but you asked for one example.
- lomnakkus 12y agoI find this a strange and unconvincing example -- if I'm understanding you correctly, that is. Is your complaint about strong typing here that you'd be forced to define stuff like a record Customer with fields "lastName", "firstName", etc. and you'd rather avoid that? If you'd like something more "dynamic" (i.e. type-unsafe), you can instead just define a "universal data type" for all your CRUD data. For example you could define, say data Any = Number Int | Str String | Map String Any | Date ... | ... and where you want "universal" data manipulation you just use Any. EDIT: Thus you've confined all the "fuzziness" of your data definitions to a "subsystem" of your system and you can still benefit from proper types and type checking everywhere else.