How about an upgrade for Inventor to modern Dotnet?
I know for a huge app like this it's not a trivial consideration, but I'm actually going to guess that Microsoft's Upgrade Assistant is going to get it a huge portion of the way there, if not completely get the job done of upgrading it.
The performance benefits are huge, like by multiples in many cases, and it might even be fast enough for you to ditch the absolute need for native code interop in some places, as the overhead from using in P/Invoke, according to some people I've heard, can actually be as significant as to undercut the native code performance gains altogether.
Also, the ability to write more modern plugins would be really nice, from a development point of view, being stuck on .NetFramework really is a frustrating and limiting factor.
I have had such a hard time, for instance, with dealing with assembly binding redirects, that I have to modify Inventor's config to get it to work with Elmish.Wpf at all. To use that library, which is for making an Model-View-Update style of UI work with WPF, using FSharp, I have to go in to the Inventor.exe.config and add this: =
<dependentAssembly>
<assemblyIdentity name="Fsharp.core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.6.0.0" newVersion="4.6.0.0" />
</dependentAssembly>
This is because of a transitive dependency, an older version of Elmish , that relies on fsharp.core 4.6.0 EXCLUSIVELY. As far as I can tell, and I wrestled with this a long time, there is no way around this limitation specifically because of how .NetFramework manages it's dependencies. It is not just OK with having dll's roll forward to the latest version, which in many cases is by default a better version, assuming the API surface isn't full of breaking changes.
Is this the sort of thing 90% of the people who make inventor plugins run into? Probably not yet, but I'd be willing to bet that my fringe case is the canary in the coal mine, because the package world continues to march on, and soon I'm not going to be the only weirdo who wants something that is relying on transitive dependencies that should be fine with rolling forward.
I don't know that waiting even longer to modernize the architecture of Inventor is going to make it easier, and if you guys get Microsoft to come help, which people like David Fowler have been known to do for big customers like you guys, then it's likely going to be a better business investment than trying to do the same upgrade process in 10 years, when it's going to be many times more expensive and difficult to accomplish, as the people familiar with doing these massive upgrades are going to be able to charge crazy amounts for such a process.
It's like the problem of finding a COBOL programmer. They can charge whatever they like. There are so few of them, it's a difficult ancient language, no one really seems to actually ENJOY COBOL, and it just so happens to be the foundation of super critical systems like traffic lights or financial exchanges, or things like that.
No one wanted to change these things when it was easier, because, well, leave it alone, it's working now. But it's an expensive and horrible dinosaur that will not die, simply because it's now so costly to change it would require too much.
I think Inventor is great, I want to use it for years to come, but if it isn't modernized, I'm afraid there is going to be an all too happy competing product with an easily extensible API with modern library support that will come in and take over the space.
You guys could even take it cross platform eventually, and get a whole new market of people willing to use it on Mac or Linux.
Also, the reliance on VB.Net is a limiting factor for those using iLogic, while Microsoft is not dropping it in terms of it being usable, they are not improving the language any further. No more updates, no more features. So by limiting iLogic to only VB.Net then you're guaranteed to not benefit from what developers will come to expect in the next decade. I don't prefer CSharp to FSharp, I think FSharp is a much better language by a long shot, but BOTH are so much nicer than VB. VB, without the promise of development of new language features that make new software less costly to write, it is a liability.
On top of that, VB is not easier to write. It's actually a lot more difficult to write and reason about, with so much boilerplate and noise that it's a slog to even wade through to figure out what's going on most of the time. "It looks like English!" people say, well, we don't speak in code, and we shouldn't expect code to look like English. Forcing an irrelevant paradigm onto code has the opposite effect in readability, I can easily and quickly understand what is happening in most of the FSharp I see, because you're only seeing what's necessary to actually getting the job done. I just don't see the "usability" argument as a strong one, especially with the kinds of variable and method names I see all the time in Inventor VB code.
Hungarian Notation ends up as clutter. I'd be willing to bet that many, if not most, people probably don't even realize WHY they're adding "o" the the beginning of every thing in the examples, and even if you know it's supposed to indicate Object, then that tells you precisely NOTHING about that object aside from it not being a language primitive. The name the object is given should be doing a good enough job of describing it to begin with, and the "saving of keystrokes" doesn't make a bit of difference in the long run if most of your time dealing with code isn't the typing, it's reasoning about the code. I'd actually argue that single or couple letter variable names in many cases is better, because that truly DOES save keystrokes, and if your function is so lengthy and complicated that you can’t tell what is happening to these variables or what they are, then it’s likely going to be not something you should have in production code to begin with..
Anyway, I’m diverging a bit, the point is that having an upgrade and a language change would be absolutely killer and a good decision, I think.
