We need less powerful languages - <AUTHOR> http://lukeplant.me.uk/blog/posts/less-powerful-languages/ <comment><USER2> Yeah, that's what we need for writing the same bored boilerplate CRUD all over again, though note that those less powerful languages end up being so painful to use that we eventually end up machine-generating most of the code (see: Java, HTML, CSS).

Sometimes we also need languages for exploratory work...

But anyway:

> _In my years of software development, I 've found that clients and users > often ask for "free text" fields. A free text field is maximally powerfully > as far as the end user is concerned — they can put whatever they like in. In > this sense, this is the "most useful" field — you can use it for anything._

> _But precisely because of this, it is also the least useful, because it is > the least structured. (...) The longer I do software development involving > databases, the more I want to tightly constrain everything as much as > possible._

And that's _precisely_ why they want that free-form text field. That's why people still use Excel instead of whatever database solution their IT department bought/prepared - because it doesn't limit them to particular poorly understood interpretation of their workflow that was outdated last week. Real world changes, requirements of the job change, and there's nothing more annoying than be stopped dead in tracks because some smartass from IT thought that this particular field should always be a number...

Use text fields unless you're absolutely, positively sure the constraints you want to impose are valid and will never change.

<comment><USER3> Free-form text input may be preferred by users, but possibly a nightmare for the developer. As an example, I've been assisting a small non-profit arts organization, constructing a database system to keep track of artists' work, etc.

In the past there was essentially no ordered data-keeping. For several years certain bits of info had been entered into a spreadsheet, like name, title of art work, date created, medium, email addresses and so on.

Data in that spreadsheet was a total mess. Most fields were "free-form" text, with no consistency at all in format of dates, email, URLs, crucial fields left empty, data put in wrong fields, etc. It was a lot of work to clean it up and quite clearly showed what motivates programmers to be "controlling".

To be sure, excessive rigidity can be problematic, but it's hard to make clear to users the importance of maintaining data integrity. Frequently enough, users complain about constraints despite effort to demonstrate their necessity and benefits.

Of course constraints evolve, which is often the challenging component of creating and growing a system. If there's good reason to modify things, because what we conceived of as a number turns out otherwise, then we must indeed find a way to accommodate that reality. OTOH if it really is a number and the user wants it different, we leave it as is and once again patiently try to show the user our reasons.

Finding the right balance between user "freedom" and necessary limitations on data input is hard to achieve. I suppose the right approach has something to do with avoiding the illusion that data system development is actually ever done.

<comment><USER4> This isn't always about data integrity.

I'm an American, but I live in the UK: My _home address_ is in the UK, but I live in a flat and my neighbours are mail stealing cunts so I use a scan+email service for my _mailing address_ which is based in the US.

Similarly, my _land line_ is a UK number, but my _mobile_ is a US number, and when you refuse to let me type in a `+` sign I spend a lot of energy guessing whether to give you a number in NANP or in international formats.

The thing is, capturing information is just that: capture. By doing the traditional programmer thing of validating the field on input, you're pissing me off as a potential consumer. I _guarantee_ that I know more about where I live than you do, so I'm more likely to abort my transaction if you tell me that my address is invalid. That means your non-profit arts association simply doesn't get my donation.

Thing is, I actually accept that my situation is exceptional and not the rule, so I think this is really about programmers being unable to deal with exceptions; treating them as nothing more than dynamic escapes or nonlocal goto, like there's only a choice of more complexity, or more rigidity.

This is nonsense.

Simply capture whatever the user types. That means all input fields are plain text or blobs or whatever. You can try to validate it into your business model when you have some business need: like mailings, or shipping, and then attempt to extract and validate _the specific fields_ when applying the mapping. If you have an array of failures, you can allow the user to review at that point.

I do this with two tables: An input table, and a data table. The input table has forward pointers to the data that is extracted, and the data table has backwards pointers to the inputs. The data tables might be used for business logic like mailings, order processing, login management, or shipping things.

Shipping is a particularly good example: I want to maintain four shipping providers since they offer different rates. This allows me to offer "free shipping" by simply selecting the cheapest provider and pushing that cost into the product. To do this I need to know their shipping zip code for the US, or the shipping country for international _that 's it_. I don't need anything else, and three patterns (/(\d{5})(?:-\d{4})/, /\b([A-Z]{2}$)/m, and maybe a list of common countries) should be enough to extract from most orders. Anything else I can punt to my fulfilment center who can either call the potential customer, delete as spam, or manually extract.

Or maybe I just ship everything UPS: I send it off to label making, and the 0.003% that fail I have to hand-check anyway (after all, are we verifying the city names as well?)

What am I doing with these URLs? Am I visiting them? Am I verifying someone has placed some widget on there? Or am I putting a link next to their name on a bulletin board? Verification means different things depending on the use case.

Missing that crucial email address field? Or maybe there's an extra space on it? What exactly am I doing emailing them? What if the email bounces? What if it gets marked as spam? Verification of an email address has less to do with the characters in it than it has to do with the use-case: If this is for an account recovery, I want to know you can email me and will work with your system to do that.

This approach also means I don't need to "edit" things either, because edits are simply new inputs. Logging is free. Users are happy.

The point is it's not a balance; avoiding the illusion is easier than you think and the hardest parts of the problem of data validity are problems you have to solve anyway.

<comment><USER5>
      My home address is in the UK, but I live in a flat and my neighbours are mail stealing...

Are you sure it's your neighbors? We get mail theft here (in Silicon Valley) all the time; thieves harvesting mail for valuables, credit cards, tax data, etc. for ID theft.

In my city, police will _not respond even if there is theft in progress_ and they have idle units at Starbucks next door, claiming that there is no state law against mail theft -- it's up to the USPS to deal with it.

I have a PO Box for everything but junk mail. The much-maligned USPS has a really nice feature nowadays: you can sign a (free) agreement allowing them to accept packages on your behalf from other carriers... so I have FedEx, UPS, etc. all going to my PO Box, using the street-address format for the Post Office proper. It's much less expensive than private services like the UPS Store and such.

Your neighbors are probably more focused on stealing your newspaper. Or spouse.

<comment><USER4> The USPS operate their own police force[1] because federal laws are handled by the federal government.

[1]: [https://postalinspectors.uspis.gov/](https://postalinspectors.uspis.gov/)

</comment></comment></comment></comment></comment><comment><USER6> It seems to me that the author is attacking the wrong problem axes. I don't think expressiveness or power are the problem here. I think the problem is lack of clarity.

Consider the discussion of terseness. What is the best way to explain something in Englush? Long winded or terse? Wrong axis. Explain things _clearly_. Expressing a concept perfectly with a small number of words the listener doesn't understand is useless. Beating a dead horse is useless.

I have a huge problem with C because the same characters and keywords are reused in multiple different similar but different ways and it adds cognitive load to things that should be simple (eg declarations) -- leaving me less able to devote my limited mental faculties to the problem I am actually trying to solve. (Not singling out C, just picking a well known example.)

Languages that give you lots of redundant ways of doing things -- especially if some ways are better than others but not obviously so -- aren't more powerful, they simply harder to understand. (This is not the same as arguing for newspeak — words that are similar but not the same are useful.)

What we want is clarity. Clarity isn't simple or easy but it is exactly what we want in programming languages.

<comment><USER7> Clarity is hard to define. You seem to argue that a simpler language such as C gives rise to more convoluted code while more complex languages such as Java can deliver more terse code.

That's not always the case. Take GUIs for example. In pre-C++/Java times the user interface declaration was often data. Now it is code. Whatever data is still necessary to function, such as button texts, are now object attributes. That code can then grow functionality and that's when you get non responsive UIs and hard to debug callback spaghetti. So things are done differently in less expressive languages, but it's hard to argue it's less clear in the general sense.

Another example is "application servers" and the rise of enterprise programming where object factories instantiate other objects in order to keep dependencies unidirectional. In a more simple language none of that would exist, and that particular problem would not be there to solve. But would it mean more complex, and perhaps unique, solutions elsewhere in the software? I'm not sure. Git won out over the more engineered and more complex alternatives for example.

<comment><USER6> I agree that clarity is hard to define. But so is power. Is C more or less "powerful" than Java?

</comment></comment></comment><comment><USER8> Graham's essay is basically about what general purpose language to use when you're a small technical startup of clever hackers who want to develop cool stuff as fast as possible, using the language as a competitive advantage.

His conclusion is, bluntly, Lisp, since you can reprogram that language arbitrarily and it won't get in your way.

It is also excellent for implementing DSLs, which can be as powerful as you want. For example, Viaweb uses (still!) a Lisp-based DSL to provide the non- Turing-complete customization language for their customers, and I suspect that whole thing was a weekend hack.

(Edit: it probably is Turing complete though.)

The ease of creating such restricted DSLs comes from Lisp's power. At some point you'll need a general purpose language, if only to implement your other specific languages. If your team can be competitively productive with a remarkably powerful language, Graham says you should use it.

<comment><USER9> The other side of massive isolated productivity is: nobody except them knew it or could maintain it. Yahoo ended up doing the whole "rewrite lisp in C++" thing because you can't hire "experts in paul graham's custom lisp macros" at scale.

But, it worked, didn't it? Grow, scale, cash out, dump code on non-founders, become startup messiah.

<comment><USER10> Let's see now. Paul Graham wrote viaweb in Lisp and claims it was a competitive advantage for a startup.

What is his track record with startup(s)? Do we just count N=1? Or do we include what YCombinator has accomplished?

Now let's look at what Yahoo has accomplished as a BigCo.

Under the circumstances, would you bet that Paul was right about Lisp, Yahoo about C++, neither, or both?

I'd go with Paul being right about Lisp, and Yahoo, well... I'd call that N=1 at best. Clearly they started from a "We already have hordes of C++ programmers" point of view, and a "We apply hordes or programmers to every problem" point of view.

It might be the only point of view for them. It could very well be that there were hundreds of Lisp programmers available, but none might have wanted to work for Yahoo under any circumstances. Your mileage may well differ, based on the overlap in the venn diagram of language, culture, and problem set.

<comment><USER11> One thing that people forgot to mention is that Paul Graham was a Lisp expert before he started Viaweb - he had already written _On_Lisp_ which is still considered as one of the references to learn Common Lisp - and probably Robert Morris wasn't a bad lisper as well. They most likely were much better programmers than their competitors or Yahoo's median employee, so while Lisp may have been a competitive advantage for them, it wasn't the one that gave them the strongest edge. We don't have the data of how Lisp experts fare against equally strong C++ (or some other language) - although it may be that Lisp magnifies programmer's strength.

<comment><USER10> If we take Paul's "The Python Paradox" essay, and turn its conclusions up to eleven, we might end up with this extreme perspective:

Perhaps great programmers are great in any language, and a company employing great programmer will have great results in any language, it's the programmers that are the competitive advantage for a startup.

But although they'd be great in any language, they have taste, and prefer to work in some languages regardless of whether that is a competitive advantage or not. And therefore, they prefer jobs and startups with languages that match their taste.

And taking that a step forward, these mythical great programmers might prefer working with other people they perceive have taste, so they tend to clump together, and they see the language choice as a kind of signal of what kind of colleagues they will have working for a particular company.

If all this handwaving has merit, it could be that choosing to do your startup in Lisp when Paul started ViaWeb was't 100% about having a competitive advantage from Lisp itself, it was having a competitive advantage from having Paul and Robert, and anybody else they hired.

\---

With larger companies, they will never say it, but sometimes they don't want these "great programmers," with their taste and their salary demands, and their code that causes an army of middle-of-the-road workmanlike programmers to stare thoughtfully for long periods of time working out how it does what it does.

Even if they end up being more productive, perhaps they end up being less predictable, because a smaller team of better programmers is more vulnerable to poaching as the company goes from developing the next big thing to an endless march of adding small enterprisey features. Even if you write in Scala, Haskell, Lisp, or Clojure, when the work becomes maintaining Yahoo... Maybe you don't want people who relish a challenge, because they'll quit.

So you want to anti-signal, by rewriting it all in a workmanlike language, so you get workmanlike people. And if it takes touch longer or costs a bit more overall, it's predictable because the people are more fungible. They're easier to replace.

So it could very well be that when you're launching a startup, you want to go out on a limb and choose the language based on the kind of people you want to hire for a startup.

And when you mature, you might rewrite it in another language based on the kind of people you want to hire for a mature company.

And both choices might be right for their times. And neither might actually have anything to do with the "power" or "expressiveness" or "abstraction" of the language itself.

<comment><USER12> The vast majority of companies don't need these great/gifted programmers, they need the workmanlike people who will suffer the constantly changing requirements and priorities, and lack of product management, or even product definition.

<comment><USER13> I still remember the day I realized that this 5-years-cursus titled engineer was a glorified cashier position.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> It's a great post, well worth reading.

However, I don't completely agree with the conclusion. I think that what we need is to correctly identify the situations in which giving up power _in a specific way_ will give more power elsewhere.

You can't always know this up front. And you can't just get all this benefit for free by religiously following the principle "always go for the least power possible".

Instead, we need to look at the status quo -- even parts of it we haven't questioned for a long time -- and ask, "Where could I give up a little power in exchange for much greater benefit elsewhere?"

<comment><USER15> Indeed. HTML and CSS are great examples where by giving up expressiveness for the author, you can gain more power for later reprocessors -- uncommon for programming languages (because halting problem) but a common thing to do for language-like things like markup, Puppet manifests, etc.

<comment><USER16> Oh, you overstate it. You could always do that stuff in DSL's in languages like LISP while maintaining the power. That would've been helpful to prevent what HTML and CSS's lack of expressiveness resulted in: a whole mess of tech for client, server, and transport to make up for what they couldn't do. Languages like Curl or Opa were both more powerful and more understandable than that collective mess.

Hence, why we want powerful and versatile languages with optional reductions via DSL's.

<comment><USER17> Writing and using a DSL in LISP seems to be the definition of reducing your power in a case you find it useful. I'm not sure what nuance you're drawing.

Changing requirements and the browsers wars made the web a mess, not this design decision. If the web is a set of linked documents available for public consumption, do we really need to encrypt it? I would say yes (because information about STD treatment may be public, but your interest isn't), but it would be understandable to leave it in clear-text. But what about a worldwide commerce platform? Oops, we'd better layer on TLS.

<comment><USER16> "If the web is a set of linked documents available for public consumption, do we really need to encrypt it? I would say yes (because information about STD treatment may be public, but your interest isn't), but it would be understandable to leave it in clear-text. But what about a worldwide commerce platform? Oops, we'd better layer on TLS."

That's a tangent topic I'm not really focusing on. I'm talking about the presentation, efficient transport/updating, storage, and so on of content & data accessed via the web. Aka web sites and web applications. I'm saying Turing complete HTML doesn't cut it by far which is supported by the fact that hardly anyone uses it: server-side includes and Javascript at a minimum going back to 90's. Leading to...

"Writing and using a DSL in LISP seems to be the definition of reducing your power in a case you find it useful. I'm not sure what nuance you're drawing."

It reduces power for that DSL specifically. This gives us the advantages of reduced power. However, every other requirement can then leverage either DSL's or the powerful language to solve them. Or, like Opa, one can just use a powerful language with good attention to safety. In any case, you get a language that solves your current problem, solves your [likely] next problem, solves them well, is efficient, is compatible with HTML or whatever, and _is consistent across the stack_.

Sounds better than the hodge-podge of crap that mainstream, web apps are made off. The mess certainly wasn't created by HTML's design but HTML's & its partners aren't suited to dealing with the mess most effectively. Right tool for the job, ya know.

</comment></comment></comment></comment></comment><comment><USER18> This 100x. After learning to program in Coq (sub-Turing-complete functional language) and SQL, I've come to recognize that I have never in two dozen years of coding needed to express something that wasn't expressible in some sub- Turing-complete language.

Turing-completeness is overrated and is more often that not a cop-out excusing poor language design. Sub-Turing-complete domain-specific-languages simplify program design, reduce bug surface area, and aid analyzability and understanding.

<comment><USER19> SQL is actually Turing-complete; using recursive CTEs, you can build a cyclic tag system, which has been proven to be Turing-complete.

<comment><USER20> SQL in its original incarnations is not Turing complete. It's mainly the bastardized, enterprised, heavily-extended versions built by people who have to sell it that are Turing complete.

<comment><USER18> To be fair, recursive CTEs are somewhat a blessing when you need to compute transitive closures. It is just unfortunate that they were designed as generative constructs (= you can create and recur on rows out of thin air rather than only products of other finite relations).

</comment></comment></comment></comment><comment><USER21> Bob Harper has also made this point before: "The power of type theory arises from its strictures, not its affordances, in direct opposition to the ever- popular language design principle "first-class x" for all imaginable values of x." [https://existentialtype.wordpress.com/2013/01/28/more-is- not...](https://existentialtype.wordpress.com/2013/01/28/more-is-not-always- better/)

<comment><USER18> Completely agree. People think I'm weird that I think functions being first- class is a dumb idea.

But think about it: how often do you need to perform some complicated algorithm on a function, or store a dynamically generated function in a data structure? Almost always, first-class functions are simply used as a means of genericizing or parameterizing code. (e.g. as arguments to `map` or `fold`, or currying.) (Languages like Haskell and Coq that are deeply rooted in the lambda calculus are a notable exception to this; it's common to play interesting games with functions in these languages.)

You can get the same capabilities by making functions _second-class_ objects, with a suitable simple (non-Turing-complete) language with which to manipulate them. That language can even be a subset of the language for first-class objects: the programmer is none-the-wiser unless he/she tries to do something "odd" with a function outside the bounds of its restricted language. Generally, there is a clearer, more efficient way to express whatever it is they are trying to do.

There is some precedent for this. In Haskell, typeclass parameters live alongside normal parameters, but aren't permitted to be used in normal value expressions. In OCaml, modules live a separate second-class life but can be manipulated in module expressions alongside normal code. In Coq, type expressions can be passed as arguments, but live at a different strata and have certain restrictions placed on them.

Unfortunately designing languages like this is _hard_. It's easy to just say "well, functions are a kind of value in the interpreter I just wrote; let's make them a kind of value in the language". This is the thinking behind highly dynamic languages like JavaScript, Python, and Elixir: the language is modeled after what is easy to do in the interpreter without further restriction. The end result is a language that is difficult to optimize and analyze.

It's a lot more work to plan out "well, I ought to stratify modules, types, functions, heterogenous compounds, homogeneous componds, and scalars, because it will permit optimizations someday". But these are the languages that move entire industries.

<comment><USER21> In general, language design requires a balance between first-class vs. second- class objects. First-class objects are important because they let you write the program you want. Second-class objects are also important because they let you write programs that can be reasoned about.

For instance, Haskell's type language (without compiler-specific extensions) has no beta reduction, because only type constructors can appear not fully applied in type expressions anyway. This reduces its "raw expressive power" (w.r.t. System F-ω, whose type level is the simply typed lambda calculus), but it makes inference decidable, which helps machines help humans. It also helps humans in a more direct fashion: Haskellers often infer a lot about their programs just from their type signatures, that is, _without having to compute at all_. It's no wonder that Haskellers love reasoning with types - it's literally less work than reasoning with values.

So I agree with you that "first-class everything" isn't a good approach to take. A language with first-class everything is a semantic minefield: Nothing is guaranteed, sometimes not even the runtime system's stability. (I'm looking at you, Lisp!)

\---

But, on the specific topic of first-class functions, you'll pry them from my cold dead hands. Solving large problems by composing solutions to smaller, more tractable problems, is a style that's greatly facilitated by first-class functions, and I'm not ready to give it up.

<comment><USER18> You misunderstand (as most do): I never said function composition was a bad idea; I do it all the time.

My only claim is that you don't need a Turing-complete language to compose functions. As an thought-exercise, consider replacing all uses of first-class function compositions in any given OCaml program with top-level module compositions. You lose nothing: no-one (who designs maintainable software) uses the full expressive power of a Turing-complete language to manipulate first-class functions.

(Of course there are more user-friendly ways to implement second-class functions, which make using them less a burden, but no extant language has such a system.)

<comment><USER21> When did I say "function composition"? What I said is "composing solutions to smaller, more tractable problems". If you divide a problem `FooBarQux` into a sequence of subproblems, `Foo`, `Bar` and `Qux`, sure, these solutions must be combined using the function composition operator. But there are other ways to decompose problems. For instance, splitting a problem into a DAG of subproblems with overlapping dependencies gives rise to dynamic programming.

And, no, an ML-like module system wouldn't make up for the lack of first-class functions. Standard ML doesn't allow any module recursion whatsoever, and, while OCaml allows it, it's quite unwieldy to use in practice. It would be literally impossible to define a function like `fix`, which requires the ability to call its function argument (let's call it `f`), supplying an expression containing `fix` itself as argument.

<comment><USER18> Since when do you need first-class functions for dynamic programming?

How often have you had to define `fix`? It's not even possible in certain strongly typed functional languages.

I stand by my assertion. First-class function manipulation is not a thing 99% of programs need to do.

</comment></comment></comment></comment></comment></comment><comment><USER22> Seems like an argument in favor of domain-specific languages: identify the domain, and create something just powerful enough to suffice.

Indeed, most of the arguments made are the same that were used as justifications for DSLs a while back:

> The problem with this kind of freedom is that every bit of power you insist > on have when writing in the language corresponds to power you must give up > at other points of the process — when 'consuming' what you have written.

A good DSL lets you create, for example, business rules that are easy to maintain (for those familiar with the business) but don't prevent me from swapping out the implementation that drives them for something better on down the line.

<comment><USER23> What would a DSL for creating DSLs look like? And could it be self-hosted? It's turtles all the way down. :)

<comment><USER24> Kernel is ideal for creating small embedded languages, where you can selectively expose parts of the parent language to perform general purpose computation, without giving any access to sensitive code.

Kernel is like Scheme, except environments are first class objects which you can mutate and pass around. A typical use for such environment is for the second argument of _$remote-eval_ , to limit the bindings available to the evaluator. If you treat an eDSL as a set of symbols representing it's vocabulary and grammar, then you bind them to a new environment with _$bindings-environment_ , then passing a piece of code X to eval with this resulting argument as the second environment, will ensure X can only access those bindings (and built-in symbols which result from parsing Kernel, such as numbers), and nothing else.

There's a function _make-kernel-standard-environment_ for easy self-hosting.

Trivial examples:

        ($define! x 1)
        ($remote-eval (+ x 2) (make-kernel-standard-environment))
        > error: unbound symbol: x

        ($define! y 2)
        ($remote-eval (+ x y) (make-environment ($bindings->environment (x 1))
                                                (make-kernel-standard-environment)))
        > error: unbound symbol: y

        ($remote-eval (+ x y) ($bindings->environment (x 1) (y 2) (+ +)))
        > 3

        ($define! x 1)
        ($define! y 2)
        ($remote-eval (+ x y) (get-current-environment))
        > 3

_$remote-eval_ is a helper function in the standard library which evaluates the second argument in the dynamic environment to get the target environment, then evaluates the first argument in that. The purpose of this is to provide a blank static-environment for o to be evaulated, so no bindings from the current static environment where _$remote-eval_ is called from are made accessible to the first argument.

       ($define! $remote-eval ($vau (o e) d (eval o (eval e d))))

If you're familiar with Scheme, you may notice the absensce of quote.

And contrary to the opinions in the article, Kernel is the most expressively powerful language I know, and I'd recommend everyone learn it. You have a powerful but small and simple core language, from which you can derive your DSLs with as little or much power as you want them to have.

<comment><USER23> Thanks! I will check out Kernel.

The ability to restrict the environment is key. Creating a DSL in standard Lisp would create a _more_ powerful environment: the DSL would include all Lisp features plus the domain features.

</comment></comment></comment></comment><comment><USER25> This is a big part, if not _the_ most important part, of why I like Haskell. "Purity" is a giant stroke in the direction of using the least powerful language possible at all times (and the advanced types let you both declare the level of power you want and compose sub-languages of different powers together). You also often go deeper due to the large prevalence of deep or shallow embedded DSLs in the typed-functional languages.

In short, this is, to me, one of the most important principles of programming.

<comment><USER26> So why Haskell and not, for instance, SML? I guess SML is not necessarily pure, but it certainly a much simpler language than Haskell.

<comment><USER27> Without purity, you have the power to express a lot more, burdening the reader.

Purity lets you easily and arbitrarily constrain a function or program -- easing the burden for the reader who is free to assume so much more about what they read.

</comment></comment></comment><comment><USER28> Sometimes, yes. But sometimes, you're just going to chafe at the restrictions. And then you start adding to your restricted language and you've created a monster.

Case in point: every build system targeting the JVM. Most build systems in general.

</comment><comment> vezzy-fnord I wouldn't read that much into what TimBL is saying about the "principle of least power". It seems more like a _post facto_ realization, and particularly in light of expectations for a transition into a Semantic Web. The 1990 WWW proposal [1] reveals the web to have been more-or-less the bare minimum glue to unify CERN's document troves, and to do so in a highly expedient timeframe. A far cry from TimBL's earlier ENQUIRE, and no in-depth design principles per se.

[1] [http://www.w3.org/Proposal.html](http://www.w3.org/Proposal.html)

</comment><comment><USER29> It's kinda interesting that he writes a long blogpost with many ideas that are quite similar to the Langsec ideas, however in the comments he says that he wasn't aware of Langsec.

I am not surprised. Langsec could really be a gamechanger in many aspects of IT security, yet many people in the Infosec community are not aware of these concepts.

If you're curious, this older talk by Meredith Patterson is still worth watching a lot: [https://www.youtube.com/watch?v=3kEfedtQVOY](https://www.youtube.com/watch?v=3kEfedtQVOY)

</comment><comment><USER30> Pick the most expressive language that you can get. Constrain it with a coding standard. As people chafe against the coding standard, alter it as needed.

There is no benefit to restricting yourself arbitrarily based on what someone who isn't even involved in your project thinks. I think that most people have difficulty enforcing a coding standard. This is because they don't have a cohesive team. This is a people problem, not a technical problem. If you try to fix the people problem with technical solution, the problem will just pop up some place else.

<comment><USER31> For most practical purposes I agree, I would just like to add that restricting yourself on top of a non-restricted language is something where technical help is useful: that's basically what lints are about. This is not to say that the people aspect is irrelevant; after all, you need to get the people to agree to the lints.

</comment></comment><comment><USER32> See also: [http://langsec.org/](http://langsec.org/)

</comment><comment><USER16> Tloewald is right that clarity is the real issue. I've seen powerful, BASIC- like 4GL's whose operation were more clear than simple language doing equivalent things because they were designed for that. The ideal language gives you just enough features and power to let you productively express what you need without being too complex to understand.

The DSL languages are in a special category here. You start with powerful host languages such as LIPS/Racket or REBOL. The language is usually simple enough to understand plus has something like macros for extension. Each domain that we run into a lot and/or has plenty boilerplate can have a DSL that lets us concisely express those operations both for productivity and clarity. The underlying language is powerful and still comprehensible for times when the DSL's aren't enough.

So, the author is a bit off. What we need isn't less powerful languages. It's powerful languages maintaining clarity and avoiding the everything but the kitchen sink philosophy.

Note: HTML/CSS wasn't the best choice to support author's point. It was good for static pages. Yet, people needed more power. So, they added a crappy client-side language, all kinds of server frameworks, then all kinds of client frameworks, and so on and on. Languages like Curl and Opa handle the situation with a unified, powerful approach that was more clear than the web ecosystem in general. Also had less security and maintenance issues. So, author's example works against them in practice.

</comment><comment><USER33> It's well known that there is a trade-off in language and systems design between expressiveness and analyzability. That is, the more expressive a language or system is, the less we can reason about it, and vice versa. The more capable the system, the less comprehensible it is.

[http://blog.higher-order.com/blog/2014/12/21/maximally- power...](http://blog.higher-order.com/blog/2014/12/21/maximally-powerful/)

</comment><comment><USER34> I would guess the canonical example of this is goto. By the definition the author uses, goto is extremely powerful. At the same time code written with goto is generally a complete mess. Instead languages provide for loops and while loops which are more restrictive than goto, but much easier to reason about.

(I'm working on a blog post about this.)

</comment><comment><USER35> The biggest change to my coding style in the past few years has been to opt out of the most expressive solution if it will fall apart in a cut-and-paste situation.

Many new features are variations on old features. The incremental cost of implementing one so that I can cut and paste the next half dozen is small. The cost of refactoring to a generalization after that is also small. But the cost of poorly generalizing early and having to reimplement feature one and everything it touches in order to make feature two possible is quite painful.

This becomes more obvious when you have different codebases with similar features that might want to share from time to time. A formally generalized solution becomes a big dependency, as it relies on a heavily specified problem. A slightly too primitive solution flows between codebases freely - plug in new primitives and it runs.

</comment><comment><USER36> This reminds me of the philosophy behind Forth, where you build up 'words' enough to express your program, but by itself it doesn't have much built in.

<comment><USER37> That's something that always kinda bugged me about tcl, the language is pretty bare bones in itself and you end up writing some pretty basic stuff in any given project.

Of course you end up building your own little standard library over time, but then you've got to import it into any given project.. Just an irritating extra bit of friction. And reading someone else's code means learning their standard library... (is it a standard library when everyone has their own?)

<comment><USER38> Is this simply a consequence of Tcl not shipping with the sort of standard libraries that are expected nowadays, as opposed to being a problem that follows from having a terse language?

<comment><USER37> I like that question and that distinction, and I think the answer is I'd give is "yes".

Tcl's flexible, to the degree of being able to define new language constructs or redefine built-ins (e.g. you can redefine the basic if-then if you want), which is great in some ways.

But it always seemed to me like the language culture is so deep in the mentality of "if you need, implement it yourself," that the flexibility becomes a crutch for the language developers.

What I mean is.. well, the basic data structure is the list, and you get built-ins for adding to a list (lappend), reversing a list (lreverse), but removing an element from a list (what would be 'lremove')? You've got to code it yourself.

Hey, the man page for 'lreplace' even gives an example! [http://www.tcl.tk/man/tcl/TclCmd/lreplace.htm](http://www.tcl.tk/man/tcl/TclCmd/lreplace.htm)

 _Why isn 't that built in?_ The common answers are, it's so simple you can code it yourself, or you might want an lremove with different behavior than me. To the second answer, realistically, if the language had a built-in lremove, most people would just express their programs to use it, and those who needed a different one could still write it. To the first, yes, it's simple, but it's just a little bit of sand in the underwear--unpleasant friction you'd like to ignore but keeps popping up.

Lack of built-in OO was the same way until relatively recently in the language history. Lots of people made home-brew ones, and there were several common OO systems, but what's a newbie to do? Research all the different OO systems to make a decision first? More sand in the underwear. Run into enough of that stuff and it just drives you crazy and makes you want to stop using the language.

</comment></comment></comment></comment><comment><USER39> Optimize for writers or optimize for readers. The more powerful languages optimize for writers. The less powerful optimize for readers (aka the code reviewers, the people who come after you to fix your bugs, etc).

I'm a huge fan of less is more. I review a lot of code.

<comment><USER16> That's just what's common. General-purpose 4GL's are both very powerful and easier to read than most languages. Similar examples in LISP and REBOL communities. Power != lack of comprehension.

</comment></comment><comment><USER40> I don't really see an issue here. Regular expressions, HTML, configuration files... these aren't _programming_ languages, they're _data_ languages.

They don't describe an algorithm or a behavior, they just describe data. For that purpose, it's preferable to have a format that's as simple to read, process and analyze as possible. On the other hand, actual _programming_ languages are meant to describe an algorithm, and "power" usually means either high-level expressiveness (Scala) or low-level adaptability (C), both of which are very important in some contexts.

<comment><USER21> The language of regular expressions _is_ a programming language. It's just not Turing-complete.

<comment><USER41> it's a programming language in the same way that a flashing light can be a programming language. If someone on the other side is using it to make decisions then you're technically programming something so it's a "programming" language.

I mean sure, technically that's true, but it's also not interesting.

The interesting thing about regexp is that it's really damned close to the mathematical notations used for describing regular grammars, and therefore it's a good, tight way to specify pattern matches on regular grammars.

No one ever really answers with "I've been programming the regular grammar parser". Sure, maybe technically that's what they've been doing, but the context isn't really right.

<comment><USER21> > it's a programming language in the same way that a flashing light can be a > programming language. If someone on the other side is using it to make > decisions then you're technically programming something so it's a > "programming" language.

You're totally missing my point. A regular expression describes a _computation_ \- the series of state transitions a nondeterministic finite state automaton undergoes in order to decide whether an input string belongs to a language. (The fact that this computation is typically optimized by regex compilers is another matter.)

A programming language doesn't need to be general-purpose to be a programming language.

> The interesting thing about regexp is that it's really damned close to the > mathematical notations used for describing regular grammars, and therefore > it's a good, tight way to specify pattern matches on regular grammars.

Are you saying that what matters most about a language is its surface syntax? Seriously? Wow.

<comment><USER41> > A regular expression describes a computation

So does the flashing light, it also has the cool advantage of being parameterized by time.

> Are you saying that what matters most about a language is its surface > syntax? Seriously? Wow.

If that's what you took from that then there's a knowledge gap and it will do us no good to continue this conversation.

</comment></comment></comment></comment></comment><comment><USER42> > •compilers — with big implications for performance

D is one of the most powerful languages available, and it compiles faster than about any.

In any case, in the hands of an expert, using a powerful language results in simpler user code. This is because the program can be crafted to look like the problem being solved. In fact, it's why we have programming languages in the first place rather than writing assembler in hex bytes.

</comment><comment><USER43> This topic seems less about power and more about invariants. I could imagine a powerful, fully expressive language that does a better job of explicitly stating its invariants.

In the `urlpatterns` example,

      urlpatterns = [
          url([m('kitten/'), views.list_kittens, name='kittens_list_kittens'),
          url([m('kitten/'), c(int)], views.show_kitten, name="kittens_show_kitten"),
      ]

I could see `m` and `c` being used as a more-specific-than-regex DSL specifically for routes. Reversing routes would be even easier because of the inherent limitations of using the DSL - you have to pass a string to `m`, you have to pass a type (and a variable, ideally, so it would be `m('kitten/'), c("id", int)` or just `m('kitten/'), id()`.

The lesson I gain is "figure out the implicit invariants from your design decisions, make them explicit and try to keep as many of them as possible, only letting go once you have no other choice."

</comment><comment><USER44> From a productivity & maintenance perspective, very many coding jobs / tasks can be executed more efficiently by using purportedly limited tools. Are you HNs really surprised to hear this? The drive is time-to-market reduction, improved communication and, overall, domain-specific standardisation.

<comment><USER45> One objection I have to this is that no matter how much someone believes they can guarantee a certain job or task will be confined within a subset of general computing, inevitably the software gets pressured by business use cases to 'break free' and do more general purpose computing.

An example might be saying something like "Things you do in a spreadsheet will never benefit from object orientation to such a degree as to justify implementing that ability for the sake of the business's bottom line."

As a former analyst in a financial firm, I encountered this idea all the time. You can use Excel's "slope" to do regressions. You can even do matrix arithmetic if you're willing to deal with the syntax. You can program basic functions.

In a strictly time-to-market sense (the time from some ad hoc financial analysis in a spreadsheet to 'market' \-- either producing a report for your boss, a strategy implementation, or some other deliverable based on what your spreadsheet calculations showed you), throwing stuff in Excel, copy/pasting code from templates, etc., can't be beaten.

But this is a very narrow view. For example, data provenance is extremely difficult if your work is a directory of spreadsheet files. Even if they are version controlled, there is no automatic way to understand how the spreadsheet programmer intends to copy/paste some functionality out of one template and into another at the moment a new analysis is performed. The dependencies, if documented at all, are documented only in natural language descriptions, rather than overt 'import' or 'include' style statements, or static analysis of what gets used where.

Unit testing is often ignored in a spreadsheet environment and it's a huge pain to do in the rare cases when someone actually tries to do it. The focus on superficial aspects of 'time-to-market' also puts pressure to avoid version control, even if the spreadsheet paradigm as a whole doesn't necessarily have to reduce use of version control.

But far beyond any of these items, there are (for example) tools like Pandas, or even xlwings, in Python, or HFrame/HMatrix in Haskell, and I'm sure many other things in many other languages, which presents you with what is effectively a spreadsheet as an abstract data type.

You can programmatically perform the spreadsheet interactions that would otherwise have been manually reproduced, and you can include more advanced software techniques, like logging or unit testing, since you are simply working in a full-featured programming environment, rather than an environment where the feature set is purposely limited.

In this case, I've never heard any compelling argument for why a direct spreadsheet is better than a spreadsheet-like abstraction in a full programming language.

The arguments I have heard to justify continued direct use of a spreadsheet are:

(a) the people using it don't know how to write code and the business doesn't believe it's worthwhile to hire/train programming talent for such a role.

(b) someone who makes the decisions is using a hyperbolic discounting function when they assess the future returns of compounding automation through proper software design vs. just-get-it-done-today-by-copy/pasting-in-a-spreadsheet- if-you-have-to attitude.

(c) "Programming" is a low-status activity, and so business/marketing/financial analysts must perform some activity that is plausibly different than "programming" so that "programming" doesn't experience a status rise within the organization, and potentially affect people's raises/bonuses/promotions or project allocation.

Let's take a step back from this example of spreadsheets. What is the general phenomenon going on? I would argue that it is about automation and productivity. But then, general purpose computing is also about automation and productivity. There can be counterexamples for sure, but most often newer layers of abstraction are introduced because they create genuine value in terms of making it easier to automate something or making a more generalized lever that lifts whole categories of heavy things instead of just lifting this or that specific heavy thing.

No matter what limited-scope tool you start out with, over time lots of the tasks performed within the scope of that tool will be repetitive and/or will agglomerate into clumps of similar work that can be factored out into an abstraction.

When the tool also has general purpose computing abilities, you can take advantage of these opportunities to automate or factor out clumps of work and write generic, reusable solutions. The process of doing this almost always has huge positive effects of productivity, especially as it accrues and compounds over time. It's overwhelmingly worth it to pay generally modest short term costs to work in this manner, rather than trying to hack in ways of coping with bottlenecks in a tool that can't support general computing.

Part of the problem, though, is that many middle-managers and up within any given organization do not understand how this works. The syntax of their brains only manipulates the "programming language" of the business. Deliver X to Y; ship Z by Friday; give me a forecast of W. They don't unpackage "Deliver X to Y" down into its atomistic components and ask to what extent general programming can help, and whether or not it will have returns on "Deliver X1 to Y1" next week and "Deliver X2 to Y2" the week after that.

When programmers throw an exception within the business's programming language, Exception('We can't ship Z by Friday if we also write sufficient unit tests this week.'), what happens? Let's just use unit tests as the example of a "general computing" behavior that might sometimes be axed in favor of justifying a narrow-scope tool environment for business reasons.

In some organizations, this is considered very carefully, and a lot of attention is paid to the engineering assessment. The managers may ultimately come back and say, "You know, we really looked it over and did some careful thinking, and we still must ship Z by Friday, so skip the tests." In that case, probably the managers and engineers alike both agree that you don't want a limited programming environment for the task. Unit tests mattered to the engineers, and they also mattered to the managers even though they had valid reasons to skip it this time. But all parties probably agree that, in principle, unit testing would have been better and should be at least a possibility.

In other organizations (a lot), the Exception is simply caught and never handled. Managers don't like hearing about something that sounds like a whiny and low-status issue ("programmers want unit tests"), and so they mandate that such things be skipped, and support using tooling environments where such things are not even a possibility. And at the end of the day, they justify this as a necessary business reality, when it's pretty questionable whether they truly ran any numbers to decide if the longer term gains from unit testing more than offset any short term slowdown to write the tests.

In practice, it's always some gray-area mixture of all of these things, and sometimes there definitely is a legitimate reason to forego general computing options for business reasons.

But I am very skeptical of the more far-reaching claim that it helps bottom- line business productivity to reduce _the possibility of_ automation and software productivity practices enabled by general computing capabilities.

<comment><USER44> Great comment, thanks. We both know that corp managers prefer straining systems, reap rewards and then disband: no legacy, no reuse, new projects. I have one question, though: would you suggest a 2016 startup to focus on best practices or product-market fit? That's the value we're considering here, imho.

<comment><USER45> My feeling is that it is indeed worth it to be pedantic about these kinds of best practices in a start-up. In fact, when I left finance to join a start-up, literally the whole reason for doing so was that the start-up was supposedly a place where engineering best practices are valued more than incremental short- term business progress, in contrast to the stodgy bureaucratic finance firm where political in-fighting prevents best practices from materializing.

I don't personally see any reason to believe working for a start-up could possibly be a good idea otherwise. (And since most start-ups only pay lip service to supporting best practices, while really supporting only short term incremental business gains like any other kind of organization, this is generally a good reason to default to believing that it's a bad deal to work at any given start-up.)

For me, this also has a lot to do with vision and consistency. If you create a start-up and your only goal is to sell it (or, more realistically, you are expected to do this because it is the goal of the VC firm you got into bed with), then you're not only not going to focus on best practices, but you're also going to jettison any part of your mission or vision any time it's not convenient to some incremental short-term growth opportunity. By the time you reach a point to sell the business, it may be completely unrecognizeable from the vision you started with.

If your only goal is to make money, this might not be a problem. But probably not very many people who agreed to work with you will share the feeling -- and they certainly won't stand to make meaningful amounts of money -- and so they are unlikely to be happy workers through most of the process. That means you haven't been getting their best effort all along, and the product is probably shoddy.

Generally (but not always), good engineers don't want to work for something that is explicitly a hype machine where _maybe later_ quality will be hacked back into it, but probably not. So start-ups that fundamentally take an approach of short term product-market fit are pretty much by definition staffed by bad and/or unhappy engineers.

Contrast this with something like 37Signals/Basecamp. Of course they had to make engineering sacrifices along the way and didn't always do everything in some pedantically best-practices-adherent way. But their ethos/vision was to be much more about best practices than about unreasonable growth or winning an acquisition lottery. Yes, they were driven by succeeding with product/market fit, but they didn't ever become a slave to it or turn into zombies about it.

Given that there's such a poor success rate among start-ups (a large base-rate bias towards failure mode), it's hard to draw much from outliers of any kind, whether they are like 37Signals/Basecamp, or they are like some always- pivoting shop that always favored short term business gains but still succeeded despite it. But my perspective is that it's way, way better to be on the side that pedantically clings to an engineering vision and has a general ethos of turning down short-term business gains as a means of investing in longer-term best-practices-focused infrastructure.

</comment></comment></comment></comment><comment><USER46> I have been looking into quicker languages for scripting and scripting desktop applications. I found [http://www.rebol.com/](http://www.rebol.com/) which is fantastic and powerful without being overcomplicated.

</comment><comment><USER47> _Burdening the reader_. That's a good take-away for anyone reading this article. Every abstraction you introduce is a burden on your reader, user, and customer. They will be more difficult to maintain without passing on your specialized knowledge. They will be slower than they otherwise would be. They come with a cost.

These are machines we're programming. They have instruction sets and memory architectures. We need more languages like Jai, IMHO, that give more power to the programmer to exploit the target platform underneath and provide interesting patterns for controlling resources and transformations.

</comment><comment><USER48> That's why I'm not a huge fan of Coffeescript or even convenience utility libraries like underscore/lodash. They save you a couple of lines or a few opening /closing braces but they make code more difficult to understand (to the average programmer) and (in the case of utility libraries) increase your reliance on reference documentation.

I generally prefer simple constructs that require multiple lines over complex one-liners. Although it depends on who is on the team. I prefer to write code that any polyglot programmer with a modest level of mastery in any specific language can understand.

<comment><USER49> > They save you a couple of lines or a few opening /closing braces but they > make code more difficult to understand

There is a massive confounding factor: popularity, in the sense of what is familiar to the largest number of people. And this, in turn, is largely an accident of history, politics, and marketing.

Which is to say, sure, more people will understand a "for" loop written in the familiar C/Java style than a "map" one liner. But that does _not_ mean the "for" loop is easier to understand, in the sense of expressing a concept naturally and declaratively.

<comment><USER50> On the other hand having a filter construct is way nicer than having to manage the two arrays on your own.

Or worse yet, when someone is trying to remove items from a list that is self resizing, it is very easy to make bugs (by not adjusting the counter in the for loop when one is removed).

</comment></comment></comment><comment><USER51> I take exception at the notion that one cannot "guarantee" the presence of a specific key, when one is using a key:value store without an explicit schema. (sounds like someone was believing anti-mongo FUD and living in sql-land too long...) If you built a structure and put it IN the database, you can use that same structure to get it OUT...the presence of a key can be checked, etc. all one is doing is moving the schema into the codebase (where I argue it belongs... the opposite being an all-powerfull-db with stored procedures as a kind of remote-remote-procedure-call)

</comment><comment><USER52> I think the author is mixing two separate issues - data (HTML, JSON, database records, etc) and the tools to manipulate it (languages).

IMHO, we need simplicity and clarity in our data structures, APIs, JSONs and powerful (but simple, still) tools to modify that data. If you're using Clojure this library has been great for me recently [https://github.com/nathanmarz/specter](https://github.com/nathanmarz/specter) .

</comment><comment><USER53> So, great, this is the mainstream view. It won. We got Pascal, that philosophy mutated into Java and here we are. It takes lots of code to do stuff, and that's universally scored as a maintainability win. All right. Who disagrees? Little pockets of Lisp hackers up in the hills?

Unless the argument is that we need another big wave of even weaker tools, it feels unnecessary to give this sermon in 2015.

(I invite people who disagree to express something concrete in reply.)

<comment><USER54> One example would be a language to deal with TLV data, like ASN.1 DER (e.g. TLS certificates). Currently most TLS libraries use C, which is insane, but in principle, you don't even need recursion to parse DER data; so even vanilla Haskell is overpowered for the purpose.

<comment><USER53> Yeah, for sure, in a lot of applications you really don't want people chanting "code is data, data is code" and building impossible shit that nobody can figure out.

A finite state machine can easily be made basically un-debuggable by human beings.

It's just ... maybe it's the crowd I hang out with, but I feel like these ideas have already totally won.

</comment></comment></comment><comment><USER55> I think the problem here isn't power or expressiveness per se, but a large number of fundamental concepts. For example, vanilla Haskell has a lot of expressiveness built around a few core concepts (first-class functions, parametric polymorphism, typeclasses). However Haskell + 101 extensions or Scala derive a lot of their expressiveness from a plurality of fundamental languages features. _That_ is what creates the real problem.

<comment><USER27> Note that Haskell extensions all compile (straight-forwardly) down to a relatively bare (typed) language.

That is, the set of fundamental concepts exposed is no greater than the bare language, except the higher abstraction allows controlling which subset of the power is exposed so that type inference can be kept, and various syntactic sugar can be used.

Haskell (with virtually all extensions used) doesn't have that many fundamental concepts, and a small minority of extensions actually are fundamental at all.

</comment></comment><comment><USER56> Well, yeah. Wasn't this really obvious from "goto considered harmful" and the concept of functional programming (a 'pure' function being a function that's constrained from having side-effects, i.e. explicitly less powerful)?

Basically, YAGNI.

<comment><USER24> But how do you implement the small, concise languages without the gotos and side-effects to begin with? You're gonna need a language with sufficient expressiveness and the capability to perform side-effects to do so. Implementing a new language entirely without side-effects is infeasable. Replacing GOTO with some structured variant is trivial though.

</comment></comment><comment><USER57> Funny that he links the Video of Paul Philips. He never said 'the language is bad because it's so complex', he said the internals are bad because it's so complex. That's a total different thing.

</comment><comment><USER58> This Forth alumni just sits back and smiles...

</comment><comment><USER59> Another advantage would be low barrier of entry and therefore bigger ecosystems due to a larger dev pool.

</comment><comment><USER60> That's why I love Erlang, Scheme and other FP languages. They're so _simple_.

</comment><comment><USER61> 1.

> I also need a word about definitions. What do we mean by "more powerful" or > "less powerful" languages? In this article, I mean something roughly like > this: "the freedom and ability to do whatever you want to do", seen mainly > from the perspective of the human author entering data or code into the > system. This roughly aligns with the concept of "expressiveness", though not > perhaps with a formal definition. (More formally, many languages have > equivalent expressiveness in that they are all Turing complete, but we still > recognize that some are more powerful in that they allow a certain outcome > to be produced with fewer words or in multiple ways, with greater freedoms > for the author).

I understand that adding

\- automatic memory management \- exception handling \- object oriented facilities (polymorphism, inheritance)

make a language "more powerful" by allowing the programmer to think at a higher level. For me, this means the language gets out of the way and I can focus on the problem at hand, but everyone seems to have a different idea of what "getting out of the way" means and what constitutes the ideal "default toolbox" for a programming language.

For decades it was true that higher level meant more powerful meant a better default toolkit for the developer, but I resonate with the sentiment that a plateau has been reached in terms of designing the basic toolbox a languages makes available for the programmer.

A less powerful language means easier and more readily available tools to parse and manipulate programs written in that language, which leads me to...

2.

> This happened to me recently, and set me off thinking just how ridiculously > bad our toolsets are. Why on earth are we treating our highly structured > code as a bunch of lines of text? I can't believe that we are still > programming like this, it is insane.

With all due respect, JavaScript as implemented in node.js or in Chrome is a brilliant language and is a fine environment for implementing a static code analyzer and transformer. The same is true of Python, Scheme, C, C++, Java, and many other modern programming languages. It takes relatively little code to to implement powerful tools to parse and manipulate source code when relatively few syntactic forms are accepted. See for example my autoclave.js project below.

The one Wikipedia article I come back to again and again is the "Additional Example 1+1" of [https://en.wikipedia.org/wiki/LR_parser](https://en.wikipedia.org/wiki/LR_parser)

3.

There is a parallel between the instruction set architecture (ISA) of a chip and the syntactic forms that a programming language recognizes. One measure of the "size" of a language is the number of productions in the grammar definition. So I think of a "highly expressive" language with a complicated grammar as a "CISC language" and as you say a "less powerful language" as a "RISC language". All other things being equal, it is easier and faster to implement a toolchain for a smaller language than for a larger one. This is why it is (or was, at any rate) reasonable to ask a first-year college student to implement a meta-circular interpreter in Scheme (MIT 6.001). This is not possible for most other languages (and it is certainly not possible in Python).

This project is just one attempt to carve out such a usable "RISC language" as a subset of JavaScript. If you have the time, I'd appreciate your feedback, thoughts, and suggestions. Thanks!

[https://github.com/dbpokorny/autoclave](https://github.com/dbpokorny/autoclave)

</comment><comment><USER62> I'll give you a two character answer: C#

</comment><comment><USER63> If you want a simple dev environment, language and tools, you can start with Microsoft WebMatrix and Visual Basic and then graduate up to more complex stuff. Visual Basic is very similar syntax to python in a lot of ways. WebMatrix IDE and ASP.NET makes it simple to do. One click deploy to Azure and you are done.</comment>


Gym Class Is So Bad, Kids Are Skipping School to Avoid It - <AUTHOR> https://www.theatlantic.com/education/archive/2019/01/why-pe-is-terrible/581467/ <comment><USER2> I think the worst thing about gym is that I didn't learn anything there.

I didn't learn about calories, or healthy eating. I didn't learn about basic cardio, why it's good for you, or how often to do it. I didn't learn about how to build muscle, what reps or sets were.

Gym amounts to mindless busywork. Do stuff or you get an F. It could serve as a foundation of knowledge to set yourself up for healthy habits for the rest of your life. Instead, it has the opposite effect of training you to hate fitness.

<comment><USER3> I gained a deep, searing hatred of team sports due to a combination of forced participation and being a physically awkward teen in the middle of an epic growth spurt. Being graded on ones ability to complete a mile within a certain time constraint, as opposed to being graded on effort, is utter madness. The whole thing put me off physical activity for most of my adult life. Only in the last couple of years have I started exercising again, but on my own terms and for my own reasons.

There is a huge difference between "because you have to" and "because I want to".

<comment><USER4> > Being graded on ones ability to complete a mile within a certain time > constraint, as opposed to being graded on effort, is utter madness

How is that different from being graded in other subjects in school? You don't get an A in calculus because you tried to answer the question, you get a grade based on how good you answer the question.

<comment><USER5> Calculus isn't a required course and as such has less of a pressure to "pass everyone". You don't get an A in pre-algebra either just for trying, but since everyone has to take it if you're trying then you're unlikely to get held back on that class even if most of your answers are wrong.

I'm fine with coaches grading on performance. It's a proxy for effort + talent like a lot of things, and as non-geniuses know effort extends outside the classroom proportional to your talent. If you can't even get a 20 minute mile, you're going to have to put in more effort outside the classroom, which might involve refusing to eat 100% of mom's delicious huge dinner or doing "exercise studies" (i.e. working out outside of class).

Whether gym class should be required is another discussion. I don't think it should be (and that easily filters out most people complaining about being graded for performance anyway) and it's a pretty poor attempt at managing rising obesity rates.

<comment><USER4> I was giving calculus just as an example, I was referring to a general subject in school where you have to study and do your homework in order to get good grades. I am pretty sure most of those who got low grades in gym classes did not bother to do any "homework" to make themselves prepared to the next class (e.g. practice catching the ball, do pull ups etc). It's the same with kids who had bad grades at subjects that required thinking, they did not bother to do their homework and were not really interested in reading, studying etc...You should look at the issue from both perspectives

</comment></comment></comment></comment></comment><comment> yoz-y Before I moved to France I hated P.E. classes. But I think they did something right here. The year is divided into three sports that you do for three months each. There is always an individual sport (track, swimming) a team sport (rugby, handball) and a one on one (e.g.: badminton). Emphasis is on knowledge of oneself, for example for track you have to predict your time for 3x500m run and you get 1/3 of points this way. If you predict too low or high, you will lose on grade. This means that you actually have to get to know your limits.

The only issue I had was for team sports where the individual differences are just way too high to construct a game interesting for everybody.

<comment><USER6> Yeah, I didn't particularly care for PE as a French kid growing up, but in hindsight I can play pretty much any common sport decently because of it. One unexpected side effect is that it makes socializing quite easy - I can accept when someone invites me to play tennis, volleyball, etc. because I have some basic grasp of the sport from school.

In fact, when I moved to California, I saw that everyone was really into climbing, and started doing it too because I had done it in school, even though I had never been into it at the time.

</comment></comment><comment><USER7> I'm convinced that gym class results in millions of lost disability-adjusted life years for every generation. Kids are either naturally athletic, in which case they'll exercise whether you want them to or not, or they are naturally nonathletic, in which case gym class just teaches them that exercise is the officially sanctioned method adults use to bully kids. It took me about ten years to figure out that exercise could be enjoyable when it's not forced on you by the psychopaths who end up as gym teachers. Gym class should be banned, or if that's politically impossible, the job should be assigned by sortition like jury duty. Nobody who wants to be a gym teacher should be allowed to do it.

</comment><comment><USER8> If it were more about physical education (literally) and had less emphasis on actually _doing_ intense exercises I think it would be a lot more beneficial. Leave the crazy intense physical activities to extracurriculars. No personal trainer would create a one-size-fits-all training routine, but for some young students that's literally the entirety of what "gym class" entails.

By Physical Education, I mean learn about basic health issues, commons diseases and symptoms to look out for, learn the importance of diet and exercise, standard first aid, that kind of thing.

<comment><USER9> Even the physical activity isn't bad - but it's completely unfocused. One week you're running laps, the next you're playing random ball games. You learn a little about stuff in the weight room, but not enough where you can run a good routine after the fact.

At no point is there any option of "hey, let's tailor a fitness goal and plan for you to stick to for the majority of your life". But then again, the goal of schools isn't to maximize pleb fitness, right?

<comment><USER8> I'm _pretty_ sure the purpose of the modern gym curriculum is to create more meat for the college-football grinder.

<comment><USER10> Modern P.E. (and many sports) goes back to at least antiquity where the need for militarization in society was greater. Military training has set the standard for exercise and sports because it provided an established system of collective activities and clear outcomes to promote strength, discipline and collaboration. Qualities that any military force needs.

<comment><USER11> > Modern P.E. (and many sports) goes back to at least antiquity where the need > for militarization in society was greater.

Honestly, even without the need, it would probably be better if modern PE was structured with the intent of preparing students as much as individually practical for participation in the universal militia, even if we know to a relative high degree of certaintt that those who don't volunteer are unlikely to be called to serve, with a curriculum cooperatively designed by experts in child physical development, child intellectual and social development, and modern military operations and civil emergency operations.

As it is, it seems to be an unfocussed and poorly directed afterthought that remains around because eliminating it would offend people, but without a strong purpose or any concern from policy makers except firefighting reacting to problems that emerge as the unmaintained structure clashes with evolving social values.

</comment></comment></comment></comment></comment><comment><USER12> When I was at school you were sneered at by teachers for anything less than upper average performance - imagine that happening in maths or English classes.

It took me years to recover, I never did any more structured exercise until I was in my late 30's, now I love it.

<comment><USER13> Ahhh - bad memories of humiliation and bullying. Took me 2 decades to realise I can actually love sport, sad to see that happening to the current generation.

<comment><USER14> Yep. I'm 57 and I still hate all forms of exercise thanks to my experience in gym class.

</comment></comment></comment><comment><USER15> People don't like to be in situations where they are stack-ranked according to a skill they are bad at.

Stereotypical jocks lose when you stack-rank them in a random math class, so the second they can drop maths they do. And before that, they might wag it.

Stereotypical nerds lose when you stack-rank them in a random p.e. class, so the second they can drop p.e. they do. And before that, they might wag it.

When you force people in the bottom end of skill distribution into a stack rank system, it does real damage to their self esteem. And this will essentially traumatize them from actually achieving growth in the subject. And that growth is actually important. Stereotypical jocks are much better off for not being afraid of maths. Stereotypical nerds are much better off for not being afraid of exercise.

One solution is pretty simple. Isolate the top, say, 10-20% of performers in each skill, and stack-rank away if you want. They'll have enough self esteem with respect to the skill to be motivated by the open competition. But most of all, just isolate them from the rest.

With the rest, you'll probably have more luck with a growth mindset type philosophy. Do whatever you can to take focus away from absolute performance metrics, and get them to focus on their own growth. And keep them the hell away from that top 10-20%.

Ideally, you follow this principle through all the way through the skill distribution and organize classes into quintiles of ability.

Just remember, if you're going to rank people, then isolate them from people they can't compete with.

It takes a very unusual kid/teenager to come away _motivated_ by the experience of being totally dominated in some area.

</comment><comment><USER16> It seems to be terrible in both Australia and the USA, over a long period.

My son's Judo instructors had much more fond memories of European style instruction, which sounded considerably more demanding, but more structured and educational. Part of the problem to my way of thinking was that PE class, by high school, has just become a way of glorifying those who already have physical prowess at the expense of everyone else.

This is not helped by the fact that most PE teachers, in my experience, were the most avid disciplinarians and the least intelligent teachers of anyone I encountered.

It's a pity. It could be done way better. They would have to start earlier, set higher standards for the kids (while practicing positivity and focusing on how much they can improve everyone), and VASTLY increase the quality of the teachers. It also wouldn't hurt to reemphasize the offering of a wide variety of sports for everyone (rather than focusing all resources on a few chosen teams, or, like most schools I know about in Australia now, just not really having sport anymore).

</comment><comment><USER17> Am I wrong in thinking that technology amplifies how we gauge the energy required for physical activity? With just a few moves of my finger I can watch a video, read a paper, talk to people, etc. Contrast that with running, lifting, etc. The effort required for the comparatively minute results we achieve seem dramatic across this contrast. I wonder if having computers with an internet connection in their pocket at all times is making kids lazy... which may be an additional factor in this reported situation.

</comment><comment><USER18> That's sad. In my high school days (2000s) gym class was just as bad. I skipped it every time, flunked it, and took a health night class to make it up. I liked going to school at night and health class was awesome so it was worth it :)

The worst part of gym class was the bullying. The aggressors usually got energized through gym class and started messing with other students right after. Gym classes were pretty big and we often had "do what you want" days so idle/bored bullies went into action some more.

</comment><comment><USER19> I was fortunate that my highschool offered a choice between PE and _weightlifting_ classes.

PE has clearly always been for suckers, I remember seeing kids playing volleyball or soccer or running 3 times a week in the hot sun with no sunscreen, half of them not really even giving a fuck, and thinking how I had NO desire to be a part of that mess.

Weightlifting by contrast, was not only an easier class but also much more educational. It was like going to the gym and having a personal trainer plan your workout and give you advice. The coaches wrote up an exercise plan on the whiteboard and you just went and did it on your own, occasionally they walked around making sure people weren't goofing off.

If you wanted to slack off it was easy to just do light weights and go through the motions but most people actually did put in effort to see physical change in their bodies (and of course there's always peer pressure to be strong and fit, especially with girls watching). And because weightlifting has natural downtime in between reps you could socialize freely.

The stuff I learned in that class helped me to not be clueless when I went to an actual gym by myself. In fact, I've been going to the gym regularly ever since that class ended.

</comment><comment><USER20> I don't understand all of these complaints. Is the solution to difficult coursework to do away with lessons? Why are physical challenges treated so differently from mental difficulties? Sure, not everyone is athletic, but the fact that not everyone is studious and intelligent is not a reason to avoid encouraging people to be so by sending them to school.

I think what we really need is a serious, rigid, disciplined curriculum in PE. That probably doesn't involve team sports so much as learning to exercise for fitness and self improvement, totally different from the half-assed gym classes that we have in the US now.

Bullying is a symptom of other problems and is not an argument against good physical education. Perhaps if ours hadn't turned into such a sensitive, coddling culture, we wouldn't have a 40% obesity rate[1].

1.[https://www.cdc.gov/obesity/data/adult.html](https://www.cdc.gov/obesity/data/adult.html)

</comment><comment><USER21> In lieu of gym class, my school required us to participate in a club sport or school team every season. We actually got much more exercise having gym every few days, and the fact that we got to choose what sport to play made it something we could get personally invested in, even people who were not naturally athletic.

</comment><comment><USER22> I hated gym class the most out of all the classes in school. It felt like torture. But then again, I have asthma and nobody had explained to me back then what asthma meant for gym class.

Outside of that, I have to agree that gym class didn't really teach me anything.

</comment><comment><USER23> A counter opinion:

I wasn't that great. But I found out that, if I got open in the end zone, they'd throw me the ball, and I could catch it. This led to me going out for the football team.

I wasn't that great there, either. I was like fifth or sixth on the depth chart. But it led to a lifetime of being in fairly decent shape.

(Note well: Gym class itself did not lead to a lifetime of being in fairly decent shape. But the exposure to various sports, and finding one that I liked and did all right at, was still a big deal. Also note that this was in the 1970s; things may well be worse now.)

</comment><comment><USER24> I have to say Gym for my 14 year old has turned from one of her favorite classes to one of the worst.

It seems like a pretty rigid curriculum that's centered around various easy to quantify things (like time to run a mile) and not anything to do with being healthy, exercising, or having fun.

So they keep them on the asphalt for an hour when it's 110F. They teach them dancing and changing partners every 30 seconds during flu season. They have then run through muddy grass when it's raining. More like a boot camp than anything fun/healthy.

<comment><USER25> > run through muddy grass when it's raining

Will the horrors never end?

<comment><USER24> Try spending 8 hours working productively with cold soaking wet feet the squish when you walk.

</comment></comment></comment><comment><USER26> I loved gym class. It was easy and a relief. Some of the sports I really enjoyed, like floor hockey and soccer. There were some lame ones too, and also some creepy behavior from the male gym teachers toward certain female students. But other than that it was the easiest part of the school day. I could turn off my brain and work up a sweat.

</comment><comment><USER27> My son did crew to avoid gym class. Turns out he really liked it, but the motivation was a hatred of gym class.

</comment><comment><USER28> I didn't want to have PE at 7am and be sweaty and stinky for the next 5 hours. On sport teams we showered but that's the people wanted to be there.

> why this particular P.E. program was counterproductive... points to > bullying... it facilitates the teasing of overweight or unathletic kids.

Making PE more strict on _everyone_ because of the _few_ promotes the exact opposite of the desired result. It's fallacious to believe the obese are that way because they are bullied. We divert dumb kids, yes? Why is it insensitive for the obese? Mixing these groups destroys morale. Varsity kids workout together, junior-varsity work out together, etc, because it works.

The administration babysits warm bodies for cash. The PE teachers will end up taking the blame for giving kids their recess back.

</comment><comment><USER29> We had an odd thing in elementary school gym class - parachutes! We sat around a parachute on the floor, and the teacher would play a record (it was the 80s) that would tell us when to raise/lower our arms then swap places by running under it when it was above us.

<comment><USER30> I think this was really common in the 80s/90s in the US.

</comment></comment><comment><USER31> It's the same problem everything suffers from: meeting targets rather than doing a good job.

</comment><comment><USER32> They need to have less competitive sports where everyone focuses on themselves. Team sports like football and softball causes lots of bullying of weaker and non-athletic kids because everyone else is drive to make their team win.

</comment><comment><USER33> Kind of funny how so many people here (myself included) hated gym class because of being bullied or being physically awkward. I wonder if this is a widespread issue or if it's just that hackernews is full of nerds.

</comment><comment><USER34> During gym we did running, sit-ups, volleyball and kickball. Wish we done weights instead. no one on YouTube is making money with jogging and sit-up videos. it's all weight lifting.

</comment><comment><USER35> My two most excruciating memories of physical unpleasantness: having strep throat, and cooling down after "the mile" in middle school gym class.

Gym class taught me that a healthy lifestyle is about extreme discipline and regular self-torture. It took me a decade to discover that you could ramp up into exercise in a way that didn't make you want to die, and to make sense of the way other people talked about having any kind of positive experiences with it.

</comment><comment><USER36> Gym was awful. The teachers were awful, the bullies were awful, we learned absolutely nothing and felt like they were just trying to make us expend energy. What time would've better been spent in a class talking about cooking and nutrition, and how to prepare healthy meals

</comment><comment><USER37> The comments here are really confusing me. I went to a New England public school. Gym was mostly a fun team sport game that rotated every month or so. I was very athletic. Most of my friends were the opposite. I believe we all had a good time regardless.

</comment><comment><USER38> things i remember from gym class in middle school/high school:

* gym class was every single day, 5th grade until 12th grade.

* mile run every Friday (I hated it, but it did help me get to sub-7 mins by high school, for someone who was never athletic)

* heart-rate monitors we wore that strapped across our chests. every day we had to get our monitor and apply this gross conductive gel to the device and strap it around our bare skin at chest level. you got credit for the gym period if you got >15mins of HR above 120.

* Badminton!

* Those scooters with wheels on them.

* Step-aerobics. Holy cow. Exercising with plastic stools.

* A locker room with showers, which showers I have never seen anyone use once.

* line dancing for some reason?

</comment><comment><USER39> The problem with gym class lesson plans is they gradually become "laminated" so all you have to do is wipe them with a paper towel when you spill your coffee on them.

</comment><comment><USER40> My high school removed dodgeballs and gave us these foam bullshit things that didn't even work.

So that was the end of PE, at least for me...

</comment><comment><USER41> My school district required gym for everyone from jr high through high school. Did I enjoy it? No. Has it been useful for the rest of my life? Absolutely. If it weren't for those PE classes, I wouldn't feel comfortable at the gym with free weights, and wouldn't know how fast I can be at running. It changed my life despite being my least favorite class. I'd recommend daily gym be required for my children.

</comment><comment><USER42> Three words:

Shirts.

Versus.

Skins.

<comment><USER43> Haa...I remember those days. Actually, I saw some kids playing pond hockey yesterday who were playing shirts vs skins in the 40 degree (f) temperatures.

</comment></comment><comment><USER44> Two things predict success, which correlates to health and happiness, in life well, IQ and Conscientiousness.

Schools can't teach IQ.

Does gym teach conscientiousness? I don't know, but for smart kids academic high school classes certainly don't. School should not be easy for anyone including smart kids, it needs to challenge.

"These adolescents were not enjoying the daily P.E. requirements and would've rather skipped school,"

Swap that with work and you get life. At what stage do you teach children to be adults?

</comment><comment><USER45> Ah, the days when the US had Government-ordered fat shaming.[1]

"Give that chicken fat back to the chicken and don't be chicken again."

"Nuts to the flabby guys."

[1] [https://www.youtube.com/watch?v=EFofqe26t-4](https://www.youtube.com/watch?v=EFofqe26t-4)

<comment><USER26> Ah.</comment></comment>


I'm thinking of open sourcing an old project - <AUTHOR> http://demo.chartwidget.com

<comment><AUTHOR> I'm going to copy the text that I posted to my blog here. Not sure about all the etiquette of this.

<http://paddymullen.com/2008/11/19/open-sourcing-chartwidget/>

In 2007 I wrote a javascript charting package named chartWidget. I intended to pursue business opportunities with it, that didn't work out (another post).

Take a look at the site. You can view the javascript source, but it is obfuscated, I modified the YUI Compressor to munge global variables somewhat safely.

Anyway, I think I wrote some pretty cool code. I'm not currently doing anything with it, and many friends have recommended that I open source it. So I am thinking about it.

I have some questions

1\. Which license to choose? I'm leaning towards GPL, because it is still a bit hard to let go. Which license puts me in the best position should someone want to use it (for me to possibly receive consulting fees)?

2.Should I include my whole subversion repository, about 700 revisions, I'm worried to do this, because it quite likely includes passwords ( I know bad practice)? On the plus side including the whole repository could show thought patterns, to help other people debug the code

3.Will anyone care? I guess I can find out by doing it.

4\. My code is idiomatic to say the least, in some places wrong, and in many more places just hard to understand. How much will this matter for me, if someone looks at the code will they consider me an idiot?

5.What questions am I not asking that I should be?

* editted to remove p tags

<comment><USER2> 1\. The license you choose probably won't make anyone more inclined to hire you for consulting. You're better off trying to decide how open you want code and contributions to remain.

2\. While a revision history is nice to have available, odds are most people aren't going to really look back at older versions of the code. Some code cleanup and documentation would be preferable (but does require your setting aside time to do that).

3\. You'll never know until you do. And it doesn't cost you anything to do it. (With some exceptions... see #5)

4\. You're not claiming its perfect so don't stress too much about it. Part of what open source is about is allowing someone to see what makes everything tick, warts and all. Because someone could always contribute back fixes.

5\. Have you thought about where you're going to make your code available (Sourceforge, GitHub, etc.)? Is there going to be a Google Group or something so people can ask questions or share their experiences with the code? Even if you're not expecting a massive wave of adoption, having some of that in place can make everything better (both for people interested in your code and yourself).

<comment><AUTHOR> I would probably do a Google Code/Google Group

</comment></comment></comment><comment><USER3> I clicked on the link and from the description thought "big deal" but checked out the demo anyway and actually that is really slick! definitely something that could be built upon or componetized for other projects!

<comment><AUTHOR> Thanks

</comment></comment><comment><USER4> GPL is hostile to commercial uses. Offering GPL only would restrict the use of your code to inhouse development and personal projects.

You could ALSO offer a "commercial" licence. That would give users the right distribute your code with their closed-source commercial code.

The dual licence approach means that users that aren't making money off your code don't have to pay, and those that are do.

On the repository point: I'd suggest putting the current code onto something like Google Code. If you're not moving the code forward and no one else can fix bugs or make improvements, then the project is basically dead.

<comment><USER5> Slight correction: hostile to _proprietary_ usage. Lots of people are making money using GPL</comment></comment>


Lifehacker Faceoff: Outlook vs. Gmail—The Definitive Comparison - <AUTHOR> http://lifehacker.com/398778/outlook-vs-gmailthe-definitive-comparison <comment><USER2> They gave wins to gmail in some categories (like spam filtering) because it's better than out of the box Outlook. Fair, but irrelevant. You don't use Outlook out of the box.

I'll take Outlook with a Barracuda spam box over Gmail for spam filtering. It's Outlook's ability to be so customized that makes it worth it for me. (Plus mobile is very important, and until Android hits it has a huge lead there.)

They should have at least made extensibility a category.</comment>