The original #LISP had 7 primitives: \(\texttt{cons}\), \(\texttt{car,}\) \(\texttt{cdr}\), \(\texttt{atom}\), \(\texttt{quote}\), \(\texttt{eq}\), and \(\texttt{cond}\). And the original #Smalltalk syntax could fit on a 5×7 card. That meant a novice could learn the syntax in a matter of minutes, and direct all his efforts to learning how properly to wield the power of that Turing-complete language. This was why, in the 1970s and the 1980s, many college freshmen were taught FP in Scheme (a more modern LISP) and many middle school children were taught OO in Smalltalk. These were surely the best "first" #programming languages.

#FORTRAN and #BASIC were simple, too. FORTRAN, the first high-level language, has been in continuous use since the late 1950s by engineers, who are not keyboard warriors. BASIC was invented in the early 1960s for teaching programming to non-STEM students at Dartmouth. It sired a whole generation of self-taught children in the 1980s.

Compare those to C++, Erlang, Python, Haskell, Java, JavaScript, Scala, Rust, Kotlin, and pretty much every language in popular use today. Most consider Python and JavaScript to be the simplest of modern languages. Yet, they are massive, complex languages. No 10-year-old could teach himself those, nor should he.

The original versions of those classic languages cannot be used to solve modern problems. But they should still be taught to youngsters as their first language. Throwing in the kids' faces a modern enterprise language confuses them and discourages them. Consequently, many novices never attain that state of flow, when the joy of programming gushes forth.

#Simplicity is a virtue.

I like all #programming languages. I like even more those languages that an experienced #programmer could learn in a few hours, like #Elm, #TypeScript, #Gleam, and a few other similar ones.

I am not claiming that these languages will make all jaded programmers happy, for each has its own set of pluses and minuses. I am simply pointing out that "unquantifiable something" in their design that makes these languages easier to take up.

That "something" could well be #simplicity. The designers of these little languages seem to be more concerned with making the language users' lives easier through simplicity, instead of with impressing other language designers through complexity. This is also the same philosophy behind FORTRAN, LISP, C, and Smalltalk. And I would add ML, MATLAB, and Go to this list, too.

Carved oak stool (2023)

Perky Sue
Johns Canyon Road, UT

Stumbled across this older photo and found it very pleasing to my eye. I hope you find it so, as well.

#StandingStoneSunday

#SimpleSaturday or #SilhouetteSatuday ?

Continuing my theme of hashtags that nobody has ever heard of

The latest episode of #indulgentlyminimal is live! Listen for free on our website or on your favourite #podcast platform.

https://www.indulgentlyminimal.com/episode/minimalism-of-simplicity

This week we’re going back to basics, bringing the focus back to minimalism but how we can use what we have learned from our previous conversations. Join us this week as we discuss minimalism via maximalism, keeping it simple, and the return of the goose...

This is one reason why I ignore mission statements when I make decisions.

#simplicity #sustainability
Honoring the 50th anniversary of E.F. Schumacher’s book Small is Beautiful in 2023, the Schumacher Center commissioned this updated study guide from British author and Journalist David Boyle.

https://centerforneweconomics.org/envision/library/small-is-beautiful-study-guide-50th/

Die Geschichte der #DIY - #Fashion

„A STITCH IN TIME“

#pattern #Schnittmuster #nähen #sewing #stiching #handmade #burda #butterrick #Vogue #mccalls #Simplicity

https://simplicity.com/stitch-in-time

If you’re feeling anxious about the next Trump administration and the grip of Big Tech, take a moment to think about where you’re getting your information. If you’re reading this on my RSS feed or here on Mastodon, congratulations—you’re already part of a decentralized alternative that doesn’t rely on corporate giants.

You don’t need to depend on Big Tech to live a simple life. It’s possible to step back and live below your means, focusing on what truly matters instead of getting caught up in the endless cycle of consumption. Reflect on the repentance needed for all the tech you consume daily. Every time you log onto a corporate platform, remember that you’re feeding into a system that prioritizes profit over your well-being.

Living simply doesn’t mean giving up; it means reclaiming your independence. The Fediverse is waiting for you, offering a chance to connect with others who share your values without the interference of algorithms and ads.

So, if you're feeling overwhelmed by the state of things, remember: you have choices. You can break free from the digital chains of Big Tech and find community in spaces that respect your autonomy. Let’s prioritize genuine connections and take back our freedom from corporate control.

Definitely my philosophy.
#simplicity

'White Hydrangea'
https://fineartamerica.com/featured/white-hydrangea-jasna-dragun.html

#ZenBuddhism’s connection to #Nature is evident in Japanese garden design. Rooted in #Zen principles, #Zen gardens serve as physical manifestations of #simplicity, #mindfulness, & #impermanence. Every element of a #Zen garden, from its rocks to its plants, is meticulously chosen & arranged to evoke a sense of #harmony & #balance.

Language obesity happens one "indispensable" feature at a time.

The vast majority of Go proprosals get rejected. "Oh those opinionated Go maintainers! If the language had just feature x, y, and z, writing code would be so much more efficient."

Beware of the shiny object syndrome.

From one persons perspective, only five feature would be enough to make Go "great". Well, there are umpteenth people who think the same, but with different feature sets in their mind. And their definitions of "great" differ, too.

If Go would happily ingest new language features for the promise of becoming more effective, concise, elegant, etc., it would end up as the next C++.

C++ has started as a lean language, easy to pick up, easy to program with. (I know it because I was there when C++ came out.) Look where it is now: A feature behemoth that became so complicated that teams have to agree on a subset of the language to work efficiently.

There is an old joke among guitarists:
How many guitars are enough?
Just one more.

Go deliberately chose not to go down that route. Go is widely popular in the backend and infrastructure world precisely because it maintains a rather stable feature set. Junior devs can pick up the language quickly, and senior devs aren't encouraged to write "clever" code to try setting themselves apart from the juniors. Everyone speaks the same language because the language is simple but expressive enough to get shit done.