
Where Yegge’s Wrong - pw
https://www.tbray.org/ongoing/When/201x/2018/03/26/Yegge-Being-Wrong
======
IBM
> Steve says An­droid is Google’s most im­por­tant chan­nel. That’s on­ly if
> you don’t mea­sure by mon­ey. From a busi­ness point of view, AdWords is
> five times more im­por­tant than any­thing else.

How is AdWords the channel? It seems like the product to me, while Google
Search is the vehicle for delivering them.

>My per­son­al opin­ion is that An­droid orig­i­nal­ly ex­ist­ed to pre­vent
Ap­ple get­ting a monopoly lock on the hand-held mar­ket and lock Google
en­tire­ly out of mo­bile ad­s.

Apple's business model doesn't lend itself to getting a monopoly lock on any
business they're in. Apple was always destined to having a nice chunk of the
premium market, but someone else would have sprung up to serve everyone else.
It could have been Symbian, Blackberry, Microsoft, etc.

~~~
mattnewton
I think it’s easy to look at it with hindsight and say that Apple’s
positioning was inevitable, but I certainly didn’t feel that way ten or even
five years ago. As is, google pays Apple already a lot of money to be the
default search engine on their phones. I imagine that number could have been
triple that if no credible rival emerged in the medium/high end phone space.

~~~
ocdtrekkie
There's about a 0% chance of a company that doesn't license or open up their
platform not having a credible rival, because by default, there's a huge open
market they're leaving on the table. This is the same with Tesla, and why
Tesla cannot be more than a niche member of the EV market in the long run.

If anything, the companies we _need_ to worry about are those who offer
extensible "open" platforms that build partnerships with most of the industry,
while retaining control and decisionmaking authority over them all.

~~~
mattnewton
What’s wrong with a possible universe where the iPhone is the only modern
smartphone, ubuntu/sailfish/Firefox rules the low end, and Tizen or something
is keeping one manufacturer alive in the medium end? There are very strong
network effects to an app ecosystem, and you can imagine a future where all
the high end users are on iOS.

~~~
ocdtrekkie
If Ubuntu and the like were successful with a strong ecosystem on the low end,
why wouldn't they find someone to build a high end device? Companies that
just... don't like profit, perhaps?

Android won it's success in the budget market, and that gave it the ecosystem
it needed to survive in the high end market.

~~~
mattnewton
The network effect is a chicken and egg problem that can’t be solved with just
finding a partner. A large part of why android succeeded because it solved the
chicken and egg developer - user problem by being early enough, and by having
a company like google put their full support behind it. Other platforms were
late to the table incompeting with iOS (windows), or didn’t have the clout of
a large competent software company backing it, or both.

~~~
esrauch
It seems that Windows phone would have filled the Android mid-range/licensed
niche if Android wasn't already established.

------
jeremiep
> And last time I looked, all the coolest, hippest, “thought-leader-ish”
> peo­ple I know are build­ing rad­i­cal JavaScript frame­work­s.

Is he being serious? I can't tell if its a joke or not.

~~~
hliyan
This is the man who wrote "Execution in the Kingdom of Nouns" ([http://steve-
yegge.blogspot.com/2006/03/execution-in-kingdom...](http://steve-
yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html)), one of my
all-time favorites.

Of course he's joking.

~~~
faitswulff
> And last time I looked, all the coolest, hippest, “thought-leader-ish”
> peo­ple I know are build­ing rad­i­cal JavaScript frame­work­s.

Tim Bray wrote this, not Steve Yegge.

------
pfarnsworth
Where Yegge is wrong is that he thinks somehow Grab has moral authority or
high ground over Uber. Once he finds out all the scummy things they and
everyone else has done in South East Asia, he might have second thoughts about
his holier-than-thou attitude.

~~~
jpatokal
Any pointers to "all the scummy things"? Or even some.

------
zachrose
> Steve cor­rect­ly notes that front-end pro­gram­ming is hard, but leaves out
> maybe the sin­gle most im­por­tant rea­son why: It’s super-hard to unit-test
> prop­er­ly.

Can anyone elaborate on this?

~~~
ender7
\- UI code spends most of its time interacting with a UI API (Android view
framework, whatever iOS uses, DOM/CSS in web). These APIs are enormous and are
rarely designed with testing in mind. Mocking or faking the pieces of API that
you need to interact with is frequently a daunting or impossible task.

\- Followup to the above: because so much of the "work" involved with UI code
involves interacting with another API, usage of that API tends to spread
itself through the entire codebase like cancer. You can create a careful
separation of concerns, but it takes a lot of upfront work, verbose
boilerplate code, and constant vigilance -- if you're just handed an existing
UI codebase you won't have that luxury.

\- UI code is highly stateful and highly mutable. A core skill in UI
programming is managing your app's enormous state profile. Single-path, whole-
world rendering techniques like React/other shadow DOM techniques really help
here.

\- UI is highly temporal. It needs to change over time. Testing anything to do
with time is an enormous headache. Animations can force you to temporarily
separate your underlying state from its representation, which is a testing
nightmare. But just in general, writing unit tests that involve time passing
is infuriating and fragile (even if you can control time passing via a mocked
clock object).

\- A lot of core functionality in UI involves different pieces handing off to
each other -- one window transitions to another window, etc. To test that
properly you need integration tests, but now your integration tests also need
to interact with the underlying OS/browser (because you can't separate any of
that stuff out). So your integration tests are in general way flakier than you
can get on UI-less systems that really only need to worry about faking out a
DB of some kind.

~~~
steadicat
Not to mention that UIs are visual, i.e. defining what is “correct” in terms a
computer can understand is very hard. There are dozens of criterias (colors,
spacing, borders, shadows, fonts, behavior, etc.), and often what is accetable
is fuzzy and sometimes even subjective.

Take spacing: if something moves 200px it's probably broken. But a couple
pixels off are usually fine. Unless those 2px are the vertical position of an
icon inside a button or two things that need to align. Where do you draw the
line? Humans are pretty good at spotting when things look off just by looking
at a screen. Computers, not so much (yet).

------
swyx
So it looks like Tim Bray is not refuting Yegge's central point: that Android
is vulnerable to "stealing" due to someone else (the RN community, which i
have to point out is much bigger than Facebook at this point) developing a
true xplatform alternative. Thats a very non obvious conclusion and I went
from total ignorance to completely agreeing with it in the span of one post.
Do people actually agree that Android is that vulnerable?

and what -is- the deal with Flutter? Is it Dart 2.0?

~~~
on_and_off
FWWIW, the article was discussed a bit in the Android slack I hang around, and
quickly dismissed.

The consensus is that there are always big downsides to cross platform
solutions and that it is not going to change anytime soon. They have their
niche, but currently have zero chances to replace native.

Flutter is a runtime for Android and iOS powering apps written in Dart.
Flutter itself is written in c++ and Dart.

The main originality is that it uses it's own runtime instead of using the
platform widgets. It is not as original as its creators would like you to
believe though since that's basically what all the cross platform toolkit
running in a webview has been doing. The difference is that performances are
not atrocious with flutter but they still fall short of being any better than
native apps.

Flutter could be a big deal if/when Fuchsia becomes a thing it is adopted as
its main app runtime. And by 'become a thing' I mean that it completely
replaces Android.

You would get native dev on 'android z+' and high quality iOS ports very
easily.

------
coldtea
> _Steve cor­rect­ly notes that front-end pro­gram­ming is hard, but leaves
> out maybe the sin­gle most im­por­tant rea­son why: It’s super-hard to unit-
> test prop­er­ly_

Yeah, no, that's hardly the reason.

Besides, it's wrong. It might be harder to functional or integration test
properly, but unit-testing front-end code properly is not an issue.

~~~
discodave
100% agree on functional/integ/end to end testing being harder for fronentd.
On the other hand, nobody seems to unit-test Javascript where I am. Maybe
they're just silly, or maybe it's harder, maybe it's just a lack of tooling.

As an aside, it is actually _more_ important to unit test lest "safe"
languages. E.g. Java ensures you're passing correct types around at compile
time. But with JS/Python et al. you need to unit test to check that you're
passing, say a String rather than a tomato.

~~~
reggieband
>nobody seems to unit-test Javascript where I am

That is an engineering culture thing. I work on a small JS project (node.js
server + React FE) that has >95% unit test code coverage. It isn't even
difficult to do - it is just not a major part of a lot of front-end teams
culture.

------
commandlinefan
> I think a whole lot of pro­gram­mers would rather work in high-level
> lan­guages like Ru­by and Python

That doesn't mean that C++ programmers aren't looking down on those people,
though.

------
ttul
“Snoot Mountain”

I want a picture of this.

------
draw_down
It's not like I disagree, but the first point is the same god damn pedantic
point that gets hit over and over again, that Google's customers are
advertisers rather than users. We get it already, and it ignores Yegge's
actual point to say the same thing we've heard a million times before.

If I never have to read "Unless you're paying, you're not the customer you're
the product" again, that shit will be too soon. If they don't make something
that people actually want to use, there will be no audience for advertisers.
Come on.

Lastly, I thought it was funny that both Yegge and Bray can agree to take
shots at JavaScript. There's another thing you'd think nerds would get tired
of already.

~~~
zeveb
> Lastly, I thought it was funny that both Yegge and Bray can agree to take
> shots at JavaScript. There's another thing you'd think nerds would get tired
> of already.

Why? JavaScript is really, truly, awfully horrible. It's a local maximum which
could easily be escaped with just a very little bit of effort, and the fact
that no-one has done so is one of the strongest-possible condemnations of our
industry. JavaScript is a shame, an embarrassment and a squandered
opportunity. When one thinks that we could have had Scheme, and instead thanks
to a benighted Netscape executive we're stuck with JavaScript forever — it is
to weep.

~~~
deckard1
Eventually WebAssembly will allow you to use whatever language you want.

> When one thinks that we could have had Scheme

This may have been true 5 years ago. I'm probably the biggest Scheme fan there
is. I've created assemblers, compilers, and even started an OS in Scheme. I've
been using Scheme since the late '90s.

Modern ES6 and beyond JavaScript is quite nice. I really don't miss Scheme at
all. Scheme, mind you, was incredibly limited in R4RS and R5RS, around the
time Netscape would have adopted it anyway. It didn't even have a module
system, much like old JavaScript. We would be stuck with the largest problem
still facing JS: multiple sucky module systems requiring a webpack-like
monstrosity.

~~~
anothergoogler
Single-threaded in a multicore world is nice? Implicit type coercion on par
with PHP is nice? Implicit var args are nice??? (That's the worst part by
far). I would choose pretty much any non-shell mainstream programming language
over JavaScript for a program with results I care about (that is, a useful
program). Throwing a bag of syntactic sugar (ES6) on a rotten language is
meaningless.

~~~
kybernetikos
> Single-threaded in a multicore world is nice?

Javascripts approach to threading - default single threaded event loop, but
with message passing to communicate with other threads is actually a pretty
good model for people who want to write multi-threaded code that doesn't
break. This is important when coding for a very open platform like the web.
Confusion about what is running on the UI thread and what isn't and how to
communicate between them is the kind of error that pops up in java ui code. I
wouldn't want that for the web.

Besides, the threading approach is more about the runtime rather than the
language. There are lots of clustering and threading libraries on npm if you
want them for your server-side code, and you have WebWorkers in the browser.

Sure, the implicit type coercion (pretty much everyone hates this) and var
args (hasnt bothered me as much as it seems to have bothered you) were not
good choices, although compare it to other languages of the time - first class
functions were by no means universally available and now almost every modern
language has them. A literal notation for maps in the language was a great
decision too. Prototype inheritance may be a little weird but it is elegant,
more general and radically simpler than class based inheritance.

Javascript certainly has its warts but I find it fairly productive to code in.
Plus it's paired with a runtime that has seen a shocking level of genius
engineering over the last 10 years. The speed of iteration is unparalleled.
The reach of a deployed piece of code is unique and likely to remain so for
the foreseeable future. There aren't many other platforms that have developer
tools for inspecting a running system, visualizing ui, network and detailed
render performance that are as good.

~~~
anothergoogler
> Javascripts approach to threading - default single threaded event loop, but
> with message passing to communicate with other threads is actually a pretty
> good model for people who want to write multi-threaded code that doesn't
> break.

This is simply wrong. The "approach" to threading is that there is none. It's
single-threaded. You cannot write multi-threaded code directly in JS. On the
server side, this can lead to things like a naive fetch after cache miss
denying service to your web application. Nothing on the queue can run until
the current function call finishes. Even lovely Python doesn't have this issue
because, while the GIL is a PITA, Python has real threads, and can switch
during a function call.

To be clear, I'm not talking about web browser programming, where JS for some
time has been the only option. I'm talking about the ridiculousness of server-
side JS when we know clock speeds are hitting a wall and that parallelism is
the only way to squeeze out more performance. Steele, Armstrong et. al. have
lectured at length on this topic.

> There are lots of clustering and threading libraries on npm

No, there aren't. Running several node processes via PM2 is not threading.
_You cannot use multiple cores directly from the same Node program unless you
drop down to C++_.

You can vaguely do it in the browser, but the limitations on communications
between the main thread and web workers, especially with SharedArrayBuffer
being off-limits post-Spectre, are pretty much non-starters. It's a nice
option to have for specific cases (games programmers take advantage of web
workers to read models without blocking the main thread, for instance), but
it's only bolted onto web browsers.

~~~
kybernetikos
> You cannot use multiple cores directly from the same Node program unless you
> drop down to C++.

Well, someone has to drop down to C++, but it doesn't have to be me (node
webworker-threads). This is the same as in most languages.

> you cannot use multiple cores directly from the same Node program unless you
> drop down to C++.

As I said in my comment, _threading is primarily a runtime thing, not a
language thing_. There are javascript runtimes (napa.js, node webworker-
threads, nexusjs, browsers) that have threading (even by your restrictive
definition that doesn't include threads layered onto child processes like the
npm package 'threads' does), just as there are runtimes for e.g. java that do
not (and the bulk of the threading support in most other language runtimes is
also written in C++ so it seems churlish of you to complain about that in
javascript runtimes). Most languages do not need significant changes to their
syntax or keywords to support multithreading.

Maybe you're comparing node.js specifically (where I think that for a long
time there was a belief among the leads that letting the OS manage processes
was a better approach - it's been interesting to watch this same argument play
out in the rust community) with something like Go which has pleasant
primitives for concurrency built in as part of the language. If you are, then
to some extent I agree with you - something like goroutines might be really
nice in javascript and is arguably better than what the js community has, but
I also stand by my runtime/language distinction. Goroutines are not OS
threads. You can run go programs with GOMAXPROCS set to 1 without changing the
_language_ at all.

