clord

I like that they can use software in the camera to cut glass out of the lens. I have some pretty hefty glass, and if this is executed right (quality wise) it could be a big win -- even if they fix the focus like a traditional camera.

I have this crazy idea in the back of my mind to write a visual programming language based on Haskell, where shape and colour convey kind and type information. Still cooking that one.

We have some scripts at work that take 10+ hours to execute. Granted most of that time is in large child processes.

On top of what others have said, it takes some time to dynamically load a library into an address space. There are tables that may need to be walked and updated with correct pointers. For large libraries, this can be quite measurable. A statically linked executable will be memory-mapped and then brought in lazily as the program runs. And then if executed again, everything is mapped and loaded, so there is zero delay. Compare to dynamic loading, which will require table updates again (especially with ASLR).

This is why I like to re-make my shell and associated tools static binaries — shell scripts run 10-20% faster. (lots of small programs running repeatedly)

Scientific computing will hit this sort of problem just because the kernel is so large it actually needs to be broken into sub-procedures for icache reasons. But also, the penalty is large, because there is a full store/load cycle involved, which will clear caches and increase memory bandwidth requirements.

The big problem (other than verbose code) with rolling up stuff into classes in C++ is that performance suffers. Many platforms will not pass small structs efficiently.

Inspired by Haskell's newtype, I drafted a proposal for C++14 which would have introduced native newtype to C++, but it got rolled into an omnibus paper (n3635) and appears to have been forgotten.

The proposal is modelled on strong enums, but generalizes them to all types. They are essentially strong typedefs with none of the weaknesses of wrapper types, restrict pointers, typedefs, and pragma disjoint.

    newtype NotInt : int; 
    NotInt k(5); // call ‘default’
    NotInt bar(NotInt);
    bar(k); // passes exactly as an ABI int would
    int baz(int&);
    baz(k); // Error! no conversion
	

While drafting this proposal, I realized it was a much more C++-like way of bifurcating aliases than 'restrict' keyword:

    newtype D1 : double; 
    newtype D2 : double; 
	
    void biz(D1 *x, D2 *y) {
        // Being separate, D1/D2 can be
        // assumed not to alias by optimizers
	...
    }
	

While playing with it, we came up with this proposed syntax (although I don't think this would get through the committee):

    [template <typename T>]
    newtype [NotT] : [(public|private)] T [= (default|explicit|deleted)] [{
      // only non-virtual member functions, no data or reference members (something like POD)
      // this->value has all of the operations of T, but only aliases with the new type, and implicitly converts to/from T prvalues.
    }] [optional_variable_name];

Yep, but I'd qualify that: The demo seems to show wet snow (snowball snow) only. There are a few other types that happen around here, like dry snow, and crystallized snow. Dry snow is light fluffy stuff that doesn't pack. And crystallized snow is made of what feels like little daggers, behaving almost like ball bearings. But still, their result is brilliant!

We're contemplating going after harder-to-get fossil water because the easy stuff is depleted and can no longer keep up. Sounds like the situation we're in with oil.

In the case of water, which replenishes, the 'production cycle' is actually the global fresh-water cycle. If we dirty all of the fresh water faster than the earth can clean it, we're going to have to start drilling for the fossil stuff in hard-to-reach places. It's strange to think there would be drilling rigs in the ocean with people risking their lives and taking danger pay... for water. It raises a question in my mind: affordability. Who is going to be able to afford to buy all their water like this?

It's the next step now that there are several major rivers no longer reaching the ocean.

Using whole fingers for binary is more useful on a table or when trying to remember numbers.

On the go, I find myself using the finger-bone counting method, where you use your thumb to point to each of your finger bones (3 per finger) allowing you to count 12 on a hand. This probably has a name since it's so easy. And 12 has lots of really nice factors when doing math on the go.

If you point at the joints plus the tip of each finger, you have 4 positions per finger (i.e., nibbles), which can be useful for working through power-of-2 stuff.

When I was a kid I remember imagining that the dinosaurs managed to create an advanced civilization, reaching the moon, creating cities, tried to harvest asteroids but accidentally wiped themselves out after a major mistake, eliminating the evidence for their civilization in the process.

This was after reading The Crucible of Time by Brunner (one of my favourite books)

I think it's a reference to the supernova that occurred before our sun existed, which created the seed material for the sun to form from. It had to have happened because there are heavy elements on earth that only form in a supernova.

Earlier generations could have said the same thing before each of: the internet, petroleum, flight, biotech, robotics, atomic bombs, the electric grid, the automobile, etc.

AI, nanotech, biohacking, and other possible future technologies just don't seem anywhere near as disruptive as that first list. They'll get incorporated into the "business as usual" machine if they come to pass at all — and much more easily than, say, atomic bombs were.

I like my 30", and wish for more (4 side-by-side windows!). I suspect people who don't like big monitors tend to make their windows fullscreen instead of keeping them content-sized. If you think in windows instead of maximized screens, 50" is superior to 54" split in two. It comes down to the artificial split down the middle which limits where you can stick your windows.

I try to do my estimates (team size, man-days) in Big-O notation. Haven't nailed how to do that yet, but it helps people understand that estimates are non-linear functions.

The demo videos seem to suggest it works at 60hz, including 3d and videos. If true it's a bit of a game-changer — I could move even more stuff onto my home server (assuming we get the bits, and not just this cloud BS)

Standard with one time pads (and symmetric encryption in general) — the key and plaintext are a shared secret.

In one sense, we're "in space" more so than people on the space station — there are no walls between us and the stars, just a gas that tapers off to zero with us clinging to our rock by the merest force. It gives me vertigo when I try hard to comprehend that.

We have a really big C++ codebase at work and I find codesearch[1] to be the best way to search through the code, although the UX is terrible compared to Ack/Ag. Another problem is that it's written in go; so hard to get builds for the AIX PPC machines. Faster than everything though -- running a complex regex against 2-3 million SLOC and getting an answer within a second is certainly worth something.

[1]: http://code.google.com/p/codesearch/

This would require some sort of single-sign-on, or capabilities system. Would love to see capabilities-based security for web services, actually. "Here is a token that grants permission to service X to perform action Y for duration Z." Can OpenID and ilk do this?

Anyway, apps that don't need security should be as you describe already.

Best argument I've ever seen for not wanting to work at Facebook... wow that's a lot intertwined spagetti code.

Our source repo at work (a C++ compiler with full commit history going back to the early 90s...) is smaller and more componentized!

The advantage of "everything-is-a-file" is that every process gains thread-safe access to some API without having to pull in the headers, link, and manage a foreign memory management regimen.

But the real boon is that each process can conceivably be linked with any 'file'. I liken this practice to the STL library's iterator pattern: algorithms are the processes, and files are the iterators (although I bet STL was inspired by unix). You can redirect your tty through an ssh tunnel, you can scp a regular file, or you can ssh tunnel your soundcard or mouse. And of course 'ssh tunnel' is only one such kind of glue. There are pipes, devices, fifos, etc. In the end it works out that there are O(n*m) possibilities for only O(n+m) implementation cost.

But remember that with STL, not all algorithms will work with all iterators, and vice versa. And likewise, not all processes can work with all files, and vice versa. The benefit comes from the significant overlapping portion.

Stores are focused on individual wait times, not on total throughput.

Types define the encoding for some pure mathematical thing, and they define the set of things that can be done to objects in that encoding. Something is the same type as something else iff they share representation and a particular set of operations. There are ideal types, and there are practical types.

UTF-8 and Unicode are great examples of a practical type. Null-terminated UTF-8 is a type, but unicode is an alphabet of characters in the abstract. The type called "UTF-8 string" has certain permitted operations, and a particular representation in machines.

Another good example is the set of all integers modulo 2^x, and the type consisting of unsigned x-bit binary integers for x86-style processors. The x86 add operation is permitted only on the later, which makes it a distinct type from, say, the PPC integer type. (so does endianness, but that's encoding, not the op)

Ideal types are things like sets, trees, lists, and so on. Their encoding is such that all everything is possible. Look at any functional language. These things are in math, although often less formally defined. The only problem with ideal types is that bottom is a member, which is a problem for some operations permitted on said ideal type.

To put this all another way, types convey something terribly important: What is this thing, and what operations can I do with it. In math, we tend to hand-wave both of these things away, and instead rely on human intuition to determine what something is (set, integer, field, vector, etc.) and what we can do with it (intersect, add, integrate, rotate, etc.) But if you look hard, you'll see types in math. Vectors are bold, fields have arrows, integers have an initial assignment, sets are capital letters, and so on. A human must do type analysis to figure out of an operation or encoding is conforming.

This is an excellent example of cargo cult thinking. If we build the airports and control towers that look right, the cargo will flow!

My position on the matter is that patenting software or other mathematics should require full disclosure of the source for the system. If not expressible in a full-blown language, it's not patentable (e.g., one click).

Let's shorten the length for software patents. For the duration that it is valid, the patent office simply acts as a custodian of the code, ensuring that it works and certifying that it is novel. The patent office should maintain (or contract a company like GitHub to maintain) the repository of pending public domain source.

And once the patent expires, the source is released into the public domain, still under source control.

We can also strengthen prior art rejection of bad patents.

Finally, give enforcement more teeth, but narrow the scope to match more closely what is checked into the repository.

A system like this is more in the spirit of what a patent is: a temporary monopoly with a public-domain disclosure of the idea at the end of term.

3) double-tap home, then hold finger on app you want to terminate. the icons in the task switcher start to dance. click the terminate button.

It looks to me like a woman with arthritis covering her face from the (large) film camera across the street. That might be why she turns to look at the last frame, as well -- curiosity combined with fear.

Requiring a code-sample will increase the false-negative rate quite a bit. A lot of employees can't provide samples of their work because of NDA, contract, or other legal reasons. In a perfect world, everyone would have some side-projects, but not everyone has the time for side-projects or is permitted to contribute to open-source projects. For instance, my employer requires that I can't admit that I work on (well known) open-source projects.

Granted such companies are pre-lithic in nature, but none-the-less, employers will miss out on great people because they think publicly available code samples mean anything at all.

Also consider that blogs get different comment rates depending on what they are about.

My wife's blog gets about 10+ comments per post with only 100-300 uniques per day. Sometimes a traffic spike will bring in a bunch of extra hits, but the amount of comments left after the spike depends on who was coming in. If it was a bunch of web developers or something: zero comments, even over thousands of hits.

A minor conclusion I draw from this is that blog comments come from community people, visitors and fans who keep coming back.

The "jadedness" of the community is a far bigger factor though. Some people are on a quest to consume, and not necessarily to participate.

There is an existence proof "for some value of objective": Your and my own subjective tastes are also an objective determinant. With enough data from people, one might find some function over the domain of colour that yields pleasing combinations.

I'd suggest you put your candidates up on http://www.colourlovers.com/ and have them vote.