

How can I convince my boss that ANSI C is inadequate for our new project? - yitchelle
http://programmers.stackexchange.com/questions/164017/how-can-i-convince-my-boss-that-ansi-c-is-inadequate-for-our-new-project

======
shadowmint
It's not.

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.

~~~
Too
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?

~~~
alephnil
> It's running on windows, which makes the "real-time" argument void.

That is simply not true. You can set a windows process to use real-time
priorities.

------
webreac
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.

~~~
damian2000
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.

~~~
kokey
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.

------
cobolorum
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.

~~~
debacle
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.

~~~
gms7777
If your speed of development is glacial in C, then perhaps its that the skills
of your developers that are inadequate.

------
debacle
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.

~~~
chris_wot
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...

~~~
debacle
I write C# for mono and I've never had a portability issue.

~~~
acuozzo
How do (or would) you deal with architectures that Mono doesn't currently
support?

~~~
debacle
I probably wouldn't purchase those servers.

~~~
acuozzo
Ah, sounds like an excellent approach to "portability". Good luck with that,
but be sure to let me know when you return to the real world.

------
dave_sullivan
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.

~~~
heretohelp
>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#.

~~~
MartinCron
_Well it's obvious you haven't done any systems programming_

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.

~~~
huhtenberg
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.

~~~
MartinCron
_The insulting tone is well justified._

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."

~~~
huhtenberg
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.

~~~
MartinCron
I get the point, but I still disagree with it.

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?

~~~
heretohelp
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.

~~~
MartinCron
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?

~~~
heretohelp
Okay, I'll be nice.

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.

~~~
MartinCron
You are confusing me with someone else. I wasn't the one who made the original
claim.

~~~
heretohelp
Fair, but don't defend the propagation of things like that.

~~~
MartinCron
I promise I won't.

You seem to be a very talented writer. Have you ever considered using your
powers for good instead of for evil?

:)

~~~
heretohelp
Only rarely:

<http://blog.bitemyapp.com/>

<http://bitemyapp.tumblr.com/>

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.

~~~
eps
Good read, gentlemen.

------
patrickmay
"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.

~~~
juan_juarez
I'd have my resume up to date (and start shopping it around) if my manager was
telling me the names of global variables I should be using.

~~~
patrickmay
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.

------
forgottenpaswrd
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"

~~~
eropple
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.

~~~
huhtenberg
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).

~~~
eropple
I don't really care what you believe. I do it with Mono and open-source
libraries.

------
phomer
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.

~~~
bmj
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.

------
gregsq
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.

Bad move.

------
arocks
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.

------
petervandijck
"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.

~~~
MartinCron
This smells like a lost cause. I would consider looking at finding a manager
with whom you are more...compatible.

~~~
Turing_Machine
I suspect that choice is going to be made for him, once the manager learns
that his explicit instructions were ignored. :-)

~~~
MartinCron
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.

------
dumbdumbda
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.)?

------
philhippus
"ANSI C is inadequate" - No. It's perfectly adequate. I think you mean too low
level.

------
guilloche
I only realized that C is much better than c++ after using c++ for 20 years.

------
Locke1689
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.

~~~
MartinCron
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.

~~~
Locke1689
Totally true, but it doesn't appear that hiring another developer is in the
works. So C# it is.

------
EvaPeron
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.
:-)

------
pfortuny
Part of the project is writing it in C, so you cannot and you should not.

Sorry for the bad tidings.

------
chris_wot
Oh look! Not constructive.

------
umustbejoking
lolwat?

