yoavg

A criticism of "On the Dangers of Stochastic Parrots: Can Languae Models be Too Big"

Yoav Goldberg, Jan 23, 2021.

The FAccT paper "On the Dangers of Stochastic Parrots: Can Languae Models be Too Big" by Bender, Gebru, McMillan-Major and Shmitchell has been the center of a controversary recently. The final version is now out, and, owing a lot to this controversary, would undoubtly become very widely read. I read an earlier draft of the paper, and I think that the new and updated final version is much improved in many ways: kudos for the authors for this upgrade. I also agree with and endorse most of the content. This is important stuff, you should read it.

However, I do find some aspects of the paper (and the resulting discourse around it and around technology) to be problematic. These weren't clear to me when initially reading the first draft several months ago, but they became very clear to me now. These points are for the most part

JoshuaSullivan

class MobiusRing {
  float majorRadius, minorRadius;
  int segments;
  
  PVector[] vertices;
  
  MobiusRing(float majorRadius, float minorRadius, int segments) {
    this.majorRadius = majorRadius;
    this.minorRadius = minorRadius;
    this.segments = segments;

proclaim

var util = require('util');
var events = require('events');

function WaitForText() {
  events.EventEmitter.call(this);
}

util.inherits(WaitForText, events.EventEmitter);

WaitForText.prototype.command = function(selector, expectedText, timeoutInSec, callback) {

spookylukey

# If it's complex, Django's Generic CBVs will probably
# make your life harder. And if it's simple, they probably
# will too.

# Before:

from django.views import generic

class ReportPDFDetailView(generic.DetailView):
    model = DesignerReport

lakesare

import express from 'express';
import bodyParser from 'body-parser';

const app = express();
app.use(bodyParser.json()); // add a middleware (so that express can parse request.body's json)

app.post('/api/courses', (request, response) => {
  response.json(request.body);
});

tristanm

<%# Example of using OffsitePayments::ActionViewHelper to generate a form %>
<%= payment_service_for 'ORD123456', '[user id]', service: :pxpay, return_url: 'http://localhost:3000/pxpay/return', credential2: '[key]', currency: 'NZD', amount: 12.34 do |service| %>
    <%= submit_tag 'Pay Now' %>
<% end %>

<%# Example of generating a URL directly (see controller) %>
<%= link_to @service.credential_based_url, @service.credential_based_url %>

scottmagdalein

<!-- This is the HTML element that, when clicked, will cause the popup to appear. -->

<button id="open-popup">Subscribe to our mailing list</button>

chantastic

Hi Nicholas,

I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:

The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't

obfusk

import code; code.interact(local=dict(globals(), **locals()))

sebmarkbage

import { Component } from "React";

export var Enhance = ComposedComponent => class extends Component {
  constructor() {
    this.state = { data: null };
  }
  componentDidMount() {
    this.setState({ data: 'Hello' });
  }
  render() {