@kentpitman wrote quite some time ago:
«...
I often do binary partitions of languages (like the static/dynamic split, but more exotic), and one of them is whether they are leading or following, let's say.
...
But, and this is where I wanted to get to, Scheme led on continuations. That's a hard problem and while it's possible, it's still difficult.
...
In the early days of Lisp, the choice to do dynamic memory management was very brave.
...»

Is this related to Worse Is Better?

(I suppose it may be unusual to apply the latter to the Lisp family of languages, but nevertheless.)

#ComputerProgramming
#Lisp
#ProgrammingLanguages
#ProgrammingLanguageDevelopment
#WorseIsBetter

@screwlisp @cdegroot @ramin_hal9001

🧵 3of3
The last portion of Richard Gabriel's #WorseIsBetter is most salient pour moi:

"Completeness: the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface."

NGL the CS Stanford Edu (middle of thread was the more enjoyable read for me)

#ThinkElegantly #WednesdayWisdom

🧵2of3
Richard Gabriel "The worse-is-better philosophy is only slightly different (MIT/Stanford style of design's The Right Thing):

Simplicity: the #design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.

Correctness: the design must be correct in all observable aspects. It is slightly better to be simple than correct.

Consistency: the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency."

Source: https://web.stanford.edu/class/archive/cs/cs240/cs240.1236/old/sp2014/readings/worse-is-better.html

#WorseIsBetter #WednesdayWisdom #ThinkElegantly

Needless to say, this is interesting and valuable.

I wonder how this approach could be applied to Richard Gabriel's famous "worse is better".

I can't summarize it properly here, but in a sentence,
this is a thesis that
a partial solution that is available now and that can be improved later
often wins
over a complete solution that takes a long time to be produced.

#DoingTheRightThing
#WorseIsBetter

@johncarlosbaez @Adittya

@atlefren @kly

Det er på et vis den naturlige utviklingen av å prioritere "enkelt å komme igang" over alt annet. Har sett noen tilsynelatende js-utviklere omtale det på et vis som … kanskje er sånn Rust-typer ville omtalt js og php.

Basert på det forventer jeg at det blir ekstremt vanlig og ekstremt dritt. #WorseIsBetter gjelder formodentlig fortsatt (selv om js ser ut til å bli skiftet ut med ts i disse dager)

@cstross Unfortunately what UNIX actually delivered was "a bunch of tools that just barely perform their purpose", the culmination of #WorseIsBetter.

These days I barely use bash files as config files with reams of `export FOO=BAR` or a bunch of flags set for some other command; pretty much anything complex enough to have some conditionals or functions get turned into a Python script.

Perl at least got `use strict;`; bash remains broken with its "unofficial strict mode".