jneen

This is a problem in most imperative-paradigm languages, unfortunately. The issue is in the semantics of the `for` loop, which make everything confusing both for the programmer and the compiler.

What's really missing though is unions with destructuring `case`. Once you start coding in a language with proper unions, it's hard to go back. In python it might look something like this:

    DataType = union({ 'type1': ['field1', 'field2'], 'type2': ['field3'] })

    DataType.type1(val1, val2)
    DataType.type2(val3)

    # pretend syntax
    case datum:
      DataType.type1(a, b):
        doSomethingWith(a, b)
      DataType.type2(c):
        doSomethingWith(c)

=parent.location='http://www.google.com/'

hey look, a page redirect :D

"I'm buying up this incredibly valuable resource to lease it to people who only need it temporarily so I can turn a profit! Cool, right?"

Uh, it is not at all vitriol. You read the thing right? It's about self-discovery and the discomfort we all feel when we find out we're supporting violent or oppressive systems.

Those... get bulldozed all the time too, unfortunately.

These look an awful lot like homes to be calling the people living in them "homeless". I wonder what it would look like if the city didn't keep bulldozing them?

'Syn'

I'm not sure what you mean by "cases where the return value type is actually unknowable". Does that mean you only return an Element when it's something for which there can be only one on the page (like document.body)?

As far as APIs go, one way would just be to return a list always. The DOM, afaik, returns a special NodeList thing that isn't even an array. ( https://developer.mozilla.org/en-US/docs/Web/API/NodeList?re... ). What's the actual issue with using wrappers?

    If multiple elements of the same tag exist, a proper
    array of elements is returned otherwise an Element is
    returned.

STAHP. Please don't make the type of the return value dependent on runtime state. This is exactly why jQuery created its own array-like wrapper (which subclasses Array, fwiw).

Uh, ruby can be parsed, it's just hard. It's waaaay saner than perl.

"Code is meant to be consumed by machines"

Well, partly. Code is actually a piece of writing intended for two very different audiences - one human, one machine. The machine doesn't actually care how long your lines are - this is an optimization for humans.

And I hear you about fixing the tools. Wouldn't it be easy if everyone used the same editor. But alas, this isn't a problem with the tools. It's an inherent limitation of text. That "figuring out visual structure" bit only works if your editor deeply understands your language. And different editors understand languages to different degrees and in different ways.

They say parsing is a solved problem, but I dare you to parse Ruby or Python correctly.

Yeah but they all boil down to the central charge of "embarrassing the government".

Just asked about this on #altjs, and it looks like TypeScript will actually give you a static error if you try to assign to a free variable.

Hm, but it seems to be a runtime error. Is there a transpiler or other tool that will give you static errors if you try to set an out-of-scope variable?

Actually, good js implementations (like v8, for example) will only create one code object shared by all the unpack functions, with separate closures assigned to each. And since closures can (usually) be statically determined, they can use an offset lookup for the closured variable in place of a hashtable. So it's not quite as inefficient as it looks :).

An alternative would be the old lambda-calculus trick of just saving the function with values in the closure.

    function Tuple(/* args... */) {
      var args = arguments;
      this.unpack = function(fn) {
        return fn.apply(null, args);
      }
    }

I really like the way scheme does it. In order to mutate a variable (which is actually comparatively rare), you have to use `set!`, and to create a binding (much more common), you just call `define`. `set!` is incapable of creating new bindings, and will error if the variable is in scope, while `define` will always shadow.

The js and coffeescript ways of handling this seem both to come down to the assignment operator being used for both creating bindings and mutating them, which gets confusing, and causes the failure modes you described.

I assume you're being facetious (tm).

Okay that's an awesome acronym. "Language for Systems Development" = LSD

"No."

Warning: auto-playing video.

"By electronic e-mail" groan

Let's beam! ...igos

Metaprogramming syntax isn't built in to ruby. Instead, it's really internally consistent and lets you leave out a few tokens, which means it's really easy to write libraries with beautiful interfaces.

The built-in features usually try to solve the general case, rather than focusing on specific use-cases. For example, in python you have iterators, which make it easy to have a block of code that is run multiple times with different bindings. In Ruby, you have block syntax, which solves the more general problem of "let me pass this anonymous block of code to this function", and they built iterators on top of that.

Yeah, housing. It's the big issue of the day here, and you can see how much it affects our culture.

Basically we created a mortgage system that only works as long as property values continue to rise, which created a lot of political will behind "improvement" measures like eliminating public housing, like we did in the early 80s.

(see http://www.wraphome.org/downloads/without_housing.pdf [pdf] for a fascinating study on the origins of modern homelessness)

I'm doing some experiments with cooperative housing and income-sharing right now, which slightly mitigates my contribution to gentrification, but something else is needed, and I'm not sure what.

The video is down :(

Maybe it's just me, but this seems like a very... convoluted process.

That's actually a great idea. If I were a math teacher, I would teach my class that IFQ is a reasonable answer to a question, and I'd throw in a few plainly ill-formed questions just to keep them on their toes. Actual thinking > correct answers.

In high school geometry, I remember my teacher making some assertion that was plainly false - I think it was that 3 planes always intersect in a line. After arguing with him for like 15 minutes, I walked to the front of the class and wrote a proof on the board. I spent the rest of the class period sitting outside.