4 ms·

I watched the first half hour of this earlier this week. I was surprised at just how differently two people can view the world. I'm not sure I would be as dogma

I watched the first half hour of this earlier this week. I was surprised at just how differently two people can view the world. I'm not sure I would be as dogmatic as him, but just using the first few points, I think you can make strong cases against: 1. Everything is exposed as an API with little no insight to inner workings (black box) 2. Everything should be broken down into modules at a level where one person works on that module 3. He shows a video of his video editor, saying it supports multiple inputs (like two keyboards or two mice), then says no platform supports it, but if they ever do, it will work 4. Don't implement 'good enough apis' I hope that anybody who has ever worked on software understands that there are virtues to doing exactly the opposite of what is described in each of these points. Even if you can make an argument for any of these, you would have to qualify them with so many exceptions that you would effectively negate the entire argument. I spent a lot of evenings early in my career watching similar videos, hoping to find some magic bullet in how people better than me do what I do. People make a living doing this on the conference circuit. Maybe it is a fools errand to try to distill something as complex and situationally dependent as software into a video, but I'm having a hard time finding any major insights in all of the videos I watched.

ribelo 1y ago
He basically just described the FCIS[0] architecture—the same one Gary Bernhart laid out thirteen years ago. We love reinventing the wheel. Chaplicki did it with ELM, Abramov with Redux, day8 did it with re-frame, and the beat goes on. I’m still amazed it isn’t obvious: every piece of software should be a black box with a pin-hole for input and an even tinier pin-hole for output. The best code I’ve ever touched worked exactly like that and maintaining it was a pleasure, everything else was garbage. I push this rule in every project I touch. [0] https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell https://www.destroyallsoftware.com/screencasts/catalog/funct...
- leecommamichael 1y ago
  Could you point to the place in the video that you felt resembled this principle most? I don’t really see the connection, but am open to it.
- thisoneisreal 1y ago
  "The Unaccountability Machine" does a great job summarizing the thought of Stafford Beer, who explained basically exactly what you said as the only viable strategy for designing and managing complex systems.
- preommr 1y ago
  > Chaplicki did it with ELM, Abramov with Redux, day8 did it with re-frame, and the beat goes on. None of these projects reinvented the concept of FCIS. These are just projects that had functional elements, or were outright functional languages. This is like saying jsx reinvented markup languages.
  - pjmlp 1y ago
    I think the actual point was, > We love reinventing the wheel.
leecommamichael 1y ago
I think the mistake people make when trying to teach this stuff is in generalizing too much. His input layer is good because it helped him emulate local multiplayer with keyboard and mouse. It solved _his problem_. The graphics layer is good because it is so much easier to work with than OpenGL _for him_. The library wrappers are good for him because they solve _his desire_ to run portably while maintaining the smallest possible interface. This stuff matters to Eskil because he’s: - just one person - has deep expertise in what he’s wrapping (win32, OpenGL) - wants to make an impressive program solo I think his expertise, historical perspective, and culture make it feel as if this is the only way to do this very hard task, so he wants to share it. It helps him believe his way is right that many great, and reliable projects are done in C89. I think the truth at this point is that folks still using old versions of C have, on average, more experience than everyone else. It’s not just the language that’s making them strong, either. It’s having evolved with the platforms. Now the only question that leaves is whether it makes a huge difference to really stick with one language over the decades. I know we’ve all heard both sides of that quandary.
- pjmlp 1y ago
  > ...reliable projects are done in C89. Only if static and dynamic analysers are part of the development cycle.
SkyPuncher 1y ago
This type of software architecture is good when you're building stable, well known systems. Notice that none of his examples were new or novel functionality. Most people don't work in that world.
- wellpast 1y ago
  The majority of people work in that world. Even the majority of startups, where you’d expect to find the novel pursuits, are building glorified spreadsheets.
  - bubblyworld 1y ago
    Startups are glorified spreadsheets in the same sense that you and I are glorified collections of atoms. Technically correct (spreadsheets are turing complete after all) but totally useless as a model of how they work.
    - wellpast 1y ago
      I’m just making the point that most software dev work is not novel. You’re either making a productivity app where CRUD and UX are pretty well known patterns. Or a scalable web system - also very well tried territory. Or analytics and data processing - again well trod. If you’re not a good pattern matcher you might think every UI framework, or your next API abstraction, is some next general theory of relativity. But otherwise the major novelty in most software project pursuits is going to be the context, people, and industry your building it into not the tech
      - bubblyworld 1y ago
        Right, fair enough, I agree with that.
abetusk 1y ago
Thanks, I'm 13m in and I haven't found anything I would consider valuable or insightful. I haven't watched many of these videos but the two that stand out for me as being genuinely helpful is Jonathan Blow's talk about software quality [0-4] and Daniel Sockwell's "Imagining the Ideal Language for Writing Free Software" [5]. From Blow's talk, my takeaways are: * Large organizations don't necessarily know how to make software and small teams can make quality, large scale projects * Abstraction is its own form of optimization and should be used sparingly. Stripping away a level of abstraction is sometimes desirable. * Design should be data centric. That is, focus on how to pass data between different domains of concern. Don't be shy about exposing data and don't hide data. This differs slightly from "API-centric" approaches as the contract is in the data, not in the function call interface. * Keep inheritance to a maximum of 2-3 levels deep, with a preference of 1 or none. Not all language features should be used. Use language features sparingly, and this is one of them. * Duplicate code (e.g. "cut-and-paste") for clarity. Dispensing with code-reuse isn't a sin and is sometimes desirable. DRY is fine but sometimes having a common function increases cognitive load to understand what code is doing and often portions of code that look very similar are different in substantial but subtle ways that make de-duplication overly confusing to handle all cases. When reviewing a function, having all code available locally, without having to page out to different areas of the code base to see what a common function is doing, often helps with readability and isn't as detrimental to reliability as people make it out to be. From Sockwell's talk: It's a weird premise (how can software be ideal for writing FOSS?) but the point is that many software architectural concerns stem from what economic environment they're being developed in. FOSS tends to be developed by a single or small team. The focus is on "master-craft" tools that allow a single contributor to be more effective at the cost of a high learning curve. Since corporate environments tend to have high turn over rate with software developers, the focus is on stable "commodity" tools and methodologies that can better take advantage of the fungible nature of their software developer labor. The talk itself isn't focused on large software projects architecture directly, but, from my perspective, it gives some very actionable items for tackling larger projects on an individual or small teams basis: * Focus on expressibility. That is, choose languages that allow mastery over being "safe/boring/simple". Don't worry about making code readable to the lowest common denominator, make it readable for someone who's at your skill level but is trying to find out what the code does (aka "future you"). Allow "footguns" if you trust you can avoid them. Don't worry about language popularity. Enjoy using a "dialects" if it helps empower you. * Focus on composability. Composability is a broad term but focusing on data-centric design is one way to make things composable as the design can be made around the data being transported. For me, the major insight is to understand the context of what software is being developed. A corporate environment will have different concerns, for both the employer and employee, than a small project with one or a few developers. For example, a corporate environment might favor a language that encourages a type of code structure, testing suite, code review process and idiomatic way of solving problems. This makes labor more fungible but means that increased productivity of any individual developer will be met with resistance if it deviates from corporate convention. It also means employees will be motivated to recommend projects using technology that's perceived to be corporate friendly to make sure they're more marketable. Small projects (FOSS, say) might focus on niche languages, dialects, idioms or other non-standard conventions that incorporate well with the skills of the primary developer. This means the individual developer is more productive but makes it harder for others to contribute. [0] https://www.youtube.com/watch?v=oJ4GcZs7y6g https://www.youtube.com/watch?v=oJ4GcZs7y6g [1] https://www.youtube.com/watch?v=FvBySbGueww https://www.youtube.com/watch?v=FvBySbGueww [2] https://www.youtube.com/watch?v=URSOH4F3vbU https://www.youtube.com/watch?v=URSOH4F3vbU [3] https://www.youtube.com/watch?v=MlIZ2Q3Rvc8 https://www.youtube.com/watch?v=MlIZ2Q3Rvc8 [4] https://www.youtube.com/watch?v=xK6YZ3NFjuE https://www.youtube.com/watch?v=xK6YZ3NFjuE [5] https://ftp.belnet.be/mirror/FOSDEM/video/2021/D.perl/programming_lang_for_free_software.mp4 https://ftp.belnet.be/mirror/FOSDEM/video/2021/D.perl/progra...
deterministic 1y ago
> Everything is exposed as an API with little no insight to inner workings This is how I build large scale biz software (30+ years of experience). And I have never seen a case where it wasn't a good idea. For example, the largest software system in the world (the internet) operate this way. However I am always open to learn something new?
wellpast 1y ago
I had the same reaction. I’m eager to find someone who has managed to abstract expertise. I’m 25 years into repeatedly building large software systems. I was thinking, look here maybe someone’s managed to codify what I do. Nope. To your point, everything is contextual. If you try to apply a suite of rules the systems (which extend far outside of the bounds of a software subsystem deployment) will mock you by burying your efforts leaving no intentional outcome. Everything is systems thinking and every seat & context is different. You have to navigate mostly with realtime navigations based on long- and hard- earned muscle memory.

ribelo 1y ago

He basically just described the FCIS[0] architecture—the same one Gary Bernhart laid out thirteen years ago. We love reinventing the wheel. Chaplicki did it with ELM, Abramov with Redux, day8 did it with re-frame, and the beat goes on. I’m still amazed it isn’t obvious: every piece of software should be a black box with a pin-hole for input and an even tinier pin-hole for output. The best code I’ve ever touched worked exactly like that and maintaining it was a pleasure, everything else was garbage. I push this rule in every project I touch. [0] https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell https://www.destroyallsoftware.com/screencasts/catalog/funct...

leecommamichael 1y ago
Could you point to the place in the video that you felt resembled this principle most? I don’t really see the connection, but am open to it.
thisoneisreal 1y ago
"The Unaccountability Machine" does a great job summarizing the thought of Stafford Beer, who explained basically exactly what you said as the only viable strategy for designing and managing complex systems.
preommr 1y ago
> Chaplicki did it with ELM, Abramov with Redux, day8 did it with re-frame, and the beat goes on. None of these projects reinvented the concept of FCIS. These are just projects that had functional elements, or were outright functional languages. This is like saying jsx reinvented markup languages.
- pjmlp 1y ago
  I think the actual point was, > We love reinventing the wheel.

leecommamichael 1y ago

I think the mistake people make when trying to teach this stuff is in generalizing too much. His input layer is good because it helped him emulate local multiplayer with keyboard and mouse. It solved _his problem_. The graphics layer is good because it is so much easier to work with than OpenGL _for him_. The library wrappers are good for him because they solve _his desire_ to run portably while maintaining the smallest possible interface. This stuff matters to Eskil because he’s: - just one person - has deep expertise in what he’s wrapping (win32, OpenGL) - wants to make an impressive program solo I think his expertise, historical perspective, and culture make it feel as if this is the only way to do this very hard task, so he wants to share it. It helps him believe his way is right that many great, and reliable projects are done in C89. I think the truth at this point is that folks still using old versions of C have, on average, more experience than everyone else. It’s not just the language that’s making them strong, either. It’s having evolved with the platforms. Now the only question that leaves is whether it makes a huge difference to really stick with one language over the decades. I know we’ve all heard both sides of that quandary.

pjmlp 1y ago
> ...reliable projects are done in C89. Only if static and dynamic analysers are part of the development cycle.

SkyPuncher 1y ago

This type of software architecture is good when you're building stable, well known systems. Notice that none of his examples were new or novel functionality. Most people don't work in that world.

wellpast 1y ago
The majority of people work in that world. Even the majority of startups, where you’d expect to find the novel pursuits, are building glorified spreadsheets.
- bubblyworld 1y ago
  Startups are glorified spreadsheets in the same sense that you and I are glorified collections of atoms. Technically correct (spreadsheets are turing complete after all) but totally useless as a model of how they work.
  - wellpast 1y ago
    I’m just making the point that most software dev work is not novel. You’re either making a productivity app where CRUD and UX are pretty well known patterns. Or a scalable web system - also very well tried territory. Or analytics and data processing - again well trod. If you’re not a good pattern matcher you might think every UI framework, or your next API abstraction, is some next general theory of relativity. But otherwise the major novelty in most software project pursuits is going to be the context, people, and industry your building it into not the tech
    - bubblyworld 1y ago
      Right, fair enough, I agree with that.

abetusk 1y ago

Thanks, I'm 13m in and I haven't found anything I would consider valuable or insightful. I haven't watched many of these videos but the two that stand out for me as being genuinely helpful is Jonathan Blow's talk about software quality [0-4] and Daniel Sockwell's "Imagining the Ideal Language for Writing Free Software" [5]. From Blow's talk, my takeaways are: * Large organizations don't necessarily know how to make software and small teams can make quality, large scale projects * Abstraction is its own form of optimization and should be used sparingly. Stripping away a level of abstraction is sometimes desirable. * Design should be data centric. That is, focus on how to pass data between different domains of concern. Don't be shy about exposing data and don't hide data. This differs slightly from "API-centric" approaches as the contract is in the data, not in the function call interface. * Keep inheritance to a maximum of 2-3 levels deep, with a preference of 1 or none. Not all language features should be used. Use language features sparingly, and this is one of them. * Duplicate code (e.g. "cut-and-paste") for clarity. Dispensing with code-reuse isn't a sin and is sometimes desirable. DRY is fine but sometimes having a common function increases cognitive load to understand what code is doing and often portions of code that look very similar are different in substantial but subtle ways that make de-duplication overly confusing to handle all cases. When reviewing a function, having all code available locally, without having to page out to different areas of the code base to see what a common function is doing, often helps with readability and isn't as detrimental to reliability as people make it out to be. From Sockwell's talk: It's a weird premise (how can software be ideal for writing FOSS?) but the point is that many software architectural concerns stem from what economic environment they're being developed in. FOSS tends to be developed by a single or small team. The focus is on "master-craft" tools that allow a single contributor to be more effective at the cost of a high learning curve. Since corporate environments tend to have high turn over rate with software developers, the focus is on stable "commodity" tools and methodologies that can better take advantage of the fungible nature of their software developer labor. The talk itself isn't focused on large software projects architecture directly, but, from my perspective, it gives some very actionable items for tackling larger projects on an individual or small teams basis: * Focus on expressibility. That is, choose languages that allow mastery over being "safe/boring/simple". Don't worry about making code readable to the lowest common denominator, make it readable for someone who's at your skill level but is trying to find out what the code does (aka "future you"). Allow "footguns" if you trust you can avoid them. Don't worry about language popularity. Enjoy using a "dialects" if it helps empower you. * Focus on composability. Composability is a broad term but focusing on data-centric design is one way to make things composable as the design can be made around the data being transported. For me, the major insight is to understand the context of what software is being developed. A corporate environment will have different concerns, for both the employer and employee, than a small project with one or a few developers. For example, a corporate environment might favor a language that encourages a type of code structure, testing suite, code review process and idiomatic way of solving problems. This makes labor more fungible but means that increased productivity of any individual developer will be met with resistance if it deviates from corporate convention. It also means employees will be motivated to recommend projects using technology that's perceived to be corporate friendly to make sure they're more marketable. Small projects (FOSS, say) might focus on niche languages, dialects, idioms or other non-standard conventions that incorporate well with the skills of the primary developer. This means the individual developer is more productive but makes it harder for others to contribute. [0] https://www.youtube.com/watch?v=oJ4GcZs7y6g https://www.youtube.com/watch?v=oJ4GcZs7y6g [1] https://www.youtube.com/watch?v=FvBySbGueww https://www.youtube.com/watch?v=FvBySbGueww [2] https://www.youtube.com/watch?v=URSOH4F3vbU https://www.youtube.com/watch?v=URSOH4F3vbU [3] https://www.youtube.com/watch?v=MlIZ2Q3Rvc8 https://www.youtube.com/watch?v=MlIZ2Q3Rvc8 [4] https://www.youtube.com/watch?v=xK6YZ3NFjuE https://www.youtube.com/watch?v=xK6YZ3NFjuE [5] https://ftp.belnet.be/mirror/FOSDEM/video/2021/D.perl/programming_lang_for_free_software.mp4 https://ftp.belnet.be/mirror/FOSDEM/video/2021/D.perl/progra...

deterministic 1y ago

> Everything is exposed as an API with little no insight to inner workings This is how I build large scale biz software (30+ years of experience). And I have never seen a case where it wasn't a good idea. For example, the largest software system in the world (the internet) operate this way. However I am always open to learn something new?

wellpast 1y ago

I had the same reaction. I’m eager to find someone who has managed to abstract expertise. I’m 25 years into repeatedly building large software systems. I was thinking, look here maybe someone’s managed to codify what I do. Nope. To your point, everything is contextual. If you try to apply a suite of rules the systems (which extend far outside of the bounds of a software subsystem deployment) will mock you by burying your efforts leaving no intentional outcome. Everything is systems thinking and every seat & context is different. You have to navigate mostly with realtime navigations based on long- and hard- earned muscle memory.