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).
You have completely failed to convince us that ANSI C was inadequate. C is an excellent language that seems adapted for the kind of tasks you have described. With the short description of the task (except the language requirement), I would also recommend C or go. I think the problem is that you were programming in C with your mind thinking in C#. I have a similar problem when I switch from Perl to C or java. You must learn to adapt to the language, and not learn to translate from your way of thinking toward the language of the day. The problem is not your boss or the C language, the problem is to open your mind toward different ways of thinking.
Yeah C is good for lots of things, but not great for developing a desktop UI in Windows, when compared to C# for example. You'd be going back to the dark ages of Windows SDK development if you want to do that part in C.
That's assuming that in 5 years from now Windows is going to be the popular UI platform. If much of the program is not about the UI, then C is a good choice, since whatever finger nail mounted laser projection display computer will become popular in the future, you'll have ANSI C projects ported to it quickly. C#, I'm not so sure.
C# is not that great either. It's the IDE and all the supporting libraries that make a difference. And in this lies the problem - what if these libraries change, what if the IDE goes away or it license changes. Chances are that in a few years your UI code won't even build with then-current version of the C# toolset. On the other hand, C-based UI that depends solely on <windows.h> will.
Well, C is never inadequate. Quite a few languages have their interpreters/jit-compilers written in C. C is portable. C will continue to be a major language and will not become some obscure legacy language. You can tell I am a fan boy, but I am a fan boy for a reason. That said, you do not seem to like C, and further you already have the program written. I think you would pitch this as your "pseudo-code" and show it to your customer. Let him or her know that you will be rewriting it and that this could take some time. If your customer is willing to wait, you now have two programs that you can benchmark to compare speed. You can compare development times in a real way, etc... quite an interesting little project once the "project" is finished.
If your speed of development is glacial because the language you are writing in is just a hop skip and a jump away from ASM, then the language you are writing in is inadequate.
This sounds a lot like some random FUD that you picked up somewhere. If C dev times are so long, why is it that new versions of large scale applications written C are available so often? An adept C programmer can get an application up and running in quite short order. Quick GUI? GTKDialog is available as are: Win32 GUI API, GTK, QT, ncurses, FLTK, and many more. It is also worth noting that should your customer/employer be willing to use some opensource code in his/her/their application, the amount of open source C code available online is quite staggering.
Many of the responses there are for C in lieu of C#, which I disagree with. Unless you need the performance of C, you should always use a higher-level language, and C# is a beautiful and powerful language, and if you're any sort of C programmer, you can pick up C# relatively easily.
There's another reason. C + threads + computer science students maintaining it in sequence over the course of years is a recipe for disaster. Drop any one of those and it can be made to work, but not that trifecta.
That said, the right answer is probably still to deliver it in C as requested, and walk away. The customer has spoken, and seems to broadly know what he is talking about (ie, it isn't a nontechnical customer who is asking how "cloudy" your solution is, it's a programmer), so... well... OK... if that's what you really want....
In general of course what you say makes sense but in this instance the app should be written in C.
The client asked for C, they know the future, you do not. If, as the service provider, you recommend C# and detail all the advantages and the client still wants C you go with C. Simple as that.
Saying C# is beautiful and powerful is irrelevant. The task can be done in any number of languages but the client asked for C, go with C.
Yes there is but within the scope of this problem I don't see that it makes much difference.
You talk to your manager and recommend something but the buck stops with him and you do what he says. He is essentially in charge.
If you can't accept this then leave, you have no respect for then, why would you want to work with them. If you need the money they get on with it.
Programmers need to be more professional. As a professional you give your professional opinion but that isn't gospel. You note your protest and then get on with the job you are paid to do to the best of your ability.
BTW I am a programmer. I've been junior, lead and manager so I've seen it from all sides.
Progress is achieved by unreasonable people. If all programmers had never "disobeyed" their managers, we'd be probably still writing accounting software in COBOL.
You don't do that by disobeying your boss - you do it by quitting, finding your own clients, and saying "your competition is taking 6 hours to do this, and I can do it in a fraction of the time by using new language/feature/technology/process X", and beating your boss at his own game.
If your boss isn't paying you to look at the new technology, do it on your own time and in your own projects. If you want, you can come back afterwards and say "based on my personal experience, we can save time/money by switching to X" and give them the opportunity to try it out - or to overrule you.
ANSI C is a near universally portable language, C# is not. His boss wants it written in C, and his boss is the customer. Of course, his boss is specifying global variable names, so said boss is a micromanager... A no-win situation here really...
The problem isn't that mono (or programs written using mono) have portability issues themselves. Requiring mono itself is the portability issue. Many people don't like running mono or .Net runtime or even the Java runtime and some businesses/clients don't want to support it. That is quite a portability issue.
Have you ever heard a C# guy going around talking about how they ported their C# code to iOS/Android/Linux? Excluding projects started with that specifically in mind and built using Mono I have never heard of of a Windows C# project going the other way.
Agreed its rare but I wanted to reply here because I did just this thing myself last week. I had a ~6000 line TCP/IP sockets and serial port application (command line) written in C# on windows. I needed to port it to run on a Raspberry Pi (running Debian Wheezy). A rewrite in C was the initial plan/expectation. But got it working in Mono, with only a handful of changes to the serial port code.
Hardware interaction is the place where mono fails most often in my experience; portability for something that actually touches the underlying hardware (of any type) is probably not possible using c#.
And for that you can always call the native methods written in C, from C# - the support for doing this is excellent on both Linux and Windows. You can reference a function in a .DLL on windows and in a .so on linux.
Explain to your boss the cost/benefit of using a higher level language over c.
C's benefit historically has been performance. I think the case for performance is becoming less compelling for 2 reasons:
1) The performance gap is closing, thanks in particular to projects like cython that let you write python code that gets converted over and compiled as c++ that's often more performant than the c++ code that devs might write themselves.
2) In general, the cost of hardware continues to drop while the cost of developers goes up. C takes longer to write than eg Python--I don't care who you are, it does. And if you're the god programmer of C, you probably cost a lot.
So what would be the benefit of c for your boss really? It will cost more to develop, and the performance gains may not be as noticeable. It would quite possibly be bad business.
>The performance gap is closing, thanks in particular to projects like cython that let you write python code that gets converted over and compiled as c++ that's often more performant than the c++ code that devs might write themselves.
Well it's obvious you haven't done any systems programming.
>In general, the cost of hardware continues to drop while the cost of developers goes up. C takes longer to write than eg Python--I don't care who you are, it does. And if you're the god programmer of C, you probably cost a lot.
That's not what experiments have borne out, time-to-develop generally has a lot more to do with proficiency in the language of choice and in the problem domain than the language itself. I will say, however, that it is generally slower to write things in C, but not so drastically that it merits abandonment.
>So what would be the benefit of c for your boss really?
A solution that would reliably fit within the real-time and maintainability requirements of the problem being solved, unlike a throughput-focused GC'd language like C#.
Specifically what experiments have shown that people can write in C faster than python? You even admit yourself that it "generally" takes longer. I think it just plain takes longer. Of course that's anecdotal, but if you've got something non-anecdotal, I'd love to see it.
And since you've been so steeped in systems programming, would you not agree that the performance gap is shrinking? I think that's hard to argue against. And who said anything about abandonment? There's a place for C, but there are fewer than there used to be.
But hey man, sorry if I offended you, maybe you're having a bad day.
I would take GP's comment over someone preaching on a subject that he has no direct experience with. Latter is far more damaging to the discussion. The insulting tone is well justified.
Having done my share of kernel development I can assure you that anyone who brings up a topic of rewriting Linux kernel in (even) C++ gets laughed out of the room. When someone starts suggesting that there are plausible alternatives to C for kernel development, it is indeed a clear indication of no prior experience with the subject matter.
You can make the exact same point in a way that doesn't smell of the condescending dick-waving and "laughing people out of the room" that debases the level of discourse. I think that HN can and should be a more civil community than Linux kernel programmers.
Here, let me take a stab at it:
"In my experience with systems and kernel development, there are some scenarios where working with a higher level language than C simply isn't possible. This sure looks like one of those scenarios to me. If the manager in this example is mandating that it be written in C, it could be that the manager knows this from painful experience."
You are missing the point. Condescending dick-waving is there to discourage original poster from making half-assed assertive comments in the future. I understand that you don't like it, but it is the most efficient way to carry the point across.
> Here, let me take a stab at it:
Nope. Wishy-washy, excuse me this, excuse me that, I'm pretty certain to a degree that I might be right if you don't mind me saying. Not discouraging enough.
If you want another justification for the tone, let me tell you that I would've not hesitate to say the exact same thing in person, which is the criteria for wording HN comments as per pg's original guidelines.
> "I would've not hesitate to say the exact same thing in person, which is _the_ criteria for wording HN comments"
That is the second criteria. Immediately preceding it is "Be civil." Shortly after is an example: "That is an idiotic thing to say; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
Intentionally using an aggressive and insulting tone seems more harmful to the community than expressing the opinion that there is a performance gap between C and higher-level languages, but that gap is narrowing
How dangerous is that opinion, anyway? I mean, even if the opinion were demonstrably incorrect, is it so important to keep someone from daring to express it a second time?
There is real and legitimate compiler and JIT research, like PyPy, that could lead to reasonably efficient implementations for dynamic languages that can be expressed in RPython.
It is not, however, under any circumstances going to lead to code that's any faster than what an experienced C programmer can produce.
That's a "hard problem" in the mathematical sense is essentially impossible for reasons related to the halting problem and writing programs that can holistically analyze programs. For similar reasons, I find the type-fascism of the Haskell community amusing, although I find stronger type systems useful.
If aren't familiar with the implications and realities of systems programming and/or compiler implementation, stop making false statements about it.
Ask questions, read books, but don't toss out ridiculous bull-honkey like:
>thanks in particular to projects like cython that let you write python code that gets converted over and compiled as c++ that's often more performant than the c++ code that devs might write themselves.
I'm actually pretty familiar with Cython and have spent many man-hours optimizing Python code.
I'm a relatively terrible C++ and C programmer, but I can still produce code that profoundly outpaces Cython.
The only way to write C/C++ code slower than Cython is to use the wrong goddamn algorithm or data structure. (like std::list when you should be using std::vector)
Also, the protocol holds for me here too. I'd gladly say all of this to your face. Stop projecting manufactured confabulations about programming into the ether.
To be clear. I'm not the one who said anything about Cython or cross-compiling or anything. I hadn't even heard of Cython before and I don't have any strong opinions about it.
I don't doubt that you're right about all of the facts, that hand-rolled C will be faster than something cross-compiled unless the C coder did something profoundly wrong. I'm sure that lots of people are surprised and annoyed that all systems and kernel-level work is done with a language as out-of-fashion as C and ask stupid questions on other forums. You're right. The original poster was wrong. You win. Hooray!
But, here's the thing, I don't care how right you are, I care that you're violating the #1 commenting guideline and the thing that I generally like about this community, which is "be civil". So, even if you're the sort of person who wouldn't be civil to my face, please be civil here.
If you can do that much for me, I'll gladly buy you a coffee or beer if you're ever in Seattle and you can be as rude as you like to my face. Fair?
You're using the community guidelines as a shield to hide behind while you de-emphasize the fact that you were completely wrong and feigning to compensate for your total lack of experience in the relevant subject.
Stop using the community guidelines a shield. Own up to the fact that you were more than merely ignorant, you were aggressively promulgating and infecting others with falsehoods borne from your ignorance which is a kind of behavior I can't even begin to fathom the reasons for.
This is where it starts. This is how the incorrect campfire knowledge starts. CompSci and software engineering are rife with this plague and you are subject zero. CompSci is notorious for being, get this, unscientific because of the amount of false folk knowledge that gets bandied about.
Our lack of rigor, from the point of a view of an experimentalist and also an engineer, is dishonorable and unnecessary.
Your behavior shames all professional programmers.
So, lesson learned. I'll honey up my criticisms. I'll find ways to communicate that are pleasant and convincing.
That doesn't change that you'll never be free of my contempt, even if I'm being nice.
Keep the beer and coffee, you want to do me a favor? Don't ever do that again.
I don't tell my lawyer, my accountant, or my doctor how to do their job. I'll get a second opinion where prudent, but other than that, I don't assume I know more than somebody who's spent a good chunk of their life specializing into that field.
Extend the same professional courtesy to your fellow programmers who specialized in a different field than you.
Get a second opinion if you like.
But stop spreading your ignorance.
I have about as much patience for mollycoddling your ego as a doctor would for Jenny McCarthy telling people how dangerous and pointless vaccines are.
I totally agree with that. I respect people who know more than I do and I don't tell any specialist how to do their job. But I sure as hell don't like it if a doctor or lawyer or accountant rolls their eyes at me and speaks to me in a dismissive or condescending tone because I'm trying to have an informed opinion even though I don't have the same degree of expertise that they have. Here's an example:
Me: "I've done some research and I think I should get a Roth IRA..."
Accountant A: "Roth? Seriously? Sigh... You obviously don't know a damn thing about tax planning. Good thing I'm here to save your sorry ass. You need a traditional IRA"
-or-
Accountant B: "Actually, in this case, a traditional IRA would make a lot more sense than a Roth IRA. It's a common misunderstanding."
Technically, they are both on the same page, but tonally, the difference is huge. Our industry has too many people who act like Accountant A.
1) The original question was how to convince his boss that C is a bad choice. My answer is a good way to do it.
2) Re: my direct experience...
If you're talking about writing C, that's not true. But it has been a while because, frankly, I'd rather not torture myself. If you're talking about embedded programming, you're right, I haven't touched it.
If you're talking about applications where performance is very important, I've been dealing with quite a bit of HPC type stuff over the last year or so. In general, the hardcore C/C++/Fortran guys are becoming less useful, for reasons I stated in my OP. Notice I'm not saying "useless", I'm saying "less useful". There are absolutely applications in which this just isn't possible, so use what works. But applications where C is your only choice are becoming rarer and rarer.
And while we're here, where exactly did I say that the linux kernel should be rewritten in some other language? I didn't. So why would you suggest that I did?
You're certainly welcome to disagree, but if you think that that warrants an insulting tone, it may just be because you're an asshole. It wouldn't be an internet first.
"A few months ago, we started developing an app to control an in-house developed test equipment and record a set of measurements. It should have a simple UI, and would likely require threads due to the continuous recording that must take place.
. . .
Our boss . . . has mandated that we develop this application in ANSI C.
. . .
I actually tried that approach for a while. . . . After a few days, I scrapped the entire thing and started anew using C#. Our boss has already seen the program running and he likes the way it works, but he doesn't know that it's written in another language."
I'd have my resume up to date if I were you. Your technical arguments are irrelevant at this point -- you spent a significant amount of time deliberately ignoring the clear instructions of your manager and, apparently, not communicating with him. I would fire you on the spot regardless of the quality of your solution.
That is a valid point. I would still certainly suggest having an open and honest discussion before spending company resources on something other than what was specified, though.
While I think the poster really messed this up, big-time, I can empathize with him or her to a degree. I prefer high-level languages to low, and I also tend to avoid conflict.
One way to salvage this situation without getting fired might be to come clean now, be contrite, stop using incendiary words like "inadequate" and demonstrate the new solution as something that just got out of hand. It's hard to hire programmers right now, and the manager would have to weigh the (legitimate) desire to fire someone on the spot with the fact that getting a replacement would be expensive and annoying.
One could even say "now that I understand the problem better, I have a better handle on implementing it in ANSI C, as requested".
Interesting. The boss gives a very specific set of requirements, then the programmer disobeys this direct order, goes behind his back to do it differently and has essentially been lying to him or her for months.
It doesn't matter if it's the right or wrong technology choice, this is really an issue of 'work ethic'. Perhaps if the language was left unspecified, or it was a suggestion to use C rather than a requirement then it might be different, but this sounds like a rather blatant violation of trust based on a lack of respect.
I'd have no problems removing the programmer from the project, even if the software was awesome.
Yeah, I think this is an important point. If you don't agree with your bosses architectural decisions, you probably should have discussed those initially. If you feel like your boss wasn't listening to reason, does he have a boss? Simply going off and doing your own thing seems like a particularly bad idea, and I'm not sure I'd want someone on my team acting in the same manner.
You should stop thinking that c is inadequate and do two things:
1-Automate pointer creation so you don't spend time with them.
2-Automate string creation.
The good thing of programming is that you could automate anything. C# just automates it for you by default, but it is not god either.
In fact for platform independence is one of the worst languages to choose(and windows future looks no brighter than its past with iOS and android). You could use c inside Obj c, on c++, on python and java super easy.
It seems to me that "inadequade" is "I don't know enough about programming, and I only know one (proprietary) language, so I want to only use it"
It is one of the worst languages to choose for platform independence, is it? Strange. My application running on Windows (Desktop and Metro), OS X, Linux, iOS, Android, and the PS Vita seems not to have gotten the memo.
And as it happens, I used it not because I'm not able to write C or C++, but because doing so is a waste of effort better suited to doing other tasks.
I find it hard to believe that you can cross-compile C# code to all these platforms without creating heavy dependencies on 3rd party abstraction layers and/or toolsets (like Unity).
Sorry to be so pedantic, but C# is absolutely not a proprietary language. Yes, it's predominantly used in a proprietary context (OS and tooling), but the language itself isn't proprietary.
Be afraid. Very afraid. Project managers can often appear like roadblocks to innovative solutions. In fact, I've lost arguments even when the benefits for a particular technical solution are obvious and accepted. But maintenance is a big factor for those people. Not meeting a requirement is bad for your future prospects. Deceiving others is potentially disastrous for you current ones.
What would be said if a future requirement, unknown to you, were for an ARM chipped portable controller for said instrumentation, as a student project.
Rather than a language inadequacy issue, it is better to think of this as a resistance to 'change'. This is a much bigger and yet common problem in enterprises. Everyone would have their comfort zone and have found safety in sticking to it for years. So why change now?
There have been many studies on Change Management and certain strategies work in some situations better than the others. Most of them take a structured and step-wise process - e.g. Preparing for Change, Managing Change then Reinforcing Change.
It is certainly hard to master the skill of convincing others to take up change, but it is paid off many times over the years in numerous situations. So it is well worth trying.
"he even gave us a list with the name of the global variables (sigh) he wants us to use." -> Your boss clearly doesn't trust his team. Get him to trust you (may or may not be possible), and everything else will follow.
I think so too. It makes me sad, because the whole thing could have been avoided with some better communication and leadership skills.
We programmers tend to look at all things as technology problems, even in the way the question was asked ("inadequate?" what?) when it's almost always an interpersonal problem.
On the other hand, the poster didn't say what this list of global variables is. Maybe they are just configuration values? Probably not, and mentioning threading and global variables probably means some kind of nightmare, but as I've recently been reminded, not knowing all the facts we tend to make up a story in our heads...
I've had to write some C that interfaces with C#, so providing a low level library for a C# UI might be an option, but implementing it without the Boss's permission...yeah probably not so wise.
How can I convince young programmers who read StackExchange and generally look to forums for "advice" that it is worth their time to learn ANSI C (e.g., because it performs better than their suggested alternatives, it is time-tested, more widely known among programmers, etc., etc.)?
Everyone here has forgotten the main rule for choosing a language for projects. You have to actually know the language. The developer here very clearly doesn't know c all that well. That's all we need to know to know it's a bad choice. C is an especially bad language to use if you don't really know what you're doing.
If Linus Torvalds it's starting a new project, C is probably a good choice for almost anything. Why? Because he's an incredible C programmer. But we shouldn't confuse every developer with Linus Torvalds.
If that's the case, and C is the wrong choice for that developer but the right choice for the project, then it follows that the developer is the wrong one for the project.
I had that exact same thing happen to me once. There's no shame in it.
One could of course write a wrapper function to create strings, like char* someString = makeAString("A String"); where makeAString takes a char* as input, allocates the memory it needs via malloc (I prefer calloc though as it is safer by setting the allocated memory to a default value, IMO), and returns a char* as output, thus saving lines of code whenever one wants to make a string. Probably stating the obvious I guess, but if one takes a few days to make some wrappers like that one saves time down the road. Were it my boss, I would say, OK, we can do it in C, but you need to give me time to make some wrappers that I need in order to get this done efficiently. Just a thought. :-)
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.