How can I convince my boss that ANSI C is inadequate for our new project?
programmers.stackexchange.com
programmers.stackexchange.com
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.
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).
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?
That is simply not true. You can set a windows process to use real-time priorities.
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.
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 actually made by teams of people working together for a common goal.
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.
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....
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.
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#.
While it may be true in this case, this is the sort of insulting and dismissive argument that I don't like to see here.
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.
No! No! A thousand times No!
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."
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.
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.
> 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.
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?
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.
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.
You seem to be a very talented writer. Have you ever considered using your powers for good instead of for evil?
:)
I don't generally find myself with anything profoundly useful (to others) to say outside of any specific context.
If you have a topic/post suggestion, I'd love to hear it.
Thank you for the compliment, you're a very patient man.
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."
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.
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'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.
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".
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"
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.
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.
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.
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.
Bad move.
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.
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.
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.
He failed to follow the first requirement (ANSI C). Everything else afterwards is merely more justification to distrust him or her.
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.
I had that exact same thing happen to me once. There's no shame in it.
Sorry for the bad tidings.