Aiming For Mediocrity

(This page would greatly benefit from some context. What originated this discussion? What does Haskell have to do with Aiming For Mediocrity?)

[This discussion originated on someone's homepage. The only thing preceding it was me asking a question that never got answered and having to reword it below. Haskell enters into the picture because it is, presumably, non-mediocre. The same goes for Slate and Smalltalk. What is mediocre is wanting to reimplement them for the hell of it.]

[Names of the guilty were stripped in the following, so that DaveVoorhis couldn't accuse me of being impolite or whatever. Also eliminated some utterly pointless judgements about Slate and Smalltalk seeing as they're now off-topic for this page. It doesn't help that they're made by someone who admits he knows almost nothing about either Slate or Smalltalk ... and it shows. -- RK]

You say that you're trying to be a language designer. All right, so what do you want to learn from the experience? What features and concepts do you want in the language? Why isn't Smalltalk good enough? Why isn't Haskell good enough? What about Self or Slate? What about whatever successors to Haskell there are in the research pipeline? What do you want to accomplish? -- RK

Well, first of all I want to learn something from it. That's enough. Even if it is "I can't do this". I applied the same reasoning when I delved into Linux kernel programming and ProgrammableLogic? and it has served me well. What I'm hoping to learn varies from advanced syntax (TwoLevelGrammars? and such) and denotational semantics to compiler design and optimisation. I hope that my language can serve as a vehicle for all this.

Why I think Smalltalk, Haskell, Self and Slate aren't good enough? Well, for one I don't really like the look of the Smalltalk variants. I basically grew up with C and am really fond of the free-form braces style. Note that at least Smalltalk is also a commercial product. Regarding Haskell: I don't really like the programming style of functional languages (although they are very interesting from a design viewpoint).

Additionally, I guess there's something of a NotInventedHere attitude involved.

I'm interested in trying to integrate OperatorOverloading and UserOperatorDefinition? into the language, as well as MultiMethods, CompileTimeExecution? (a'la ForthLanguage) and possibly CoRoutines. It should, of course, feature ObjectOrientation support, preferably beyond what languages like C++ and Java support.

Lastly, I hope to design a language I really like using, and maybe other people like using too. However, I'm not into this to become famous or anything.

So ... you want to reinvent Slate with a couple minor features added.

As for Smalltalk syntax, I suggest you simply suck it up and learn to like it, which is something that will almost inevitably happen if you actually use Smalltalk for any length of time.

I looked at Slate for a bit, and it's really not the direction into which I want to go. Just for fun, I've thrown together a brainfuck interpreter in what is currently defined as my (as of yet unnamed) language: 

    [ Example removed because it only detracts from the discussion here ]
As you can see, the big ideas here are: CompileTimeExecution? ("main" is just a variable, to which a function is assigned; after the toplevel code is evaluated, code is to be generated from the declared functions), UserOperatorDefinition? and the notion that types are expressions too (hence the slightly odd syntax for declaring arrays).

By the way, don't let this simple example fool you, CompileTimeExecution? is not just a gimmick. Suppose you have an XML file describing a the layout of a certain dataset. Using CompileTimeExecution? you can simply generate a class hierarchy based on this with zero runtime overhead.

I am currently unaware of any compiled language other than ForthLanguage (and some members of the LispLanguage-family) featuring compile-time execution. If you do, please tell, I'm very interested.

Besides, what's wrong with "reinventing Slate with a couple minor features added"? Maybe I really value those "minor features".

What is it about the general Slate approach that you don't like? Couldn't you add compile time execution to a Slate compiler? And to answer your question with another question, what's wrong with reinventing the wheel?

No, you can't just add compile-time execution to a language that doesn't have it. It looks ugly, doesn't fit in. The only way to do that cleanly would be to make the top-level execution environment the same as the level of a function. That is, any statement (or expression) that can be placed in a function must be possible to be placed top-level (with the possible exception of the return statement). My knowledge of languages from the Smalltalk-family is not very extensive, but from what I know this is not possible.

"what's wrong with reinventing the wheel?" Nothing. The fluid dynamics of air blowing by (and through) a wheel can be surprisingly complicated and may require reinvention (talk to any racing-bicycle designer for more information). And I'm not even going to start about racing tyres. Just as the interaction between programmer and programming language is surprisingly complicated and may require language reinvention (as one cannot (easily) reinvent programmers).

What does "top level execution environment" mean if it doesn't mean the environment the compiler uses in, say, an empty workspace?

Well.. bit difficult to describe for me (and English not being my first language). It's basically where you put your lines of code. If you can only place "a := foo()" inside a function, then you can't cleanly add compile-time execution.

For example, you can do this in LispLanguages, TclLanguage and ForthLanguage (where it has indeed been done) but not in CeeLanguage (because it doesn't allow the above construct outside of functions).

Yeah, that's what I figured. But there is no analogue to "outside a function" in Smalltalk. There's no such thing as a source file in Smalltalk in the same sense as the term is construed in other languages. The most bare environment you can dream up is inside of a bare or new workspace, one unaugmented by local variables. And inside of a bare workspace, you can evaluate any kind of expression that you could inside of a method. When you do this, the editor wraps your text inside of an anonymous method and compiles that method. So by your explanation, Smalltalks have the property you deny they have. If you're going to claim that Smalltalks can't have clean compile time execution because "placing" code outside of functions is lexically impossible, then clean compile time execution is a very uninteresting property.

I never claimed I knew smalltalk well. Please read what I've written above before accusing me of all sorts of heinous acts.

You claimed to know it well enough to judge, albeit implicitly. And you made it very clear that you believed Slate couldn't have compile time execution added to it in a clean manner. A conclusion I doubt since Slate will no doubt go the Smalltalk route of workspaces and browsers, as opposed to source files. You still haven't explained what it is about Slate's approach that you don't like.

Look, I'm all for tackling massively ambitious projects long before you've got any experience in the field. I mean, look at me, I've started a dozen such projects. And I'm all for nuking everything that came before and starting from scratch, using a fresh mind uncorrupted by obsolete constraints and past failures.

But I do not support reinventing the wheel for the sake of reinventing the wheel. Every one of the projects I started has goals and objectives that are, at least, very different from everything that came before and radically different from anything else currently being developed. If you can't express how your objectives are different from other projects' objectives, the merits of your project fall into question.

I find this idea that every project must have a merit intriguing. I usually embark on projects because I find them interesting and think I can learn something from them. Isn't that enough? Admittedly, this does mean that I occasionally reinvent the wheel, but it'll be my wheel and I'll totally understand its properties and limitations. I'm still young and figure the only way to learn stuff thoroughly is just to do it.

Or so you think. In any case, it is an exceedingly inefficient way to learn. It also leads to specialism, a disease of modern society which is all too common nowadays. And then there's the value of learning something genuinely new versus relearning what everyone else knows. If you valued something being yours, one would think you'd work on an original creation and not a reproduction of someone else's.

Your justifications seem exceedingly thin. Personally, I think you're just risk-averse to a pathological extreme. You don't want to try doing something if there's a chance you might fail, if there's a chance it's not even possible for you to succeed, you want to know ahead of time that success is assured.

And I think this is driven by a severe lack of confidence in your capabilities. You don't think you can do something new so you won't bother trying. You also don't think you can do anything of societal or practical value; your little ploy that "not every project needs to" is so very transparent. The only questions left in my mind is whether this is a general attitude of yours or just one reserved for programming languages as compensation for more risk-taking in other fields.

I believe programming language design is at a critical threshold. There is a critical number of designers working on it, so it is just barely chugging along. And if you count only the language designers working to advance the field, who are many times fewer in number, then it is subcritical. An example of an extremely subcritical field is operating systems design, which is a dead field. So in the case of programming language design, the field can't afford to waste talent on mediocre projects. -- RK

I had that same attitude about a year ago. Everything I made had to be prefect. Flawlessly designed, state of the art algorithms and ideas (I was doing OS-design at the time). That worked really paralysing. And slowly you realise that it just doesn't work that way. You can't make perfect stuff until you can make crap. You have to make the important mistakes first (and learn from those).

Going from one pathological extreme to the opposite pathological extreme is not healthy. Some people, and most societies, unconsciously go through such stages as a way to mitigate the excesses of the past. But conscious people should know better. Conscious people should know that the solution to principles that don't work is not to compromise the principles but to get a better set of principles entirely. If the pursuit of perfection didn't work then the pursuit of mediocrity won't work either. Something entirely different will, and you're just wasting your time until you realize that.

The problem with OS design isn't the attempt at perfection. The problem is that OSes are tools without a market. You can build one, but you'll never use it so there's no point to doing so. So the problem with implementing an OS design, or even in finishing the design, is one of motivation. The same problem exists for programming languages but to a lesser extent. In the case of a mediocre language, the problem is multiplied. If you don't plan to use the language for anything or you don't know what its features are going to be used for, you'll never get motivated enough to finish it. -- RK

My point was that you have to know how to make bad stuff before you can make really good stuff. You have to know what differentiates your worst from your best. This is usually not what you think. For me, I find that it's not code quality per se that differentiates my best and my worst, but clarity. So, in order to write even better code, I go for clarity above all else.

If you don't know what it is that makes a design bad, you're simply going to hit the upper limit of your preconceptions (likely sooner than later).

-- WouterCoene (almost ashamed the above makes him sound like a buddhist monk more than twice his age)

This has nothing to do with ambition or mediocrity. Nothing you say in the above is even remotely relevant. You write as if you were justifying or explaining a decision to aim for mediocrity but in reality you are explaining nothing at all. Come to think of it, the ability to sound like you're saying something without saying anything at all, is very much the hallmark of Buddhism. Not that I'd ever pride myself on it. -- RK

Personally I think all modern languages are bad, and that the next paradigm lies nearest to CollectionOrientedProgramming and OcamlLanguage, though those have some flaws which must be addressed.

I think a more worthy discussion would be to take a small business app example with a diverse set of requirements and ask people what code in their 'dream language' would look like to implement it. The code would describe a small GUI, some IO+Data, some mapping/formatting, some math/statistics, events, some manipulation of strings/lists/collections/etc, and maybe some rules/roles/HOFs. Basically a small amount of a lot of things. We could compare the elegance/utility of our dream language. This isn't pseudocode, it must be directly compilable in our dream compiler.

What does this have to do with the topic of this page?

AAAAARRRRRGGGHHH!!!!

Richard, why is it that discussions with you so often turn into some weirdass suckhole of despair, where nobody ever agrees on anything, nobody ever learns anything, and everyone comes away feeling vaguely insulted, ashamed, slightly pissed-off, and guilty for ever having stepped in it? This whole page has become an unsettlingly weird quibble over something that was so obviously good that I'm quite disgusted with you for even arguing about it.

But, alas, I forge ahead once again, in some slim hope that... I don't know what. On we go, anyway:

Instead of talking about language design, let's talk about being a clocksmith. Let's assume that the original intent was not to implement a language as part of learning language design, but to become a clock designer. How would our budding clocksmith learn his art?

First, he'd probably take a lot of clocks apart and study how they work. He'd learn clock theory and practice until he knows existing clocks inside and out. He'd discover how to disassemble clocks, repair clocks, and put them back together. That's Stage I.

Then he'd move on to building new clocks. That's Stage II. He'd do so by studying the construction of existing clocks, and emulating their design and manufacture in the smallest detail. He would learn, at a fundamental and visceral level, all the lessons that his predecessors had learned about designing and building clocks. If he were an apprentice to a master clockmaker, he would probably be producing clocks following his master's design.

Then, and only then, having fully learned clock theory and practice in terms of existing clockworks, would he reach Stage III. He'd start creating his own original clock designs. He would do so fully armed with a complete understanding of all that had gone before in clockmaking practice, so that he could learn from, and leverage, past progress without needing to blindly repeat the mistakes of his ancestors. His designs would confidently and imaginatively deviate from past practice, based on a mature understanding of all the past mistakes, past successes, and limits and benefits of current practice. In short, he would become a master craftsman, an expert in his field, with not only the creativity to carry the field in new directions, but the fundamental knowledge to base those new directions on comprehensive understanding rather than pure whim.

Our language designer, by his own admission, is at Stage II. He's studying the construction of existing languages and making his own refinements. That is a bad thing? Obviously not! It is a fundamental component of learning a complex craft. He might even make significant discoveries or innovations there.

If you genuinely wish to argue that his approach is a bad thing, and that it somehow leads to mediocrity, then you are either (a) quibbling needlessly because your ego can't lose face by saying, "Oops, sorry, I didn't quite get it the first time;" or (b) your thought processes are so profoundly different from mine (and the language designer in question, I would guess, given his strong and articulate arguments) that there is no chance of achieving anything like concensus, understanding, or even useful knowledge from this whole vaguely unpleasant page.

-- DaveVoorhis

I don't know about you but I learned quite a lot. I learned that programming, and the programmer community, has completely fucked up values by the standards of a creative field. I learned that plagiarism, which is everywhere considered a bad thing, is somehow considered acceptable by programmers. You may consider it an "obviously good thing" but that's your problem, not mine.

Oh, and I don't accept your clockmaker example. Not least because it's engineering. And get this Dave, DESIGN has jack squat to do with ENGINEERING. There may be room for good little engineers to do their tearing apart, learn by example and learn by doing shit, but that place isn't in language design.

As a designer, I think that my word on matters of design counts for about 1000x yours. And even if it didn't, I only have to point to the fact that 'learn by doing' in design requires designing, which by definition means creating something NEW and NOT PLAGIARIZING.

You've reached a new low Dave. I was able to craft a reply that sweeps away your position without needing to glance at even 1 word in 5 of your argument, of 6 paragraphs I read maybe 3 sentences. Your position is that flawed. I'll spare you my reading more of your argument (that a budding designer should ruin any talent they have by learning engineering) since it only serves to piss me off.

You might like to think about the fact that what is "obviously good" to an engineer is "obviously evil, loathesome and contemptuous" to a designer, and that all you've done is greatly annoy this designer by trumpeting your uninformed opinion on a matter of design. -- RK

First: In these things, you seem to persist in sharing your feelings, like, telling us that "all [Dave has] done is greatly annoy [Richard]..." Might I remind you that no one cares whether you're annoyed or not? Might I remind you as well that your self-described avocation (somehow I seriously doubt it's your vocation) of "designer" is highly questionable, and that your contributions generally convey the impression that you're a designer only in your own imagination -- of the same useless, whinging ilk as the thousands of would-be "Game Designers" who haunt their mother's basements playing Everquest day and night, and vainly dream that they too could be a great game designer, if only some enlightened company would hire them to play Everquest day and night.

Second: Bah! How do you know my position is flawed if you haven't read it? Even though my clockmaker example is in fact a superbly apt analogy, I believe you actually do think that clockmaking is all about engineering and nothing about design. Of course, as a collector of clocks I know that's ridiculous, but we could quibble about this all day and get nowhere. The same holds for your definition of plagiarism. I think you're barking mad on that one, but you probably think the same of me.

Therefore, I open this up to public vote:

If Dave is right and Richard is wrong, add an X to the line below: 

 * X
If Richard is right and Dave is wrong, add an X to the line below: 
 *
If both of you should STFU and stop polluting Wiki with your silly quibbles, add an X to the line below: 
 *
I shall count the 'X's tomorrow at 6:00pm GMT, and that shall decide who is right and wrong on this matter. I'll be keeping an eye on RecentChanges, so merely plunking in a line of Xs won't work.

Ridiculous, you say, to rely on ad populum to settle an argument? Of course, but unless you've got something better than the "did, didn't, did, didn't" sort of tirade this will otherwise turn into, I see no alternative.

So there. --DV

Yeah, great, a poll made in an exceedingly biased population comprised >>99% of people who don't even know what the the subject is about but are prejudiced against it by the pseudo-anti-elitist "programmers are designers too" claptrap that routinely makes its way around here. How about you just STFU about a subject you know fuck all about? The only people here who I'm confident even know what design is are DM and DF. Everyone else's votes on design are about as relevant as their votes on general relativity.

I have no idea why programmers insist on weighing in on matters of design. It's not like I weigh in on whether projects should use Smalltalk or Java; the fact that Java is ugly and shouldn't even exist is a completely different issue. And I don't even bother stating my preferences on programming methodologies since a designer's opinion is worth less than a programmer's and would be less representative of programmers' consensus. But do programmers return the favour? No. Instead, I get some loudmouthed know-nothing asshole that insists he knows better than an expert in the field.

You claimed I was disrespectful or whatever shit? Here's a clue Dave, the very first time you opened your mouth on this subject, you were supremely disrespectful. And I put up with it but there are goddamned limits to my patience. -- RK

Again, you are sharing irrelevant feelings. I have no interest in the limits to your patience.

You aren't a designer. You might call yourself a designer, but you've never designed anything. All I see are frequently rude, often strange rants about something you call design, but which are usually more about anti-programmer sentiment than design. These aren't designs. You're like someone who claims to be a furniture designer despite having never produced a sketch or a blueprint, or having had a chair made from his "designs," yet he bitterly complains that chair manufacturers, and the real designers who design real chairs, are evil and incompetent. Would you call such a person a Designer?

You know what design is? TheThirdManifesto is design. It's a design for a RelationalLanguage. It has been published in two editions. The first edition, which I have beside me, runs for 496 pages. Yet, there are many aspects of the design that could benefit from more detail, and so I am fortunate to be in regular contact with one of the authors, so that I can ask him about the details. If I take that into account, the design documents could probably run for a thousand pages. That is a design.

So what have you designed? Can we see your design documents? Can we see your prototypes? Can we see the software produced from your designs? If we can't, then you're not a designer. You might become a designer, but right now you are a dreamer. Until at least one of your so-called designs has turned into some structured manifestation -- beyond your rants here and that strange gleam in your eye -- your views are going to be treated with disrespect because you've done nothing to earn respect. Let me repeat that: You've done nothing to earn respect, so don't expect any. At this point, if people even treat you with politeness you should consider that a bonus. However, if you actually produced some designs instead of rants -- especially against folks who want to learn something, like the fellow whose comments led to the creation of this page -- so that us programmers might say, "Mmmm, nice design. I think I'll go code that," then things would be different. -- DV

I'm sorry to disappoint DaveVoorhis but such polling approaches never worked, nomatter how legitimate was the reson to start. Not the least because even if the resolution should be obvious there's really no motivation for people to participate. And even if they did participate the outcome would be of no consequence anyways, especially because it's not an obvious political issue or settling a factual matter of false versus true but rather "right versus wrong" and degrees of interpretation. As for "design" issues, I'll believe RK is a designer when I'll have seen his first original creation, but not a moment sooner, and I don't know of any contributor on this wiki who takes seriously RK's claim to be a designer. Also voting on obvious issues is a sign that trolls are winning.

Just think about it: RK cannot win support for these idea by simply implementing -- not even by prototyping them, because he just can't, so the more disturbance he produces with trolls like ProgrammersAreNotProfessionals, WhatIsStateOfTheArt?, etc, etc the more he is rewarded with exposure and the more he creates the impression that he is "somebody" of importance on a wiki dedicated to practitioners of programming. That certainly amounts for something that's better than nothing, maybe a chance that he will find a naive programmer to look at him as design guru and implement something, or maybe a chance to be hired -- although far fetched it's certainly more than what he'd compete more honestly in the marketplace of ideas.

Situations such as this make very good cases for discussing WikiChangeProposal. And how to deal with it, so I'll take the discussion to WcpUseCases, if you're willing to join. Richard is invited as well, especially given his claim to expertise in InteractionDesign. --CostinCozianu

Costin, in case you aren't trolling, there are a few people on this wiki that "take seriously my claims to being a designer" and it should be obvious who they are. As for your opinion of me as a designer, until you show some evidence that you understand what design is, at least enough to intelligently comment on a design issue, then I really couldn't care less about it. But hey, you're still up on Dave since you haven't completely shot yourself in the foot yet. I thank you for your invitation but I'll have to decline, citing lack of time and a competing interest (I already have a design in mind). Lastly, your opinion of me as a programmer is factually wrong but not worth any effort fighting. -- RK

Richard, your intelligence should tell you better than to assume you can put me in some kind of competition with David for your graces. I sincerely do not know who takes your designer claims seriously (if its DM or DF, can it be that you misread too much into their polite curiosity ?). Until I'll find an explicit declaration to that effect I remain healthily skeptical on this matter. It is true, that I cannot with absolute certainty rule out that you might be a good or gifted programmer or that your ideas on design should deserve a better fate than having such a poor advocate. But in the same time, given that we operate in a world of partial information and uncertainty any objective reading would have to assign to that case a probability that is small enough (and I'm not even saying negligeable) as to be uninteresting (for no other reason than LifeIsTooShort?). So, as you can see, you have nothing to fight over with speculative arguments. It's either that you prove your value or you don't. And the more "stuff" you type on wiki, the less your value is proven.

Oh, you can rule out that I'm a good or gifted programmer with absolute certainty, I've said as much myself. I'm a pretty mediocre programmer but I don't think I'm completely incompetent as you implied earlier. I pretty much agree with everything else you say here. -- RK

OctoberZeroFive

CategoryMotivation

EditText of this page (last edited June 2, 2008) or FindPage with title or text search