ಠ_ಠ
61 karma · joined January 3, 2015
Having multiple hour outages makes me really want to go back to hiring a couple of physical servers in a rack somewhere.
It was better for a period after the fork, but the only guy working on it hasn't maintained it that well...there's a significant number of bugs in GraphicsMagick that have been there for years.
Nope, it's not polite, it's the most convenient thing for you.
> It’s certainly the most professional thing.
That phrase sucks. Whenever I hear it, I always interpret it as "Someone did something I didn't agree with, but I can't actually express a legitimate reason why they shouldn't do that."
e.g.
Programmer who never has any customer contact doesn't wear a suit to work - oh how unprofessional.
Someone has their job outsourced, can't be arsed to fly out to Bumfuck Nowhere to train the new people how to do his job - oh how unprofessional.
Customers of a conference object to giving their money to pay to listen to someone who thinks that a Monarchy would be better than Democracy, and that "Traditional sex roles are basically a good idea" - oh, how unprofessional of the customers!
If you have a legitimate reason to disapprove of someones actions you should be able to express it a lot more clearly than just calling them 'unprofessional'.
For the record - Moldbug/Yarvin wrote my favourite article on the internet: http://unqualified-reservations.blogspot.co.uk/2009/07/wolfr... But his lack of ability to see/predict the real world results of his actions, is totally consistent with his lack of ability to see the result of the policies he thinks we should be following.
And yes, people may be using their emotions to make a decision, rather than segmenting things perfectly and thinking about each of them separately with a coldly logical basis. Humans, eh?
You can't give read only Oauth access to private repos....it has to be read/write. Which means if you want to use online CI tools with those private repos....you've got to hope they don't either turn malicious, or they get hacked and have their keys copied.
1. Customer places an order.
2. SYN: Can I charge $30?
3. SYN/ACK: Yes.
4. ACK + SYN: Do it.
5. SYN/ACK: I am gonna do it.
6. ACK: I see that you're gonna do it.
Er.....that doesn't appear to solve anything, instead it just pushes the error state down a level; there's still an ambiguous state where #6 is sent and not received.
The client thinks the charge is going to take place, and so thinks the client will be charged, but the bank never gets #6 and so never makes the charge, aka distributed atomic operations are hard.
And as I'm usually on a laptop, having less continued CPU usage is a good tradeoff against having to press refresh when I'm going to do something in SourceTree.
https://aws.amazon.com/blogs/aws/amazon-cloudfront-support-f...
If someone dropped a 30kg piece of steel and it landed corner first, there's a decent chance of it just going straight through the foot.
Not using setter injection eliminates a huge class of bugs that occur when people try to use objects that haven't had all of their dependencies injected yet:
$user = new RegisteredUser();
// Any code that touches $user here will be bad
$user->setEmail($email);
Which is why people use library to do it for them - an example for PHP https://github.com/rdlowrey/auryn.
Which if you read it out, it sounds entirely natural "This is a function called foo, which takes some params, and returns a float". Most of the other variants don't read as naturally.
> Since that's how it's done in other languages and people would feel at home with it.
PHP doesn't need to copy the mistakes of other languages. It's got plenty of its own mistakes.
Strict types make it easier to reason about code, that the tl;dr version.
> To me it seems that Ze'ev's proposal would be even better for you - > it does the equivalent of the validation and conversion automatically > including with an error if it doesn't validate.
Rather than having int 'types' which we can reason about, it has int 'values' which are harder to reason about. Types can be reasoned about just by looking at the code. Values can only be reasoned about when running code. A contrived example:
function foo(int $bar){...}
foo(36/$value);
For the coercive scalar type proposal, this code works - except when it doesn't. This code works when $value = 1, 2, 3, 4 and breaks when $value = 5.
This is the fundamental difference; whether conversions between types have to be explicitly done by code, and so any implicit or incorrect conversion can be detected by static code analysis tools, or whether the conversions are done at run time, and so cannot be analyzed fully.
This means most of these errors will be discovered by users on the production servers. Strict mode allows you to eliminate these types of errors.
Yes, this means I need to add a bit of code to do the explicit conversion, but I just don't convert between values that much. Once a value is loaded from a users request, config file or wherever, it is converted once into the type it needs to be. After that, any further change in type is far more likely to be me making a mistake, rather than an actual need to change the type.
> Any idea why it was rejected so badly? Is it because the coercion rules are different from the rest of PHP?
At least in part it was because the RFC was seen as a way to block strict types; about half of the RFC text is shitting on people desires for strict types, which did not make people who want strict types be very receptive. If it had been brought up 6 months ago, there is a good chance it would have passed, or at least would have been closer.
Some parts of the proposal were good - other parts were nuts that were pretty obvious the result of the RFC only being created once the dual mode RFC was announced and about to be put to the vote, with a very high chance of passing.
* Good - "7 dogs" not longer being converted to "7" if someone tries to use it as an int.
* Bad - Different mode for internal function vs userland functions e.g. "Unlike user-land scalar type hints, internal functions will accept nulls as valid scalars." and other small differences. This is even more nuts than you might realise as it means if you extend an internal class, and overload some of the methods on the class, those methods will behave differently to the non-overloaded methods.
* Bad - Subtle and hard to fix BC breaks in conversion which are probably not right anyway. e.g. false -> int # No more conversion from bool true -> string # No more conversion from bool
It is a shame that the discussion became so contentious. It would have been good if the conversion rules could have been tidied up, but all the time and energy had been used up the not particularly productive discussion.
Hopefully.
> How does putting (int) before the arguments to function help anything?
It wouldn't. Anyone who is casting from an unknown type to an int by using just `(int)` is doing something wrong in my opinion.
Even in web-based applications there are at least two layers of code: i) One where the type of the values are unknown and they are represented as strings. ii) One where the types of the values are known.
At the boundary between these two layers you should have code that inspects the strings that represent the input values, check that they are acceptable, and convert them to the desired type. If the input values cannot be converted to the desired type, the code needs to give an error that is both specific to the type of error so that a computer can understand it, as well as provide a human understandable explanation of why the conversion was not allowed.
The reason why I want strong types is that I never, ever want to blindly cast from one type to another. The decision about how to convert from one type to another, should always be made at a boundary between areas of the application where types are known, and the areas where the types are unknown. I always want to be forced to make that decision in the right place, using code that gives useful errors and messages, rather than having the value coerced into the desired type.
tl;dr I won't use (int) to cast, I will use something like the code below.
cheers Dan
function validateOrderAmount($value) : int {
$count = preg_match("/[^0-9]*/", $value);
if ($count) {
throw new InvalidOrderAmount("Order amount must contain only digits.");
}
$value = intval($value);
if ($value < 1) {
throw new InvalidOrderAmount("Order amount must be one or more.");
}
if ($value >= MAX_ORDER_AMOUNT) {
throw new InvalidOrderAmount("You can only order ".MAX_ORDER_AMOUNT." at a time.");
}
return $value;
}
function processOrderRequest() {
$orderAmount = validateOrderAmount($_REQUEST['orderAmount']);
//Yay, our IDE/static code analyzer can tell that $amount is an int if the code reached here.
placeOrder($orderAmount);
}Other people would like to use PHP more as a general computing language.
Having optional types takes nothing away from using PHP for simple web pages, but does make it easier to right analyzably correct programs.
The fact that the founder of a language doesn't want to see it grow is quite depressing.
function foo(int $x) { // x is guaranteed to be an int. }
The type-hinting for scalars has two modes:
* strict - the parameter passed to the function must be of the exact* type. * weak - the parameter passed to the function will be converted to the correct type.
The strictness depends on what mode PHP was in when the function was called. This is the right choice as it:
* Allows library authors to write their code in either strict or weak mode.
* End-users to write their code in either strict or weak mode. Or even without using scalar type-hints.
* End-user to be able to choose when they are writing their code do they want their variables to be converted to the type expected by the library automatically, or do they want PHP to give them an error if they accidentally pass the wrong type of variable to a function that is expecting an int.
*except for some widening rules, e.g. you can pass an int where a float is expected, as ints can be converted into float without data loss (for ints less than 2^53).
And also the jump from 5.4+ to 7 is probably smaller than the jump from 5.2 to 5.3.
Although I think the PHP project does need to support versions for longer, the adoption rate of 7 is going to be quite rapid due to the low barrier of doing it, and the massive performance and language gains.
Having an optional mode per file allows:
People who want to write code with strict types can do so. People who want to write code with weak types can do so. People who want to write code without these new fangled types can continue to do so.
All without any issues of compatibility between running code on the current version of PHP and what will be the next one, and without any compatibility issues for libraries that are solely written in one mode, being used in applications that are written in the other mode.
\o/
To be honest, I'm completely in the strict camp - but it's awesome that we've gotten a solution that should allow everyone to use the mode they want, without splitting the PHP ecosystem.
This is explicitly listed as off-topic:
Questions asking us to recommend or find a book, tool, "software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it."
What is Stack Overflow's goal
-----------------------------
To be a large repository of reasonably correct answers to small technical problems, where there is only one reasonably correct* answer. Everything else is considered off topic, and unfortunately not a good fit for the site, due to the lack of tools to manage other types of questions
Although there are lots of other things that could be asked and answered, if they are out of that scope then they are considered off-topic and should be closed, according to the people who own StackOverflow. They're closed, not just to annoy people who want those other types of questions answered but because SO really lacks the tools to manage the answers to those questions reasonably.
For example the question "how do you install and configure nginx on different operating systems" is definitely a question that could be asked. However it would require a massively long answer, without a provably correct answer, with different approaches based on how you prefer to configure stuff. i.e. not a single probably correct answer.
Questions that ask for a recommendation for which library to use don't also meet the criteria of having a single reasonably correct answer. Which library you should use depends on lots of factors, and there's probably several, if not a hell of a lot more, possible libraries to use.
Also, questions like that invite debate, multiple answers, spamming by companies trying to promote their software etc. Although people might like to ask all sorts of questions SO have decided to try to limit the number of off-topic questions.
But hasn't the goal of being the large repository of answers already been achieved?
-----------------------------------------------------------------------------------
Yup, which is why StackOverflow is a considered a shit-show by people who used to find it very useful. If I had to guess, I'd say that something like 95% of all questions that are 'on topic' have already been asked and answered.
Although I've been using it a while, it's just incredibly rare for me to find a technical question that would be on topic for SO, that doing a google search for doesn't have an answer on SO in the top 5 results.
I think the people who run StackOverflow are either morons or have business reasons for not dealing with this problem.
Although the 'find me a library' questions are off-topic they aren't really a big problem - what is a big problem is just the same set of questions being asked day in, day out by people who are too stupid to be able to use Google to find answers to questions like "Q) Why is my compiler saying there is a syntax error on this line?" "A) There's a syntax error on that line."
The vast majority of people who are asking questions on StackOverflow are people who either read their compiler's error message, or do a google search - so it's really unlikely that they're going to spend time trying to understand the ethos behind StackOverflow or spending much time formulating a short, self-contained, correct example.
Because it's so easy for people to sign up to StackOverflow it only takes people a minute to post their badly formed question, which leads to the current torrent of the same questions day in day out. Without increasing either the 'cost' of asking a question or other barrier to prevent people who fail at using google, then it's inevitable that SO will continue to be besieged by bad questions.
-------------
As I said, I think the real problem is that the vast majority of on topic questions have already been asked. The site needs better tools for finding duplicates or expanding into a wider set of questions, for which some answers will be longer, non-authoritative answers which just currently aren't a good fit for the site as it currently exists.
The current system lacks lots of tools that would be required to manage questions and answers that are currently off-topic. Personally I'd prefer it if they improved the site to allow more wide ranging questions and answers and better filtering of 'questions' (e.g. why is the only tool available to mark a question as something that is asking for a recommendation of a library to close it? Why can't we just tag it as 'find me a library' so that people who are interested in answering that can answer it?
*Note - even if an answer is provably incorrect, it won't get deleted unless it's downvoted into oblivion. Which leads to raising of eyebrows when answers to security questions have wrong answers that have been voted to 40+