madflame991

We can already do that even if the shreds are 1px wide https://github.com/robinhouston/image-unshredding

> If it's faster, they can benchmark before and after

That goes bad very fast. I've worked with someone who tried winning arguments with one-line microbenchmarks; They even tried to convince me that I should always use undefined over null in JS since one is faster than the other (forgot which).

> Introduce them to the concept of static single assignment form

I failed with this as well; some coders don't trust the compiler/runtime at all. I had people tell me that garbage collectors don't deal with cyclic dependencies or that "simple comparisons" (<, >, ==) are faster than "compound comparisons" (<=, >=).

Not all languages in the "Lots of Supported Languages" are actually supported; i.e. Greek, Turkish, Swedish...

No need to mutate/slice/sort anything

    Math.max(...lines.map((line) => ctx.measureText(line).width))

That's why I recommend jams like Ludum Dare [1]. You're constrained to 48 hours. You can't waste time on writing an engine in that amount of time; you can't work on anything else than the game content itself.

[1] http://ludumdare.com/compo/

If it had a date I would have said "OS on xkcd from a year ago - ah, seen that". If it doesn't have a date it must mean it's new and I _have to_ see it.

Whatever happened to learning something to broaden your view? I doubt I'll get a job in Clojure anytime soon - but learning it has been the biggest eye opener to me as a programmer in the last 5 years.

> The answer to all these questions seems to be "no".

In conclusion you shouldn't be learning it and good luck to the company trying to hire people for Rust positions?

You're saying you should only learn what the industry is pushing towards. The thing is that the industry is pushing towards what sort of talent they can acquire - this is a vicious cycle.

The title is incorrect; you need "!" and the only reason why I clicked on the article was that doing it without "!" would be a BIG deal. The title of the original article is "A Javascript journey with only six characters" and the topic has been posted/reposted and explained more times than I can count on HN

Your mere presence provides value for them as you are part of the reason why your friends are on FB.

> “Data that comes off a mechanical disk has a subtle warmth and presence that no solid-state drive can match,” the cogniscenti will tell us.

Probably not

"The new engine will meld the best characteristics of gasoline and compression ignition engines with an innovative piston architecture refined by Achates Power that sets two pistons moving in opposition in one cylinder."

We already have this technology. Diesel engines ignite the fuel through compression. We also had the opposing pistons layout for a while (https://en.wikipedia.org/wiki/Opposed-piston_engine).

EDIT: we even have triangular-y shaped opposing engines (https://en.wikipedia.org/wiki/Napier_Deltic)

Managed to close it twice, but it took a while. I don't understand how a single application can render a whole (multicore) system unresponsive. Isn't the OS supposed to take control from a long-running task once in a while? I've encountered dozens of other graphical demos in JS that cause the same thing. I'm running Chrome 48 on Linux.

> Haskell, for instance, is mind blowing.

Mind blowing is the amount of output and obscurity of the error message you get from the type checker. It's harder to understand the error message than to debug the program if compiled "unsafely".

I was wondering the same thing; I had to check on wikipedia that indeed consumer-grade 64 bit processors were on the market in 2003 (AMD Athlon 64). I also remember Windows XP and Mandriva had support for 64 bit processors at the time. This launch doesn't feel like the celebration it should be.

There are type inspection tools for JS - Webstorm has one and then there is the open source tern.js and facebook's flow. I imagine in erlang it's a bit easier to infer types in erlang because it's immutable and because functions don't just take whatever amount of arguments (like in JS). I'd say erlang is not as dynamic as JS.

The research around erlang is due to the fact that it's heavily backed by Ericsson and the university in Uppsala (it's common for Uppsala master theses to be erlang-related). The other languages have more "neutral" origins.

"Almost every application that is being made ends up lagging in schedule, regrettably"

I'm grateful, of course, for the technological progresses we've made since '73, but how come this is still an issue?

> So, is this is a point in favor of not commenting your Javascript code or using inline docs?

You can of course strip comments when making builds. In fact you can even write functions of more than 600 chars and get away with it as long as you use a minifier. If you have a minified function of more than 600 chars then that's a bulky function which should instead be split in smaller ones.

1. Search on the internet and you might stumble upon lists like these http://www.quora.com/What-are-some-programs-every-programmer....

2. Search for images of "procedural generated art" - there are TONS of these. Pick a pretty/simple one and try to reproduce it.

3. Pick an esoteric programming language (http://esolangs.org/wiki/Main_Page) that doesn't yet have an interpreter/compiler and write one for it.

4. Pick an old piece of hardware and write an emulator for it: old consoles and home computers (NES, Commodore64, CHIP-8, etc). While writing the emulator you're going to need an assembler, disassembler and debugger to have any chance at debugging - these are bonus.

5. Try to port something to the GPU, something that's really awkward/challenging to port. Like a small lisp interpreter - I've no idea how to do that; early shader models aren't even turing complete.

While trying to nail down the last few bugs in my own chip-8 emulator I consulted other emulators on github (there are tons). Weirdly, some instructions behave slightly differently with every emulator. I found this guide to be the most complete one and hence thought it's worth bringing up. However, I could not find consensus on what "borrow" means for the SUB instructions (8XY5 and 8XY7) - most implementations set the borrow bit even when the two operands are equal.

You need about 250 points; I couldn't change the color 2 days ago when I had 227 and now that I'm at 267 I can.

Agreed, regular expressions are not turing complete and they can still make your browser ponder for a bit if carefully crafted. Try

  /(x+x+)+y/.test('xxxxxxxxxxxxxxxxxxxxxxxxxxxxx')

for instance. This regex doesn't even use non-regular extensions; it's expressible in a very limited computational model, it fits in a tweet and yet it renders my browser unresponsive.

I can do even more damage with a nasty shader; GLSL is not turing complete either (in fact it looks a lot like Crema).

"In no way should this promote you killing yourself, killing others, or killing in any other fashion."

You don't see this disclaimer too often

  Color = Data(function() ({ Red: {}, Green: {}, Blue: {}, Yellow: {} }))

Is this JS or pseudocode? There are some extra parens in there and the pattern repeats everywhere.

"I'd spend a month or two immersing myself in the technical, in the algorithms, in the memorization, and in the process push aside my creative and experimental tendencies."

Memorization is certainly not the way to learn how to solve math/cs/logic problems. There's a lot of thinking and (creative) experimentation involved when trying to solve a problem.

A lot of problems are classic problems in disguise. You'd be amazed to find out how many problems are just sorting + one traversal: reducing the average wait time in a queue, convex hull, counting duplicate elements (no extra space), interval scheduling, maximum number of overlapping intervals and a ton more. Can you memorize all of these problems individually? No, but you can ask yourself "how about if I sort my data first, what then?". If that doesn't work then try another question: "I have this brute force algorithm, if I use some other data structure will it get better?" - that question alone solves half of the problems I've ever seen. Follow up questions would be "does my problem look fractal-y?, maybe I can divide it repeatedly" or "can I incrementally build the solution?"

Even more interesting is that problems usually have more than one optimal solution: Prim's algorithms and Kruskal's solve the same problem in opposite-ish ways and use different data structs. How about substring searching: Boyer- Moore searches backwards, Rabin Karp computes hashes while others simulate automata. With self-adjusting binary trees it's the same story: a lot of very diverse solutions to the same problem.

Solving problems implies doing a lot of permutations and experimenting with data structures and classic approaches if you ask me - it's certainly not about memorising more than "sorting sorts and hash tables have constant-ish access time"

Is this process any different than changing colors, fonts and layout on a website until you get a good-looking enough whole? All you have to know are some principles about contrast, alignment, spacing and what not, and the rest is experimentation.

...and it gets even more interesting if you throw in a few circular references in there

You can make an interesting challenge out any one of the bigger (in LOC) functions of underscore.js or any promise library. You get a profound "a-ha" moment the first time you implement `deepClone` or `Promise.all`