I disagree with the concern, because obviously making Free Software easier for non-technically inclined people to use does not make the software harder for technically inclined people to use. This is strictly an issue for proprietary software.
> This is strictly an issue for proprietary software.
it really isn't, as Google Chrome and Chromium shows there's no clear dividing line in the real world. Linux isn't developed by Bob the free software enthusiast, take a look at the code contributions to the kernel.
Overall I'm also in favour of driving linux adoption because it's still a better world but the idea that this has no spill over effect on anyone else is wrong. It's a fiction to think that Linux, just like a browser is anything but a collective project with most development driven by very few organizations who also have commercial or proprietary interests.
there's not any genuine forks. They're all dependent on Google, see Vivaldi last year announcing they'll drop manifest v2 support. They're all pretty much cosmetic reskins. Whoever puts up the money for development makes the choices, regardless what license you slap on it.
And if there was a drastic mainstream adoption of linux, whatever implications that has for development focus, it would affect everyone because nobody is going to run a sincere kernel fork.
I don't have a specific thing to back it up but from my exercise science degree(in another life) men are at a greater risk for pretty much all heart/cardiovascular problems.
> A side effect of proposal #23367, which is needed for determining upper bound stack size, is guaranteed de-virtualization when there is only one Io implementation being used (also in debug builds!).
> In the less common case when a program instantiates more than one Io implementation, virtual calls done through the Io interface will not be de-virtualized, as that would imply doubling the amount of machine code generated, creating massive code bloat.
I wonder how massive it actually would be. I'm guessing it really wouldn't be all that massive in practice even if it of course is easy to create massive examples using ways people typically don't write code.
If takes two or three arguments, but never one. The condition is the one made syntactically obvious in most languages, the consequent is another required argument, and the alternative is optional.
They aren't talking about C and its descendants in particular, but more generally. For example in Haskell and Scheme there is only an if function and no if statement. And you're welcome to create an if function in any language you like and use it instead of the native syntax. I like to use an if function in PostgreSQL because it's less cumbersome than a case expression.
So in the abstract, if is a ternary function. I think the original comment was reflecting on how "if (true) ... " looks like a function call of one argument but that's obviously wrong.
this is not quite right. haskell and scheme have if expressions, not if statements. that's not the same as if being a function. if is not, and cannot be, a function in scheme, as it does not have scheme function semantics. specifically, it is not strict, as it does not evaluate all its subexpressions before executing. since haskell is non-strict, if can be implemented as a function, and iirc it is
> since haskell is non-strict, if can be implemented as a function, and iirc it is
"If" can be implemented as a function in Haskell, but it's not a function. You can't pass it as a higher-order function and it uses the "then" and "else" keywords, too. But you could implement it as a function if you wanted:
if' :: Bool -> a -> a
if' True x _ = x
if' False _ y = y
Then instead of writing something like this:
max x y = if x > y then x else y
You'd write this:
max x y = if' (x > y) x y
But the "then" and "else" remove the need for parentheses around the expressions.
Depends on the language! If "if" wasn't a keyword, in Ruby that would be calling a method that takes one positional argument and one block argument, such as `def if(cond, &body) = cond && body.call`. In PureScript that could be a call to a function with signature `if :: Boolean -> Record () -> _`.
But I assume the comment you were replying to was not referring to the conditional syntax from C-like languages, instead referring to a concept of an if "function", like the `ifelse` function in Julia [1] or the `if` form in Lisps (which shares the syntax of a function/macro call but is actually a special form) [2], neither of which would make sense as one argument function.
Assuming the / was meant to describe it as both an HTTP API and a JSON API (rather than HTTP API / JSON API) it should be JSON/HTTP, as it is JSON over HTTP, like TCP/IP or GNU/Linux :)
reply