4 ms·

There is a third way: define, explore and build a model of the problem space your program is supposed to be addressing. This forces you to understand its proper

by bakul 3y ago

There is a third way: define, explore and build a model of the problem space your program is supposed to be addressing. This forces you to understand its properties much better. Once you understand it better you can likely implement in any of the common programming languages. This is also why I like languages like Scheme or APL or k for exploration. Often the UI addresses only a subset of this space -- it is only the visible part of the iceberg as it were! There is a lot going on under the UI surface. Not to mention you may want more than one (kind of) UI.

leobg 3y ago
Sounds interesting. Can you give or link to an example?
- bakul 3y ago
  The idea is quite old -- See for instance https://en.wikipedia.org/wiki/Formal_methods https://en.wikipedia.org/wiki/Formal_methods For an example see https://en.wikipedia.org/wiki/Vienna_Development_Method#Bank_system_example https://en.wikipedia.org/wiki/Vienna_Development_Method#Bank... The idea is to model the key aspects as mathematically rigorously as possible while ignoring lower level details. But even if you are not as rigorous, the process of creating such a model can help clarify things. As an example, if you are developing a file system you can abstractly define operations on it (read, write, create file, dir, etc.) and one can come up with a huge number of implementations satisfying this but as you add other requirements or constraints, quite a few choices are no longer meaningful. For example you want to implement a FS that takes advantage of NVMe SSDs, they put certain constraints. So then you need a model for an SSD (erase blocks are multiples of data blocks, write must be preceded by erase, etc. etc.). The idea is to model all this using a few abstract data types and state. You need not strive to programmatically derive an implementation from such a spec for it to be useful.

by bakul 3y ago

leobg 3y ago

Sounds interesting. Can you give or link to an example?

bakul 3y ago
The idea is quite old -- See for instance https://en.wikipedia.org/wiki/Formal_methods https://en.wikipedia.org/wiki/Formal_methods For an example see https://en.wikipedia.org/wiki/Vienna_Development_Method#Bank_system_example https://en.wikipedia.org/wiki/Vienna_Development_Method#Bank... The idea is to model the key aspects as mathematically rigorously as possible while ignoring lower level details. But even if you are not as rigorous, the process of creating such a model can help clarify things. As an example, if you are developing a file system you can abstractly define operations on it (read, write, create file, dir, etc.) and one can come up with a huge number of implementations satisfying this but as you add other requirements or constraints, quite a few choices are no longer meaningful. For example you want to implement a FS that takes advantage of NVMe SSDs, they put certain constraints. So then you need a model for an SSD (erase blocks are multiples of data blocks, write must be preceded by erase, etc. etc.). The idea is to model all this using a few abstract data types and state. You need not strive to programmatically derive an implementation from such a spec for it to be useful.