electrograv

1. IMO you're using the wrong text matching algorithm for file search. This is pretty critical, considering it's the main interface for opening files.

Zed seems to search for simple text substrings only, whereas both Sublime Text 2 and Xcode look for the longest common subsequence. This is huge, for me at least; in Xcode or ST2 I can type the first few letters of one of my files, followed by a few more letters from different words in it, followed by ".cpp" and it finds the file.

Zed (as is) is completely unusable to me, because my project folder contains many similarly named files (.h, .cpp) as well as a ton of other source files from external libraries/modules with similar sub-words with what I'm searching for which for some reason always show up first and saturate the search results. With Zed there's no way to narrow down to what I'm looking for besides typing in the full name of the file. With ST2 or Xcode this is not a problem due to LCS.

2. This is not your fault necessarily, but it's a big deal to me: Text rendering is slow in Zed (and in every other web-technology-based code editor I've tried, e.g. Light Table).

For example, scrolling is even choppier than Xcode. The primary (if not sole) reason I moved away from Xcode to ST2 was because Xcode's horribly laggy UI was driving me crazy.

This is a bit of a personal rant, but we're living in an age with multi-gigaflop CPUs and multi-terraflop GPUs, yet we have somehow regressed to a point where scrolling (of all things) is laggy? IMO this is absurd, as an industry trend in general. For this reason, I generally dislike the trend to write everything (including local apps) in HTML/CSS/JS. These technologies really weren't designed to support this sort of complex dynamic UI. While it's quite impressive what's possible despite this, the stress of forcibly warping HTML/CSS/JS to accomplish some of these UI feats shows through as horrible inefficiency.

Chatbots that perform the best on a traditional Turing Test are all extremely specialized 'bag of tricks' approaches. They can be surprisingly convincing, because they often use huge databases of real human responses to construct their own -- if you haven't already, I'd recommend giving Cleverbot a try[2].

However these chatbots often fail when an important continuity of facts is being discussed in context, where their parrot-like nature is exposed. Therefore I think this "TED XPRIZE" will be much easier to fool in this sense, because there's only two questions from the judges. This essentially removes the most difficult AI challenges of a traditional turing test.

Of course, succeeding at the "TED XPRIZE" would without a doubt require legitimate and significant advancements to the field of artificial intelligence and machine learning. Synthesizing a convincing talk/essay with an engaging narrative and central theme is no easy task (though limited successes already exist [3]).

But even now computers can beat humans in very specialized areas (and specialization is a key requirement to this). For example, we already have human level-facial recognition[4] and superhuman character recognition[5]. Similarly, while it would indeed be a legitimate AI advancement to be able to construct such a speech, I do not believe this would be any more a holy grail of AGI than character recognition and facial recognition. Instead, it would be incremental progress disguising itself as having already arrived.

[1] http://www.xprize.org/ted-rules

[2] http://cleverbot.com

[3] http://www.geekosystem.com/journal-accepts-nonsense-paper/

[4] https://www.facebook.com/publications/546316888800776/

[5] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.84.1...

Please implement this RFC. I really hope this gets in before Rust 1.0. I'm extremely excited and looking forward to using Rust in all my hobby projects once it stabilizes, but honestly when going through the tutorial this stood out as the only ugly wart in an otherwise amazingly beautiful language.

Flying machines vs AGI makes a much better analogy. Natural flying machines (birds) existed in nature, before artificial ones (planes) were invented. Artificial manned flight was speculated as a possibility for centuries with no macroscopic working examples, and heavily criticized as a transportational panacea/fantasy that was seen as clearly impossible to people at the time.

In fact, the analogy extends startlingly far. People doubted the possibility of manned flying machines for the longest time, with arguments strikingly similar to yours, e.g. 'We have no proof that such artificial flying contraptions can exist!'. Explaining away natural flight as a supernatural magic only accessible to birds is also eerily similar to the constantly retreating dualistic arguments against a mechanical brain.

Even your criticisms of current AI has analogues[2]. Long ago, even in ancient times, there is evidence of small "toy" birds that might have flown much like paper planes. Many similar toy examples existed around the 19th/20th century, too, yet many people still vigorously doubted the possibility of a flying machine that could carry a human.

Let's compare a paraphrase of common arguments against heavier-than-air human flight, with a paraphrase of your argument:

Of course we have natural examples of flight, as we see birds all around us. But there is no more evidence for human flight than there is for Bigfoot, leprechauns or space aliens. Sure, we have little toy examples of flying machines, but they're very limited -- the idea of full heavier-than-air human flight requires a leap of faith.

Vs.

[Of course we have natural examples of AI, I, the author presumably am one.] But there is no more evidence for AGI than there is for Bigfoot, leprechauns or space aliens. Sure, we have little toy examples of AI, but they're very limited -- the idea of full AGI requires a leap of faith.

[1] (Obviously I'm not referring to fusion or anything like that, because people of that era wouldn't have recognized that as transmutation.)

[2] To be fair, I think it's safe to say old-school non-probabilistic AI is dead. But just because one path ends doesn't mean there aren't a thousand others constantly exploring new ideas. Indeed, recent advances in deep learning are incredibly promising.

Deep Learning generally refers to machine learning algorithms that deal with stacking multiple layers of simpler functions to enable more complicated functions, and optimizing all the parameters to best fit your training set and generalize to new samples (the hard part). Though it usually refers to neural networks, I dont think there's any reason it doesn't also apply to other layered approaches as long as there's a relatively unified learning algorithm applied across the whole system.

There are clearly many different deep learning algorithms, even if you just count the permutations of tricks you can choose from to improve layered NN generalization. Though to be fair I think very good progress is being made towards developing "better" algorithms in the sense that new ones (e.g. RBM pretraining + dropout) usual perform better than than older algorithms, no matter what data you use it on (now network architecture is another matter entirely).

But this isn't true everywhere. Imagine if Google's servers cost 100x more to run, if they didn't spend time to make their code efficient. Imagine if your video games ran at a frame rate 100x slower than they do now. Imagine if your phone sucked 100x more battery power, and lagged 100x longer after each tap.

Sounds like I'm making extreme hypothetical examples? Not really, when languages like Python and Ruby can be over 100x slower than other high level languages (e.g. Java, not to mention C/C++).

And of course, the counterpoint is usually "But most of the time is spent in the database/[some highly optimized library], not the high-level logic." To that I reply: You're absolutely right. Guess what those subsystems were written in? C/C++/Java, most likely.

If you're fortunate enough to have all your performance-critical components already highly optimized and written for you by experts at bare-to-the-metal efficiency, you probably don't have to think about this. But if you're working on a technology truly new and unique, chances are you're going to have to "get your hands dirty" at some point if you want to avoid paying 100x more than is necessary in server fees.

A single self-hosted compute server that costs ~$20/month in electricity to run 24/7 would cost over $1500/month from AWS.

I'm inclined to agree (with what you explained) as well. But, if this is conveyed by the article/graphic, it sure is subtle. I think it would have been a better article if he just explained his complaint (if it is as you say), rather than making a mockery of celebrity quotes with big sarcastic quotes next to pictures of their faces.

> In the context of Victor's body of work (which is focused more or less entirely on making the incredible power of computers more accessible to more people), I have a hard time believing that any such motivation underlies the linked piece. While I think there definitely exists such a motivation in other criticisms of the learn-to-code meme, I don't think it has much to do with Victor's critiques.

Yeah, I was mostly referring to the negativity towards code.org and coding as basic literacy in general, not this author specifically. But that's good to know at least in this case he's not one of those people.

Quite frankly I'm shocked and confused by some of the negativity I've seen expressed (including those from the HN community) towards code.org, and the idea of programming as a basic literacy in general.

It seems like these people will do almost anything to find something about this idea to pick on, ridicule, discredit, and otherwise attack. Seriously, last time this came up on HN the majority of the discussion was about how horrible it is that this movement uses the phrase "learn to code" rather than "learn to program".

Now it's ad hominem attacks against musicians/artists advocating literacy and education -- and what do those attacks say? "Congratulations [...] for having an educational philosophy that's not completely unreasonable and horrifying." What a disgusting backhanded "compliment". Is there something about being a musician or artist that disallows one from having a valid intellectual opinion taken for its own sake, without being patronized?

"Aww isn't that cute! A musician/artist having an intellectual idea that isn't completely terrible -- like a quaint little animal trying to imitate us true intellectuals up here in our high tower of superiority." I exaggerate, but this is basically the elitist mentality I perceive behind the actual quote.

To me, this comes off as a desperate attempt to defame this movement because it threatens to demote the status of basic technology roles from "elite magic" to "basic literacy" -- and to some people, apparently that's not an amazing social good, but a terrifying prospect of power loss. Am I way off base here in perceiving this?

To address the main point: So what if some person never intended to claim that learning to program makes you smarter. Coding is becoming more popular, more socially acceptable, and viewed more positively not only as a career choice but as a basic literacy that will be extremely important in the future (which is true). That's a good thing.

I'm sorry, but you have your science backwards. You don't dismiss evidence because it doesn't fit your current hypothesis.

Most significantly though, you grossly misunderstand statistics/surveys if you think it's possible to extract definitive physiological truths out of a subjective "how do you feel about remembering X?" survey.

For what it's worth anecdotally, I also can access memories from when I was 3-4 years old, and I can easily prove they're not fabricated memories because the memories in particular were not retold, and in some cases took some effort to actually confirm when I was the only one remembering them (even parents forgot).

Usually the memories are misc. trivia -- e.g. the design of the wallpaper of a house I only lived in until I was 4, a certain set of kids' cups I only used until I was 6, etc. There is no way these are false memories, because nobody told such things to me. I also remember some of my thoughts as a very young child, which is interesting, because they're very different from adult thoughts (though obviously I can't really "confirm" this in the same way I can physical memories).

Anyone saying childhood amnesia occurs completely is completely misguided. Of course, I have "childhood amnesia" like everyone else in the sense that most of those memories I haven't accessed in a long time, and can't recall them instantly at will. But they're still there, and I can access them with meditation if I want.

Unfortunately the GPU vendor divide still exists (mainly CUDA for NVIDIA, and OpenCL for AMD/Intel) with no immediately obvious solution. For example even the Rust-to-PTX compiler from this article will fail if you try to run it on AMD, or Intel, or anything but NVIDIA because PTX is an NVIDIA-only pseudo-assembly intermediate format. Projects like "gpuocelot" promise to translate PTX to run on other GPUs, but until such translation layers reach maturity (and don't sacrifice any performance in the process of translation), OpenCL will remain the only viable "intermediate" format that is truly GPU-agnostic.

Which is really a shame, because quite frankly OpenCL is horrible to develop for multiple GPUs, because each GPU vendor has their own OpenCL compiler with a slightly different interpretation of the spec (not to mention severe performance differences between OpenCL and CUDA for NVIDIA GPUs), plus their own proprietary extensions. It's like writing C code that has to run on N different, immature, and mostly quirky compilers all with their own different subset of features, where N is completely unknown to you -- in fact N will grow over time after you release your application.

That said, I agree with this criticism of "procedural content" completely. A while ago I created a little toy WebGL tech demo featuring "a vast virtual 3D universe containing billions of unique stars and planets" (it's open-source on github if anyone's interested) -- so I encountered this issue first-hand (and saw it come up many times elsewhere in the past, of course).

IMO, the fundamental problem lies in a subtle distinction between "infinite variation" vs. "infinite novelty". Most procedural generation amounts to not much more than random noise passed through a variety of hand-tuned filters and/or custom code. In most cases it's how you tune that filtering and custom logic that leads to any amount of interesting results, not the underlying random noise generator (from which the too-good-to-be-true claim of "infinite variety" is derived).

I don't think it's completely impossible to derive interesting variation from a combination of mathematics and randomness, but I think the degree to which we find something interesting or "novel" is at least somewhat related to the amount of computational complexity put into its derivation (at least, that's my intuition on the matter).

Several times I tried expanding an existing modular 3D engine (OGRE) towards my goal of displaying a huge virtual universe of planets and stars. While I got it rendering 3D planets after some work (where I basically had to implement manual rendering code anyway, since the engine didn't support the odd use-case of spherical terrain), contorting it to support massive coordinate spaces, huge view ranges, dynamic loading/unloading etc. was just far too messy to even hope to attempt in that engine.

After several attempts to cleanly implement a space-scale engine as an extension of an existing engine, I started over from scratch using pure OpenGL (WebGL). And this time, I managed to keep the code reasonably tidy while supporting trillions of stars, planets etc. as I had originally planned [1].

Would I have been able to do the same thing in OGRE if I kept trying? Probably... but likely with far more ugly code, terrible hacks, bloated engine, and slower loading times.

To be fair, I'm not advocating always "rolling your own" 3D engine. It's usually a huge task, and using a pre-existing engine will in almost every case be the smarter choice. But with some people trying to argue "you can make it fit in [Unity/OGRE/etc]", I thought I'd provide at least one anecdotal counter-example.

1. Kosmos: A virtual 3D universe in your web browser (https://github.com/judnich/Kosmos)

Keep in mind I'm not saying it's a deterministic inherited thing (it's clearly not). However I believe there is strong evidence that everyone is born with a unique personality and potential. An "environmental chaos theory" does not do justice to unexplained outliers, those with recognized mind-affecting genetic conditions, and many other real-world scenarios.

My situation is even more unusual than you realize. I didn't even meet many people while growing up; throughout my childhood I was almost entirely separated from the outside world (lived secluded in the mountains). Almost no neighbors near by. I never went to public school. Extremely protective parents did not allow us to ever talk to strangers. All this is the same case for my siblings, yet they have no desire to pursue technology, while I do.

Note that by no means am I trying to downplay the importance of environment. I'm simply trying to illustrate that the claim "environment determines 100% of someone's mental and personality development" is empirically wrong.

To provide just one example (out of many, I'm sure): I was born into a very poor (far below poverty level) working class family that was extremely techno-phobic. Despite being actively discouraged almost throughout my childhood of pursuing an intellectual career, I always had an intrinsic motivation and desire to learn and create tech-related things. This ultimately lead to where I am now, as a software engineer (and I'm definitely the only one like this from my family, a clear outlier).

To this day I can't come up with a single environmental influence that explains this -- and believe me, I've tried. I don't mean for this example to detract from the positive message of the article -- that talking to children is very beneficial to their cognitive development (obviously) -- but hopefully to demonstrate that it's a lot more complex than just environmental factors.

This is so wrong (at least as a stereotype).

All throughout my early education I HATED arithmetic, and found almost everything about it mind-numbingly boring and repulsively repetitive. At that point in my life, I hated math. The moment I encountered algebra though, it was "love at first sight", and ever since I've absolutely been fascinated and engaged with every type of high-level math I encounter (the more abstract, the better). And not just "fascinated" in the "I like it" sense -- math, CS, etc. is more easy/natural to me than most humanities subjects, by far.

So although I can only speak for myself, I quite disagree with any claim that the brain isn't naturally suited to abstract thinking. While I know not all people think the way I do, certainly quite a few do.

It's also important to realize that these aren't beliefs, or truth claims, or scientific claims. They're philosophical perspectives; no more, no less. They might guide the intuition, but have no bearing on the science itself. Someone who doesn't clearly understand the distinction between the philosophy and science of a topic may definitely risk either contributing to the "depressingly common fallacy in science" you mention, or risk misinterpreting a philosophical argument for a scientific one, and hence through blurred vision believe they see fallacy when in fact there is none.

One way of looking at it is both views are different philosophical angles of the same thing (or at least the same problem/mystery). A connectionist sees this conception of a "shared language of representation" as assigning a sacred mystery (what does this language actually consists of, precisely?) to an as-yet unexplained phenomenon, in the same way a computationalist sees this of the connectionist's learning algorithm (how does this learning algorithm work, precisely?)

The reason I highlight this philosophical symmetry is to emphasize that these are merely different intuitive mindsets developed towards approaching the common mystery of general intelligence.

The bottom line is so long as human-like "general intelligence" is a mystery (to the extent that we can't replicate it 100%+ effectively in computers), it's going to be an "unexplained phenomenon", and thus any theories developed around it will have some "magic" hole somewhere -- some key element devoid of predictive power. (Because if there were no such hole, then by definition, we'd already have it all figured out.)

What you express in the quote above is a very "computationalist" view to AI. FWIW, in contrast, I'm more of a "connectionist" [1]. This means that when I look at the same incredible "general intelligence" of humans -- this almost "synesthetic" ability to abstract and connect ideas -- I do not see a powerful translation and symbolic reasoning machine with some seemingly magical universal language buried deep within. In fact, I believe there can be no such language without severely compromising the reasoning system's generality.

Instead, I see a powerful "connection machine", where concepts, thoughts, language, etc. are all the result of some incredibly versatile connective learning/creativity process. Of particular importance, I see this connection machine thrive and prosper within systems where there are no axioms, no ground truth, no single agreed-upon notion of what separates "this" from "that" (you'll see this in humans when studying philosophy). The analogy to this notion from a computationalist perspective would be a machine whose instruction set, or core reasoning language, is always in a state of flux.

I will freely admit though that one view does not necessarily have any more explanatory power than the other; they both rely on some "magic" unknown assumptions. For a connectionist, the "magic" is the connective learning algorithm. For a computationalist, the "magic" is in this universal language/symbolic system.

Disclaimer: I'm by no means an AI expert (still have a lot more to learn!), but I always enjoy thinking/discussing these topics and the surrounding philosophy.

[1] http://en.wikipedia.org/wiki/Connectionism

> Layer some octaves of simplex-noise to form a terrain, and then for any non-occluded map region, "grow" a building from the center of each noise feature. Might be possible to only tell the GPU about the terrain-texture, and create the buildings entirely in a shader, actually.

It's possible to generate the simplex multi-fractal texture itself on the GPU purely using GLSL via WebGL [1].

Growing buildings from a heightfield texture purely on the GPU though is a bit more tricky, because you don't want to scan the entire hightfield redundantly every frame to extract noise features. In other words, you'll want to cache this feature data, then "grow" the buildings, then cache that. It may be possible to hack OpenGL/WebGL into doing something similar to this on the GPU, but honestly OpenCL/WebCL will make this so much cleaner to implement I shudder to think how ugly this would look in GLSL.

So I would actually use the GPU to generate terrain heightfields (a good use of its massive parallelism), then a special shader to detect features (e.g. even something as simple as a few order derivatives at low resolution) and download them to the CPU. The CPU would then generate and compile a list of building coordinates, upload to the GPU, and use the GPU to perform instanced building rendering from them.

[1] https://github.com/judnich/Kosmos/blob/master/README.md

Edit: Apparently, according to other commenters, there are already open-source autonomous quad-copters you can hack on, which is great news to me! (And you can buy the hardware preassembled).

Otherwise, how can a "decentralized, infrastructure-less" system really guarantee any privacy beyond simply making it more of a hassle to wiretap?

This is actually precisely why I'm abandoning WebGL in favor of Native/OpenGL-ES for future versions of "Kosmos" (I intend to eventually make a game) - WebGL is plagued with compatibility issues, for all but the most traditional/simple GLSL shaders.

Since all the planets in Kosmos are procedurally generated on the GPU, this requires rather complex GLSL shaders (GPU code). Sadly, even with a lot of ugly hacks I've only been able to get this to work on Windows for Firefox, after hacking out a lot of features. It works great on Mac/Linux in my testing though, as long as you have a sufficiently modern GPU that supports modern OpenGL.

The compatibility issues I think are mostly due to ANGLE (http://code.google.com/p/angleproject/), which is Google's so-called "compatibility" layer for WebGL used in both Firefox and Chrome on Windows, apparently. It actually takes your GLSL shader code, and rewrites it as it sees fit. This would be fine if the rewrite didn't break things, but sadly, it breaks things.

But ultimately, the user doesn't care about excuses. The user cares that they see a black screen with no content. Hence, I'm forced to abandon WebGL and go back to native code + OpenGL[ES]. It was a really fun experiment though and I learned a lot in the process.

I don't want to detract from the article's main point with a cliche "algorithmic optimization beats fine tuning", but I think it's worth mentioning. Unless I'm mistaken, this particular problem can be solved about 10,000,000x more efficiently.

    > Given two numbers X and Y, return how many numbers in that range
    > (inclusive) are palindromes, and also the square of a palindrome.

If the original algorithm runs in 10^N time, this would be 10^(N/2). For N=14 as mentioned, that's roughly a speedup of 10,000,000.

Edit: It seems I misinterpreted the question (which sounds like you're supposed to enumerate all palindrome numbers X>=N>=Y, and also print out the squares of those numbers). This is actually asking for a particular type of palindromes -- those which are palindromic squares of palindromes. As macobo helpfully points out, you can drastically optimize mathematically from this additional filter.

If you think Elon Musk is 100% correct that the reporter was a liar, or that the reporter was 100% in the right for publishing a big picture of a Tesla Model S being towed, you're going to be disappointed.

Both sides are upset, extremely opinionated, and have their own slant on the matter. Both sides made mistakes, and probably could have held back on a few things they claimed.

Elon Musk should have focused just on the obvious faults of the reporter -- like how the reporter probably should have more clearly highlighted that he literally began a trip for X miles with Y miles range displayed on the dash, where X > Y by a considerable amount (rather than burying this fact in noise). Not little details like air conditioning and driving in circles to find the supercharger.

And similarly, although there's disagreement over what certain Tesla reps may have recommended over the phone, it seems at last slightly disingenuous to post a big photo of a Tesla Model S being towed given the fact that he started and forced a trip of length X when the car showed range Y on the screen, where X > Y by a considerable amount.

Saying that you lost respect for Elon Musk is your right. However I personally haven't lost much if any. He was defending a cause he felt strongly about. What was the reporter's motivations?

The article was clearly slanted. So was Elon's rebuttal, but with every force, expect an equal and opposite reaction.

I'm not condoning the rebuttal, but I would put it this way: I understand and sympathize with Elon's overreaction far more than I do with the reporter's initial motivations to slant the story. And he very clearly did slant it.

> Just fix the car.

That's not really the issue, even if he could fix it. Which is easier said than done; we're dealing with advanced material science here. You can bet his team is hard at work on it, but this is the kind of thing that takes many years of deep research. Let's deal with the issue at hand (slanted articles vs slanted rebuttals), for now.

    Triangle Setup
    Xbox 360 - 500 Million Triangles/sec 
    PS3 - 250 Million Triangles/sec

    Pixel Shader Processing with 16 Filtered Texels Per Cycle (Pixel ALU x Clock) 
    Xbox 360 - 24.0 Billion Pixels/sec
    PS3 - 16.0 Billion Pixels/sec 

Almost nobody used "cell processors" to potential initially, and for very good reason [2]. The bottom line is they were incredibly difficult to program for in any useful way to graphics. But more than that, they are limited in very specific ways [3]. They won't increase triangle throughput, and they don't directly increase pixel throughput.

In some extremely rare cases, some game engines found a way to use them for graphics (like Battlefield 3's Frostbite 2 engine towards the deferred lighting passes). But by the time engineers found a way to leverage this extremely complex architecture, it was already too late. If you actually look at most Xbox360 vs PS3 games side by side, the Xbox360 often looks much better.

In this case though (the next gen Xbox and Playstation) the situation is reversed: Sony's GPU is actually legitimately faster, and by a large margin. Not only that, but having a full 4GB of fast ram is a HUGE advantage to Sony. High performance 3D rendering is inherently a bandwidth hog, because everything on the screen must be pushed through the pipes every single frame. Having a fast 32MB cache doesn't really help you if you want to consistently and smoothly render more than 32MB of content on the screen. And moreover, just as the last generation PS3 had an overly complex architecture making it difficult to reach its full potential, it seems Xbox and Playstation are swapping roles here as well with this generation.

[1] http://forums.gametrailers.com/viewtopic.php?f=23&t=7947...

[2] http://www.videogamer.com/ps3/saints_row_2/news/two_or_three...

[3] http://stackoverflow.com/questions/1355827/what-does-program...

Of course a simple "widget" library is relatively easy to make, provided you already have powerful drawing and text functions. Then you realize, integrating text entry and copy paste consistent with the operating system gets much more tricky if you're making all your own widgets from scratch. More complex rich markup is even harder though... getting text to flow around correctly while achieving the layout you want at the same time. I think CSS does a fairly good job here, but I think we can do better.

A lot of the work before you even get to this stage though lies in good cross platform drawing and text rendering. OpenGL support is a 'must', of course. Then, 2D and vector graphics need to be implemented. OpenVG is supposed to provide this, but is useless as a cross platform solution, because it's only supported on a handful of mobile only systems. So I'd either have to implement all of OpenVG through OpenGL (and I certainly don't look forward to implementing the mess that is SVG) to get HW acceleration, or make my own VG library.

But that doesn't even solve text rendering. Text rendering western fonts is relatively easy, but it gets much more complex when you need to support unicode cursive fonts like Arabic with HW acceleration consistently. Fortunately the actual shape generation is already solved in the GNU world, but caching fonts efficiently on the GPU and with smooth antialiasing is another matter. It would be nice to just use the operating systems text renderer, but not only would the results be inconsistent across platforms, but I don't think it's possible to do this on an OpenGL framebuffer on all platforms.

So once I have HW cached text rendering, and vector graphics, only then can I even start thinking about building a widget library on top of it.

So it's much more complex than it initially sounds when you have to essentially reinvent the entirety of what the OS GUI API should provide. And if you can't settle for lowest-common-denominator functionality provided by all OSes, then reinventing the wheel is your only remaining option.

I know how to do all this, it's just a lot of work. If I was working on it full time it would go fairly quickly, but it doesn't seem to be a very profitable task so that's not feasible right now.

The language issue ultimately leads you to conclude that we need a browser with a built-in VM, rather than a built-in scripting language. It makes so much more sense, as a clean and elegant solution.

"I know! I'll make my own new browser with an embedded VM and newer cleaner APIs, and revolutionize the web! It'll be amazing, allowing native-like performance from the browser. WebGL will finally achieve performance feasible for high quality games, the need for full native apps would be tremendously diminished, etc. etc."

JVM is a well known example of a cross-platform VM, which tried to enter the browser via Applets. I think Java Applets failed because they were slow, ugly, clunky, and usually looked horrible and disturbed the web experience. Kind of like flash ads, but worse.

Microsoft Silverlight is kind of similar, but using the CLI rather than the JVM. As a plugin, it still wasn't seamless. And it had cross platform compatibility issues (not a fault of the CLI though).

The GUI issue (bloated DOM, hacky HTML/CSS) leads me to conclude that we need a new API stack for rendering GUIs that satisfies both web and application use cases without massively sacrificing memory and performance like the DOM seems to excel at.

But here's the thing:

Creating a new browser with a new VM and new GUI stack, all from scratch, is almost an insane undertaking. Sure, it's one I could almost see myself trying (being a perfectionist ADHD OCD coder) as a hobby, but I know better than that if I want to actually ship anything.

Ideally, I'd like to see some day a kind of "Mono Browser" - a browser that basically runs CLI code "scripts" in an otherwise traditional HTML/CSS stack for backwards compatibility. But the primary feature would be a new GUI stack completely disjoint from HTML/CSS for people who want to create blazingly fast and native-like snappy UIs.

It's fairly critical though to expose this new GUI stack, because otherwise it's just CLI-scripting-in-the-browser. CLI in a regular browser would be great IMO, but not a significant enough change for end-users to upgrade to the browser. Moreover, such a API stack would be extremely useful for cross-platform developers even of native apps. It would essentially compete with web-based cross platform frameworks like PhoneGap, and native ones like QT (though QT IMO is ugly and old fashioned vs web rendering).

So a great deal of work lies ahead in creating this GUI stack. This is something I'm kind of intermittently working on in my spare time. Unfortunately I'm usually kept quite busy on research work towards a PHD, but now and then I make a little progress. But if you know of others working on something similar, feel free to point me in that direction to collaborate.

"Ray Tracing" has always been an overhyped or misunderstood technology, at least in my experience. Because of the impressive lighting effects it's famous for producing, people view it as some "holy grail" of superior computer graphics technology that we just need to optimize a bit for use in games.

As Carmack described, those highly realistic ray traced renders come at a price: billions of ray calculations. You don't get all that pixel-perfect refraction, etc. for free (and probably never will - at least not with ray tracing.) He also explains that for most people, this (e.g. pixel perfect refraction) really doesn't matter, when rasterization techniques exist that achieve extremely high quality approximations at a fraction of the computational cost.

Conversely though, ray tracing and related concepts (ray casting) are not at all without value. Many modern video games today actually use a sort of hybrid rasterization / ray casting approach. Macrostructure objects are rasterized the normal way, while smaller high resolution detail patterns (like a brick wall, or stones in the ground) are "added" to surfaces via per-pixel displacement mapping, which is ray casting at its core. This is one of the few cases where you can take advantage of the "log2" efficiency Carmack mentioned -- in a highly specialized implementation without a huge time constant.

1) It sounds like companies are hand picked. On the other side: How do you filter for great developers? I'm sure you can't assume every prospective employee signup is a top-tier developer. Do you have some algorithmic, human, or other process?

2) As someone about to graduate and transition to a PHD program after the summer, I'm looking at technically challenging summer internships. I'm sure there are other prospective interns. Do you have any plans to support matching summer internships?

3) Assuming a github profile is the only "resume" your site accepts (implied by another comment here), where do developers list journal and conference publications? (Apologies in advance if this assumption is wrong -- I haven't signed up due to reasons mentioned in question #2.)

Thanks!

All I can say is: Yellow gradient smeared over sky blue? Seriously? I just... I don't know what else to say.