Why does everyone here seem to dislike C++?
So I'm a 3rd year electrical engineering student at university and so far we've been taught how to code in ones and zeros, assembly, C and C++. Out of all of these I like C++ the best. I wouldn't say I'm great with it, but I can use it to get what I need done. But every time I come onto this subreddit everybody always makes fun of C++.
Apart from school I'm kinda interested about getting into game programming as well as windows applications. Can anyone explain what's wrong with C++ and suggest a language to learn next?
45 comments
Because what I can clearly express in one line of swift/haskell/etc is often like 15 lines of nasty in C/C++. And when I make a mistake, the former has around a 90% chance of telling me about it immediately whereas the later is maybe 30%. When you're dealing with a couple person decades of code, that really really matters.
It's kind of like building a house using a rock instead of a hammer. It works. But after a few years building houses with a rock....when you try out a nailgun for the first time......yea not going back to that insanity. Of course sometimes a rock is your only choice...embedded, and a few other domains, but I'm never writing another line of C++ unless it's genuinely the only language that can solve the problem. To be fair, if you stick with EE, then yea it may be your only choice most of the time.
Also, as a counterpoint to the C++ makes more $$ comments. I doubled my salary(and got way more job offers) going from embedded C to iOS dev. Most of that's attributable to moving out of an economic backwater, but C/C++ is not necessarily a magic ticket to more cash. Being the company expert in C++ might be, but then so is being the company expert in <whatever>. I'd be lucky to see any increase at all moving back to C.
It's kind of like building a house using a rock instead of a hammer. It works. But after a few years building houses with a rock....when you try out a nailgun for the first time......yea not going back to that insanity. Of course sometimes a rock is your only choice...embedded, and a few other domains, but I'm never writing another line of C++ unless it's genuinely the only language that can solve the problem. To be fair, if you stick with EE, then yea it may be your only choice most of the time.
Also, as a counterpoint to the C++ makes more $$ comments. I doubled my salary(and got way more job offers) going from embedded C to iOS dev. Most of that's attributable to moving out of an economic backwater, but C/C++ is not necessarily a magic ticket to more cash. Being the company expert in C++ might be, but then so is being the company expert in <whatever>. I'd be lucky to see any increase at all moving back to C.
There is only one thing "wrong" with C++ and that is undefined behavior. An accident of history, but one that will make you cry at times. For the rest the tooling around it is quite depressing as well. But none of this prevents you from getting great work done, they are annoyances.
i.e. you can have a solid career with C++ so the languages to learn are suggestions for horizon expansion not career advice.
Now it looks like you want to stay close to the hardware so there are a few options that can be interesting to look at. Game programming is not nearly as much fun as game playing so be careful what you want.
Rust: the new kid on the block, learning this will help you look different at C/C++ and even if you don't continue using it professionally you will pick up nice things.
A scripting language with a REPL. Lua, JS, a lisp, python, perl, ruby, it doesn't matter. Just have a look at one and see what tools to make tools you can build with them.
The following I would suggest having a look at but not more than 1 weekend each ;) They are very far from windows apps and game stuff.
Ada/spark: the old kid on the block, a could have been interesting. Again not something that is widely used so learn for curiosity not for career.
JavaCard: the slow kid on the block. Not talking about plain java here, but specifically the JavaCard environment which is a whole different playing field. You will pick up standard Java as well, by doing this. Massive different perspective, but no games ;(
Outside of languages I would spent time picking up Vulkan the new graphics API and OpenCL or Cuda. These will help with getting into the game market but also help you look at visualization and data presentation. Valuable skills no matter where you go afterwards.
Remember in the end people don't pay for code. They pay for solutions to their problems. If you can solve problems you will always have a job.
Now it looks like you want to stay close to the hardware so there are a few options that can be interesting to look at. Game programming is not nearly as much fun as game playing so be careful what you want.
Rust: the new kid on the block, learning this will help you look different at C/C++ and even if you don't continue using it professionally you will pick up nice things.
A scripting language with a REPL. Lua, JS, a lisp, python, perl, ruby, it doesn't matter. Just have a look at one and see what tools to make tools you can build with them.
The following I would suggest having a look at but not more than 1 weekend each ;) They are very far from windows apps and game stuff.
Ada/spark: the old kid on the block, a could have been interesting. Again not something that is widely used so learn for curiosity not for career.
JavaCard: the slow kid on the block. Not talking about plain java here, but specifically the JavaCard environment which is a whole different playing field. You will pick up standard Java as well, by doing this. Massive different perspective, but no games ;(
Outside of languages I would spent time picking up Vulkan the new graphics API and OpenCL or Cuda. These will help with getting into the game market but also help you look at visualization and data presentation. Valuable skills no matter where you go afterwards.
Remember in the end people don't pay for code. They pay for solutions to their problems. If you can solve problems you will always have a job.
Ada was held back by super-expensive compilers. This was the natural result of Ada being required by military contracts. You paid, or you didn't get the job done.
Free compilers are available now, along with free RTOSes that support an Ada runtime. The language seems to be growing in popularity again, partly because of the free compilers and partly because of a renewed interest in security.
Free compilers are available now, along with free RTOSes that support an Ada runtime. The language seems to be growing in popularity again, partly because of the free compilers and partly because of a renewed interest in security.
When you learn/taught any new programming language you learn about the primitives of the language and how to combine them to create programs. You will create simple programs to test the understanding of the language and get used to the features of the language in terms of how to solve a problem.
On the other hand, the world of professional software development is very very messy, instead of creating program you end up creating these enormous complex software systems. Most importantly its not like that you get requirements, you implement them and you are done, instead you will keep getting new requirements over time which in most cases are conflicting with the existing requirements and the system needs to keep evolving to handle this mess forever. Handling this evolution over time is the most important feature of any language/tools/platform and it seems those people who don't like C++ have been through the frustration of handling that evolution of software in C++.
Because it adds complexity, but doesn't deliver the gains in productivity or encapsulations that you hope for.
C++ is a big language, and most people agree that "some parts" of it are useful, but they just can't agree on which parts are the good ones. You have to decide that for yourself.
This is worth reading for a good suggestion of how to use C++ features sparingly:
"Orthodox C++" https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b
Everyone has their own opinions, from dogmatically never use anything c++ to only stopping short of using boost. I will vary by project, using STL sometimes and not others, sometimes using classes lightly, other times sticking to POD, etc. I think you have the right idea when you say "Use it to get what you need done".
C++ is a big language, and most people agree that "some parts" of it are useful, but they just can't agree on which parts are the good ones. You have to decide that for yourself.
This is worth reading for a good suggestion of how to use C++ features sparingly:
"Orthodox C++" https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b
Everyone has their own opinions, from dogmatically never use anything c++ to only stopping short of using boost. I will vary by project, using STL sometimes and not others, sometimes using classes lightly, other times sticking to POD, etc. I think you have the right idea when you say "Use it to get what you need done".
While C++ has plenty of interesting and nice features to play with it lacks something important Java has, reflection.
C++ would be pretty close to "perfect" language if it would add reflective capabilities on top of all the other nice features.
Yes. I know some libraries add "reflection" but its not good enough. It needs to be baked in language and not require additional syntax on classes to be used as data for your own reflective code.
Yes. I know some libraries add "reflection" but its not good enough. It needs to be baked in language and not require additional syntax on classes to be used as data for your own reflective code.
Generic reflection for C++ would require disabling optimizations that affect object memory layout somehow. It would also mean you need to have all the symbols present.
It would also require additional overhead for RTTI information per object, if you want it to work using arbitrary void *.
It'd br great to have reflection of course. At least so some subset, non-generic but with zero (or low) overhead.
Just being able to iterate known type struct or class fields could be something.
It would also require additional overhead for RTTI information per object, if you want it to work using arbitrary void *.
It'd br great to have reflection of course. At least so some subset, non-generic but with zero (or low) overhead.
Just being able to iterate known type struct or class fields could be something.
It varies per person. The history of imperative programming branches off from ALGOL into several directions. One was to C and then C++. Here's my point-by-point trace of how those were "designed." You'll see that C is more an accident of history designed to work on ancient hardware then lots of uptake since UNIX was written in it. C++ was actually designed carefully on top of C with features from many languages but inherits C issues and kludginess of that approach.
http://pastebin.com/UAQaWuWG
Now, there were a few other paths from ALGOL. One was Wirth's tradition of languages that were simple, type-safe, memory-safe as possible, compiled lightening fast, consistent, and still performed well. Started with Pascal with Turbo Pascal and Delphi being big commercial successes. Drawback with him was he leaned too far to simplicity as some features might justify extra complexity. Yet, the Oberon's, Modula-3, and Component Pascal derived from this style could do much of what C++ developers could with more safety, consistency, and development speed. Examples below:
https://en.wikipedia.org/wiki/Modula-3_%28programming_langua...
http://blackboxframework.org/index.php?cID=why-program-in-co...
http://www.freepascal.org/
Another branch was Ada family. It was designed to prevent as many faults as possible in embedded programming mainly. They systematically eliminate them with syntax, semantics, and defaults. SPARK variant extends that to automatically prove absence of common errors in code via formal verification that runs behind the scenes. The systems were never popular for various reasons but empirical studies by military showed vastly lower defects than C or C++ with productivity and maintenance advantages.
http://www.adacore.com/uploads/technical-papers/SafeSecureAd...
http://libre.adacore.com/
So, ignoring functional programming and such, it's hard for me to like C++ coming from a Pascal background where the syntax was readable even to lay people a bit (a la BASIC), operations were safe by default, compiles up to 100kloc/sec on Pentium3, no segfaults, less hacks, GC by default, unsafe for speed if I need it, and small set of features all developers understand and use. C++ was nothing like that although they've improved it a lot over time.
So, given I know better stuff is possible and even out there right now, I have to still think C++ is crap because it combines pieces inconsistently to approximate stuff like I use plus builds on an unsafe foundation with undefined behavior.
http://pastebin.com/UAQaWuWG
Now, there were a few other paths from ALGOL. One was Wirth's tradition of languages that were simple, type-safe, memory-safe as possible, compiled lightening fast, consistent, and still performed well. Started with Pascal with Turbo Pascal and Delphi being big commercial successes. Drawback with him was he leaned too far to simplicity as some features might justify extra complexity. Yet, the Oberon's, Modula-3, and Component Pascal derived from this style could do much of what C++ developers could with more safety, consistency, and development speed. Examples below:
https://en.wikipedia.org/wiki/Modula-3_%28programming_langua...
http://blackboxframework.org/index.php?cID=why-program-in-co...
http://www.freepascal.org/
Another branch was Ada family. It was designed to prevent as many faults as possible in embedded programming mainly. They systematically eliminate them with syntax, semantics, and defaults. SPARK variant extends that to automatically prove absence of common errors in code via formal verification that runs behind the scenes. The systems were never popular for various reasons but empirical studies by military showed vastly lower defects than C or C++ with productivity and maintenance advantages.
http://www.adacore.com/uploads/technical-papers/SafeSecureAd...
http://libre.adacore.com/
So, ignoring functional programming and such, it's hard for me to like C++ coming from a Pascal background where the syntax was readable even to lay people a bit (a la BASIC), operations were safe by default, compiles up to 100kloc/sec on Pentium3, no segfaults, less hacks, GC by default, unsafe for speed if I need it, and small set of features all developers understand and use. C++ was nothing like that although they've improved it a lot over time.
So, given I know better stuff is possible and even out there right now, I have to still think C++ is crap because it combines pieces inconsistently to approximate stuff like I use plus builds on an unsafe foundation with undefined behavior.
Try learning Python, Java, Erlang/Lisp/OCaml/Haskell, Prolog, and then look
back at C++. You'll see what's the reason.
This type of comment is really unproductive. Not only does it not answer the question, it dismisses it with an air of superiority. I happen to know Python, Java, Lisp, OCaml, Haskell, and Prolog, and wouldn't use anything other than C++ for my day job.
Expressing yourself in languages like Python is much easier
than C++. You'll be able to concentrate more on solving
the problem at hand than dealing with the language.
I highly recommend these two short books:
https://www.amazon.com/Treading-Python-Beginning-Programming...
http://www.amazon.com/Treading-Python-2-Intermediate/dp/1490...
I highly recommend these two short books:
https://www.amazon.com/Treading-Python-Beginning-Programming...
http://www.amazon.com/Treading-Python-2-Intermediate/dp/1490...
You'll spend more time debugging errors that could have been caught at compile time by strict static types.
The minimum here should be C with the warnings enabled. Things like Ada and Rust may improve upon this.
Also, I think performance issues can count as "dealing with the language". Python is roughly 100x slower, making it like all your computers are a dozen years older. It's like having a 2004 computer in 2016.
The minimum here should be C with the warnings enabled. Things like Ada and Rust may improve upon this.
Also, I think performance issues can count as "dealing with the language". Python is roughly 100x slower, making it like all your computers are a dozen years older. It's like having a 2004 computer in 2016.
I'd wager that python's ease of expression is enough to beat C/C++'s strict static types as far as reducing bugs. I'm all about strict static types, but C++'s incarnation of them is surprisingly un-helpful. Several other languages(swift, haskell, etc) actually deliver on at least most of the promise of static typing, with nearly the ease of use of python, and nearly the runtime performance of C. Maybe the newest flavors of C++ are better, but the C++ I coded in 7ish years ago was a morass of boilerplate and foot shooting.
Compared to plain C, C++ tends to become unmaintainable. Everybody knows a tiny subset of the huge language, yet must somehow work together on a team. People do not stick to a common subset of the language that everybody is comfortable with, especially considering team members that will be hired in the future.
In theory, C++ can be as fast as C. (officially lacking the "restrict" keyword, but otherwise fine) In practice, C++ is much much slower. The theory is no help. C++ code runs slow. People layer on the abstractions.
Suggested next language:
Well, although Rust and Ada look nice, I'll tell you what I use at work. I use C99 and lots of assembly. I do assembly for x86 (16-bit, 32-bit, 64-bit), PowerPC, ARM (original, thumb, thumb2, aarch64), ColdFire, MIPS, and many stranger things. Oh, don't forget the build system tools: bash, sed, GNU make, awk
In theory, C++ can be as fast as C. (officially lacking the "restrict" keyword, but otherwise fine) In practice, C++ is much much slower. The theory is no help. C++ code runs slow. People layer on the abstractions.
Suggested next language:
Well, although Rust and Ada look nice, I'll tell you what I use at work. I use C99 and lots of assembly. I do assembly for x86 (16-bit, 32-bit, 64-bit), PowerPC, ARM (original, thumb, thumb2, aarch64), ColdFire, MIPS, and many stranger things. Oh, don't forget the build system tools: bash, sed, GNU make, awk
> Compared to plain C, C++ tends to become unmaintainable...
Yeah, true. Used to think otherwise, but experience shows over and over again this happens in most large teams. C++ somewhat encourages too many abstractions and complicated control flow (exceptions, [multiple] inheritance, templates, ninja operator overloads). Building and linkage (especially against third party blobs) is also a big issue even in 2016. Builds are slow and binary incompatible between compiler versions and vendors.
> In theory, C++ can be as fast as C.
Actually, it can go both ways, C++ can be faster as well. For example when C++ enables inlining - std::sort beats idiomatic C qsort quite handily. Depends how you use it more than anything else.
Yeah, true. Used to think otherwise, but experience shows over and over again this happens in most large teams. C++ somewhat encourages too many abstractions and complicated control flow (exceptions, [multiple] inheritance, templates, ninja operator overloads). Building and linkage (especially against third party blobs) is also a big issue even in 2016. Builds are slow and binary incompatible between compiler versions and vendors.
> In theory, C++ can be as fast as C.
Actually, it can go both ways, C++ can be faster as well. For example when C++ enables inlining - std::sort beats idiomatic C qsort quite handily. Depends how you use it more than anything else.
Whether code is maintainable or not depends on the developers, not the language. I have worked on million+ line C++ projects that were very maintainable. And also on much smaller Ruby projects that were a total cluster f* and impossible to maintain. Don't blame the tools. A good developer can write excellent clean maintainable code in ANY language.
For an EE, C++ is a pretty good language, in that it lets you get very close to the hardware. Most of the people who criticize it don't work in that world.
As a computer engineering student (the programming counterpart to electrical engineering), I still prefer C over C++.
I dislike C++ because it's just so unbelievably complicated and hard to learn. There's a special place in hell for the abominations C++ calls error messages. Clang helps, but not enough unfortunately.
I dislike C++ because it's just so unbelievably complicated and hard to learn. There's a special place in hell for the abominations C++ calls error messages. Clang helps, but not enough unfortunately.
Im suprised that nobody has mentioned golang, which is generaly described as the successor to "c".
Golang is great, and I'd love to move my code over to it from C and C++. But one of my projects involves creating a Windows DLL, and I don't think Golang provides a way to for me to compile to that just yet. I don't think Go has a strong GUI story yet either (and even if it did, it will take a while for the tooling to match XCode or Delphi or Xojo).
Languages have different strengths, part of programming is deciding which languages & toolset are most productive for the project you're working on.
Languages have different strengths, part of programming is deciding which languages & toolset are most productive for the project you're working on.
> Most of the people who criticize it don't work in that world.
Huh. I've always kinda thought it is other way around. People who tend not to criticize C++ are not suffering it on a daily basis in dysfunctional organizations. :-)
Huh. I've always kinda thought it is other way around. People who tend not to criticize C++ are not suffering it on a daily basis in dysfunctional organizations. :-)
Yes, stupid rules can make C++ a pain. But they can do so to any language, not just C++. Don't blame the language for the organizational dysfunction. (For that matter, have you run into corporate Java?)
I think its just personal taste and preference. It also depends alot on the kind of projects interests you to work on.
Go with what you like.
Go with what you like.
Apart from school, let me give you an advice.
If you have a brain that can handle multiple levels of OO in c++ across multiple threads; keeping multupltformness in mind and crunching out optimized code with all that you learned in your data structure classes, stick with C++.
The pay is way better (like three times more here in Toronto) than anything web or app related, the working hours are more sane, and stuff are usually way more planned in advance.
You'll have way better life sticking to the shops that need your engineering coding skills.
Think carefully and be ready to wait out few months for your first job when you graduate. Charging jobs after is hard. App/web/testing shops will take a decent low level engineer any day of the week. A financial/embedded/engineering company will think long and hard before they hire a web dev for a backend/driver team dev.
In this proffesion you are beign paid to think. Why not approach your career choices similarly?
'everybody making fun of c++' is a non issue. You may as well worry about what wasn't cool in kindergarten. C++ was and is an industry standard.
On a unrelated note: this post will reflect the HN community by their impulsive up/down voting it ;)
If you have a brain that can handle multiple levels of OO in c++ across multiple threads; keeping multupltformness in mind and crunching out optimized code with all that you learned in your data structure classes, stick with C++.
The pay is way better (like three times more here in Toronto) than anything web or app related, the working hours are more sane, and stuff are usually way more planned in advance.
You'll have way better life sticking to the shops that need your engineering coding skills.
Think carefully and be ready to wait out few months for your first job when you graduate. Charging jobs after is hard. App/web/testing shops will take a decent low level engineer any day of the week. A financial/embedded/engineering company will think long and hard before they hire a web dev for a backend/driver team dev.
In this proffesion you are beign paid to think. Why not approach your career choices similarly?
'everybody making fun of c++' is a non issue. You may as well worry about what wasn't cool in kindergarten. C++ was and is an industry standard.
On a unrelated note: this post will reflect the HN community by their impulsive up/down voting it ;)
> The pay is way better (like three times more here in Toronto) than anything web or app related
Web developer with 5+ years experience can expect 75K+ in Toronto (according glassdoor / reddit / google search). And both python jobs and such salaries are available. I doubt C++ developer can make 225K in Toronto. Even if some one does like you, it's an exception.
I wish I was pulling that kind of money here. From my anecdotal experience, I had friends that started at 35k/y as frontend devs, and 65k / year at IBM for c++ , both fresh out of univ. I agree that 75k with few years under the belt seems reasonable.
But, we should move to where the 225k jobs are it seems :)
But, we should move to where the 225k jobs are it seems :)
There are hardly any (well paid) remote positions in C++ though? So it's the kind of path where your career might dictate where you live.
This advice is pretty spot on.. I know from really sharp C/C++ guys here in silicon valley and they are all making at least 280k a year. That's generally around double of your average backend web-dev.
People get very hung up on the complexity of the language and all the bad code one could potentially write. I use a C++ compiler to compile my preferred subset of the language, and for me that's within epsilon of the best of all possible worlds. If I was on a team that forced me to use every language and library feature, I'd probably be unhappy.
Interesting workflow. Whats your preferred subset ?
[deleted]
[deleted]
[deleted]
C++ is very hard. IMO, that's why people dislike it.
I was writing a test output parser in Python: ~50 lines of functional code in less than an hour. Testing the script for about 10-20 mins and tweaking it to my liking.
The same in C++ would've required me to look up/read up a bunch of library functions that I've forgotten (Should I use file I/O, string manipulation C functions or C++ functions?), link to a few libs (non-C++11) or read some obscure documentation on C++11's regex implementation. Compile, test, change, repeat. This is way more time spent as compared to the Python option.
This is not a fair judgment of the language, but my point is that for something simple there are other languages. For something complicated, C++ has been used in many applications (successfully and unsuccessfully). But there is no doubt that once a C++ code base becomes large it is extremely hard to maintain.
I was writing a test output parser in Python: ~50 lines of functional code in less than an hour. Testing the script for about 10-20 mins and tweaking it to my liking.
The same in C++ would've required me to look up/read up a bunch of library functions that I've forgotten (Should I use file I/O, string manipulation C functions or C++ functions?), link to a few libs (non-C++11) or read some obscure documentation on C++11's regex implementation. Compile, test, change, repeat. This is way more time spent as compared to the Python option.
This is not a fair judgment of the language, but my point is that for something simple there are other languages. For something complicated, C++ has been used in many applications (successfully and unsuccessfully). But there is no doubt that once a C++ code base becomes large it is extremely hard to maintain.
From a gaming industry perspective, Jonathan Blow gave a great presentation about his problems with C++:
https://www.youtube.com/watch?v=TH9VCN6UkyQ
https://www.youtube.com/watch?v=TH9VCN6UkyQ
C++ has lots of issues, most of them due to backward compatibility and versatility. Also, the language is very complex and enormously hard to master. I've used C++ for quite a while and everybody I know who used the language for at least a few years have developed a love&hate relationship for this language, or abandoned it.
To answer the titular question: I hate C++ because I worked in it for 10 years, and I came to realize things could be otherwise.
I almost came back to the language with C++11, but its core problem remains the same: the only maintainable codebases seem to be those strictly ruled over by language experts with an iron fist -- and too many people think they're experts (hint: if you haven't read the language standards (or written them!) and hacked on a compiler or two, you probably aren't an expert).
You inevitably have to choose an opinionated subset of C++, which often results in a language which is more on par with many modern languages, but with more pitfalls and traps, and which you have to teach to every person you bring on board.
And let's not even start on compile times and other problems C++'s legacy brings with it.
FWIW, I still do a lot of C and assembly. Modern C is pretty nice, although it will be nice to see a newer systems language finally take over.
You will probably end up doing C++ professionally, and that's fine, but for your own sake and the sake of your coworkers, learn some other languages that will broaden your mind.
You can find many suggestions in this thread, and I could go on about the more mind-broadening ones (logic programming, dependent types, metaprogramming, etc), but the most valuable might be another systems language, even if it's not popular, just so you can see how things could be otherwise. I think reasonable candidates might include Ada, Modula-3, Rust, D (which is a little too close to C++), BLISS if you can track down a compiler, Forth; maybe even Common Lisp.
I almost came back to the language with C++11, but its core problem remains the same: the only maintainable codebases seem to be those strictly ruled over by language experts with an iron fist -- and too many people think they're experts (hint: if you haven't read the language standards (or written them!) and hacked on a compiler or two, you probably aren't an expert).
You inevitably have to choose an opinionated subset of C++, which often results in a language which is more on par with many modern languages, but with more pitfalls and traps, and which you have to teach to every person you bring on board.
And let's not even start on compile times and other problems C++'s legacy brings with it.
FWIW, I still do a lot of C and assembly. Modern C is pretty nice, although it will be nice to see a newer systems language finally take over.
You will probably end up doing C++ professionally, and that's fine, but for your own sake and the sake of your coworkers, learn some other languages that will broaden your mind.
You can find many suggestions in this thread, and I could go on about the more mind-broadening ones (logic programming, dependent types, metaprogramming, etc), but the most valuable might be another systems language, even if it's not popular, just so you can see how things could be otherwise. I think reasonable candidates might include Ada, Modula-3, Rust, D (which is a little too close to C++), BLISS if you can track down a compiler, Forth; maybe even Common Lisp.
I thought BLISS was just a macro language. Why do you count it as a systems language?
https://en.wikipedia.org/wiki/BLISS
It included a macro facility, but it was also a full-blown systems programming language.
It included a macro facility, but it was also a full-blown systems programming language.
I'll be darned. Whole time I've seen it in VMS-related material I thought it was just a pre-processor for ASM or something. Turns out it was a sort if C competitor. Thanks for the tip. :)
No problem. I'm trying to remember when I first learned about it. I want to say it was a compilers (?) course in grad school. The professor was lamenting that C had survived and BLISS had disappeared, led me to research it originally. I particularly like that everything (or nearly everything) is an expression, probably due to my affinity for functional programming languages. Beyond that, I'm not sure that I like it's typeless nature for doing systems programming work. I guess it depends on how low-level you're talking about, though.
EDIT: I recall reading more about BLISS back then, but that was a decade ago. This [0], linked in the Wikipedia article, is pretty interesting. I'm about 5 pages in and have to head out so I'll finish it later, but it seems like something you'd be interested in given your general interest in language history (from reading your posts in the past).
[0] http://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bli...
EDIT: I recall reading more about BLISS back then, but that was a decade ago. This [0], linked in the Wikipedia article, is pretty interesting. I'm about 5 pages in and have to head out so I'll finish it later, but it seems like something you'd be interested in given your general interest in language history (from reading your posts in the past).
[0] http://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bli...
Not everyone here dislikes C++. C++ is a good language for some things, and a bad language for others. In particular, C++ is not a good fit for web development and an especially bad fit for the type of web applications that the majority of people on HN work on. If you had asked people who make AAA games or create more performance sensitive applications you would likely see a different opinion of C++.
I for one don't. C and C++ runs the software that runs the world. From operating systems to embedded systems to browsers to whatever you can think of. Even the interpreters/VM's of all other languages (Python/Java/Ruby/...) are written in C/C++. All other languages have about 0.1% of the impact that C and C++ has. People who love other languages hate that. And haters will be haters. I for one am super happy that people choose other languages. Please do that! Less competition for me.
Name me one programming language that people don't make fun of. There aren't any. And why do you care anyway? Pick what works for you.
For me a lot comes down to the tooling.
* How do I start a new project
* How do I build/test/cross compile the project
* How do I add dependencies and optionally vendor them
If someone could 'reboot' c++ so it ships a decent standard library and update the tooling to work something like go or rust I'd be interested.
One of the projects I've been working on in go parses some csv files, stores the data in a sql database and presents a simple http json rest api. Could I write this in c++? yes. Do I know how to do all the bullshit needed to get a c++ project going that includes csv+sql+json+http libraries? no.
* How do I start a new project
* How do I build/test/cross compile the project
* How do I add dependencies and optionally vendor them
If someone could 'reboot' c++ so it ships a decent standard library and update the tooling to work something like go or rust I'd be interested.
One of the projects I've been working on in go parses some csv files, stores the data in a sql database and presents a simple http json rest api. Could I write this in c++? yes. Do I know how to do all the bullshit needed to get a c++ project going that includes csv+sql+json+http libraries? no.