You're using "corruption" in a different way than delichon. delichon is using it to mean government members take so much money for themselves that the bombs and the rest of the military stop functioning.
The video is a parody of marketing. If you want to criticize it for being irrelevant and that humor doesn't fit this situation, then sure. But saying it has similar marketing to consumer goods isn't really accurate.
Context for people who might not get the joke/parody: SST adding containers to their stack might be viewed as a "betryal" in a similar way to how some basketball fans felt when LeBron James switched teams, from Cleveland Cavaliers to Miami Heat. LeBron had a media event/interview called "The Decision" [1].
I love the clip of @dhh's keynote to engineer's "learned helplessness" to AWS and the cloud [2]. While SST + containers is very very different than DHH's Kamal [3], they both embrace containers without the paas service tax (heroku/vercel/etc) or the overhead of kubernetes.
Something interesting is that the top bar text (File, Edit, etc.) is a little bit blurry, but when I click on one of them (e.g. File), the drop down text (e.g. New Project) is completely crisp with no antialiasing.
Yeah, the company can tell the candidate the salary they will pay for someone in the role. If that doesn't match the candidate's needs then the process stops. If the candidate's performance during the interviews shows they can't function effectively in the role, the process stops.
Remember that people go by what others do. There is 0 penalty for lying about the fact that the number is not negotiable and so recruiters will do that often. So job applicants are conditioned to try to negotiate even if told quite clearly that its the “final number”.
that is exactly how it's presented, I give my methodology and how I arrived at the number (market rate in munich + 20%) and then give the number with exactly this caveat.
>When "out" and "in out" parameters are distinguished, there is no need for the existence of constructors as a separate concept. Any ordinary function with an "out" parameter can be used wherever C++ requires a dedicated constructor. Instead of constructors, it is enough to have an identifier convention for functions that should be called by the compiler when you want implicit initialization or implicit conversions.
Why do we need "out" vs "in out" parameters for this? Why can't a function that returns the object work just as well? And "an identifier convention for functions that should be called by the compiler when you want implicit initialization or implicit conversions" seems essentially the same as constructors to me.
>Moreover, there is no need to care about "copy" semantics and "move" semantics or about temporaries which are or which are not generated by the compiler. It is easy for the compiler to always choose the best implementation without programmer intervention, when it knows the correct parameter modes for the functions.
How would I implement something like std::vector with deep copy and move support of its contained objects without writing copy and move constructors (or operators)? There needs to be code saying "allocate a new block of memory and copy all the elements to that new block", and code saying "just copy the pointer, and set the other pointer to null". Are you saying the implementer would still write that code, just not in constructors/operators? How is that better?
The big reason for `out` only is "I want to write here, but I don't care about the initial value." It's a more explicit version of the C++ `Foo& outFoo` output parameter paradigm.
> When "out" and "in out" parameters are distinguished, there is no need for the existence of constructors as a separate concept.
I don't agree with this. You can get I need to do things "post-init" with controlled types, or use a `return X : Thing do ... end return` block. Constructors help ensure invariants. You can make a type `is private` to prevent instantiation, only allowing creation via functions (sort of like Rust `new` associated functions), or initialization via an `out` param. It's OK but not perfect, but you can also tag on a `Type_Invariant` aspect if there are conditions which have to be met by a type. My big problem with Controlled types is that forces a type to be `tagged` (i.e. it has a vtable) which means it affects storage layout of values of that type, which isn't a problem in C++.
You can forbid copies by making something a `limited` type, but you'd have to write your own "Move" equivalent, and some of the containers have `Move` subprograms implemented to transfer contents. Limited types might elide the copy when returned from a function, but it's been a while since I looked at those rules.
In C++ or similar languages, where the function parameters behave semantically as either "in" or "in out" parameters, a function that returns an object must have already created somehow the object.
Therefore calling a function just adds a task of invoking a constructor also into the function, it cannot replace a constructor.
In C++, an object cannot be created by assigning a value to it, because the left hand parameter of the assignment operator is an "in out" parameter, like for any other function, so it is assumed that it already has a value of the type of that object.
Therefore an assignment operator must execute the equivalent of invoking a destructor for the target of the assignment, followed by the invocation of a copy constructor.
Attempting to assign a value to memory allocated but not initialized will attempt to invoke a destructor for an invalid object value.
The constructors are the only C++ functions that implicitly have a result which is an "out" parameter, not an "in out" parameter, like the other functions.
Because the memory where the result of the constructor will be placed is not initialized, no destructor must be invoked for it, so all will be OK.
All these rules about when to use constructors and when to use functions and the need to have duplicate almost identical in meaning functions for certain purposes, e.g. copy constructors and assignment operators, complicates a lot C++.
Any copy or deep copy operations would be implemented very simply, just by copying what needs to be copied.
There would be no need for "move" operations of any kind, which are just a trick to avoid the inefficient code generated by compilers when the semantics for some parameters is "in out" when what would have really been needed is "out".
Specifying that some functions are not normal functions, but constructors, or that some operations have "move semantics" is just an extremely complicated way to specify that some function parameters are "out", not "in out". Besides being hard to understand, these tricks only work in particular cases, instead of being able to specify the mode of any function parameter.
In a language with distinction between "in out" and "out", the mode for the result of assignment is naturally "out" and there is no need for the contortions of C++. In such a language a compiler knows when to invoke destructors and when not to invoke them and it knows when no extra temporaries are needed for computing a complex formula with objects.
>In C++, an object cannot be created by assigning a value to it, because the left hand parameter of the assignment operator is an "in out" parameter, like for any other function, so it is assumed that it already has a value of the type of that object.
While "the left hand parameter of the assignment operator is an "in out" parameter" is correct, I want to point out that
Foo f = CreateFoo(1);
never calls the assignment operator. It either calls the move constructor, copy constructor (only if the move constructor doesn't exist) or does copy elision (meaning no copies or moves, more on that below).
>In C++ or similar languages, where the function parameters behave semantically as either "in" or "in out" parameters, a function that returns an object must have already created somehow the object.
If the object is being declared at the same time as being assigned to, and the function's return instantiates the object, e.g.
Even if there isn't copy elision, usually move constructors (which is what will happen in the second example if the compiler decides to not do copy elision) are pretty cheap.
With Ada, if you want to call a function with an out parameter, doesn't the object for the out parameter need to be created before calling the function, and thus at least partially initialized? The article says "Non-scalar values like pointers are always initialised.'
>Therefore an assignment operator must execute the equivalent of invoking a destructor for the target of the assignment, followed by the invocation of a copy constructor.
If the assignment operator isn't used, this problem doesn't happen.
>Attempting to assign a value to memory allocated but not initialized will attempt to invoke a destructor for an invalid object value.
Can you give an example of where this would happen? This should never happen unless you're doing something strange. If you do things with standard high-level capabilities, you won't hit this problem. For example you can allocate memory without initializing it with vector.reserve() , then later initialize an object into that memory with vector.push_back() or vector.emplace_back() . If you want to go low-level (e.g. to implement vector yourself), you have to be careful to get things right, but it's possible to avoid the problem you mention by using placement new.
>All these rules about when to use constructors and when to use functions and the need to have duplicate almost identical in meaning functions for certain purposes, e.g. copy constructors and assignment operators, complicates a lot C++.
I agree it's complicated. But I don't think "in out" parameters would solve all the use cases. E.g. I don't think they can guarantee invariants like constructors and destructors can.
>There would be no need for "move" operations of any kind, which are just a trick to avoid the inefficient code generated by compilers when the semantics for some parameters is "in out" when what would have really been needed is "out".
move operations aren't just needed for output. They're also used for input. E.g.
Here we can modify foo to contain a string, without copying the string. "in out" parameters wouldn't replace move semantics here in terms of avoiding copies.
True, but 'church' is a mosaic of many different types of church. There are churches that are dropping fast, especially liberal ones. There are also a lot of large churches growing at 10%+ annually. I have friends that go to one that is up 50%+ in less than a year and might hit 100%.
Currently the overall delta is negative. Maybe once the shrinking ones shrink sufficiently and the growing ones grow sufficiently, the overall delta will be positive.
I think the argument is that the drug dealers are actually using bitcoin for its utility, whereas the 1000 normal dudes are just buying it as an investment, not to use.
https://github.com/google/go-safeweb/blob/c2d1215a6a2445915c...