www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Scott Meyers wants to bring default zero-initialization to C++,

reply Joakim <dlang joakim.fea.st> writes:
He advocates for a tool like gofix, to automatically convert such 
features to be deprecated:

http://scottmeyers.blogspot.com/2015/11/breaking-all-eggs-in-c.html

Good to see C++ finally trying to deprecate more, long overdue.
Nov 18 2015
next sibling parent reply ponce <contact gamesfrommars.fr> writes:
On Wednesday, 18 November 2015 at 15:12:27 UTC, Joakim wrote:
 He advocates for a tool like gofix, to automatically convert 
 such features to be deprecated:

 http://scottmeyers.blogspot.com/2015/11/breaking-all-eggs-in-c.html

 Good to see C++ finally trying to deprecate more, long overdue.
I doubt anything will get done even in 10 years. The average C++ industrial codebase don't build with the latest compiler, or even any static analyzer, and has its own particular build system. It is already a big trouble to upgrade C++ compilers even if nothing in the language is changing. D numerous, tiny interchangeable releases are a big asset when compared to the whole compiler-tied-to-IDE-tied-to-OS-releases which is what things are in C++ land. The idea that you could bring the C++ community to use an automatic upgrade tool, or to get everyone to follow optional "Core Guidelines" is optimistic.
Nov 18 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 18 November 2015 at 15:29:04 UTC, ponce wrote:
 The idea that you could bring the C++ community to use an 
 automatic upgrade tool, or to get everyone to follow optional 
 "Core Guidelines" is optimistic.
What community? Compilers can have pedantic compiler-switches. C++ needs what Ada has, different profiles for different scenarios. No problem in having a strict profile as the default for a compiler.
Nov 18 2015
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 18 November 2015 at 18:43:59 UTC, Ola Fosheim 
Grøstad wrote:
 On Wednesday, 18 November 2015 at 15:29:04 UTC, ponce wrote:
 The idea that you could bring the C++ community to use an 
 automatic upgrade tool, or to get everyone to follow optional 
 "Core Guidelines" is optimistic.
What community? Compilers can have pedantic compiler-switches. C++ needs what Ada has, different profiles for different scenarios. No problem in having a strict profile as the default for a compiler.
Oh God, please don't push for PHP-ifying C++. It's already confusing enough as it is. For those of you who have never had the pleasure of writing PHP, lots of PHP code does completely different things depending on the compiler switches when the interpreter was compiled, the global config for the host machine, the local config files in the directory, and the warning level switches at the start of the code. So much so that it's impossible to understand what a lot of code does without consulting all of these locations to double check. When looking at code, it should be obvious what it does without consulting outside factors.
Nov 18 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 18 November 2015 at 18:52:02 UTC, Jack Stouffer 
wrote:
 For those of you who have never had the pleasure of writing 
 PHP, lots of PHP code does completely different things 
 depending on the compiler switches when the interpreter was
Php is a dynamic language, that's different.
 When looking at code, it should be obvious what it does without 
 consulting outside factors.
I don't think this is a problem, it probably will be better overall. When C++ adds modules they have a golden opportunity to clean up the language for those compilation units that use it. But they probably won't. Which is good for languages like Rust and D.
Nov 18 2015
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 18 November 2015 at 19:09:48 UTC, Ola Fosheim 
Grøstad wrote:
 On Wednesday, 18 November 2015 at 18:52:02 UTC, Jack Stouffer 
 wrote:
 For those of you who have never had the pleasure of writing 
 PHP, lots of PHP code does completely different things 
 depending on the compiler switches when the interpreter was
Php is a dynamic language, that's different.
Is it really though? In theory, yes. But in practice it's the same problem. A switch to the compiler would change the behavior of some very common and fundamental pieces of code sounds like the same problem to me.
Nov 18 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 18 November 2015 at 21:08:38 UTC, Jack Stouffer 
wrote:
 Is it really though? In theory, yes. But in practice it's the 
 same problem.
Not the same problem. In dynamic languages changes are caught at runtime, not compile time. When changes affect compile time only then you can give up upgrading the code base and use a compatibility switch.
Nov 18 2015
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 18 November 2015 at 19:09:48 UTC, Ola Fosheim 
Grøstad wrote:
 On Wednesday, 18 November 2015 at 18:52:02 UTC, Jack Stouffer 
 wrote:
 For those of you who have never had the pleasure of writing 
 PHP, lots of PHP code does completely different things 
 depending on the compiler switches when the interpreter was
Php is a dynamic language, that's different.
Would you guys please stop calling PHP a language. JS and PHP are not languages, they are a fiddly feckin mess, which accounts for their high adoption rate. Sigh. Please, no gainsaying now, no "Yes, buts".
Nov 20 2015
next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Fri, 20 Nov 2015 12:12:41 +0000, Chris wrote:

 On Wednesday, 18 November 2015 at 19:09:48 UTC, Ola Fosheim Grøstad
 wrote:
 On Wednesday, 18 November 2015 at 18:52:02 UTC, Jack Stouffer wrote:
 For those of you who have never had the pleasure of writing PHP, lots
 of PHP code does completely different things depending on the compiler
 switches when the interpreter was
Php is a dynamic language, that's different.
Would you guys please stop calling PHP a language. JS and PHP are not languages, they are a fiddly feckin mess, which accounts for their high adoption rate. Sigh. Please, no gainsaying now, no "Yes, buts".
I'd rather limit the number of posts on this forum that contain contempt or dismissiveness. It's unfriendly and doesn't help anything.
Nov 20 2015
parent reply Chris <wendlec tcd.ie> writes:
On Friday, 20 November 2015 at 16:38:02 UTC, Chris Wright wrote:
 On Fri, 20 Nov 2015 12:12:41 +0000, Chris wrote:

 On Wednesday, 18 November 2015 at 19:09:48 UTC, Ola Fosheim 
 Grøstad wrote:
 On Wednesday, 18 November 2015 at 18:52:02 UTC, Jack Stouffer 
 wrote:
 For those of you who have never had the pleasure of writing 
 PHP, lots of PHP code does completely different things 
 depending on the compiler switches when the interpreter was
Php is a dynamic language, that's different.
Would you guys please stop calling PHP a language. JS and PHP are not languages, they are a fiddly feckin mess, which accounts for their high adoption rate. Sigh. Please, no gainsaying now, no "Yes, buts".
I'd rather limit the number of posts on this forum that contain contempt or dismissiveness. It's unfriendly and doesn't help anything.
Now, now, no need to feel offended. Bashing programming languages is part of programming. Never read any of those "Why [Python|PHP|JS|C++...] sucks" articles on the internet? I've had the misfortune of having to work with PHP and JS, and no shaming me will ever convince me that they are serious languages. Anyway, D is being bashed here all the time, haven't you noticed ;)
Nov 20 2015
parent reply Chris Wright <dhasenan gmail.com> writes:
On Fri, 20 Nov 2015 16:48:06 +0000, Chris wrote:

 On Friday, 20 November 2015 at 16:38:02 UTC, Chris Wright wrote:
 On Fri, 20 Nov 2015 12:12:41 +0000, Chris wrote:

 On Wednesday, 18 November 2015 at 19:09:48 UTC, Ola Fosheim Grøstad
 wrote:
 On Wednesday, 18 November 2015 at 18:52:02 UTC, Jack Stouffer wrote:
 For those of you who have never had the pleasure of writing PHP,
 lots of PHP code does completely different things depending on the
 compiler switches when the interpreter was
Php is a dynamic language, that's different.
Would you guys please stop calling PHP a language. JS and PHP are not languages, they are a fiddly feckin mess, which accounts for their high adoption rate. Sigh. Please, no gainsaying now, no "Yes, buts".
I'd rather limit the number of posts on this forum that contain contempt or dismissiveness. It's unfriendly and doesn't help anything.
Now, now, no need to feel offended.
No need to be condescending to me, either. I want this newsgroup to be helpful and friendly in its attitude. I think that's a reasonable goal, and I think most people here would agree that it would be good if that goal were achieved. When people complain about others being offended, it's usually to distract from the issue at hand. So let me say it straight: it doesn't matter whether I'm offended. It only matters what effect your words have on people.
 Bashing programming languages is
 part of programming. Never read any of those "Why [Python|PHP|JS|C++...]
 sucks" articles on the internet? I've had the misfortune of having to
 work with PHP and JS, and no shaming me will ever convince me that they
 are serious languages. Anyway,
 D is being bashed here all the time, haven't you noticed ;)
Nov 20 2015
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/20/2015 09:06 PM, Chris Wright wrote:
 ...

 When people complain about others being offended, it's usually to
 distract from the issue at hand.
When people complain about others being offended, I think it is usually because being offended can be a way to artificially add weight to the issue at hand, and they feel treated unfairly. Sometimes, they have gotten offended themselves. It is always possible to inflate the issue at hand by generalizing and extending it until it can be put in the same category with only slightly related, but much worse issues.
 So let me say it straight: it doesn't
 matter whether I'm offended. It only matters what effect your words have
 on people.
People should assume responsibility for their own actions and reactions.
Nov 20 2015
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Friday, 20 November 2015 at 12:12:42 UTC, Chris wrote:
 On Wednesday, 18 November 2015 at 19:09:48 UTC, Ola Fosheim 
 Grøstad wrote:
 On Wednesday, 18 November 2015 at 18:52:02 UTC, Jack Stouffer 
 wrote:
 For those of you who have never had the pleasure of writing 
 PHP, lots of PHP code does completely different things 
 depending on the compiler switches when the interpreter was
Php is a dynamic language, that's different.
Would you guys please stop calling PHP a language. JS and PHP are not languages, they are a fiddly feckin mess, which accounts for their high adoption rate. Sigh. Please, no gainsaying now, no "Yes, buts".
You may say that, yet, it both are widely used. There are reasons for that, and people are idiot is not one of them. PHP scales. This is why people use it. And this is why people will continue to use it. This is why Facebook, wikipedia, Baidu, wordpress and many others are using it. There is always a reason, and if you don't understand it, you are doomed to miss the point.
Nov 20 2015
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 20 November 2015 at 20:37:10 UTC, deadalnix wrote:
 On Friday, 20 November 2015 at 12:12:42 UTC, Chris wrote:
 On Wednesday, 18 November 2015 at 19:09:48 UTC, Ola Fosheim 
 Grøstad wrote:
 On Wednesday, 18 November 2015 at 18:52:02 UTC, Jack Stouffer 
 wrote:
 For those of you who have never had the pleasure of writing 
 PHP, lots of PHP code does completely different things 
 depending on the compiler switches when the interpreter was
Php is a dynamic language, that's different.
Would you guys please stop calling PHP a language. JS and PHP are not languages, they are a fiddly feckin mess, which accounts for their high adoption rate. Sigh. Please, no gainsaying now, no "Yes, buts".
You may say that, yet, it both are widely used. There are reasons for that, and people are idiot is not one of them. PHP scales. This is why people use it. And this is why people will continue to use it. This is why Facebook, wikipedia, Baidu, wordpress and many others are using it. There is always a reason, and if you don't understand it, you are doomed to miss the point.
D is not in that league.
Nov 20 2015
parent reply deadalnix <deadalnix gmail.com> writes:
On Friday, 20 November 2015 at 22:01:58 UTC, Chris wrote:
 D is not in that league.
Doesn't matter? It is clear you shit on things you don't understand. That makes you sound like an idiot to these who understand.
Nov 20 2015
parent Chris <wendlec tcd.ie> writes:
On Friday, 20 November 2015 at 22:12:13 UTC, deadalnix wrote:
 On Friday, 20 November 2015 at 22:01:58 UTC, Chris wrote:
 D is not in that league.
Doesn't matter? It is clear you shit on things you don't understand. That makes you sound like an idiot to these who understand.
Thanks for the compliments. The reason why PHP and JS took off have nothing to do with quality. JS was called Javascript, because Java was on the rise in those days. A deal was made to promote JS along with Java. JS is so successful, because there simply was no other option for a long time. This has nothing to do with tutorials or the quality of the language. Now, it is relatively easy to do things with JS and PHP which attracted a huge crowd of hobby HTML developers and also professionals took to it too, because they could get things done quickly and make their clients happy, "Look ma, the box changes its background color!" - and could charge their clients a sh*it load of money for relatively simple things (we're talking late 90ies to early 2000s). I know this for a fact, because I had to deal with web developers who fleeced the company I was working for big time (e.g. for changing a line of code in the JS). This also means that a lot of people who use JS and PHP are not really into programming, it's just a convenient way for them to develop homepages and web apps, which is fine. D on the other hand is a completely different beast. D was meant to be a full fledged multi-purpose programming language. To compare D to PHP or JS is mixing apples and oranges. It makes no sense whatsoever to compare them. D cannot "compete" with JS or PHP, because they are completely different things. This is why I say we should stop demanding that D be as 'successful' as PHP and JS. It is misleading and doesn't help D in any way. By the way, a lot of people regret later that they've chosen PHP. PHP an JS offer instant gratification but give you a terrible headache later (like a cheap street drug!). D cannot offer instant gratification and we should not aim to appeal to people who want or need (web developers) instant gratification. It just won't work. This is not being elitist, it's being realistic.
Nov 22 2015
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 20 November 2015 at 20:37:10 UTC, deadalnix wrote:
 On Friday, 20 November 2015 at 12:12:42 UTC, Chris wrote:
 Would you guys please stop calling PHP a language. JS and PHP 
 are not languages, they are a fiddly feckin mess, which 
 accounts for their high adoption rate. Sigh. Please, no 
 gainsaying now, no "Yes, buts".
You may say that, yet, it both are widely used. There are reasons for that, and people are idiot is not one of them.
It is a big part of the reasons.
 PHP scales. This is why people use it. And this is why people 
 will continue to use it. This is why Facebook, wikipedia, 
 Baidu, wordpress and many others are using it. There is always 
 a reason, and if you don't understand it, you are doomed to 
 miss the point.
Whut? PHP scales?! If you simply mean that it is easily coded by lowest-common denominator programmers, so it's easy to throw a bunch of those low-skilled coders on the job, then perhaps that's why you end up with monstrosities like this: http://quellish.tumblr.com/post/126712999812/how-on-earth-the-facebook-ios-application-is-so http://www.darkcoding.net/software/facebooks-code-quality-problem/ Potshots at your employer aside- ;) I could have done the same for Wikipedia and Wordpress, don't know much about Baidu- I'd honestly like to know how you think PHP scales, because it's success has always been a perfect example of Gresham's law to me: http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2015-06.html#e2015-06-14T09_17_33.htm
Nov 20 2015
parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 21 November 2015 at 07:20:07 UTC, Joakim wrote:
 PHP scales. This is why people use it. And this is why people 
 will continue to use it. This is why Facebook, wikipedia, 
 Baidu, wordpress and many others are using it. There is always 
 a reason, and if you don't understand it, you are doomed to 
 miss the point.
Whut? PHP scales?! If you simply mean that it is easily coded by lowest-common denominator programmers, so it's easy to throw a bunch of those low-skilled coders on the job, then perhaps that's why you end up with monstrosities like this:
Yes PHP sclaes. PHP scales like crazy? PHP scales better than whatever modern framework you'll present me. There is just nothing that came up with the same execution. You can say whatever you want about the languages (and there is a lot to say !) but it gets its execution model right for scaling, while everybody gets it wrong. And apparently, getting your execution model right is more important than all the quirk you pour into the language. Actually, that's not surprising, Rasmus Ledorf is a specialist of the web, while he doesn't knows much about PL both theoretically and practically (by his own admission). As a result, you get a passable language, but you know what ? That's not the important part.
 http://quellish.tumblr.com/post/126712999812/how-on-earth-the-facebook-ios-application-is-so
 http://www.darkcoding.net/software/facebooks-code-quality-problem/

 Potshots at your employer aside- ;) I could have done the same 
 for Wikipedia and Wordpress, don't know much about Baidu- I'd 
 honestly like to know how you think PHP scales, because it's 
 success has always been a perfect example of Gresham's law to 
 me:

 http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2015-06.html#e2015-06-14T09_17_33.htm
You can go for it, I've read these article already. Yet, Facebook as the strongest engineering team I've worked with, and not by a thin margin. Maybe some of the people writing on the subject have a strongest team, but statistically, it is very improbable that more than a ridiculously small fraction of them actually do. Nobody cares about what some guy on reddit think about the number of classes there is in the iOS app. What matter is delivering value to users and customers. And as a matter of fact half of the top 10 apps are Facebook owned. This is not a one time lucky shot, this is just a working methodology that delivers. Just from the comment this one is delicious : "This kind of attitude is so anti-user." Yeah sure, Facebook is anti users. It has just more than a billion of them, how many do your app has ? As to Gresham's law, it's kind of defeated by the move to hack (http://hacklang.org/) isn't it. But let's not get the facts get in the way of a good story. Long story short, nothing reach the level of usage PHP, Node.js or other techno has at random. You can only go so far not knowing what you are doing. When you see something that big, and when it has obvious flaws (I mean, it is not like it is difficult to find problems in Node.js or PHP), it is really need to take step back and wonder, what did they get right ? Because obviously, they got something right. In fact they got something SO right that it can get over flaws on other aspects. These are lesson in delivering value to users. One should learn from it rather than dismissing it. Node.js is used at linkedin, paypal, ebay, netflix, uber, and who know else. Realistically, what is the probability that all these companies are staffed by morons and still succeed at the scale they do ? Negligible. Get over your proudness. Node.js and PHP answer actual needs that is what matters. It doesn't matter how much inconsistency there is in the languages when no alternative does better.
Nov 21 2015
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Saturday, 21 November 2015 at 10:29:57 UTC, deadalnix wrote:
 On Saturday, 21 November 2015 at 07:20:07 UTC, Joakim wrote:
 PHP scales. This is why people use it. And this is why people 
 will continue to use it. This is why Facebook, wikipedia, 
 Baidu, wordpress and many others are using it. There is 
 always a reason, and if you don't understand it, you are 
 doomed to miss the point.
Whut? PHP scales?! If you simply mean that it is easily coded by lowest-common denominator programmers, so it's easy to throw a bunch of those low-skilled coders on the job, then perhaps that's why you end up with monstrosities like this:
Yes PHP sclaes. PHP scales like crazy? PHP scales better than whatever modern framework you'll present me. There is just nothing that came up with the same execution. You can say whatever you want about the languages (and there is a lot to say !) but it gets its execution model right for scaling, while everybody gets it wrong. And apparently, getting your execution model right is more important than all the quirk you pour into the language. Actually, that's not surprising, Rasmus Ledorf is a specialist of the web, while he doesn't knows much about PL both theoretically and practically (by his own admission). As a result, you get a passable language, but you know what ? That's not the important part.
Could you elaborate a bit on this? What about the execution model is so right?
Nov 21 2015
parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 21 November 2015 at 11:40:41 UTC, John Colvin wrote:
 Actually, that's not surprising, Rasmus Ledorf is a specialist 
 of the web, while he doesn't knows much about PL both 
 theoretically and practically (by his own admission). As a 
 result, you get a passable language, but you know what ? 
 That's not the important part.
Could you elaborate a bit on this? What about the execution model is so right?
PHP runs every request in complete isolation. All global/static are in fact request local storage. This has many consequences, namely: - It scales. More machines, more requests. - It makes memory management easier: everything is reference counted, and if you leak because of cycles, it doesn't matter, you trash it all at the end of the request. - Because of builtin reference count, you can get efficient COW containers. PHP array are weird, but they get that right. - Because you have COW containers, you can shared them accross request without fear of screwing everything up. Useful for configurations or other data structures that doesn't change often. - Because you get fresh environment for each request, it is much easier to debug when something goes wrong. - If something goes bad for one request (out of memory, takes too long to run, ...) you can trash it without any risk of impacting the service at large. - When a request corrupt its state for whatever reason, you don't put the whole service in jeopardy. Log and trash it all. Amazingly, most other tools to do the same do not share this design decision, and it has quite a negative impact. Python with things like django has the GIL, Java and C# have locking all over the place in its standard lib, Node.js mixup all requests int he same context and play the callback game, which put the whole service at the mercy of one request going sour, and will cause major issues when scaling. I have to say, even vibe.d doesn't get this right. Obviously alternatives have other selling points, but overall, there is nothing like PHP to serve web request at a massive scale and this is why so many big websites are using it.
Nov 21 2015
parent reply Dicebot <public dicebot.lv> writes:
On Saturday, 21 November 2015 at 22:47:46 UTC, deadalnix wrote:
 Could you elaborate a bit on this? What about the execution 
 model is so right?
PHP runs every request in complete isolation. All global/static are in fact request local storage. This has many consequences, namely: - It scales. More machines, more requests. - It makes memory management easier: everything is reference counted, and if you leak because of cycles, it doesn't matter, you trash it all at the end of the request. - Because of builtin reference count, you can get efficient COW containers. PHP array are weird, but they get that right. - Because you have COW containers, you can shared them accross request without fear of screwing everything up. Useful for configurations or other data structures that doesn't change often. - Because you get fresh environment for each request, it is much easier to debug when something goes wrong. - If something goes bad for one request (out of memory, takes too long to run, ...) you can trash it without any risk of impacting the service at large. - When a request corrupt its state for whatever reason, you don't put the whole service in jeopardy. Log and trash it all.
And something like Erlang does all of the above at much better performance and quality of implementation. Most importantly, though, you completely ignore the performance overhead costs that matter for most companies that are not Facebook. Reimplementing main points from abovementioned list (primarily isolation and request-local allocators) can be done with pretty much any decent language and potentially save huge amount of money on server costs. Scaling implies not only being able to increase the load without system redesign but also doing it efficiently - both in server and maintenance costs. PHP is rather bad at both.
Nov 21 2015
parent reply deadalnix <deadalnix gmail.com> writes:
On Sunday, 22 November 2015 at 03:28:42 UTC, Dicebot wrote:
 And something like Erlang does all of the above at much better 
 performance and quality of implementation. Most importantly, 
 though, you completely ignore the performance overhead costs 
 that matter for most companies that are not Facebook.
Erlang makes state terrible to work with (but doesn't bound state to a request). PHP has request local state. The model is very different. One of these models is way easier to work with. I also didn't went into this as it was irrelevant to the scaling argument, but having rapid iteration is key, especially for UI work where automation is hard. Erlang doesn't fit the bill. Last but not least, Erlang has a foreign syntax, so ramping up devs is harder. Back on PHP, there are many other aspects of the siloed requests model that provide benefits that erlang simply cannot provide.
 Reimplementing main points from abovementioned list (primarily 
 isolation and request-local allocators) can be done with pretty 
 much any decent language and potentially save huge amount of 
 money on server costs.
Well one can recode the runtime to get these behaviors. Or one can focus on delivering value to customers. That's one damn thing that the D community need to get burned into their brain. "You can avoid using the GC", "You can use addr2line to get line number in your stacktrace", and so on are cheap excuse for delivering crap. There are good plateforms that come with shit language out there. We have a good language with a shit plateform (let's be honest one second). Facts show that 1/ win over 2/ 100% of the time. Writing how bad 1/ is in the 2/ forum is simply an exercise in finding excuses to not look where it is ugly.
 Scaling implies not only being able to increase the load 
 without system redesign but also doing it efficiently - both in 
 server and maintenance costs. PHP is rather bad at both.
No, performance, efficiency and scalability are disjoint things. Scalability is about how much more resource are needed to serve how much more requests. I'm living in the real world, where at least half or the request you make to a webserver are handled by PHP. Arguments are cheap when facts refuse to match.
Nov 22 2015
next sibling parent reply Dicebot <public dicebot.lv> writes:
On Sunday, 22 November 2015 at 08:00:51 UTC, deadalnix wrote:
 Erlang makes state terrible to work with (but doesn't bound 
 state to a request). PHP has request local state. The model is 
 very different. One of these models is way easier to work with.
I see the point but it is quite subjective/arguable. If one wants to go for scalability model with discardable requests context there is a lot of merit in not having any locally stored state at all.
 I also didn't went into this as it was irrelevant to the 
 scaling argument, but having rapid iteration is key, especially 
 for UI work where automation is hard. Erlang doesn't fit the 
 bill.
No objections here but it is indeed irrelevant to scaling in any sense.
 Last but not least, Erlang has a foreign syntax, so ramping up 
 devs is harder.
It is also quite true and irrelevant to scaling statement. Though I'd expect Facebook to have less trouble with it considering the famous hiring standards.
 Back on PHP, there are many other aspects of the siloed 
 requests model that provide benefits that erlang simply cannot 
 provide.
Probably, though wording "simply cannot" is very rare to be true. But it is also true the other way around - in PHP it rather hard to get transparent messaging between services (decoupled from underlying physical server layout) and I will call that more important for scaling than all of your points combined.
 Reimplementing main points from abovementioned list (primarily 
 isolation and request-local allocators) can be done with 
 pretty much any decent language and potentially save huge 
 amount of money on server costs.
Well one can recode the runtime to get these behaviors. Or one can focus on delivering value to customers.
Recode runtime? Most of stuff you mention is provided for free by simply using CGI model :) Using vibe.d processes in single thread mode with external load balancer provides system with similar benefits and better performance/maintainability - right here and now. Apart from COW bit of course, but that is one I completely disagree with as beneficial at all. And D isn't any special here. You describe one specific (not even necessarily as scalable as you claim) approach to service architecture and call it inherent property of a language (and pretty much a killing feature). That is absurd.
 Scaling implies not only being able to increase the load 
 without system redesign but also doing it efficiently - both 
 in server and maintenance costs. PHP is rather bad at both.
No, performance, efficiency and scalability are disjoint things. Scalability is about how much more resource are needed to serve how much more requests.
Yes, and if absolute amount of resources is too costly, it doesn't matter if relative increase is linear. It like having algorithm with good complexity but huge constant - theoretically it scales but in practice you want better. Maintenance costs are directly related though - developer resource also counts when measuring the increase. Because of that one can't ignore problematic parts of PHP as a language itself when talking scalabiliy. If it can't survive business logic increase, being able to survive request count increase only helps so much.
 There are good plateforms that come with shit language out 
 there. We have a good language with a shit plateform (let's be 
 honest one second). Facts show that 1/ win over 2/ 100% of the 
 time.

 Writing how bad 1/ is in the 2/ forum is simply an exercise in 
 finding excuses to not look where it is ugly.
 I'm living in the real world, where at least half or the 
 request you make to a webserver are handled by PHP. Arguments 
 are cheap when facts refuse to match.
And this is what struck me as unpleasantly surprising in your comments on topic. You take social factors (getting the momentum, gathering large stable community) and derived beneficial factors (good tooling, good platforms, lot of out of the box solutions) and proceed to use it as a backing argument to mostly technical statement ("PHP (as a language) scales"), casually accusing everyone of being stupid in process. Like, WTF? One can also say that PHP is easy language to start with which got in right place in right time with good vision. That contribution snowball effect resulted in having very good platform and collective wisdom, as well as solid developer pool. That it outshines all commonly called technical flaws and, together with convenient common request processing model, can make it feasible decision for scalable systems if one can afford it. But going straight to "PHP scales, suck it" and backing it by "hey, Facebook uses it"? That is missing important context at best.
Nov 22 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 22 November 2015 at 10:58:33 UTC, Dicebot wrote:
 comments on topic. You take social factors (getting the 
 momentum, gathering large stable community) and derived 
 beneficial factors (good tooling, good platforms, lot of out of 
 the box solutions) and proceed to use it as a backing argument 
 to mostly technical statement ("PHP (as a language) scales"),
Php started at zero like everyone else. It followed a growth pattern like Perl, and did so by accumulating C libraries/APIs and making 5 liners productive. But it was also reasonable effective compared to perl/python and it most certainly worked better at the small web scale than the alternatives. Working well at the small scale was probably the primary reason for Php's success. And being able to scale up to hosting many websites on a single server reasonable efficiently was also a factor. So scaling has been a factor for the success of Php, just not the big site scaling. Erlang is probably the only language that has gained momentum because of the ability to scale upwards.
 One can also say that PHP is easy language to start with which 
 got in right place in right time with good vision. That 
 contribution snowball effect resulted in having very good 
 platform and collective wisdom, as well as solid developer pool.
The dominant factor has probably been that Php has been perceived as non-professional and unsuitable for serious business all along. As a result it become a differentiating factor for hosting. Charge a small fee for Php/MySQL aiming at personal sites and small businesses, charge a premium for Python/Java/Postgres/MS etc. But most people want to save money so they went with Php... Php might have failed if it had been a good enterprise level language, it would have been too attractive to differentiate web host pricing.
Nov 22 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-11-22 09:00, deadalnix wrote:

 Last but not least, Erlang has a foreign syntax, so ramping up devs is
 harder.
There's Elixir [1] as well, which runs on the Erlang platform. It has a syntax that is quite similar to Ruby. I know some developers don't like Ruby but the syntax less is alien than Erlang. [1] http://elixir-lang.org/ -- /Jacob Carlborg
Nov 22 2015
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 21 November 2015 at 10:29:57 UTC, deadalnix wrote:
 Yes PHP sclaes. PHP scales like crazy? PHP scales better than 
 whatever modern framework you'll present me. There is just 
 nothing that came up with the same execution.
Not what I've heard. Thankfully, I've been able to avoid using PHP, but like John, I wonder what you think it does right in its scaling.
 You can say whatever you want about the languages (and there is 
 a lot to say !) but it gets its execution model right for 
 scaling, while everybody gets it wrong. And apparently, getting 
 your execution model right is more important than all the quirk 
 you pour into the language.

 Actually, that's not surprising, Rasmus Ledorf is a specialist 
 of the web, while he doesn't knows much about PL both 
 theoretically and practically (by his own admission). As a 
 result, you get a passable language, but you know what ? That's 
 not the important part.
Actually, it is. What percentage of the PHP code out there needs to scale much? Facebook is the exception that proves the rule. I disagree with your notion that all the large orgs you mentioned as PHP users are dispassionately comparing a bunch of languages and chose PHP because it was the _only one that scales_ to the extent they need, and that was so important to them that they overlooked all its other problems. And even if PHP scales better as you claim, that's not particularly important for most of the PHP code out there.
 You can go for it, I've read these article already. Yet, 
 Facebook as the strongest engineering team I've worked with, 
 and not by a thin margin. Maybe some of the people writing on 
 the subject have a strongest team, but statistically, it is 
 very improbable that more than a ridiculously small fraction of 
 them actually do.
Several people argue in those reddit threads that the problem likely isn't weak engineers but a corporate culture that doesn't value a designed architecture and code quality. Perhaps that hasn't mattered so far, but it likely will at some point.
 Nobody cares about what some guy on reddit think about the 
 number of classes there is in the iOS app. What matter is 
 delivering value to users and customers. And as a matter of 
 fact half of the top 10 apps are Facebook owned. This is not a 
 one time lucky shot, this is just a working methodology that 
 delivers.

 Just from the comment this one is delicious : "This kind of 
 attitude is so anti-user." Yeah sure, Facebook is anti users. 
 It has just more than a billion of them, how many do your app 
 has ?
If you give away a free app that lets people share pics with each other and that's funded by VC millions, you can get very popular. Instagram and Snapchat have also shown that. That doesn't mean the tech is any good or that the company will last.
 As to Gresham's law, it's kind of defeated by the move to hack 
 (http://hacklang.org/) isn't it. But let's not get the facts 
 get in the way of a good story.
Doesn't that prove it? Why create something that you feel is better otherwise? And assuming Hack _is_ better, not like it's killing PHP yet, further supporting the law. ;)
 Node.js is used at linkedin, paypal, ebay, netflix, uber, and 
 who know else. Realistically, what is the probability that all 
 these companies are staffed by morons and still succeed at the 
 scale they do ? Negligible.
Well, to begin with, none are running their core services on node.js that I know of. Is it possible that they all have their usual quota of morons simply picking node.js for smaller projects that don't matter because it's the current coolness? Very likely.
 Long story short, nothing reach the level of usage PHP, Node.js 
 or other techno has at random. You can only go so far not 
 knowing what you are doing. When you see something that big, 
 and when it has obvious flaws (I mean, it is not like it is 
 difficult to find problems in Node.js or PHP), it is really 
 need to take step back and wonder, what did they get right ? 
 Because obviously, they got something right. In fact they got 
 something SO right that it can get over flaws on other aspects. 
 These are lesson in delivering value to users. One should learn 
 from it rather than dismissing it.
Of course they got something right, as there are scores of languages that sit unused. But that doesn't mean they are technically any good or even worthwhile solutions for what they're being used for. Users choose tools for the wrong reasons all the time.
 Get over your proudness. Node.js and PHP answer actual needs 
 that is what matters. It doesn't matter how much inconsistency 
 there is in the languages when no alternative does better.
Not proud, I've argued in this forum in the past that scripting languages have an audience that D is unlikely to make much of an inroads into. They simply optimize programmer convenience over efficiency and that's an acceptable tradeoff in certain niches. However, even in that market, there are badly-designed languages that do unreasonably well. Not interested in an argument here, so I'll end with a constructive question: what do you believe D "should learn from [PHP/JS] rather than dismissing it?"
Nov 21 2015
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 21 November 2015 at 13:28:20 UTC, Joakim wrote:
 an inroads into.  They simply optimize programmer convenience 
 over efficiency and that's an acceptable tradeoff in certain 
 niches.  However, even in that market, there are badly-designed 
 languages that do unreasonably well.
That's true. The computer market is heavily dominated by critical mass. That means any poorly thought out technology will survive on a long death trail when it reaches critical mass. Php was really only for adding a little bit of scripting within HTML, and was shipped as easy installs for web servers. Then Php got installed by default by providers on the cheap offerings and people wanted apps that they could just install and configure with minimal effort. Which is why we have seriously bad code like Wordpress all over the web... Anything can be made to scale... just reach critical mass and it scales since people stick to their investments. And knowhow is a big investment...
 Not interested in an argument here, so I'll end with a 
 constructive question: what do you believe D "should learn from 
 [PHP/JS] rather than dismissing it?"
From Php: - Focus on ONE domain and make it very easy to get started with in that domain. - Gain critical mass in that domain before spreading out. From JS: - A modern language that is aiming for high level convenience has to transpile to javascript/asm.js. That's a very important target if you want to increase the amount of portable code written for your language. - One big-big advantage Node.js has is the ability to make backwards compatible views of a web-app by running client code on the server for older browsers. - When designing a language around a garbage collector, make sure it is top notch before extending the language.
Nov 21 2015
prev sibling next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Sat, 21 Nov 2015 13:28:19 +0000, Joakim wrote:
 Actually, it is.  What percentage of the PHP code out there needs to
 scale much?
Wordpress and MediaWiki are both written in PHP. But this level of scaling doesn't require a framework that scales. It requires a database system that scales, a clever load balancer, and an RPC mechanism. There are several popular forum systems written in PHP, and they are sometimes required to scale a fair bit on a single host. I'm seeing few concrete references in terms of QPS, but it looks like, for phpBB, people are recommending splitting frontend servers from database servers around 1500 simultaneous users. Another way to estimate (crudely) how well platforms scale is to compare pricing for similar products implemented in each. vBulletin, for instance, has a $75/month tier supporting up to 200GB of data transfer. nodeBB has a $100/month tier supporting 500,000 monthly pageviews. These turn out to be roughly comparable if you ignore caching, and nodeBB has some extra value adds. So vBulletin and nodeBB probably scale similarly -- unless one of these organizations is getting significantly different profit margins or something, anyway. And this is evidence toward PHP scaling about as well as Node.js. Collating a large number of examples like this would give us a good overall estimate of each platform's scaling properties.
Nov 21 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 21 November 2015 at 17:31:15 UTC, Chris Wright wrote:
 Collating a large number of examples like this would give us a 
 good overall estimate of each platform's scaling properties.
In order to scale easily you need to use NOSQL databases, but you can use any language. IIRC youtube started out with Python and MySQL. http://highscalability.com/blog/2012/3/26/7-years-of-youtube-scalability-lessons-in-30-minutes.html The code structure of Phpbb is so-so and does not really afford scaling. I ported it to App Engine and it took more effort than I expected. Phpbb also used/used unsafe features that have been removed from Php on App Engine. But the Phpbb source sure is a lot better than WordPress, which I ditched after looking over the core codebase. It is beyond me why any professional programmers are willing use it. Scaling? Scaling up a PoS, just makes it a bigger PoS.
Nov 21 2015
parent reply Chris Wright <dhasenan gmail.com> writes:
On Sat, 21 Nov 2015 21:51:43 +0000, Ola Fosheim Grøstad wrote:

 On Saturday, 21 November 2015 at 17:31:15 UTC, Chris Wright wrote:
 Collating a large number of examples like this would give us a good
 overall estimate of each platform's scaling properties.
In order to scale easily you need to use NOSQL databases, but you can use any language.
There's nothing inherent in having a rigid schema or using SQL as a query language that prevents scaling. But MySQL, for instance, is twenty years old, and PostgreSQL is nearly as old. Oracle, in contrast, is nearly forty. A system designed originally to scale to PDP-11s requires extensive effort and redesign to scale to scale as well as modern applications require. Databases implemented more recently are generally built to scale out. They have automatic sharding built into them, client and server. They were developed (and their scaling systems designed) when we already had algorithms like RAFT and a lot of experience with distributed systems.
Nov 21 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 22 November 2015 at 01:53:01 UTC, Chris Wright wrote:
 There's nothing inherent in having a rigid schema or using SQL 
 as a query language that prevents scaling.
That's right, except that joins and desirable consistency requirements creates a ceiling when it comes to scaling. It does so on NOSQL databases too, but you tend to avoid those there by making joins "manual labour". A database like BigTable does encourage two fundamental concepts: 1. eventual consistency, meaning: - indexes are out of date - reads based on identity are up to date 2. transactions and consistency on shared ancestors, meaning: - transactions acts on a hierarchical database structure (hierarchical data bases have always been more performant than relational, but the latter is more convenient). 3. massively frequent updates and infrequent queries are handled by representing a single object as many objects (sharding) (like voting in an election) The relational model is flat and flexible, but is resistant to scaling.
 Oracle, in contrast, is nearly forty. A system designed 
 originally to scale to PDP-11s requires extensive effort and 
 redesign to scale to scale as well as modern applications 
 require.
The main challenge is to break relationships with consistency requirements across compute-nodes (servers).
 designed) when we already had algorithms like RAFT and a lot of 
 experience with distributed systems.
Looks interesting, but I don't see how it helps with the fundamental model used in RDBMSes?
Nov 22 2015
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
On Saturday, 21 November 2015 at 13:28:20 UTC, Joakim wrote:
 As to Gresham's law, it's kind of defeated by the move to hack 
 (http://hacklang.org/) isn't it. But let's not get the facts 
 get in the way of a good story.
Doesn't that prove it? Why create something that you feel is better otherwise? And assuming Hack _is_ better, not like it's killing PHP yet, further supporting the law. ;)
Hack IS better no doubt. But that disprove the Gresham's law hypothesis, namely that PHP sticks because it is irreplaceable. On the other hand, you'll note that what I said was good about PHP also apply to hack; hack is a different language, but it shares its execution model with PHP.
Nov 21 2015
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 21 November 2015 at 13:28:20 UTC, Joakim wrote:
 Not proud, I've argued in this forum in the past that scripting 
 languages have an audience that D is unlikely to make much of 
 an inroads into.  They simply optimize programmer convenience 
 over efficiency and that's an acceptable tradeoff in certain 
 niches.  However, even in that market, there are badly-designed 
 languages that do unreasonably well.

 Not interested in an argument here, so I'll end with a 
 constructive question: what do you believe D "should learn from 
 [PHP/JS] rather than dismissing it?"
Well the first lesson would be in your comment already. A badly designed languages that get what matter to some user right will do unreasonably well. By extension I'd say that the ecosystem matter as much, if not more than the language itself. That getting something really right can excuse a lot of crap. Think iPhone 1, the smartphone that don't do 3G nor send MMS. Sounds like a joke doesn't it ? Yet thi is how the second biggest mobile platform started with. On a more meta level, when something succeed at a very large scale, while having aspect of it that smell bad. Believe me I can tell you a lot about how bad PHP is, as well as most people at Facebook could. This language is fucked beyond repair in many ways. But, that only makes it more interesting, because that means there is something in there that is non obvious and that most alternatives missed. Rather than having an aristocratic attitude toward these languages that we perceive as badly designed, we should be really asking ourselves the question "what did they get right ? Can we get it right too ?". Because we have signal here, that is telling us this thing really matter.
Nov 21 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/21/2015 3:32 PM, deadalnix wrote:
 Rather than having an aristocratic attitude toward these languages that we
 perceive as badly designed, we should be really asking ourselves the question
 "what did they get right ? Can we get it right too ?". Because we have signal
 here, that is telling us this thing really matter.
15 years ago, everyone loved to bash BASIC as a terrible language. I did too. But then I was looking at some Visual Basic code for a friend, and noticed something I had forgotten - it was really easy to manipulate strings. I was used to the horrible way of dealing with strings in C. I resolved that D had to have strings as nice as BASICs, and pretty much succeeded.
Nov 21 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 22 November 2015 at 07:36:40 UTC, Walter Bright wrote:
 15 years ago, everyone loved to bash BASIC as a terrible 
 language. I did too. But then I was looking at some Visual 
 Basic code for a friend, and noticed something I had forgotten 
 - it was really easy to manipulate strings. I was used to the 
 horrible way of dealing with strings in C. I resolved that D 
 had to have strings as nice as BASICs, and pretty much 
 succeeded.
Just about all 8 bit computers shipped with BASIC and it was quite reasonable as a scripting language/CLI as Microsoft had a relatively memory efficient VM for it. One could do cool stuff in BASIC by adding small pieces of machine language to do the heavy lifting, just like you can with Python or Lua today. But the line numbering system was annoying. (Perl, sed etc are still the most concise languages for string manipulation...)
Nov 22 2015
prev sibling parent Dicebot <public dicebot.lv> writes:
On Friday, 20 November 2015 at 20:37:10 UTC, deadalnix wrote:
 PHP scales. This is why people use it. And this is why people 
 will continue to use it. This is why Facebook, wikipedia, 
 Baidu, wordpress and many others are using it.
This is one of most ridiculous statements I have ever heard from you. If anything, Facebook is prime example of how terrible PHP does scale and how much it additional costs it creates to get bound to it in the long term. Wordpress simply can't handle any non-trivial load with straightforward setup. I have expected better from you than to back technical statement with marketing reference.
Nov 21 2015
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/18/15 10:12 AM, Joakim wrote:
 He advocates for a tool like gofix, to automatically convert such
 features to be deprecated:
It isn't going to happen. See the caveat at the bottom, along with his other post. As long as C has the preprocessor, a tool like gofix is nearly impossible to create. I'm sure Daniel has some experience with this ;) -Steve
Nov 18 2015
parent deadalnix <deadalnix gmail.com> writes:
On Wednesday, 18 November 2015 at 15:46:38 UTC, Steven 
Schveighoffer wrote:
 On 11/18/15 10:12 AM, Joakim wrote:
 He advocates for a tool like gofix, to automatically convert 
 such
 features to be deprecated:
It isn't going to happen. See the caveat at the bottom, along with his other post. As long as C has the preprocessor, a tool like gofix is nearly impossible to create. I'm sure Daniel has some experience with this ;) -Steve
Note that we have the same problem with our unstructured templates and string mixins.
Nov 18 2015
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 18 November 2015 at 15:12:27 UTC, Joakim wrote:
 He advocates for a tool like gofix, to automatically convert 
 such features to be deprecated:

 http://scottmeyers.blogspot.com/2015/11/breaking-all-eggs-in-c.html

 Good to see C++ finally trying to deprecate more, long overdue.
Also found this comment from Scott when reading the comments just now: "If C++ were to adopt zero-initialization by default, I'd expect a provision for opting out in every context where the current language doesn't require initialization (e.g., arrays, heap objects without constructors, etc.). What the opt-out syntax would be for the various contexts, I don't know, though the first place I'd look would be D to see what it does." Good to see D influencing C++ development. I thought this anonymous comment about his pacemaker example was funny: "I surely hope you are talking about the programmer device for pacemakers and not the actual pacemaker inside someone's body. I worked for Intermedics until we got bought by Guidant on Monday and shut down on Tuesday. We had a project at that time that was being written in C++ and it was likely the compiler did not even have a standard year attached. I was never comfortable with that project given the really ugly tendencies of both compilers and software engineers to do awful things in code. The ugly things in compilers was behind the push for standards in both C and C++! The actual pacemaker likely has so little memory and power that it would be very strange to be written even in C (but more likely after 16 years of improved technology). It is more likely that the pacemaker code is still being written in assembler and the whole program is likely less that a few thousand lines. I am confused by your assertions. It would be *very* unlikely once a device is released to production that the compiler would be changed to a newer version. Medical device software that is done properly must undergo massive amounts of verification and validation before it is released. Changing the compiler would require that the compiler itself be exhaustively validated against the old compiler and then the verification and validation of the device would be required to be repeated. That whole process would likely cost hundreds of thousands of dollars (perhaps even a million) in engineer/clinician time to verify that the device is still safe and effective. It is very likely that all properly managed medical device companies continue to use the initially validated compiler for a *very* long time. As an example, when I worked in arthroscopy, we used the same C compiler for our micro-controllers for 6 years before we even entertained updating to the very latest. And arthroscopy is not nearly as mission critical as pacemakers. If the company you did contract work for was not that diligent, I would sure like to know who it is so I can tell my Dad to decline to use that manufacturer's pacemakers."
Nov 23 2015
parent Paolo Invernizzi <paolo.invernizzi no.address> writes:
On Tuesday, 24 November 2015 at 06:31:17 UTC, Joakim wrote:
 I thought this anonymous comment about his pacemaker example 
 was funny:

 "I surely hope you are talking about the programmer device for 
 pacemakers and not the actual pacemaker inside someone's body. 
 I worked for Intermedics until we got bought by Guidant on 
 Monday and shut down on Tuesday. We had a project at that time 
 that was being written in C++ and it was likely the compiler 
 did not even have a standard year attached. I was never 
 comfortable with that project given the really ugly tendencies 
 of both compilers and software engineers to do awful things in 
 code. The ugly things in compilers was behind the push for 
 standards in both C and C++!

 The actual pacemaker likely has so little memory and power that 
 it would be very strange to be written even in C (but more 
 likely after 16 years of improved technology). It is more 
 likely that the pacemaker code is still being written in 
 assembler and the whole program is likely less that a few 
 thousand lines.

 I am confused by your assertions. It would be *very* unlikely 
 once a device is released to production that the compiler would 
 be changed to a newer version. Medical device software that is 
 done properly must undergo massive amounts of verification and 
 validation before it is released. Changing the compiler would 
 require that the compiler itself be exhaustively validated 
 against the old compiler and then the verification and 
 validation of the device would be required to be repeated. That 
 whole process would likely cost hundreds of thousands of 
 dollars (perhaps even a million) in engineer/clinician time to 
 verify that the device is still safe and effective.

 It is very likely that all properly managed medical device 
 companies continue to use the initially validated compiler for 
 a *very* long time. As an example, when I worked in 
 arthroscopy, we used the same C compiler for our 
 micro-controllers for 6 years before we even entertained 
 updating to the very latest. And arthroscopy is not nearly as 
 mission critical as pacemakers.

 If the company you did contract work for was not that diligent, 
 I would sure like to know who it is so I can tell my Dad to 
 decline to use that manufacturer's pacemakers."
Well, I've actually wrote some code that's running inside this [1], a device that I think it is at least as critical as a pacemaker... Well, I do take the view, but the situation is not so dark as he describe. [1] http://www.transenterix.com/company/corporate-news-events/video/ -- /Paolo
Nov 24 2015