3 ms·
In Eiffel you do not fight the compiler. The idea is that you define a set of assertions that must be true before writing the code. This process strengthens the
by jlouis 17y ago
In Eiffel you do not fight the compiler. The idea is that you define a set of assertions that must be true before writing the code. This process strengthens the program as you get a more well-defined knowledge of who-does-what in the program. This "Design by Contract" behaviour is much like TDD/BDD.
In Haskell, you do not fight the compiler either. With practice, you will find that the few type errors the compiler returns to you are legitimate: Wrong calling conventions, typos, API misuse, returning nonsense in a specific case and so on. I have, perhaps, some 5 errors per 100 lines of Haskell code I write that the compiler quacks on. It is equally bad moving dynamically typed programming idioms to Haskell as it is moving statically typed programming idioms into, say, Python.
- nostrademons 17y ago"Fighting the compiler" doesn't necessarily mean type errors. It could mean that you have to warp your design to fit the constraints of a language, often making much more extensive changes to your program than you would otherwise would've had to. Though a lot of my complaints about Haskell's type system could be alleviated with a good integrated refactoring tool. If I had one-command operations to: a.) Convert a plain function to a monadic one b.) Change the signature and stacking order of a large stack of monadic transformers c.) Add a new alternative to an algebraic data type, and track down and fix all functions that use it. d.) Add a new parameter, at an arbitrary position, to a function. e.) Change a straight return value to a Maybe. f.) Add a new field to a record or tuple type. Then I'd find Haskell's type system much less oppressive. What's the status of Leksah these days?