That is what everyone means when they say "run out of oil". Read it as "run out of oil worth extracting". We're obviously not going to spend 2 TJ of energy to extract oil that contains 1 TJ of energy.

This assumes we use the oil purely due to its energy content. Which is true in some sense or the other, but unless you can replace all uses of oil derivatives with either synthetic sources (that don't cost significantly more energy to create than the oil extraction would) or something different altogether (e.g. in the "producing electricity" use case).

And even then, who knows whether dumping spare electricity into oil wells instead of e.g. batteries or pumped storage hydroelectricity might remain profitable.

My point is, it's not necessarily that obvious, and we better not wait for people to stop running out of ideas to make a profit on fossil fuels.

There are people willing to extract despite negative energy efficiency, especially in underdeveloped parts of the world. Societal development requires a particular amount of energy expenditure per capita to progress.

>And last, people compare it to languages like Rust or Go since they consider those are "innovative"

No, they do not. The entire appeal of go is that there is zero innovation at all. It is the most plain, boring, ordinary language around. It does absolutely nothing different or neat or new or special. Instead, it focus on being simple, easy and fast. Just like PHP apologists keep claiming about PHP. The difference is go was developed by competent software developers, so it isn't a broken, buggy, inconsistent mess.

>PHP was created for website development

And yet it is outclassed for that purpose by general purpose languages like go.

>and in that area neither Go or Rust are even close to matching it in terms of maturity.

Age is not maturity. PHP is old. It is less terrible than it was 20 years ago, but it is still worse that any other language except javascript.

you are claiming the developers of PHP are incompetent? bold claim, coming from a throw away.

Some people simply have reasonable standards. I tried for years to hire a PHP dev. I never found a single one. I found tons of people who had PHP on their resume, and not a single one of them was anything close to competent. PHP only makes hiring easy if you don't care about the quality of work that gets done. I can hire a million PHP monkeys, but everyone who has the right combination of intelligence and conscientiousness to be a competent software developer moves on from PHP after 2 or 3 years as they discover what it is.

You can hire "good programmers" and ask them to write PHP - Facebook does

Facebook, Slack, Etsy, the list goes on. In fact, I think all thosr companies are actually hiring right now, unlike many of those advanced non-PHP shops.

Many employers use php because it allows keeping salaries down, though. So your advice would not work for those.

The parent post complained about the quality not salary level of PHP programmers, though. The parent wants a quality PHP programmer, you want to keep salaries down - there is an acceptable tradeoff, somewhere.

The parent poster didn't complain about anything, he pointed out the flaw in the grandparent poster's claim.

I doubt that Facebook tries to hire Hack devs off the street. No one uses Hack except FB. They hire PHP developers and teach them Hack in boot camps.

The point being, you can hire good php devs.

Facebook probably just hires super bright developers, not PHP developers per se. Those developers can pick up Hack in a couple of months.

Normally, bright developers acquire a new language* within a few weeks, if they already know the paradigm from another language. Hack is OOP, and so are many others, so I would expect a bright developer to learn hack in 2-3 weeks, not months.

Heck, I just read the docs of hack for 2 hours, and I already got a good sense of what the language can do. I worked with PHP internals, and a bunch of other languages in my career.

* as language we define the language, its syntax and semantics, not any other library or the ecosystem. And yes, the standard library is still just a library. Knowing a list of functions and parameters does not mean knowing a language.

Well Ruby is OOP, is it gonna be super easy for me to get a java web development job? All things being equal a hiring company will go for someone with 3 years java experience over my 8 years Ruby experience. Facebook has no choice since no one knows their language, but most other companies will hire someone with the particular experience of their stack if possible.

No, facebook doesn't. The good programmers facebook hires don't work on the legacy PHP code. They do stuff like sigma. Also, I am not describing a problem, I am pointing out that their perceived problem doesn't exist. If I can hire a good programmer and make them write PHP, I could also hire the good programmer and let them write in a tolerable language, so the mythical "its easy to find PHP devs and impossible to find anything else devs" claim is out the window.

Are you trying to hire vanilla PHP devs or framework PHP devs?

In my previous company (based in Paris, FR) we had a very hard time getting skillful PHP devs, even if there were a lot of candidates.

I spent 17 years going through that. I can't say I recovered my optimism, but I stopped being cynical and am now realistic (which people tend to think is pessimistic), but without it being negative. Get off the drugs, move into the country and eat a lot of peaches. Technology will never be enjoyable again, and that's a good thing. Grow your own food, make your own tools, build your own furniture. Use your intelligence to make your life better instead of helping greedy people try to shove more ads in front of people.

And skip the middle man and build your own software product. Then there will be more sane software companies to work for.

>can't we simply compare the populations that consume a lot of omega-3 ( fish primarily ) vs those who don't?

That's how we came up with the hypothesis in the first place. But that's all such a study can do, give us a hypothesis. There are too many confounding factors (smoking rates, alcohol consumption, poverty, environmental toxins, ethnicity, other dietary differences, etc) to answer the question of omega 3 relevance. We need studies like this one, only with objective measurements instead of asking subjective questions to draw conclusions.

I don't think it is harsh enough. The comment is devoid of substance and wrong.

care to detail how

    do
      x <- a
      y <- b
      return (f x y)

isn't basically imperative syntax ? hint: if you can get from it to C (or pascal or python or whatever) simply by adding a couple types, semicolons and replacing operators, it's C.

How is that any more or less imperative than the standard Haskell syntax:

    let x = a
    y = b
    in (f x y)

? Which in turn is very much like OCaml syntax or plenty of other functional syntaxes.

IIRC that desugars to a >>= (\x -> b >>= (\y >>= return (f x y))) . I don't write Haskell, so that might be slightly off

This could be doing any one of:

- flatmapping over lists

- doing a computation with Maybe types, producing Nothing if a or b are nothing

- doing IO

- managing futures

- pretty much anything, actually

Don't confuse 'x <- a' with assignment, or 'return' with returning a value.

Another way of looking at it, (f x y) might be invoked:

- once

- never

- more than once

- later

> hint: if you can get from it to C (or pascal or python or whatever) simply by adding a couple types, semicolons and replacing operators, it's C.

hint: you are wrong.

Because it’s one big expression. A C version would have statements.

There is no such thing as imperative syntax. Syntax is completely orthogonal to being imperative, which is semantic not syntactic.

It isn't "almost C-like syntax", unless you define that to mean "if I do any amount of search and replace I can make it into valid C code that has completely different semantics". "x <- a" in haskell is not at all the same as "x = a" in C.

And that isn't the reason I said your comment is wrong. Your comment is wrong because do notation is not the result of "40 years of research in functional PL", nor is it an accomplishment. It is simple syntactic sugar that didn't come from research at all.

Your comment could be accurately summarized as "I would like to express how smug I feel for not learning something".

> Your comment is wrong because do notation is not the result of "40 years of research in functional PL"

are you kidding me ? if a 2016 paper from Simon Peyton Jones isn't research then what is ? (https://dl.acm.org/doi/pdf/10.1145/3241625.2976007)

Of course, the only thing 40 years of PL research resulted in was the do notation. I was under the impression that the do notation was syntax sugar for any kind of Monad - List, nondeterminism, asynchronous iO, parser combinations, exceptions etc. Stuff that appears as language features in other languages, but are just a library in Haskell.

But your chuckle has shown me that this code is just plain old C, with links to documents you haven't even read. Thank you for enlightening me, great chuckler.

I am honestly amazed at such an incredible bad reading of my comments. Next time I'll just write a phd chapter instead as apparently this is what is needed sometimes.

You are not capable of writing a PhD chapter. You lack the basic scientific thinking or method required. I suggest you focus on your core competency - chuckling.

Here is some basic reading material for you. Lets see if you can follow this

https://hackage.haskell.org/package/async-2.2.2/docs/Control...

   do a1 <- async (getURL url1)

      a2 <- async (getURL url2)

      page1 <- wait a1

      page2 <- wait a2

This implements async await in Haskell via a library using Monads. Hint: you cannot do this in C via any library. You need to modify the language. If you are uneducated about Monads, you might think this is similar to some kind of C code. It is not!

Here is the same do syntax being used to parse source files instead of doing async/await IO. Yes this parser will also perform backtracking etc, which will not be obvious to anyone who thinks this is some kind of transliteraton of C

https://markkarpov.com/tutorial/megaparsec.html

mySequence :: Parser (Char, Char, Char) mySequence = do

  a <- char 'a'

  b <- char 'b'

  c <- char 'c'

  return (a, b, c)

Hint: If you want to do something like this in C, you use yacc/bison, a parser generator tool - there is no library. And it is fucking ugly.

Hint 2: There are monads for parsing, async IO, exceptions, nondetermenism, monte carlo .........

Hint 3: The parser libraries are 25 years old.

Hint 4: Monad libraries represent less than 1% of PL research over the last 40 years.

Hint 5: C# LINQ is basically a Monad.

Hint 6: When confronted with something you don't understand, it is better to be quiet instead of opening your mouth and advertising your ignorance.

Hint 7: If your conversational style consists of chuckling and providing "Hints", be prepared for receiving a taste of the same medicine.

I am still humbled by your persistence in looking for deep truths in forum comments.

> This implements async await in Haskell via a library using Monads. Hint: you cannot do this in C via any library. You need to modify the language. If you are uneducated about Monads, you might think this is similar to some kind of C code. It is not!

it's still pretty much

> almost C-like syntax once again.

at no moment, not a single time, did I say in any way that I was talking about semantics but this is apparently a hill you wish to die on... so, by all means have fun !

Maybe you'll be more convinced by the exact text of the paper that introduced do-notation though ?

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.11....

let me quote it :

> Using monads gives functional programming an imperative flavour. Gofer supports a, so called, do notation which makes this imperative flavour more apparent.

or, let me rephrase that whole thing for you in a language that you seem to speak quite fluently:

    class BasicallyC m where
      (>>=)  :: m a -> (  a -> m b) -> m b
      (>>)   :: m a ->  m b         -> m b
      return ::   a                 -> m a
      fail   :: String -> m a

    class BasicallyC m => ImperativeFlavour m

You very conveniently skipped that you cant build async /await in C without modifying the language.

You also failed to show how parser combinator grammars such as yacc/bison/BNF forms are basically just imperative code.

Monads model effect systems; not imperative code.

I am impressed by your ability to argue about stuff you know nothing about, and linking to papers and documents you can't even read. Have you considered running for US president?

> You very conveniently skipped that you cant build async /await in C without modifying the language.

but async / await is semantics, not syntax, thus completely irrelevant to the conversation. you want an example of building async / await into the syntax of C as a library ? tada !

    void* async(...) { return NULL; }
    void await(void* ptr) { }

    int main(int argc, char** argv) { 
       void* handle = async(printf("foobar"));
       await(handle);
    }

or maybe you would prefer the more "modern" version, still compatible with pure C89 syntax though ?

    #define async
    #define await (void)

    int main(int argc, char** argv) { 
       auto x = async printf("foobar");

       /* wow, you can even compose it ! */
       auto y = async 2 * x;

       await x;
    }

please go on, this is super entertaining !

Wow man! your async-await code actually does nothing! I don't think I have argued so much and so far with an idiot!

Have you considered reading it?

would you consider showing me a previous appearance of ApplicativeDo (not do notation of course, that shit is almost older than me) in scientific literature before that paper ? As surely, if a concept had existed for a long time it would be more relevant to start by the original paper that introduced it ?

Farmers haven't been hard working in decades. There's a reason most farmers are obese, sitting isn't hard work. Even when I was a kid everyone around here still did square bales of hay and tossed them around by hand. Now it is 100% round bales handled with a loader. As everything got bigger, there was simply no possibility of human involvement because people can't lift 800 pounds.

It would just shift more to healthier meat like beef instead of so much chicken. Beef production requires no large tractors, seeders, harvesters, etc. You are just letting cows eat grass. Chicken production is basically an extra step in corn production, so it needs all the equipment involved in corn production.

I think that is actually a very harmful myth that huge multinational corporations want to keep in people's minds. We produce less food per acre with modern industrial farming, not more. They optimize for total cost, not for land use. We could feed more people than we feed now just fine without any modern equipment, it would simply create lots of jobs.

Maybe I should edit the comment to say "... feed as many people as we do at the cost that we do..." because while it's true we can gain the same land productivity with less advanced equipment, it would seem that the total labor cost to do so would make overall food cost very high. Not to mention difficulties in hiring the quantities of people needed. I'm definitely not any sort of knowledgeable expert here, just thinking aloud.

We currently have massive unemployment, and low quality, toxic food. I think rather than giving everyone a "basic income" to purchase that inferior food, we should give them jobs producing better food, and the overall increased price of food wouldn't be any worse than the cost of UBI.