3 ms·

No! Eiffel should be the default OOP language for any kind of course. Being forced to think about pre- and postcoditions and invariants by the language is a rea

No! Eiffel should be the default OOP language for any kind of course. Being forced to think about pre- and postcoditions and invariants by the language is a really good thing for beginner programmers. While the syntax is somewhat verbose (mainly because of using keywords instead of most punctuation) Not teaching about Design by Contract is yet another billion dollar mistake in computer science. There are DbC libraries or frameworks for just about any language, but only very few programmers know about its existence, which leads to criminal underutilisation of the technique in the industry. I can't be sure, but I think there's a lot of thought, at least, behind selecting a particular language for an introductory course on programming. I don't know which language I would choose, but I'd like something that would broaden the horizons of student as much as possible. It could be Mozart/Oz or something similar.

yesenadam 5y ago
I didn't know anything about Eiffel or DbC, just reading about them now. "Eiffel Software applied for trademark registration for Design by Contract in December 2003, and it was granted in December 2004." https://en.wikipedia.org/wiki/Design_by_contract https://en.wikipedia.org/wiki/Design_by_contract Is that possibly something to do with it not commonly being taught about/learnt?
- klibertp 5y ago
  I have no idea, unfortunately. On the other hand, the trademark doesn't seem to be a problem to guys behind Racket, which has the most advanced contracts system out there; the canonical book for programming classes in Racket, "How to Design Programs", teaches you everything you need to know about DbC without ever mentioning the term itself, IIRC. Even if you don't want to touch Eiffel due to it being proprietary, there are many languages which support DbC you can choose from: already mentioned Racket, Ada, Clojure, Scala, D, Nim, Haxe, Elixir, and many more. Also, there's a difference between DbC and simply using contracts - it's similar to the difference between writing tests and doing TDD. Many people might not be convinced that the benefits of DbC are worth rethinking the development process, and so they dismiss all contracts as "too many asserts, don't need". But, like with tests, you can benefit from a solid test suite even if you don't do TDD; similarly, you can reap a lot of benefits from simply ensuring that precondition violations are caught at the boundary of a subroutine, because it makes it easier to find the reason beind the problem. I'm convinced that in the next 10-15 years we will see gradual typing (with type inference) embracing contracts as a way to extend the guarantees from compile time to runtime. Maybe we will finally get the best of all worlds: rapid prototyping, great performance, and verifiable program correctness.

yesenadam 5y ago

I didn't know anything about Eiffel or DbC, just reading about them now. "Eiffel Software applied for trademark registration for Design by Contract in December 2003, and it was granted in December 2004." https://en.wikipedia.org/wiki/Design_by_contract https://en.wikipedia.org/wiki/Design_by_contract Is that possibly something to do with it not commonly being taught about/learnt?

klibertp 5y ago
I have no idea, unfortunately. On the other hand, the trademark doesn't seem to be a problem to guys behind Racket, which has the most advanced contracts system out there; the canonical book for programming classes in Racket, "How to Design Programs", teaches you everything you need to know about DbC without ever mentioning the term itself, IIRC. Even if you don't want to touch Eiffel due to it being proprietary, there are many languages which support DbC you can choose from: already mentioned Racket, Ada, Clojure, Scala, D, Nim, Haxe, Elixir, and many more. Also, there's a difference between DbC and simply using contracts - it's similar to the difference between writing tests and doing TDD. Many people might not be convinced that the benefits of DbC are worth rethinking the development process, and so they dismiss all contracts as "too many asserts, don't need". But, like with tests, you can benefit from a solid test suite even if you don't do TDD; similarly, you can reap a lot of benefits from simply ensuring that precondition violations are caught at the boundary of a subroutine, because it makes it easier to find the reason beind the problem. I'm convinced that in the next 10-15 years we will see gradual typing (with type inference) embracing contracts as a way to extend the guarantees from compile time to runtime. Maybe we will finally get the best of all worlds: rapid prototyping, great performance, and verifiable program correctness.