Well, I think there is something to it. Computers were at some point newly invented so research in algorithms suddenly became much more applicable. This opened up a gold mine of research opportunities. But like real life mines at some point they get depleted and then the research becomes much less interesting unless you happen to be interested in niche topics. But, of course, the paper mill needs to keep running and so does the production of PhDs.
There are some services where it makes sense. E.g., submitting taxes with the government, logging into the banking website. Apart from that kind of service, yes I don't think I would want my identity or age verified on more or less any website.
The article talks about 'software development will be democratized' but the current LLM hype is quite the opposite. The LLMs are owned by large companies and are quite impossible to train by any individual, if only because of energy costs. The situation where I am typing my code on my linux machine is much more democratic.
Sure, we can run the math on heat dissipation. The law of Stefan-Boltzman is free and open source and it application is high school level physics. You talk about 50 MW. You are going to need a lot of surface area to radiate that off at somewhere close to reasonable temperatures.
Whether or not a 'LIO' exists is not that interesting to me. What is interesting is what actually exists and what has happened in history. What actually exists is an enormous shock after, for instance, world war one where the question arose how it is possible that basically an entire generation of young men was slaughtered. E.g., every small village in France has a memorial of the fallen soldiers during world war one. For many decades after the war commemoration were/are still being held. It used to be that competing for territory was just the normal thing countries did. Then, it became clear that this has a potentially enormous cost in human lives. The obvious conclusion for people who are not sleepwalking through life and through history, is that any political leader who advocates for a change in country borders and does so much as hint to violent means of doing so is totally deranged and immoral. A similar shock has gone through the world after world war two, which, for instance, lead to the creation of the declaration of universal human rights. Among the decent public, it is also concluded that a violation of human rights is deranged in immoral.
They say that prediction is difficult, especially when it is about the future. Unwise economic policies may be punished quickly, slowly or might be revoked before punished severely. The question is how much risk one is willing to take. Another matter is of morality. Being invested into something means supporting its practices and being partly responsible for them.
Incorrect. The rules based order was first attempted after the first world war and then created after the second one. These are lessen that have been bought with blood. Lots of blood. Megaliters of it. The incredible stupidity of throwing that away is absolutely disgusting.
Sure, high level is the goal. But the question is whether the abstractions are the correct ones that fit the problem. Almost all software that I have encountered that was painful to work with chose a framework that did not apply to their situation.
E.g., develop a generic user interface framework which makes it very quick to produce a standard page with a series of standard fields but at the same time makes it very painful to produce a non-standard layout. After that is done it is 'discovered' that almost all pages are non-standard. But that 'discovery' could also have been made in five minutes by talking to any of the people already working for the company....
Another example: use an agent system where lots of agents do almost nothing, maybe translate one enum value to another enum value of another enum type. Then discover that you get performance problems because agent traffic is quite expensive. At the same time typical java endless typing occurs because of the enormous amount of agent boilerplate. Also the agents that actually do something useful become god classes because basically all non-trivial logic goes there....
The difference is that in C one is supposed to do allocations and deallocations oneself. Then move semantics is just pointer assignment with, of course, the catch that one should make sure one does not do a double-free because ownership is implicit. In C++ ownership is indicated by types so one has to write more stuff to indicate the ownership.
With 'auto' it is so very verbose. It can be shorter. Let us put "using TP = std::chrono::steady_clock::time_point;" in some header file to be used in many places. Now you can write
TP start = TP::clock::now();
do_some_work(size);
TP end = TP::clock::now();
I agree that auto should be used as little as possible. There are good uses, though. It is okay to use when the type is trivially inferred from the code. What is auto in "auto ptr = std::make_shared<MyNiceType>();". Everybody who knows any C++ knows. Also, lambdas do not have a type that can be written down, so it is okay to use auto for them.
I also prefer not to use auto when getting iterators from STL containers. Often I use a typedef for most STL containers that I use. The one can write MyNiceContainerType::iterator.
Documentation like doxygens is almost completely opposite from literate programming. The comment you are responding to emphasizes the ability to determine yourself the order in which to present the documentation. Literate programming is writing a document in the first place where, as an afterthought, a program can be extracted. Source code with doxygen is source code where, as an afterthought, documention can be extracted from. In many cases doxygen documention is quite worthless. Very often it is very helpfully documented that the method get_height, "gets the height". It is very fragmentary documentation where the big picture is completely missing. There is also a case where doxygen-like documentation is needed. This is when writing a library that is going to be used by many people. But then the doxygen comments should only be used on methods that you want those other people to use. And then there is still the danger that there will be too little higher level documentation because the doxygen is treated like it is sufficient.
Literate programming is, in my opinion, only used very seldomly because keeping an accurate big picture view of a program up to date is a lot of work. It fits with a waterfall development process where everything that the program is supposed to do is known beforehand. It fits well with education. I think it is no coincidence that it was brought to prominence by D.E. Knuth who is also very famous as an educator.
This is the kind of development that one needs for safety critical applications. E.g., nuclear power plants or airplane control software. I don't think it is economically feasible for less critical software. It presumes a great degree of stability in requirements which is necessary for such applications.
I have been programming professionally for 17 years and I think this guideline is fine. I have difficulty imagining a function of 70 lines that would not be better off being split into multiple functions. It is true that if a function is just a list of stuff longer functions can be allowed then when it does multiple different things but 70 lines is really pushing that.
I don't know that much about PM but I from what I read I have the impression that for the purposes of paradox avoidance it is exactly the same mechanism but that PM in the end is quite different and the lowest universe of PM is much smaller than than that of practical type theories.
One way that is very common to have decidable dependent types and avoid the paradox is to have a type hierarchy. I.e, there is not just one star but a countable series of them *_1, *_2, *_3, .... and the rule then becomes that *_i is of type *_(i+1) and that if in forall A, B A is of type *_i and B is of type *_j, forall A, B is of type type *_(max(i, j) + 1).
Nobody can vouch for their own sanity. Attempting to do so only make you sound insane. Incentives to be insane? Sure, but.... it is timing the stock market of ideas. Some will get rich but most will not. And sanity either has to return or insanity will destroy many lives and the society in which it is allowed free reign. In any case if you promoted insanity when sanity returns and people regain their ability to have a memory you may reap what you seeded.
If others control the things that are important to you, they will at some point find a way to abuse that power. A very important point to keep in mind when making technology choices.
It certainly makes things easier. But it also makes some things very, very, very inefficient. I want a list with millions/billions of elements. I want to regularly change one of the elements somewhere in the middle. Good luck with the copying.
The bike shedding is optional once one accepts that code written by someone else might look a bit different from ones own. _Some_ conventions are beneficial, and one might discuss those, but one does not have to have complete uniformity.
Bike shedding for weeks might happen and is not helpful. On the other side of this argument there are not-so-very-pleasant things as well.
A: We follow this-and-this coding convention and we do not like wasting time on discussing it so we follow it to the letter.
B: I don't like this small thing that I would like to write differently.
A: We follow this-and-this coding convention and we do not like wasting time on discussing it so we follow it to the letter.
B: You actually don't follow this-and-this coding convention because you are not following this-and-that rule.
A: Yes, that is a change that I liked.
One can easily end up with a very old coding convention that only the oldest developer likes so the oldest developer can now be dictator over everybody else.