nuntius

Very cool. Seems to be another tool in the same vein as halide-lang.org, now extended for sparse data.

Dependency graphs can also be annotated with the resources required for each node or edge. Resources are estimated by summation, time is estimated by finding the critical path.

Gantt charts are a partial linearization of a dependency graph. People tend to fixate over the dates shown, allow schedule pressure to "correct" previous estimates, etc.

According to some early users of Gantt charts, they are a great tool for summarizing a plan, a terrible tool for developing and maintaining one.

Of course H1Bs get and accept the same offers. That's exactly the issue.

Don't tell me you never knew the H1B who knowingly accepted a low salary because that was their chance to move to the US, get their food in the door, and hopefully move up. I've known many, from both Asia and Europe, who told me exactly this.

Companies knowingly use this to keep wages lower than the US-based supply would otherwise demand. At one level, I support this -- it maintains a competitive edge.

So what's wrong? Unlike a citizen or permanent resident, H1Bs feel indentured. They are even more risk averse. If you believe in free trade, then the freedom of both parties must be protected. Both H1Bs and undocumented immigrants feel far from protected. There are both moral and economic problems with the arrangement.

If you emulate a dozen machines on one physical machine, then a single exploit can traverse them all. If you pack a dozen "single board computers" in a case and give each a single function, then entire classes of attack are ruled out.

Some of the visual SLAM techniques are also getting fairly good results for cheap. In particular, see DSO (same research group as the previous LSD-SLAM).

http://vision.in.tum.de/research/vslam/dso

Instantly, as in next line of code? Yeah, probable human error (or auto-generated code).

Without being used? Not surprising. It is surprisingly common to allocate a variable, pass it to a function, and have the call never actually use the variable. Unwind, and the variable is destructed without use.

I've seen other nasty framework errors exposed by such (non-)usage patterns.

Very much a part of the standard. i.e. not specific to SBCL.

Think of defgeneric as the function signature and defmethod as the template specialization. Not sure why you say this is an error in CLOS. Looks fine to me.

That said, most implementations try to auto-infer the generic function metaobject when you use defmethod without defgeneric. SBCL raises a warning.

Good reads on the topic:

http://www.gigamonkeys.com/book/object-reorientation-generic...

https://mitpress.mit.edu/books/art-metaobject-protocol

http://mop.lisp.se/

I read those comments more than a decade ago. They seemed weak but tolerable then. They seem broken now. Git is supposed to guarantee that the code I see is the code the author saw, in a distributed and decentralized environment. This is Git's entire reason for existing.

A secure design is essential for trusting this functionality. My trust in Git has always been tempered by the weakness of SHA1.

A GPG signature is no stronger than its object ref.

Have you seen how many frameworks believe "auto-pull and compile deps by hash from github" is reasonable? They are assuming this isn't a massive attack vector. They are trying to build on a core feature that Git claims to have.

Recent events moved this from probably foolish to provably so.

Backwards compat requires that both old and new hashes work at the same time. A simple typedef is unlikely to handle all the semantics and space needed for such a change...

It is often hard to generalize when N=1. Now that the N=1 use case is established and we are moving towards N=2, it is painfully obvious to all that a better abstraction is needed.

Typedef or no, we would still need a full audit of the code to find spots where people "inlined" the expansion.

IMO, Linus should have done better here -- no crypto hash lasts forever, but this code is far cleaner than useless layers of abstraction.

Fully agree regarding your points about micro payments. Patronage, monopoly-priced copyright, and advertising have all proven to have bad side-effects.

IMO, the market may be acting rationally here. I have tried Octave several times, and always moved on with little regret. Genuine Matlab is tolerable for some prototyping tasks. A slow clone of Matlab has little value outside of academic environments where Matlab compatibility is required. Programmers use their favorite language, and others use a spreadsheet.

Matlab has always been a quirky language. It has good libraries for common math operations, good visualization tools, good documentation, and toolboxes available for many special tasks. There are a number of common pitfalls, with well-known workarounds, that cannot be fixed without breaking backwards compatibility. The performance of a "for loop" is usually dog slow (some special cases were optimized recently). You often spend hours figuring out how to vectorize your code so it runs decently fast. OOP and other techniques have been bolted on in a workable but unusual way, and they are not widely used. Licensing costs add up.

People looking for a free Matlab replacement often gravitate to a full replacement, rather than a clone. In the past, this meant learning something like C++, a significant hurdle to migration.

Python is generally seen as a much better general-purpose language than Matlab. It is building a much larger developer community. It is no harder to learn than Matlab, and it supports similar interactive development. Tools like numpy start adding easy support for Matlab's core strengths. Python is free, even in commercial deployments.

Matlab's primary competitor used to be Excel. Python is emerging as a very real threat. Outside of the core Matlab user base, preference for Python (or Go or ...) is building fast.

Halide is for explicit SIMD, and a couple of the others provide good support for it as well. These tools are made by graphics and physics optimization people. Look at the examples.

Take a look at Halide. I think it is an excellent DSL, covering the base of what you describe, and well positioned for extension to the rest. If nothing else, the documentation is a summary of a wide range of optimization techniques. Written as a C++ library, it also supports dumping an object file with C-style header.

http://halide-lang.org/

Another option in the area is OpenMP. It has a wider base of users and contributors, but I think the abstractions are not as good.

http://www.openmp.org/

If you can move to a completely new programming language, then Chapel is built to easily scale up across large supercomputer clusters.

http://chapel.cray.com/