tmcb

> The United Nation's Food and Agriculture Organisation (FAO) reported on Jan 6th 2020: "The Desert Locust situation remains extremely serious in the Horn of Africa where it threatens pastures and crops in Ethiopia, Somalia and Kenya. Numerous swarms have formed in eastern Ethiopia and adjacent areas of northern Somalia. A number of large immature swarms moved south in the Ogaden of eastern Ethiopia and adjacent areas of central Somalia and reached southern Somalia, southeast Ethiopia and, on 28 December, northeast Kenya." The FAO warns a dangerous situation arises at the Horn of Africa and on both sides of the Red Sea.

Thinking on the opposite direction, wouldn't it be interesting to have unmanned drones to eliminate locusts with ballistic impacts?

Not too far from my personal experience, but it seems to me that all these mismatch scenarios arise when you are programming in the large, either directly or indirectly, i.e., by using third-party libraries, code snippets or even RESTful APIs. In a sense, programming in the large with an APL-like language reminds me of Perl in its best and worse. But things fit pretty well in the small.

Not really, I think. "[O]utside of the browser on the host computer" implies that there are other possible ways in which JavaScript could execute, one of those inside of the browser on the host computer, which is pretty much the expected thing and tangentially covers the concept of sandboxing.

This covers so much more things than you actual question, but let me try.

You must realize that self confidence is not about thinking you are the best on what you do, but making sure that you are trying to do your best at every opportunity that you are given.

Once you assimilate that, you will understand that asking for help is sometimes the best way to do your best. And you will grow as a person with that.

Not a very original suggestion, but the original book (“A Programming Language”, by Ken Iverson) would probably fit in.

This is partly what I was trying to convey with the "turning this aphorism into a question" fragment. Sometimes it is just not possible, or it is too expensive, to increase hardware performance.

Premature optimization, or at least one of its manifestations, is failing to consider the opposite.

I read somewhere else yesterday that “it’s easier to throw hardware at a problem than people.” It certainly does not hold true for all cases, but turning this aphorism into a question seems to give us some good heuristics---provided you do know the what the root cause of your performance issues could be, of course.

Somebody with better knowledge of that will hopefully chime in. My impression is that most of the distributions either don't patch upstream besides the build recipes, and upstream maintainers turn a blind eye to that. The ones that do, though (e.g. Debian), take the approach described on the OP and rebrand it (e.g. https://en.wikipedia.org/wiki/Mozilla_software_rebranded_by_... ).

It is not about having the right to fork under the same name only, but also having the ability to apply small patches to the code without going to the great lengths of rebranding everything---of course we can discuss if changing a single bit from the source code would qualify the result as a fork or not.

> Surely this is different from a stateless pipeline of functions where data is put into the front of the pipe And a new value pops out of the other end of the pipe.

By no means I want to sound inquisitive, but, if it is different, how is it? Is one of these models (OOP and functional) a subset of the other? If so, do they represent levels in a given hierarchy? If not, do they even intersect? Are dissimilar properties complementary?

Mutable state is an implementation detail. It is tricky, it induces confusion, maybe it should be avoided whenever possible. But if you are using a physical computer, that is all that you have.

And, in those very same computer implementations, data cannot possibly contain methods. The compiler is going to treat them as ordinary function implementations, not any different from functions generated by the compilers of non-OO languages.

So I would love to see a mathematical proof of the isomorphisms you mentioned but, especially, a proof that your proposal is actually non-isomorphic to the other examples. I don't believe that holds true.

I don’t think so. My hopes here are that, in having two orthogonal code bases in extremely different languages, there would be no chance that typed and untyped code intertwine, hence compromising typing accuracy. I regard this possibility as a serious problem with gradually typed languages, one of those that risk to be addressed with lengthy software engineering books, those to be mentioned as mandatory knowledge on every single programmer job interview by the year of 2039. But I digress.

“Abrupt typing” would describe this approach more precisely, if there was such jargon. A program module has no types while it is a prototype, but it must be completely typed (which is just another term for “having its correctness proved with the best tools available at this day and age”) before it goes into production.

I can't see how they do, sorry. In fact, they complement each other. The usual static typing mechanisms I mentioned force you to approach a problem with their specific mindset, very much like math problems that add unreasonable constraints to their statements in order to check if you grasped a specific concept really well. In a real world scenario you should be able to reason your way out of the problem without such artificial constraints. So it should not be a restriction to anybody if they can accurately explain a concept or implement a program without using tools such as types.

Static typing is not at all bad; usual static typing mechanisms are, due to the fact that most of them force you into designing your types before you even have a working prototype.

(If you should first understand your problem before you write some code or if you should use code to help you understand the problem and then write more code is up to debate, of course. Typing is an invaluable tool of thought to help you understand your problem, yes, but it is just one more tool in the toolbox.)

The sad thing I noticed though is that, having hacked a mostly untyped Python code base during the last few days, making sure that all typing annotations you add to the code base are sound is a big PITA, to put it bluntly, and I would pretty much prefer to work with a statically typed language in this particular case. If your typing discipline is uncoupled from the ability to run code, people simply remove that obstacle from their way. It starts to be treated pretty much like tests and documentation: indispensable in theory, relegated to second plan in practice.

So my impression is that gradual typing almost got it right, but it may do a great disservice to overall code quality as well. I am now inclined to think that some kind of barbell strategy on typing will render better results: use both a completely untyped dynamic language such as Tcl, where everything is a string, and a static, strongly typed programming language (ideally a proof assistant with dependent types). You prototype with the former and move into production after translating your solution to the latter. If you ever need to push untyped code into production, it will be obvious to everyone involved and, since it is so decoupled, it cannot affect the quality of the statically typed codebase by any chance.

I see. In that case, the output is right and the comment is misleading.

Looks like the comment is zero-indexed as well. I wouldn't consider that a typo.

I would like to recommend Kona[1] as well. It is an open-source K implementation, with some small differences.

[1]https://github.com/kevinlawler/kona

You shouldn't feel intimidated by their density. Both J and K are extremely approachable languages, but you need to try them an open mind and act as if you didn't know a thing about good coding practices. With time you will realize that only a tiny fraction of those apply to the APL language family.

On the same line, let me recommend you a book: "The Design of the Unix Operating System," by Maurice J. Bach. If I am not mistaken, Mr. Bach was a member at Bell Labs.

My personal take on the book is that the kernel was meant to be a portable virtual machine, extensible through processes, and that those would be the building blocks of user applications for which the shell would act as glue.

In other words, the shell and the OS are separate because most of what we commonly call "the OS" may be interpreted as mere encapsulation of less versatile hardware architectures.

It is easy to talk about premature optimization in a world like ours; the hardware industry spits products twice as fast and generous in regards to memory every three years or so, to keep up with software designed by programmers who think likewise. You just replace your two-year old laptop with 4GB of RAM---which became unusable all of a sudden because now it keeps hitting virtual memory, which is I/O expensive---for one with 8GB of RAM.

If you consider hardware is a commodity and the cost of opportunity for replacing hardware instead of optimizing software is worth it, then formulate it better.

One may object by saying that the burden on hardware resources is higher because we consume more data, which is partially right. Although I don't intend to give a thorough objection here, please consider those two points:

- The payload fraction is larger in multimedia applications, for sure, but I can't see a reason why the "propellant mass fraction" equivalent in software should be bigger than it was, for example, 10 years ago. If we consider text-only data as an example, we notice that the propellant mass fraction increased as well.

- Higher level languages undeniably consume more resources by orders of magnitude; hardware frequencies must keep up by orders of magnitude as well.

There may be some duality on the use of the word "language". If it is used in the literal sense, I agree. In another case (i.e., if you were referring to languages and their execution environments), I beg to differ. For the end user of a programming environment, differences on syntax are mostly tangible in the aesthetic sense. Some languages are more readable or expressive, indeed, but, in the end, syntax has something to do with our perceptions on how beautifully the code lays out.

Execution environments, on the other hand, are tailored for a class of problems, incorporating useful abstractions. Yes, I know it is not so evident in a world where we have general-purpose programming environments by the dozen; when we talk about domain-specific languages, this makes a lot of sense. They can only gain expressiveness if they can represent bigger abstractions with fewer words.

This, somehow, reminded me one of the Leslie Lamport's definitions for a distributed system [1]:

A system is distributed if the message transmission delay is not negligible compared to the time between events in a single process.

If link transmission rates continue to drop and latency to get lower with time, some dull distributed programming problems we have today will disappear, as another ones will raise and become feasible. On the day this happens, maybe a local network will be considered a single piece of hardware.

[1] http://awards.acm.org/p558-lamport.pdf

It is not intended to be solely a general purpose programming language. It looks more like a DSL for inter-process communication. As "process", I mean not ordinary OS processes, but computation units written either in Escher or other languages, like Go, at the moment.

It's mostly systems programming research (IMO, at its best, given the poor state of the art nowadays), but at that intersection area with programming languages.

It doesn't look like a joke. The use of unconventional terms seems to be justified by the vast coverage seen on the references: arts, linguistics, cognitive sciences, just to name a few. It even looks a bit non-academic, in the best sense of the term: it departs from the classical aggregation of buzzwords backed by a properly chosen set of bibliographical references.

It wasn't clear to me at first if choiceless computation is present due to a mere design decision or if it is necessary to the Escher paradigm. I suppose it plays a role on the load distribution over different instances of a same computation unit --- as "computation unit", I mean reflexes, gates and circuits. Am I right?

It reminded me of languages like Lucid[1] and Quil[2], which treat non-von Neumann models of computation; Escher, though, seems to focus at the IPC level.

[1] https://en.wikipedia.org/wiki/Lucid_%28programming_language%...

[2] https://sites.google.com/site/quilweb/

No, of course not. I'll try to be short, though.

The first thing to ask is what differentiates Wikipedia content from the rest of the 'net so that it would be OK to break net neutrality principles towards the implementation of this project.

So, even if this breakage is somewhat worth the bending of the rules, companies must support the idea. Once they do it, what would be the moral ground to rightfully deny another proposals from content providers that offer them money to do that?

Well, this problem is not something really new. Net neutrality is already broken, though almost everybody agrees on its importance. There must be some kind of consistency if we want it to survive.

I can't help pondering about the implications this move could consequently bring to the perceptions of net neutrality.

Not that I see this project as something inherently bad, it is just the contrary, but it can give rise to some bad moral precedents.

I'm quite impressed no one mentioned 'fg', 'bg', and 'jobs'. Since I got used to them, the number of open ptys in my screen dropped drastically.

The idea looks pretty good, and it's OK if someone hacks it for themselves, but the implementation is lame, in my opinion. I understand that I can be a bit off-topic or ranting worthlessly on a simple hack that was intended to be just that, a simple hack.

It looks like people forgot how to develop simple protocols for this sort of thing. A simple protocol for remote named pipes, a client and a server, and a wrapper/gateway for dotCloud/HTTP wouldn't take a (very) long time to develop, wouldn't be completely dependent on an external service, and would probably develop into something bigger --- even for anonymous file sharing!

I really would like to know why programmers, in general, seem not to be doing this sort of thing anymore. Sorry if it looks like some sort of misplaced criticism, I'm posing all of it genuinely as a question to the community.

Lua internally represents any kind of number as a floating-point one.

http://www.lua.org/pil/2.3.html