4 ms·

I know a lot of successful companies with products that are notoriously poorly coded : - "security software"; - "game industry"; - "car industry"; And if you

I know a lot of successful companies with products that are notoriously poorly coded : - "security software"; - "game industry"; - "car industry"; And if you read correctly I think the biggest issue is TIME is MONEY. What are the advantages of using techniques that: - are expensive (productivity is constant in sloc whatever the language); - are notoriously a systemic risks given their domain of work and is hard to audit; - that can be smoothly achieved by upgrading a faster to build architecture in a scripting language ; They may have bigger balls of steels than me doing it in C and be the best programmers in the world. My question is business oriented: what is the economic rationale of a full C solution from start?

ArkyBeagle 11y ago
Beats me. I know that if I had a large enough project and had to add people, I have a dozen people in my Rolodex who speak 'C' at the expert level and that they will perform. But depending on the problem domain, that might mean C++ or it might mean Python or something else. But given the level of hostility the language inspires, I have to wonder. To wit "bigger balls of steel" and "best programmers in the world." Both sentiments are quite foreign to the sorts of environments I've worked in, I assure you.
- SFjulie1 11y ago
  Sorry for you then. Living in such a boring world, and what a disdain-full answer that makes my point. I have add my share of conferences technical or about FOSS. And I met peoples with a lot of passion ... and code delivered. You probably use their software daily. I have been using more than 13 langages ranking from C to forth, matlab, vhdl, spice, python, perl and php. There are definitively cultures associated with languages and beliefs. Perl community is thinking coding is like speaking/writing a foreign language; Ruby about you IQ and technical skills are totally correlated with how nice your apple laptop looks like and how expensive it is. They are our hipsters (troll); Python secretly hides a sect hating braces and everything that looks like C and believe C coder can't make safe thread code, malloc, correct string handling. And they hate braces. for c++ coder referring to linus torvalds rant would be the spirit. Java coder believe in the utltimate safe portable VM and the power of GoF. And think people look the wrong way; Haskell thinks of themselves as alchemists loving to use obscure terms coined by an hallucinated metaphyscian priest that said ET must exists and that no one will notice. They still laugh of their ultimate joke; And C coders think that only them are the pure programmer, the only one that can see the matrix between the purity of abstraction and the undetermination of hardware/norms due to the imperfection of the humans. But, with their discipline that is above the norm (no noob accepted) they can fight the God of Entropy FORTRAN coder think that computers are a pain and would just like to have exact figures much more than nice looking interface and wonder when a correct intuitive language will appear (<--- My sect) They appear maybe because for each language comes a practical field of use and that one computer language cannot fill all the needs. The need for correction and exactitude in science conflicts with the "ease of use" of numbers. The need for having cheap workforce conflicts with efficient cheap to maintain code; The need for preventing embezzlement (origin of SQL) conflicts with creative accountability; At one moment, at my opinion C is like a middle age corporation. Trying to promote a one best way of CS that always boil down to C. C community maybe "professional" as opposed to "enthusiasts". But I think it does not always serve them. And I do not think that recognizing Computer Science is a peaceful uniform land, but an arena full of organic entities in conflicts with logical distinct rationalities for the same resources. In short, I have the write to mock other cultures.
  - ArkyBeagle 11y ago
    Nicely put. Very nicely put. I don't know how you came up with "disdainful"; it's more sort of sad and weary as I read it now. After all, I started with "Beats me" - such a decision would have to be very local. The first rule of 'C' is "don't use 'C'" these days... the people I know DON'T swagger; that was my point. The "professionals" vs. "enthusiasts" divide is extremely interesting in all fields of endeavor. I'm definitely on the "professional" side. I... don't think 'C' programmers are "above any norm"; they just sort of know where the rocks are right under the surface of the water. It's more difficult to explain than to do. If a bunch of people misrepresent themselves as ... badass because they sling 'C', I can't help that. The appropriate mentality for it is one of caution. I specifically called that out here... It also matters less because coding a system is roughly 5-10% of the actual cost of most deployed systems. Language matters much less than mechanism. Meanwhile, the worst horrors are inflicted using systems like SAP. Don't feel too sorry for me; I use at least three language systems every day, and have messed with ... dozens ( all resulting in deployed code at some level) , including graphical CASE tools.
vidarh 11y ago
If you are building large scale systems, the amount of time spent writing and testing actual code, rather than collecting requirements, designing the solution etc. is typically small. Imatix also specialise in code-generation. One of their earliest open source releases was Libero - a code generator to generate state machines. The point being that they have spent a couple of decades on solutions based around minimising the sloc, and while a lot their output is in C, a large part of the code they write is not C, but code generators and input to code generators. In terms of their techniques, a both the code generation and many of the other techniques they advocate are about reducing and isolating risk: Generate code so that you DRY things up and can focus on testin a smaller code base; split code into modules separated by process boundaries and message-passing, giving you smaller modules to test, boundaries across which you can add high availability (distribute message across multiple instances) or handle failures by queueing and so on. And as much as I love "scripting languages" - almost all my code is Ruby these days - there are many areas still where C is necessary for performance. The approach advocated in this book fits neatly with that: Nothing stops you from interoperating with any language you want - the message passing creates nice boundaries to isolate components in whatever mix of languages you want. But also keep in mind that they've been doing this for more than two decades. They have amassed a lot of tools and a lot of experience in doing C fast and right. It might very well be that the economic case for/against C or other languages would look very different to them if they were to start today without that experience. That said: It also isn't all about economy. I regularly reject job offers because it's not what I want to do. If we all made all our decisions based on time being money, most of us would be in different jobs.

ArkyBeagle 11y ago

Beats me. I know that if I had a large enough project and had to add people, I have a dozen people in my Rolodex who speak 'C' at the expert level and that they will perform. But depending on the problem domain, that might mean C++ or it might mean Python or something else. But given the level of hostility the language inspires, I have to wonder. To wit "bigger balls of steel" and "best programmers in the world." Both sentiments are quite foreign to the sorts of environments I've worked in, I assure you.

SFjulie1 11y ago
Sorry for you then. Living in such a boring world, and what a disdain-full answer that makes my point. I have add my share of conferences technical or about FOSS. And I met peoples with a lot of passion ... and code delivered. You probably use their software daily. I have been using more than 13 langages ranking from C to forth, matlab, vhdl, spice, python, perl and php. There are definitively cultures associated with languages and beliefs. Perl community is thinking coding is like speaking/writing a foreign language; Ruby about you IQ and technical skills are totally correlated with how nice your apple laptop looks like and how expensive it is. They are our hipsters (troll); Python secretly hides a sect hating braces and everything that looks like C and believe C coder can't make safe thread code, malloc, correct string handling. And they hate braces. for c++ coder referring to linus torvalds rant would be the spirit. Java coder believe in the utltimate safe portable VM and the power of GoF. And think people look the wrong way; Haskell thinks of themselves as alchemists loving to use obscure terms coined by an hallucinated metaphyscian priest that said ET must exists and that no one will notice. They still laugh of their ultimate joke; And C coders think that only them are the pure programmer, the only one that can see the matrix between the purity of abstraction and the undetermination of hardware/norms due to the imperfection of the humans. But, with their discipline that is above the norm (no noob accepted) they can fight the God of Entropy FORTRAN coder think that computers are a pain and would just like to have exact figures much more than nice looking interface and wonder when a correct intuitive language will appear (<--- My sect) They appear maybe because for each language comes a practical field of use and that one computer language cannot fill all the needs. The need for correction and exactitude in science conflicts with the "ease of use" of numbers. The need for having cheap workforce conflicts with efficient cheap to maintain code; The need for preventing embezzlement (origin of SQL) conflicts with creative accountability; At one moment, at my opinion C is like a middle age corporation. Trying to promote a one best way of CS that always boil down to C. C community maybe "professional" as opposed to "enthusiasts". But I think it does not always serve them. And I do not think that recognizing Computer Science is a peaceful uniform land, but an arena full of organic entities in conflicts with logical distinct rationalities for the same resources. In short, I have the write to mock other cultures.
- ArkyBeagle 11y ago
  Nicely put. Very nicely put. I don't know how you came up with "disdainful"; it's more sort of sad and weary as I read it now. After all, I started with "Beats me" - such a decision would have to be very local. The first rule of 'C' is "don't use 'C'" these days... the people I know DON'T swagger; that was my point. The "professionals" vs. "enthusiasts" divide is extremely interesting in all fields of endeavor. I'm definitely on the "professional" side. I... don't think 'C' programmers are "above any norm"; they just sort of know where the rocks are right under the surface of the water. It's more difficult to explain than to do. If a bunch of people misrepresent themselves as ... badass because they sling 'C', I can't help that. The appropriate mentality for it is one of caution. I specifically called that out here... It also matters less because coding a system is roughly 5-10% of the actual cost of most deployed systems. Language matters much less than mechanism. Meanwhile, the worst horrors are inflicted using systems like SAP. Don't feel too sorry for me; I use at least three language systems every day, and have messed with ... dozens ( all resulting in deployed code at some level) , including graphical CASE tools.

vidarh 11y ago

If you are building large scale systems, the amount of time spent writing and testing actual code, rather than collecting requirements, designing the solution etc. is typically small. Imatix also specialise in code-generation. One of their earliest open source releases was Libero - a code generator to generate state machines. The point being that they have spent a couple of decades on solutions based around minimising the sloc, and while a lot their output is in C, a large part of the code they write is not C, but code generators and input to code generators. In terms of their techniques, a both the code generation and many of the other techniques they advocate are about reducing and isolating risk: Generate code so that you DRY things up and can focus on testin a smaller code base; split code into modules separated by process boundaries and message-passing, giving you smaller modules to test, boundaries across which you can add high availability (distribute message across multiple instances) or handle failures by queueing and so on. And as much as I love "scripting languages" - almost all my code is Ruby these days - there are many areas still where C is necessary for performance. The approach advocated in this book fits neatly with that: Nothing stops you from interoperating with any language you want - the message passing creates nice boundaries to isolate components in whatever mix of languages you want. But also keep in mind that they've been doing this for more than two decades. They have amassed a lot of tools and a lot of experience in doing C fast and right. It might very well be that the economic case for/against C or other languages would look very different to them if they were to start today without that experience. That said: It also isn't all about economy. I regularly reject job offers because it's not what I want to do. If we all made all our decisions based on time being money, most of us would be in different jobs.