DanWaterworth

Totally agree, it was a joke.

Time to start sending PRs [1], :P

[1] https://github.com/search?utf8=%E2%9C%93&q=language%3Ac

Thanks for providing context.

> PyPy 5.3.0 is twice as slow as Python 3.5.0 for some work I regularly deal with

Is this because you are using ctypes or a C extension written against the CPython API? If not, have you filed a bug report?

> Surely it is, if you precisely know all timings and IO and can replay them there's nowhere for non-determinism to creep in.

This was my original point, the address space layout information leaks into python land via things like id.

> That's not really an acceptable scale of required knowledge for a time-traveling debugger though.

That's what recording captures (though, you don't need to know the times at which things happened).

You can compile PyPy without its JIT.

Ah, you've caught me out on my sloppy use of English.

What I should have said is that the address space layout is a source of non-determinism that would otherwise need to be accounted for in the recording of a program.

Further, I hold to the view that given a program, knowledge of the thread execution schedule/scheduler and the results of external calls, a program's execution should be deterministic.

Thinking about this now, I realize disabling ASLR shouldn't be enough to fix this problem since recording and replaying are sufficiently different.

Here's a python program that should be deterministic, but isn't without disabling ASLR:

    print id(object())

Go's threading primitives are not unmatched. You can do the same in Rust [1], but the gold standard in my eyes is STM in Haskell which allows you to block on arbitrary conditions.

[1] https://doc.rust-lang.org/std/macro.select!.html#examples

Essentially all but the most used code-paths with be bug riddled. This paper [1] on finding bugs in C compilers by fuzzing is an interesting case-study.

[1] http://lambda-the-ultimate.org/node/4241

I think that's true, but I don't like that it's true. What does that say about programming as a profession? Yuck.

That's brilliant. I love that there are people in the world working on "EEG for birds". It might even be my favourite "X for Y" startup idea.

That's basically true.

I consider myself an "advanced coder", whatever that means and so I know that an IRC server is likely to be IO bound. I also know to avoid C, especially multithreaded C. Not because I would be unable to write correct multithreaded C, but because I probably don't have to to solve the problem adequately.

My experience means I know to pick my battles.

Apparently it didn't have to be C or blazing fast.

I find it hard to believe Sally is so advanced if she writes code that others have difficultly reading.

It shouldn't take a year to find someone who writes unmaintainable soup.

EEG?

That's already the case during BST.

I'm surprised that you expected it to.

edit: Having looked at Reason more closely, I now see where the confusion came from. Sorry, I didn't mean to deceive you.

This is what I'm doing with plastic [1], though it also has some semantic differences: strict instead of lazy, monads become objects.

[1] https://github.com/DanielWaterworth/plastic

There's PyPy. I think the problem with python is the community is especially resistant to breaking changes.

How do you unbox something that could be null? Why not have a separate method on the sequence to define the initial value?

When I was adding for each style loops to my language, plastic [1], I just opted for 'you can iterate over any expression that produces a coroutine'. It shouldn't cause any problems a tracing jit can't fix and it's super convenient.

[1] https://github.com/DanielWaterworth/plastic

> Is CoffeeScript considered a programming language? :O

No, technically it's a type of vegetable.

The lens library is more like a dialect of Haskell than a library.

I've also been creating a programming language recently [1]. I'd recommend looking into the pypy tool chain. It makes it pretty easy to hack together a decent interpreter (that JITs). That and rply for the front-end gives you enough tooling to be dangerous. Here's a good tutorial [2].

[1] https://github.com/DanielWaterworth/plastic

[2] https://morepypy.blogspot.co.uk/2011/04/tutorial-writing-int...

You have my condolences.

Thanks, that's an interesting nuance.

When you have imperfect information, understanding the other player's strategy becomes part of the game. A perfect solution may be computable against any deterministic strategy, but its stops being a possibility when you don't know the other player's strategy.

I've found this podcast [1] really insightful. The guy who presents it is Christian, but it's interesting whether you buy the Jesus thing or not.

[1] http://subversivekingdom.com/theres-no-such-thing-as-a-soulm...