smosher_

11 lat temudiscuss

It's because the generator recurses with:

    return fself(num - 1) + fself(num - 2);

instead of calling fib (or fib_gen) explicitly. fself is passed into the generator and it will need to be passed in again and again. That's what Y gets you. You could get tracing the way you suggest from something like:

    let fib f n =
        let n' = (* compute fib for n *) in
        f n'

and supply some f that will log (and return) the computed values, but that won't work with the motivating example: memoization. This really should have been clearer in TFA.

It's worth noting the memoization in the linked gist isn't pure. memo() allocates a cache and returns a function that references it. The cache is updated by mutating in place. After all the hoops we've jumped thorugh it's a bit of a let-down to end up here. (It's doable though.)

(Edit: improve clarity.)

smosher_

11 lat temudiscuss

If you read the comment you'll see that I'm talking about different interpretations of memory safety. You can't just decide what it means in Rust applies to all languages, or that everyone knows what you mean.

I was trying hard to have a conversation while avoiding arguing about semantics, so thanks for that.

smosher_

11 lat temudiscuss

> My objection is that I see unsafe just for memory integrity.

Either you think this way because of a sense of orthodoxy or because you think memory safety is important in a way the other kinds of safety aren't. I disagree, especially since "memory safety" may or may not imply protection against aliasing of mutable data. Those nuances I like about Rust probably wouldn't exist without the broader scope of safety concerns.

> As for voicing my objections to the Rust community,

About the discussion you linked? I meant to me, in the service of explaining your objections.

> My time is already quite filled following the JVM, .NET and C++ eco-systems, the ones I get payed to be an expert on.

Well, that was important information. Thanks for making the time to share!

smosher_

11 lat temudiscuss

> They are abusing it, specially as workarounds for constraints that cannot be expressed in the type system.

That doesn't sound like abuse to me, as long as the exposed interface remains safe.

> some Rust devs are using it for anything they assume isn't logical safe.

That sounds like an objection to the scope of what Rust defines as safe. Unless you mean to imply there are reasonable, Rust-safe ways to rewrite the transgressions. In the former case I have to disagree. It would be nice if we could prove more. But you can't prove everything.

I haven't seen the ICFP talk but I might watch it later if you can link to a video. I've skimmed that discussion before but you will need to point out your objections—IMO it is great that Rust devs are having that discussion.

smosher_

11 lat temudiscuss

> new generations never heard of those languages and think C was the very first systems programming language.

That's just it. Rust looks enough like C++ to catch on. This was not an accident though I can't say I'm jazzed about it.

Rust brings a lot to the table with its type system too. I would rather be using Rust tomorrow than having had the benefits of say Pascal derivatives for the past 45 years. I'm not saying this just for effect: after the obvious ML influence, the parts of Rust I like most are the nuances.

> Instead, many Rust users seem to sprinkle it everywhere.

Is that true? You will necessarily see it in bindings, or to implement certain essential features that can't be implemented otherwise. Beyond that there is the motivation to use unsafe code for speed, hopefully this is mostly restricted to modules.

Are you complaining that people are using when they could reasonably avoid it or that it is too often necessary?

smosher_

11 lat temudiscuss

> To me, green threads are just an implementation detail. The fact that green threading is being used shouldn't leak into the interface.

I think that mentality, which I supported, may be what ruined green threads for Rust. Perhaps the enemy was the perfect of the good. On the other hand, maybe not having to worry about differences is the better benefit. I would rather be slower-but-acceptably-fast than have to think about 1:1 vs M:N threading in the case that they are not interchangeable.

On the third hand, it could be that Rust is too close to the metal for green threads to be of any significant benefit. If that's the case, Rust ought to trounce all the M:N implementations, subject to reasonable limits on spawn rate, memory pressure and inter-thread communication. Does that sound right?

Incidentally, I've never seen a cooperative threading implementation that didn't have a yield call of some kind available, and you can usually jam any of them up by writing an infinite computation-only loop, so even in the langauges where the scheduler is automatically invoked, correct 1:1 code can deadlock in the M:N scenario. State machines can too, but a trivial example, translated, might read something like the following:

    for(;;);
    exit(EXIT_SUCCESS);

I've seen code like this written by complete newbies, but threading constructs can hide that relationship even from experts. In parallel code it isn't a sequential relationship, but it is with cooperative threads. I guess this is all fairly pedantic (such a minor detail, mostly affecting only poorly-written programs), but in the end, one of: yield(), sched(), sync(), etc. does show up in practically all of the cooperative threading interfaces.

smosher_

11 lat temudiscuss

Blocking at the request level is where it's at: you don't download the content, you don't execute the scripts, you don't interact with the DOM. You block requests to third party servers or resources based on lists or other policies. This saves you load time, execution time, and it keeps you from being tracked by targeted ad systems.

If people start bypassing the DOM with canvas we will have a bigger problem than cosmetic filters failing: we will no longer be served the same kind of document. Or we will, but the content will be in an opaque region of it. If that happens the web is dead. People tried this before with flash and that smoldered for a while in the 90s but didn't last, so I'm not feeling all doom-and-gloom about it.

Aside: Standardized document formats are important. If rendering to canvas takes on as the defacto standard, it would cripple the web technologically.

smosher_

11 lat temudiscuss

That's a little extreme. I think most computations are best¹ written in a way that is amenable to mathematical treatment, and most of the useful ones can be. Just because a counter-example exists doesn't mean we should give up hope.

I find constructing programs mathematically makes life easier in the common case and possible in nearly all others, unless you insist on things like proof-of-termination for programs which do not (I do not.)

1. 'best' because it gives us the means to reason about the code, and we know what kind of transformations we can perform on it, and do them abstractly without having to simulate it, potentially for infinite inputs, etc., etc. You know the drill.

smosher_

11 lat temudiscuss

> Stuff like SmallTalk wouldn't be possible if programming was turned into math

> and frankly I don't understand why mathematicians want to take over a completely different domain

I would like to challenge the assumption here: that programming (in whatever mode) can't be adequately described by mathematics. I don't have time to make a thorough argument, but consider this: instead of thinking of what programming would be like as some kind of math, think of what math would need to be like to adequately describe your favourite mode of programming. (Forget arithmetic, consider algebra, geometry.)

As for FP: these days it wants all the tools, and it is picking up whatever it can formalize. Some FP tools are uncommon or don't work well outside the paradigm. To me that makes all the difference: I'd feel more restricted working without FP than by being strictly within it.

smosher_

11 lat temudiscuss

FYI the quote above refers to the develeoper/community response to criticisms/ideas (eg. see the comment I replied to), not the criticisms/ideas offered by newcomers.

smosher_

11 lat temudiscuss

I don't know what it's like now. Rob Pike in particular made a lot of noise like this early on. There was a lot of parrotting of that, so it was hard to have a serious conversation. It seems like it's still getting play but I don't know how widespread that is today.

smosher_

11 lat temudiscuss

I think it's a canary. How many languages do you hear this said about? I've only heard it in regards to Go which is fairly pedestrian (read: looks and acts something like C / Java) as far as these things go.

More exotic languages, which take the uninitiated longer to acclimate to, don't seem to be trying to tell people they're not allowed to think deeper about and question the design of the language. Good criticisms of Go were made on day 1 and are being made to this day, Rob Pike's ego notwithstanding.

At the end of the day, if I see a problem with a developing language I am interested in, I'm going to report it. If I'm met with: "I don't know you but I'll assume you don't know what you're talking about" that's a second problem and I'm not about to double-down on it.

smosher_

11 lat temudiscuss

Fwiw I avoid writing both loops and recursion as much as possible. Collection data structures usually come with their own fold/map/etc functions, so this works well in practice.

smosher_

11 lat temudiscuss

I posted this in another comment, but her github repo has a Ceptre implementation: https://github.com/chrisamaphone/interactive-lp/

There are details on getting the trace graphed in the tutorial. (If you want more detail in the trace you can uncomment the code on this line: https://github.com/chrisamaphone/interactive-lp/blob/master/... )

smosher_

11 lat temudiscuss

I'm a big fan of this work. For the PDF-shy, there's some excerpted text on LtU: http://lambda-the-ultimate.org/node/5216 but you'll miss some of the goodies, like the graph of a scenario from Romeo and Juliet, showing the actors act concurrently at different locations.

See also the github repo: https://github.com/chrisamaphone/interactive-lp/

There is an emphasis on using Ceptre for developing interactive fiction¹ (text adventures/parser games.) From my perspective, a pain point in developing truly creative interactive fiction is the tools available tend to impose a world model on your work. I'm excited for Ceptre because it lets you write causal relationships directly and that makes starting from scratch a more realistic proposition.

1. With some work I think it could be (and should be) used in other kinds of games, such as sandbox games or anything that would benefit from a living world, even if only in part if the main story must be nailed down and deterministic.

smosher_

11 lat temudiscuss

In case anyone is wondering which project this is:

    The concrete contribution of the research report here
    is the design and implementation of a fully compartmen-
    talized operating system, MINIX 3. To properly isolate
    faults, we have removed all drivers from the kernel and
    run them as separate, unprivileged user-mode processes,
    protected by the MMU hardware. Since all servers also
    run in user mode in our design, only a tiny microker-
    nel that does not contain any foreign, untrusted code is
    left in kernel mode. Each component has only the mini-
    mum privileges it needs in order to prevent failures from
    spreading. In our design, driver failures are no longer
    fatal and do not require rebooting the computer.

smosher_

11 lat temudiscuss

^A in bash will go to the beginning of the line. I don't know if this is why tmux changed the key, but it certainly makes a bigger difference to me because I use that function a lot. I rarely press ^S by accident (less often than I press it on purpose.)

smosher_

11 lat temudiscuss

The idea is you can write this:

    let _ = print_string "foo"
    let _ = print_string "bar"

at the top level.

Of course you can write

    let msg = "foo" in print_string msg
    let msg = "bar" in print_string msg

(which isn't at issue, except no semicolons are needed.)

But you can't write

    print_string "foo"
    print_string "bar"

without semicolons.

smosher_

11 lat temudiscuss

Philip Wadler's paper Monads for functional programming is the first thing I read that made any sense. FYI this is the horse's mouth.

smosher_

11 lat temudiscuss

Did you even read the article? The article's description of "beat" doesn't conflict with the musical term but yours does. In fact the article even relates beats to tempo and describes the results in terms of tempo. This is about tempo detection.

The reason this technique is called "beat detection" is it can be used to collect the individual beats from the stream contrasted with knowing the just the tempo doesn't tell you where the beats are exactly (and doesn't help a lick with finding the off-beats.) Tempo detection is only one product of these algorithms, and guesses can be constructed from any of them, though sometimes additional heuristics are needed.

The accuracy of the LPF technique is well worth criticizing. Yes, it's fairly good, but it's not the best one we have and the article says part 2 will describe a better technique. I should note that even organs and vocals can create transients that are often associated with beats. The LPF probably does better simply by eliminating false-positives.

Submissions

“Propositions as Types” by Philip Wadler [video]

Specialize to reuse (inheritance-like patterns in Rust)

comments