tored

How are going to mine resources that doesn’t exist? There is not enough of the metals needed to go full renewable.

The winning proposal of referendum about nuclear power in 1980 never said anything about when the shutdown should be, that was something the politicians added afterwards. What it said was that shutdowns should be done as long it doesn’t undermine employment and welfare.

And because these shutdowns have radically increased electricity prices with unemployment as a result, thus both undermining employment and welfare, it actually violates what the winning proposal stipulated in the referendum.

Furthermore the tax on nuclear power was massively increased three times as consequence of influence of the two green parties, Center party and the Green Party, 2006, 2008 and 2015, and the same time subsidizing renewables, thus making nuclear power not economically sustainable. There was even a referendum in parliament about these latest shutdown with only one vote difference. No, it was intentional.

session_* can be misused if developer is not careful be closing the session as soon as possible to avoid being open during the entire request (mostly a problem for the default file session storage).

Personally I store a token in in my own cookie and then read from whatever storage. No need to correctly implement SessionHandlerInterface (which can be tricky to get right)

Agree, if you examine Swedish modern history since the industrial revolution you will find that Sweden has always produced lots of startups (or the equivalent in the old days) with both low taxes and high taxes, with a welfare state and without.

High taxes and a welfare state do of course have some role to play (positive and/or negative), but as you say there other important parts that probably matter more.

One thing we can say empirically is that Sweden have had it difficult to create large sustainable companies from startups like it did hundred years ago, Spotify is a notable exception.

Writing cross platform desktop applications is series of compromises in the technical requirements you may have. You should prioritize each requirement from top to bottom. Then start removing requirements from the bottom and compare against available technologies, iterate this process you will find out what is truly important and what compromises you are willing to make.

Personally I searched for many years for the perfect GUI system, the unicorn, but never found any. By doing a stricter prioritization I came to the conclusion that writing in a modern language is overrated.

These problems were fixed in PHP 8.0 and 8.1

https://wiki.php.net/rfc/engine_warnings

https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_a...

Personally I prefer the opposite, I have managed many old projects (10+ years old) and I always prefer raw SQL over some outdated ORM that is hard to configure and finetune. With SQL I have access to one of the most powerful query languages in existence that can never be matched by an database layer written in general purpose language.

Raw SQL can be a bit problematic if it is spread out in the entire code base with little structure ("littered"), however that is relatively easy to fix by centralizing the queries with a repository pattern. It is much harder to fix an ORM ten years later.

Do we know why ORM's are popular? I don't think it has to do with that ORM's are good, rather that developers want to avoid SQL because lack of experience, but that is me guessing based on my prejudice (I was myself in that category as a junior).

I have written in the past why ORM's are bad https://news.ycombinator.com/item?id=27407690

How is hand rolled SQL queries something bad?

xdebug 3 has been released with great performance improvements.

https://php.watch/articles/xdebug2-vs-3-benchmark

And you actually can have xdebug installed without performance degradation if it is not automatically enabled on every request (think that was true for xdebug 2 as well). What you do is to send a special request payload to enable it when needed, can be done with a browser extension.

There is also phpdbg, shipped with php, it does not suffer from the same performance penalties that xdebug prior to version 3 had (not sure how it compares to xdebug 3). However it is a command line debugger only, it does not support remote debugging or IDE integration.

https://youtrack.jetbrains.com/issue/WI-21414

Now I don't know how your PHP code was structured, but in my experience there usually three types of mistakes done with error handling in PHP code

1) not properly checking return values from standard library functions

2) not checking correct last error level function after use of standard library function, e.g. json_last_error(), curl_errno() etc

3) different handling of old style errors vs exceptions

This is an unfortunate legacy of PHP, it is messy and error prone.

I'm not a golang programmer but to my understanding is that the golang compiler does not enforce strict error handling, if a function changes its signature to start returning an error when it previously didn't is not something the compiler will warn about. This is unfortunate too.

I never really been a huge fan of exceptions either, but the good thing about exceptions is that they are not silent by default whereas return values can be ignored and therefore errors can missed.

What I'm trying to say is that we need stricter compilers.

My personal style of coding in PHP to avoid hidden bugs is to code in defensive style, where the unhappy path is as important as the happy path, combined with strict type handling where I try to use the type system to detect bugs.

It depends entirely on what kind of immigration you are talking about, there are empirical evidence that certain type of immigration can be beneficial, but it also exist empirical evidence of the contrary, thus making a general claim is not possible without looking at the specifics, i.e. which immigrant group to what country and in what time.

> Japan doesn’t like immigration at all.

Thus you agree with me that integration is huge cost, because immigration will create big friction within the Japanese society and that is a cost.

It is interesting that you admit that Japanese society is anti-immigration and yet you push this as solution to their problem. That is elitism.

> You still also need low skilled immigrants

Another alternative is to increase salaries, but immigration does the opposite, pushes wages down, especially for low income jobs.

Problem is that low income jobs is net loss in payed taxes in high tax welfare states, because the tax they put in is lower that the benefits they get, thus the more low skilled immigrants you bring the higher the taxation must be, but too high taxes will have a negative effect on general employment and business.

Believing that low skilled jobs is something beneficial for an advanced society is like believing that handing out shovels to dig holes is net beneficial in world with excavators.

What a society becomes rich on is processing either goods or services to something of higher value and preferably in multiple steps, not flipping burgers at minimum wage.

Oh, so you want low skilled immigration to Japan like in Europe, not high skilled immigration. How would that help anything?

Sweden has about ~5 physicians per 1000 people, largest migration groups to Sweden, Syrians has a rate about ~1.3, Iraqis ~0.7, Indians 0.9, Pakistani 1.1, Somalis ~0.02.

And then you have other important public skilled professions like teachers & educators, law enforcement, health services etc.

Thus low skilled immigration increases shortages on high skilled professions.

Then we should reform our economic system, endless growth is not viable, especially if you take into account climate and environmental issues. Again, band aid solutions does not work in the long run. We need to adress the real issue.

If Japan went from the current child birth rate to same same rate as Hungary then Japan would be almost be at equilibrium, Japan has the same child birth rate as Hungary ten years ago before Hungary added a tax credit program for new families.

Hungary has increased their number of births per woman from 1.23 ten years ago to 1.55 today by giving tax credits for new families.

The thing is if the idea is that women should equally participate in the labour market then child births will decline.

Thus if immigrants already has or adopts the Japanese way of living then child births will still be low.

Or if immigrants have high childbirths then women will not equally participate in the labour market, therefore that family only has one or fewer incomes in a high tax society that is designed for two persons per family taxable income, thus that family will probably be a net loss for tax payers.

> Imo it’s a big reason the US eventually surpassed Europe

When was that?

If I'm reading the stats correctly for Japan

1960 94 million, ~50% labour participation rate for women, ~4 million child births, ~1 million abortions

Today 126 million, ~80% labour participation rate for women, ~800 000 child births, ~150 000 abortions.

There are other solutions of course, like automation. With technology we can do more work on less time, and that is something we have done since the industrial revolution. It is a bit bizarre that on technology forum this is not go-to answer.

Immigration is not one-stop solution to fix GDP because integration is huge cost that is rarely taken into account. And of course it doesn't at all address the real problem, that men and women no longer creates families.

This is typical of todays debate in the West, not solve the real issue, instead offer some sort of band aid solution and completely ignore the real issue.

Japanese is a population of about 126 million living on size of Norway, a country of 5.4 million inhabitants.

Interesting question, pike has a stable C API for creating C modules

Step by step instructions https://pike.lysator.liu.se/docs/cmod-step-by-step/

What is CMOD? http://wiki.gotpike.org/index.pike?page=PikeDevel/C%20Module...

Calling pike functions from within C/CMOD code http://wiki.gotpike.org/index.pike?page=PikeDevel/C%20Module...

example https://github.com/pikelang/Pike/blob/master/src/modules/Ino...

I guess it is more of packaging issue of using pike in that manner, perhaps this is something for the pikers to explore. Could be a great way to revitalize the language, the world could need a embeddable strictly typed C like dynamic language.

Good question, perhaps strictly typed dynamic C like language with an event loop and a large standard library.

- repo

https://pike.lysator.liu.se/development/git/

- git mirror

https://github.com/pikelang/Pike

- web mailing list

https://www.mail-archive.com/pike@roxen.com/

But yes the web page is stale, it has been for a long time.

One unfortunately thing is that the industry in general struggles with incrementally improve functionality within a product over time, this goes for product managers, project manager, software developers etc.

This is why everyone wants to make every decision up front, before you have enough knowledge about what you are building, with endless meetings instead of pushing it out and learn that way.

Software developers doesn't like it because that could mean large rewrites because of ripple effects.

Product owners fears that there won't be second chance to do things, thus try to cram in as much as possible early on.

Project managers fears it is going to be more expensive to revisit functionality instead of doing it once.

I noticed a sharp decline in quality when Netflix started with their own original content, some of it was good but most of it was mass produced low quality trash.

But it also an inherit problem with any movie streaming service that wants to have fresh content, you have to fill the content bucket with something and mass produced low quality stuff is both cheaper and faster to produce.

Yes I think so, Java(JavaEE?) did the same with jsessionid.

My proposal would be to let the community build a stdlib and after it is battle tested merge it with core PHP.

It has been proposed before to have PHP source shipped with PHP (and also the possibility mix C and PHP) and think that would be the best option.

One option could be to have slower evolved stdlib in core and a faster community version with composer.

Reason why I’m proposing to develop it outside of core is because a rfc based process is not necessarily the best approach to design a good & well functioning api (and empirically that is true).

It is better to deliver a complete stdlib (or major sub parts) as one or multiple rfc.

And by doing like this you allocate resources better, the few with knowledge about PHP internals can keep focusing on that while the community, a much larger group, can design a stdlib.

And PHP has done a lot of great work on making user land and stdlib on equal footing, so now you can implement strpos(…) to exactly match the stdlib version thanks to union types, similar argument parsing and using same type rules (type errors) between the too.

Only major thing I know of that differs when exposing an api, that is either from a PHP C extension or PHP code, is operator overloading.

A rfc proposal to add it was unfortunate declined, but I’m hopeful that on day it will be added in some form because of this reason, it ought to be possible to express the same intent regardless if it is from C or PHP.

With user land operator overloading we can implement object based primitives with methods instead of the current function based approach. And it could be possible to extend it.

Other nice things you could do is to implement safe and unsafe string handling to avoid injections.

With operator overloading the community can evolve the language without the need to evolve PHP itself.

Not necessarily, because you have to consider the entire lifecycle.

When doing frontend rendering you usually work against a REST(ful) API to fetch data, the idea is to reuse endpoints for multiple frontend components, because of this generalization you usually end up sending more data than necessary, not only between the database and the backend, but also between the backend and the frontend.

And not only that, you start doing JOINs over HTTP and JavaScript.

With server side rendering I can write an exact SQL query to render that component.

Why so many failed to answer this questions is probably due to multiple reasons, here are a few

1) Some programmers are just either too lazy or too arrogant to read the manual, thus bad programmers. As a senior programmer that has helped numerous juniors in their work, this is probably one of the most common mistakes I see, they write code without checking how the API works, or they ask me why something isn't working when it can be easily found in the manual. This is not specific to PHP and I have seen this in everything from PHP to C++.

2) PHP is dynamic language, similar to JavaScript, types were not something you historically bothered with, thus parsing to int is not something the community has a large shared knowledge about, similar how it is rare in JavaScript. However with the introduction of primitive type hinting it has become more common to do proper parsing, hopefully PHP programmers will learn eventually. Thus it is a thing with dynamic languages, not specific to PHP.

3) Why can't programmers find the filter_var method in the manual and/or in the standard library? This I considered as valid criticism of PHP, the standard library is not structured because of the C like flat structure and many of the stdlib functions are weirdly named, like filter_var, what is filter to begin with?

The solution is to build a better stdlib, not throw out the language. I think the community can build a well designed stdlib if PHP implements operator overloading. The performance issues is no longer valid, PHP 7+ has great performance, thus worrying about losing important cycles is not really true anymore.

PHP as a language works well to build good solutions, I have done so in many projects. The critique here evolves around the stdlib, that is not something new.

Above usage of filter_var is wrong, there is no need to cast $thing to int, filter_var already returns the filtered int or false on failure. The correct usage is therefore

    /**
     * Cast to int, fail if not a valid integer
     * @throws \UnexpectedValueException
     * @param mixed $thing
     * @return int
     */
    function as_int($thing): int                                                                                             
    {   
       $int = filter_var($thing, \FILTER_VALIDATE_INT);
       if ($int === false) {
         throw new \UnexpectedValueException("Value is not an integer.");
       }
       return $int;
    }

Thus the critique against PHP that is lacks a proper integer parsing function is simply not true, filter_var has been part of PHP since 5.2 released in 2006, over 16 years ago. filter_var works as advertised, because I use it almost every time i write PHP and that is to mostly to parse integers but sometimes also for other types. And I don't even wrap it with my own as_int function, using it inline with an simple if-check afterwards is actually cleaner. And if you prefer that filter_var returns null on failure instead of false you can simply add FILTER_NULL_ON_FAILURE as the third argument to filter_var.

And this is the recurring thing with PHP critique, vast majority of the time it just in imagination because nobody bothers to look it up.

https://www.php.net/manual/en/function.filter-var.php

stdlib will never change, because it would break every PHP project out there. Many of the previous deprecations as been relatively easy to handle, like switch from each to foreach, or make sure that you don't pass null to stdlib functions, but changing the stdlib itself would instead be a complete nightmare.

Remember that many projects out there needs to support multiple PHP versions at the same time, it would be extremely confusing if the stdlib started to do subtle changes between versions and also hard to properly handle and detect.

Like if you would swap $needle and $haystack for strpos(), it would be nightmarish to statically detect in an existing code base which is the correct order and quite hard for a human.

Introducing aliases is also a bad idea, there already exists aliases in the stdlib and they only add confusion when reading code, that would be true for new aliases as well.

Named arguments alleviates the problem with argument order in exchange for more verbosity.

What PHP could do is to introduce primitive objects, e.g. $str->substr(...), however that would not guarantee a well designed standard library either, because RFC:s and emails is not a good forum for designing API:s.

I think the correct solution is to implement operator overloading and let the community design a standard library/libraries. Because of the massive performance improvements of PHP the standard library is no longer required to be pure C, it can either be implemented in PHP or wrap the existing stdlib.