Warwolt

How would you do layouting without a tree structure in place? Not really sure what you're getting at here

Nice article! Having little interactive examples I think is fantastic, and makes the text really utilize it's medium well.

The text was mostly a refresher for me who already knew the subject, but I would heartily recommend it to colleagues with less hardware know-how

Can someone give a tl;dr? Feels like a whole lot of preamble in the article

That's not a good analogy. A good mathematician isn't necessarily dealing with calculations, i.e. long division, but rather with proof.

No-ones becomes a good mathematician without first learning to write simple proofs, and then later on more complex proof. It's the very stuff of the field itself.

Actually, I think this is a case where LLMS _can_ be useful. If we're prompting for small enough outputs, for examples around things we can already sort of reason about it, we're able to judge whether or not what's presented to use makes sense.

Presumably you're also reading some kind of learning text about the Chinese language, so the sole source isn't just the LLM?

In my experience, asking an LLM to produce small examples of well-known things (or rather, things that are going to be talked about frequently in the training data, so generally basic or fundamental topics) tend to work fine, and is going to be at a level where you yourself can judge what's presented.

I think the real danger is when a person is prompting things they don't know how to verify for themselves, since then we're basically just rolling dice and hoping

Unfortunately in the majority of organizations, the idiots are at the wheels. It's not people with actual experience of how engineers do things, that dictates what those engineers should do.

But common, collouqialy "Garbage Collection" as a language feature refers to a run time garbage collector.

Saying that the language has GC just because it has opt-in reference counting is needlessly pedantic

> they either must be bought at an increasing steep price

It's a variable simply because it doesn't refer to a specific object, but any object assigned to it as either function argument or by result of a computation.

It's in fact us programmers who are the odd ones out compared to how the word variable has been used by mathematics and logicians for a long time

Making a distinction between pure and effectful functions doesnt require any kind of effect system though.

Having a language where "func" defines a pure function and "proc" defines a procedure that can performed arbitrary side effects (as in any imperative language really) would still be really useful, I think

Who cares? That's just semantics. If we define science as the systematic search for truths, then mathematics and logic are the paradigmic sciences. If we define it as only empirical search for truth then perhaps that excludes mathematics, but it's an entirely unintersting point, since it says nothing.

To be fair, presumably debug printig could be "escaped" from the effect type checking if the designer of an effect system would want it. For instance, debug printig in Haskell completely sidesteps the need for the IO Monad and just prints in whatever context

Ease of definition doesn't equate ease of measurement..

My issues stems from me feeling like a lot of terminology introduced by the author ending up being used in different ways in different paragraphs.

It didn't feel like a thought through whole, and I felt somewhat punished for trying to read along attentively.

I also found there to be a frequent conflation of e.g. the notion of modules and a classic OOP-class, to me it seemed like the author thought of them interchangeably.

To me there's enough theoretical computer science that can be used to help ground the terminology, even if it's just introduced cursory and with a reference for further reading. But at least then there'd be more consistency.

I'm not sure I think the book is invaluable, but I think it's a good contribution to the subject.

While the tools you talk about sound interesting, to me this was more about an in-principle possible measurement rather than something we'd actually carry out.

I think stating that "more stuff" in the program code and in the spec leads to more stuff to keep track of, and so we want to minimize complexity to maintain tractability?

I think model theory is a really good source of theory to ground the notion of modules.

The relation between an interface and an implementation to me is very much the same as between a formal theory and a model of that theory.

I agree that in practice you'd want to use heuristics for this, but I think the benefits would be similar to learning a little bit of formal verification like TLA+, it's easier to shoot from your hip if you've studied how to translate some simpler requirements into something precise.

For a book like this you'd probably not need more than first order logic and set theory to get a sense of how to express certain things precisely, but I think making _reference to_ existing mathematics as what grounds our heuristics would've been beneficial.

I mean, we can definitively talk about simplicity/complexity in a fairly easy way when it comes to mathematical structures or data structures in my opinion.

For instance, a binary tree that contains just a root node is clearly simpler than a binary tree with three nodes, if we take "simple" to mean "with less parts" and complex to mean "with more parts". Similarly, a "molecule" is more complex than an "atom".

This is a useful definition, I think, because when we write computer programs they always written in some programming language, with a syntax that yields some kind of abstract tree, so ultimately we'll always have _some_ kind of graph-like nature to the computer program, both syntactically and semantically, and surely graphs also permit the same kind of complexity metrics.

I'm not saying measuring the number of nodes is _the_ way of getting at complexity, I'm just pointing out that there's no real difficulty in defining it.

Complexity means more stuff, and we simply take it as a premise that we can only fit so much stuff in our head at the same time.

I should've noted that, although I found it frustrating, I think it's a good read for most programmers. There are many excellent ideas in the book.

I'm very mathematically inclined, so I would probably want a "proper" treatment of this subject to include both formal logic, set theory, type theory and model theory, but they're also subjects I'm still familiarizing myself with.

My basic pitch is that, to a large degree writing sensible computer programs is about modeling some real life activity that the computer program will be part of, and describing things accurately has been done in other fields than programming for many hundreds if not thousands of years, so there's a deep well to draw from.

Despite my appetite for a dry and mathematical treatment of writing computer programs, I still think the book is good for what it is. I think I would go easier on the book if it were not for the title, because philosophy is precisely one of those subjects that tend to favor being very precise about things, something I distinctly think the book lacks. What the book is, however, is an excellent _sketch_ on what we'd want out of program design. I definitely agree about the author's notion of "deep modules" being desirable.

I found "A philosophy of software design" to be a well intended but somewhat frustrating book to read.

It seemingly develops a theory of software architecture that is getting at some reasonable stuff, but does so without any reference _at all_ to the already rich theories for describing and modeling things.

I find software design highly related to scientific theory development and modeling, and related to mathematical theories like model theory, which give precise accounts of what it means to describe something.

Just taking the notion of "complexity". Reducing that to _just_ cognitive load seems to be a very poor analysis, when simple/complex ought to deal with the "size" of a structure, not how easy it is to understand.

The result of this poor theoretical grounding is that what the author of A Philosophy of Software Design presents feels very ad-hoc to me, and I feel like the summary presented in this article similarly feels ad-hoc.

Looks nice! Is there any plans on a language server and formatting tooling?

Usually I feel like that's bare minimum before I'd like to try and play around with a language

When a bug like this can cause real world harm, we can't just bumper car program our way out of things. As engineers we should be able to provide real guarantees.

Types give you static proof where tests only give partial inductive evidence. I cannot _fathom_ why people would prefer tests over types where types do the job, outside anything but sheer ignorance.

Isn't this just the newtype pattern?

To be fair, the fact that the IO Monad is in fact a monad is a sort of quality of life solution. Monads themselves don't have any side effect implications

Something about the website is melting my phone while trying to read the article. I think it's maybe those animations? Couldn't finish reading because the tab froze

It's a quote that originated as a paraphrase of Einstein about applying Occam's razor to development of scientific theories.

Things should be as simple as possible, with respect to your criteria. E.g. a scientific theory should posit as few objects as possible while still being able to explain all observed phenomenons.

Yes, it's a pretty good book. I'm somewhat annoyed at the book _sometimes_ speaking in general terms applicable to any paradigm, and then sometimes speaking in very OOP centric terms. It's still a worthwhile read.

I read this book with some colleagues at a work book club, and I think it's interesting how split the opinion on the book is among readers.

My impression is that there's some good ideas in the book, but it suffers from not being thorough enough on a theoretical level. Many definitions given are NOT consistently used, the book frequently falls back on discussing things in a very OOP centric way, and a lot of stuff came across to me as just opinion pieces.

Some stuff I found was excellent, like the notion of module depth.

When reading reviews on Goodreads, there's a similar disparity between people who really liked it and people who are critical of it.

Your own words betray you.

Pinning down the details of your requirements is _exactly_ the act of choosing the correct level of abstraction. When picking out what matters for correct behavior, and what doesn't, you are defining an abstraction.