Webkit only has 10k LOC specific to WebAssembly because like every other browser it reuses the javascript JIT. That's an incredibly tiny part of the entire browser.
But why is it adding their patent grant which only protects facebook to non facebook projects like atom? Should every company add their own company patent grant? Why not simply add a general patent grant that protects all users and companies?
Facebook only cares about facebook in the license. We can't say that facebook is doing it for the benefit of the project itself. The more projects that have the license the more protected facebook is while everyone else is left out.
If we were to believe that it is an altruistic endeavor that will result into a "world without patents" then in fact it would be a world without patents... but only for facebook.
I have nothing against patent grants with the condition of not suing for patent infringement but they shouldn't only apply to one specific company. The apache software license and many others have already solved this problem. There is no need for a facebook only solution.
My issue is with people pretending that facebook is doing everything right when they are doing everything wrong.
If by political correctness you mean the basic human rights of the constitution
Of course we could add an exception to the constitution that excludes lab grown children. Well, unfortunately gene manipulation is eugenics unless you are willing to support your "defects" until they die of old age plus their offspring but then china is probably going to win again because they are disposing their defective subjects as soon as they notice the defect.
It doesn't take much imagination to think of this scenario. Creating artifical super children that grow up inside a lab and get killed off when convenient is the most common staple in scifi books and movies involving gene editing.
What's more important? Basic human rights for all humans or competitiveness?
> If by political correctness you mean the basic human rights of the constitution
I think the US constitution is silent on the subject of genetic research.
> What's more important? Basic human rights for all humans or competitiveness?
If a nation is uncompetitive, it won't matter in the long term what it thinks about human rights, as that nation will will be out-competed by other natinos that are more competitive.
>"Is there anything I could get paid to do that a machine couldn't do?".
Work for free or even pay for the privilege of working. See some short distance truck drivers working 20 hours a day making losses on some weeks after paying for their truck lease and other costs that were externalised from the employer to the employee. You can't exploit a robot but you can exploit a human.
Unfortunately in my experience I don't know what type of x I'm supposed pass into to. I either have to guess what x is out of a infinite search space or I have to look at the implementation but unfortunately it also calls some other functions so I need to determine the possible inputs for that function and repeat this until I've read 100s of lines of code just to use a single function because someone thought that documentation is uneccessary and 10 seconds of less typing were worth the tradeoff. Static typing is statically enforced documentation. Sure you might be lucky and already have voluntary documentation available but I am not. I'm getting sick of randomly being stuck for 10 hours on some trivial problem caused by wrong incentives.
C++ shows that in theory you can fix any flaw in an existing programming language as long as you maintain backwards compatibility by simply adding more features. The only thing you cannot change are implicit defaults (e.g. pass by value is the default, you have to manually opt out to pointers or references).
I like modern C++ because for me it's a reasonable compromise between java safety and C safety. Other than out of bounds memory accesses and legacy code I feel there is not much that can go wrong. However compiling C++ projects takes ages and in the projects I've worked on I often have to modify headers that are included almost everywhere. Every trivial changes requires a 5 minute rebuild.
After working with several high level programming languages with slow compilers I realised the following: typing is fast, compiling is slow. There is a reason why go is so popular. It offers that tradeoff in fast turn around time / compilation time with reasonably good performance and simplicity in exchange for more keyboard bashing and keyboard bashing is a cheap price to pay for what you're getting back.
> C++ shows that in theory you can fix any flaw in an existing programming language as long as you maintain backwards compatibility by simply adding more features.
Depends on what you mean. At a minimum, I think it's clear that C++ has avoided a Python 2/3 style split in the community. This means that otherwise relatively conservative users (I'm thinking of users on supercomputers in this case) are upgrading quickly to new C++ compilers and standard versions.
On the other hand, C++ has always been a kitchen sink sort of language, and it is even more so now. As codes age, they tend to grow and not shrink in the feature set they use, and so long-lived codes will probably never completely escape the demons of previous versions, regardless of how nice the shiny new features are.
Was it one of those? If not then the fault was with your code or the implementation, not the spec. The language itself is very good at maintaining backward compatibility.
1) are 90% every really large software projects written in C++. All the programs "everybody knows" just happen to be in C++. Examples include Chrome, Windows, Microsoft Office, Adobe tools, KDE, Autodesk, ...
Clearly those programs have massive scopes, large complexity, the need for extensive abstractions, the need for large teams cooperating, tests, ... all the stuff we value as programmers.
2) Are all programs in most other languages so ... small. In scope, in features, in ... Just look at Go programs on github. Or python ones.
Very large Python projects are a few 10's of thousands of lines of code. And they are limited by their complexity. Somehow C++ programs seem to have less of this problem.
Very large javascript projects don't even seem to get above a few thousand lines of code. And reading them, I can see why. Typescript at least seems to match Python in how much complexity it can contain without imposing too much of a burden, but that language doesn't match C++ either.
Most of those fancy languages are artificially limited in some ways. For instance, you cannot easily link QT into Go (nor can you do that with many other libraries, GTK has the same problem). C++ does not have that problem, and if it does, you can solve it. I do not claim doing so is easy, but it can be done. You're not stuck. Go on IOS ? It sort of works, with a boatload of limitations that make it utterly unworkable. C++ on IOS ? It works, with less limitations than Objective C.
I feel like C++ gets a much worse reputation than it deserves. Much worse. It is not the solution to everything, of course.
1) I know so many programs which are the same size or bigger than your "well-known" programs you probably never heard of but still use daily - They are just not desktop programs, a place where C++, for various reasons, is often the language of choice, but desktop programs are (for better or worse) just a small subset of all programs written.
2) See answer above.
> I feel like C++ gets a much worse reputation than it deserves. Much worse. It is not the solution to everything, of course.
In the end it all boils down to Stroustrups quote about programming languages: 'There are only two kinds of languages: the ones people complain about and the ones nobody uses'
Point 1 is mostly down to history I suspect. The big Adobe stuff is in C++ because they started writing them when C++ was The Thing. Probably quite cutting-edge then (not that it doesn't have some cutting-edge features now of course, that's what makes C++17 and C++20 and so on worth watching). Windows, Office likewise, although I've always assumed that an increasing chunk of Office is now written in C#. I have no evidence of that by the way. KDE - again of its time. Autodesk, likewise.
And then that gives you a huge historical inertia. Chrome started out using KDE's rendering engine, which was written in C++, at a time when writing cross-platform GUIs wasn't really feasible in anything else if you wanted it to also be reasonably fast.
And they stay in C++ because changing languages is a right pain in the whatsit, and C++'s ABI is so variable across platforms and compiler versions through history that integrating components in other languages is often not worth the effort to maintain. Not that it hasn't been done, of course, and done well. Look at how Firefox are now integrating Rust components in their C++ codebase - although they're doing it by relying on Rust's ability to expose a perfect C ABI, and C++'s ability to call it.
Point 2... yeah. I get this. C++ has a higher complexity bound than many languages, especially dynamic ones. C++ used as C++ rather than C-with-classes has a strong type checker and some very robust capabilities around memory management, program integrity, metaprogramming (even though the syntax is dire and the compile times are horrible). C++ expertise in large software construction is widely available. C++ will compile down to efficient machine code that runs well on many platforms. These are all huge advantages in large projects.
Python has its troubles with concurrency, and the lack of type information in the source code to help maintainers. Go is just too young - I suspect we're going to see some really giant Go projects emerging over the next ten years, especially outside the space you can see on GitHub. There will be big enterprises deploying enormous Go codebases, although they'll likely be made up of multiple components instead of one giant thing like we used to do. Rust's too young, Haskell's got the chops but is too weird for most people (and its own problems, although Stack has really helped with the developer experience), JavaScript is entirely unsuitable to a large maintainable codebase. I'd guess TypeScript can probably go a bit further then Python in that space, at least until Python's new type annotations start getting fully checked by tooling at which point it returns to parity (or exceeds it, due to not being JavaScript in disguise. Guess what, I don't like JavaScript, who'd've thought!)
But still we've got C++'s inertia to thank for a lot of this. It's huge, it's old, it's still being developed and still being used and there's a lot of knowledge and a lot of capability out there.
But then look at newer disciplines. Look at mobile apps - yes you can write C++, but the native languages of Android are Java and Kotlin, and of iOS are Objective-C and Swift. What are new developers going to want to do - learn Kotlin and Swift or figure out how to shim C++ into those platforms via the variously awkward methods available?
What about the web? How many web applications are written in C++? Very few, I suspect. It's all C#, Java, PHP, Node, Python and other modern things which may or may not be considered sexy.
C++ dominates in the older disciplines, the older software that's still here and we still use and will use for a very long time.
I think elsewhere it's being passed by, especially as we get languages like Rust and Go which are considered as possible replacements in the "I really need this to go as fast as possible" camp.
It's a shame really, as C++ is still a powerful, impressive language and the new stuff is fantastic. But I always felt when I was working as a C++ developer that I wished I could turn off those C-compatible core behaviours and completely block those implicit-but-dangerous type conversions, and get the compiler to scream at me about dangerous pointer usage (I believe something along those lines is in the works for a future standard).
And also a shame about D, which has its followers but has been largely ignored, overshadowed by C++ to start with and later passed by the new languages which get all the hype.
C++ is a tool for low level systems programming. Why would you compare that with GO? Also, I would argue that C++ is _WAY_ more popular than GO. It allows you to be productive in the real world, utilizing legacy code, legacy libraries, APIs, etc. Very few projects are 100% greenfield.
"Many" is an understatement here. Pretty much every Windows desktop app is written in C++ and Windows runs on over 90% of all desktops.
Adobe will never rewrite Photoshop in Rust or whatever. If you thought burying COBOL was hard.. C++ will outlast humanity.
I can already hear the Alien scientists: "An amazingly intricate and convoluted language for such a primitive species. The mismatch between their mental abilities and their language might explain the bug which caused the incident.."
As someone that has spent quite some years writing Windows software, actually since the .NET introduction and the maintenance status of MFC, the majority of Windows desktop apps are written in a mix of .NET and C++.
> Pretty much every Windows desktop app is written in C++ and Windows runs on over 90% of all desktops.
I think you may be the one overstating things. Where I work, a biomedical device firm, for every one app written in C++ there is either one python or matlab prototype of it and 5 python/matlab apps to test it/show it off. I'm sure for other places that number is far higher. I honestly don't see how you could quickly prototype sufficiently complex ideas any other way.
Better said, I can build a working Kalman filter, load saved patient data to it, create a primitive db, save output data to said primitive db, build a primitive, but functional enough that non-technical people can use it, GUI, from scratch, to plot said output data in Python all in a couple hours. Can you do that with C++ for the same time frame? Heck can you do it within an order of magnitude of the time I used? If you can't, why should you be spending an order of magnitude more money for it?
You wouldn't have to rewrite Adobe. You could rewrite one component of it (0 cost FFI). That's fair more reasonable. I think Servo is proving that Rust has a lot of potential for slowly replacing a C++ codebase, piece by piece.
Sure, people will ultimately use the tool they think is right for the job, given the people they've hired, etc. C++'s strength isn't UI programming (might be generalized to things that require more input from designer's than programmers), but writing high-performance, low-abstraction code (which could very well be the dominant factor in the success of the desktop app, hence the choice).
>C++ shows that in theory you can fix any flaw in an existing programming language as long as you maintain backwards compatibility by simply adding more features.
Well, "adding more features" can't be done "simply" if you want to "maintain backwards compatibility"; indeed, in the process of doing this is that the "flaws" are potentially augmented.
Yes! These are underrated items on the change list. Establishing precedents and habits for removing harmful things (like trigraphs) is very important to the future of the language.
There's some funny ones there. std::random_shuffle because it relies on rand() which may be bad, but ironically most (all?) the rng's that are in the standard library would be considered "bad" by modern standards.
"bad" for what purpose? The linear congruent stuff and Mersenne twisters, for example, are leaps and bounds better than a typical rand() implementation, and very appropriate for many uses.
You say that as if it is a small thing. Convenience, lack of additional code to maintain, consistency across platforms - for many projects these things will easily trump any algorithmic improvements from using something else.
> keyboard bashing is a cheap price to pay for what you're getting back
Only if your program is trivial. That is, if you can afford to run it over and over with results you can verify in the output as being incorrect, sure, keyboard bashing works.
Most of us work on programs that have been made trivial by abstracting the complexity into a framework or protocol library - like a web server. You can keyboard bash out a correct rest implementation on top of a routing library in minutes.
The problem domain is tiny(but really flexible!), and largely automated by code generation in most languages. The programmer is only there to cross some t's and dot some i's.
It would be a waste of productivity to write your own http server from the ground up. Writing one is non -trivial. For every new programming language that wants to serve web apps, a webserver must be written in that language. Having a compiler that verifies or does more for you on a non-trivial program is great. Not saying c++ is the right language here, just that a statically compiled program with an expressive type system catches more errors at compile time. Some/(most) bugs are unapparent in localized, repeated runs and unit tests that really only ever test a small subset of the range of possible inputs.
I like easy as much as the next programmer, I just mourn the fact that we can't seem to provide a safe, simple and easy in the same programming language.
Other than out of bounds memory accesses and legacy code I feel there is not much that can go wrong.
If only we could stop at single-threaded applications :-)
I'm not convinced modern C++ stops all issues with pointers/iterators and ownership either. But it's hard to tell because every large-enough application inevitable has to interface with legacy pointer code.
The point about legacy pointer code is valid, but the benefit of the newer pointer / iterator / ownership stuff isn't really that it is in and of itself a magic bullet.
What it does do is make it easy to reason about how pointers are used across the application. Also worth noting that even with legacy libraries, you can wrap a given pointer with std::unique_ptr or std::shared_ptr and provide a custom deleter and maintain reasonable safety guarantees.
I do get it's easier. I use std::unique_ptr when interfacing with legacy code because I like that I need an explicit .release() to relinquish ownership. It's self-documenting.
But I was considering modern C++ compared to, for example Rust. I'm not sure if the memory safety issue that Rust solves still exists as strongly with a purely modern C++ codebase...but then again I never run into those either.
For threads it's no contest between Rust and C++, although TSAN is pretty damn nice.
Your complaint about the slow compilation times might be addressed partially by Modules, expected for C++20. VS 2015 Update 1 and Clang already have experimental support.
in my experience when testing the current modules implementation, PCHs are still a good deal faster; if you use CMake they are dead easy to set-up so you may as well use them today.
> I often have to modify headers that are included almost everywhere.
I think this problem started with templates - previously you wrote abstract base classes (interfaces) and concrete classes had most of the code changes. I avoided templates where possible largely because of this.
>Using make, you can standardise a lot of this. If you set up a coding standard that after you clone a repo, "make dep" should grab anything the project requires, then developers don't initially need to know whether that's calling out to npm or composer or pip or whatever - it's just "working".
In my experience you will end up with a dozen coding "standards" and project structures. Especially in C and C++ where header dependencies have to be generated by the compiler even the most basic makefile will take you at least an hour to create if you already have experience in making makefiles.
Comes down to how you enforce it. To be clear, I'm not talking about mediating the build in Make unless that's the best tool for the job. On a C project I would use cmake, but within this system I'd run it out of a Makefile at a top level, so the person pulling it can just run 'make build'.
The point is to have a known starting place, so that when you pull down a new project you don't have to spend ages reading about how it works.
Even if you can't grab the deps automatically, doing 'make build' and it saying "Hey, you don't have cmake and a bunch of other things you need, but go look at http://whatever.. to set yourself up" is a much better experience.
The main function is 111 lines long but only roughly 30 lines of that are setup up code. The remaining 81 lines are the business logic that happens when a control has been interacted with.
Since when does initialising the GUI framework include all of your business logic and if it does should a non trivial application have a main function that is several thousands of lines long?
Why is paid busywork or a job guarantee more acceptable than basic income? Apparently the risk of basic income is that people end up only playing video games. But aren't video games the definition of busywork?
