przemo_li

copy files deploy

That one is not great, unlike first two points. For one, larger bespoke programms need CI (and would benefit from CD). There is linting/type checking/testing to be done.

Secondly, "copy files deploy" is cheating. Somebody else did the job (hoster) and we are claiming that it is somehow benefit of PHP itself. Well? Did hoster do nothing? Really nothing at all? Nope. On top of that. Performant set up for PHP nowadays do not look that much differently then say, setup for Python.

Two first points are very good. Shared nothing architecture preclude existence of subtle bugs. While multi-threading in mutable, imperative code is the definition of subtle bugs. Those two keep PHP relevant and even on top of it's game (in certain domains).

As a PHP developer who did some nice parser to get strict schema & data validation out of XMLs of potential fluid (over time) structure, I can assure you that PHP do not bring any ergonomic solutions to the table.

It's possible and even very probable that PHP devs... stolen plenty of ideas from Haskell just to write "utility" libraries with witch they could write those parsers/analyzers/linters you are talking about :)

However, I also can't see how PHP could be used to efficiently re implement that spam library Facebook developed.

There whole promise lies on separation of effort into two teams: * spam engineers write pure code that happily merges data from different sources * backend engineers write integrations with Facebook systems and optimization passes over code spam engineers wrote to make sure that most optimal use of costly I/O was made

PHP brings nothing, literally nothing to the table here. While Haskell have all the mechanisms already built in.

Your argument about PHP sadly boils down to "its all Turing complete anyway".

You have just started that Java isn't as good but since it isn't, it shouldn't be judged so hardly and thus concluded that Java is as good as any (when using softer requirements just for Java)

I also think that explicit threadpool isn't the same thing as implicit one. But that's very minor issue here easily solvable by different api for parallel method

That's quite strange. Rust is system level language.

Most web stuff need no memory management and can happily live with GC or even with giant memory footprint and reboot once a day.

Ruby is direct competition. One of two PHP major web frameworks borrowed everything they could from it. Even PHP is on Ruby bandwagon .... XD

PHP have nice libs as extensions for those data structures. It's std variants that should be avoided.

You really have to stop assuming "intellectual superiority" when people talk about more advanced / less advanced stuff.

Go have limited capabilities type system. C have limited capabilities type system. Both are quite successful. If talking about C I didn't shown "intellectual superiority", maybe it would be incorrect label if I where to talk about Go?

Actually, what killed both is market size.

Internet boom === small simple apps where emphasis is either on looking good or being very responsive.

That meant that vast majority of developers where not in a market for rich GUI stuff, but for better CSS and smaller size.

OTOH desktop never rewarded simple apps. Distribution and marketability asked for more features exposed via GUI, thus most developers where OK with bigger in scope GUI stuff.

As for "next browser breaks your stuff" excuse, I think it wasn't true for a very long time now. Include polyfills, css defaults reset, do transpiling into less features and you are good to go.

OTOH, web underwent multiple groundbreaking shifts in computational models. This is why complex but somewhat encapsulized/localized Angular/Ember won over spaghetti inducing predecessors and why truly encapsulated/localized Reacts eats old Anguler for breakfast.

One last point would be about crazy stuff in programming languages / programming paradigms that was already available in 60's and 70's at least as a statements of need. Those made for very stable platform on which GUI ecosystems could be build. Relative instability of JS with generational changes can explain why it gets a new ecosystem every few years.

math: I found out that if your operation is XYZ then ABC nobody: hurray! ... few decades latter programmers: how the f* do we do paralle? math: ... programmers: shut up! NO! NOOOOOO!

Hey.

PHP do have its great niche.

Namely it's the only programming language where whole ecosystem lives and dies by the "build and burn the whole world on each request" mantra. It have significant advantages compared to other models of computation. (Granted even PHP devs often misplace "developer friendliness" of PHP, so you are not alone ;))

Typescript can be used for type checking. Disclaimer: I'm not familiar with jhall to know if it does or requires something inexpressible in Typescript.

It's not that simple.

You can easily design type system + compiler, which will have destructive "attitude".

It's no different from human interactions and how being "right" is not always "being constructive".

Best type systems have low mental overhead, can be selectively applied (to benefit when it's profitable, and to avoid costs where it's too costly), are humble, and are good companions by helping developer learn the domain space.

E.g. 1 there are good blog posts describing how you can write Haskell code by just asking Haskell compiler what type is needed to fit with the rest of your code. Step by step you fill in the blanks.

E.g. 2 there are good videos from Clojure about how you can follow types to implement a new idea.

Counter example: Neither 1) nor 2) is possible in C, and yet you pay hefty price mandated by C type system.

All 3 type systems have their own trade offs. Picking one that is most aligned with goals of your project does have impact :)

Read up on logical fallacies. You claim Haskell is how language and then point out how stupid it is. But we only have your word that Haskell indeed is how language. Show your proof ;)

Assess for yourself: https://en.m.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_4...

For me, it's easy enough to follow.

Because media report on events. There is someone saying not-yet-president groped them without permission? They can report on it. It's called free press.

Your comment make no sense what so ever.

Number of haskellers in some particular company (despite your attempt at labeling it as "largest" without providing any evidence), do not prove or disprove quality of haskell.

Number of developers implying perfection of language is also easily disproved. PHP or JS are good examples, where original languages become popular because of other factors.

Also, original poster was trying to sell us single data point as measure of popularity O_O

Getting good quantitative informations about languages is hard. But claiming that X devs hired in some company implies poor quality but X+10 would imply good quality is just ridiculous.

If you stopped using native loops / forEach how do you handle iteration for the sake of creating side effects?

+1 for including take/drop alongside map/reduse/filter

In that sense You should add disclaimer at the beginning of this blog post ;), that by "OpenGL" You mean both OpenGL without AZDO extensions and OpenGL ES.

AZDO is not about "single draw per frame" nor "single draw per scene".

Its "single draw per timeframe needed for switching state".

Difference bing that modern GPUs can "hide" state change behind big enough workload.

Also OpenGL as is right now, allow for explicit GPU/CPU synchronization. Multi threaded content creation (without needing any explicit api for it).

What it lacks are: * Requirement for caching shaders. (Quality of implementation) * Requirement for offline shader compilation. (Quality of implementation) * Intermediate representation (so that mundane task like elimination of dead code happen ahead of time) (Specification) * Having all that good stuff in core (Specification) * App devs moving to Core Profile (thats us...)

So OpenGL as is now, is quite close to solving all Your problems. And it do it somehow-less-somehow-more explicit then DX12/Mantle (as those focus on exposing CPU/GPU intensive operations, while OGL "AZDO" go ahead and propose solution to solve GPU/CPU bottlenecks)