51–60 of 61 posts
Those TIOBE numbers (linked to in the article) are quite interesting. As well as C refusing to go away, there's a noticeable surge for C#, Objective-C and Lua, and a substantial erosion in the popularity of trendy languages like Python and Ruby.
Earlier quoted context omitted.
I think, wolf 3d is C++ too.
Why would you think that? That was their first FPS released way back in 1992. If you are thinking of Return to Castle Wolfstein, that was C as well, using the Quake 3 engine. But id didn't even make that game.
Pure C seems to be enjoying a bit of language fad hipness lately but I don't know anybody that has to maintain a large body of non-trivial, low-level code that chooses pure C over C++. There's a good reason that everything from Solaris to V8 to Photoshop to Quake is written in C++ and not C. That C is still in wide use after 40 years is a testament to the elegance of its original design but let's not get carried away…
I've consulted in the past on embedded projects. In my experience, maintaining a non-trivial body of C++ code is easily a factor of 2-10x harder than maintaining equivalent C code. I have lots of reasons why this is true, many of which are specific criticisms about C++. There is one issue that is industry specific: Everyone working in embedded has either come from the bottom up (deep firmware in assembly or machine c…
Earlier quoted context omitted.
Zawinski's point is true iff "large application" means an application which allocates and frees plethora of tiny chunks -- however I will argue that this is not a necessity, rather a style coming from a try to port scripting experience to lower-level languages to speed up development. Probably in most cases this is not a problem (no one will notice 100us speedup in GUI), but if one starts to tweak GC or new to rescue…
Because then you have to control ALL of the memory, not just the data that you're interested in optimizing. Not to mention that (at least in the JVM) the gc is pretty tweakable, and the entire team may not need to know about all of the tweaks.
Pure C seems to be enjoying a bit of language fad hipness lately but I don't know anybody that has to maintain a large body of non-trivial, low-level code that chooses pure C over C++. There's a good reason that everything from Solaris to V8 to Photoshop to Quake is written in C++ and not C. That C is still in wide use after 40 years is a testament to the elegance of its original design but let's not get carried away…
The Linux kernel, Subversion and PHP are pure C. And don't get me started on the BSDs or binutils... ld and libbfd are pure C and its C++ replacement (gold) is still not widely used. And this came without thinking about it... surely in two more minutes or by going to ohloh I could fire a couple more large bodies of non-trivial low-level C code at you.
I tried writing Linux kernel drivers; it was a horrifying mess. Tragically, it would have been easily managed in C++.
Earlier quoted context omitted.
Lua is small and embeddable. You can run multiple independent instance of it in the same process. The lua table is a very useful data structure. Then you have luajit - also a small, easy to embed solution, that approaches standard "C" written code, and it's main weakness, from what I understood (Mike Pall had a post about it) is it's garbage collector. On top of that, ffi bindings make "C" calls extremely fast, when…
Using LuaJIT with minimal FFI C code to optimize, seems to be the best way forward in maximizing both performance and maintainability. What would be really interesting is to see someone highlight specific cases where this approach ultimately fails to measure up in performance with using pure C. I would think that the LuaJIT approach would be tens of times more maintainable for a sufficiently large application, so it'…
One area which is not easy translatable is OpenMP (www.openmp.org), inlined assembly, and SSE packed floats. But that's okay, and even then there is probably a better alternative - a language more suited to such tasks, instead of "C" - OpenCL (www.khronos.org) or DirectCompute.
But for general coding, it's very very good.
Earlier quoted context omitted.
All RAD's products are pure C at the interface level. Most of them are pure C at the implementation level, too. The one exception is that Telemetry (which I work on) uses C++ to implement the C interface, but only minimalistically.
I've had the pleasure of integrating your Granny SDK into our engine at the indie iOS shop I work at and it's been a total pleasure to work with and a perfect example of solid C interface design. Now when can we get telemetry support? ;)
I'm confused. Did C stop being taken seriously at some point? C is the only language that you can truly get things done without having to fight the language every step of the way. I can't say the same of... well, any other language I've used in the past 5 years.
agreed. and if you do any sort of embedded work, you must know C and C++. If history is any predictor of the future, chips will continue to get smaller and the "embedded" development world, I think, will proliforate and demand coders to know C and C++ at least for the next several years until fancy tools/compilers argue things like Java and C# code bloat doesn't matter because a 4Gig embedded system will be the norm.…
Not saying it disappeared, but there is now a bifurcation between C and C++ programmers.
Earlier quoted context omitted.
I've consulted in the past on embedded projects. In my experience, maintaining a non-trivial body of C++ code is easily a factor of 2-10x harder than maintaining equivalent C code. I have lots of reasons why this is true, many of which are specific criticisms about C++. There is one issue that is industry specific: Everyone working in embedded has either come from the bottom up (deep firmware in assembly or machine c…
Then why doesn't somebody clue in Adobe, Ableton, Epic Games, Pixar, Valve, Google etc and get them to abandon their wicked C++-loving ways? If what you say is true in general then you could save a lot of the brightest engineers in the world a lot of headache.
For low level systems work, C++ can be considerably more difficult than C to organize and port large programs.
It isn't "C++ is always worse than C" it is "C is often better than C++ for a given task, depending on task"
Pure C seems to be enjoying a bit of language fad hipness lately but I don't know anybody that has to maintain a large body of non-trivial, low-level code that chooses pure C over C++. There's a good reason that everything from Solaris to V8 to Photoshop to Quake is written in C++ and not C. That C is still in wide use after 40 years is a testament to the elegance of its original design but let's not get carried away…
I've consulted in the past on embedded projects. In my experience, maintaining a non-trivial body of C++ code is easily a factor of 2-10x harder than maintaining equivalent C code. I have lots of reasons why this is true, many of which are specific criticisms about C++. There is one issue that is industry specific: Everyone working in embedded has either come from the bottom up (deep firmware in assembly or machine c…