Hi Offray, Very kind of you to have shared links to the document: "Tracing the Dynabook". That thesis is what I will definitely read through thoroughly, even though it weighs in at 300+ pages. But, and a big but, I doubt the validity of the depth of research conducted by John W Maxwell. In the opening sentences of his abstract, he errs by stating that: The origins of the personal computer are found in an educational vision. Desktop computing and multimedia were not first conceived as tools for office workers or media professionals— they were prototyped as “personal dynamic media” for children.
Both of John Maxwell's statements above are "completely" brain-dead. To begin with, the origins of the "personal" computer and therefore by extension, "desktop computing" were laid out by the team of Dr Douglas Englebart at SRI and was brilliantly presented in his demonstration in 1968. Dr Douglas Englebart conceived of his Online System (NLS) at SRI for the explicit need of "knowledge workers", a term later on stolen by Mr Steve Jobs. Also, in case you haven't known, Mr Alan Kay worked as a non-core member of Dr Englebart's team, before being poached by Xerox for PARC. If I am not wrong, Mr Alan Kay, back then, was just an intern at SRI. Also, I give full credit to Mr Alan Kay for conceiving a message-passing based programming system which morphed into Smalltalk, and even more, I am in awe of Mr Dan Ingalls for having implemented large sections of it, using the crude tools of his day. I assure you that I will overlook that fundamental flaw in John Maxwell's premise and plow through his entire thesis. Again, thanks for sharing details regarding John Maxwell's thesis, as well as writing-in your mail outlining the benefits of engaging with Smalltalk/Pharo. Best regards, ~Mayuresh On Tuesday, January 17, 2023 06:32 AM IST, Offray Vladimir Luna Cárdenas <offray.l...@mutabit.com> wrote: > Hi Mayuresh, > > To add a little bit to the excellent answers thread, I would emphasize > that the important thing is effectively the how and not the what, > despite of some languages excelling at some particular contexts (for > example JavaScript being part of the de-facto emergent glued together > under pressure "standard" for the Web with HTML and CSS being the other > two parts of the Manticore) or that, at some point, several of us have > listened that all languages being Turing complete are equivalent in such > nerdy metric and capable of the same "what", but definitively not of the > same how. Even authors like Maxwell in Tracing the Dynabook[1], said > that comparing Smalltalk with other computer languages (like Ruby or > Python) instead of computer environments misses the point and that a > more convenient comparison would be between the Dynabook tradition and > the Unix tradition. > > [1] > https://mutabit.com/repos.fossil/grafoscopedia/uv/#Tracing%20the%20Dynabook > > In the case of Pharo and Smalltalk, I feel them pretty empowering as a > way of conceiving computing, where environment, language, tools, apps, > conform an explorable/modifiable continuum, instead of all the > indirection layers common in the Unix paradigm. This have allow us in > the local community to address a set of projects in a pretty different a > more agile way to what could be done in languages like Python under Unix > (and I tried that combination before confirming my definitive bet for > Smalltalk like/inspired metasystems). As a consequence, we have been > able to enable grassroots innovation in several topics that fall under > the umbrella of civic tech, including: performative writing and > (re)publishing, agile data storytelling and visualization, data > feminism, civic hacktivism, reproducible research, making "Big Data" > approachable, hypertextual resilient community and interpersonal memory > and presences, among other topics (see our portfolio at [2]). > > [2] https://mutabit.com/repos.fossil/offray-blog/uv/bliki/#Portfolio > > Even when Pharo/Smalltalk are not suited for every context, you can > combine them with external tools (for example when some functionality is > not implemented in Pharo or for performance reasons). We have being > doing that with Nim language, Lua, Pandoc with pretty good results. So > you can be as agile as you need and rely on external tools when needed. > Pharo is not only a innovative place/tech with a welcoming, vibrant and > responding community, but also is becoming a good team player with other > tech ecosystems and tools. > > Hope this helps, > > Offray > > > > On 15/01/23 5:30, Tomaž Turk wrote: > > Hi Mayuresh, > > > > I think that the choice of what programming language one needs to > > learn or use depends today from the goals that you have - and these > > goals are not only tied to specifiic business projects that you > > (might) pursue but also career and self-enrichment missions. Years ago > > we had programmers who did their entire career by knowing and using > > only one language, however this is nowadays almost impossible, in general. > > > > As others already nicely put, Pharo and Smalltalk are, also in my own > > expeirence, the most beautiful and productive programming languages > > and environments. What would be the type of use cases which would be > > exemplary for Pharo? Well, I find Pharo to be a general programming > > language in its true meaning. You can grasp the diversity of what can > > be done by just looking at this list > > https://github.com/pharo-open-documentation/awesome-pharo. You can go > > close to the machine with uFFI and be very "declarative" with Glorp > > and similar packages. You'd like to do the data mining? No problem, > > except that everybody talks about Python and R. > > > > As MIS professor, I'm interested in new technologies, old technolgies > > in new settings, always looking for the best ways to do research about > > and to teach modern concepts, also challenging myself with real, > > "production" cases from the field. Once I learnt the Smalltalk way, > > the challenges for me with Pharo were mostly the following: > > - For a specific project, you sooner or later bump into a missing > > functionality in some package or other. Here, it's true that you can > > relatively easy see the inner structures of these packages and add the > > functionality that you need. The challenge here is grasping the > > architecture model and development patterns that the original > > contrubutors and the community already "engraved" into the package, > > trying to understand it and to follow the same patterns - i.e. to > > participate in a constructive manner. My case: PharoWin32 and PharoCOM > > <https://github.com/tesonep/pharo-com>, I had to add the functionality > > that I needed to work on PharoADO <https://github.com/eftomi/PharoADO>. > > - There is a constant lag of documentation publishing activities which > > cannot follow the actual development; typical examples that I stumbled > > across are Pharo Spec2 book (but it can be "replaced" by excellent > > Spec Handbook > > <https://github.com/pharo-spec/Spec/blob/Pharo11/spec2.md#SpStyleClass>), > > the second one the deeper settings of Seaside framework that I needed > > for production environment. > > > > For these challenges, you can always count on really helpful > > community, however it is time consuming and eats away the positive > > side of productivity gains that are brought by the language itself. > > > > So, if you need some occupation, not necessarily one from which you > > would demand financial returns as you put, I suggest that you choose a > > couple of small projects just to try it out and see what happens. > > Pharo is a heavy addition to one's self-enrichment in the sense of not > > learning the tools but learning the concepts and "the big picture". > > Nice examples are the book Learning Object-Oriented Programming, > > Design and TDD <http://books.pharo.org/> and Pharo MOOC > > <https://mooc.pharo.org/>. If you pursue into more serious projects > > (research or productionwise), the community would be grateful. > > > > Best wishes, > > Tomaz
