Hacker News Comments on
Growing a Language, by Guy Steele
Bill Pugh
·
Youtube
·
269
HN points
·
63
HN comments
- This course is unranked · view top recommended courses
Hacker News Stories and Comments
All the comments and stories posted to Hacker News that reference this video.I've just started playing around with CSS after a seven year break from web programming and have the opposite impression. The two biggest additions I've seen are flexbox and grid both of which massively decrease the cognitive load—compared to past options, it almost feels like cheating. Moreover, they do this by consciously not building on top of past layout features but instead doing their own thing.CSS is still a mess of random features that can't be cleanly composed or extended—it's the complete opposite of a language that can grow[1]—but it's a more usable mess than it used to be.
[1]: Wonderful talk on language design by Guy Steele: https://www.youtube.com/watch?v=_ahvzDzKdB0
⬐ naasking> CSS is still a mess of random features that can't be cleanly composed or extendedThe lack of orthogonality and composability has always been the core issue. It's definitely better now, and atomic CSS makes this pretty close to simple.
⬐ alwillisCSS is still a mess of random features that can't be cleanly composed or extendedIf you separate old CSS from new CSS, it’s not so bad.
Yes, CSS has some technical debt from the olden times (like any programming language does) but these days, you need less and less of the old stuff.
For example, all of the alignment stuff created originally for Flexbox (justify-content, align-items, justify-self, etc.) were broken out in their own specification [1] and now CSS Grid and any future specification uses the same terminology to describe how to align something in a box.
Instead of every color model having it's own syntax, which is how CSS started, there's now color functions that can specify any color in any color space [2].
Since this is HN, let me note a wonderful talk based on the "introduce words carefully" concept: growing a language, buy Guy Steele
⬐ MrDOSThis is an excellent talk, and exactly where my mind went, too. I might suggest watching this upload of it instead, to avoid capture errors in the older upload: https://www.youtube.com/watch?v=lw6TaiXzHAE
I believe this great talk is a must for anyone interested in the topic: https://m.youtube.com/watch?v=_ahvzDzKdB0(Do give it a few minutes if you don’t find it useful in the beginning, it will make sense I promise)
⬐ ncmncmGuy Steele has fallen much farther from grace than almost anyone has risen.⬐ kaba0⬐ barking_biscuitWhat do you mean? (I am not a native speaker, but I believe it wants to be a praise, yet it seems negative to me..)⬐ ncmncmHis participation on Java is not to his credit.This starts off very strange and quirky and the moment it clicks was a very magical one for me the first time I watched it many years ago. It's one of my all time favorite talks.
It became a kitchen sink language similarly to C++. For all the hate Java gets, they did tackle language development very well - wait a bit for other, niche languages to be your testing ground of new features, and only add what sticks. Swift literally has all the features you can find in today’s modern languages, and they have some inconsistent interactions with each other. Also, even this litany of features isn’t enough to make SwiftUI implementable only as a Swift library, it uses some specifics not available in the language otherwise.And also, as most apple dev tools, it is the only modern language whose compiler failed under me (other than being slow as hell) - I have never gotten a type inference timed out error in other languages, even though it has been around for a time :D
As for growing a language, this is a must watch (bear with the presenter for the bit, you will soon understand why he talks strangely in the beginning): https://m.youtube.com/watch?v=_ahvzDzKdB0
It's not stealing if you first introduce it properly :-)
This is probably the best talk ever on the general topic: https://m.youtube.com/watch?v=_ahvzDzKdB0 [Growing a language by Guy Steele], seriously give it a look if you have the time and do put up with the seemingly strange start.But at around the end it asks this (paraphrasing): Should a language have complex numbers implemented natively? Should it have numbers module n implemented natively? What about intervals, or rational numbers?
I also dislike the ridiculous overloading of cryptic symbols, but neither extreme is good. Not allowing overloading will give you BigDecimal.of(3).add(BigDecimal.ONE).divide… , while allowing it unrestricted will give you things like msg #!! something. But perhaps a sane middle ground is to allow only basic operators (+,-,*,/) to be overloadable.
Reading the paragraph about Galileo's telescope reminded me of Guy Steele's talk Growing a Language:
⬐ mwcampbellIt does have a similar feel, but IIUC, Minimal English is trying to be systematic about restricting itself to true primitives, as opposed to starting with all of the words that happen to be one syllable in English. I imagine one can compose many hard-to-translate expressions out of one-syllable words.
I would say Java the language is fine, but the culture around it is what's grown the distaste many have for it. The overuse of design patterns, etc.I also find it fun how Guy Steele had in retrospect the perfect plan for Java back in the 1990s, and it took them 15 years to come around to it:
⬐ PaulHouleIf Common LISP had become popular I think there would be a popular distaste for everything about it and people would be wishing they could write code in PHP, Visual Basic, COBOL, Cold Fusion, etc. (There was a popular distaste for Common LISP at the time, it was hard to find a LISPer in the 1980s who liked it. Half of that was it was hard to fit it into a 16-bit machine and wouldn't become really implementable on microcomputers until a 32-bit OS was available... Thus BASIC got another decade of life extension.)Until Java came around every book on Object Oriented programming (say "C++") had examples such as "Stack", "Queue", etc. In the case of Java you saw people starting to write objects mirroring the business and application domains. People who were trying to use objects in Smalltalk or C++ in 1990 just weren't accomplishing enough that somebody could step back and say "object orientation sucks", rather they were getting stuck and blaming themselves or blaming the tools, rather than the concept.
⬐ pjmlpI see this repeated all the time.What people fail to realize is that the enterprise culture is language agnostic.
Before Java we were doing the same with C, C++, VB, Delphi, Smalltalk and whatever 4GLs one wants to dive into.
When Java gets replaced by TechX, the space ship enterprise architects will keep doing what they know best in TechX.
⬐ thomascgalvin> The overuse of design patterns, etc.Java has been trending away from this for some time now. A modern Spring app looks nothing like an old J2EE app.
⬐ fsdjkflsjfsoij⬐ txruModern Spring Boot is still incredibly bloated and full of questionable design patterns. A simple web application should not consume hundreds of megabytes of RAM by default and startup time on modern hardware should be basically instantaneous. Classpath scanning and annotations are still massively overused and most of the time they're accomplishing little more than obfuscation and turning compile time errors into runtime errors.⬐ kaba0⬐ dagwWhy exactly? How often do you start up a web application? And it’s not like the RAM is not there to use it — thread pools, db connection pools, etc have to be set up.A lot of us jumped off the Java train in disgust at the height of the J2EE craze and never looked back, so fairly or unfairly we'll forever be judging everything Java by that tainted memory.⬐ smrtinsertYep spring since 1.12 here.⬐ pjmlpA framework originally designed for Objective-C, actually.⬐ tombertWait, is that true? I know WebObjects was designed around ObjC, but a quick ten seconds on Wikipedia doesn't indicate that J2EE was designed around ObjC initially.----
Unnecessary opinion: I don't like either, but WebObjects sucks about 1/10th as much as J2EE.
⬐ pjmlpYou should have spent more than ten seconds.> By the time DOE, now known as NEO, was released in 1995, Sun had already moved on to Java as their next big thing. Java was now the GUI of choice for client-side applications, and Sun's OpenStep plans were quietly dropped (see Lighthouse Design). NEO was re-positioned as a Java system with the introduction of the "Joe" framework, but it saw little use. Components of NEO and Joe were eventually subsumed into Enterprise JavaBeans.
Taken from https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere
⬐ tombertAh, I was just quickly reading on the J2EE wikipedia entry and didn't see "Objective" anywhere on there.You're absolutely right, thank you for clarifying!
⬐ pjmlpNo issues, and here is another one, while Java might have a C++ like syntax to make it more appealing to mainstream, its main influence was Objective-C, not C++.https://cs.gmu.edu/~sean/stuff/java-objc.html
Hence interfaces, dynamic loading, reflection and so forth.
⬐ tombertInteresting.Bringing it back to a previous point I made, I met someone who claimed to have helped port over the WebObjects framework from Objective-C to Java, and he claimed that while it's not a 1-to-1, you can fairly easily map a lot of the Objective-C semantics to Java, making the porting process not that hard.
⬐ pjmlpYes, they are quite close.Objective-C related content,
https://developer.apple.com/library/archive/documentation/Le...
Java variant,
https://developer.apple.com/library/archive/documentation/Le...
Since that's an hour-long video, what do you consider the most salient points of his plan for Java that it ended up embodying eventually?⬐ VHRanger⬐ itronitronAbout user-grown features. Over time, Java let users expose more lower level details to the language than before.But, really, watch the talk. It's one of the best conference talks in computer science history.
Just like any other language, in order to use Java well you have to ignore a lot of the hyped up techniques.⬐ smrtinsertOveruse of design patterns seems like decades ago.⬐ polotics⬐ smallhandsSadly it is not: they still get taught, and then juniors come and they expert-beginner projects to death. And yes in 2022 expert-beginner is a verb! Cheersit is painful watching this video . presentation software and projectors are truly blessing⬐ alexjplant> I would say Java the language is fine,When I was using it I didn't particularly mind it except for the clumsy handling of functions (i.e. as objects instead of first-class citizens) and verbosity (no automatic accessors, implicit typing, etc). Adding Lombok solved most of these. *EDIT: Except for runtime type erasure of generics which caused (not sure about new Java) performance issues and made certain type operations difficult.
> but the culture around it is what's grown the distaste many have for it.
Having to debug esoteric issues with classpath, Spring, CDI, JPA, Aspect4j, etc. is hell on earth. I've lived that life and have no desire to do so again. Because Java is the lingua franca of enterprise development it also tends to rear its ugly head on modernization projects and rewrites. 80% of the abhorrently-engineered codebases I've encountered in my career were written in Java by body shops (C# and Coldfusion were the runners up).
> The overuse of design patterns, etc.
I'm not an adherent of the design pattern cargo cult but I'm one of four people under the age of 50 that have actually read the GoF book and I do indeed sometimes name objects after patterns described in the book; I typically design components and name them such after the fact as opposed to constructing systems from the ground up using design patterns. Calling a thing that persists comments in a database `CommentRepository` is a lot more useful than calling it `CommentHelper`.
⬐ PaulHouleIf you don’t like putting objects and classes on the left you can writeAnd proceed to write in your main methodimport static example.Library.*;in a style like C, LISP, or ML. You can write a whole program (like the answer for a HackerRank problem) in a single file. The developers of Java have always respected the ML family and JDK17 incorporates pattern matching, records, algebraic types and and many other features that make functional programming fun.var x = someFunction(6, ‘that’);The type erasure problem for generic classes goes away when you use generic methods; type inference works without limitation for generic methods and is great for defining APIs for internal domain-specific languages
the great thing about Java is a quality IDE is certain to support this programming style.any(grammar,you.want(ifIt.parses(ON_THE_LEFT)));Any complaint that the internal DSL is too verbose can be attacked by the use of code generation which is straightforward to incorporate in a maven build and your IDE. (The LISPer is using code generation and you have to do it if you want to keep up.)
⬐ progmetaldevI think the real majority of hate that I've seen for design patterns are when juniors go into a system looking to slap a design pattern anywhere they possibly can, quickly creating a ball of mud that is difficult to work with and figure out. At least that's been my experience (and I have to sadly admit I did the same when I was a junior without a mentor to help me through figuring out how to refactor my code into these patterns only when needed).⬐ matwoodI'm under 50 and read the GoF book ;)I'm one of the rare people who was writing vb and then c# during the terrible Java j2ee days. Then I got a job in a startup using Java which avoid the 'enterprise' idioms. So my experiences with Java over the last decade or so have been mostly good (except for a foray into Hibernate, never again - jOOQ for life). No crazy class models, no xml configuration, etc...
⬐ slaymaker1907Amen to esoteric Spring issues. I once dealt with a jar that suddenly started failing despite no code changes because Spring uses the order of files in the zip file/jar to determine initialization order. Turns out one that particular time files ended up in a weird order inside the jar file.⬐ The_Colonel⬐ pjmlpIt's natural to read and initialize the classes as they come, _unless the code defines a specific dependency order_.This looks like a developer simply did not declare proper dependency between classes/beans.
Try doing the same with CORBA and DCOM.⬐ stickfigure> Having to debug esoteric issues with classpath, Spring, CDI, JPA, Aspect4j, etc. is hell on earth.The term "DLL Hell" came from Windows development before it. The Node/Ruby/Python equivalent is getting native libraries to build (node-gyp, I'm looking at you!). I've burned days in Ruby Version Hell and Node Version Hell. Javascript dependency upgrades are a nightmare compared to Java dependency upgrades.
I don't think this problem has gone away, or even improved. It's just a grim fact of life, and Java doesn't deserve special mention.
⬐ alexjplantThe things you mention are no fun either (`node-gyp` in particular), but the Java issues I encountered were far beyond run-of-the-mill runtime linking and interop issues you describe. The details are lost to time and a bit fuzzy but I recall the primary issue being competing CDI implementations stepping on each other when we tried to use JSF with a recent version of Spring... and because most everything in the Java ecosystem was doing some opaque Aspect4J magic it was nigh-impossible to debug.⬐ tombertDespite my love for the language (and Stack has mostly fixed this), I feel like Haskell's "Cabal Hell" is amongst my least-favorite headaches from my past.Getting weird, hard to follow conflicts between different packages on Hackage and dealing with weird compiler hack flags is something that never got fun or easy.
People say this, but it seems like a false dichotomy. I use Emacs exactly because I choose productivity!Emacs might take more time to configure, but that's time measured in hours or, at most, days—a tiny blip compared to the total amount of time you spend programming in the environment! On the other hand, you get a system that you can quickly adapt to your specific needs in a way that other editors do not really support. It's the perfect environment for "situated software"[1], and environment that can grow[2] with your needs and workflow.
Emacs's learning curve and configuration is an O(1) cost for an O(n) benefit. As long as you're planning to use it a lot—and we're programmers, we're going to use it a lot—even a small increase in the benefit is worth a substantially larger up-front cost.
[1]: https://www.drmaciver.com/2018/11/situated-software/
[2]: "Grow" in a similar sense to Guy Steele's "Growing a Language" talk: https://www.youtube.com/watch?v=_ahvzDzKdB0
What a delightful talk! And how it resonates well with Nim!I went first for the transcript [2] but you should go for the video [1].
[1] https://www.youtube.com/watch?v=_ahvzDzKdB0
[2] https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf
delightful: full of good things that give joy
resonates: sounds in a way that is like the one you also say, and if you hear both you get more joy
transcript: a way to track down stuff that you can read and you do not need to see or hear
Changed from https://www.youtube.com/watch?v=_ahvzDzKdB0. Thanks!
I think you can draw this ‘core of an environment’ parallel between Forth and Scheme: both are small languages and they emphasize growing the language to the problem domain [1]. Common Lisp, on the other hand, is a large language: implementations provide much more than a foundational core, and a fairly comprehensive list of libraries exists. I think RPG’s Worse Is Better highlights some of the reasons why CL isn’t as popular as other languages [2].
⬐ pkageOff topic, but this (from RPG's Worse is Better) sounds very familiar:> Part of the problem stems from our very dear friends in the artificial intelligence (AI) business. AI has a number of good approaches to formalizing human knowledge and problem solving behavior. However, AI does not provide a panacea in any area of its applicability. Some early promoters of AI to the commercial world raised expectation levels too high. These expectations had to do with the effectiveness and deliverability of expert-system-based applications.
Haven’t read it but remembered this paper being mentioned in Guy Steele’s fabulous “Growing a language” talk [0].I don’t want to give anything away about the talk (which is one of my absolute favorites), but Steele says about the title of this paper: “... the truth is that Dick Gabriel knew how to choose words with punch“
If you like this, you'll definitely enjoy the talk "Growing a Language", by Guy Steele:
⬐ nalzokI was waiting for him to share thoughts on the failure (?) of Lisp, which I believe is a decent "shopping mall", but unfortunately he did not :(
> Honestly, this reads more like you're burnt out and would prefer not to have to keep apace of new developments to continue contributing.New developments don't necessarily mean "let's create new and weird syntaxes for TMTOWTDI"
> For one, natural language is constantly evolving. Shouldn't the languages we use to describe the solutions to problems be similarly capable if they want to keep up with a rapidly changing world?
There are many problems with this analogy. But before you read my points, or even instead of reading my points, I'd recommend you watch "Growing a Language" by Guy Steele: https://www.youtube.com/watch?v=_ahvzDzKdB0
1. A programming language is not a natural language. It is a constructed language
2. A natural language is not really constrained by anything. It can willy-nilly invent new words and concepts. It can import words and sentences wholesale from other languages, adapt, translate or transliterate them. It can deprecate and get rid of unused words concepts or give entirely new meaning to words. It can and is ambiguous.
3. A programming language is constrained and restricted. English has 500,000 headwords in a dictionary. All of those are "built in". Perl has maybe 100 total built-ins (including operators and keywords), plus a couple of hundred functions in the standard library?
4. A programming language does not aim to encompass all of human knowledge (a natural language does).
5. A programming language hopes to avoid ambiguity (C++ is rightfully criticised and ridiculed for the amount of ambiguous places in its standard). It aims to assign one and only one meaning to every word. A natural language will have thousands of words which have multiple meanings (famously, in English "set" has 464 definitions).
6. A programming language over the course of its evolution does not flip concepts or change meaning of words (except in very rare cases such as changing operator precedence). There are hundreds if not thousands words in every natural language that changed meaning (gay, nice, clue, spinster, senile etc.).
7. A programming language is usually concerned with backwards compatibility (even the rapidly evolving Javascript has to take care not to break sites from 15-20 years ago). Natural languages are never concerned with that. There are tragic stories of huge swaths of history and culture not available to modern generations in South East Asia after they swapped the commonly used Chinese hieroglyphics for national alphabets. Meanwhile programming languages like Clojure boast being able to run old code, and Linux is famously boasting that "it's usually just enough to recompile old programs".
etc. etc. etc.
> For two, we can look at what extreme conservatism in this department does to you. Python 2
That's not conservatism. That's pragmatism. "Don't fix what ain't broke" is a maxim that is as true today as it was yesterday, and as it will be tomorrow. There can be decades of institutionalised logic coded in Python 2. And it works. We should switch to Python 3 because someone said so?
There are 40-year old COBOL codebases that are still doing their job. Should they have been switched to C in the 80s, only to be switched to Java in the 90s, only to be switched to Python in the 00s, only to be switched to Javascript in the 2010s?
> Similarly, we see a lot of languages punt on actually making it easy to prototype and deploy modern data structures and algorithms.
What you call modern were most likely discovered in 1940s-1960s. All languages have been slow to adopt those. It still has no bearing on my initial statement of " A code by programmer A that does X is not significantly different than code that does the same X by programmer B". A boring language will adopt those modern structures in a boring way and my statement will remain as valid as it is now.
> That's why a bunch of mainstream languages still have very slow sorting algorithms in the stdlib
So, don't rely on stdlib in these cases.
> No one actually has this problem. Not Perl 6, not Perl 5, and not Haskell or Ocaml
Everyone has those problems in any language that adopted TMTOWTDI. It manifests in difficulty reading other people's code, onboarding of new hires in organisations etc. etc.
On that note, Rails' popularity (and its clones' popularity) comes from the fact that it enforced the "there's only one true way to do it" mentality in a language known for its TMTOWTDI approach. And still, if you take code that does the same by two different people, you'll have to reverse engineered each one as they will use and abuse the "let's do it differently" mentality.
⬐ KirinDave> 1. A programming language is not a natural language. It is a constructed languageConlangs can be universal. Certainly Toki Pona and Esperanto punch above their weight when given an opportunity to do so.
> A programming language is constrained and restricted. English has 500,000 headwords in a dictionary. All of those are "built in". Perl has maybe 100 total built-ins (including operators and keywords), plus a couple of hundred functions in the standard library?
Programming languages that lack these constraints not only exist, they're quite famous. You may have heard of Lisp. Similarly, the vocabulary that is the union of every C library in existence is surely more than half a million distinct tokens!
Both natural languages and constructed programming languages can constrain themselves to subsets of the total vocabulary, and then extend or contract that context.
> . A programming language over the course of its evolution does not flip concepts or change meaning of words (except in very rare cases such as changing operator precedence). There are hundreds if not thousands words in every natural language that changed meaning (gay, nice, clue, spinster, senile etc.).
Programming has tons of these as well. Many concepts are overloaded right now! The semantics under the symbols are constantly evolving. Heck, even things you might not believe have changed at lot have altered in subtle but important ways, like "new" and "delete" and "malloc" and "fopen." One of the most dramatically changed is "map."
> What you call modern were most likely discovered in 1940s-1960s.
No. 1990 onwards. People still spout absurdities like, "the fastest you can sort an array is O(n log n) time." But another important example is Bagwell's Hash Array Mapped Tries, which dramatically improve the performance of well-ordered key-value stores dramatically on modern hardware.
Outside of some interesting index techniques, I can't think of many worthy algorithms from the 60's lingering in obscurity. Can you?
> That's not conservatism. That's pragmatism. "Don't fix what ain't broke" is a maxim that is as true today as it was yesterday, and as it will be tomorrow. There can be decades of institutionalised logic coded in Python 2. And it works. We should switch to Python 3 because someone said so?
If you don't change your methodologies at all over the course of a decade as the entire world of computer science revolutionizes itself and we even start rethink how we're organizing operating systems?
> There are 40-year old COBOL codebases that are still doing their job. Should they have been switched to C in the 80s, only to be switched to Java in the 90s, only to be switched to Python in the 00s, only to be switched to Javascript in the 2010s?
Are there? I know a few banks deeply regretting their decision to keep their system of record on outdated cold-war-era technology as they struggle with hard complexity caps they can't address. But sure, I'm sure somewhere somehow this is true. It's just not actually an argument.
> Everyone has those problems in any language that adopted TMTOWTDI. It manifests in difficulty reading other people's code, onboarding of new hires in organisations etc. etc.
This is a just-so story. There is no magical solution that makes all code permeable. It's misguided to assume code can exist without good documentation.
> On that note, Rails' popularity (and its clones' popularity) comes from the fact that it enforced the "there's only one true way to do it" mentality in a language known for its TMTOWTDI approach.
Hi, I actually know a lot about this and there is no such notion in Rails. In fact, you have it exactly wrong. Rails is deeply committed to a "good default behavior" that is always subject to modification. And people do in fact modify it extensively to suit their needs. The idea that Rails's defaults are constraining as opposed to a rational starting point fundamentally misses the point.
⬐ landyacht> "let's create new and weird syntaxes for TMTOWTDI"Nothing in Perl 6 is there just for the sake of having it. Usually the options give you trade-offs between generality and concision/clarity. Like `[+]` vs. `sum`; sum is clearer (to someone who speaks English, at least), but it's only that: sum. You can stick any old operator in `[]`, and that happens to include `+`.
Also, "weird" is entirely subjective.
> There are 40-year old COBOL codebases that are still doing their job...
Absolutely agree here. There's no need to update well-written code just to keep with the fads. However, when the code is less-than-well-written, or the newer alternatives really do offer something better, you have a different story...
> So, don't rely on stdlib in these cases
So we're introducing a new dependency for a common task, adding extra work to maintenance and setup, because our language's standard library isn't worth a crap.
And what about the people who either don't want to bring in that dependency or are blissfully unaware that their stdlib's sort is suboptimal? There's no excuse for having an objectively inferior default. Third-party libraries should only have to implement use-case-specific algorithms.
> Everyone has those problems in any language that adopted TMTOWTDI. It manifests in difficulty reading other people's code, onboarding of new hires in organisations etc. etc.
As for onboarding, I think that has more to do with the "boring" languages being popular (so it's easy to find experts) than with those languages being inherently more readable.
I don't know if you've ever tried to get yourself "on board" with a Java codebase of any significant complexity, but I can tell you from experience that it's hell. I'm aware Java is an easy target, but it's what I imagine you mean when you say "boring." Sure, it only takes a competent programmer about a week to learn fully, but that doesn't make real-world Java code easy to read. Simplicity and readability aren't the same thing, and in fact too much of the former hinders the latter. The human brain has a limited amount of short-term memory and some pretty awesome long-term memory, but committing to it takes time. When you go about understanding a Java codebase, you're trying to commit an awful lot to short-term memory, including all the boilerplate and plumbing needed to build a workable platform up from the feature-bare language itself. And you repeat this for every new codebase. And people will make different architecture choices, even if the body of the code ends up looking similar.
However, what if the creator didn't need to write all that boilerplate? What if the language provided all the common tools? Now, a maintainer can take their time once committing the language's standard set of tools to long-term memory and recall that knowledge for every codebase they encounter. When there's less for creators to re-invent, there's less for maintainers to commit to short-term memory when they're trying to get in quickly to make a change. Thus, I think your point about trying to dissect two codebases which serve the same purpose is moot for Perl 6--it's either provided by the language or it's something unique enough that you'll only ever need to read one implementation.
Not to mention holding a load of Big Java Nouns© in short-term memory is exhausting. Ditto on C#, though it's admittedly a bit better. Same for C++ with its type parameterization insanity, or C and its macro insanity... the common thread here is Larry Wall's old Waterbed Complexity Theory being proven correct. Give people a limited set of tools with one knife and they'll always reach for the knife, eventually hurting themselves or someone else.
Perl 6 provides ways to very naturally express concepts, which in fact makes reading it easier. Plus, the excellent docs and helpful communities on IRC & StackOverflow make it very easy to learn as you go. I'm not going to sit here lying to you though--it does take time to get in the right mindset and fully grasp the language.
An interesting related talk, touching on the minimality and expressiveness of both natural and computer languages, is Guy Steele's 1998 talk "Growing a Language":Video: https://www.youtube.com/watch?v=_ahvzDzKdB0
PDF: https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf
Prior HN discussion: https://news.ycombinator.com/item?id=16847691, https://news.ycombinator.com/item?id=2359174, & others
⬐ fpgaminerThank you so much for linking this. It's such a fun talk, and I've been looking for it for years but nothing I tried in Google would ever bring it up.⬐ peterkellyThat's the first thing I searched for when opening this thread to see if anyone else had posted the link yet. Just brilliant.
This is what Guy Steele's Growing a Language talk was all about: "I should not design a small language, and I should not design a large one. I need to design a language that can grow. I need to plan ways in which it might grow—but I need, too, to leave some choices so that other persons can make those choices at a later time."https://www.youtube.com/watch?v=_ahvzDzKdB0
or as PDF:
https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf
⬐ nabla9Guy's point was that the language should be designed to be grown grown by users, not by language designers.> We need to put tools for language growth in the hands of the users.
Guy's previos work with Common Lisp is epitome of this. There are three kind of macros in the language: reader macros, macros and compiler macros. They give the tools for the user to extend the language. There is just 25 or so core primitives in the 'core' language and the runtime. The rest 900+ functions and symbols are basically the standard library (the fact that they are slapped into the same package and they extend the core in a ways that other languages can't hides the simplicity of the language somewhat).
⬐ joppyThis is an amazing talk, and a transcript does not do it justice in the slightest. If you have the time, listen to the talk!⬐ cagefaceI think this is a really appealing idea but so far nobody’s managed to build a successful language this way. I’d love to see a mainstream language designed on these principles myself but I think it’s not going to be an s-expression based language.⬐ ramchip⬐ duncanawoodsWhether it’s mainstream is debatable, but I think Elixir is a really successful example of extensible language, and indeed it managed to do this without s-expressions. Various libraries extend the language for HTTP routing, parsing, DB queries, property testing, static analysis, etc. It makes possible a lot of experimentation by the wider community, and not just the group of core language developers.The creator has repeated this philosophy a few times:
> There is very little reason for an Elixir v2.0 with breaking changes. The language was designed to be extensible and if we need to do major changes to the language to improve the language itself, then we failed at the foundation.
https://elixirforum.com/t/what-would-you-like-to-see-in-elix...
> A big language does not only fragment the community and makes it harder to learn but it is also harder to maintain. It is also why the language was designed to be extensible: so the community could build what is necessary without a push to make everything part of the language.
https://elixirforum.com/t/questions-about-property-testing-s...
> We also understand there is a limited amount of features we can add to the language before making the journey too long or the language too big. Adding something now means not including something else later. As an exercise, let’s see a counter example of when we didn’t add something to the language: GenStage. [...]
https://elixirforum.com/t/questions-about-property-testing-s...
It's been a while since I watched this but my current thoughts on "Growing a language" is that I fear it is an unhelpful simplification of what makes language design hard. IMHO language design is a holistic design problem that needs global optimisation. You cannot incrementally hill-climb yourself anywhere useful when you can't backtrack over past decisions.It is like designing a workshop. You only have so much space within arms reach. Here you place your most frequently used and valuable tools. You can "grow your language" by adding tools but they can't replace what you have in this limited and privileged position - instead, new tools have to go in cupboards or on another table. The new tools will have higher friction than the first priority tools you added.
Maybe you can have a workshop where you imagine a tool and it appears in your hand thereby removing the constraint of "tools within reach" but I think this then makes it too ephemeral and abstract. It is the constraints that makes a language tactile and ergonomic - remove the constraints and you have no structure at all.
In this case, the "tools within reach" are your core keywords and syntax. Growing features via libraries or syntactic extensions generally incur more ceremony and less elegance. Having totally flexible syntax extensions/keywords doesn't solve the problem, it just moves up a level abstraction/generality and means you have given your users the "design a language" problem instead of solving it for them.
⬐ wool_gather> you have given your users the "design a language" problem instead of solving it for themThis is an interesting observation that reminds me of
> In Lisp, you don't just write your program down toward the language, you also build the language up toward your program.
from Paul Graham's "Programming Bottom-Up". Some people would consider it an advantage being allowed to fold the "design a language problem" into the overall problem.
More, I think this is just a matter of degree, not kind.
As soon as you have something as apparently simple as named procedures, you're really writing a DSL, albeit very coarsely, for your business problem. Add named record types. Add textual macros. Add operator overloading. Add Lisp-style macros. At every point where the language allows a word on the screen to stand in for something larger, you're giving the programmer the power to design a language for their problem domain.
Guy L. Steele, "Growing a Language" (1998) (https://www.youtube.com/watch?v=_ahvzDzKdB0)As far as technical presentations can be, this is a work of art, and in spite of its age still completely relevant.
⬐ seanmcdirmidAnd YouTube doesn’t even really capture his use of beautiful crayoned transparencies in the live version of the talk!Also, any talk where Richard Gabriel and Guy Steele get together will be a treat. I really miss those old quirky OOPSLA days.
Maybe these are mostly too new, or you have different (more practical, hands on?) definition of tech-talk - but from a quick look the only speakers I expected - and found - were Sandi Mets and Rob Pike.If it's practical, I'm surprised not to see the js "wat" lightning talk (which I now can't seem to find...).
If it's more general "best of", I'd expect something like Guy Steele "growing a language" : https://youtu.be/_ahvzDzKdB0
Douglas Engelbart "the mother of all demos": https://youtu.be/yJDv-zdhzMY
Alan Kay "doing with images makes symbols": https://youtu.be/p2LZLYcu_JY Or, if that's too long, the much more condensed ted talk: "a powerful idea about teaching ideas": https://youtu.be/Eg_ToU7m1MI (Maybe that's not a "tech talk"?)
Rich Hickey "simple made easy" : https://youtu.be/34_L7t7fD_U
To name a few of the top of my head.
⬐ bcbrown> js "wat" lightning talk (which I now can't seem to find...)⬐ lgregg⬐ O_H_EI really enjoyed that. Thanks for finding it.Just watched Sandi Mets talk because of your comment, and it sucks to be forced to go study biology/sociology/literature after this ;)⬐ yaj54You're right those are all great talks (and fit in my definition of a tech talk). I just checked, and none of them are in my dataset, which I'll admit I'm surprised about. But they (and related ones) will make it into the next round.⬐ Tuna-FishThe issue seems to be that they are not typically watched on youtube. For example, the "simple made easy" linked above is a low-quality pirate youtube copy, the proper place to watch it is here:
If you haven't come across it yet, I recommend carving out some time for Growing a Language given by Guy Steele: https://m.youtube.com/watch?v=_ahvzDzKdB0Steele played a major role in shaping Java, and his perspective is that from a Lisp vantage point, so, naturally, he argues for the opppsite of you.
An important nuance is that where a language like Go or Java limits you to only sentences using nothing but the most common 100 words, Lisp makes it really easy to define other words and integrate them in your speech as though they always existed.
Of course, that ability may lead to a lack of canonical definitions and everyone may soon speak their local variant of the language, which can be both a good and a bad thing depending on your priorities.
⬐ lispmWell, Steele not only worked on Lisp and Scheme before, but he also co-wrote a C book and was working on High-performance Fortran.⬐ CMCDragonkaiI find that happening alot with the Elixir community. Over abuse of macros in every library. No idea what's canonical and what's something somebody just made up.
⬐ lioetersA classic that is relevant today as it was 20 years ago. Thank you for the repost, it's a good reminder to (re-)examine what I'm doing these days in a larger context."..plan for growth with help from users. This is a win for you because you have help. This is a win for the users because they get to have their say and get to bend the growth to their needs."
"Parts of the language must be designed to help the task of growth. A good set of types, ways for a user to define new types, to add new words and new rules to the language, to define and use all sorts of patterns — all these are needed."
⬐ pvgPreviouslies: https://hn.algolia.com/?query=%22growing%20a%20language%22&s...⬐ cntlzw20 years later. What does Guy Steele thing about how Java ended up? We still have no operator overloading, no value types. There are plans, sure, but Java grows very slowly. Good thing? Bad thing?Does anyone know if there is a follow up on this?
⬐ Cthulhu_⬐ garborgI think it's less relevant today, because we now have multiple languages running on the JVM - and I think that was always the most powerful feature of the Java program, the write once, run anywhere idea. Not so much the language itself, although at the time it was pretty good too.⬐ truncate⬐ exitcode__0IIRC Steele talks about languages which are extensible by users not just compiler writers. Although, JVM allows you to have multiple language implementation on top of JVM, it still doesn't make it easy to extend a language the way lets say Lisp can. He speaks of having primitives in language which allow programmers to extend language (macros?).⬐ gizmo385If macros and LISP on the JVM are what you're looking for, that already exists: https://clojure.org/⬐ truncateYes I know. I'm not talking about JVM specifically, but extensible languages. I'm a Racket programmer myself, which has much more powerful macro system. I didn't make my point clear. What I was trying to say was these languages are still not mainstream and understood by wider audience, and the argument Steele makes is still relevant. All this lisp and macro goodness existed back then as well.There is, Ada continues to evolve and grow - it can even directly interface with Java...⬐ kochthesecondThank goodness there is no operator overloading. I maintain 15 year old java codebases and am very happy they did not add user defined operators...⬐ jVincI always find this an odd reason to be against usable features. I have inherited codebases in extremely confined languages as have I inherited codebases in very permitting high-level languages Python, and never have I though "Thank good this language decided to restrict its reach in order to confine the programmer to a smaller subset which made it harder for him to mess up."Often have I though "My good, if only the language had better supported what the programmer is trying to implement himself through horrible hacks, then I wouldn't be sitting here trying to wonder exactly what mistakes he made that casuses everything to crash inexplicably."
⬐ sharpercoder⬐ willtimI guess the culture around a language matters significantly. For instance, there is quite a specific culture around the Rust community/language. The focus on the language ergonomics is also reflected in many packages. Same goes for the mutability/immutability aspect of code.A second example of this culture is the go language. I read a few repo's, and the same style of programming is seemingly applied throughout.
For the Java case, I can actually see operator overloading going haywaire over many codebases. The same as overengineering is a typical trait associated with Java.
Arithmetic expressions on BigInteger and BigDecimal currently look like an OOP parody. I cannot believe there are folks willing to defend this decision. Even Sun couldn't resist overloading '+'.This is one of my favorites. They played it for us when I was at https://www.recurse.com. I half appreciated it then, but it's gotten better with repeat viewings.⬐ namarieThank you for this! I'd forgot the name of the talk, and I spent some days looking for it, with no success...⬐ wontruefreethis was the first video handed to me when I started in Java⬐ mpweiherGreat talk, one of my inspirations.The "nub" (slightly edited):
"A language design can no longer be thing. It must be a pattern, a pattern for growth".
"My point is that a good programmer does not just write programs. A good programmer builds a working vocabulary. A good programmer does language design, though not from scratch, but building on the frame of a base language"
Oh, the paper if you don't want to watch the whole thing:
https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf
⬐ kristianp"nub" - I think you might mean "point" or "crux"?Main Entry: bottom line
Part of Speech: noun
Definition: indispensable content
Synonyms: basis, conclusion, core, crux, determination, essence, fiber, final decision, fundamentals, income, key point, last word, loss, main idea, main point, main thing, meat and potatoes, name of the game, net, nitty-gritty, nuts and bolts, point
⬐ mpweiher⬐ piinbinary> "nub" - I think you might mean "point" or "crux"?"This is the nub of what I want to say" is a direct quote from the paper/talk.
The language in the paper reminds me of Up Goer Five [0]⬐ sharpercoder> [...] A good programmer builds a working vocabulary. A good programmer does language design, [...]You see this more and more in "test languages" like cucumber. These languages more explicitly allow programmers to specify domain items and behavior, much more so then general programming languages like Jav, C#, js, etc. I'm currently experimenting with a piece of software that actually does have a specific domain language defined using ANTLR. I'm totally unsure of this will make any sense, but at least it is fun to do. One benefit I can see already is that I now have fully typed & typechecked logging :). Another aspect I'm experimenting with is using it as a replacement for sais "test languages".
You can find my grammar here: https://github.com/generateui/jsettlers-web/blob/master/jset...
Growing a Language, by Guy Steele:
⬐ ericfloVery glad someone posted this.⬐ shacharzAmazing talk, here's another great one: https://www.youtube.com/watch?v=_ahvzDzKdB0
Guy Steele, "Growing a Language", https://www.youtube.com/watch?v=_ahvzDzKdB0
Not from 2017, but Growing a Language
No, the idea is that your language should be able to express patterns in the language. Then they're not patterns any more—they're libraries! Working with an explicit abstraction from a library is far more pleasant than working with an implicit abstraction from a book.The way to achieve this is emphatically not adding patterns to the language spec. Instead, you want small and simple languages that can grow—languages flexible enough to add new abstractions that let you write code the way you want.
"Growing a Language"[1] by Guy Steele expounds on this and, as a bonus, is the single best technical talk I've ever watched. Highly recommend watching it[1] or, if you're pressed for time, reading the transcript[2].
[1]: https://www.youtube.com/watch?v=_ahvzDzKdB0
[2]: https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf
Slightly off-topic but does anybody know of other great talks with a quirky theme like this, where the talk is "set" in the 70s talking about the "future" (present)?I'll kick it off by submitting [Growing a Language] (https://youtu.be/_ahvzDzKdB0) by Guy Steele, where he speaks using only monosyllabic words and words he defines in terms of other monosyllabic (or previously defined) words.
⬐ spiralganglionThere's the Gary Bernhardt classic "The Birth & Death of Javascript"https://www.destroyallsoftware.com/talks/the-birth-and-death...
Guy Steele, Growing a Language: https://www.youtube.com/watch?v=_ahvzDzKdB0
Not a paper, but one of my favorite talkshttps://www.youtube.com/watch?v=_ahvzDzKdB0&t=642s
Growing a Language by Guy Steele (co-inventory of Scheme). Brilliant speech about how to grow languages and why it's necessary. Languages that can be grown by the programmer, like Lisp or Smalltalk are better than languages that fixed like most others, this is why.
⬐ NoneNone
YouTube link for those interested: https://www.youtube.com/watch?v=_ahvzDzKdB0
So basically, the Guy Steele approach to cooking
That, in turn, reminded me of Guy Steele's "Growing a Language" [1] speech on programming language extensibility at the 1998 ACM OOPSLA conference.
Smalltalk has been very influential in other ways, especially on Ruby. But yes, it would be great if more languages borrowed the "small simple core" bit (possibly adding some syntactic sugar, like ML does).On the other hand, it's possible to make (core language + standard library) too small. A particularly bad thing to leave out is a module/separate compilation system, ensuring that a zoo of incompatible module systems will grow up.
You may enjoy Guy Steele's talk "Growing a Language": https://www.youtube.com/watch?v=_ahvzDzKdB0
Guy Steele's talk, "Growing A Language", is very good: https://www.youtube.com/watch?v=_ahvzDzKdB0
⬐ kaelukaYes, essential viewing!⬐ kaelukaYes, essential viewing!
I'll just leave this here:* Growing a Language, by Guy Steele
⬐ jeremiepI loved that talk!I especially loved the moment when I finally understood the point he's trying to make is applied to the writing of the very talk he's giving.
The logical extreme of your argument is to make everything a `div` with classes.While possible, the main issue with that model is that it provides no encapsulation strategy. Encapsulation is one of the core tools for programmers for building complex programs, so having first class support for that in the templating language suddenly makes a lot of things easier.
Without encapsulation, a lot of things become more frustrating. Event bubbling has to be micro-managed. Dev tools are less useful. It becomes even more frustrating to deal with conflicting CSS IDs.
Steele's Growing A Language[0] talk specifically points to encapsulation as the core building blog for programs. Given how HTML is used nowadays (React + Angular are both "HTML as program layouts" models), not having encapsulation is a crutch
⬐ erikpukinskisFor me the logical extreme is "use the most basic control structures you can get away with". And it's easy (and useful) to use `a` tags and `span` tags and even `p` and `h1` tags every now and then. Also, `canvas` is quite useful, and `input` not to mention `script`, `link`, ...Actually, now that I think about it, there are lots of tags I use that aren't `div`. Writing the shims to reimplement all of those is exactly counter to what I am suggesting. I am saying, use what's there unless you have a really really good reason.
> Without encapsulation, a lot of things become more frustrating.
I'm not talking about encapsulated vs. raw, I'm talking about two things mostly:
1) declarative vs imperative.
2) bundled frameworks vs single purpose tools
Angular is a huge monolith that one must boot and then understand, because the way it does work for you is by having you declare things correctly on the filesystem and in magical scopes.
Jquery is bundled, but it's imperative.
Webpack is declarative, but it's not bundled.
I have no problem with tooling I just think the way we are designing tools is going entirely in the wrong direction.
The general question to ask is: how many systems do I need to understand in order to be able to describe what this tool I am using will do?
If the tool is Rails, the answer is "there is no end to the number of systems you need to understand in order to be able to describe what this Rails app will do".
If the tool is a PHP binary, the answer is much narrower.
> what's that one talk that changed the way you think and you feel everyone needs to see?Growing a Language by Guy Steele.
⬐ Jtsummershttps://www.cs.virginia.edu/~evans/cs655/readings/steele.pdfA write-up of the same talk. Fantastic read and watch.
⬐ chubotThis is a great talk, but what he was advocating never came to pass. He wanted to add 3 things to Java:Generic types are the only feature that made it (not without some controversy).- operator overloading - small value types on the stack (for vectors, rationals, etc.) - generic typesC++ has all three features. I suppose there is some success in games and graphics using overloaded operators on vector types. But otherwise it doesn't seem like a huge win, or something that is critical for the design of a language.
Python has operator overloading. I never really use it, but I guess it did allow NumPy and Pandas to exist. And TensorFlow uses it.
Perhaps it boils down to the fact that Java is more of a business language, and C++ and Python have more mathematical applications, which require richer algebraic expressions of many types. But I suppose if Java had gotten operator overloading, it may have been used more for scientific computing.
Perl 6 and Racket seem to be the languages that really allow creating your own language. But actually I heard Larry Wall say that they want to provide so many little languages within Perl 6 that users don't need to invent their own. Because this often makes it harder for others to read your program.
⬐ desdiv⬐ epidemianValue types is coming to Java 10, and Guy Steele is one of guys making it happen.Thanks for posting this; it's my favourite talk too :)BTW, does somebody know of (or have) a better quality version of this talk? The one on YouTube has some annoying audio cuts. There used to be a copy on Google Video[1], which i don't remember having the same issues.
As some people like to point out, I'd also like to remind that in 1968 Algol had:Given that many mainstream languages don't offer even what Algo68 had, I personally understand how a Go developer might thing that "nothing is new under the sun" since the 80's. After all, Go ignores all progress in programming languages for the last 40 years.- user defined record types - user defined sum types - switch/case statement with support for sum types - unified syntax for value and reference types - closures with lexical scoping - parallelism support - multi-pass compilationI recommend watching "Growing a Language", a legendary presentation by Guy Steele: https://www.youtube.com/watch?v=_ahvzDzKdB0
I do love the attempts of Go developers to rationalize Go's choices. But in the end it will end up being a hated language, universally recognized as a net negative in the industry. But that won't stop the working programmer from doing the same mistake again and again.
⬐ danmuxI'm no language historian, but I did limit my timeframe to my personal experience of 36 years of development for a reason. There was necessarily incredible research in the 20 years prior to that, which made it into useable languages, of course this is no hard cutoff, just an arbitrary personal choice, and I am happy to stand corrected. My point was simply that at least in the languages that make up 2σ of all code running in production in the last 20-30 years very rarely do they include "language" features that did not appear as truly innovative sometime before that. It may be argued that simply including some prior research in a useable language is innovative, or that the incremental improvements are themselves innovation, but then we are bogged down in semantics. In summary every time anyone in recent years has claimed to be innovating in language design someone else counters it with prior art, and that Go never pretended to be innovative in this direction. Given the lineage, and experience of the Golang authors it is more likely, in general that they considered and rejected, rather than ignored.⬐ snaky> Go ignores all progress in programming languages for the last 40 yearsThat's not unusual at all. Look what Fran Allen said about previous language from those guys - https://news.ycombinator.com/item?id=11578995
⬐ jacques_chesterThe most famous writeup, discussed here when it emerged 7 years ago, was "Go vs Brand X".⬐ _ak⬐ mixedCaseAnd where is Algol now? It's dead. Theoretical superiority on paper is worth absolutely nothing when there is no usable implementation for modern computing environments out there.This article was written to make Go look bad and unoriginal, but it inadvertently proves that Go is Algol's legitimate successor exactly _because_ it has all these features _and_ a working implementation that is available for wide variety of architectures and operating systems.
⬐ jacques_chesterI think Pascal (and Modula and Oberon) are more legitimate successors to Algol.I wasn't aware that all of those working implementations had stopped working.
Popularity is just one dimension a language can be placed on. Java utterly dominates the volume of new code being written in regular industry and has most likely done so for the entire lifetime of Go.
And this says little about their other relative virtues.
⬐ _akFun fact: one of the Oberon-2 developers is also one of the principal developers of Go. Learn your PL history.⬐ snakyI think it could easily be INTERCAL (and INTERCAL#, of course) dominating the world now, if Sun, IBM and other giants choose it instead of Java and pushed it with the same amount of force.>After all, Go ignores all progress in programming languages for the last 40 years.I've seen this meme being spouted so much every time Go's mentioned it's ridiculous.
No, piling up feature upon feature is not progress otherwise we wouldn't be using anything but C++.
Go is a language you pick for the right situation. If it's not enough for what you're trying to do, go for a different one instead of trying to expand in the wrong direction leaving you with warts, like Java's done, C++'s done, Python, JavaScript etc... which you will have to end up avoiding in order to write performant and clear code, counting on luck not to have to deal with code that abuses those features to create anti-pattern upon anti-pattern.
⬐ AdieuToLogicIs it a meme when it is true? To support this question, witness the statements of Rob Pike[0] below.>After all, Go ignores all progress in programming languages for the last 40 years. I've seen this meme being spouted so much every time Go's mentioned it's ridiculous.---
Regarding the utility of supporting first-order functions[1]:
---I wanted to see how hard it was to implement this sort of thing in Go, with as nice an API as I could manage. It wasn't hard. Having written it a couple of years ago, I haven't had occasion to use it once. Instead, I just use "for" loops. You shouldn't use it either.Regarding progress in programming languages[2]:
And[2]:One thing that is conspicuously absent is of course a type hierarchy. Allow me to be rude about that for a minute.---Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive.The part about "particularly inheritance and subclassing and all that" is ironically a meme spouted by Go's community so much it is, if you'll pardon my borrowing your description, ridiculous. For the curious, there are many community "Go-isms" explainable by the Pike talk[2].
Even a casual reading of the "list of significant simplifications in Go"[1] (35 in all) is enough to reasonably support the "ignoring all progress" position.
Of course, YMMV.
0 - https://en.wikipedia.org/wiki/Go_(programming_language)
1 - https://github.com/robpike/filter
2 - https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
⬐ mixedCase> [1]:I don't see how that helps your argument. For loops are more than enough for that task, it's easily readable and universal.
And Go does support first-class and higher order functions so not sure what you're talking about here.
> [2]:
How's ditching inheritance in favor of composition "ignoring the last 40 years"? It's the biggest example together with goroutines that proves that phrase is a meme, and that we've learnt a lot on typing best practices as an industry over the past couple decades.
And as an added bonus, another thing that's a good example of Go actually looking back and improving upon what's been done before is the select statement. Most popular languages fall through by default with the switch statement.
Outside of examples on the internet, I can't recall right now the last time I've seen a switch statement in the wild that didn't break at the end of every case. Making the case (pun not intended) for a fallthrough statement and having switch/select break by default.
I'm a fan of Guy Steele's Growing a Language, a talk about programming language design where he limited himself to using mostly only single-syllable words: https://www.youtube.com/watch?v=_ahvzDzKdB0
⬐ e12eThis seems like a good companion (probably as a sequel) to:"Richard Feynman - Computer Heuristics Lecture": https://www.youtube.com/watch?v=EKWGGDXe5MA
In general, Feynman might be a poster child for using simple language to explain complex things.
⬐ seanmcdirmidNot to mentioned hand crayon drawn transparencies.
This idea reminds me of an amazing talk by Guy Steele: https://youtu.be/_ahvzDzKdB0He starts the talk by assuming monosyllabic words as his primitives and builds up the words he needs to use to give the talk by providing definitions for them first.
⬐ kogusThanks for that, I really enjoyed it. Back when Java was new and cool...⬐ NoneNone
Agreed. It makes me think of the amazing Guy Steele talk "Growing a Language."
I recently watched Guy Steele's "Growing a Language" talk. It's very much related to jmoiron's post here, and is worth a watch despite its age:https://www.youtube.com/watch?v=_ahvzDzKdB0
Steele's commentary on "Worse is Better" seems to me to be a better representation of the original essay than the one expressed here about Go. Steele says:
"The gist of ['Worse is Better'] is that the best way to get a language used by many persons is not to design and build 'The Right Thing,' because that will take too long. In a race, a small language with warts will beat a well designed language because users will not wait for the right thing; they will use the language that is quick and cheap, and put up with the warts. Once a small language fills a niche, it is hard to take its place."
In other words, the lesson of 'Worse is Better' is that getting a 'good enough' thing to market, and benefiting from the network effects of its widespread use, will always beat getting the 'the really good' thing to market in the same category, because the cost of delay is the loss of (community) network effects. The illustrative example here is UNIX and C, but it can be easily cross-applied to more recent projects.
From that vantage point, Go isn't a good example of 'Worse is Better'. It occupies the same niche as C, but was delivered nearly 4 decades later. It seems to be a "second edition of C" designed with very explicit goals of correcting specific deficiencies of C as a systems programming language, but without the scope creep that characterizes many "second systems".
Other languages -- like Python and Scala -- occupy completely different niches and have already achieved similar scale of network effects.
The rest of Guy Steele's talk is worth watching, because his high-level point is that the languages that win aren't the simpler ones, or the ones with the simplest/best design, but instead are the "growable" ones that get to market.
For example, from Steele's vantage point, the success of a programming ecosystem like Python's would be evaluated as follows: it isn't that it has the right level of simplicity/dynamism, or an appropriate programming paradigm. That Python made good decisions there helps, but they aren't the key ingredients. Instead, its success is that it shipped in 1991, evolved over time to keep up with programming trends, that it has an awesome 'import' statement, and that programmers feel they can 'grow' the language through libraries (e.g. Django for web development, Pandas for data analysis) without waiting on the slow core language or stdlib evolutionary process.
I recently watched Guy Steele's "Growing a Language" talk. It's very much related to jmoiron's post here, and is worth a watch despite its age:https://www.youtube.com/watch?v=_ahvzDzKdB0
Steele's commentary on "Worse is Better" seems to me to be a better representation of the original essay than the one expressed here about Go. Steele says:
"The gist of ['Worse is Better'] is that the best way to get a language used by many persons is not to design and build 'The Right Thing,' because that will take too long. In a race, a small language with warts will beat a well designed language because users will not wait for the right thing; they will use the language that is quick and cheap, and put up with the warts. Once a small language fills a niche, it is hard to take its place."
In other words, the lesson of 'Worse is Better' is that getting a 'good enough' thing to market, and benefiting from the network effects of its widespread use, will always beat getting the 'the really good' thing to market in the same category, because the cost of delay is the loss of (community) network effects. The illustrative example here is UNIX and C, but it can be easily cross-applied to more recent projects.
From that vantage point, Go isn't a good example of 'Worse is Better'. It occupies the same niche as C, but was delivered nearly 4 decades later. It seems to be a "second edition of C" designed with very explicit goals of correcting specific deficiencies of C as a systems programming language, but without the scope creep that characterizes many "second systems".
Other languages -- like Python and Scala -- occupy completely different niches and have already achieved similar scale of network effects.
The rest of Guy Steele's talk is worth watching, because his high-level point is that the languages that win aren't the simpler ones, or the ones with the simplest/best design, but instead are the "growable" ones that get to market. For example, from Steele's vantage point, the success of a programming ecosystem like Python's would be evaluated as follows: it isn't that it has the right level of simplicity/dynamism, or an appropriate programming paradigm. That Python made good decisions there helps, but they aren't the key ingredients. Instead, its success is that it shipped in 1991, evolved over time to keep up with programming trends, that it has an awesome 'import' statement, and that programmers feel they can 'grow' the language through libraries (e.g. Django for web development, Pandas for data analysis) without waiting on the slow core language or stdlib evolutionary process.
Reminds me of this[0] talk by Guy Steele where he explicitly defines any word outside of a given set before he can use that term in his speech. Interesting language exercise, definitely worth a watch![0] https://www.youtube.com/watch?v=_ahvzDzKdB0&feature=youtu.be
This is the text from a very clever 1998 OOPSLA keynote, which can be viewed here: https://www.youtube.com/watch?v=_ahvzDzKdB0
I get a 403 on this link. The running theme is that Guy Steele avoids using multi-syllable terms in the talk without defining them first. Getting only the slides dampens the impact a lot. Video version: https://www.youtube.com/watch?v=_ahvzDzKdB0
⬐ rbshadeloh man, the reveal is so good though! I hope people get a chance to watch before discovering the theme :)⬐ mikeashDude, spoiler alert!
The contrast between simple and complete languages was best (imho) expressed in Guy Steele's convoluted 1998 OOPSLA talk, Growing a Language.The whole talk is expressed in terms of words of one syllable.
⬐ jasodeI'm familiar with that talk and it's a good one but Guy Steele's main thesis is not showing the difference between small/simple and large/complex.Instead, his main point is that a successful language can start small and it is inevitable[1] that it will grow into a larger one. Therefore, let's plan on its growth from user feedback. To help the thinking, he defines a sort of "meta framework" for the directions a language can grow. The idea is that the growth can be more systematic instead of a random chaos of adding keywords and syntax (e.g. PHP).
My message is orthogonal from Steele's. I'm saying that evangelizing that a "language X is simple" in terms of a formal language spec is not useful to real-world programmers. The working programmers actually care about holistic simplicity/complexity that combines Formal specs and Informal idioms.
[1](my description not his because he used 1-syllable words)
⬐ NoneNone⬐ achamayouIt's Guy Steele, with an e.⬐ None⬐ tallesNone⬐ pvorbI know. I entered an entirely different title: "Growing a Language (presentation by Guy Steele, 1998)". I'm not sure how and why it was changed.⬐ dangThe 'e' thing was just a temporary typo by a moderator. The title change was presumably because "presentation by" is redundant (and not in the original).But mostly we take the author's/presenter's name out of titles, in keeping with HN's emphasis on content over personalities.
⬐ sitkackGuy Steele isn't a personality and his content is always king.⬐ dang⬐ agumonkeyIndeed, which is why it can speak for itself.May I ask how many mods are working on HN ? I naively thought you were the chosen one.When I send nobody cares :(⬐ pvorb⬐ seanmcdirmidSorry, I didn't look for other submissions here on HN. Just thought it was worth submitting. It's likely your submission also has not been the first.⬐ dangIndeed: https://hn.algolia.com/?query=growing%20a%20language&sort=by....It was fine to repost, because it hasn't had significant attention in the last year. Also, it's one the best talks ever.
I saw a live version of this when I was a grad student (not the original talk at OOPSLA, but he re-gave it a lot at some universities). It was fascinating to see what could be done with hand drawn transparencies; you have to give GLS lots of style points!
This reminds me of Guy Steele's 1998 talk "Growing a Language" (https://www.youtube.com/watch?v=_ahvzDzKdB0). It's really worth watching.
He gave a brilliant talk about it: "Growing a Language"[1].The idea is to make languages that grow—ones that provide a small, uniform core that can be extended by the user. Ideally, these extensions feel like first-class citizens: things added by users should feel on par with built-in language features.
It's still one of the best technical talks I've ever come across.
⬐ agumonkeyHe even humorously implied that a growing language shrinks, by replacing many specific constructs with a single general one.
I think we can build it however closed or open we would like it to be. The sharing of source code I suspect is more social than technical, therefore I don't expect much change.Java Applets, Flash, SilverLight always was at a disadvantage, not being native to the browser runtime. Startup time and the need for a "plugin" hurt them. And they all kinda sucked in their own way. I hoped for a long time that Dart / native DartVM to Chrome could make a stride, but sadly they were fighting uphill battle against the sheer volume of JS developers resisting change. I'm convinced that it's never about the language[1], but the VM and it's abstraction layer. We need a layer that we can compile JavaScript(/HTML/CSS), Scala, Haskell, C#, F# etc. down to, not more languages.
I wonder how many man-years has been wasted on vertically aligning div's inside a div. :)
[1] Guy Steele, amazing talk on "Growing a Language", https://www.youtube.com/watch?v=_ahvzDzKdB0
I personally like to think of simplicity as the opposite of entangled / intertwined, which is often at odds with easiness / familiarity. Rich Hickey has a very good presentation about it. I like doing that because then simple and easy are expressing 2 different things, both desirable but kind of orthogonal.> overall simplicity and consistency matters more
Go took some good steps towards simplicity. OOP as present in languages such as Java is overrated and a primary reason for the complexity created.
We could use some variations for this need for ad-hoc polymorphism that we have. Unfortunately Go doesn't go far enough by not addressing the need for type-classes or something similar. And the language doesn't have to end up with a type-system as sophisticated as Haskell if you want type-classes. Clojure has a similar mechanism called protocols and yet it doesn't have OOP in the traditional sense, Scala has implicit parameters solved at compile time that can be used to model type-classes and overall type-classes are a simplification because they cleanly separate data from behavior.
Go also provides those channels as a more useful abstraction than plain threads. That's cool and all, but channels are not enough and a language should allow other people to evolve the language with even more abstractions for dealing with concurrency and parallelism, because there's no silver bullet. On top of the JVM people have built frameworks and libraries for actors, agents, csp, futures/promises, parallel collections, light-weight threads, STM, reactive programming / streams and most other things you can think of and the best a language can do is to allow evolution.
One should not confuse a small set of features with simplicity. Java was also a language that refused in the beginning to have generics and then in version 5 it got an abomination - as in generics that don't specialize for primitives and that solve co/contra-variance by means of use-site variance and freaking wildcards, instead of the much saner declaration-site variance. This happened because backwards compatibility is important and an established language needs to be evolved by providing a sane migration path. Go is slowly losing its window in which it can make bold changes.
Going back to your original point, a small set of features is bad if users cannot efficiently extend the language because the needed features aren't included. Having a small set of features is great, but it matters what those features are. I invite you to watch Guy Steele's "Growing a Language" presentation on this point, it's an astonishingly good presentation: https://www.youtube.com/watch?v=_ahvzDzKdB0
⬐ NateDadExtending the language is exactly what the go authors and most experienced gophers don't want. I shouldn't have to learn your whole DSL / language extension to use or even read your code. Go intentionally disallows this so that everyone writing go is using the same language, rather than some subset, or god forbid superset, of the language.⬐ bad_userWell, it's a wonder that you're speaking English then, since English is routinely extended by means of new words and metaphors. Look, you just used "DSL" and "code", words part of a domain specific language that regular folks do not understand, plus "subset" / "superset" which require basic knowledge of set theory.Besides, every time you create a new type or interface, you just extended your language with a noun or adjective and every time you come up with a function, you just created a verb. And I have to learn your nouns and your verbs to understand your code, even if you try explicit naming that don't really say anything (my personal favorite being variations on "processItems").
Go is not the first language to take this approach, it won't be last last either. Unfortunately people never learn and it feels like groundhog day, the movie.
⬐ NateDadThere's a difference between adding nouns and verbs, and changing the very structure of the language. If I say "I like to flargle my pofdin in a huffalop" you can still pick out the verb and the nouns, but if I say "#&_35( bar mdfsgh" you can't even tell if what I wrote is valid English.⬐ bad_userWe aren't talking about changing the structure of the language, but about adding a feature to the language, generics, that would make it easier for people to build reusable libraries, especially libraries that treat functions (the verbs) as values that can be passed around, reused and still keep the static type safety of a language that is static.Thing is, if you want a language without generics, then you want a dynamic language, because a static language without generics is overkill for building reusable stuff. Go's structural typing is cool and all, that's ad-hoc polymorphism done tastefully, but we are talking about a different kind of polymorphism here with different use-cases.
Watch that presentation, it's genius.
⬐ NateDadWhen you said "a small set of features is bad if users cannot efficiently extend the language because the needed features aren't included" I assumed you meant something like operator overloading or macros or compile-time templates like in other languages. It seems like I was misunderstanding you. If all you meant was "a small set of features is bad if users don't have generics", then yes, my earlier response was not appropriate.However, I would still have to disagree, given that I have written a lot of very useful code in Go, much of it quite reusable (without interface{} or reflection).
I did go click on that link and started to watch the presentation, FWIW. It's too long for me to watch now, but it definitely looks interesting, so I'll try to watch it in the next couple days. Thanks for pointing it out to me.
The argument on looking at Go's trend in isolation is a really weak one. Let's also look at Clojure in isolation: https://www.google.com/trends/explore#q=clojure - and oh look, Clojure runs on the JVM.> If I were a developer getting started today, I’d make a career bet on Go
Advice on picking languages as career bets are especially weak. In my experience, careers are being built on being able to get stuff done and in the long list of things that a developer has to learn to get stuff done, the language itself is very uninteresting considering everything else combined. Personally it takes me 2-3 weeks to become functional in any new programming language, I've worked with half a dozen thus far in production and I played with another dozen in my free time. The language itself is like a drop in an ocean, compared to more fundamental knowledge that makes one productive, like math, algorithms, concurrency and parallelism, hardware, usability, domain specific knowledge, libraries, frameworks, being able to interact with a community, etc...
> Go is a simple language by design. You can read the spec and other materials on the Golang website and start being productive in a single day
Simplicity in the language doesn't translate to simplicity in the solutions that you're building. This is a fundamental divide, since often people are mistaking simplicity for easy, for being familiar. It's not in the original sense of the word - simplicity is the opposite of complexity, which means interwoven or entangled and in the context of software it means building reusable / modular components, that do one thing well and that can be stacked / connected together to build bigger solutions and to keep complexity manageable.
Go is in fact anti-simplicity. Its lack of generics, given its static typing, is a really good example of a design fuck-up, since for building reusable higher-level abstractions, one really, really needs generics and this is an objective fact - note that we aren't talking about dynamic languages here, which don't care about static typing or for being close to the metal. There's no point in denying that and Go will end up like both Java and C++, both of which didn't have generics in the beginning - and so it will end up with a half-baked solution with lots of corner cases and that people will hate, until the next language comes along also lacking generics, because "simplicity", repeating the cycle ad-nauseam.
In fact a programming language is supposed to be extensible, because both in natural speech and in our systems, we are extending our language all the time to manage complexity. If this gives birth to features that are harder to learn, that's a freaking drop in the ocean compared to all the shit that we must do when implementing complex business logic. I recommend watching Guy Steele's "Growing a Language" presentation, it's very enlightening: https://www.youtube.com/watch?v=_ahvzDzKdB0
But then again, extensible languages and higher-level abstractions are raising the bar to entry, which often goes against the other generally accepted solution for managing complexity, which is to hire more average Joes that can sit in a chair and type.
> Simple languages are easier to learn.
Familiar languages are easier to learn. There, fixed the typo. And if you're only learning familiar stuff, then you're not learning anything new ;-)
I keep going back to Alan Kay's quote which will be relevant for a long, long time: "Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves."
⬐ Artemis2I love Go because it fits in my head. There are tons of applications for which Go won't be the best fit, but Go is fantastic for some others.⬐ bad_user⬐ minaandrawosI don't disagree with that. If Go suits your needs, then good for you. My rant is related to my general dissatisfaction with the status quo and personally I expect more from new languages.⬐ swahEveryone loves that. But most people also want to write algorithms that work on different kinds of collections.I think its just a matter of Go arriving at a good proposal for generics.
I agree that generics is bound to become a limitation as Go get more used in APIs and similar use cases. For now, if anyone interested, here is a way you can get generics like functionality with Go: http://blog.jonathanoliver.com/golang-has-generics/⬐ frowaway001⬐ _dpsDid you actually _read_ the article?> There's no point in denying that and Go will end up like both Java and C++, both of which didn't have generics in the beginning - and so it will end up with a half-baked solution ...[I take no position on whether Go should have generics]
Go has one thing that neither of the other languages had: Rob Pike. This is not meant with any disrespect to Gosling or Stroustrup, and I don't know Pike personally, but he has a reputation for sticking to his convictions even (especially?) when they are contrary to "market pressure".
Guy Steele Jr.: Growing a Language https://www.youtube.com/watch?v=_ahvzDzKdB0
What do you say to people like Guy Steele who believe that small languages that can be grown by their users are the way forward, and do not want to pay to use a closed source programming language, ever?(fyi I'm referring to this famous talk he gave http://youtu.be/_ahvzDzKdB0 )
⬐ taliesinbThanks for the talk, I'll watch it tomorrow (gotta catch Snowden's interview at 10am).But in the meantime, I'd say: pick your battles.
Many developers, including me, moved from Linux to OS X so they could get on with their lives.
And we pay for things much lower on the abstraction hierarchy: CPUs and GPUs and their proprietary IP, physical hardware, various industry-group protocols and standards, OSes in some cases, hosting.
And we know from experience that the whole hierarchy tends to move down as we build on it -- maybe the time has come for that to happen to languages, too.
If, in time, the things that WL is doing inspire higher-level, free languages to raise the abstraction (and semantic) bar, I think we'll all benefit. For now, we can only do what we do because we're a private company.
http://www.youtube.com/watch?v=_ahvzDzKdB0This video is relevant. Amazing talk.
I agree entirely and>This kind of annotation hell is indicative of the inflexible and unextensible nature of Java.
This line made me think a lot, it reminded me of this amazing talk by Guy Steele[1], an absolute must for every language developer (or software developer in general, really). It's ironic that he's mostly referring to Java the language itself when he talks about "flexiblity" and "growing the language", where ~10 years later we all know that Java is becoming a messy inflexible deprecation hell. Still a solid talk nonetheless!
That's really unfair to Haskell. What are things like Hoogle if not tools, uniquely[1] enabled by Haskell's type system? All the basic IDE-like frills exist too, if you really want them. And now, with the advent of deferred type errors and holes, Haskell's type system is getting even more interactive. The process is quickly moving from writing code and running it through a compiler to having an ongoing conversation with the typechecker as you build up your program.More importantly, types can go well beyond catching errors or tooling. Types can actually make your code more expressive and they can push your design forwards.
For the first, the simplest example is with Haskell's typeclasses: you can't easily write something like Show or have something like Haskell's flexible numeric literals without types. This allows you to grow[1] Haskell in ways that are even difficult in Lisp! For a more practical standpoint, I've found certain libraries to be much harder to reproduce without typeclasses, most crucially QuickCheck.
The second idea is slightly more abstract. As somebody else put it, types are like gravity sources: we place them strategically in our design space, and the rest of the code falls towards them. More concretely, coming up with the types to represent some domain often really helps in writing the code for it. Sometimes, once you've got the general framework of the types, the actual programming just feels like systematically filling in the blanks. More generally, the effect is nowhere near that pronounced, but the types do help shape everything else. In a sense, types help you constrain the set of possible programs at the outset, giving you fewer options to consider as you go along.
Oh, and I guess there's the performance thing. This includes both low-level optimizations (C++ or even C-style stuff) and high-level ones (like rewrite rules). Optional type systems seem to give up on these as a matter of principle. I don't believe static types are strictly necessary for good performance, but empirically they seem to help. Most languages with really good compilers are statically typed.
I think the idea that types just exist to catch type errors is one of the most unfortunate common misunderstandings about type systems. It really scares people away before they can learn about all the other benefits a good type system confers.
[1]: Okay, not really uniquely, but it's close. I've seen Hoogle-like tools for OCaml but not for Java or C++, much less something like Python. I'm not sure how useful or general they could be for other languages.
[2]: Easily my favorite CS talk: http://www.youtube.com/watch?v=_ahvzDzKdB0
⬐ seanmcdirmidI saw Growing a Language in person in 1999 (he redid the talk during Utah's yearly Organick lecture). As for your arguments about Haskell, I find this very useful; thanks for the reply. I am quite interested in type systems for tool purposes, and grocking whether even code completion is possible for Haskell is quite a chore. Hoogle is exactly the tool I'm competing with :)
Yes, there are differences. Fundamentally, the Haskell type system is not just about correctness: it actually makes the language more expressive! You simply wouldn't be able to do some very awesome typeclass things with a system like this, for example. I've found things like QuickCheck--or even just using different monads--to be much more awkward without typeclasses.The way this works is by allowing you to overload a function on its return type. It's very easy to imagine a function overloaded on its argument; for example, a hypothetical:
This function can take an argument of some sort and returns its string representation. Many languages support this sort of overloading--it's very straightforward. But what about the symmetric from_string function?to_string :: a -> StringNow this is trickier! Most languages would force you to be more explicit about which function you're using, so you would have to write something like Double.from_string or Integer.from_string and so on. This loses the symmetry inherent in the types and forces you to add a whole bunch of redundant noise to your code. Very reminiscent of Java's Foo i = new Foo()!from_string :: String -> aWith typeclasses, you can actually write a from_string function like this. Moreover, it works using exactly the same type inference system you already know and love! In practice, this means that the overloading is very straighforward: it just chooses whatever type you need. And since the type system is pervasive, you know that it will always choose the right instance if possible: if you use from_string expecting an int, it can't accidentally use Float.from_string because that wouldn't even typecheck.
This turns out to be useful in a whole bunch of different places. One of my favorites is with numeric literals: in Haskell, numeric literals are polymorphic. This means that if you write f 10, 10 will be the right type--integer, double, arbitrary precision integer, whatever--for the function. No more arbitrary sigils after your numbers (like 10L). More importantly, this makes new numeric types feel just like native ones[1]. So you can use normal literals with rational numbers or constructive real numbers or 8-bit words or symbolic bitvectors (most of which I've used in real code). These types no longer feel like second-class citizens!
Haskell type inference is even more useful than that though. Not only does it reduce the burden of using the type system, it also actually enables new workflows. Instead of giving the compiler your types and waiting for it to show you where they're wrong, you can actually just ask the compiler what type it expects. You can use this to interactively grow your program, informed by your types. The newest version of GHC will make this more convenient by adding a feature called "type holes", which lets you leave holes in your code and will tell you the types of those holes. Once this gets good editor support, it'll be incredible.
The Haskell type system--partly because it's pervasive and partly because it controls effects--also makes some high-level optimizations like steam fusion possible. The basic idea is that it can rewrite multiple logical traversals over an array into a single tight loop. The crazy thing is that this optimization is actually specified by a library, and not built into the compiler! So there are actually a whole bunch of rewrite optimizations like this, most of which are only guaranteed to be correct thanks to the type system. Since they're somewhat tricky to debug even with all the existing guarantees, I don't even want to imagine what it would be like with a weaker type system.
Honestly, I think you would be missing out on most of the real advantages Haskell gives you. And for what? At least in my experience, you do not get much of a boost in productivity or expressiveness. Even without invoking the optional type system.
So yeah: lots of deeper tradeoffs.
[1]: Take a look at "Growing a Language", a brilliant talk by Guy Steele that goes into why it's important to allow new additions to feel just like native parts of a language.
⬐ pronAll true, but at least Clojure (I don't know about other dynamic languages) provides some this power with protocols (which are very efficient) and multi-methods. core.logic provides the missing pieces.> Honestly, I think you would be missing out on most of the real advantages Haskell gives you. And for what?
Forget about a static type system in particular: every bit of power you get from a language has a price. Sometimes the cost is performance and sometimes – and this is often a much higher cost – language complexity.
When choosing a programming language, you should not aim for the most powerful language, but for the one that gives you the power you need for a price you're willing to pay. Clojure strikes a pretty remarkable balance: a lot of power at a very low price (it's very simple, very easy to learn, integrates extremely well with legacy code, and can give you great performance when you need it). It is arguable whether Haskell gives you more power, but even assuming it does, this power comes at a much higher cost. Haskell is not easy to learn, and it's not simple to integrate with legacy code. The right question, I think, is how much are you willing to pay for extra power? Is extra power worth it?
⬐ tikhonjHaskell, fundamentally, is actually quite simple: it's just the lambda calculus. You could fit the typing rules on a single piece of paper, and the evaluation rules are even more trivial. It is very difficult to come up with a simpler model than the lambda calculus.Sure, it might be difficult to learn, but that's very different from being complex. Haskell is, if anything, different--but this is also why it's so much more expressive! I think this is a great example of Rich Hickey's distinction between simple and easy. Also, learning a language to some level of proficiency is an O(1) cost but the benefit is O(n) to how much you use it, so I really don't think you should consider that much.
Avoiding a language because it seems difficult to learn is just shortsighted.
Now, Haskell does have some complexity that other languages don't. But this is mostly in the compiler and runtime system: things like the incredible parallelism and concurrency features. There are languages that have much simpler runtimes, but Clojure ain't it: the JVM is probably the most complex existing runtime, full stop.
Legacy code, also, is more a matter of being on the JVM than language design. If you have a bunch of legacy code in C, it'll fit better with Haskell than Clojure. Calling out to native programs from the JVM is a real pain. The Haskell FFI, on the other hand, is relatively nice.
More generally, I think the idea that every bit of power has a price is not accurate. I agree that language design is going to be a complex optimization problem against several axes. However, this does not mean every improvement along one carries a cost along another--not every language is along the Pareto frontier! Since all languages are imperfect, you can get strict wins.
Also, as I understand it, protocols do the easy part I talked about. Certainly useful, but not very interesting. I do not see how you would accomplish return type polymorphism in Clojure--something like the from_string function or polymorphic numeric literals--because the information needed is simply not there. I'm not saying it's impossible, but I've certainly never seen it done.
That really is a great talk! It's on Youtube too: http://www.youtube.com/watch?v=_ahvzDzKdB0
> it's entirely possible to make insightful points without sophisticated language."Growing a Language" by Guy Steele is an extreme example of that.
Summary of the links shared here:http://blip.tv/clojure/michael-fogus-the-macronomicon-597023...
http://blog.fogus.me/2011/11/15/the-macronomicon-slides/
http://boingboing.net/2011/12/28/linguistics-turing-complete...
http://businessofsoftware.org/2010/06/don-norman-at-business...
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...
http://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-R...
http://en.wikipedia.org/wiki/Leonard_Susskind
http://en.wikipedia.org/wiki/Sketchpad
http://en.wikipedia.org/wiki/The_Mother_of_All_Demos
http://io9.com/watch-a-series-of-seven-brilliant-lectures-by...
https://github.com/PharkMillups/killer-talks
http://skillsmatter.com/podcast/java-jee/radical-simplicity/...
http://stufftohelpyouout.blogspot.com/2009/07/great-talk-on-...
https://www.destroyallsoftware.com/talks/wat
https://www.youtube.com/watch?v=0JXhJyTo5V8
https://www.youtube.com/watch?v=0SARbwvhupQ
https://www.youtube.com/watch?v=3kEfedtQVOY
https://www.youtube.com/watch?v=bx3KuE7UjGA
https://www.youtube.com/watch?v=EGeN2IC7N0Q
https://www.youtube.com/watch?v=o9pEzgHorH0
https://www.youtube.com/watch?v=oKg1hTOQXoY
https://www.youtube.com/watch?v=RlkCdM_f3p4
https://www.youtube.com/watch?v=TgmA48fILq8
https://www.youtube.com/watch?v=yL_-1d9OSdk
https://www.youtube.com/watch?v=ZTC_RxWN_xo
http://vpri.org/html/writings.php
http://www.confreaks.com/videos/1071-cascadiaruby2012-therap...
http://www.confreaks.com/videos/759-rubymidwest2011-keynote-...
http://www.dailymotion.com/video/xf88b5_jean-pierre-serre-wr...
http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...
http://www.infoq.com/presentations/click-crash-course-modern...
http://www.infoq.com/presentations/miniKanren
http://www.infoq.com/presentations/Simple-Made-Easy
http://www.infoq.com/presentations/Thinking-Parallel-Program...
http://www.infoq.com/presentations/Value-Identity-State-Rich...
http://www.infoq.com/presentations/We-Really-Dont-Know-How-T...
http://www.slideshare.net/fogus/the-macronomicon-10171952
http://www.slideshare.net/sriprasanna/introduction-to-cluste...
http://www.tele-task.de/archive/lecture/overview/5819/
http://www.tele-task.de/archive/video/flash/14029/
http://www.w3.org/DesignIssues/Principles.html
http://www.youtube.com/watch?v=4LG-RtcSYUQ
http://www.youtube.com/watch?v=4XpnKHJAok8
http://www.youtube.com/watch?v=5WXYw4J4QOU
http://www.youtube.com/watch?v=a1zDuOPkMSw
http://www.youtube.com/watch?v=aAb7hSCtvGw
http://www.youtube.com/watch?v=agw-wlHGi0E
http://www.youtube.com/watch?v=_ahvzDzKdB0
http://www.youtube.com/watch?v=at7viw2KXak
http://www.youtube.com/watch?v=bx3KuE7UjGA
http://www.youtube.com/watch?v=cidchWg74Y4
http://www.youtube.com/watch?v=EjaGktVQdNg
http://www.youtube.com/watch?v=et8xNAc2ic8
http://www.youtube.com/watch?v=hQVTIJBZook
http://www.youtube.com/watch?v=HxaD_trXwRE
http://www.youtube.com/watch?v=j3mhkYbznBk
http://www.youtube.com/watch?v=KTJs-0EInW8
http://www.youtube.com/watch?v=kXEgk1Hdze0
http://www.youtube.com/watch?v=M7kEpw1tn50
http://www.youtube.com/watch?v=mOZqRJzE8xg
http://www.youtube.com/watch?v=neI_Pj558CY
http://www.youtube.com/watch?v=nG66hIhUdEU
http://www.youtube.com/watch?v=NGFhc8R_uO4
http://www.youtube.com/watch?v=Nii1n8PYLrc
http://www.youtube.com/watch?v=NP9AIUT9nos
http://www.youtube.com/watch?v=OB-bdWKwXsU&playnext=...
http://www.youtube.com/watch?v=oCZMoY3q2uM
http://www.youtube.com/watch?v=oKg1hTOQXoY
http://www.youtube.com/watch?v=Own-89vxYF8
http://www.youtube.com/watch?v=PUv66718DII
http://www.youtube.com/watch?v=qlzM3zcd-lk
http://www.youtube.com/watch?v=tx082gDwGcM
http://www.youtube.com/watch?v=v7nfN4bOOQI
http://www.youtube.com/watch?v=Vt8jyPqsmxE
http://www.youtube.com/watch?v=vUf75_MlOnw
http://www.youtube.com/watch?v=yJDv-zdhzMY
http://www.youtube.com/watch?v=yjPBkvYh-ss
http://www.youtube.com/watch?v=YX3iRjKj7C0
http://www.youtube.com/watch?v=ZAf9HK16F-A
⬐ ricardobeatAnd here are them with titles + thumbnails:⬐ waqas-how awesome are you? thanks⬐ ExpezThank you so much for this!⬐ X4This is cool :) Btw. the first link was somehow (re)moved. The blip.tv link is now: http://www.youtube.com/watch?v=0JXhJyTo5V8
Guy Steele's "Growing a Language". A very cool idea for a talk!
⬐ fmstepheI Second this nomination. I re-watch this talk about once a year. Very entertaining.⬐ mtrnImpressive convergence of form and content.⬐ kenjacksonGreat talk. One of the best. His talk with Gabriel, 50 in 50, is not as good, but still quite fun. Well worth watching, but it is much better in person than on video (saw it at HOPL):⬐ endgameSeconded. I saw it at YOW a few years back. If you get a chance to see it live, it is well worth it.⬐ seanmcdirmid⬐ kopfSteele (and Grabriel) are great at doing this talks, they are almost art. Which is why I wouldn't call them so much technical (even growing a language) as they are entertaining and perhaps a bit influential.You couldn't make it up - http://ahye.ventolin.org/s/zfSylv3i.png
⬐ ColinWrightAlways a favorite.Comments are closed on these previous submissions, so this is the best place to start a new discussion about this brilliant talk. You may want to read some of the previous discussions, so here are earlier submissions:
http://news.ycombinator.com/item?id=68918
http://news.ycombinator.com/item?id=92542
http://news.ycombinator.com/item?id=122989
http://news.ycombinator.com/item?id=150863
http://news.ycombinator.com/item?id=152311 <- 7 comments
http://news.ycombinator.com/item?id=626380
http://news.ycombinator.com/item?id=827107
http://news.ycombinator.com/item?id=2359174 <- 21 comments
http://news.ycombinator.com/item?id=3744125 <- 5 comments
http://news.ycombinator.com/item?id=4245680
Also, here's the PDF of the talk: