3 ms·
Great to hear! I would be happy to learn more about the specific need you see in your work context. Either here or on our Discord. If you are interested to le
by tudorgirba 2y ago
Great to hear!
I would be happy to learn more about the specific need you see in your work context. Either here or on our Discord.
If you are interested to learn more about kinds of problems and how it fits in the development environment, perhaps take a look at the book I am writing in the open with Simon Wardley (we recently released the first four chapters):
https://medium.com/feenk/rewilding-software-engineering-900ca95ebc8c https://medium.com/feenk/rewilding-software-engineering-900c...
- WillAdams 2y agoI think this is most interestingly framed as an extension of/successor to/alternative for Literate Programming, or at least that's the mental cubbyhole it best fits in for me. Another recent screed on programming in this vein is John Ousterhout's: https://www.goodreads.com/book/show/39996759-a-philosophy-of-software-design https://www.goodreads.com/book/show/39996759-a-philosophy-of... https://news.ycombinator.com/item?id=31248641 https://news.ycombinator.com/item?id=31248641 which similarly, walks up to, but doesn't quite come out in favour of Literate Programming. EDIT: That said, it is framed as LP in at least one description: https://futureofcoding.org/catalog/smalltalk.html https://futureofcoding.org/catalog/smalltalk.html
- tudorgirba 2y agoInteresting. Let me offer you a different perspective. Moldable Development is different from Literate Programming in at least two ways: - Literate Programming is focused on a single narrative. In contrast, a system can be seen in many ways. - Literate Programming has a fixed environment, and mixes text and code. In contrast, Moldable Development emphasizes the importance of the tool as an essential artifact through which to explain the system. While Literate Programming does talk about explaining systems, I find it too limiting. Instead, we start from the observation that figuring systems out to know what to do next is the single most expensive activity in software engineering; thus it's more interesting to regard software engineering as a decision making activity about an ever changing system. This stands in contrast to the pervasive idea of software engineering as a construction activity. Optimizing for decision making leads to a new set of practices that are not an increment compared to what those typical used today. Glamorous Toolkit looks odd exactly because we optimized for something else that others disregard.
- WillAdams 2y agoDonald Knuth uses METAFONT/METAPOST as an on-the-fly calculator for math at need, including while working on programming problems. I guess what I want is something like to: - LyX --- where there is a focus on structure and tagging, and an ability to output a correctly typeset document - pyspread --- where it is possible to work with data and calculations and arrive at results, including graphical ones (my current issue is that making a DXF and an SVG use different coordinate systems --- DXF is simpler, and uses the same one as for G-code, so that's what I use) where it is possible to embed the spreadsheet cells/sheets dynamically as one used to use OLE to put a spreadsheet in a word document.
- tudorgirba 2y agoSure. Those are technical details. But ask yourself: how many things have been expressed this way? For example, what about security? Business domain documentation? Performance? Architecture? Discovering APIs? etc It's not that the idea is not useful. It's that it's incomplete. We should not get stuck on it.