orodley

The fact that surprising things have happened in the past isn't evidence for a particular surprising thing happening in the future.

Intel released the source of XED a while ago, in December 2016. Not sure why it's popping up on HN now.

Lots of Greg Egan's work deals with consciousness. For example, "Permutation City" is great.

Shameless plug - I wrote my own self-hosting C toolchain (compiler + libc + assembler + linker): https://github.com/orodley/naive.

It was a really fun project, and I learned a lot from it.

I don't know about this implementation in particular, but in general a cons cell is just an object with two slots in it. You can use it to represent a list (by putting another cons or nil in the cdr), but you can also use it to represent other things. For example, a pair, by putting an arbitrary object in the car and cdr. This is a pretty common technique, see "a-list" for one application.

>the ease of CSS/HTML

Is this a joke? I can't use either of those for more than 5 minutes without wanting to commit self-harm.

Because the useful types of optimisation around undefined behaviour aren't: "we can prove that your program definitely contains undefined behaviour, so we'll compile it into 'rm -rf /', mwahahaha" but rather: "if property P about your program is false, then it would definitely contain undefined behaviour, therefore P must be true" followed by using P to do useful optimisations.

This applies even when your original program contains zero undefined behaviour. Warning here isn't useful.

Income tax is still very visible in NZ. On your payslip it lists the before-tax value, and then deductions for PAYE, student loan payments, etc. Plus wages/salary are still expressed as a before-tax rate, so you can see the disparity there too.

I get the argument, but whether or not I /want/ to pay taxes, I still have to, so why make it inconvenient? The NZ government finds plenty of other ways to make me angry and upset anyway.

Just by the way, the statement in the article is incorrect. Google Sydney does have male/female toilets, but we have unisex toilets as well.

>barely enough to be noticeable

For me it's (off the top of my head) about 10%. Definitely noticeable.

Their API has a TOS. Not everything that uses the API is allowed by the TOS, and you shouldn't assume that it is. Not saying this site is against the TOS (I haven't read it), but something to keep in mind.

Many implicit rules make use of variables, which you can change as you see fit. For example, creating an object file from a C file will do something like "$(CC) $(CFLAGS) $< -o $@". You can change CC to change the compiler used, and add stuff to CFLAGS to add compiler options, all without touching the rule itself.

Other than that there's not much configuration, but the predefined rules are usually quite simple, so it's pretty easy to just write your own implicit rules if the predefined ones don't suit your needs.

My favorite site for these kinds of puzzles is https://www.ocf.berkeley.edu/~wwu/riddles/intro.shtml

% is really useful for dealing with functions too. For example, deleting "foo(a + bar(x, y) + c)" by placing the cursor on the "f" and executing "d%".

But the amount of code that deals directly with producing such output is usually very low, as a proportion of the total amount of code in the system. Having a pane on the right say '825' next to the 'printf("%d\n", do_the_actual_work(foo, bar));' in my code isn't useful. I already get that from the terminal. The place where the benefit would actually appear is visualizing the parts of the code that are doing the complex and error-prone tasks in the system.

If you're a frontend web developer, then sure, it could be useful for you. But with the kind of stuff I do personally, the 2D output demonstrated in the article is irrelevant. Most stuff is much more abstract, and has zero relationship to direct production of visual output. It looks cool and all, but ultimately I feel like it's focusing on the easy problem rather than the important one.

There are a few examples in there of visualizing the values in a for loop over time, but again, I feel like this is unrealistic. The proportion of my code that only executes for a fixed number of iterations that is easily determined at compile-time is negligible. As is iteration over a fixed, compile-time set of values. Most code lives inside functions that can be called with different combinations of parameters, interspersed with multiple nested loops and conditionals at different levels in the call stack, etc. Visualizing something like that in a useful way is much more difficult. If they can show an example of that, I'd be very interested. Until then, it seems more like a toy. A very interesting, promising toy, but still a toy.

The unit test example gets a bit closer, but it's still just dealing with the output of all the code that actually does the work, not the details of that code itself. A tool like this should be helping you with the hard tasks rather than the easy ones, because the easy ones are already, well, easy.

I'm not trying to be hostile, it certainly looks cool, and it looks like it could potentially be very useful in the future. It's just that currently it doesn't look like it would have any practical utility for me.

It doesn't function as a detector for both, it functions as a detector for either. I'm not being pedantic, there is a subtle difference. ALARM -> EARTHQUAKE is false: the correct theorem is ALARM -> (EARTHQUAKE | BURGLAR). If the alarm goes off then you have no certain knowledge about which one caused it, only probabilities.

CLisp is an implementation of ANSI Common Lisp.

There's a great collection of gradual typing papers here:

https://github.com/samth/gradual-typing-bib

Pretty neat. I did find a bug while I was playing around with it though: it doesn't correctly translate Duff's device.

Jonathan Blow is doing some very exciting stuff in this area with his new language. Check out his latest talk on YouTube about data-oriented programming.