¿Cómo puedo convencer a mi jefe de que ANSI C es inadecuado para nuestro nuevo proyecto? [cerrado]

64

Hace unos meses, comenzamos a desarrollar una aplicación para controlar un equipo de prueba desarrollado internamente y registrar un conjunto de mediciones. Debería tener una interfaz de usuario simple y probablemente requeriría subprocesos debido a la grabación continua que debe llevarse a cabo. Esta aplicación se utilizará durante algunos años y será mantenida por varios estudiantes de informática durante este período.

Nuestro jefe se graduó hace unos 30 años (no debe ser tomado como un delito; también tengo más de la mitad de ese tiempo en mi espalda) y ha ordenado que desarrollemos esta aplicación en ANSI C. La razón es que él es el único que estará alrededor todo el tiempo y, por lo tanto, debe ser capaz de entender lo que estamos haciendo. También dictaminó que no deberíamos utilizar tipos de datos abstractos; Incluso nos dio una lista con el nombre de las variables globales (suspiro) que quiere que usemos.

En realidad probé ese enfoque durante un tiempo, pero realmente me estaba ralentizando para asegurarme de que todas las operaciones de puntero fueran seguras y que todas las cadenas tuvieran el tamaño correcto. Además, el número de líneas de código que realmente se relacionó con el problema en cuestión era solo una pequeña fracción de nuestra base de código. Después de unos días, deseché todo y comencé de nuevo con C #. Nuestro jefe ya ha visto el programa en ejecución y le gusta cómo funciona, pero no sabe que está escrito en otro idioma.

La próxima semana los dos nos reuniremos para repasar el código fuente, para que él "sepa cómo mantenerlo". Estoy un poco asustado, y me gustaría saber de ustedes qué argumentos podría usar para apoyar mi decisión.

Cobarde tuyo,

almiar
fuente
220
"Oh, no, esta no es la versión final, es solo una versión de C # que escribimos rápidamente en unos días para la creación de prototipos y pruebas, para asegurarnos de que entendemos los requisitos y ajustar la interfaz de usuario. Implementar esto en ANSI C tomará otro X semanas, porque, ya sabes, tenemos que evitar no tener todas las estructuras de datos de lujo. ... Bueno, sí, ahora que lo mencionas, la versión C # hace ya hacer todo lo que el programa final debería, pero dijo lo necesitas en ANSI C. ... OK, si insistes,
quedémonos
8
@Heinzi: He tenido la misma experiencia: escribir un prototipo C # de una biblioteca en 2 días y pasar varias semanas reescribiéndolo en C. Afortunadamente, después de ese proyecto, me ofrecieron la oportunidad de transferirme a otro equipo con más Elección del lenguaje sensible.
dan04
49
Variables e hilos globales? Estás en problemas, amigo mío, independientemente del lenguaje de programación que uses.
Nemanja Trifunovic
16
El argumento que realmente necesita es por qué debe mantener su trabajo.
epo
11
Su suposición es incorrecta: ANSI C es adecuada para casi todos los proyectos. Es por eso que sigue siendo popular después de todos estos años. Si es óptimo o no es una pregunta diferente.
Mark Ransom

Respuestas:

108

Tenga en cuenta que el "Por favor hágalo así, así que estoy seguro de que puedo mantenerlo" es en realidad un requisito muy bueno: la mayoría de los programas pasan mucho más tiempo manteniéndose que escritos y mantener una solución en una tecnología conocida suele ser una buena idea.

Imagínense si un chico nuevo de la computadora, cuando se le pidió que escribiera una aplicación C #, la escribió en Haskell en dos días y dijo "Oye, funciona y me voy, adiós", dejándote el mantenimiento.

Imagínense si un chico nuevo de la computadora, cuando se le pidió que escribiera una aplicación ANSI C hace 15 años, la escribió en Visual Basic 6 en dos días y la dejó. Ahora debe mantenerlo y Windows 7 comienza a quejarse cuando se inserta el medio de instalación .

Esta podría ser una buena oportunidad para decir, como lo insinuó Heinzi en los comentarios, que "este es un prototipo rápido escrito en C # que se parece mucho a C: ¿debemos prepararlo para la producción o volver a implementarlo en ANSI C como usted? preguntó ", y luego toma la discusión ahora. Tener una fuente real para ver, es mucho mejor que "Oye, ¿no deberíamos escribir nuestra próxima aplicación en Haskell porque es más rápida".

En otras palabras, ahora tiene la oportunidad de demostrar que podría considerarse una nueva plataforma. Mencione que escribió un prototipo antes de la revisión del código; esto ayudará a eliminar la impresión de que está intentando infiltrar C # debajo del radar. Sugeriría que también demuestre que todo el código existente escrito en ANSI C se puede usar desde C #. Personalmente, creo que le dirán que el objetivo sigue siendo ANSI C para permanecer en una sola plataforma.


fuente
26
+1: para señalar el requisito "hazlo así, así que estoy seguro de que puedo mantenerlo". C # es sin duda mucho más fácil / más rápido que C desarrollar (en general), pero C ha cambiado en los últimos 30 años menos que C # ha cambiado en los últimos 15 años. Entonces, para un producto que debe mantenerse durante muchos años, C podría ser más adecuado. Debe comprometerse entre todos los requisitos: complejidad del proyecto (C # es probablemente una mejor opción), mantenimiento a largo plazo (C parece ser más estable), quién va a hacer el mantenimiento, etc.
Giorgio
44
@Ramhound No estoy hablando del soporte de VB6, sino del soporte del entorno de desarrollo de Visual Basic 6 . Mi copia de Windows 7 me notificó explícitamente al insertar el medio de instalación que no era una buena idea.
12
Buenos puntos, pero ¿y si el jefe hubiera pedido que se escribiera en COBOL? O 6502 montaje? ¿En qué momento puedes decirle a tu jefe: "Ese lenguaje es obsoleto para este propósito, y una vez que te hayas ido, no quedará nadie que comprenda estas cosas"?
Ant
66
@ Alex: La consistencia es agradable, cierto. ¿Pero escribiría un nuevo sistema web en C si todo el otro software (no web) escrito por su departamento fuera escrito en C? Creo que todo se reduce a un equilibrio entre elegir las tecnologías apropiadas para el sistema que está escribiendo y las habilidades existentes del equipo. Elegir un idioma sin deliberación porque eso es lo que siempre usas puede ser perjudicial.
Ant
8
@ant, el que paga a la banda puede elegir la música. (y somos una tienda COBOL, no hay problema para respaldar eso)
35

En este caso, su jefe parecería ser su cliente, y su requisito principal es que pueda mantener la aplicación cuando continúe. Esto parece bastante razonable.

Por lo tanto, la opción es hacer lo que le pida o demostrar que puede completar el desarrollo Y enseñarle cómo mantener una aplicación C # dentro de las limitaciones de tiempo y a un costo menor. Si no puede hacer eso, no está cumpliendo con los requisitos del proyecto.

Matthew Flynn
fuente
21
El OP omitió explícitamente los requisitos sin notificación ni discusión. Si el jefe fuera un cliente comercial, podría rechazar el pago y posiblemente demandar por los costos incurridos debido al tiempo perdido. Invierta los roles, ¿qué sucede si, por ejemplo, ordenó un traje a medida y descubrió que al sastre no le gustaba trabajar con la tela que especificó y que sustituyó en silencio por una que le gustó, en su elección de color? El problema del OP ahora es que no se puede confiar en los proyectos sin una supervisión cercana, carece de las habilidades de las personas y no respeta la gestión.
epo
1
@epo Creo que entiendo su afirmación de que el jefe no puede confiar en el OP ya que no hicieron lo que se les pidió. Sin embargo, si es un gerente razonable, eso no debería suceder. Si el desarrollador se acercara al gerente con una solución mejor de la que se consideró originalmente, espero que el gerente esté abierto a ella. Si puedo modificar su ejemplo ligeramente, es como si el sastre hiciera un traje en el color / patrón deseado con un tipo de tela más nuevo, más duradero, con mejor sensación y más barato de lo que se solicitó, aunque el comprador solicitó un tipo de tela con la que estaban familiarizados.
Taylor Precio
Dicho esto, también estoy de acuerdo en que, en este caso, el mantenimiento es un requisito importante. El OP ahora está obligado a demostrarle al gerente que resolvió el resto de los requisitos de una manera que el gerente pueda aprender a mantener de manera rápida y efectiva.
Taylor Price
26

No ha proporcionado mucha información, pero creo que C es la opción correcta: trabajo como ingeniero en una planta industrial y la mayoría (si no todo) de nuestro código está escrito en C. Si necesita obtener mediciones de un dispositivo (supongo que un medidor de flujo o termopar o similar aquí) y mostrarlo casi en tiempo real C es una excelente opción.

Es rápido, portátil (nunca he escrito en C #, pero no creo que funcione sin una versión particular del marco instalado y, por lo general, solo está basado en Windows).

Por supuesto, podría usar otro idioma para hacer la GUI. Pero podría ahorrarse el esfuerzo y simplemente usar un paquete de tendencias preexistente (hay algunos buenos de código abierto disponibles).

Para resumir, diría que la interfaz subyacente con la parte de hardware C es una buena elección.

Mate
fuente
77
He tenido más éxito al portar código C # de Windows a Linux (usando Mono) que con el código C ++.
dan04
8
@ dan04: ¿Qué problemas tuviste con C ++? Pensé que C ++ sería bastante portátil. Además, C ++ no es C. Siempre encontré que usar C con la biblioteca GNU C es bastante portátil, por ejemplo, entre GNU Linux y cygwin.
Giorgio
44
@ dan04 C! = C ++.
2
@Giorgio: Una parte molestamente grande era cuerdas. Tuvimos que eliminar toda la TCHARbasura específica de Windows (que de todos modos no estábamos usando constantemente) y adoptamos un estándar de equipo para usar UTF-8 al mismo tiempo que la transición de Linux. Desafortunadamente, esto requería volver a implementar una gran parte de la biblioteca estándar en Windows, que boost::nowideno existía en ese momento.
dan04
3
@ dan04: Como se dijo, C ciertamente no es tan expresivo como C # (o C ++ para el caso), pero he estado usando la biblioteca GNU C ( gnu.org/software/libc ) desde 1997 y es realmente estable y portátil. Para C ++, miraría Qt (o boost y las bibliotecas estándar) porque son bastante portátiles. Evitaría cosas específicas de Windows si fuera posible: AFAIK nunca ha sido el objetivo de Microsoft producir software portátil ya que el bloqueo del cliente es parte de su estrategia de marketing.
Giorgio
24

Oh querido. Esta es una aplicación en tiempo real? ¿Equipo de control en tiempo real? ¿Recopilando datos en tiempo real? ¿Usando un lenguaje con un recolector de basura? Oh querido.

Si bien estoy de acuerdo en que probablemente puedas hacer la aplicación en un idioma más moderno en menos tiempo, probablemente ese no sea el criterio principal. LA FACILIDAD DE SU PROGRAMACIÓN ES PROBABLEMENTE MENOS IMPORTANTE QUE LOS OTROS CRITERIOS, como los que estableció su jefe, el tiempo de respuesta y el comportamiento determinista.

Te habría sugerido que hagas un prototipo en C # o Python, solo para probar la funcionalidad principal y la interfaz de usuario. ENTONCES, pruebe el rendimiento, midiendo las latencias reales y los tiempos de respuesta, cuando la aplicación recibe muchos datos, durante muchos días de funcionamiento continuo. Lo más probable es que la aplicación podría terminar siendo demasiado lenta o quedarse atrás en momentos aleatorios, cuando VM o el recolector de basura se activa.

Le sugiero que presente lo que ha hecho como PROTOTIPO.

La codificación en C no es tan difícil. Si no estás preparado, dilo. Hay muchos de nosotros listos para el desafío. (He estado haciendo codificación C en tiempo real por, argh, décadas).

Gumpy Gus
fuente
3
Vamos a expresar la primera parte de manera diferente. Oh querido. Esta es una aplicación en tiempo real? ¿Equipo de control en tiempo real? ¿Recopilando datos en tiempo real? ¿CORRIENDO EN UN ENTORNO ROSCADO NO EN TIEMPO REAL? Oh querido. Siempre tendrá que tomar muestras cuando cruce los límites del dispositivo. 'Tiempo real' es un argumento de hombre de paja y un requisito mal definido. C # está bien.
Gusdor
Obviamente no has oído hablar del trabajo de Joe Duffy . Ha estado trabajando en la programación de sistemas en C # desde al menos 2013 . El compilador de Roslyn puede compilarse en código nativo (así es como funciona UWP) y la recolección de basura no es un problema si prestas atención a lo que estás haciendo.
RubberDuck
14

Bueno, lo primero que debes hacer es ir a tu jefe y confesar. No ha tenido en cuenta su solicitud clara, y lo peor es que lo ha estado haciendo durante meses. No sé cuánto tiempo tienes en esto, pero suponiendo que es la mayor parte del tiempo asignado para completar el proyecto, tienes que enfrentar el hecho de que pronto estarás buscando un nuevo trabajo.

Cuanto antes lidies con esto, mejor.

En segundo lugar, no creo que pueda convencerlo de que ANSI C es inadecuado, lo que debe hacer es convencerlo de varias otras cosas (1) que c # es adecuado, (2) puede aprender fácilmente a mantener c #, (3 ) que no fue suficiente para escribirlo en C. Suponiendo que todavía tiene un trabajo y un papel que desempeñar en este proyecto, me concentraría en 2, haciendo hincapié en las similitudes entre c y c #.

Citas en respuesta a comentarios ...

Hace unos meses, comenzamos a desarrollar una aplicación [...] Después de unos días, descarté todo y comencé de nuevo con C #

jmoreno
fuente
¿En ninguna parte mencionó que había estado construyendo una versión de C # durante meses?
Anónimo
1
@ Anónimo: no importa si fueron días o meses, todavía no siguió las instrucciones de sus gerentes. El autor claramente no tenía las habilidades necesarias para desarrollar la aplicación en ANSI C.
Ramhound
1
@Ramhound: no estoy discutiendo que él no siguió las instrucciones de sus gerentes, solo digo que jmoerno se estaba besando como si hubiera pasado meses en tangentes. Además, si reconstruyó el proyecto en un par de días para servir como un prototipo funcional en el que se pueda basar la versión C más estable especificada, entonces tiene mucho sentido. Es parte de la etapa de planificación.
Anónimo
@ jmoreno - Disculpas, debo haber leído mal la pregunta.
Anónimo
2
@jmoreno - Por supuesto. Publiqué mi último comentario después de ver la cita que agregó. Disculpas una vez más.
Anónimo
12

ha ordenado que desarrollemos esta aplicación en ANSI C. La razón es que él es el único que estará presente todo el tiempo y, por lo tanto, debe ser capaz de comprender lo que estamos haciendo.

Este es un requisito bastante razonable.

También dictaminó que no deberíamos utilizar tipos de datos abstractos;

Esto no tiene sentido. Ahora está comenzando a oler un poco sospechoso, porque este es un requisito de diseño del programa y no un requisito de idioma. Si el código fuera fácil de mantener, la implementación de ADT o el uso de los bien probados y preexistentes deberían ser una prioridad.

Incluso nos dio una lista con el nombre de las variables globales (suspiro) que quiere que usemos.

Ok, ahora apesta. Ahora podemos decir que su jefe tiene una experiencia limitada no solo de varios lenguajes de programación, sino también de la programación en general. Un programador veterano experto, sin importar la preferencia de idioma, nunca haría tal declaración. (La única excepción que se me ocurre es si la mayor parte del código está destinado a ejecutarse en un sistema incrustado bastante pequeño, y por lo tanto se esperaba que toda la memoria de trabajo necesaria para el código fuera asignada previamente. La idea de que el mismo código se espera que tenga un nivel de pantalla que la UI argumenta en contra de que ese sea el caso, sin embargo).

Supongo que su jefe nunca ha estado involucrado en proyectos de software a gran escala y de misión crítica, pero es más probable que haya estado flotando en varios proyectos de baja calidad.

Por lo tanto, esto no tiene nada que ver con el lenguaje de programación C. También puede escribir fácilmente programas igualmente repugnantes en C #. Es un error muy común creer que el buen diseño del programa depende del idioma. ¡Eso simplemente no es cierto!

C # ciertamente tiene una sintaxis más bonita, más limpia y menos oscura que C. Tiene una gran cantidad de soporte de diseño de programas, ya que tiene muchas más palabras clave relacionadas con OO que C. Pero aparte de eso, no le dice cómo escribir sus programas. Si cree que todo lo escrito en C es horrible por defecto y todo lo escrito en C # es el paraíso por defecto, apuesto a que actualmente está escribiendo programas de C # bastante horribles sin darse cuenta.

Lo que sugeriría es que haga un diseño de programa abstracto, independiente del lenguaje, pero detallado antes que nada. Use el enfoque normal orientado a objetos. Qué objetos hay y cómo se comunican entre sí, cuáles son las dependencias necesarias, etc. Cuando le ha dado suficiente importancia al diseño del programa y lo ha escrito en papel, no debería importarle mucho a usted ni a su jefe. idioma en el que elegiste implementarlo.

Comunidad
fuente
1
+1 para "También puede escribir fácilmente programas igualmente repugnantes en C #".
Javier
11

El primer problema que debe abordar es emocional e irracional. La industria de TI está en constante cambio y, aunque hay lugares para todo, negarse a mejorar o aceptar el cambio es un problema.

¿Por qué su jefe se aferra a ANSI C? Si ese es el único idioma que él o ella conoce, entonces tal vez sea hora de un cambio, pero un argumento racional puede ser insuficiente. ¿Se sentirá infravalorado o posiblemente despedido si se ve obligado a trabajar en un idioma desconocido? Haga hincapié en la experiencia que tiene y otros beneficios que aporta.

Si no resuelve este problema, se desperdiciarán todos los argumentos racionales que pueda aportar. Como subordinado, es posible que no seas el que pueda tener esta discusión con él. Quizás mencione este tema a uno de los otros gerentes, si hay alguno.

También considérelo desde su perspectiva. ¿Por qué quieres usar C #? ¿Cuánto de esto es el deseo de usar algo nuevo y genial? Se honesto contigo mismo. Si reconoce esto, le ayudará a discutir más eficazmente.

La segunda cuestión es de riesgo y costo. Escribir software es costoso y la elección del idioma es un factor importante en eso. Considerar:

  1. ¿Cuánto tiempo tomará escribir en C # versus C? Con una orientación de objeto más fácil y una mejor recolección de basura, C # puede ser más fácil. Sin embargo, si la aplicación usa muchas llamadas API no administradas, C puede ser más fácil.
  2. Si usa C #, ¿necesita comprar herramientas adicionales? Parece que ya usa Visual Studio, pero ¿necesita herramientas adicionales para la localización, revisión y análisis de código, depuración, etc.?
  3. ¿Qué tan fácil es de mantener? Si encuentra un error, qué tan rápido se puede solucionar. C # puede reducir la orientación de este objeto. La recolección automática de basura también evita la mayoría de los problemas de pérdida de memoria y puntero.
  4. ¿Qué tan fácil es apoyar? Si tiene personal de soporte, pueden saber cómo leer un volcado de memoria, pero ¿saben cómo usar windbg con SOS? ¿Las máquinas de destino ya tienen instalada una versión adecuada del marco .Net?
  5. Considere la dotación de personal. ¿Cuántas personas conocen C versus C #? Si uno o ambos abandonaron la organización, ¿qué tan fácil sería reemplazarlo? ¿Los desarrolladores de C son más baratos o más caros que los desarrolladores de C #?

Podría continuar, pero el punto es dejar de discutir solo sobre los méritos técnicos de los idiomas. Los méritos técnicos son cosas que solo usted y su jefe entienden. Si comienza a hablar sobre el impacto comercial, atrae a un grupo mucho más amplio de personas y presenta un argumento mucho más convincente.

Quizás C es una mejor opción. C # no es automáticamente mejor para todas las situaciones. Tal vez haga este proyecto usando C, pero haga una prueba de concepto de C # para el próximo. Recuerda que puedes perder la batalla pero aún así ganar la guerra también.

akton
fuente
55
No estoy de acuerdo con la suposición implícita de que C # es, por defecto, una mejor opción que ANSI C. Por ejemplo, si desea permanecer independiente de la plataforma, C # es probablemente una mala elección.
@ ThorbjørnRavnAndersen Estoy de acuerdo. Por favor vea el último párrafo. También menciono casos como llamar a código no administrado. Supongo que la independencia de la plataforma habría excluido a C # en el OP. Quizás esta es una suposición incorrecta.
akton
1
La independencia de la plataforma fue solo una posible razón. Una redacción como "aferrarse a ANSI C", en mi opinión, indica un sesgo.
@akton: desde cuándo no puede llamar a código no administrado desde C #. Por supuesto, requiere un contenedor y eso introduce problemas adicionales de soporte, pero es posible. Además, puede admitir C # en plataformas múltiples si lo desea. Mono es compatible con todas las principales plataformas de escritorio (OS X, Windows y Linux). Dado que el .NET Framework basado en Microsoft Windows avanza, la base de características de Mono no coincidirá exactamente (ese ya es el caso con WPF) y, por supuesto, no podrá desarrollar aplicaciones Metro que se ejecuten en Linux. Por supuesto, es poco probable que se haga en este caso.
Ramhound
@Ramhound No dije que no se puede llamar a un código no administrado desde C #, solo que mucho puede ser una molestia. Del mismo modo, puede hacer desarrollo multiplataforma en C #, pero C es casi universal, como dijo Thorbjorn.
akton
7

Quizás otro argumento: probablemente sea muy difícil encontrar estudiantes de ciencias de la computación que tengan suficiente experiencia para escribir código C sin cometer errores. ANSI C no es lo primero que la gente aprende hoy.

Ahora todos los estudiantes de informática me matarán.

JohnB
fuente
ANSI C fue en realidad una de las primeras cosas que aprendí en la universidad. Comencé en 2004. Así que en los últimos 10 años todavía se estaba enseñando. Pasé muchas noches conectadas a través de SSH a un entorno Unix tratando de compilar mi código.
Ramhound
1
Es curioso, no aprendí ANSI C hasta mi último año en la Universidad. La primera lengua que se enseña fue Pascal, de modo que estoy protegido ...
tehnyit
Graduado reciente aquí; tuvimos exposición a C y C ++, sin embargo, la C estaba en un contexto incrustado y mínima. Ambos estaban en mi último año, puramente C # y Java antes de eso.
Ross
2
C simplemente ser difícil de programar correctamente es probablemente el mejor punto contra el uso de C.
Paul Nathan
7

No ha logrado convencernos por completo de que ANSI C era inadecuado. C es un lenguaje excelente que parece adaptado para el tipo de tareas que ha descrito. Con la breve descripción de la tarea (excepto el requisito de lenguaje), también recomendaría C (o tal vez ir).

Creo que el problema es que estabas programando en C con tu mente pensando en C #. Tengo un problema similar cuando cambio de Perl a C o Java. Debes aprender a adaptarte al idioma y no aprender a traducir desde tu forma de pensar hacia el idioma del día.

El problema no es tu jefe o el lenguaje C, el problema es abrir tu mente hacia diferentes formas de pensar. Cambiar el lenguaje de programación es algo que lo beneficiará.

BOC
fuente
44
Gracias por responder su primera pregunta sobre Stack Exchange Programmers. Sin embargo, es posible que desee que sus futuras respuestas sean un poco menos personales al no usar frases como "ha fallado por completo", "el problema es abrir su mente". Revise las preguntas frecuentes programmers.stackexchange.com/faq#etiquette . Creo que puedes hacer una buena descripción de tu punto con un lenguaje neutral.
DesarrolladorDon
2

Primero, debes decirle a tu jefe que ahora está en un idioma diferente. Él estará (comprensiblemente) enojado si traes algo intencionalmente en contra de los requisitos sin previo aviso.

Ahora, la mejor manera de explicar estas cosas a los jefes / gerentes es expresarlo en términos de tiempo y dinero. Calcule cuánto tiempo tomaría un proyecto de este tipo en ANSI C, y luego calcule cuánto tiempo tomaría en un nivel superior, como C #. Tenga en cuenta que dije de nivel superior, no moderno. Esto también puede ayudar a suavizar las cosas. Quiero decir, no abordarías pintar una habitación con solo un pequeño pincel, usarías rodillos y otras cosas que hacen que cada trazo (línea de código) cubra más área del proyecto. Además, si usted o uno de los miembros de su equipo no conocen C, o se sienten cómodos haciendo un gran proyecto en C, esto afecta aún más el problema del tiempo porque tendrán que ponerse al día.

También parece que tu jefe está tratando de microgestión. Estoy seguro de que una de las otras respuestas tratará de explicar cómo hacer que tu jefe lo haga menos

Earlz
fuente
La asequibilidad parece un posible argumento. Si bien el jefe (como cliente, según la sugerencia de @ MatthewFlynn) argumenta que no puede permitirse que el programa no esté escrito en C, OP puede argumentar que el jefe tampoco podrá pagar los costos de implementación y mantenimiento asociados con el programa. escrito en C. De cualquier manera, se necesitan compromisos para que las cosas sucedan.
rwong
1

La aversión del supervisor a los ADT se abordó en otra parte, al igual que la aparente inconsciencia del desarrollador de los costos de GC, por lo que me centraré en los "hilos".

Quizás, en lugar de pensar en términos de subprocesos .NET (o JVM, si está tan adoctrinado), lo que puede desear son múltiples procesos, utilizando algún mecanismo de comunicación entre procesos (IPC) para comunicarse entre ellos. Por ejemplo: mensajes de Windows, memoria compartida, memoria intermedia de archivo asignada a memoria, canalización con nombre, lo que sea. Dedique pequeños procesos a interactuar con un dispositivo o aspecto del dispositivo y verifique el IPC para comunicar actualizaciones y reconocer solicitudes, y tenga un proceso algo mayor para mantener la GUI y comunicarse con los "monitores" del equipo utilizando cualquier IPC que seleccione.

Roboprog
fuente