Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Worst is Best #16

Open
jbenet opened this issue Jun 15, 2014 · 4 comments
Open

Worst is Best #16

jbenet opened this issue Jun 15, 2014 · 4 comments

Comments

@jbenet
Copy link
Owner

jbenet commented Jun 15, 2014

@cleichner let's set aside time and draft this essay here.

Premise: javascript is C in the "Worse is Better" paradigm.
Goal: extract learnings from "worse" programming systems that won. Identify properties systems should aim for and avoid.

@cleichner
Copy link

I like the phrase "Programming System" and think it is very useful for these sorts of discussions. This is going to be super scattershot because I thought about this a bit this morning and want to get these ideas out.

Worse is better and friends were written before the development of the internet so it misses some very important facets of development now.

  • The rise of the open source movement.
  • Licensing issues and accidental ubiquity.
  • Deployment, packaging, and monitoring.
  • Development via copy-pasta and Stack Overflow.

With that in mind, there are two more examples of systems being more important than language in a worse-is-better (or maybe system-is-better) way:

  • PHP and the LAMP stack - Lack of barrier to entry, easy on-ramp. Very very easy development and deployment story. Lots of available examples for copy-paste coding. (PHP's package manager is Google) Great documentation with user-contributed notes
  • Java and the JVM and how it became ubiquitous in enterprise development - strong deployment and monitoring tools, code maintenance via IDE. Also interesting because of the current reuse of the system while attempting to switch out the language (Clojure and Scala are actually getting traction)
  • Perl, CPAN, and the cgi-bin internet. Leveraged sysadmin knowledge and code reuse. (This might be an example of best-is-best depending on your perspective)
  • Could also be interesting to look at how C++ supplanted C using the same worse-is-better tricks C used in the first place. (Cfront starting as a C preprocessor, choosing backwards compatibility over "the right thing")

Richard's follow-up essay Worse is Worse explicitly states a few points that I think are relevant to this discussion. ("within the context of the worse-is-better systems, these system were the right thing")

  • Being the default language of the system.
  • What sort of people use these systems? (Lisp is used by weirdos who do weirdo science, haskell "requires a computer science PhD")
  • Being affordable for the common person and the role of the host computer. PHP and shared hosting are deeply related to this in a modern way. Unstated here is the understanding that today's cheap shitty thing only taken seriously by amateurs is tomorrow's industry-standard platform.
  • Avoiding buggy complexity is the right thing. Go very strongly supports this point.
  • Winning by default ("there was never a head-to-head competition between a right-thing solution and a worse-is-better one") LAMP stack is relevant here, many people never knew another way to get code on the internet.

@cleichner
Copy link

The domain and codomain of "worse is better" are different. Sometimes worse is worse and sometimes better is better. Make a two-by-two.

@cleichner
Copy link

Unix and C are not disjoint from the worst is best languages. Diff and patch came from C and Unix, this is a package manager and code distribution tool. Email is the substrate.

@markmiro
Copy link

markmiro commented Jun 8, 2021

Some guesses and observations:

  • If you start build when you know everything, you're probably too late. I used Instagram and Snapchat early on and they're different apps now. They took a risk in building something on imperfect data and assumptions.
  • Leveraging existing knowledge of users.
  • Over-optimization for common usage patterns seen in early days, which makes building on top increasingly more difficult and makes it seem like the "worse" solution won.
  • Courage is in shorter supply than genius, which is why worse solutions tend to win.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants