http://www.reddit.com/r/programming/comments/aue06/going_back_to_c/
Going back to C (self.programming)
submitted 5 hours ago by buddhabrot
When I was 12 someone gave me a Metrowerks IDE to learn programming on my mac. I learned a lot with it, and got programming in C. I never really wrote a large program in it, only things like ROM hacks that extracted levels and models from snes/psx games I liked. Later, I got a windows PC and messed around with MFC in C++. That was the end for me, programming UI's was too much work in C++ and I couldn't handle the encyclopedic knowledge needed to program the Microsoft framework.
Later, I learned Java, which was also the language most commonly in my college. Making UI's was a blast with it, I could factorize anything and really loved making as generic code as possible with it, even for small projects. Everything I made was made in Java.
Later in uni, I started learning functional languages, we used Haskell in one class. I got intrigued with Haskell and started solving Euler problems, up to this day I still have not written anything useful in Haskell but I love using it.
In the mean time I did some jobs for writing web sites. I used perl and php. After a while I only used php and used it more frequently.
After working for a while as a programmer I started to love higher-level languages, most of all Ruby. I became convinced that higher-level interpreted languages were the future because the slower execution times were to become meaningless. For any web projects I started using Ruby on Rails and to this day it still is my favourite framework.
Then, I learned Erlang because everyone was talking about it, and it showed me how to unleash parallellization, in whole new ways. I still think Erlang is the most amazing language I have ever seen. But then I found out it was also rather slow for the things I had in mind with it. I just didn't find any use for it and never completely learned the language.
Last week I wanted to make a big poster of a fractal. I wanted to compute it on a friend's octocore, and write a fast parallellized program. At first, I used Ruby, thinking it would perform better than I thought. And I quickly abandoned the idea because it was too slow.
Then I rewrote the same single-threaded algorithm in Haskell and saw that it was much, much quicker. But when I tried to parallallize it, I couldn't fathom how to do it in Haskell and abandoned the idea. I tried to write a parallellized version in Erlang, and while it spreak across the machine nicely, each individual process was way too slow, the parallellized algorithm was hundreds of times slower than the single-threaded haskell.
Because I really wanted that poster, I decided to switch to C because I had this idea that nothing could fail in C. And I started to code in a language I hadn't used for years, even a decade. And suddenly it hit me, everything made sense. Sure, I was writing so much boilerplate but it didn't bother me. I suddenly realized that everything I wrote would be inside the program's code, and that nothing more would. It was a great feeling.
I used simple pthreads to do the parallellization, and I used libgd to output my data to a png file. I started learning about mutex lock hierarchies to make the parallellizations overlap without endangering thread safety, it was all ugly code and the API's felt horrible compared to what I was used to.. but it all worked out. The resulting program was thousands of times faster than anything I had written.
And now, I am seriously wondering where I have been all this time. Sure, I still think C is incredibly clunky. But now I got the dust off of my old course on writing compilers (Modern compiler implementation in C), and I want to write a compiler in C for a small programming language. I want to get down to earth again, and write things that are efficient and just run very quickly. I want to write lots and lots of code and know exactly what every line does.
Has anyone else had this feeling, this evolution? Am I going mad? Do you think C will last, and there are intersting jobs left for pure C developers?
208 commentssharesavehidereport
comments
sorted by: new200
formatting help
save
chmod700 1 point 3 minutes ago[-]
I run gmake and gcc, And I ain't never called malloc without calling free.
You kids get off my lawn with your ruby, java, vm crap. They're all written in C.
permalinkreportreply
frikk 1 point 8 minutes ago[-]
So... about that wall-sized fractal generator. Source? I'd love to make one of those!
permalinkreportreply
MpVpRb 1 point 13 minutes ago[-]
I do embedded systems programming.
I program in C and C++.
I use C++ in a fairly minimal way...
No MFC, ATL or templates.
No complex constructors.
No complex inheritance.
Dynamic object creation only when necessary.
I like simple.
permalinkreportreply
STATUS_SUCCESS 1 point 15 minutes ago[-]
Welcome back to programming.
One of the reasons the languages you mention even exist is the ridiculously fast hardware that has become available over the years.
"Is this possible on this hardware?" is not a question asked by very many programmers these days.
permalinkreportreply
nint22 1 point 30 minutes ago* [-]
I find it funny you said C is clunky. Yes, it's quite a "verbose" language with the old concept of header files that unnecessarily repeat lines of codes, but it's nothing compared to the bloat and overhead of Java, C++, etc. OOP languages are notorious for the boilerplate code; even if you are a good programmer, the language forces you into such bad styles.
Now, this isn't a bash against all aspects of OOP languages! Yes, OOP languages do have their strengths, and no, I'm not saying C is better than other languages - just pointing out that C is far from "clunky". I would have to say it's one of the "slickest" languages designed!
edit: dwchandler says it very well :-)
permalinkreportreply
p0nce 1 point 34 minutes ago[-]
D
permalinkreportreply
TiltedPlacitan 1 point 35 minutes ago[-]
You have been a victim of the "language of the month club". Welcome back. We missed you.
In the meantime I've been working almost exclusively in C and C++ - and have developed quite a library of code in this environment.
Yes, we C folks still exist. Yes, there are jobs. Yes, there are interesting projects - particularly in the embedded space. Get yourself back up to speed and join us.
permalinkreportreply
stesch 0 points 53 minutes ago[-]
People thought I was mad when I asked Are there any good and free libraries to develop web applications in C? on Stack Overflow.
This was over a year ago when I got frustrated with all the current languages I'm using and playing with.
permalinkreportreply
smakusdod 1 point 58 minutes ago[-]
Try c#. Don't hate what you don't know.
permalinkreportreply
mysticalfruit 1 point 59 minutes ago[-]
Congratulations and welcome to the club! Now you're really a programmer which means that you're not tied to a particular language. You use the tool that's best for the job at hand.
permalinkreportreply
adraffy 1 point 1 hour ago[-]
you could do this as an "1-liner" in mathematica, including both parallelization and a fancy gui for parameters.
sure, c will always exist; the c-style langs are great for taking a concrete solution/process and turning it into a stable application.
but when i write software, it's to find answers to questions in a reasonable time frame. low-level implementation is not my concern until i hit a wall. and even then, it's often cheaper and faster to throw more machines or ram at the problem than deal with optimization.
permalinkreportreply
tomazk 1 point 1 hour ago[-]
Modern compiler implementation in C - and I want to write a compiler in C for a small programming language
by Andrew W. Appel i presume?
What are your expectations on this? Because I must warn you that implementing a compiler that is being used in this book (or later versions of it) will not get you very far unless you can spare about 10-15 hours of pure programming a week - and it takes about 12 weeks to finish.
At the end you will end up with a pretty much useless compiler and a language that can solve only basic problems.
The later version of the book got me trough a rather buggy and non optimised compiler - implemented in Java - that can compile programs for a ARM platform. Designing such a compiler got me some basic understanding of how compilers should be built and i started appreciating the work of gcc creators :)
permalinkreportreply
buddhabrot [S] 1 point 1 hour ago[-]
Yes, the Appel book.
I'm going to use an external lexer and parser, I don't see the point in writing my own. I will try everything from AST myself and skip some steps to the target language (I don't think I'll target machine code but would like to build a very small domain language on top of C). Frankly I don't know what I will end up with.. writing my own little language just seems like somehting I have to do.
permalinkparentreportreply
paradgim 2 points 1 hour ago[-]
I have had a similar path to you - starting in the same way (with Turbo C in 1988), but with industrial use of C later on as I left university, but the path is the same, and I have ended up with Erlang. With the latest release, you have NIFs, which are native implemented functions - you can write all the computationally expensive code in C, but still have the ease of use, flexibility and productivity gains you have with Erlang. The NIFs behave exactly as erlang functions, but execute with the full speed of C. In short I can build applications many times faster than anything else, but have the computational capacity of C where needed. It has really been an awakening.
permalinkreportreply
bitwize 1 point 1 hour ago[-]
You are maturing as a developer.
In your youth you probably thought -- much as I did -- that C++ must be better than C; look at all these new features it has! It's inherent even in the name!
As time wears on and angle-brackets from template declarations grate against your soul, you will learn, again as I did, that given two ways to do something -- the C way and the C++ way -- the C way is almost invariably simpler and cleaner.
Welcome back. May your pointers never dangle.
permalinkreportreply
SteveJorgensen 1 point 1 hour ago[-]
I don't think you're going mad at all. Each language has its appropriate and inappropriate places for use, and perhaps this is one perfectly (or at least very well) suited to C.
I am also a Ruby fan with some programs I'd like to write for high performance and concurrency. I've been considering trying out IO Language http://iolanguage.com/ to see if I can have the best of both worlds (or at least much of the good of both).
Has anyone here tried using IO?
permalinkreportreply
collegefreshman 1 point 1 hour ago[-]
Blasphemy. C is the creation of the Devil.
Then again, I am the guy who has been sheltered his whole life with stuff like Java and MATLAB.
Maybe I will appreciate C, some 5-6 years down the road, but currently, I can't fathom using it for my own stuff.
--a new guy to programming
permalinkreportreply
alaskanpimp 1 point 1 hour ago[-]
Great little read! Perhaps you should get a job doing embedded stuff. C is certainly not dead in that regard.
permalinkreportreply
ModernRonin 1 point 1 hour ago[-]
Has anyone else had this feeling, this evolution?
Some of us just never left C. I've programmed extensively in Java, Perl, and my current paycheck comes from ActionScript. I still like C better, and always have.
Am I going mad?
(Cheshire Cat) We're all mad here. (/CC) ;]
Do you think C will last,
Its death will be slow. Higher-level languages will replace it for specific tasks (web developement is the obvious example), but C will often be found lurking under the covers, in places where performance or memory consumption actually matters.
and there are intersting jobs left for pure C developers?
Embedded System is generally very interesting, and will require you to be good at circuits as well as code.
permalinkreportreply
Riesling 1 point 1 hour ago* [-]
Nice that you found your joy in programming low level languages again, but I according to your requirements I have the perfect language for you: Scala
Later in uni, I started learning functional languages, we used Haskell in one class. I got intrigued with Haskell and started solving Euler problems, up to this day I still have not written anything useful in Haskell but I love using it.
Functional Programming supported [checked]
Then, I learned Erlang because everyone was talking about it, and it showed me how to unleash parallellization, in whole new ways. I still think Erlang is the most amazing language I have ever seen.
supporting the Erlang "actors concept" [checked]
I wanted to compute it on a friend's octocore, and write a fast parallellized program.
having an Java equal performance [checked]
Edit: Forgot to mention that the poster is really cool!
permalinkreportreply
negascout 2 points 1 hour ago[-]
You didn't hate programming GUI in C++... you hated programming against MFC. C++ is fantastic with the right library choices.
permalinkreportreply
fmoliveira 1 point 2 hours ago[-]
My greatest disappointment with C was incredible boring stuff that wasn't even supposed to be written in C. In one I ended working more with .INI files than with the code. In the other, I was doing a website using C and some inhouse outdated, slow, clunky, terrible framework. Them I ended doing something interesting for a while, now I'm doing boring shit again.
permalinkreportreply
foobaar 1 point 2 hours ago[-]
C is as close to assembly as you can get. As long as there is new hardware coming out, C is irreplaceable. Porting existing software, writing new device drivers or just fine tuning is all done in C.
permalinkreportreply
matjam 14 points 2 hours ago[-]
Other programming languages make you a better C programmer.
permalinkreportreply
tpk1024 1 point 55 minutes ago[-]
This comment made my day :)
permalinkparentreportreply
foobaar 0 points 2 hours ago[-]
Ha ha nice.
permalinkparentreportreply
Araucaria 1 point 2 hours ago[-]
You can make your C programming totally awesome by using m4 macros instead of cpp.
M4 is everywhere (it's used in autoconf). If you use a Makefile to convert your file.c.m4 into file.c, your debugger will find the actual text being run, instead of some weird preprocessor line.
permalinkreportreply
balau 3 points 2 hours ago[-]
Don't worry: C will last, because of embedded platforms and Linux kernel.
permalinkreportreply
Jey_Lux 3 points 2 hours ago[-]
tl;dr: I thought C was stupid, I tried everything else trying to replace it over the years, and came back full circle. I now love it, because i finally have enough practical knowledge to appreciate it for what it really is.
permalinkreportreply
tybris1 2 points 2 hours ago* [-]
People forget the best engineering solution is always in the middle. More than any other language, C fits in between the human mind and the metal. You can try to make it more extreme, but you're only going further from the ideal. Of course, a language that is tailored to a specific type of problem works better for that, but for the general case C is just fine.
permalinkreportreply
Wendel 1 point 2 hours ago[-]
I find COBOL exciting.
permalinkreportreply
madman1969 3 points 2 hours ago[-]
Exciting like a heart-attack ?
permalinkparentreportreply
royrwood 8 points 2 hours ago[-]
Write it in something like Python first, get it working
Profile it, identify the processing bottlenecks, code those bits in C
Profit....
permalinkreportreply
bluGill 0 points 49 minutes ago[-]
There is a lot of optimization you should do in python before dropping down to C. The easy way isn't always fast. Spend your time researching algorithms for the slow parts before you drop back into C. Dropping into C from python can give you at most a 60x speedup. Sticking to python, but using a better algorithm can give you 100,000x speedup. Once it is working in python you can go to C and get a 1,000,000x speedup over the original. (Not 6,000,000 as you might guess: optimized algorithms tend to use much faster python code paths)
permalinkparentreportreply
brave_sir_robert 12 points 2 hours ago[-]
2b. realize you're losing 80% of time waiting for a socket or the disk anyway...
permalinkparentreportreply
TiltedPlacitan 1 point 23 minutes ago[-]
So export the processing of sockets/disk writes to separate threads or processes.
permalinkparentreportreply
twotime 2 points 43 minutes ago[-]
2b. realize you're losing 80% of time waiting for a socket or the disk anyway
I am not so sure about waiting for disks ;-(.
I'm yet to see a non-trivial python program which would be local IO-dominated...
All the IO-intensive python code which I ever looked at was CPU bound ;-(.
permalinkparentreportreply
QuantumFTL 2 points 2 hours ago[-]
You might find some modern assemblers to be more useful, if you want better control over what's in your code. Indeed, assembler macros are so good that you can write code that's easily much higher level than C, without sacrificing much (perhaps a little time figuring out how to use it).
permalinkreportreply
Lyjontko 0 points 2 hours ago[-]
Dude C/C++ is THE shit.
Also, pointers.
permalinkreportreply
ghostvillain 8 points 2 hours ago[-]
I think you were impressed by C because you had a clear and relatively self-contained objective in mind, and could picture the whole development process in your head. In situations such as this one, most of the features of the higher level programming languages become cruft, and you are happy to give up abstractions for raw speed and control.
My suggestion is: go ahead, write some more code in C.
After a while, as your code grows more and more complicated, the lack of abstractions will kill your enthusiasm. You will remember what's so great about the high level languages you mentioned, and you will find an excuse to switch to a project where speed is not essential, so that you can finally ditch C for good :)
permalinkreportreply
Biber 2 points 2 hours ago[-]
and you will find an excuse to switch to a project where speed is not essential, so that you can finally ditch C for good :)
Bill Gates is that you?
permalinkparentreportreply
buddhabrot [S] 3 points 2 hours ago[-]
I hope you're wrong :)
permalinkparentreportreply
ghostvillain 2 points 2 hours ago[-]
Why?
We're slowly getting to the point where any language can be as fast as C, or at least will allow you to pay (performance-wise) only for the features you actually use.
permalinkparentreportreply
buddhabrot [S] 2 points 1 hour ago[-]
That's the opposite of the truth? I could write this algorithm as literally as possible in Python and it would still be hundreds of times slower.
I'm just wondering if all those language constructs that essentially just remove boilerplate actually amount to anything, in the end. Aren't all the really good things written in C? Aren't Python and Ruby written in C?
permalinkparentreportreply
andyou 3 points 2 hours ago[-]
Have you tried D? Having played around with raytracers, fractal 2d and 3d generators and all kinds of brute force procedural graphics in c, c++ python etc.. D is awesome, just a shame there arent as many libraries yet.
ps. Post the image.
permalinkreportreply
buddhabrot [S] 3 points 2 hours ago[-]
Haven't tried D, not sure if I want to learn it.
Lower res/depth output with coloring is here: http://dl.dropbox.com/u/3545003/buddhabrot.png FUll version is still rendering, will take 24 hours.
permalinkparentreportreply
losewinspin 5 points 2 hours ago[-]
Well, we all know that it is extremely unlikely that you can travel faster than C. :-)
You might want to look into Ocaml and Go though. Save yourself a few pointers.
permalinkreportreply
TomSwirly 4 points 2 hours ago[-]
First, I hope you're talking about C++ and not just pure C. It's 2010, there's literally no reason at all not to use C++ if you're wanting to use C.
Most C programs are also legal C++ programs, all C programs can trivially be changed into C++ programs, the efficiency of the generated code will be exactly the same; but the advantages of using the STL cannot be overestimated, if only std::string and std::vector.
That said, there are thousands of C++ jobs out there. I just "retired" after five years at Google where I spent nearly all my time writing C++ (and boy, are my arms tired!) Google alone employs probably thousands of C++ programmers; I'm sure Microsoft does also; anyone who writes games, device drivers, real time programs of any type, all of them need C++ programmers.
Now, my favorite language these days in Python (though this week I'm writing music programs in Javascript, long story...) because it takes me literally less than a third the time to write the same program, because my program quality is better and because I can manage complexity a lot better that way.
But Python is slow - it uses a lot more of your CPU. Nearly all the time, I simply don't care - my CPU is sitting there doing nothing anyway, it's likely that my program is spending most of its time waiting for the disk or the network anyway, and can I really tell the difference between 1ms and 10ms anyway?
But sometimes I really do care. And when I do care about speed, or memory, or I have some other serious hardware or system limitation, then C/C++ is the only possible choice.
I like Java - and for many applications, it's "almost" as fast as C++ - it's good for server-side manipulation. Hotspot is amazing, and will often generate code that's faster than a C compiler could ever do, because it can optimize for the specific processor that the code is running on, rather than a generic Pentium-class processor. But it's big, and in practice, you can simply get better overall performance, and definitely a much smaller memory footprint, from a C++ program.
permalinkreportreply
drewc 13 points 2 hours ago[-]
It's 2010, there's literally no reason at all not to use C++ if you're wanting to use C.
... And there's no need to read the rest of your comment when you start with such an idiotic statement.
permalinkparentreportreply
wnoise 8 points 2 hours ago* [-]
The problem with using just the simplest features of C++ is that they act as a gateway drug to using the features that should work, but just end up fucking your program.
permalinkparentreportreply
jonask84 3 points 2 hours ago[-]
Ah, it warms my heart to read this. It is so true though, you have to part with a bit of your programer's soul when you move up from C.
Sure the C#s and pythons of the world are convenient and comfortable, but any programmer worth his salt should know and love C for it's close relation to asm and machine code.
Good for you man, wb!
btw, that octocore, is that a hyperthreaded quadcore (boo!) or a genuine 8 core monster?
permalinkreportreply
buddhabrot [S] 4 points 2 hours ago* [-]
It's the real thing :) http://www.apple.com/macpro/
permalinkparentreportreply
whosyerparrot 0 points 36 minutes ago[-]
oh god, the mac pro has got to be one of the most overpriced computers...
permalinkparentreportreply
fired comment score below threshold[+] (0 children)
z0ltanz0ltan 4 points 2 hours ago[-]
This is the first time I am going to thank anyone in reddit for truly re-inspiring me (and I have an inkling it may also be the last). Just reading through your text section made me realize why I got into the IT industry in the first place. Somehow over the last few years I had got jaded and became more of a code monkey than someone who loved the very concept of 'programming', the wondrous magical possibilities inherent in it and truly something that one has to love to master. I will be quitting the industry per se soon, but I will always harbor a love for, and will definitely indulge in it throughout my life - just without the ennui, drudgery and plain moronicity of the trade. Thanks, friend, and good luck with your love of the art. Hope it lasts a lifetime!
permalinkreportreply
awj 10 points 3 hours ago* [-]
C is great. Most of the scripting monkeys you hear proclaiming its demise fail to realize that their entire world is built on C. Sure it can be ugly as sin, manual memory management is a pain in the ass, and (IMO) threading is even harder, but it gets the job done where nothing else seems to.
That said, I'm going to strongly suggest learning how to write bindings in $favorite_scripting_language. There's a lot of glue work out there that these languages excel at. Ruby, Python and (from what I hear) Erlang are relatively simple to write bindings for, which lets you try to grab some of the best of both worlds.
Your Erlang solution, for instance, could have used Erlang to distribute the workload and some C to do the actual work. I wouldn't be too surprised if Erlang could rival and/or beat your pthreads code at distributing the work, and either way it obviously would be easier to adapt to some kind of multi-machine fractal farm.
permalinkreportreply
logicalmind 1 point 26 seconds ago[-]
COBOL is great. Most of the scripting monkeys you hear proclaiming its demise fail to realize that their entire world is built on COBOL. Sure it can be ugly as sin, manual memory management is a pain in the ass, and (IMO) threading is even harder, but it gets the job done where nothing else seems to.
permalinkparentreportreply
tgbyhn 5 points 3 hours ago[-]
Haskell is one of the best languages for creating compilers, IMO. C has a lot of advantages in many domains, but compiler writing isn't one of them.
The trick with Haskell programming is ignoring all the people that are doing incomprehensible things with the type system.
permalinkreportreply
ungulate 2 points 1 hour ago[-]
The trick with Haskell programming is ignoring all the people that are doing incomprehensible things with the type system.
This is true for C++ as well, and increasingly so for Java. Some programmers are just hell-bent on creating their own new languages by torturing type systems.
permalinkparentreportreply
tgbyhn 1 point 18 minutes ago[-]
Agreed. Here's a representative example: http://www.reddit.com/r/cpp/comments/au1sq/the_safe_bool_idiom_learn_how_to_validate_objects/
After reading the article, see my comment in the reddit discussion.
permalinkparentreportreply
mpr312 1 point 1 hour ago[-]
Hugs is implemented in C for performance reasons.
permalinkparentreportreply
buddhabrot [S] 2 points 1 hour ago[-]
Hugs isn't a compiler, and I can't remember it being faster than ghci.
permalinkparentreportreply
self 2 points 1 hour ago[-]
Are you sure it's not for bootstrapping issues? If Hugs was written in Haskell, how would you get it up and running on your platform? A lot of compilers/runtimes (POC, GHC, Gwydion Dylan, etc) run into this problem.
Has anyone tried rewriting Hugs in Haskell, to be compiled with GHC?
permalinkparentreportreply
buddhabrot [S] 2 points 3 hours ago[-]
Heh, that last bit is probably great advice! #haskell is probably the best irc channel out there but it is terribly confusing.
I understand that C might be a bad choice for a compiler, I just dug up all old C books I had and compiler writing in C was one of them.
permalinkparentreportreply
stillalone 1 point 3 hours ago[-]
I know that feeling, but I feel it is more of a curse. I'm always concerned about efficiency. When I code in Python or any other high level language I worry about what libraries to use and what functions to call. But in C, it's always better to code it yourself, because you have specific needs. So I end up wasting so much time trying to save a few kilobytes off my executable and an unnoticeable performance gain.
permalinkreportreply
ahminus 5 points 3 hours ago* [-]
Your post was very interesting for me. For about 2 years now, my mantra has been "C is all you need" (which, is, of course, a bit tongue-in-cheek). It was born of a journey which parallels yours pretty closely. I suspect I'm about 10 years older than you, though.
I started in Object Pascal on one short project as a research programmer in college, and went on to do several projects in C++ with MacApp, after which I spent several years with CodeWarrior (on Mac and Linux), and programming NeXTSTEP (Objective C).
I then spent about 5 years in Java-land (working on a well known IDE from a Big Successful Java Enterprise company) and dabbled in Python and Ruby (and, I'm loathe to admit, even some PHP).
For the last 5 years or so, I've worked pretty much exclusively with C (and some occasional) C++, mainly working on networking and simulation code for MMOG backends.
I really don't think I'll give up C before my career as a programmer ends.
Truly good C programmers know that other languages only buy you something if you're not already a good programmer. There are many many open source libraries and applications written entirely in C which are much more "object oriented" and embody all the precepts that OOLs are supposed to grant you than the majority of applications written in said OOLs.
When I first started programming in dynamic languages and other languages with runtimes, I found certain features to be hugely advantageous (reflection, ease of dealing with heterogenous containers, etc.), but my love for languages with a runtime waned over the years as I more and more felt like I was just poking at a box with a stick sometimes, trying to figure out why code wasn't working as it should, or more often, was performing horribly.
At least with C, I can look at disassembled code in the debugger, and the profilers are much more helpful than with any other language I've used (including in Java-land, where there are good profilers).
Also, all the most used software in the world is still written in C/C++: every popular operating system, all the popular web servers, every popular web browser, almost every office suite, and almost every video game on PCs and consoles (including all those handhelds), and a whole lot of mobile software.
permalinkreportreply
chmod700 1 point 7 minutes ago[-]
Well said.
permalinkparentreportreply
hiker 3 points 1 hour ago[-]
The more you know, the less you need.
permalinkparentreportreply
TiltedPlacitan 1 point 16 minutes ago[-]
Enthusiastic upvote from another minimalist.
permalinkparentreportreply
antareus 2 points 3 hours ago[-]
The reasons you state are why I stick with C++ for hobby projects. I like being able to produce tiny, standalone executables that have zero dependencies. I also like the ability to construct decent abstractions once I've figured out which ones are necessary.
permalinkreportreply
goggles2 8 points 3 hours ago[-]
Yes, going back to C from the popular scripting languages, the first thing you notice is how freaking fast it is. I mean, it's just "knock-your-socks-off" "jaw-hanging-open" "holy-crap-that-was-fast" fast compared to Perl/Python/Ruby.
permalinkreportreply
brave_sir_robert -1 points 2 hours ago[-]
... until you write one I/O call ...
permalinkparentreportreply
twotime 1 point 27 minutes ago[-]
Not in my experience. Not with local IO.
Any IO-bound non-trivial C program suddenly becomes CPU-bound once you rewrite it in python.
I'd be curious to hear if you had different experience.
permalinkparentreportreply
bibster -4 points 1 hour ago[-]
downvoted you because it's brave sir robin, not robert.
permalinkparentreportreply
acow 10 points 3 hours ago[-]
I can sympathize with this experience, and I find it an interesting commentary on C. When I do go back to C, I am initially very impressed by how straightforward it is to write programs that run very quickly, but that impression often wanes as the application grows and I find myself thinking, "If only C had this one little extra feature, then it would be a serious contender for even more programming tasks!"
And yet, when you look at all the would-be successors to the throne, the sum of the "little features" becomes a flood that hides the landscape you loved. For example, I sometimes feel that I should use C++ rather than C more often. When I start in such an effort, I do indeed take advantage of the greater support for abstraction and encapsulation, but the amount of boiler plate syntax becomes a turn-off. Then, when I find a surprising performance pitfall through some use of an iterator or template or other C++ feature, I can't help but think that I've lost C somewhere in there. I think that it's just harder to shoot yourself in the foot with C because it's so much harder to use it to build a gun.
As for C being replaced, it's not clear that it needs replacing, but my usual answer to this is that its usefulness will be diminished the farther hardware moves from C's implicit model of the computer. Such differences (e.g. memory hierarchies not necessarily apparent at the C level) have, as far as I can tell, yet to have a large effect on C's applicability, but who knows how things will go?
permalinkreportreply
TiltedPlacitan 1 point 25 minutes ago[-]
I think that it's just harder to shoot yourself in the foot with C because it's so much harder to use it to build a gun.
This gave me a chuckle. IMO, C is the language that makes it too easy to unintentionally build a bomb that blows up the amateur coder.
permalinkparentreportreply
zem 2 points 1 hour ago[-]
the two 'one extra feature's i want are decent string handling and lexical closures. so far, D, vala and objective c seem to be stepping up to the plate.
permalinkparentreportreply
acow 2 points 1 hour ago[-]
In a way they are, but my point is that D, Vala, and Objective-C do not at all resemble C + my-most-wanted-feature-at-this-moment. C is a line in the sand, and attempts to slightly blur it seem to inevitably end up diverging dramatically.
permalinkparentreportreply
zem 1 point 33 minutes ago[-]
this is also true. and everyone wants a different 'one extra feature'. though i'd bet a decent string handling library with syntactic support would be on everyone's list.
permalinkparentreportreply
antareus 5 points 3 hours ago[-]
Then, when I find a surprising performance pitfall through some use of an iterator or template or other C++ feature, I can't help but think that I've lost C somewhere in there.
Read through your C++'s implementation of iterators and decide whether it is OK. Most of the typical ones are little more than pointers which are checked before being dereferenced. As for template performance characteristics, that is entirely dependent on what type you're using (a value or a reference?) and how you're using it.
permalinkparentreportreply
acow 2 points 3 hours ago[-]
Sorry, I wasn't trying to suggest a fundamental limitation, but rather the danger of hurting performance in order to fit into a well-supported abstraction.
The C approach of allocating a block of memory then poking pointers is very flexible, and it's easier to accidentally fail to, say, pre-allocate a vector when using more full featured collection classes. Of course the standard libraries excel in the general cases, but it's the very specific cases where you know, or think you know, exactly what needs to be done that they can be a hindrance over the straightforward C approach.
Don't get me wrong, I spend most of my time in languages other than C these days, but I still believe that C's transparency with regard to what the machine is doing can certainly be illuminating.
permalinkparentreportreply
antareus 1 point 2 hours ago[-]
The C approach of allocating a block of memory then poking pointers is very flexible, and it's easier to accidentally fail to, say, pre-allocate a vector when using more full featured collection classes.
Absolutely. Failure in the C case is much easier to handle -- generally, if malloc fails. You are SOL if that happens and it may be better to dump core immediately. In C++, new might throw, and the temporaries involved in initial construction of the vector might throw, too. You don't know -- you hope the caller knows. This also imposes the burden of exception-safety on all the callers until the exception is actually handled.
By virtue of being higher-level, STL makes it easy to forget that sometimes a simple, contiguous block of memory offers much better performance due to cache coherency.
permalinkparentreportreply
smcameron 1 point 1 hour ago[-]
By default, on many OSes these days, malloc won't fail, because you'll have virtual address space. Instead, the OS will overcommit, and malloc will happily proceed to hand you a pointer, and then when you try to access that pointer, the OS will scramble to meet its overcommit, fail, and kill your process. Checking malloc's return is a fool's game on such OSes.
permalinkparentreportreply
eallin 6 points 3 hours ago[-]
Most people focus on writing abstractions in high-level languages these days. It's great for a while, because you get things done really quickly... but then you get really tired of having no idea what you're doing. I used to write networking code in C and I learnt a lot about networking/sockets etc. With python + twisted, I can make things "just work", but I haven't a clue about what's going on underneath. Everything is an abstraction... factories, reactors etc. In theory it's great: especially if the libraries are really well-documented.
People like bashing C in order to promote ruby/haskell/python (which are all great languages), but how come there's so few apps written in those languages? In my job I use FreeBSD, Postfix, Apache, BIND etc. and they're all written in C.
permalinkreportreply
self 1 point 52 minutes ago[-]
I used to write networking code in C and I learnt a lot about networking/sockets etc. With python + twisted, I can make things "just work", but I haven't a clue about what's going on underneath.
You could write your networking code on plan 9, and never deal with sockets. You'd still write your code in C, but the platform takes care of the 'magic'.
permalinkparentreportreply
eallin 1 point 41 minutes ago[-]
That seems better than both of the other alternatives. However, it would probably not work on any other platform or production environment? I don't know much about the current state of Plan 9...
permalinkparentreportreply
self 1 point 17 minutes ago* [-]
You can fake it somewhat with plan9port, but it's not ideal. It just ends up being an abstracted layer on top of sockets.
My point was that it's not programming in C that gave you a deeper insight into how sockets/etc work; it's that sockets were the lowest available abstraction on your platform.
permalinkparentreportreply
flogic 2 points 2 hours ago[-]
BSD and Bind of those are OLD. Apache is old enough for C to have been the correct choice for performance reasons. I suspect the same applies to Postfix. Truthfully we're only just getting to the point where the better languages are fast enough and have enough libraries. For instance Ocaml Batteries included only just hit 1.0. Chrome's V8 is still relatively new.
permalinkparentreportreply
eallin 4 points 2 hours ago* [-]
Perhaps you are right, but that's what they said about Haskell, Arc, Ruby etc. "They're new, but with a few years on their back..." I wasted a lot of time waiting for Common Lisp, Python and whatnot to become "the new C". After giving up a few times, I decided to embrace C.
permalinkparentreportreply
dfj225 7 points 3 hours ago[-]
The truth is, C is the lingua franca for high performance computing. It seems like the major requirement for your fractal code (other than generating fractals :-P) is that it runs quickly. Since this is a requirement, I think C is probably the best choice. You could probably use some C++ in there, but I think that most compilers will generate faster code if you use C for the heavy computation portions of the code.
I don't envision C being replaced any time soon for HPC code. Other languages (especially interpreted / JIT langs) will get faster as time goes on, but I'm not sure if they will ever remove all of the overhead from interpretation / compiling on the fly.
permalinkreportreply
syntax 12 points 2 hours ago[-]
The truth is, C is the lingua franca for high performance computing.
Fortran is the linga franc for High Performance Computing.
That is, if your runtime is measured in minutes, your doing high performance computing.
If your runtime is measured in days, your doing High Performance Computing, and talk about MPI and clusters a lot.
(Mostly trying to clear up confusion with HPC jargon - and note that for numerically heavy code modern Fortran is still faster than modern C)
permalinkparentreportreply
dfj225 2 points 2 hours ago[-]
I might agree with your distinction between upper and lowercase high performance computing, but I don't really see the two sets of problems being mutually exclusive. A program that takes days to execute might be composed of many smaller problems that execute in minutes.
But whatever, for my comment the point was to highlight that C is a good choice for code where performance matters, meaning the programmer wants to extract as much performance as possible from a given machine.
and note that for numerically heavy code modern Fortran is still faster than modern C
I think you're going to need to provide some proof for that. I don't buy that such a statement is common knowledge (at least, I don't think I've heard that claim before). Just for kicks, here's the comparison from the Computer Language Benchmark page: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gcc&lang2=ifc
I realize this isn't proof that C is faster than Fortran, but it is some evidence that programmers were able to write faster C code than the equivalent Fortran code for these problems with these compilers.
permalinkparentreportreply
syntax 3 points 1 hour ago[-]
It's not my distinction - it's a standard term. See top500.org for people who do High Performance Computing.
You're thinking in terms of single computer. Part of the advantage of Fortran is the integration with things link Infiniband, utilisation of vector mathematic operations [0], use of masking vectors and other esoterica. The other part comes from having a more restrictive memory model, which means the Aliasing problem is avoided [1].
The language shoot out is not a good point of comparison - it's only within the domain of heavy numerics where Fortran is faster, therefore all the other parts drag it down.
Further, there is also the practical advantage that Fortran has, in the compilers have had more work on them to produce faster numeric code. These are typically pay-ware, however (e.g. PGI fortran, or NAG fortran compilers), and so will not be in that benchmark.
LAPACK [2] is still the fastest implementations of linear algebra, for example.
I can't publish the benchmarks I have (commercial and in confidence), but I've seen differences of the order of 5-10% that were attributed (by the compiler author) to the compiler.
[0] There's native syntax for it in Fortran, and has been for ... decades. [1] http://en.wikipedia.org/wiki/Aliasing_(computing) [2] http://www.netlib.org/lapack/
permalinkparentreportreply
dfj225 1 point 19 minutes ago[-]
It's not my distinction - it's a standard term. See top500.org for people who do High Performance Computing.
Yes, I should have never used the term HPC, since it does not reference the right domain of problems / computing that I want to discuss here.
You're thinking in terms of single computer.
For this thread, yes, since that seems to be what the OP is interested in. I agree there is a pretty big distinction between writing fast code for a standard "desktop" system and a cluster of systems / supercomputer.
Further, there is also the practical advantage that Fortran has, in the compilers have had more work on them to produce faster numeric code. These are typically pay-ware, however (e.g. PGI fortran, or NAG fortran compilers), and so will not be in that benchmark.
I wonder if this is where all of the difference comes from. Granted, due to properties of the language that you mentioned (whether aliasing is an issue and so forth) it might be easier to write an optimizing compiler for Fortran compared to C.
If we only consider more common compilers, (gcc, intel, ms/visual studio), does your statement still hold? For instance, if I build LAPACK with gcc for my linux system, is there really any advantage over if LAPACK had been written in C?
I don't know too much about the operation of LAPACK, but their description states that it uses the system's BLAS functions for much calculation. On Linux systems, ATLAS is a good choice and I believe they generate C code for their routines.
permalinkparentreportreply
gmh33 11 points 4 hours ago[-]
There is plenty of work for C developers.
I've worked on projects for embedded systems in C, this is probably the largest area of work for C developers. C still dominates this domain, it might not for a whole lot longer, but for now, it does.
A lot a lot a lot of high performance computing stuff is done in C, or uses C. For instance, a cool project called SPIRAL generates high performance C code. Here's a paper by the SPIRAL people describing various techniques for optimizing C for numerical computations: How To Write Fast Numerical Code: A Small Introduction.
So, I guess to answer your question, yes. If you want to work on an embedded system, one of the easiest ways to get going is with C. If you want to be able to optimize computation by taking advantage of registers, optimal cache use, limiting memory allocations, you may want to go with C.
permalinkreportreply
dsquid 2 points 4 hours ago[-]
Good for you: this is a normal part of the maturation process of a programmer/software engineer/whatever. In my experience, you're already ahead of 80% of the coders out there.
You're also, IMHO, going about this in the right way: exploring and learning on your own, expanding your "sphere of understanding" as you go.
I had a similar experience when I went back to x86 Assembler from from MFC/ATL: I know what every line of code does, and it's mine..all MINE! Glorious, though there are definitely two sides to that coin.
Another big step from where you're at comes from stepping back from this all experience and picking out trends and "lessons learned" in the broader sense. For example, think about the frameworks, the problems they solve, how they solve 'em...realize there is no silver bullet, just an endless series of tradeoffs (few of which are demonstrably "Right"). This will give you a new perspective on the religious wars others get into.
Lots of fun down this path you're one...and even more if you decide to hop into the "dark side" of management!
permalinkreportreply
spinkham 6 points 4 hours ago[-]
C will definitely last. Eventually something like Go or D or some other C incremented language will take off for systems programming, but for now C is still the king.
I love Ruby, and it beats the crap out of C for text wrangling. And there's a whole lot of text wrangling to be done out there, but Ruby isn't right for every problem.
permalinkreportreply
Rusky 2 points 4 hours ago[-]
I have the same impression of C. I started with simple games and websites, using high-level scripting languages. I also like Haskell and Erlang, but C is great. It's relationship with assembly is exactly why it's so great. There's a lot of boilerplate if you do higher-level things, but if you're writing low-level stuff (kernels, embedded, etc.) it's beautiful.
permalinkreportreply
dwchandler 75 points 4 hours ago[-]
Welcome back. :) You aren't going mad. Almost every concept embodied by newer languages was well known decades ago and have more to do with how you think about the problem domain and translate it into code. Newer languages have the advantage of allowing a more direct translation of some ideas into code, as well as doing away with boilerplate. This often comes at a price of being forced into a paradigm and/or losing control.
And here's something... I think I've become a better OO programmer after going back to pure C. It's made me rethink what I was gaining from OO, how I could attempt the same gains in C, and what OO I was glad to leave behind. My conclusion: OO solves some problems very well indeed, but the common OO mindset these days is somewhat insane.
So do I use C for everything now? Not at all. But there's a surprisingly large class of problem that I do tackle with C. Use the best language for the job at hand, with C as a viable option.
permalinkreportreply
Chridsdude 1 point 24 minutes ago[-]
am i the only one who uses python?
permalinkparentreportreply
turbov21 8 points 1 hour ago[-]
I don't disagree with you at all, but I must say, it's a little unnerving when the C guys start sounding like LISP guys.
permalinkparentreportreply
dwchandler 6 points 1 hour ago[-]
Ha! No LISP for me so far. Maybe it's the Haskell, or the more functional aspects of Python & Ruby. But really I think it's coming to an understanding of core problems and attempted solution in software development. Managing complexity, decreasing coupling, functional cohesion over temporal, etc. All of this I first learned many years ago and none of the principles have changed. It's all true for C, F# or assembler.
permalinkparentreportreply
prockcore 9 points 1 hour ago[-]
but the common OO mindset these days is somewhat insane.
Indeed. The OO "abstract every fucking thing" mindset drives me crazy.
An OO programmer designing a car would build a giant monstrosity that allowed you to replace the steering wheel with a blender if you wanted. But the desire to make every single component of the car generic and interchangable has led to a car that no one wants to drive.
permalinkparentreportreply
munificent 14 points 1 hour ago[-]
A shitty OO programmer designing a car
FTFY. People can write shit code in any paradigm. Powerful languages that let you do a lot with a little code also let you do a lot of damage with a little code. C only solves that in the sense that giving a madman a spoon instead of a sword makes him a safe person.
permalinkparentreportreply
cfedde 8 points 1 hour ago[-]
It's really hard to do good design of any type. OO is no exception. And programing language choice has nothing to do with it. It is my assertion that software projects succeed or fail despite the programming languages used.
permalinkparentreportreply
tommy255 0 points 1 hour ago[-]
The problem is that OO actively encourages you to act in insane ways.
permalinkparentreportreply
jbs398 1 point 30 minutes ago[-]
It really doesn't. It may lower the barrier to doing certain insane types of things, but you can say the same thing of any simplifying abstraction. Take the entire hierarchy of abstractions that underly that OO language (the C that it's probably written in, the machine code that translates into, the microcode running on the CPU, the CPU itself, the physics on which transistors depend, etc...) and you'll find that there are "insane" things that are made easier because of each and every one of them. There isn't anything inherent about OO that's any worse than that, the real problem is that people don't understand the abstractions that they're using (some people also abuse them because they understand the abstractions too, but that's a different story), and because of this they make bad decisions and don't realize it until they've created a monster.
Abstractions are great, just know why/how they're broken when you use them :-)
permalinkparentreportreply
tommy255 2 points 17 minutes ago[-]
But that's my point. If the vast majority of OO code looks exactly like you and I know it looks, then that's pretty good evidence that there is something wrong with OO itself.
There are lots of other evidences: continuing argument and restlessness about "unresolved" issues in OO such as single- vs. multiple-inheritence, checked- vs. unchecked-exceptions (and the whole quagmire of exceptions at all), how best to handle and implement generics. Not to mention the even bigger divide behind stances like dynamic and static typing, duck-objects, etc.
Add to all that the fact that "proper" encapsulation is almost always a fairy tale, that no one "really" does const-correctness right, etc, etc.
permalinkparentreportreply
lispnik 1 point 50 minutes ago[-]
Please elaborate.
permalinkparentreportreply
tommy255 3 points 39 minutes ago[-]
Conflating functions and the data they operate on is not always a good idea, but in OO, everything is an object. State is often hidden in objects, and side-effects are rampant.
Additionally, every implementation of OO has its serious flaws. The templating system in C++, for example, is a nightmare. Taken alone, these are just "implementation problems" and don't damn the entire approach, of course. But after all these years, we still don't have a complete system for dealing with objects, as if we are feeling blindly, heading toward something we sense as "the OO Light," not sure if with each step we are actually getting closer or heading over the edge of a cliff.
I don't really have a solution. I'm part of the problem.
permalinkparentreportreply
ericmoritz 2 points 22 minutes ago[-]
I've started using mindset that if I don't need to be carrying state around with my functions, there's no reason for me to use objects.
permalinkparentreportreply
tommy255 1 point 16 minutes ago[-]
YAY!
permalinkparentreportreply
dwchandler 13 points 1 hour ago[-]
I don't think that's true. I think it's the communal insanity that began with the pattern book and people not really grokking it, but applying patterns blindly. Somehow that led to a runaway train of burning stupid.
But step outside the bizarro world and OO languages can be very nice. You can find some incredibly well written OO code, and it's just a pleasure.
permalinkparentreportreply
tommy255 2 points 51 minutes ago[-]
I've spent most of the last 15 years writing OO code, in C++, in Java, in Python and Ruby. There is something fundamentally broken about objects and what it inspires people to do when writing code.
I'm not saying that it's impossible to write "good OO code." I'm just saying that I'm not sure the benefits of OO really outweigh its disadvantages, even after all this time.
permalinkparentreportreply
dwchandler 2 points 1 hour ago[-]
I've seen enough of other people's C++ to know that the world if chock full of shitty OO programmers. Otherwise smart people sit around thinking of how they can add more layers until it's far too complex.
You can botch C so bad it'll give you a headache, but most of the people who would do so are using Java or C++ instead.
permalinkparentreportreply
shazb0t 1 point 18 minutes ago[-]
Otherwise smart people sit around thinking of how they can add more layers until it's far too complex.
I have seen this time and time again. Things that should have taken 20 mins to code end up taking months... I pitty tha foo who has to maintain it. Oh yeah, that's me =(.
permalinkparentreportreply
dan_cooper 0 points 1 hour ago[-]
Bunny Rabbits, Satan, Cheese and Milk. I like meat. http://www.youtube.com/watch?v=eIF4xTSr6fA
It's more like giving a two year old either a shotgun or a nuclear bomb, then asking him to go hug his older sister. C is like a koan, only then you die.
permalinkparentreportreply
plainsane 2 points 1 hour ago[-]
i cant say i have become a better oo dev because i revisit c on a regular basis.
i will say its taught me a stronger appreciation for oo provided by c++ and much more so for the oo provided by java and python.
c++ has oo issues, but i can live with them. i find my self always writing pseudo c in a c++ compiler. i just cant shake the crack called "compile time c++ features"...i like operator overload and single inheritance that c++ provides...flawed, but still allows me to express my intent in my c++ code better then my c code (and i have to switch between the 2 on a regular basis).
permalinkparentreportreply
sephiroth2k -3 points 1 hour ago[-]
Java needs to die.
permalinkparentreportreply
plainsane 0 points 35 minutes ago[-]
hahahahah, i fucking hate it. i only work with it when my job depends on it.
my boss only gives me java stuff when its mission critical or nobody else can figure out the issue, the rest of the java work goes to interns. god bless those under paid sum bitches.
permalinkparentreportreply
lake-of-fire 6 points 4 hours ago[-]
Totally agree, with each of your paragraphs there.
permalinkparentreportreply
arnedh 5 points 4 hours ago* [-]
One good thing about C these days: less conversion when you adapt it to OpenCL or CUDA, and run the fractal in the GPU (240 cores) instead. There is a ready example in the ATI Stream SDK (Mandelbrot), and more code to be found elsewhere.
permalinkreportreply
OMouse comment score below threshold[+] (2 children)
pipocaQuemada 5 points 4 hours ago[-]
From what I understand, it's common to do your parallelism + distribution in Erlang, and to use C and the foreign function interface to do the actual "work" of the algorithm.
I think that there's a place for C, but using C in combination with other languages is good. I think that writing an entire program in C is probably premature optimization.
permalinkreportreply
ryeguy 5 points 4 hours ago[-]
This is even easier in Erlang now that NIFs are around. You can basically create plugins/extensions in C and call them directly from Erlang.
permalinkparentreportreply
mpeg4codec 7 points 4 hours ago[-]
C is great, and like you say, the fact that you can practically see the machine code that will come out of it is something I frequently miss in other languages.
Interesting background, I too cut my teeth on rom hacks. Maybe that's what gives us our love of the low level :)
permalinkreportreply
davebrk 3 points 4 hours ago[-]
Why didn't you try writing that in Java (I'm serious).
permalinkreportreply
buddhabrot [S] 9 points 4 hours ago* [-]
I don't know, I never touch Java anymore unless I need to program a cross-platform UI.
Java just got boring for me. I also have a lot of negative feelings on Java because it was used as a web-application language at my company and I can't understand why people would want to use it for that. I have to say I don't understand the "place" Java has in the language spectrum anymore.
permalinkparentreportreply
MarshallBanana 7 points 2 hours ago[-]
Java is an average language for average programmers to write average programs in.
permalinkparentreportreply
lllama 5 points 3 hours ago[-]
Well, for instance you could have used Java to implement this scenario you are describing here.
It has near C speed for most things, a good threading and locking API (since Java 1.6), and for the things that would be hard to do with it (manipulating byte arrays directly for instance) it has good support for letting you use C for that.
On top of that the Java framework has some very good features for performance profiling.
permalinkparentreportreply
gleapsite 15 points 4 hours ago[-]
Of course C will last. Its used quite extensively in embedded electronics. If you wanna have some fun writing C go pick up an arduino dev board, download avr-gcc (or use arduino's built in software) and happy hacking.
permalinkreportreply
spinkham 3 points 4 hours ago[-]
wrt54gl or other openwrt platforms and the beagle board are also a fun places for embedded C programming with a number of special features.
permalinkparentreportreply
rufius 24 points 4 hours ago[-]
C will last till something sufficiently low level and flexible is developed to replace it. At the moment, that seems to be of little concern to people so we probably won't see an evolution from C for a while.
That said, the software development world will continue to grow in higher level languages.
There's interesting jobs in C, but they're hard to come by. I work in operating systems and work mostly in C and C++. A lot of embedded systems groups use C among other languages like Forth or Ada. In my experience, C/C++ jobs tend to pay better than Java/C#/Ruby jobs which is also a plus if you enjoy C and can put up with its quirks :).
permalinkreportreply
HeroOfCanton 4 points 1 hour ago[-]
I have a fantastic job where the only language I work in is C. I couldn't be happier! :D
permalinkparentreportreply
ffualo 4 points 39 minutes ago[-]
Wow! Do you mind if I ask you some questions? I am moving from Python and R to C for speed. I develop tools mostly on my own time to use at work, until I can justify the extra time at work.
Do you develop in an *nix environment? Do you use a unit testing framework? What's your build cycle like? Is your development build cycle different than your release build cycle?
I ask because I am trying to move into the realm of packaged and released C programs. I use autoconf now, with a custom simple Makefile for development (because waiting for autoconf to update takes too long). I'm curious how professional software development in C happens - there is so little written about this on the internet.
Thanks!
permalinkparentreportreply
HeroOfCanton 1 point 9 minutes ago[-]
I write firmware. Right now, I am mostly working with ARM7 processors, but I've also worked with Cypress USB chips and Xilinx FPGAs.
I use 32bit Windows XP, and I use Keil tools for ARM development.
Generally all my work is a component of the overall development of a physical electronic device, the software (firmware) doesn't really get released by itself. So the dev build cycle is pretty relaxed, private releases at certain milestones (usually feature-centric) building to a public "release" when the product launches, and a certain period of maintenance afterwards.
I did *nix-based packaged C programs in college, and used emacs(and eclipse), gcc and a Makefile. Keil tools uses an ARM proprietary compiler and has a wizard-type windows to configure the build options for compiling/linking etc.
permalinkparentreportreply
fluffy_543 1 point 2 hours ago* [-]
In my experience, C/C++ jobs tend to pay better than Java/C#/Ruby jobs which is also a plus if you enjoy C and can put up with its quirks :).
I'm currently looking for a job and I noticed that low level C/C++ job-postings frequently require previous professional experience in higher-level languages like C#/Java/Python and so on. Low-level work can mean a higher career level.
permalinkparentreportreply
[deleted] 4 hours ago[-]
[deleted]
permalinkparent
Catfish_Man 1 point 2 hours ago[-]
CoreFoundation.framework on OSX is mostly written in C (among many others).
permalinkparentreportreply
cheese_wizard 2 points 2 hours ago* [-]
I work on factory equipment (Machine Vision Inspection systems to be precise). We use plenty of C. This is not embedded nor kernel related. Just lots of routines that talk to hardware from the GUI, which is written in a goofy subset of C and C++. Basically POF, but using C++ streams, STL, and such to make life easier. But we're all used to it, and we're successful.
permalinkparentreportreply
pspda5id 2 points 3 hours ago[-]
Lies, I use C and C++ at work for Windows applications work. And Objective-C for iPhone games.
permalinkparentreportreply
darth10 1 point 1 hour ago[-]
MFC or MSVC++ ... NOT PLAIN C
permalinkparentreportreply
FlyingBishop 1 point 1 hour ago[-]
iPhone is embedded.
permalinkparentreportreply
ferna182 3 points 2 hours ago[-]
we use C++ for iphone.we just write the platform specific parts on Objective C (touchscreen, sound, etc) but the whole application is written in C++. in fact, we do 95% of the development + debugging on a Windows PC and we use Xcode on a mac and iphones when testing performance, input methods, interrupts, connectivity, etc. and, since we obviously already written a common library that handles all the platform specific stuff, there's almost no need for us to write ANYTHING in Objective C. we just use the macs to compile our projects.
permalinkparentreportreply
ahminus 2 points 3 hours ago[-]
And pretty much every video game PC and console video game. Which is like, probably 50% of all the code written in the world.
permalinkparentreportreply
kefeer 10 points 3 hours ago[-]
C++ is not C.
permalinkparentreportreply
ahminus 6 points 3 hours ago[-]
Eh, lots of "C++" code bases are really C+-.
I use classes (when I actually use them) as glorified structs.
I rarely use templates, no operator overloading, and my class hierarchies are rarely more than 2 layers deep. I'm also not writing against an application framework, typically.
Any knowledgeable C programmer has absolutely no problem grokking this type of C++. And all the C++ programmers I know have no problem reading C codebases (like the kernel and device drivers, etc).
permalinkparentreportreply
princeofpeas 1 point 1 hour ago[-]
what he means is don't sully the good name of C by roughly equating its power with your C+-
permalinkparentreportreply
ahminus 2 points 47 minutes ago[-]
Yes, I know C is not quite as powerful as "C+-". I didn't mean to imply otherwise.
permalinkparentreportreply
princeofpeas 1 point 43 minutes ago[-]
you're aware that the final product is machine code right?
permalinkparentreportreply
ahminus 2 points 41 minutes ago[-]
I'm sorry, but how is that relevant?
permalinkparentreportreply
radarsat1 5 points 3 hours ago[-]
Also most audio processing code, like soft synths etc. Anything that requires real-time interaction pretty much.
permalinkparentreportreply
capt0bvious 15 points 3 hours ago[-]
Tell that to the C programmers working on the electronic healthcare claims processing apps where I work.
permalinkparentreportreply
super__mario 1 point 1 hour ago[-]
This sounds like a perfect opportunity to use something slightly higher level like Java. C is just too low level for something like claims processing. Yikes.
permalinkparentreportreply
flogic 9 points 3 hours ago[-]
I find that rather horrifying.
permalinkparentreportreply
goggles2 -2 points 3 hours ago[-]
Didn't know there were any paying kernel development jobs out there. There are probably jobs for writing device drivers though.
permalinkparentreportreply
yoda17 1 point 2 hours ago[-]
I don't know what the current statistics are, but I read that something like 97% of all embedded systems (a market that dwarfs the PC arena) run with roll your own OS as opposed to a COTS OS like VxWorks or PSOS.
Yes, this means true OS functionality like you would find in a book on operating systems like tasking, memory management, I/O etc with very little GUI work, I think anymore all GUI work is done through IP and a web browser peeking into memory locations and doing data processing elsewhere (that most people think of when you say operating system).
permalinkparentreportreply
buddhabrot [S] 4 points 3 hours ago[-]
You'd be amazed: http://apcmag.com/linux-now-75-corporate.htm
permalinkparentreportreply
iamjack 14 points 3 hours ago[-]
Are you kidding me? 75% of Linux is written by paid developers (there was a reddit post before). I'm one of them and I have a lot of kernel coworkers. And that's just Linux. Working for Apple or Microsoft or Sun (Oracle?) gives you a shot at their kernels too.
I'm not sure why you don't count device driver writing either, that's definitely kernel level C. Regardless though, algorithms are always improving, always changing. Schedulers become more efficient, memory managers more detailed. There's still a lot of work to do in OS design and maybe even more in making our current OS systems suck less.
permalinkparentreportreply
dozerl 1 point 1 hour ago[-]
How did you get into Linux kernel development with a company? That's what I want to get into. Do you have any pointers for someone wanting to get in to that field?
permalinkparentreportreply
goggles2 0 points 2 hours ago[-]
I'm not sure why you don't count device driver writing either,
Oh, you mean: why don't I count writing drivers as part of kernel development. Are drives part of a kernel which dynamically loads drivers? I guess I figured there was enough distinction there to consider them separate.
permalinkparentreportreply
inotocracy 4 points 4 hours ago[-]
Its all about the right tool for the job. If generating a fractal in C is quicker, then by all means write it in C. That doesn't necessarily mean you need to write tons of boiler plate for every application you create, or use C for everything. Also-- would you mind posting the source code for your multithreaded fractal generator? :) Would be great to see your implementation in each language you attempted.
permalinkreportreply
buddhabrot [S] 5 points 4 hours ago[-]
This is my (very amateuristic C code, it doesn't use the mutex lock hierarchies because I haven't got the bugs out of that yet. The haskell code is at home I'll post it in a separate post. Erlang is loose scraps, I programmed mandelbrot in it parallelly and quickly figured it was too slow.
http://pastie.org/795264
permalinkparentreportreply
rjett 1 point 18 minutes ago[-]
I learned something by checking out your code. I used to write a lot of PHP and I was a very big fan of GD. I didn't know that it was accessible in C. It makes sense though. Next time I get some free time I'm going to start tinkering with GD in C! Thanks man!
permalinkparentreportreply
select 1 point 34 minutes ago[-]
Could you make us a wallpaper too? :-) I like this colorscheme: http://upload.wikimedia.org/wikipedia/commons/f/f1/Buddhabrot-deep.png
permalinkparentreportreply
inotocracy 1 point 4 hours ago[-]
Looks good to me! Thanks. Even though its all loose scraps, I'd still be curious to see what the implementation may look like in other languages. I love reading other people's code, its very fascinating :)
permalinkparentreportreply
buddhabrot [S] 1 point 4 hours ago[-]
This is the haskell btw, it's slow because it's not so well programmmed. I was also in the middle of refactoring it to Map so it might look odd. http://pastie.org/795329
permalinkparentreportreply
xixor 18 points 4 hours ago* [-]
Personally, I wouldn't be too quick to cast away C++: remember, it wasn't C++ you didn't like, it was the MFC, don't blame C++, MFC was horrid.
C++ is compatible with the C99 standard so you can write C in C++ and still have access to parts of C++ that really save a lot of time without having to remember that much (i.e. classes std::vector, std::list, std::map). Seriously, who wants to roll their own linked list or hash table anymore when there are much more interesting things to work on? You don't have to go whole-hog into OOP design patterns and such, you can still program in the functional style of C, but take the parts of C++ that can really save you. C++ code is darn fast too.
permalinkreportreply
krum 17 points 4 hours ago[-]
C++ is not compatible with C99.
permalinkparentreportreply
tgbyhn 3 points 3 hours ago[-]
C++0x is just a few macros away (or even less) from C99 compatibility for the vast majority of programs.
permalinkparentreportreply
krum 6 points 3 hours ago[-]
Don't you mean C++1x? 8D
permalinkparentreportreply
fwork 2 points 1 hour ago[-]
No one ever said the numeral indicated by the x was in decimal.
/me points at his January 200A calendar
permalinkparentreportreply
bluGill 2 points 48 minutes ago[-]
I think you mean January 7DA calendar.
permalinkparentreportreply
wheeman 2 points 1 hour ago[-]
Where'd you get that January 8202 calender?
permalinkparentreportreply
fwork 4 points 1 hour ago[-]
Lying in a trash bin in January 8203, duh.
permalinkparentreportreply
nemtrif 12 points 4 hours ago[-]
C++ is compatible with the C99 standard
You probably mean the C89 standard
permalinkparentreportreply
buddhabrot [S] 4 points 4 hours ago[-]
Yes I didn't want to go to deep in the C/C++ debate but I'm also planning on learning C++ again. Although I have to say I got influenced by functional languages to think less in object hierarchies, I think a lot of areas of a compiler could be written more elegantly in C++.
For instance the hierarchy in AST's feels "simulated" when it's written in plain C.
permalinkparentreportreply
goggles2 4 points 3 hours ago[-]
I think C++ is alright if you can stick like superglue to a restricted subset of the language.
Maybe the world could use a "Strict C++ subset" renaissance instead of C++0x (or C++xx, as the case may be). Didn't someone once say,
"Imprisoned in every large programming language a smaller one is wildly signaling to be let out."
? (Apologies to Cyril Connolly.)
permalinkparentreportreply
yoda17 2 points 2 hours ago[-]
Can you say MISRA?
permalinkparentreportreply
Tommah 1 point 3 hours ago[-]
I think a lot of areas of a compiler could be written more elegantly in C++
If you really mean a compiler and not an interpreter, my advice to you would be to write it in a higher-level language with garbage collection. (Maybe read this: http://flint.cs.yale.edu/cs421/case-for-ml.html ) A compiler just takes in program code and produces machine code, so there's no need for it to be super-super-fast. Save C for when you really need it. I've used C to write some AIs for simple board games, and there it pays off, because you end up calling functions millions or billions of times.
permalinkparentreportreply
zid 4 points 1 hour ago[-]
Having a slow compiler is like being addicted to drugs.
Every thought you have is overshadowed by how it might need you to recompile. It hangs over you like a cloud. It's a persistent nagging in the background, that you had better do this, or do that, for fear of having to do an extra recompile.
A fast compiler isn't just a neat tool, it's a liberator.
permalinkparentreportreply
bluGill 1 point 45 minutes ago[-]
I agreed. Though it is more than just the compiler. By watching the process monitor I was able to determine that 75% of my build time is taken by the build system, and only 25% by the compiler. (Now if I just understood how the build worked well enough to replace it - not to mention the build system only knows how to feed 1 core)
permalinkparentreportreply
ithika 2 points 1 hour ago* [-]
With most heavy codebases it isn't the compiler that's the problem. Crufty, recalcitrant make systems which require you to blow everything away and rebuild from scratch, or slow linkers, or endless file munging with perl scripts, or systems built from several code bases that never quite work together: these are what slow me down more than the compiler itself.
Edit: Obviously this is my experience, but I think it doesn't take very long before an environment has built itself up so that production of .o's is not the aspect that needs optimised. YMMV.
permalinkparentreportreply
zid 1 point 49 minutes ago[-]
Obviously you've never used C++.
permalinkparentreportreply
TiltedPlacitan 1 point 29 minutes ago[-]
In my experience, build times under compilers that don't have pre-compiled headers support are dominated by the compilation of headers. Stripping #includes, and particularly #includes within header files themselves speed things up a great deal.
permalinkparentreportreply
ithika 1 point 42 minutes ago[-]
This is true in the sense you mean it. I have used C++ for a company but I ... uh ... I didn't get to compile it. Yeah, you read that right. They would email me a small subset of source files that had a problem and got me to "fix" them. These files couldn't be compiled on their own.
I recently heard they were looking into something called "source control" but I don't know how that went...
permalinkparentreportreply
zid 1 point 39 minutes ago[-]
How was that even possible? >_<
One of the key reasons I don't like C++ is that it's impossible to find definitions, or know what an operator is doing, etc etc etc just from a snippet of code. (This is also exactly the reason why it compiles so slowly).
permalinkparentreportreply
ahminus 4 points 1 hour ago[-]
A compiler just takes in program code and produces machine code, so >there's no need for it to be super-super-fast.
/me stares blankly.
permalinkparentreportreply
Tommah 1 point 1 hour ago[-]
Did you have a point?
permalinkparentreportreply
ahminus 1 point 44 minutes ago[-]
Time compiling Firefox or the linux kernel on your machine. Or maybe any number of Java codebases. Particularly crappy bloated Java codebases with crappy dependencies.
permalinkparentreportreply
addmoreice 3 points 1 hour ago[-]
"so there's no need for it to be super-super-fast"
try compiling a multi-million line code base and tell me how you feel on that.
permalinkparentreportreply
Tommah 1 point 1 hour ago[-]
This guy isn't trying to replace gcc; he just wants to write a simple compiler.
permalinkparentreportreply
addmoreice 1 point 25 minutes ago[-]
"A compiler just takes in program code and produces machine code, so there's no need for it to be super-super-fast"
this seems to not be a statement referring to the specific situation (which i agree with you on, hence why MY compiler is not terribly quick...for now, i hope) it seems to be a general statement about compilers. ie, they do not need to be super fast.
I was simply pointing out that without a zippy compiler some issues make development styles nearly unacceptable. an example: When my compiler can no longer compile my OS image/programs quickly enough for me to do iterative build cycles/JIT loading I will need to upgrade the performance of my compiler.
as for 'build it in a higher level language' yes, oh god yes! do this. you will save yourself many many many hours of pain. I can't do this for my JIT (and since my os is written in the same language well...i might as well build just two areas of failure instead of three >.< hehe).
permalinkparentreportreply
Tommah 1 point 25 seconds ago[-]
It obviously depends on my definition of "super-super-fast" ;)
permalinkparentreportreply
dr-steve 2 points 2 hours ago[-]
Heretical thought: nonpersistent programs don't need to care about memory leaks.
Compiler starts, it compiles, it uses memory, it finished the module, all of the memory is recycled by the OS. In fact, it may be argued that a "use it and lose it" compiler is more efficient than a "manage the FSL" compiler for almost everything it compiles.
Only persistent systems need to worry about resource recycling as they are the only systems for which monotonically increasing resource utilization can have adverse system-wide impact.
permalinkparentreportreply
Tommah 2 points 1 hour ago[-]
That's a good point. But see addmoreice's comment above :)
permalinkparentreportreply
ablakok 4 points 3 hours ago[-]
I don't necessarily want to promote this, but C++ supports a lot of functional programming constructs, especially if you use the boost C++ libraries. The syntax is cumbersome (lots of templates), but you can arguably write better C++ code after experience with functional languages, and you can write faster functional code using C++. Except I don't think there are any first-class continuations.
permalinkparentreportreply
jimbokun 3 points 1 hour ago[-]
Why are you hesitant to promote functional programming constructs in C++?
permalinkparentreportreply
load more comments (2 replies)
load more comments (1 reply)
load more comments (6 replies)
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment