Let me summarise the task: Continuous measurement of custom hardware in real time with some trivial user interface.
There are two parts to this:
1) real time device I/O <--- Really important.
2) user interface <--- Irrelevant, will probably be replaced multiple times over the life of the project.
This is how the OP needs to pitch it to the boss.
(1) is critical and C is flat out the best language for real time I/O, and it's the best choice for making an easy-to-use DLL that can be loaded and used by any number of other systems (C#, python, etc.)
(2) is hard to do nicely in C, but we can have a very trivial very rubbish ANSI C user interface if that's what you want. However, we can do a much better job by calling the library from (1) from another target (eg. c#).
We can also repeat the process in (2) to build an alternative 'user interface' that is in fact a test harness / test suite for (1), increasing reliability (something that C once again, sucks at (testing that is)).
"Here I made a prototype in a language you didn't ask for! It's the ROZZXXEOR!!!111" is just about certain to generate a negative reaction.
I agree, however, I would argue that 1 needs to be an independent process, with an IPC mechanism rather than a library. This would allow for multiple systems to access the same research data - If my experience in research maps to the specific situation (not all research is the same), this means that several experiments can easily have a rock-solid data source, without needing to debug the library integration every time, and allowing for post-processing chains to build of each other.
It's running on windows, which makes the "real-time" argument void. And if you are recording anything your hardware better have a built in buffer and real time stamps already. It's not exactly like you are bit-banging things to a serial port...
However i agree that making the hardware interface in c would be the best option. But in most cases your hardware would already come with this and using P/Invoke to call it from C# is then piece of cake.
It's hard to give a definite answer since the OP doesn't specify if the application also has hardware output or just recording. And what are the time constants? Are we talking seconds or microseconds?
This sounds like a great way to approach the problem.
While the author's boss might have too narrow of a field of view in technologies, the author shares his/her boss's strategy to use a hammer as his sole tool, regardless of whether he's driving nails or screws.
Hard? Like "registering a window class, writing a window message handler, creating a window and running a message loop" unbearably hard? That's not to say that there shouldn't be a split into an engine and a UI modules, potentially running in separate processes (and done in different languages if need be).
Let me summarise the task: Continuous measurement of custom hardware in real time with some trivial user interface.
There are two parts to this:
1) real time device I/O <--- Really important.
2) user interface <--- Irrelevant, will probably be replaced multiple times over the life of the project.
This is how the OP needs to pitch it to the boss.
(1) is critical and C is flat out the best language for real time I/O, and it's the best choice for making an easy-to-use DLL that can be loaded and used by any number of other systems (C#, python, etc.)
(2) is hard to do nicely in C, but we can have a very trivial very rubbish ANSI C user interface if that's what you want. However, we can do a much better job by calling the library from (1) from another target (eg. c#).
We can also repeat the process in (2) to build an alternative 'user interface' that is in fact a test harness / test suite for (1), increasing reliability (something that C once again, sucks at (testing that is)).
"Here I made a prototype in a language you didn't ask for! It's the ROZZXXEOR!!!111" is just about certain to generate a negative reaction.