> people who might be a little hostile to working in a Lisp.
Hostility is an excellent word for it.
> Doing VR GUI development in the native apps is unpleasant – you can gut it out in C++ with our current interfaces, but the iteration times and code structure don’t make it a lot of fun.
> In-editor prototyping is nice in Unity, but actual on-device testing cycle times are terrible, and you wind up with all the bulk of Unity and poor access to the native VR features like TimeWarp layers.
This is exactly the reason I've focused on WebVR with my Primrose project. Otherwise, JS sucks.
> I am a big believer in functional programming (and static types) for large projects, but there is an undeniable bit of awkwardness compared to just imperatively poking things for small projects
That's funny, because I would say the opposite is true: imperative code with global state is harder to poke around on because it's harder to reason about your state, whereas functional code [0] can be sliced and diced and put back together much more readily.
There are places where traditional for-loops, with a readily exposed counter, are extremely useful in game programming. Perhaps that is what he means? Map and for-each are great when they are the right tool, but I've personally never subscribed to the idea that they are particularly "easier" to use than for-loops, or "more functional".
> The design usage is to reference pre-processed models loaded from the net
This is a great point. Most (all?) beginner 3D programming tutorials start you off with making your own meshes by hand in code and leave loading models from files until far, far later. This, to me, is exactly backwards. The basics of modeling are not hard to teach, Blender is free, and building static, non-mathematically defined meshes in-code really sucks.
[0] with a REPL, any modern language without a REPL is defective. And that means with Readline, or something similar. A REPL without command history is a defective REPL.
> This is a great point. Most (all?) beginner 3D programming tutorials start you off with making your own meshes by hand in code and leave loading models from files until far, far later. This, to me, is exactly backwards. The basics of modeling are not hard to teach, Blender is free, and building static, non-mathematically defined meshes in-code really sucks.
Your mileage may vary, but I wouldn't necessarily say that modeling is easy, especially not trying to use Blender. Most beginnner 3D programming tutorials use simple geometric shapes because it is a helluva lot easier to figure out if your lighting is off or your projections wrong when the scene objects are simple. Loading complex models from file is not exactly a piece of cake, either - you either need a fully-featured library with support for models baked in, or to use something like Assimp, or even write your own model format parsers.
We should have "fully-featured library with support for models baked in" already. There is no reason for a beginner to be writing stuff like this from scratch. A scene graph and model loading library are the bare minimum for a beginner.
Why? I've put up a simple renderer (meshes + instances [transformation+material] + camera + default light behind the camera] in ~450 lines of C++ code (+ 50-ish lines of GLSL).
I've done the same for C++ DX9 code, but that was before D3DX was deprecated and then removed in DX11. It's not quite so simple anymore, unless you pull in various third-ish party libraries (usually just open-sourced versions of the D3DX stuff Microsoft cut...)
> people who might be a little hostile to working in a Lisp.
Hostility is an excellent word for it.
> Doing VR GUI development in the native apps is unpleasant – you can gut it out in C++ with our current interfaces, but the iteration times and code structure don’t make it a lot of fun.
> In-editor prototyping is nice in Unity, but actual on-device testing cycle times are terrible, and you wind up with all the bulk of Unity and poor access to the native VR features like TimeWarp layers.
This is exactly the reason I've focused on WebVR with my Primrose project. Otherwise, JS sucks.
> I am a big believer in functional programming (and static types) for large projects, but there is an undeniable bit of awkwardness compared to just imperatively poking things for small projects
That's funny, because I would say the opposite is true: imperative code with global state is harder to poke around on because it's harder to reason about your state, whereas functional code [0] can be sliced and diced and put back together much more readily.
There are places where traditional for-loops, with a readily exposed counter, are extremely useful in game programming. Perhaps that is what he means? Map and for-each are great when they are the right tool, but I've personally never subscribed to the idea that they are particularly "easier" to use than for-loops, or "more functional".
> The design usage is to reference pre-processed models loaded from the net
This is a great point. Most (all?) beginner 3D programming tutorials start you off with making your own meshes by hand in code and leave loading models from files until far, far later. This, to me, is exactly backwards. The basics of modeling are not hard to teach, Blender is free, and building static, non-mathematically defined meshes in-code really sucks.
[0] with a REPL, any modern language without a REPL is defective. And that means with Readline, or something similar. A REPL without command history is a defective REPL.