|
Today there are sh*t loads of OSes, why would you want to write a new one? Anyway, 99% of the ongoing projects is not an operating system so you can pick from lots of other popular languages. In one of my previous posts I mentioned that there is no other similar low level language however by fixing some issues with C could result in a good one to write driver level stuff.
|
|
|
|
|
pasztorpisti wrote: Today there are sh*t loads of OSes,...
None of which answered the question.
|
|
|
|
|
I answered the question, you just forget to quote the end of my post. My posts are not advertising that we have true alternatives in every areas where C/C++ is used. I just mentioned that even in the areas where C/C++ has monopoly better alternatives could be forged with todays knowledge.
|
|
|
|
|
No I don't see that answered.
Again if you were writing a OS today which language would you pick to write it in?
|
|
|
|
|
If I had to keep source and/or binary level compatibility then probably C. If I had total freedom then assembly and a new C-like language that has the unambiguous problems of C fixed.
|
|
|
|
|
So you would create a new language to create your new OS.
Have you created a language like C before? And written the support libraries for that new language?
|
|
|
|
|
Yes I created a compiled and a dynamic languages as hobby projects but that time without much focus on design and safety. Havent created a full fledged runtime support though. Anyway, if you are about to create a new OS then its not a big deal to put together a C like low level language with the base libraries as a first step. The complexity of the compiler+lib and the OS are not comparable especially if we make use of a tool like gcc or llvm.
|
|
|
|
|
pasztorpisti wrote: Even if something is good, it doesn't mean it becomes widespread
However the reality is that something that is in fact substantially better will become widely used.
And something that isn't will be tossed away.
There are all sorts of failed technology choices. And just a few winners.
If C/C++ were that bad then they would not have continued to retain the market share that they do.
|
|
|
|
|
I think I already answered this in a previous post. C/C++ simply can't be purged because of the huge legacy codebases. Better alternatives exist, the nearest to C++ is the D language. Its simple isn't used because it doesn't have library support that could compare to the legacy codebases for C++.
|
|
|
|
|
pasztorpisti wrote: think I already answered this in a previous post. C/C++ simply can't be purged
because of the huge legacy codebases.
And as I already said history is SPECIFICALLY full of cases where exactly that has happened.
So obviously it can happen.
pasztorpisti wrote: Its simple isn't used because it doesn't have library support that could compare
to the legacy codebases for C++.
Wrong. It isn't used because developers have not found an advantage to using it.
You do understand that there are many C++ developers and yet C (not C++) continues to be used significantly? Do you understand how C++ was adopted over time to take over much of the work previously done by C++ and yet C by itself continues to be used? The first part of that puts lie to your contention that legacy code preclude new adoptions and the second to your assertion that something that is better in some way must always universally replace the older because there no longer is any value.
|
|
|
|
|
jschell wrote: And as I already said history is SPECIFICALLY full of cases where exactly that has happened.
So obviously it can happen.
There is something in your statement. I guess languages are gone when they roots die. C/C++ have currently strong roots (at least Windows/*nix systems).
jschell wrote: Wrong. It isn't used because developers have not found an advantage to using it.
I still think this is partly because of library support and development environment support. Its also a high risk to start a commercial project with something new that can blow. Lets imagine a fatal D compiler crash (without the support of the authors) in the middle of your project! Startups are very slow for these simple reasons.
jschell wrote: You do understand that there are many C++ developers and yet C (not C++) continues to be used significantly? Do you understand how C++ was adopted over time to take over much of the work previously done by C++ and yet C by itself continues to be used? The first part of that puts lie to your contention that legacy code preclude new adoptions and the second to your assertion that something that is better in some way must always universally replace the older because there no longer is any value.
I guess you wanted to write C# when you were talking about the language that took over some of the work of C++. C# can became widespread (relatively quickly) because its supported by a huge rich company. Its library support is good, its IDE is superb. These give the base of one of your reasonings in a previous post: This language gave something. It made development easier and less risky because of the MS support. Noone makes you so nice IDE for D like the one you have for C#, same is true about support. Its not only the "coolness" and efficiency of the language that makes it widespread, money and/or time is also needed.
As I mentioned previously I like the simplicity of C, by modifying it a bit (without keeping the ugly backward compatibility) I think it could be a very nice language for low level coding where C++ and its friends were too high.
|
|
|
|
|
pasztorpisti wrote: C/C++ have currently strong roots (at least Windows/*nix systems).
Based on that then C/C++ will never cease to exist because there is no expectation that either or both of those OSes will cease to exist.
pasztorpisti wrote: I still think this is partly because of library support and development environment support.
Nope. If that was the case then Java/C# would have taken over.
pasztorpisti wrote: Lets imagine a fatal D compiler crash
I can't speak specifically about D but these days any marginally significant new language will not "crash" when it is released into the public in such a way that it would endanger a product. If it crashes at all then it is probably due to a language construct which can be worked around.
pasztorpisti wrote: I guess you wanted to write C# when you were talking about the language that took over some of the work of C++.
No. I was specifically using the example of when C++ became widely known and C (not C++) was the predominant language. C++ rapidly gained market share. Yet C did then and still does retain a significant market share.
This demonstrates that there is a shift when the market sees a better language come along DESPITE the extensive code base. It also demonstrates that C still finds and audience because it is still used. Thus it STILL provides a benefit that developers can appreciate.
|
|
|
|
|
jschell wrote: Based on that then C/C++ will never cease to exist because there is no expectation that either or both of those OSes will cease to exist.
Good point. Thats why I think that llvm is a great invention and a beam of hope. Its a nice thing that can glue languages together and its already good enough to compete with gcc that is a monster codebase compared to llvm.
jschell wrote: Nope. If that was the case then Java/C# would have taken over.
Despite the nice design and universality of the packages of these languages they far not cover as many areas as C/C++ libraries and they often don't cover native OS specific staff whose api is also in C. Fortunately they are often well suited for all kinds of enterprise problems where it would be a guilt to choose other languages.
jschell wrote: No. I was specifically using the example of when C++ became widely known and C (not C++) was the predominant language. C++ rapidly gained market share. Yet C did then and still does retain a significant market share.
This demonstrates that there is a shift when the market sees a better language come along DESPITE the extensive code base. It also demonstrates that C still finds and audience because it is still used. Thus it STILL provides a benefit that developers can appreciate.
A lot of factors are involved when you have to decide which language is the nearest to the theoritical domain specific dream language (+libs) to solve the actual problem. If you have to decide for example between C and C++ you are already in trouble because most of the problems are just in between. The libraries are shared between these languages but C++ is a messy language overwhelmed with freature redundancy while C is much simpler but misses some really nice features that make development much efficient and manageable. For this simple reason I always choose C++ because I already know which features to use and which ones to avoid but many C coders don't want to bother with learning the feature mass and the freestyle of C++. Without backward compatiblity it would be so easy to put together an extended-repaired C and cleaned C++, and even a good devenv, but what about library support? Thats the only thing that keeps me back from wasting my time on starting a battle I hardly win. Maybe in my older years as a hobby project when I will have less todos because its definitely fun to mess with languages even if the results go the the dustbin...  With llvm its relatively easy to experiment compared to the older times.
|
|
|
|
|
pasztorpisti wrote: A lot of factors are involved when you have to decide which language...
I have been programming for 40 years. I have spent many years programming in all of the popular languages. I programmed in C# version 1. I programmed in Java 1.0.4 (before 1.4). I programmed in C++ before there was a ANSI standard. I programmed in C before there was an ANSI standard. I have also programmed in Fortran, Pascal, Perl, assembly (for various targets), SQL (a number of variants), and even created several small languages myself.
I have been working in large systems for more than a decade. I specialize in back end systems and interfacing between sub-systems (many, many legacy systems.)
And I have also spent a great deal of time actually seeking real knowledge about making technical decisions.
So yes I am in fact aware of what factors are involved in making technical decisions.
The conclusion I have come to is that
1. The VAST majority of time technical decisions are made subjectively. There is no objective basis for the decision. The users do it just because they want to.
2. The VAST majority of time it doesn't matter. And for many cases where it it might be considered to matter the problem domain drives the decision (you can't program in C# on a system which does not have libraries, .Net, etc no matter why you think it is a good idea.)
pasztorpisti wrote: Without backward compatiblity it would be so easy to put together an extended-repaired C and cleaned C++, and even a good devenv
I have written small languages including a small C (used in a commercial application.)
I followed the ANSI process for C and C++ extensively when that first occurred.
I followed the path of Java as it attempted to reach a consensus and corporate acceptance of a accepted standard along with following the JCP from inception and following a number of topics in there throughout their lifetime.
I have even written an IDE.
So I know for a fact that it is not "easy".
|
|
|
|
|
jschell wrote: <layer>I have been programming for 40 years. I have spent many years programming in all of the popular languages. I programmed in C# version 1. I programmed in Java 1.0.4 (before 1.4). I programmed in C++ before there was a ANSI standard. I programmed in C before there was an ANSI standard. I have also programmed in Fortran, Pascal, Perl, assembly (for various targets), SQL (a number of variants), and even created several small languages myself.
I have been working in large systems for more than a decade. I specialize in back end systems and interfacing between sub-systems (many, many legacy systems.)
And I have also spent a great deal of time actually seeking real knowledge about making technical decisions.
So yes I am in fact aware of what factors are involved in making technical decisions.
Don't expect me to respect your technical knowledge based on the number of years you spent in the industry. Almost everybody have their areas of expertise here and noone is superman. There are some forum members here I really respect for their clear explanations and opinions despite the fact that I have no clue how old are they and how much have they worked on this and that. This is a discusson about the good and bad traits of C/C++ so please stick to that and don't drive this thread offtopic or into a personal tug of war because I wont participate in that. Please use your experience to list pros and contras about C/C++ thats what the OP is interested in.
jschell wrote: 1. The VAST majority of time technical decisions are made subjectively. There is no objective basis for the decision. The users do it just because they want to.
I wouldn't call a decesion so subjective when it is based on past experience. For example a technical meeting is quite enough to make a sum of everyones knowledge in a given area and to make a list of possible solutions and to list pros and contras for each. I think after this the subjective part of the decesion can considerably decrease. When you have to make decisions in unknown areas then its more subjective but spending 1-2 years in a given area make things more objective because you will know 1-2 definitely good solutions to more and more problems. This is however quite offtopic, its not about C/C++.
jschell wrote: 2. The VAST majority of time it doesn't matter. And for many cases where it it might be considered to matter the problem domain drives the decision (you can't program in C# on a system which does not have libraries, .Net, etc no matter why you think it is a good idea.)
Thats the same what I was talking about when I mentioned windows' backward compatibility. Thats a problem that drives the whole thing. From here we can easily go to an even higher level: yes, most ot the time it doesn't matter what the coder thinks because its not a technical but a business decision, thats why windows keeps the backward compatibility (an important key to its success) and partly thats why coders suffer from C's and C++'s defects. On a higher level money rules.
jschell wrote: I have written small languages including a small C (used in a commercial application.)
And how much time have you spent making the design for it to make it good to solve specific problems like system programming while keeping it well optimizable, easy to static-check, and less prone to certian frequent programming mistakes? Fro example C definitely has some holes to fix, and C++ has even more.
jschell wrote: I followed the ANSI process for C and C++ extensively when that first occurred.
I followed the path of Java as it attempted to reach a consensus and corporate acceptance of a accepted standard along with following the JCP from inception and following a number of topics in there throughout their lifetime.
I have even written an IDE.
So I know for a fact that it is not "easy".
Most coders with some professional calling read some blogs and meet some specifications like C++11. Still many of them are unable to point out certian language defects. This is especially true for C++ beginners who just think its cool when you use all fancy C++ features however this is far not true. Its a sad fact the C++ development process will never kill off serious mistakes form C/C++, they might add nice and useless features to the language but the old mistakes remain forever and new ones are also coming.
|
|
|
|
|
pasztorpisti wrote: Don't expect me to respect your technical knowledge based on the number of years you spent in the industry.
Your knowledge is based specifically on your experience with C++.
My knowledge is based on my experience with multiple languages, including C++, in addition to actively seeking out other sources specifically about technical advantages both in technology and process.
pasztorpisti wrote: This is especially true for C++ beginners who just think its cool when you use all fancy C++ feature
Could be. That however has nothing to do with me. I am not a beginner with C++. Nor am I beginner with other languages. And I know the mistakes that people can make with all of them. And the "nice and useless features" that are added to languages besides C++. Matter of fact I would say that C++ is in fact much more restrained in that. Certainly much more restrained than C#.
|
|
|
|
|
jschell wrote: Your knowledge is based specifically on your experience with C++.
My knowledge is based on my experience with multiple languages, including C++, in addition to actively seeking out other sources specifically about technical advantages both in technology and process.
Not true, I've worked with every language you mentioned extensively except fortran, but this drives this whole thread far offtopic.
jschell wrote: Could be. That however has nothing to do with me. I am not a beginner with C++. Nor am I beginner with other languages. And I know the mistakes that people can make with all of them. And the "nice and useless features" that are added to languages besides C++. Matter of fact I would say that C++ is in fact much more restrained in that. Certainly much more restrained than C#.
Then we agree that C/C++ has obvious defects that shouldn't exist with todays technology.
|
|
|
|
|
pasztorpisti wrote: Then we agree that C/C++ has obvious defects that shouldn't exist with todays
technology.
I didn't say that.
|
|
|
|
|
Well, up until now we basically havent listed any useful stuff for the OP about C/C++ benefits/defects. We just continued a totally unneded flame war that started from my statement about C/C++ headers so now I'm going to give a random list of some useful stuff about defects without attempting to be comprehensive because that would be too long.
Today it would be quite reasonable to use a "fixed/repaired" version of C without most of its defects - the same is true for C++. Of course no language is perfect but the number of C/C++ defects are unreasonable in a modern widely used general purpose language. There are several obvious bugs just alone in C that are directly inherited by C++. My favorite is: The Most Expensive One-byte Mistake[^]
The simple C language alone allows for a lot of programming errors most of which could be eliminated just by making the language more strict. I link a list of C programming errors that can be committed easily and accidently: http://www.andromeda.com/people/ddyer/topten.html[^]
Previously I mentioned header files that started a dispute. Some people would argue that headers are good because they separate the interface for reading. I think this is rather a personal preference - with todays tools you can esily extract such information on the fly for languages with better design like C# and Java as well where full runtime type information is available in the ide basically all the time. Even if you prefer header files, there are other languages that implement it in a much better way, I would compare C/C++ headers to assembly text file includes (containing full fledged C source code). (My favorite and silently compiling include related bug was when I found an anonymous namespace in a header, imagine what happens in this case...). Declarations in headers are not guaranteed to match cpp content if a mistake is made not to mention hidden dependencies. I would even question the readability of C++ header files that contain not only public/protected stuff but private and implementation details too (inlined functions -most notably templates - and data members are of course separated from actual implementation of the class methods). Headers and macros held back the development of C/C++ diagnostic tools a lot, this is why some modern (younger) languages has much better ide support even today.
Of course C++ inherited almost all mistakes and because of this immediately developed some necessary new ones. It also has its own unnecessary list of mistakes as well.
I would mention something that became immediately evident to me when I started using C++: compile speed is unreasonably slower than that of other languages even if we take the compile time of just individual compilation units in a relatively small or mid-sized project. One good comparison to this was when I used Borland Delphi and its stepbrother C++Builder that has the EXACT SAME ide but with C++ language. The compile times were so annoying in the C++ version that made iterations much worse despite the fact that I was tempted to switch to C++. C++Builder wouldn't be able to compete with Delphi even if we had the choice to use one of the best C++ compilers of the last decade and speed is gold when its about fast iterations and development time. Delphi compiled objectpascal so quickly you didn't even notice it - you modifed code, pressed the debug button, and half or one second later you saw the window of your debugged application to open - this is priceless. My favorite is when someone comes with the resoning that "C++ optimizes quite well, that takes time...". Other compilers optimize as well. This slow compile time has much more todo with reasons listed here: http://www.drdobbs.com/cpp/c-compilation-speed/228701711[^]. Please skip the first 3 links in the article becauase I think that has advertising purposes.
I'm open to any reasoning against the above list.
Another thing I simply can't understand: how does it come that you built large systems and you just say it doesn't matter what langues/tools you are using and most of the time the decisions are subjective. I completely disagree with these two points. I know that sometimes you are told to use XYZ technology becuase the customer wants it for this and that reasons (or just because there is a fashion wave and everybody wants to use XYZ technology to solve a problem beacause now that is cool) but this isn't always the case. In my opinion tools (including dev envs and languages) are very important. Depending on the type of project it often whort investing the time even to develop some additional project spcific tools because in time (and at the same time in cost) it often pays off well. At the same time if you automatize something with tools then you eliminate a lot of human errors that can increase the quality of the product a lot. You mentioned the importance of a regulated development process - I think every company that continues other than garage development has some kind of dev process, but that is another dimension of the problem of cutting development time and providing quality on a completely different level: management. The dev process is the tool of the manager, the language/ide is the tool of the coder. Without properly chosen tools both dev time/cost and quality suffers for sure but on a different level when using a bad software dev process.
modified 24-Sep-12 21:23pm.
|
|
|
|
|
C headers provide portability.
There are LOTs of C compilers. Headers provide an easy way to build a C compiler for any PIC, ARM, X86, (name your own) architecture.
It's not about the developer. It's about the CPU/Memory. About the C/C++ to machine conversion.
Headers give a lot of headaches to developers, but developers pay that price to see their code run "everywhere" and not have to rewrite ALL the code every 2 years (for other architecture).
Now you tell me that developers should have better tools. And they have. They have a lot of other languages that don't keep the "header" problem.
The slow, very basic, error prone compiling.
But that languages don't have the portability of C/C++ headers.
Portability cannot be enforced. It is the result of ease of implementation of a language for an architecture.
C/C++ compiler based approach is unmatched in this area.
it´s the journey, not the destination that matters
|
|
|
|
|
ErnestoNet wrote: C headers provide portability.
Not exactly sure what you are claiming but as stated it is wrong.
C, the language (not just headers) provides some portability but it is not guaranteed nor even easy and most of that is achieved through the standard libraries.
ErnestoNet wrote: C/C++ compiler based approach is unmatched in this area.
No idea what you are talking about.
Line for line, Java is more portable than C/C++.
C/C++ both have features that are specifically not portable in comparison to Java.
|
|
|
|
|
Headers provide an easy "standard" to build a compiler from.
If there are more compilers, there is more portability.
Java is not more portable than C. Java is (that I know) very portable, just not more portable than C.
C has compilers built from a lot of companies for a variety of products (PIC, PIC32, ARM, X86, etc). Java mostly from Sun for X86.
it´s the journey, not the destination that matters
|
|
|
|
|
It's not the C headers that provide portability. Nothing proves that better than the existence of crossplatform languages without headers.
|
|
|
|
|
Text based compilers are easier to write that binary based compilers.
The headers approach is easy to build a compiler from.
C is a very simple language to write a compiler.
There are LOTS of C compilers.
More compilers provide better portability.
Portability is also usually the result of compatibility. So the reason why the headers approach doesn't change...
There are not many cross platform/architecture languages.
Name a crossplatform language and I'll compare that to C in terms of portability....
it´s the journey, not the destination that matters
|
|
|
|
|
If we speak of writing a compiler that will be used to compile thousands of other programs, then its worth investing time to make the compiler as good as possible otherwise you will pay the price as many times as you compile/develop a program or more importantly a useful ide for the language.
I've never argued against the portability of ansi C, lets consider that as a positive trait of the language but that has really nothing to do with the header files. For example freepascal is crossplatform and it has no header files, the same is true for java+jvm and .net mono + its languages that have quite extensive and unified crossplatform library compared to that of ansi C.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
