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.

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.

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.

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

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?

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...)

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.

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.

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."

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