3 ms·

> Can you provide concrete examples of the things that you think are foundational in software? Are you really expecting an answer here? I'll answer anyway. •

by whstl 10mo ago

> Can you provide concrete examples of the things that you think are foundational in software? Are you really expecting an answer here? I'll answer anyway. • A big chunk of the CompSci curriculum is foundational. • Making wrong states unrepresentable either via type systems or via code itself, using invariants, pre/post-conditions, etc. This applies to pretty much every tool or every language you can use. • Error handling is a topic that goes beyond tools and languages, and even beyond whether you use try/catch, algebraic objects or values. It seeps into logging and observability too. • Reasoning about time/space and tradeoffs of algorithms and structures, knowing what can and can't be computed, parsed, or recognized at all. Knowing why some problems don’t scale and others do. • Good modeling of change, including ordering: immutability vs mutation, idempotency, retry logic, concurrency. How to make implicit timing explicit. Knowing which choices are cheap to undo and which are expensive, and design for those. • Clear ownership of responsibilities and data between parts of the system via design of APIs, interfaces and contracts. This applies to OOP, FP, micro-services, modules and classes, and even to how one deals with third party-services beyond the basic. • Computer basics (some of which goes back to 60s/70s or even back): processes, threads, green memory, scheduling, cache, instructions, memory hierarchy, threads, but races, deadlock, and ordering. • Information theory (a lot goes to Claude Shannon, and back): compression, entropy, noise. And logic, sets, relations, proofs. I never said there is a "simple rule" only foundational topics, but I'll say again: The biggest curse of software is people saying "no" to education and knowledge.

RaftPeople 10mo ago
> Are you really expecting an answer here? I'll answer anyway. Yes, and thanks for the examples, it's now clear what you were referring to. I agree that most of those are generally good fundamentals (e.g. wrong states, error handling, time+space), but some are already in complex territory like mutability. Even though we can see the problem, we have a massive amount of OOP systems with state all over the place. So the application of a principle like that is very far from settled or easy to have a set of rules to guide SE's. > The software engineers' body of knowledge can change 52 times in a year Nah, those changes are only in the surface, at the most shallow level. I think the types of items you listed above are the shallow layer. The body of knowledge about how to implement software systems above that (the patterns and approaches) is enormous and growing. It's a large collection of approaches each with some strengths and weaknesses but no clear cut rule for application other than significant experience.
- whstl 10mo ago
  > I think the types of items you listed above are the shallow layer They are not, by definition. You provided proof for it yourself: you mention the "body of knowledge [...] above that", so they really aren't the topmost layer. > is enormous and growing That's why you learn the fundamentals. So you can understand the refinements and applications of them at first glance.
  - RaftPeople 10mo ago
    > They are not, by definition. You provided proof for it yourself: you mention the "body of knowledge [...] above that", so they really aren't the topmost layer I said "shallow", not "topmost". > That's why you learn the fundamentals. So you can understand the refinements and applications of them at first glance. Can you explain when (if ever) a person should use an OOP approach and when (if ever) he/she should use a functional approach to implement a system? I don't think those fundamentals listed above help answer questions like that and those questions are exactly what the industry has not really figured out yet. We can see both pros and cons to all of the different approaches but we don't have a body of knowledge that can point to concrete evidence that one approach is preferred over the many other approaches.
    - whstl 10mo ago
      I'm really sorry, but if you think those topics above are "shallow", I don't think we have much to talk about and should probably agree to disagree. > Can you explain when (if ever) a person should use an OOP approach and when (if ever) he/she should use a functional approach to implement a system? I can, and have done several times, actually, for different systems. > I don't think those fundamentals listed above help me The list I gave was not exhaustive. You asked yourself for "concrete examples" and I gave examples. The reason I can't answer hard questions in a simple message is exactly because those foundations are not "shallow" at all.
      - RaftPeople 10mo ago
        > I can, and have done several times, actually, for different systems. The reason I asked that question isn't to be argumentative, it's because, IMO, the answer to those types of questions are exactly what does not exist in the software engineering world. And talking through the details of our different opinions is how we can understand where each one is coming from and possibly, maybe, incorporate some new information or new way of looking at things into our mental models of the world. So, if you do think you have an answer, I am truly interested in when you think OOP is appropriate and when functional is better suited (or neither). If someone asked me that question, I would say "If we're in fantasy land and it's the first system ever built and there are no variables related to existing systems and supportability and resource knowledge, etc., then I really can't answer the question. I've never built a system that was significantly functional, I've only built procedural, OOP and mixtures of those two with sprinklings of functional. I know there are significant pros to functional, but without actually building a complete system at least once, I can't really compare"

by whstl 10mo ago

RaftPeople 10mo ago

> Are you really expecting an answer here? I'll answer anyway. Yes, and thanks for the examples, it's now clear what you were referring to. I agree that most of those are generally good fundamentals (e.g. wrong states, error handling, time+space), but some are already in complex territory like mutability. Even though we can see the problem, we have a massive amount of OOP systems with state all over the place. So the application of a principle like that is very far from settled or easy to have a set of rules to guide SE's. > The software engineers' body of knowledge can change 52 times in a year Nah, those changes are only in the surface, at the most shallow level. I think the types of items you listed above are the shallow layer. The body of knowledge about how to implement software systems above that (the patterns and approaches) is enormous and growing. It's a large collection of approaches each with some strengths and weaknesses but no clear cut rule for application other than significant experience.

whstl 10mo ago
> I think the types of items you listed above are the shallow layer They are not, by definition. You provided proof for it yourself: you mention the "body of knowledge [...] above that", so they really aren't the topmost layer. > is enormous and growing That's why you learn the fundamentals. So you can understand the refinements and applications of them at first glance.
- RaftPeople 10mo ago
  > They are not, by definition. You provided proof for it yourself: you mention the "body of knowledge [...] above that", so they really aren't the topmost layer I said "shallow", not "topmost". > That's why you learn the fundamentals. So you can understand the refinements and applications of them at first glance. Can you explain when (if ever) a person should use an OOP approach and when (if ever) he/she should use a functional approach to implement a system? I don't think those fundamentals listed above help answer questions like that and those questions are exactly what the industry has not really figured out yet. We can see both pros and cons to all of the different approaches but we don't have a body of knowledge that can point to concrete evidence that one approach is preferred over the many other approaches.
  - whstl 10mo ago
    I'm really sorry, but if you think those topics above are "shallow", I don't think we have much to talk about and should probably agree to disagree. > Can you explain when (if ever) a person should use an OOP approach and when (if ever) he/she should use a functional approach to implement a system? I can, and have done several times, actually, for different systems. > I don't think those fundamentals listed above help me The list I gave was not exhaustive. You asked yourself for "concrete examples" and I gave examples. The reason I can't answer hard questions in a simple message is exactly because those foundations are not "shallow" at all.
    - RaftPeople 10mo ago
      > I can, and have done several times, actually, for different systems. The reason I asked that question isn't to be argumentative, it's because, IMO, the answer to those types of questions are exactly what does not exist in the software engineering world. And talking through the details of our different opinions is how we can understand where each one is coming from and possibly, maybe, incorporate some new information or new way of looking at things into our mental models of the world. So, if you do think you have an answer, I am truly interested in when you think OOP is appropriate and when functional is better suited (or neither). If someone asked me that question, I would say "If we're in fantasy land and it's the first system ever built and there are no variables related to existing systems and supportability and resource knowledge, etc., then I really can't answer the question. I've never built a system that was significantly functional, I've only built procedural, OOP and mixtures of those two with sprinklings of functional. I know there are significant pros to functional, but without actually building a complete system at least once, I can't really compare"