Why C/C++ Is My One True Love(blog.danlarsen.me)
blog.danlarsen.me
Why C/C++ Is My One True Love
http://blog.danlarsen.me/why-cc-is-my-one-true-love
5 comments
It sounds like you should take a look at go, if you haven't already :)
I'm not saying C is elegant. What I like about C, is that (in my *NIX/BSD world) it is THE language, that is always available and works the way I expect - even on old FreeBSD machine, that hasn't been touched for a decade.
It is also the language I can use for embedded computing.
In general: the more C and C++ code I have, the more systems I can create well-functioning, speedy programs for. I don't need to learn a new language's pitfalls, bugs, shortcomings, etc... I can just rely on my knowledge of C and get to know the platform I'm developing for.
That said - I recognise that some languages are more suitable for a given problem than others. I currently code a lot of Node.js (which I am starting to regret - I wish I'd chosen Go), but there is no doubt, I gain a lot in terms of not having to think about net layer (too much) and the community has made a wealth of modules of varied quality (myself included).
I think you could say, C is my favorite cordless drill! :) C is a tool that works very well for many cases - at least the once I come across. There is more specialized tools for many things, but I like simplicity.
I'm not saying C is elegant. What I like about C, is that (in my *NIX/BSD world) it is THE language, that is always available and works the way I expect - even on old FreeBSD machine, that hasn't been touched for a decade.
It is also the language I can use for embedded computing.
In general: the more C and C++ code I have, the more systems I can create well-functioning, speedy programs for. I don't need to learn a new language's pitfalls, bugs, shortcomings, etc... I can just rely on my knowledge of C and get to know the platform I'm developing for.
That said - I recognise that some languages are more suitable for a given problem than others. I currently code a lot of Node.js (which I am starting to regret - I wish I'd chosen Go), but there is no doubt, I gain a lot in terms of not having to think about net layer (too much) and the community has made a wealth of modules of varied quality (myself included).
I think you could say, C is my favorite cordless drill! :) C is a tool that works very well for many cases - at least the once I come across. There is more specialized tools for many things, but I like simplicity.
Actually, I love C and think it is very elegant=P, especially when you read its source code. But my favorite languages are Common Lisp, Ruby and Haskell. Concerning C++, I have to agree with most part of what Steve Yegge said http://bit.ly/1dUsZsv, although I used it on a daily basis... The only reason I am doing it is because the legacy code of the system is written in C++.
I think it's very interesting to note, that there are two (or more) ways to look at languages, when talking about things like elegance.
You can look at it from the perspective of the language's source code, how it handles what is put into the compiler, how it "interprets" what we tell it to do, how it handles machine resources, locking, all of that.
But there is also the perspective of the "daily developer" - how easy is it to organize the code, so it doesn't become one big pile of unreadable code, that no one but the original developer can grasp. How easy or beautiful, if you will, can I express my thoughts AND get a good result?
I am really not one to critisize or have a strong opinion about how well languages work "underneath"... I have spend way to little time reading compilers' source code or developing my own.
What I feel, I can have strong opinions about though, is whether I can create software, that doesn't end up in a cluttered mess, which I can easily maintain, make fast/optimized, find and fix memory leaks in. And of course, there is this final extremely subjective thing: I need to enjoy programming every day and have a feeling, that I am using a tool that helps me, instead if it being a struggle.
With all that in mind, I think I can maintain my love for C++, because I don't use half of it ;) As I have already stated, I use C++ as a "version" of C, where I can let go of handling some of all the pointer stuff, manipulate strings in a way that works better in my brain and can organize my code better, due to classes, etc. I agree, that C++ is an extremely "large" language, but that is something that seems to help some developers.
I think it is good, that we have choices as developers. We can choose a language that matches our way of thinking. I believe we should be a little less religious about our choice of language(s) and realize that some creates their best programs with Go, while others would never succeed in creating a useful peace of software, were they forced to do it in Go.
We are all developers, but we do not all think alike. Why would there be 78.341 languages (<- I made that up ;), if we all thought alike? What we do share though, is a passion for making computers do as we command them to do.
Steve advocates the use of server-side Javascript (I just read that on WikiPedia ;), which is what I have been doing for a couple of years now. I could not disagree more... The more I use Node.js, the more I miss C++ or wish I'd chosen to try Go instead. I am REALLY not saying Node.js sucks or anything, I am just saying, the way scope and asynchronicity is handled, really doesn't fit my brain well.
It is manageable on the client, where you don't have to handle more than 1 session. You only have to think about events, callbacks, scope, etc. for 1 single person. Take that to the server and all hell breaks loose. You take what I have just mentioned, add thousands of connections and the fact that you do not get a fresh state (page refresh on the client), till you stop and start the Node.js server. In all of that, you have to be really careful about security and permissions. (For all fairness, I should mention we use websockets and build our site as a couple of single page apps.)
It is of course solveable. I personally think, we have found a nice way of never retrieving data from data sources without having valid credentials on the user requesting the data. But I have handled easier solutions than this.
Sorry... That became a rant! :)
You can look at it from the perspective of the language's source code, how it handles what is put into the compiler, how it "interprets" what we tell it to do, how it handles machine resources, locking, all of that.
But there is also the perspective of the "daily developer" - how easy is it to organize the code, so it doesn't become one big pile of unreadable code, that no one but the original developer can grasp. How easy or beautiful, if you will, can I express my thoughts AND get a good result?
I am really not one to critisize or have a strong opinion about how well languages work "underneath"... I have spend way to little time reading compilers' source code or developing my own.
What I feel, I can have strong opinions about though, is whether I can create software, that doesn't end up in a cluttered mess, which I can easily maintain, make fast/optimized, find and fix memory leaks in. And of course, there is this final extremely subjective thing: I need to enjoy programming every day and have a feeling, that I am using a tool that helps me, instead if it being a struggle.
With all that in mind, I think I can maintain my love for C++, because I don't use half of it ;) As I have already stated, I use C++ as a "version" of C, where I can let go of handling some of all the pointer stuff, manipulate strings in a way that works better in my brain and can organize my code better, due to classes, etc. I agree, that C++ is an extremely "large" language, but that is something that seems to help some developers.
I think it is good, that we have choices as developers. We can choose a language that matches our way of thinking. I believe we should be a little less religious about our choice of language(s) and realize that some creates their best programs with Go, while others would never succeed in creating a useful peace of software, were they forced to do it in Go.
We are all developers, but we do not all think alike. Why would there be 78.341 languages (<- I made that up ;), if we all thought alike? What we do share though, is a passion for making computers do as we command them to do.
Steve advocates the use of server-side Javascript (I just read that on WikiPedia ;), which is what I have been doing for a couple of years now. I could not disagree more... The more I use Node.js, the more I miss C++ or wish I'd chosen to try Go instead. I am REALLY not saying Node.js sucks or anything, I am just saying, the way scope and asynchronicity is handled, really doesn't fit my brain well.
It is manageable on the client, where you don't have to handle more than 1 session. You only have to think about events, callbacks, scope, etc. for 1 single person. Take that to the server and all hell breaks loose. You take what I have just mentioned, add thousands of connections and the fact that you do not get a fresh state (page refresh on the client), till you stop and start the Node.js server. In all of that, you have to be really careful about security and permissions. (For all fairness, I should mention we use websockets and build our site as a couple of single page apps.)
It is of course solveable. I personally think, we have found a nice way of never retrieving data from data sources without having valid credentials on the user requesting the data. But I have handled easier solutions than this.
Sorry... That became a rant! :)
I also find comfort in C/C++, it's something about that closeness to the metal that does it.
In most other languages (recently I've done a bit of Python) you feel like your walking in someone else's shoes. But with C/C++ it's just you and the machine.
In most other languages (recently I've done a bit of Python) you feel like your walking in someone else's shoes. But with C/C++ it's just you and the machine.
Totally! I read another blog post, not long ago, that describe it pretty well... He said something like: You need to know what every single line of your code does and when to clean up after yourself - in turn, you know what every single of your code does! :)
That makes the code so much more robust and you are less likely to make wrong assumptions about what a function or piece of code does.
I do a lot of JS at the moment - node.js and jQuery - what I hate the most, is all the wrong assumptions I have, when somebody makes a function called "clone" (this particulalry one copies the reference) or when jQuery has chained functions, that does not "inherit scope"...
I wish I had the time and patience to learn assembly - but then again... C or C++ is close enough and probably way faster to get anything done in :)
That makes the code so much more robust and you are less likely to make wrong assumptions about what a function or piece of code does.
I do a lot of JS at the moment - node.js and jQuery - what I hate the most, is all the wrong assumptions I have, when somebody makes a function called "clone" (this particulalry one copies the reference) or when jQuery has chained functions, that does not "inherit scope"...
I wish I had the time and patience to learn assembly - but then again... C or C++ is close enough and probably way faster to get anything done in :)
Re. JS: "Standing on the shoulders of giants" can have its perils, when the giants exhibit a different mind set about scope or so.
Re. assembly, I'm pushing 60 so I've written a lot of assembler in the days, most of it on PDP11 and AppleII. Last time I coded in assembly was 1993, so if you're not writing your own BIOS you're good without it.
Funny, though. The other day I missed something from assembler, and I'm not taking about speed or lowlevel stuff. No it was the ability to switch text segments, in C++ it would be equivalent to be able, in a single .cpp file, to switch from one translation unit to another.
Re. assembly, I'm pushing 60 so I've written a lot of assembler in the days, most of it on PDP11 and AppleII. Last time I coded in assembly was 1993, so if you're not writing your own BIOS you're good without it.
Funny, though. The other day I missed something from assembler, and I'm not taking about speed or lowlevel stuff. No it was the ability to switch text segments, in C++ it would be equivalent to be able, in a single .cpp file, to switch from one translation unit to another.
Re. giants - that was very well put! :)
It seems like the wealth of new languages is creating a new breed of programmers, who think it is possible to know a language, after having developed in it for 1/2 a year or so...
I think that's dangerous as each language has a syntax, that is usually very easy to learn, a set of functionality and maybe some libraries, that takes some time to get used to... But then there is all the pitfalls, the bugs that you need to learn about, the need for a way to organise the code, so it doesn't become a mess...
I tend see this as "getting into the mind of the creators".
Re. assembly, I think the reason I would like to learn it, is to get a better understanding of "the metal" - not so much actually developing in it, unless it has to do with embedded computers.
It's funny how you always seem to miss something from language x, when you are coding in language y :)
So... If you are pushing 60 - what is your thoughts on all the new languages and, in my opinion, the extremely slow progress we are making, when it comes to how we "command" computers to do stuff?
I think you have spend enough time creating DB connection libraries, web servers and other networking code, forking/threading models... It should be time to make use of existing code in way that makes it extremely fast to create very well-functioning programs.
Basically: shouldn't it be possible to (more or less) create a set of test cases and have the system create the actual program, by combining existing blocks of code? Isn't that what we are striving to do all the time, by collecting more and more base code we re-use?
I think that's dangerous as each language has a syntax, that is usually very easy to learn, a set of functionality and maybe some libraries, that takes some time to get used to... But then there is all the pitfalls, the bugs that you need to learn about, the need for a way to organise the code, so it doesn't become a mess...
I tend see this as "getting into the mind of the creators".
Re. assembly, I think the reason I would like to learn it, is to get a better understanding of "the metal" - not so much actually developing in it, unless it has to do with embedded computers.
It's funny how you always seem to miss something from language x, when you are coding in language y :)
So... If you are pushing 60 - what is your thoughts on all the new languages and, in my opinion, the extremely slow progress we are making, when it comes to how we "command" computers to do stuff?
I think you have spend enough time creating DB connection libraries, web servers and other networking code, forking/threading models... It should be time to make use of existing code in way that makes it extremely fast to create very well-functioning programs.
Basically: shouldn't it be possible to (more or less) create a set of test cases and have the system create the actual program, by combining existing blocks of code? Isn't that what we are striving to do all the time, by collecting more and more base code we re-use?
Yeah, agree about learning assembly for the sake of grokking the hardware, bluescreen texts, and it helps when configuring bootloaders like Grub.
If you have a Windows XP installed somewhere, you can learn some assembler just by playing/poking the video memory with the old DEBUG.EXE program, like this:
1) Switch to fullscreen/DOS mode by running CMD.EXE and pressing ALT+RETURN. 2) Start DEBUG.EXE 3) Check you're on the right track by entering df000:0, it should display ... IBM COMPATIBLE... something 4) Fill the video memory, e.g. fb800:0 888 1 2 3 4 5 6
Try to understand what you just did :-) then try to enter some assembly code, start with the command a100
Re. our progress with computers, I think actually things have progressed rather nicely, ok maybe not so much with JS but look at Go for example, they're really trying to fulfill the old dream from the 80's of "sofware ICs". I've just written some small test programs in Go, but it's remarkable that once I've built an .EXE file, I can copy and run it on other Windows computers, no installation or other configuration necessary.
BTW, I'm testing out Qt right now, in that framework there are some great promises of code reuse.
If you have a Windows XP installed somewhere, you can learn some assembler just by playing/poking the video memory with the old DEBUG.EXE program, like this:
1) Switch to fullscreen/DOS mode by running CMD.EXE and pressing ALT+RETURN. 2) Start DEBUG.EXE 3) Check you're on the right track by entering df000:0, it should display ... IBM COMPATIBLE... something 4) Fill the video memory, e.g. fb800:0 888 1 2 3 4 5 6
Try to understand what you just did :-) then try to enter some assembly code, start with the command a100
Re. our progress with computers, I think actually things have progressed rather nicely, ok maybe not so much with JS but look at Go for example, they're really trying to fulfill the old dream from the 80's of "sofware ICs". I've just written some small test programs in Go, but it's remarkable that once I've built an .EXE file, I can copy and run it on other Windows computers, no installation or other configuration necessary.
BTW, I'm testing out Qt right now, in that framework there are some great promises of code reuse.
Nice! I have an XP running in VirtualBox for testing, so I just tried what you wrote - that was fun! :)
I have no idea what I just did, just that it felt good, to make that impact on the screen with that little code, knowing it was done directly ;)
I will have to set some time off to understand it (better)!
Re. progress, I just have this feeling, that we are just doing the same, over and over again - then creating another language to do the same over and over again. In electronics we have components that does 1 thing, usually with different values. In the worst case, we take a standard component and program it.
I would really like to have a process, where I can architect a system and the data flow and finally code a couple of non-standard functions/classes/methods/whatever and be done :)
Good or bad, Apple is trying to do it in Xcode and several IDEs, give you a glimpse of this. Maybe they just create your HTML for you, but that's a step in the right direction. Of course it would be best to be able to re-use your own code, for the "automated" parts, instead of relying on someone else's idea of what HTML and other code should look like. These guys are trying to do it for Node.js: http://noflojs.org I think it looks really promising. It would be great to be able to concentrate on solution specific code, rather than "everything".
Re. Go, it is my one big regret, I chose Node.js over Go, a couple of years ago. I didn't have the time to understand enough of both languages, so the choice was Node.js, due to the fact "it's javascript" and that it seem good, when I did some prototypes.
The reality is, you client-side developer, should probably never touch your server-side code! It is far from the same. Same syntax, same way of creating classes, less scope problems, there is only 1 environment, so you can remove some code. But from there, it's totally different! Which of course should make sense, since it is two completely different purposes.
Currently we are maintaining our code in a way (APIs), that ensures we can change either side without problems. So they future will probably be Go, as that seems like the best fit for multi-platform (BSD/*NIX) web-service development.
I ran into Qt years ago, when I was trying to get away from Java for a desktop app. I actually ended up with Python and Qt :) It was really a much horrible experience, than I would have thought! :) Qt just worked as supposed, with it's limitations (at that time at least), which wasn't to big of a problem. Have you tried on Mac?..... :)
I will have to set some time off to understand it (better)!
Re. progress, I just have this feeling, that we are just doing the same, over and over again - then creating another language to do the same over and over again. In electronics we have components that does 1 thing, usually with different values. In the worst case, we take a standard component and program it.
I would really like to have a process, where I can architect a system and the data flow and finally code a couple of non-standard functions/classes/methods/whatever and be done :)
Good or bad, Apple is trying to do it in Xcode and several IDEs, give you a glimpse of this. Maybe they just create your HTML for you, but that's a step in the right direction. Of course it would be best to be able to re-use your own code, for the "automated" parts, instead of relying on someone else's idea of what HTML and other code should look like. These guys are trying to do it for Node.js: http://noflojs.org I think it looks really promising. It would be great to be able to concentrate on solution specific code, rather than "everything".
Re. Go, it is my one big regret, I chose Node.js over Go, a couple of years ago. I didn't have the time to understand enough of both languages, so the choice was Node.js, due to the fact "it's javascript" and that it seem good, when I did some prototypes.
The reality is, you client-side developer, should probably never touch your server-side code! It is far from the same. Same syntax, same way of creating classes, less scope problems, there is only 1 environment, so you can remove some code. But from there, it's totally different! Which of course should make sense, since it is two completely different purposes.
Currently we are maintaining our code in a way (APIs), that ensures we can change either side without problems. So they future will probably be Go, as that seems like the best fit for multi-platform (BSD/*NIX) web-service development.
I ran into Qt years ago, when I was trying to get away from Java for a desktop app. I actually ended up with Python and Qt :) It was really a much horrible experience, than I would have thought! :) Qt just worked as supposed, with it's limitations (at that time at least), which wasn't to big of a problem. Have you tried on Mac?..... :)
(had some trouble posting on Hackernews earlier)
Re. Qt on Macs: sure, matter of fact I prefer to work with Qt on my MBP, the fonts are prettier etc.
I first tested Qt one year ago, they are really making progress, you should check out the recent release 5.2.
BTW, I've started a blog (mostly) about Qt: http://tripleboot.org
Re. Qt on Macs: sure, matter of fact I prefer to work with Qt on my MBP, the fonts are prettier etc.
I first tested Qt one year ago, they are really making progress, you should check out the recent release 5.2.
BTW, I've started a blog (mostly) about Qt: http://tripleboot.org
I meant to write: "... A much less horrible..." :-P
Nice blog post! That will come in handy, when I get the time try out Qt... And some modern C++ :)
I think you need to try http://www.webtoolkit.eu/wt
Wow! I didn't know about Wt! It looks really interesting!
Thanks for sharing. I can't wait to check it out.
There is no C/C++ language today! You are talking about two very different languages with similar roots.
I know they're different, but they're still close enough to use C code in your C++ projects.
And for my limited knowledge of C++, it still "feels" like an extended C.
I'm not claiming I know a hell of a lot about either - just that I know enough, for both to give me power and possibilities way beyond any other language :)
And for my limited knowledge of C++, it still "feels" like an extended C.
I'm not claiming I know a hell of a lot about either - just that I know enough, for both to give me power and possibilities way beyond any other language :)
Sounds like you are more of a C++ = C with classes type of guy.
Maybe this will interest you:
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...
Maybe this will interest you:
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...
Definitely! And I know I'm missing out on a lot... ;)
I don't get to use C++ enough, so I haven't been digging into the depths of what it's capable of.
I mostly program for embedded computers, when I get anywhere near C or C++, so not to much incentive to go digging... :-/
I still have an old copy of "The C++ Programming Language" on my shelf - unfortunately collecting dust...
Thanks for the link! I really look forward to hearing what his thoughts are on modern programming!
I don't get to use C++ enough, so I haven't been digging into the depths of what it's capable of.
I mostly program for embedded computers, when I get anywhere near C or C++, so not to much incentive to go digging... :-/
I still have an old copy of "The C++ Programming Language" on my shelf - unfortunately collecting dust...
Thanks for the link! I really look forward to hearing what his thoughts are on modern programming!
The core semantics of the two are kept in close correspondence as new versions of the standards come out. There are a few points where C and C++ disagree on things that they have in common, but C programs will almost always compile as C++.
I would definitely like to learn more C++, when time allows, but as things are right now, I guess you can say, I use C++ as the easier C, regardless of how different they are underneath.
Someone joked by saying, it's like using JavaScript as the easier Java... Well... I get the idea, but C can compile with C++ programs, making it much more of a subset of C++, which I can re-use. That makes it a "no cost" tool to fall back on, when C++ is not available/possible.
They are very compatible tools! :)
Someone joked by saying, it's like using JavaScript as the easier Java... Well... I get the idea, but C can compile with C++ programs, making it much more of a subset of C++, which I can re-use. That makes it a "no cost" tool to fall back on, when C++ is not available/possible.
They are very compatible tools! :)
On the one hand, C has a tiny runtime that can be omitted or replaced. On the other, it doesn't have all sorts of things that would be helpful but not require runtime overhead.
My biggest complaint is lack of a module system. #include is a stupid ugly hack. Second would be the way it doesn't let you portably define and work with low-level data representations in a standard way. I don't count manual bit masking and shifting for this.
I would also really prefer a more advanced type system, including parametric polymorphism integrated with the module system, but not via templates.