johnbender

In general this also translates to simply understanding the semantics of a language. If you can describe something in terms of another concept the listener already has an intuition for, often it makes the new thing easier to understand and learn.

Though it's easy to imagine cases where the "lower" thing is so abstract that it's hard to apprehend in the first place (e.g. "everything is just a closure!").

I don't know if we're talking about the same type of difficulty. I don't think program committees see the difficulty of the problem being solved at the core of the paper as a "negative" necessarily?

> The main thing PCs want is for papers which make progress on important problems. Now, you can do this either by (1) attacking existing open problems, or (2) by finding new important problems.

My earlier note aside, I think this is an extremely important point. It seems to support the idea that "impact" is hard to gauge but much easier when the community has already arrived at some form of consensus on the importance of a problem.

There are two high level criteria for publication: novelty and difficulty (this is in my field of Programming Languages and Systems so keep that in mind).

The novelty requirement is important and I trust that you satisfied it but (as you pointed out in a child comment) you may not have met the difficulty requirement and the reviewer did their "best" to articulate that in a way that isn't the all together ridiculous "not hard enough".

Naturally we might wonder why "difficulty" is a requirement at all. Shouldn't the importance or impact of the work be the thing that matters regardless of how difficult it was to achieve? The problem is that it's _extremely_ hard to know what work will be impactful and so reviewers, who have to reject something like 90% of submissions, use the heuristic of "difficulty" to estimate.

This is a problem to be sure but I think it would be a problem in other settings as well.

I'm not sure this is bad in an absolute sense. If I'm working on something, the semi-asynchronous nature of chat (assuming disabled notifications) allows me to answer questions when it makes sense for my workflow.

Generally, confining in-person chats to blocking questions seems like a reasonable thing to do.

Note, you have to be willing to put the time in, especially if your linear algebra is rusty or (like me) you have only a passing familiarity with complex numbers.

With that in mind, it's almost entirely self-contained and you can immediately start to make connections with classical computing if you're familiar with automata.

I've been interested in learning about quantum computing for a few years now and this book finally got me going.

https://www.amazon.com/Quantum-Computing-Computer-Scientists...

[update]

As an aside it's a really great excuse to try out one of the many computer algebra systems out there. I gave Mathematica a trial for fun since I'd already used SageMath in the past.

Pierce's book is as approachable as you're likely to see with respect to type systems. You mostly just have to dig in.

> Is there something inherently easier to implementing a functional language instead of something more imperative?

Other answers have focused on the parsing of the language (that is, the production of an AST) which is much easier to cover instructionally for a Lisp because it's basically the AST already.

To my mind the semantics' of imperative languages is the real issue. In particular when defining and/or implementing the semantics for an imperative language, eventually store (memory) management comes up and everything gets much more complicated instantly.

[edit] And to go along with the store there are often more forms for which you need to define the semantics (statements, expressions, classes, etc).

In contrast functional languages can frequently be implemented using term rewriting which can deal directly with the AST itself.

More broadly, this is why I wish students were required to implement an interpreter of an imperative language. The act of debugging programs becomes more difficult for the same reason the semantics is more difficult to define and implement: it's more complex and there are more nuts and bolts to consider.

The concurrency/memory model nerds out here would love to see an early draft if at all possible :)

If nothing else, is it going to be weaker than sequential consistency?

Given the sums of money involved I think it might also be worthwhile to have a formal semantics and a logic for proving safety properties of these blockchain programs (beyond type safety).

Not every application would require that kind of rigour but if the participation and value of a given currency/contract/program is determined largely by trust then it seems natural to want more serious guarantees.

I'm thinking of something like Lamport's global time model from "On interprocess communication".

http://bugs.gnu.org/22768

The the writes to the `foo.gz` file have to hit the disk before the unlink but the I/O scheduler can reorder these potentially and a badly timed crash could result in data loss. Note that journaling doesn't fix this issue because the transactions are distinct too.

http://bugs.gnu.org/22768

For example, if two processes issue writes to disk sectors that are adjacent but one of the processes' writes also affects a different sector farther away on the physical disk the I/O scheduler may re-order processes' sector level writes. Normally journalling addresses this issue but if the journalling transactions are reordered then it's no help at he application level.

Exactly.

In the first clip you posted, at the end in the tour of flanders when Cancellara attacks before the finish, neither his cadence nor his body position change as he accelerates. Further, the rider behind him who is undoubtedly an incredible athlete has to stand up just to keep his current pace.

At the very least it's not hard to see why this looks suspicious.

Oddly you would think that sacrificing non-determinism would really hurt the power of PEGs to express languages but there are languages that are not context free (eg, `a^nb^nc^n`) that can be written as a PEG.

When assignments to variables happen in the context of a procedure call it's preferable to use registers for performance reasons since memory access (even cache) is much slower by comparison. Unfortunately registers are a limited resource, so we would like to reuse them when a variable, though in scope, isn't "live" or in use.

This whole area of optimization is called register allocation and the optimal solution reduces to the graph coloring problem which is NP-complete. As a result there are a myriad of approximation algorithms with knobs to turn to spend a bit more complexity for a bit more accuracy. This patch appears to be the turning of one such knob.

As part of defining the Rust semantics they will certainly tackle the question of the memory model. Dreyer and company have a track record of providing semantics and reasoning principles for weak memory models (like C11).

You might have to wait a while for a rigorous semantics though.

That's where this project comes in and that is why the C++ memory model definition/formalization was so important. Programmers need to know what guarantees the compiler gives about the behavior of the code after compilation and the semantics is the final word.

http://matt.might.net/articles/parsing-with-derivatives/

This captures the core idea from my brushes with various constraint based programming languages. There's nearly always a spec floating around somewhere, it's really a question of how expressive your constraint language is. Even programs in "higher level" languages can be seen as a (rather complex) set of constraints.

Memory management normally conotes the process for allocation and reclamation of memory in a program.

A memory model defines where reads can get their information from in a program. In most contexts that is informally "the most recent write" in terms of wall clock time (i.e. sequential consistency).

In C++, C and Java, this is not necessarily how things are. For example in Java writes can be buffered preventing reads in other threads from seeing them right away. This means those reads will get a value from an "older" write (again wall clock time).

It's all really bad for reasoning about your program :(

Didn't make it into my first paper, hopefully will end up in my thesis :)

1. http://en.wikipedia.org/wiki/Concolic_testing

[edit] "never require the hammer of mfence for correct synchronization", maybe you're confining this to correct synch. and not recovering sequential consistency (or some other semantic property).

[edit] It's not clear to me that this project compiles to es3, but that was my assumption when reading "JavaScript that will work today".

The power of science is that it often defies reasoning and in so doing provides new insights into how things work.