Steve Yegge: Notes from the Mystery Machine Bus

So, in 2008, you made a comment (below, emphasis mine) about reader macros (yes, which I realize are not identical to macros; please understand that I use a couple reader macros in my day-to-day coding process and am not naive as to their implementation or function) that, at least to me, pretty strongly supports the narrative that Steve is painting: that the goal I somehow "have fewer features that people are less likely to use wrong as otherwise it gets confusing".

> I am unconvinced that reader macros are needed in Clojure at this time. They greatly reduce the readability of code that uses them (by people who otherwise know Clojure), encourage incompatible custom mini-languages and dialects (vs namespace-partitioned macros), and complicate loading and evaluation.

https://groups.google.com/forum/m/?fromgroups#!topic/clojure...

FWIW, this is the same argument that comes up often, from many different members of the community. The namespacing argument is commonly included and sounds technical, but is also trivially solvable; as in, was already solved in a comment during the primary-cited discussion of reader macros on the #clojure IRC channel, but was then dismissed due to the real reason: that reader macros make your code less understandable to other people who know Clojure (the exact same form of argument Steve is talking about, one layer removed).

I have never agreed more with a HN comment than this time.

This has to be the worst post by Yegge in terms of the negative impact it can have on software engineers and engineering.

He took a technical topic and labelled his belief system as "liberal" and the others as conservative. When some one proposes a technical approach he doesn't like, he can simply call him a "conservative-not that there is anything wrong with that".

Yegge is an average programmer at best. He wasn't able to maintain a simple 2D game and very easily blamed Java for it. It was a clear case of PEBKAC. It is absurd and unsurprising at the same time, that the simple act of blogging can some how elevate a programmer to expert status.

Yegge clearly has no idea what he is talking about. I am currently working with Scala which is apparently Hardcore conservative. Look at his characteristics of liberal languages.

1. Eval. - scala has a REPL, so u can do an eval if you wish.

2. Metaprogramming - scala macros

3. Dynamic scoping - No

4. all-errors-are-warnings - Meaningless bullet point, all languages encounter statements that it cannot meaningfully interpret. This statement just shows you Yegge's massive PL understanding deficit.

5. Reflection and dynamic invocation. RTTI - Scala has these.

6. The C preprocessor - Nope

7. Lisp macros - scala macros.

8. Domain-specific languages (for the most part). Optional parameters. Extensible syntax. Downcasting. Auto-casting. reinterpret_cast. Automatic stringification. Automatic type conversions across dissimilar types. - all yes for scala. Infact, you can provide your own casts for any 2 types and import/export casts as you wish.

9. Nil/null as an overloaded semantic value (empty list, empty string, value-not-present) - Yes and No, Option[T] is generic. If you want to know if any container(including strings) is empty, you say container.isEmpty(). But not container == null.

10. Debuggers. Yes Scala has debuggers. At this point one has to ask - what is this guy smoking. If your language has a debugger it is a liberal language? WTF??

11. Bit fields - No

12. Implicit conversion operators (e.g. Scala's implicits). Sixty-pass compilers. Whole-namespace imports. Thread-local variables. Value dispatch. Arity-based function overloading. Mixed-type collections. Yes, yes, yes for scala.

13. API compatibility modes. Advice and AOP. Convention in preference to explicit configuration. These are fairly vague properties and you could say yes/no.

I recently converted a "liberal" perl project into "conservative" scala and the code size fell by an order of magnitude, but apparently I live in alternate universe where "conservative" languages are somehow more succinct.

This guy is just suffering from verbal diarrhoea and he gets way too much attention for his uninformed commentary. I haven't seen a more bogus classification in ages, it is quite amazing how he politicized a purely technical topic.

It is fairly clear what his issue is

1. He likes dynamically typed languages. You have to type less and lower error checking is tolerated by the community.

2. He is uncomfortable with more advanced PL concepts, cannot decipher compiler error messages when working languages like Haskell. He would much rather let the program run and crash with a run time stack, where he can jump in and examine the value or operation that caused the failure. The Haskell compiler error message makes him feel stupid and he does not like it. This also probably explains why he wants to dump clojure into conservative territory, too much of STM and Parallel Haskellish stuff going on.

3. He is not a big fan of java/C++.

There is nothing peculiar about the set of biases he has, in fact it is fairly typical. People who favor Java/C++ simply need high performance code that would need to be maintained/refactored for a long time. It is not a religious choice but a pragmatic decision in the face of constraints. I have never seen "conservatives" write build scripts in C++ or "liberals" write OS kernels in Ruby.

All the attributes he has described simply cannot produce the ordering of languages that he has conjured. In the only barely technical portion of the post he has contradicted himself soundly, but it doesn't matter because no one is paying any attention to that.

When argumenting with other coders I lean on the architect side: do the things right, even if it means thinking and forecasting for two hours more. And it do not mean rigidity: sane architectures are those that allow a lot of flexibility, as much as you can run one any kind of road under any weather with a good 4x4, while a crappy car will break as soon as you leave the highway.

But I also advocate strongly for unit testing. Maybe it is because I write in Python for web and use unit test to run and prove the lines of code I write (I really hate going to the browser and re-clicking on the knob).

But still, I think you are a bit wrongish in your anti-TDD view. Say, check the first programming classes by Norvig in udacity. He should probably not be classified in the Cowboys, but his first step is writing the testing code.