Hacker News Reader

Comment by readerrrr | Hacker News Reader

This is really impressive and I'm interested in trying this.

But... the video shows a very specific example of programming where you are basically designing a map or a level. As soon as you are programming something else than a simple 3d game, it becomes less useful.

The major problem we are trying to solve here is managing windows, but I argue that normal screens already do that and you don't need VR.

A large screen or two plus using alt-tab and virtual desktops can completely and better replace virtual screens in VR. You have to move in the VR world to access information. On the other hand using a normal desktop where the information is represented abstractly( where in VR it is a physical object ) can be accessed instantly with a simple and fast key-combination. I simply don't see which programming activity could you do better in VR than in a normal desktop.

View on HN

OP here. Yeah, I was definitely not aiming for a full IDE here (obviously). It more like a playground environment. Something like CodePen for VR with a focus on the live-coding experience.

Using this app is comfortable but VR will definitely need higher resolutions for anything more serious. It's not too far in the future though. If things go well, I expect VR will be the driving force behind ultra-high-density 5" screens in the next few years. Or some entirely new display tech (retinal projectors?) will replace it.

I agree with Brian on this one, like I told him recently, IDEs were definitely next on my side project radar. I tried out the Gear VR and it's only about 1.5 times DK2's resolution (in both vertical and horizontal resolution) and it made a huge difference. At Oculus Connect I felt like a lot of the talks were about exactly this that we finally have a use case for way higher res screens instead of incremental demand that is only slowly cranked up by vested companies like Hardware Manufacturers and really early adopters.

I don't think this will replace your big screen(s) setup any time soon. That said, think about the mobility of a setup like this. Your psuedo-physical dev environment can move with you. I don't know if that's a good thing or not, but I'm certainly interested to see how it evolves.

It is trivial to implement that functionality in today's desktop mode without separating you from the rest of the system.

I'm trying to think of a good example where VR could be used but just can't.

It will probably be fantastic for stock brokers where their information relies on quick glances over a lot of realtime graphs/tables and if you look at their monitor setup today( +4 monitors ) the extra space will work for them. But when you code you are heavily centered on a single window and the rest doesn't really matter.

"""But when you code you are heavily centered on a single window and the rest doesn't really matter."""

For times like this you might want a completely black/white background, a forest clearing with very gentle soundscape or a quietly psychedelic lightshow/music all centered around your code window.

Some people's VR world will be serene and spare and some people's will be chaotic and full of the energy of a city street. It will be up to the user.

Some people will use the fact that everyone's brain benefits from both of those extremes at different times and use that to improve their cognition.

Your example is very idealistic. As a programmer you have to know how to concentrate, it is true that things like music( especially ) and surroundings help, but VR is overkill.

A company would never buy an VR rig for every employee just to maybe boost their productivity by an unknown margin. Also the learning curve would set them back by an unknown margin and some might have problems adapting.

Using your example, VR is useful, but only as an edge case where VR measurably help a person.

Surely the idea that a VR 'rig' will cost about as much as the monitors it replaces would change that though?

Only if you include the learning time and the lost productivity in that cost. In reality it will never happen.

Think of it as switching every keyboard in the company for a Dworak version. That will not meaningfully affect your average programmer's productivity, as their typing speed gained from a faster layout gives only diminishing results. Dworak only makes sense for a programmer that really benefits from >100 words per minute, and most really don't. The bottleneck it the programmer, not the input. The same goes for VR, unless you have a special case as I have mentioned before.

Let's say you type 300 lines of 80 characters of bug-free(!) code per working day of 8 hours. That is an pessimistic estimate( for my theory ), average is much lower.

Let's assume the average typing speed is 60 words per minute. That gives you 83% of the time not spent typing(!). Doubling the speed to a very fast of 120 wpm, only gives you 92%.

Here is one example: eye tracking could completely eliminate the need for alt tab or switching desktops. Put your keyboard's focus in a window by looking at it, and have it automatically recenter into your natural field of view. Still doable in 27" but not nearly as useful.

Just guestimating, I would need 11 or 12 27" screens to fully utilize the area I can see without moving my head. With gentle neck motion included I think that number triples or quadruples.

Let's assume; VR is much better than alt-tab and clicking at the taskbar. It will reduce the time taken by 95%. Assume 5 seconds average for non-VR method, which is a conservative estimate, this gives us 0.15 seconds for VR.

If you switch windows every 60 seconds, this gives us an improvement of ~8%.

Table:

300s -> 1.5%

120s -> 4%

60s -> 8%

30s -> 16%

15s -> 32%

I have no idea what my average window switch time is. I should measure it sometime. I doubt it is under 30 seconds where the VR actually makes a meaningful improvement.

If you take an average of 2 seconds for non-VR and a skilled user with keyboard shortcuts and virtual desktops, VR advantage becomes insignificant.

Table:

300s -> 0.6%

120s -> 1.5%

60s -> 3%

30s -> 6%

15s -> 12%

If you compare a specialized window managing software versus the VR equivalent then I don't see any benefit towards the latter. The latency is the same. The only difference is the abstract windows management versus spacial of VR.

I think programmers can handle the non-VR solution just fine. I really hope it becomes better though; the resolution is currently just too small.

I don't know I could see a scenario where you have an object moving around in space and you grab a special developer handle and a code window pops up with its behaviors. then you modify it and it starts moving around again.

Right, that falls into the very specific case which is the level/map making for 3d worlds, which usually isn't programming but more design and scripting.

Any suggestions for actual programming? You know, like; classes, boring code, loops, i/o, algorithms?

Reply on news.ycombinator.com