On Tue, Jun 25, 2013 at 12:40 PM, Jürgen Herrmann <[email protected]> wrote:
> You're not really trying to lure us into coding integral parts of blender > in python, c# or mono, are you? > No.. Blender core code is large and depends on many useful third party C/C++ libraries. I'd guess it's going to be C for a very long time (possibly it's entire useful life). ...though now we have to define "integral". I would like to see more blender UI and experimental features built in a static-typed extension language like C#/Mono or TypeScript. There is a reason why coders always fall back to c/c++, that reason is > speed. > Imho Type safety in c++ is not as critical as you present it here. Let me explain my motivations differently... Blender is an incredible piece of software, and I'm thrilled it exists, thrilled to use it, and thrilled to support it. I'm working on a VFX clip right now, and I'm just *astonished* at what I'm able to accomplish -- as a software engineer with little art-skill. who has never done any filming, compositing, or even node-editing before. It's truly awesome.... ....So it's sad that, for me, Blender crashes WAY too much and more than any other program I have ever used. I'm just an amateur who hardly does anything fancy. This is why my #1 is automatic crash reporting and a crash-stats dashboard. The only other blender users I have direct contact with also say it crashes alot. I see it crash in youtube tutorials. I personally would like to know how much it crashes. I think measurement is often a good step to improvement. However, lets get back to type-safety... My (unproven) theory is the crashes and instability is primarily for two reasons (a) devs are volunteers and there is more interest in incorporating cutting edge features than spending time making sure every piece of C/C++ code is well behaved. (b) blender is primarily used on windows, and a windows build takes quite a while to setup and get working, so it's easier for software-engineer blender users to just work-around bugs and crashes than help fix blender. (a) can be improved with type-safety, but only for code that is written in the type-safe environment. (b) I'm guilty of myself. I have spent time filing bugs for small problems that might have taken me less time to actually fix and submit a patch -- if I had a working build. However, I've tried to setup a working windows build before and given up for frustration and lack-of-time. I despise setting up builds. Build setups are notorously under-documented, and my machines are used for development, so I often can't just install the tools the build wants in all the standard places because it collides with other versions of the same tools. All of this means I just work around the issue and file a bug instead. ...so, I agree type-safety is not a panacea. In fact, if I get to choose between type-safety and enabling any blender user-dev to quickly and trivially edit/compile/run/patch/share blender code, I'd take the latter. The only path to instant embedded edit/compile/run/debug cycles I've ever seen is extension languages, which also happen to mostly be typesafe, so this is why I see the two as intertwined. A magic "push button" way to automatically setup a windows build would be a great alternative if it can be done. A new/additional scripting language might be cool and is definitely > something we should think about. > Ok you could replace some parts of blender with scripted code, but I don't > agree with your arguments at all. > Let's keep in mind the term "script language" is very imprecise, and is being blurred by technology like JIT and virtual machines. To clarify, I don't want to see more of blender written in Python, nor do I want to see another dynamic typed scripting language added to Blender. Consistency is good and Python is a good scripting language. What I would like to see is: (a) Blender crash less, (b) an easier workflow for a software-engineer blender-user making a small fix. My hypothesis is that a static-typed extension language like C#/Java/TypeScript would be a more viable way to develop "real" features, not just scripts. This would allow more of blender UI and new experimental features to be built in an extension language that won't crash blender. A language that the user-dev community could more readily fix and improve, because they wouldn't need to setup and maintain a whole blender-core build to contribute. Any of that seem more attractive? _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
