The Atoms of Programming(sicpers.info)
sicpers.info
The Atoms of Programming
http://www.sicpers.info/2017/11/the-atoms-of-programming/
22 comments
Thank you for sharing those; Jackson presented his ideas in a very clear manner. I especially liked how he broke down the evaluation and the accompanying examples. If one replaces users by other developers or even future self, the application of his ideas can lead to better system organization and consequently better developer experience.
I like to use a geographic paradigm when imagining how APIs let programs share data.
http://peterburk.github.io/ideas/#metageography
http://peterburk.github.io/ideas/#metageography
I don't really agree that paradigms are more important than programming languages the way the author suggests here. Most paradigms are best captured in particular languages oriented around those paradigms. I can learn and understand functional programming paradigms much better in a functional programming language than in C. As a naive 18 year old many years ago who knew a bit of BASIC, C++, Java and Pascal I started to think all programming languages were "entirely similar". Being introduced to ML at university rather disabused me of that notion.
I guess my point is that paradigms are important, but that they are best learned in the context of languages that are designed around those paradigms and that learning them can actually be hampered if you are only familiar with languages that don't have good support for those paradigms. New paradigms are also often only really introduced and proved effective in the context of new languages designed around those paradigms. Dreaming up a new paradigm is rather an academic exercise if no language exists that can well represent that paradigm and can be used to build actual working systems proving the paradigm useful and effective.
I guess my point is that paradigms are important, but that they are best learned in the context of languages that are designed around those paradigms and that learning them can actually be hampered if you are only familiar with languages that don't have good support for those paradigms. New paradigms are also often only really introduced and proved effective in the context of new languages designed around those paradigms. Dreaming up a new paradigm is rather an academic exercise if no language exists that can well represent that paradigm and can be used to build actual working systems proving the paradigm useful and effective.
I had a different process. I started with thinking (Basic, assembler and Java) that different paradigms were uniquely suited for different problems. Learning logic programming and functional programming changed this notion. It's possible to reduce a paradigm to explicit boilerplate code. In most cases you can reduce the boilerplate to almost nothing and get mostly idiomatic code without changing your initial approach.
The only thing left are non-functional requirements and while you could get a constant factor of slowdown, most compilers take care of 99% and you won't change complexities.
The only thing left are non-functional requirements and while you could get a constant factor of slowdown, most compilers take care of 99% and you won't change complexities.
> But collecting the models, the different representations of systems conceptually that can be expressed as software, sometimes called paradigms: this is very interesting.
Isn't this another way of saying design patterns? I know the answer has to be "no", but I don't see why.
Isn't this another way of saying design patterns? I know the answer has to be "no", but I don't see why.
Unfortunately "design patterns" for most, means technical programming language patterns, rather than the patterns found in "problem domains" outside of computing that can be repeatedly and predictably modeled into code.
They do exist, but are very rarely known. Take object-orientation. Typically the primary pattern known is just object, class and inheritance. However, there are patterns that build on those to model the things, people, places, events and concepts, and the roles they interact in, and the constraints that limit them, in every "business" or real-world domain.
Why aren't they better known? I think it is because object modeling has entirely lost the battle today to data modeling, where data entities are acted on by external code organized using functional decomposition. It doesn't seem to bother most that for 45 years we have been struggling with the problem that doing so increasingly results in a "big ball of mud" as project size and complexity increases.
They do exist, but are very rarely known. Take object-orientation. Typically the primary pattern known is just object, class and inheritance. However, there are patterns that build on those to model the things, people, places, events and concepts, and the roles they interact in, and the constraints that limit them, in every "business" or real-world domain.
Why aren't they better known? I think it is because object modeling has entirely lost the battle today to data modeling, where data entities are acted on by external code organized using functional decomposition. It doesn't seem to bother most that for 45 years we have been struggling with the problem that doing so increasingly results in a "big ball of mud" as project size and complexity increases.
We maintain a lightweight platform alongside a legacy platform that is an untestable ball of mud. This resulted from rapid implementation of business demands over the years, along with a practice of addressing numerous data quality problem through hacks in components, rather than cleaning the data or using a sanitization layer to access it.
Lack of dependency inversion in systems like this is truly the road to ruin, as the system complexity grows so quickly in time, due to interactions, that eventually nobody really understands what it does or why it does it.
I suppose this is tolerable for some applications, but if you need to numerically validate it, it's a nightmare.
Lack of dependency inversion in systems like this is truly the road to ruin, as the system complexity grows so quickly in time, due to interactions, that eventually nobody really understands what it does or why it does it.
I suppose this is tolerable for some applications, but if you need to numerically validate it, it's a nightmare.
No. Aside from the excellent link to Peter Van Roy's work someone else posted in this tree, take a look at http://wiki.c2.com/?ThereAreExactlyThreeParadigms.
Models are the substrate on which design patterns are built. Most of the design patterns you know are based on an object-oriented model. Functional programming presents a different model, with its own set of patterns (of which, for example, "monad" is one).
I'd say no, design patterns are about mechanism, 'I want to do X, this pattern is how I do it'. In that way they are similar to monads. Pardigms are about a perspective, a vantage point from which you structue your application.
Say dataflow programming, for which Norvig's sentence generator in PAIP is an excellent introduction, one can use a switch/case or an object with functions as values. Both accomplish the same, but in the latter I change the flow of my program by changing a value in a map.
Say dataflow programming, for which Norvig's sentence generator in PAIP is an excellent introduction, one can use a switch/case or an object with functions as values. Both accomplish the same, but in the latter I change the flow of my program by changing a value in a map.
Not really, no. Paradigms are quite a bit broader.
One definition/explanation:
https://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf
They also have a nice book: https://www.info.ucl.ac.be/~pvr/book.html
I personally think the notion of architectural style is more useful.
One definition/explanation:
https://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf
They also have a nice book: https://www.info.ucl.ac.be/~pvr/book.html
I personally think the notion of architectural style is more useful.
Same thought occurred to me but upon reflection perhaps they're different levels of the same thing.
tricks->idioms->techniques->patterns->paradigms->...?
tricks->idioms->techniques->patterns->paradigms->...?
"A language that doesn't affect the way you think about programming, is not worth knowing."
- Alan Perlis
- Alan Perlis
I thought I was crazy for a second... I clicked on the link that scrolls into view when you visit the linked page, and it brought me to an article with the same name and roughly the same content: https://www.startupon.net/2017/11/18/the-atoms-of-programmin...
I thought that was the article people were discussing and couldn't figure out why no one else was mentioning having trouble following the flow of the language:
I thought that was the article people were discussing and couldn't figure out why no one else was mentioning having trouble following the flow of the language:
But the utility, the summary configurations of suggestions that speed on these programs,
exist in fully separate condo and are merely (though the undeniable truth that here’s
that that you can maybe be additionally bear in mind is immensely worthy) translated
into the digital or paper medium.
Actually the whole site (startupon.net) is a bit bizarre.
There is an article on Milo which looks computer generated.
And then translated to English; instead of alt-right it has alt-correct!
And the phrasing is really weird.
There is an article on Milo which looks computer generated.
And then translated to English; instead of alt-right it has alt-correct!
And the phrasing is really weird.
Thanks! We've removed the anchor from http://www.sicpers.info/2017/11/the-atoms-of-programming/com....
Shouldn't the URL be changed to remove the #hash?
This is linking to a comment?
These two lectures by Jackson are great:
SATURN 2016 Keynote: Rethinking Software Design - https://youtu.be/LDny7VGLzTE
UMass Amherst CICS Distinguished Lecture: Daniel Jackson (Massachusetts Institute of Technology) https://youtu.be/cNe6g0qczxE
[1] http://people.csail.mit.edu/dnj/