mkremins

This is a really poor selection of events. Even if you restrict “AI” to mean “LLMs and diffusion”, this timeline starts years too late to cover the complete history of GPT models alone; I first became aware of LLMs a bit after Talk To Transformer launched in May 2019. Super frustrating.

Really cool! I also made some blackout poetry tools back in like 2019, maybe of interest… https://mkremins.github.io/blackout/interactive

This is exactly my feeling. I was on both pretty early, and was more excited about Mastodon in the early days – but when I started seeing the pattern of hackers who’d built cool new features being flamed off the platform, it became clear to me that the Mastodon community didn’t actually want to be part of the open internet. Which is fine with me, but not at all the kind of thing I’m on social media for. I’ll take my chances with Bluesky.

Here's an open access link: https://escholarship.org/uc/item/3rm1w0mn

Academics don't make any money from sales of paywalled journal articles. If you click a link to a journal article and hit a paywall, it's usually because whoever shared the link has institutional access to the journal and forgot that the paywall was there (since it effectively isn't for them.)

He also gets a fair amount of attention from game designers, especially those of us who have one foot in academia and one in the industry / "real world".

You might get more results searching for "deletionism vs inclusionism", which seems to be the most widely used name for the debate: http://en.wikipedia.org/wiki/Deletionism_and_inclusionism_in...

Bret Victor calls these sorts of things "explorable explanations" [1]. Lately the term seems to be catching on with a few others [2] as well.

[1] http://worrydream.com/ExplorableExplanations/

[2] http://blog.ncase.me/tag/explorable-explanations/

Yep, I'm aware. I'm still just a student, but I try to follow PX-related research pretty closely, and I'm actually something of a fan of your work in this space in particular :) I've also got a lot of respect for projects like Elm, where an explicit focus on programming-as-UX has produced a language and development environment that (although incomplete) are collectively more accessible and learnable than many of the existing alternatives.

That said, I'm still of the opinion that programmer culture at large is too quick to disregard design. I'd really like to see more programming tools for general use developed with an eye to design, and for more industry and hobbyist programmers to realize that the current baseline state of existence is not an absolute maximum but a local one. We've pushed plain text pretty far, but it seems obvious to me that there's much bigger wins to be had if we throw out some of the assumptions our culture tends to make.

This is spot on. In programming communities, design is frequently dismissed as an "implementation detail" or part of "making it look good" (i.e. marketing). This is a distinct and recurring cultural blind spot – more conceptually interesting programming tools than I can count have been torpedoed by a lack of attention to visual/UI/UX/HCI design.

Design is absolutely critical when it comes to helping people understand complex systems. Well-designed tools work with the human brain to mitigate cognitive load, allowing the user to focus on making stuff happen rather than on juggling handfuls of information. Few programming tools, experimental or mainstream, fit this description; even fewer have anything like it in mind.

Successful efforts to make programming less opaque and more accessible will necessarily involve massive leaps forward in design. I'm glad to see design beginning to make some inroads into programming culture, but we've got a long way to go yet considering how frequently the Unix CLI is still held up as the state of the art.

Makes sense to me, although I suppose there's probably an argument to be made in favor of the uniformity that comes with using :require for everything.

(:use clojure.test) is probably a worthy exception – 90% of the time I see :use in the wild, it's in exactly that context :)

This interpretation is error-prone. (seq 1), for instance, throws an IllegalArgumentException at runtime. Meanwhile, (seq nil) returns a falsey value even though in many cases it's possible to transparently pass nil in place of a collection of any kind.

Essentially, seq already assumes that its argument is seqable. Don't use it to test an argument of unknown type for seqability; prefer something like the seqable? function from core.incubator [1], or a different core function like coll? or sequential? where the semantics of one of these will do.

[1] https://github.com/clojure/core.incubator/blob/master/src/ma...

Both :use and :require :refer :all slurp symbols into your namespace unqualified. This behavior can cause confusion when someone reading your code tries to figure out which symbols are defined where. Most of the time, more explicit alternatives are preferred:

  (:require [foo :as f])

  (:require [foo :refer [bar baz quux]])

Generally speaking, :require :refer :all is also considered non-idiomatic. In fact, ClojureScript has explicitly avoided supporting both :require :refer :all and naked :use [1]. Backwards compatibility seems to be the only reason either is still supported by Clojure on the JVM.

[1] https://groups.google.com/forum/#!msg/clojurescript/SzYK08Od...

The thing is, Closer was created for use on CodeCombat, which expects the parse tree to be in the standard Mozilla AST format. As far as I know, none of the projects you mention satisfy this requirement.

I don't know anything about Outlet, but the Wisp compiler actually makes use of Escodegen [1] – which expects input to be provided in the Mozilla AST format – to generate JavaScript. You can peek at writer.wisp [2] in the compiler codebase to see how it's done.

[1] https://github.com/Constellation/escodegen [2] https://github.com/Gozala/wisp/blob/master/src/backend/escod...

Some of the design goals for the new language (which seems to be called Aurora) are outlined in a recent post on the Light Table blog. Definitely some exciting stuff.

http://www.lighttable.com/2014/05/16/pain-we-forgot/

I suspect they were referring more to the syntactic baggage in Objective-C – which is at least partially a result of the fact that ObjC was originally implemented as a simple C preprocessor. To avoid syntactic conflicts with C, ObjC uses lots of weird syntactic constructs that contribute to the language's characterization as ugly.

A good example is the liberal use of the @ character to denote ObjC literals – even in front of strings and numbers, because raw C strings/numbers have different semantics and won't play well with the standard ObjC APIs.

core.async [1] is basically the canonical example of a Clojure library that relies on macros to do its job, although surprisingly few macros actually need to be exposed in the public API. Most notable is the go macro, which performs deep-walking code transformation on its body, permitting clients to write async code in a straightforward, boilerplate-free way.

There's usually a heavy emphasis in the Clojure community on keeping macros as small as possible – the thinking is that any behavior that can be implemented with ordinary functions should be, and most macros should be lightweight wrappers over these functions. This seems to fit together well with what I've observed: functional programming idioms often circumvent some of the more common legacy uses of macros in practice, relegating macros to a still-essential but less prevalent role.

[1] https://github.com/clojure/core.async

I've never seen any explanation from Rich on the subject, but semantically speaking, vectors used in syntactic constructs are almost universally meant to denote binding forms. Let-bindings, loop-bindings, function parameters and the like all use vectors in the context of binding symbols to values.

I find that, having gotten used to the mental shortcut "square brackets == binding", the distinction makes it easier to read the "shape" of code from a very high level and get a general understanding of its meaning at a glance. YMMV.

But, if this is conveyed by the article/graphic, it sure is subtle. I think it would have been a better article if he just explained his complaint (if it is as you say), rather than making a mockery of celebrity quotes with big sarcastic quotes next to pictures of their faces.

Yeah – it's entirely possible that I'm putting my own words about the learn-to-code movement into someone else's mouth unwarranted. I think the linked piece is more of a frustration-fueled rant than a fully-thought-out criticism, and that the author is trying to quickly capture the spirit of a half-formed argument that he hasn't yet fully explored.

At any rate, it resonated with me, although it took me a few reads to get the gist of what he was trying to say.

I think the point Bret Victor is trying to make is that what he perceives as the real value of programming (its use as a powerful extension of the programmer's cognitive abilities) is absent entirely from the perception of programming as an inherently good thing that code.org and related groups are pushing.

Programming is, and ought to be seen as, merely a means to an end – not an end in and of itself. A movement that gets programming into to schools by claiming code is itself a Good Thing will inevitably bring into existence a programming curriculum that ignores the important abstract stuff about coding-as-a-concept (the new ways in which computers can extend the mind) and focuses instead on the concrete "implementation details" of programming today (text files, the command line, and all that other baggage from 20 years ago with which programmers are still saddled).

Basically: the reasoning is important, the code isn't, and code.org is all about the code.

"Aww isn't that cute! A musician/artist having an intellectual idea that isn't completely terrible -- like a quaint little animal trying to imitate us true intellectuals up here in our high tower of superiority." I exaggerate, but this is basically the elitist mentality I perceive behind the actual quote. Am I way off base here?

I get the impression that this comment has more to do with contrasting will.i.am's statement with the other statements on code.org for effect than it has to do with specifically putting down will.i.am.

With this comment, the linked piece seems to be implying that the statements made by Zuckerberg, Clinton et al are inspired by wrongheaded beliefs about the purpose of education, and that only will.i.am's statement comes anywhere close to hitting the right tone. I read this comment as genuinely complimentary, albeit weak.

As I read it, Bret Victor's critique of code.org is more nuanced than the usual complaints: it stems from a disagreement with code.org's implicit claim that programming should be taught in schools because programming is currently a high-value skill, in terms of the amount of money you can earn by doing it professionally. He seems to think that school shouldn't be primarily about training people to be "useful" to employers or the government in the short term. I'm somewhat inclined to agree.

To me, this comes off as a desperate attempt to defame this movement because it threatens to demote the status of basic technology roles from "elite magic" to "basic literacy" -- and to some people, apparently that's not an amazing social good, but a terrifying prospect of power loss. Am I way off base here in perceiving this?

In the context of Victor's body of work (which is focused more or less entirely on making the incredible power of computers more accessible to more people), I have a hard time believing that any such motivation underlies the linked piece. While I think there definitely exists such a motivation in other criticisms of the learn-to-code meme, I don't think it has much to do with Victor's critiques.