11–20 of 29 posts
Reminded me of bret victors “toolkits, not apps” comment ( https://mobile.twitter.com/worrydream/status/881021457593057... ) and an excerpt from the smalltalk era : https://www.youtube.com/watch?v=AnrlSqtpOkw&t=4m19s
I _agree_ that we should think more about systems design. And I _agree_ that the individual "units" that we're designing would benefit from standard ways of communicating with each other.
The entire thing about "let's not call it a program!" feels like a distraction from the core point, though. I guess I don't really believe that calling the "unit of software development that I'm currently working on" a program harms it or limits it in any way.
Even in the article, the author talks about isolated spaces:
>While the Smalltalk model holds a large number of objects in a single ‘space’ - we could imagine a system where each object has internal space which holds a cluster of inner objects, and so on.
...and so, poof, we now have a unit of software that could easily be called a "program." A program that contains multiple layers of inner program, but there's nothing about the word "program" that limits how it can be applied.
So I think 95% of this article is philosophical semantic gymnastics. There's a seed of an interesting idea -- software would benefit from the ability to connect its pieces more flexibly -- but without an actionable hint as to how to _get_ there, this is just a pointless intellectual exercise.
Changing the word to something else doesn't actually make the problem easier to solve.
A program is a set of commands. It can include state information and adaptability. A system is a system. A system, from a programming perspective, is something to be modeled and manipulated to a desired state. If you do this correctly, you're done. You don't need a degree in philosophy for this. On the other hand, a lot of programming involves creating a stateless function that looks like a simple set of commands. That's it. Input in, output out, predictable behavior, zero adaptability, zero mutability.
I really enjoyed the book, "Thinking in Systems: A Primer", because it expanded my horizons and gave words to concepts I had for systems behavior. https://www.goodreads.com/book/show/3828902-thinking-in-syst...
I think we should go even further and think systemic. I work in the public sector, where we have more than 500 different IT systems (in this context, mostly programs). It’d be a clear advantage if they were all build to be systems, but it would be even better if they were build to be systems that coexist with each other. I wish suppliers would ask us what hardware we operate, what services and API we’d want them to i…
The problem is if it's difficult to get data into or out of them.
At work we make a fairly specialized application, but we're very flexible in how we can receive data and send data back out. From manually copying and pasting Excel sheets, parsing emails and PDFs, plain XML over SFTP or web services/REST APIs, we got solutions depending on where the core data comes from and where results needs to go (status back to WMS/TMS, financial details to invoicing system etc).
If needed we have customer-specific "integration shims" to easily adjust/correct/ignore data as it comes or goes.
This allows us to focus on making our application really good at a few things, and let other programs handle the tasks our customer also needs to get the job done (warehouse management, transport management, invoicing etc).
I agree though that support can be a bit of an issue when you have many systems working together and something is wrong. The place where the user discovers the error is often not the place where the error occurred. Monitoring is important, allowing support to be proactive ("hey, the server where you're hosting the DB to our program has less than 1GB diskspace left again").
This felt to me like a roundabout way of saying "we should think more about design!" I _agree_ that we should think more about systems design. And I _agree_ that the individual "units" that we're designing would benefit from standard ways of communicating with each other. The entire thing about "let's not call it a program!" feels like a distraction from the core point, though. I guess I don't really believe that cal…
A comparison would be a computer system is like a biological ecosystem, whereas a program is like an individual biological entity. Much like biological systems, computer systems and programs are made up of small similar pieces that have defined functionality, and their interactions result in a system. Microbiology results in macrobiological systems, and macrobio results in ecosystems, etc. Program, system, whatever; it's turtles all the way down.
Also, this:
> we can also consider replacing the write-then-run program idea [..] with an incremental model where the programmer successively provides more detail about the desired behavior and a constraint solving system refines the behavior
So, like, test-driven Agile programming?
Earlier quoted context omitted.
Emergent behavior isn't always wanted. Sometimes it's desirable (Oh, this widget can be copy/pasted into other documents! I didn't expect that to work yet.) Sometimes it's not (I can't figure out why this bot keeps stacking boxes. Patrolling the area is supposed to be its highest priority right now.). Sometimes we can deliberately induce emergent behavior ( https://en.wikipedia.org/wiki/Automated_planning_and_schedul…
Why do you reference the article on planning and scheduling?
https://en.wikipedia.org/wiki/Automated_planning_and_schedul...
Also, I think I deleted something extra in an edit of my original post. These planning algorithms (or some of them) involve creating options for your agent/AI and seeing what it does when interacting with its environment. You don't design the agent so that it will do a complex task, rather you give it simpler abilities (recognize an object type, pick up an object, set down an obect on another object, etc.) and the complexity arises precisely from emergent behavior. This was meant as an example of precisely where you do want emergent behavior and actively work to induce it.
I really enjoyed the book, "Thinking in Systems: A Primer", because it expanded my horizons and gave words to concepts I had for systems behavior. https://www.goodreads.com/book/show/3828902-thinking-in-syst...
Can you share some of those words with us? Because in these comments I'm reading things like, "A system is a system."
So, what is a system? A system is a set of things—people, cells, molecules, or whatever—interconnected in such a way that they produce their own pattern of behavior over time. The system may be buffeted, constricted, triggered, or driven by outside forces. But the system’s response to these forces is characteristic of itself, and that response is seldom simple in the real world.
When it comes to Slinkies, this idea is easy enough to understand. When it comes to individuals, companies, cities, or economies, it can be heretical. The system, to a large extent, causes its own behavior! An outside event may unleash that behavior, but the same outside event applied to a different system is likely to produce a different result.
Think for a moment about the implications of that idea:
• Political leaders don’t cause recessions or economic booms. Ups and downs are inherent in the structure of the market economy.
• Competitors rarely cause a company to lose market share. They may be there to scoop up the advantage, but the losing company creates its losses at least in part through its own business policies.
• The oil-exporting nations are not solely responsible for oil- price rises. Their actions alone could not trigger global price rises and economic chaos if the oil consumption, pricing, and investment policies of the oil-importing nations had not built economies that are vulnerable to supply interruptions.
• The flu virus does not attack you; you set up the conditions for it to flourish within you.
• Drug addiction is not the failing of an individual and no one person, no matter how tough, no matter how loving, can cure a drug addict—not even the addict. It is only through understanding addiction as part of a larger set of influences and societal issues that one can begin to address it.
And an initial definition of a system on chapter 1 page 1:
A system is an interconnected set of elements that is coherently organized in a way that achieves something. If you look at that definition closely for a minute, you can see that a system must consist of three kinds of things: elements, interconnections, and a function or purpose.
edit oops, I misinterpreted what you meant by “some of those words”, didn’t take it literally... Will leave this up anyways I suppose, sorry!