marco_salvatori

I cant speak for any of the people on that list either. But if they are committed to the core values of free software and empowerment for all, then its plausible to me that, rather than words in a joint statement, they should fork the FSF. That is the course of action on which the FSF was founded and would be proof positive of their commitment to the core values they profess. They can then proceed to build a better project, with stronger core values, including universal empowerment. There is no one that has to be judged; there are no joint statements that need to be written. That is the wonderful thing about freedom. One can build, perhaps has the obligation to build, the better world that should exist.

Additionally, but on a slightly different note, I can think of two other common situations where these equivalence validation techniques are useful.

When refactoring or doing performance work, its very helpful to create two variant implementations, for instance the simple, obviously correct version and the new, optimized version. One can then send the output from a property based tester or a fuzzer into both implementations and test: assert forall x . referenceVersion(x) == optimizedVersion(x). A good property based tester or fuzzer will give one high confidence that behavior has been both understood and reproduced. Since changes to legacy code and bug fixes are among the primary causes of defect introduction, these testing techniques usually quickly bring to ones attention how fallible one is.

For non code artifacts like configurations and build systems where output is assembled or generated. The Unix diff utility can be useful. One assembles or generates the artifacts in two directories. One directory is representative of the project before the change and the second directory after the change. Anything that shows up in the directory diff should correspond to exactly to what one expected to see as a change. Since the full actions of package assembly and generation are often opaque, this technique provides assurance in parts of the system development process where there are often few other safety nets.

People who are unfamiliar with WeChat Pay in China, are underestimating the potential for the FB cryptocurrency. The integration of social media and payments by WeChat strongly facilitated consumer adoption of their payment service. Everyone already had phones, everyone had WeChat installed on their phones. When payment services later became available through WeChat, there was a minuscule barrier for customer adoption. As people started using WeChat Pay they quickly found it more convenient for physical and online payments, money transfer between friends, and financial management. Next services like taxi hailing + payment became integrated into the WeChat app, increasing the convenience. The combination of convenience, preinstallation in the dominant social application, and low barrier to entry was a killer combination. In my estimation it turned out to be a stronger combination than Alipay, which started out as a payment service integrated with TaoBao (comparable to the Ebay / Paypal).

Since Facebook has a dominant social app and messaging app position worldwide, their payments service will have worldwide penetration from day one. Since Facebook can do software, the service interface will be more convenient and user friendly that existing services in the first world, and infinitely more so elsewhere. Money can be made here and evidence suggests people want to adopt when there is a no effort road to adoption. There are vested interests to deal with and satisfy on the road to market penetration, existing market players and governments, but American entrepreneurs like Gates and Jobs were able to overcome vested interests in their time and I suspect Mark is equally resourceful when he wants to be.

Traveling extensively the past year I have noticed the following which are probably all coming into our lives soon. (a) In many countries border entry is accompanied by a fingerprint scan which will be either a left and right index finger scan or a scan of the whole left hand. The scans are done at inbound border crossings in conjunction with the passport check. (b) In many countries both border exit and entry are paired with the taking of a photograph. In some places it appears the exit photograph is validated automatically by software. (c) In some cities, the subways have security checks at entry and in those places photographs are taken, non obviously, by the security equipment. I am not sure how effective these systems are at tracking. I guessing ideally governments would like to pair these photos with a passive probe of something carried on the body like a phone or official id, something that could link the photo to an already verified identity. (d) On country entry, purchases like SIM cards for local telephone service or public transportation pass cards can only be acquired if one presents an official id. Manual computer entry usually links the card to the presented id.

And here is a prediction, getting a record of faces and fingerprints, and tracking movement is on the agenda right now. In the future there will be a equally focused agenda to acquire records of peoples DNA. In countries where there is nationalized health service, it will eventually be required. Aquisition will begin when the cost of storing, acquiring, and searching that DNA information becomes cheap enough.

Little in this article meshes with my experience living in large Chinese cities: Beijing, Shanghai, Guangzhou, and Shenzhen. Specifically, I have not observed the social problems mentioned "crime, ... social segregation, and destroyed community and neighborhood life". I believe a good description of the average large, Chinese city experience is: lots of cars and people but mixed development with plenty of shops, schools, markets, eating locations, parks, and public transport in easy walking distance. To me, the article comes across as an opinion piece - it was all bigger than the author would have preferred.

Since a full version Mathematica is available on the Raspberry Pi, anyone who is interested has a very inexpensive route to getting a free copy. Mathematica is very functional on the Raspberry Pi and, I think, making the software available as such is very generous of Wolfram. Also for those who cant afford a Raspberry Pi, excellent mathematical functionality is available via the Wolfram Alpha website for free.

Throughout my career, I have never met anyone who used MS tools that did not find them excellent and productivity enhancing. In fact I could probably add to MS any of the language vendors from years ago. I remember using Borlands terminal based C++ environment back in the early 90's. That's about 30 years ago and that environment is better than what I use programming on Linux today.

I have often thought that programmers posture over their tool independence to signal their excellence. Before the current generation of programmers, many programmers would proclaim how they didn't need to use higher level languages to assist them in programming because assembly language was sufficient given their reasoning powers. Today programmers proclaim they don't need types to insure data invariants as their reasoning powers are sufficient. They proclaim they don't get any value from unit testing because they can maintain correctness across all development phases using their reasoning powers alone. They proclaim they don't need automatic garbage collection because they can insure correct memory usage using their reasoning powers. They have no use for IDEs, debuggers, or profilers because they believe none of these tools could augment their reasoning powers.

Excellent programmers can indeed compensate for poor tooling through their reasoning powers alone. But if history is a guide, people who don't use the best tools, practices and technologies to produce the best work, at some point, wont produce the best work.

Yes. When a client hires a developer, he cares that he receives a proper delivery and he cares that all of the decisions related to that delivery were made in his best interests. Technology choices are an important part of building a technical vision for a company and planning for software maintenance. People may not seem to care much, but that's only because they are trusting the people they hire to care and to know better than they do. When there are any questions on technology, clients appreciate and value unbiased discussion on those choices, in the context of their business. An important part of having clients, perhaps the most important, is establishing trust and one does that with success, but also a record of transparent, appropriate project decisions.

Just building on the who and why idea ... as a technical manager an important aspect of your job is use your technical aptitude to help your non technical peers clarify business ideas related to, possibly, technical problems. Once problems are clarified, it should be clear whether they are technical or not. At that point you then need to advise at the proper level of abstraction on cost, timelines, possible solution benefits and shortcomings.

Lets think about clarifying business ideas. Non technical people are familiar with issues in their business areas, but they may not be able to clearly describe the issue or identify root causes. Your job as a managerial level engineer may be to interpret a vague understanding that something is not as they want, into statement that can be evaluated as a engineering problem. You may in that interpretation process find that the problem at hand is not a technical problem or that there may be effective non technical means to solve it. Remember that people you are dealing with have developed very different skills to address issues in their businesses areas, and engineering style problem definition is likely not one of those skills. For example, a typical sales manager might deal with sales issues by getting a lot of people in a room, generating visibility, enthusiasm and consensus. He may see that as the way to solve engineering issues as well. Just as you may not have developed the skills to generate institutional momentum and enthusiasm, others may not have the developed the skills to approach problems with engineering perspective. Your value comes from doing that transformation for them and then communicating it to them in terms of their skill set.

Take an example, suppose a peer tells you that it is a problem that you do not "talk like a leader". What does he mean by a leader? I have heard hundreds of definitions of what a leader should be over the years. He is trying to express a mismatch between your managerial execution and his ideal, but I'm not sure if leader is the exact word he wants to express that mismatch. Which of my hundreds of "leader" definitions would most closely match his primary complaint about your execution style? Lets go a step backwards to "dont talk like an engineer". I suspect this statement is getting to the source of his primary complaint so lets investigate this statement.

I mentioned above that you need to advise at the proper level of abstraction and in terms of other peoples skill sets. If you are in a managerial meeting about a new product X and you start talking about Ruby on Rails vs Django or using C++ vs Rust, then you are talking at the wrong level of abstraction. The business does not care if X is Ruby on Rails or Django. They care about whether its a good technical idea. Should they put resources into X? How much will X cost? How long will X take to create? And most importantly how well X might or might not solve the well defined problem you clearly communicate? If you have ever talked technical details in a meeting, then you are talking like an engineer, and your talk is irrelevant to their concerns. Conversely, if you are ever in a meeting, and a peer manager suggests they really need a Y implemented to solve their problem Z, then your job is not to give them cost and timeline information on Y. Your job is to understand that your peer manager might, himself, be operating at the wrong level of abstraction. Y might the the solution to his problem, but maybe he would be better off with a different technical solution. Or maybe he needs to see the problem in a slightly different light.

I cant be sure, but I suspect that you dont have to change perspective and become a leader. Your perspective probably has a great deal of value to your company but you are just not presenting that perspective in a way your peers find maximally useful.

My take away was that researchers produced evidence that the shape of bird eggs is optimized, around physical characteristics of the parent. I am open to the idea and sceptical. In the context of humans it would be like saying the shape of children is optimized around the physical characteristics of a womans body, as opposed the the supposition that a womans body is optimized around the physical characteristics of children it will have to give birth to.

At the risk of being too opinionated, PlusCal is a needless and unproductive diversion. The TLA language and source file structure is mostly standard mathematical notation, using ascii characters. Most people will be familiar already with that mathematical notation before any exposure to TLA. And I wouldn't be able to recommend that people learn just another novel representation for something already known. Learning PlusCal to reason about logical propositions strikes me as comparable to learning an XML notation for manipulating formulas in differential calculus. Yes, we are developers; yes, we are used to XML and, still, ... I don't see how it improves upon writing math.

Mathematical notation is a concise, time tested language for enhancing thought. People should use that to their advantage. As an added advantage, unlike PlusCal, facility in the language of propositional logic generalizes widely to other tools used in formal methods, as well as other technical fields.

Doing the comparison TLA vs Rust as programming languages is a misunderstanding. It's exactly equivalent to the misunderstanding in a comparison like "what's the advantage of SQL over Rust, that as far as I know is designed specifically for this kind of problems". Now, one could believe, perhaps, that Rust is "designed specifically" for the implementation of database "kind of problems". But the conclusion that there is therefore no "overwhelming advantage" to databases would not follow from that belief.

TLA and the TLA tools form a model checker. The TLA language is not used to do computations,but, rather, is used to describe properties and behavior of complex systems. The TLA tools then machine validate the descriptions to assure that the evolution of a system with the given behaviors will satisfy expected correctness properties. A TLA specification tells you that if your system is implemented (in a computer language, like say Rust) according to the description then the systems operation will satisfy the validated correctness properties.

TLA is about answering the question "Do I properly understand my problem and will my solution logic satisfy problem needs?". Rust doesn't help answer that question.

You might create a TLA model during the initial specification process to assist you in thinking through your problem. You would then update the model going forward as your understanding of the domain improved and as system requirements changed. However, you could write a specification for an existing system as well. Any processing where the complexity seems greater than ones reasoning ability or that needs assurance guarantees, could signal the need for a high level description to guide engineering efforts.

An initial model might take 4 hours to put in place. The time would be spent thinking through how best to abstract the modeled process and its logical properties, slowly building up a more and more complete set of events, and checking the model by running it as one goes. With an initial model, additional hours would probably be spent here and there adding enhancements and finding ways to do things better, just like one would do with regular code. The model would effectively exist over the lifetime of a corresponding code artifact and guide work on the artifact.

For a standard web application that mostly does reads and writes to a database, there usually wouldn't be any need for a tool like TLA to help you reason. A general use case for TLA is describing systems where there are multiple processes or threads coordinating on some sort of shared state.There would be indeterminacy in the order in which events happen. There could be the possibility of failure and the need to handle it gracefully.

Yes, strict separation will probably be the norm where there are sovereignty issues. And it will be enforced both ways. So for example,I will make the claim that if Alipay expanded into the US it would own the entire payments market in one year. Alipay is just that much better than anything else available in the US. Plausible or not, Alipay will never operate successfully in the US because the US will not cede sovereignty over part of its financial infrastructure to China.

I can not say if that is smart or not. That question is outside of my technical sphere of competence. But I believe it's an accurate evaluation of how states will operate, as soon as these systems start being used to project power.

My suspicion is that its very unlikely that Google and FB are going to be able to establish the government relationships that would allow them to operate successfully in China.Google collects massive amounts of citizen data and it has close relations with the US military / security institutions. The combination means Google will never be a trusted operator in China. Facebook is in a worse position. In addition to being a data collection platform with US government connections, it is a communications platform not under the direct control of China, located in the US.And these US communications platforms have a history now of being associated with movements of anti-government dissent around the world.

More generally, I dont see how US tech companies are going to be able to have it both ways -- be both willing partners in US government policy and also non threatening to Chinese sovereignty.