tyoverby

> What would Target do if their canned beans vendor started putting labels on the cans like "we sold this item for $0.23. Anything else is profit that your store is charging you."? Those cans would never see the shelves.

Arizona Iced Tea does this and they're very successful.

OCaml has an incredible optimizer, and many of the abstractions that one would use in OCaml are transparent to the optimizer.

You could say the opposite about Go.

Human Chess players lost against Deep Blue in 1997; people still play Chess. In fact, they've learned a lot of strategies from the strategically superior AI.

Here's an example scenario:

1. Your PR is tested with the merge against Master. All green!

2. Another PR is tested with the merge against Master. All green!

3. The other PR goes in first. All good!

4. Your PR goes in (merge happens, but introduces a bug). Oh no!

For Microsoft at least, most of my coworkers send their kids to public school.

I work on the C# compiler and the answer over in that world is "no"; everything needs to be supported.

Another thing that I should mention is that most langauges, features like generators / async / exceptions don't compose well at all. In a language where these features are implemented through continuations, it's really easy to pick how they interact, leading to some really powerful tricks!

The page that you linked to shows off some features that are not really found in any major programming langauge. Time-traveling search is a big one for me.

Many languages have exceptions, but with shift/reset, you can implement your own exception handling behavior trivially, including things like resumable exceptions.

Some languages have async/await, but almost all of those implementations are state-machine based, which means that they don't compose well when used with more complex language features like generics and higher order functions.

But more than that, in continuation-based asynchronous programming, "async" functions are just normal functions that execute in an async prompt. Here's an example of a multi-user asynchronous TCP echo server in my toy language with tagged delimited continuations:

    async {
      loop {
        let conn = accept_connection("localhost", 9999)
        async {
          loop {
            let data = conn.next_data()
            conn.send(data)
          }
        }
      }
    }

Where all of those asyncrhonous constructs (including `async` itself) are really short wrappers around delimited continuation machinery.

You'll notice that the nested calls to `async` indicate that there are two asyncrhonous contexts

1. Connection acceptance happen on their own "thread" of control

2. Each connection gets their own context in which everything is internally asyncrhonous

I've been playing around with delimited continuations in a toy programming language of mine for a while now and I seriously think that its a paradigm that will eventually take over the scripting language space. First-class control flow is so powerful once you get the hang of it!

> How many NPM repos are there? Just one, too-big-to-fail, centralized repository.

There are actually plenty, it's just that they're usually found on-prem at a company.

> I think the generalization of "use-after-free" to "use-after-invalidation" is the most important

> I wonder if this sort of vulnerability is possible in Rust

Rusts borrow checker is designed for the more general case of "use-after-invalidation" and `free` is treated as a simple invalidation of what happens to be a heap allocated structure.

Interestingly, the borrow checker also prevents invalidations that are still common in memory-safe languages such as iterator invalidation.

I didn't say "a" deb repo, I said "the standard debian repository". Just like when I'm talking about NPM, I'm talking about the main NPM repository, not my company's private NPM server.

Let's say that you and I both create a library. You try to publish your C++ library to the standard debian repository, and I'll try to publish mine to cpam, npm, pip, etc...

If you actually manage to get your library included, then we can compare how long it takes to update your library.

The most important part of language tooling for me is reproducability. I should be able to do the following to any project:

    git clone <project name> && cd <project name>
    <build tool> build

And have it fetch all of that projects dependencies, and then build the entire system.

Anything that requires machine-wide package installation is immediately disqualified (user-wide package installation is almost as bad).

Ended up just writing it in Rust which I've been using for years now. I wanted to try something new, it's hard to compete with Cargo for package management + build tools.

It was the last unit in senior math at my high school.

"time in the gym" is way easier to measure than tangible improvement. It's not surprising that people try to optimize things that are the easiest to graph in Excel :P

I did see that, but I discounted it because I wanted to make a serverside (native, not serverside-js) application, and I assumed that the reason-react-example was only for making compile-to-javascript applications.

I tried using Reason for a side project. Getting the build tools and the package manager for ocaml took too long so I gave up.

Sure. That's a property of the language, not S-Expressions.

It's just like how SQL decided to write all their queries backwards making it impossible to do good autocomplete.

Autocomplete is most commonly used on structures in order to find out which fields and methods that structure contains.

If you used an s-expression based grammar that still had fields and methods, then you'd get the exact same experience.

    foo.bar. <- autocomplete here

vs

    (foo.bar.)
            ^ autocomplete here

That is super impressive! I can't find the part on incomplete AST or AST reuse in their reference docs though.

I don't see why they would be any better or worse than another grammar choice.

It might be true that s-expressions would make people prefer certain semantic decisions that would be difficult to analyze for autocomplete.

The best part about going open source was being able to outsource the bikeshedding discussions to the community!

(Just kidding, we still do them internally too)

The "best" part about project Roslyn is that if someone wanted to make an s-expression frontend, they could plug that into the compiler.

We don't have specific people that do parsing; if your feature needs changes to the parser, then you make those changes.

Hello, I work on the C# compiler and we use a handwritten recursive-descent parser. Here are a few of the more important reasons for doing so:

* Incremental re-parsing. If a user in the IDE changes the document, we need to reparse the file, but we want to do this while using as little memory as possible. To this end, we re-use AST nodes from previous parses.

* Better error reporting. Parser generators are known for producing terrible errors. While you can hack around this, by using recursive-descent, you can get information from further "up" the tree to make your more relevant to the context in which the error occurred.

* Resilient parsing. This is the big one! If you give our parser a string that is illegal according to the grammar, our parser will still give you a syntax tree! (We'll also spit errors out). But getting a syntax tree regardless of the actual validity of the program being passed in means that the IDE can give autocomplete and report type-checking error messages. As an example, the code "var x = velocity." is invalid C#. However, in order to give autocomplete on "velocity", that code needs to be parsed into an AST, and then typechecked, and then we can extract the members on the type in order to provide a good user experience.

My personal opinion is that everyone should just use s-expressions. Get rid of this whole debate :P

Does Mustache compile into .swift files that need to be typechecked and linked into the binary?

I'm not ChicagoDave, but what he wrote resonates with me.

I view my blog as an extension of my memory. When I write things, I do it mainly for myself, rather than to appeal to other readers. Because of this, my blog gets practically no traffic. I'm happy with github hosting my ramblings for free.

(2) is why I'm so happy for Gc<T>.

Also, if my graph is going to be short-lived, I've had success just allocing up an Arena<T>, making as many cycles as I want, and then collecting the whole thing at once after my computation is done.

https://github.com/Manishearth/rust-gc