Fr0styMatt8

Any chance for a Samsung Gear VR version?

Cardboard is a great ecosystem, but the tracking and latency on Gear VR is just leaps and bounds above what cardboard can do (the GVR unit has its' own low-latency sensors).

I really wish AMD would promote this type of thing more heavily in general (having advanced features that Nvidia restricts to their high-cost cards). I seem to remember a similar thing with AMD being fantastic for Bitcoin mining and from memory it's because Nvidia gimped certain features that were on the cards, while AMD did not.

(on that note, I'm constantly annoyed that despite it being Nvidia specific, everyone supports CUDA for everything cool).

I understand companies have to do this to segregate their products and that it's impractical to have separate fab lines for a chip family for this kind of difference. It's still something I think AMD has a competitive advantage on though and they really need to push that alone (unless they just don't really want to - to sell their own high-end professional cards).

A worse example of this is Nvidia cards not running in systems that have AMD graphics cards in them. Which means, for example, you can't buy a low/mid-range Nvidia card to sit in your system as a dedicated PhysX/CUDA card. I'd consider such a setup for my system and I imagine there's probably others like me out there.

A bit younger (I was in my last year of primary school when I graduated from the C64 to the Amiga 2000). I fondly remember reading through the back of the Amiga 2000 reference manual (the ring-bound one) on Christmas day. It had schematics and everything! (back at that age, schematics just LOOKED cool - I couldn't really read them as such).

I remember those $5 shareware disks you used to be able to get at the markets.

By the end though, several years later.... Oh man.... Games weren't as smooth as on the Amiga, but OH THOSE SIERRA VGA GAMES ON THE PC!!!! Especially compared to their horrible Amiga ports (which were also Sierra abandoning the platform.... the port of King's Quest VI that was done by Revolution Software shows how much better they could have been).

Awesome memories!

Absolutely. When you listen to a violin live, you're of course not just getting the violin, but you're getting all the reverb of the environment, the spatial cues created by sound bouncing off your body and around your ears, etc.

So taking a violin sound and then playing it out of a speaker, you're playing into a totally different environment and it's going to sound different. If you've also captured the sound of the environment in which the violin was played, you're then also playing THOSE sounds into a different environment. The reverb still gets affected by the environment your speakers are in.

I think the closest you can get is binaural recordings done with mics worn on your own ears and then played back using suitable headphones.

Even that still doesn't cover the tactile dimension of sound (think about the feeling you get when bass goes through large stage monitors). There are products that try and reproduce this - I haven't tried any of them but would be eager to, as I primarily listen to music with headphones.

Nor does it cover spatialization properly either - without some form of processing, the sound source won't stay in position when you move your head.

A bit off-topic, but the more I think along these lines, the more I imagine the ideal music delivery medium being dry multitrack recordings with mixing and reverb supplied as metadata that's then applied with real-time audio processing. That'd be pretty wild!

No I don't think that's anything particular to do with the fact that one is iOS and one is Android; Google's OWN YouTube apps are inconsistent.

The Android TV YouTube app, for example, has no way to subscribe to a channel. It also has no immediate 'go back to the video I was watching' either; you have to wait some amount of time until your YouTube history gets updated. This is Google's own YouTube app on their own platform.

I totally agree with this.

The main point I want to put across is that it's unfortunate that as software engineers, we have somewhat of a tendency to feel guilty for what we do earn and as a whole profession we can be prone to underselling our own value. I find the parent comment a perfect reflection of this tendency.

It gets more complicated when you ask the question "How much money is the software engineer making for the company vs. what the company pays them?"

For argument's sake, let's say you're paid $80K per year. On the one hand, you may think that is high (it always depends what your frame of reference is). If the code you produce directly makes the company millions of dollars though, does that change your assessment of the 'reasonableness' of that salary?

This is the argument I've heard as to why sports stars get paid so much (because you have to look at what they get paid vs the amount of money they're making for the comapnies paying them).

It's a real can of worms.

Going to sound a bit cynical here, but really isn't $30 million just spare change to a VC?

To us we see $30 million and think "that's a ton of money!! how could he get that funding?" but to the VC it's like "Here's a bit of spare change, maybe you'll make something out of this, maybe not".

From that viewpoint alone I could understand why a VC would fund this. I mean, could you guarantee that it's NOT going to be some breakout hit? What if you did pass on that $30 million investment and the company did actually turn out to be valuable? It's easy to say post-hoc once the company has been stupid that the VCs ought to have known about it, but it looks different if you think back to what the VCs must have known when they were approached.

I agree with you in principle but find that code editors let me down in that regard.

Say I split a function up into a few sub-functions because it's getting big. Now I have the problem that I'm jumping forwards and backwards through the code when I want to explore what that function does:

SomeMassiveFunction() { SubfunctionA(); SubfunctionB(); SubfunctionC(); SubfunctionD(); }

SubfunctionA() { } ....

In this case, SubfunctionC() might end up a few pages down in source code. So now it's a context switch to go there and then go back.

Now this can be somewhat avoided with good function names (so you don't HAVE to jump backwards and forwards) and keyboard shortcuts (to make the process quicker), but it's still a trade-off that I think needs to be kept in mind.

I continually find this idea that there aren't older developers really really strange, from my own experience. Every job I've had has included me being on the younger end of the spectrum and developers a lot older than me.

The lead developer at my current company is in his mid-50s and he's as interested as anyone I've known (and more interested than a lot of engineers I've known) in learning new APIs, etc.

I know, anecdata and all that :)