yiyus

Slightly similar in practice, but very different concept.

In Plan 9, every process draws interacting with a screen file (in fact, it is a whole filesystem, also including keyboard, mouse, control files, ...). What rio, the Plan 9 window manager, does is to "multiplex" this screen file (again, file system) so that each process has its own screen which does not correspond to the physical monitor, but to a window.

An uncommon feature that derives from this design is that you can run a new rio instance inside a rio window. More important, you can just connect to other machines and interact with their windowing filesystems, getting network transparency "for free".

As a fan of nhm, I'm not disappointed: simple tools that just work.

He is a comedian talking about comedy. He makes some good points you might agree with or not, but I cannot understand why it matters how many essays he has written about George Floyd's death. If that is the new low bar to talk about something, the hand is already kilometers away of the stove. It's cold in there.

But you cannot take your 42in TV with you in a backpack. Mobile setups are more practical than fixed ones for most people.

I think the point is noticing the trends, not agreeing with them. If people were criticizing bitcoin in hn in 2013, it means the community was aware of its importance. And they were before the rest of the world did.

That does not mean this is the perfect (or even a good) metric, but I do not think that predicting tech trends is the same thing as embracing them.

Thanks for the info. I did not know this, but it does not surprise me. I am sure there are similar examples.

The first section of the linked article says that Fortran "was an odd choice from a pure computer science standpoint", that they "developed hardware optimized to run FORTRAN", and that large parts of the OS (in particular, the kernel) were eventually rewritten in other languages.

This is, in my opinion, a great example of how Fortran could not compete with C as a systems programming language.

Fortran has never been used seriously for systems programming. It got text processing capabilities and a ton of other stuff, but we do not see operating systems or web servers written in Fortran.

And C got the floating point operations B did not have, and was actually used for lots of numerical work for a while (and it still is, up to some point), but nobody was totally happy with it so we got C++, new Fortran versions, Python, now Julia... Although it always is an option due to the availability and quality of C compilers, I would not say that C succeeded in becoming the language of choice for scientific computing.

Of course, this does not mean that C or Fortran are failures.

You are absolutely right. To be honest, the current situation is not too different from this hypothetical case. Fortran is used mostly to write numeric routines and then we call them from a Python script, instead of writing text and arguments processing (for example) directly from Fortran. But I still find interesting thinking about where these languages would be if these limits had been consistently respected.

I like how constrained the language was:

> All arithmetic in B is integer, unless special functions are written. There is no equivalent of the Fortran IJKLMN convention, no floating point, no data types, no type conversions, and no type checking. Users of double-precision complex will have to fend for themselves. (But see ->32 for how to call Fortran subroutines.)

I wonder if it would have been beneficial to continue with this separation. Fortran and C started trying to do everything and they failed. Fortran was never a contender for C for systems programming, and C has not moved in the right direction to be better than Fortran for numerical computing.

I absolutely agree with you about the introduction of new symbols. Most glyphs have been there for decades now, and there is a high barrier to introduce new ones. There are Dyalog developers who experiment with new primitives that use new glyphs, and it takes years until they are actually introduced into the language, if ever.

Very clever people have been working in array languages for more than 60 years, and there is a set of around 20-30 primitives that all of them agree are worth to have. Depending on the array language of choice, there are another 10-40 primitives more. Symbols have double use (monadic and dyadic), so that makes a total of 20-40 symbols to learn, and you already know many of those (+-×÷=<>, and probably a few more).

To each his own indeed. But if you haven't, I would suggest you to give it a try. It makes much more sense once you start writing code.

Fair enough, the change from infix to prefix was misleading. But do you (or anyone) find

    (a times (b plus c)) equals ((a times b) plus (a times c))

easier to read than

    a*(b+c) = a*b + a*c

?

> words that describe the inherent function makes reading the source A THOUSAND TIMES easier

I disagree. Using add instead of +, for example, does not make code more readable at all, on the contrary.

It's not about terseness, it's about making easy to see patterns and what is going on. You probably learnt the distributive property in school:

    a*(b+c) = a*b + a*c

Let's make that "more readable":

    equals(multiply(a, sum(b, c)), sum(multiply(a, b), multiply(a, c)))

It's not about the terseness, I just don't see a clear pattern using the "readable" notation. But it is obvious when using symbols.

You can find another interesting example at: https://wjmn.github.io/posts/j-can-look-like-apl/

It's not a typo. Monadic × will return 1 if the right argument is positive, ¯1 (minus one) if it is negative, and zero if it is zero.

I found math concepts much easier to understand after seeing their application in engineering. Linear algebra and tensor calculus make sense when you study mechanics. Complex numbers make sense when you study electromagnetic fields and circuits. Differential equations are also way easier to understand when you use them in a real instead of an abstract problem.

If you are never going to get into these (or similar) fields, you should not worry.

There is an interesting conversation about this in https://www.arraycast.com/ (I think it was the second episode).

They talk about the cognitive load needed to understand code in different languages, and how thanks to the use of primitives and less levels of abstraction, they find array languages easier to work with (eg: with implicit loops, you do not need to keep track of a counter and an exit condition).

Even if you do not share this opinion, I recommend this podcast. There have been some threads in hn about it.

> It is the turbulence that create the uplift on a wing

You can have lift with laminar flow. In fact, the article includes an explanation of the usage of the Reynolds number to characterize laminar and turbulent flow and how the flow around plane wings is clearly laminar (called "smooth" in the article).

> a page that's associated with a standards body

Is it? As far as I saw, this is just the web site of the ##C channel on Freenode.

It has several interesting properties. It is quite a rabbit hole, but a nice one to get lost into.

I would say that the most interesting thing you should know about them is that practically everything they do is manipulating a stack (actually, there are usually two stacks, I don't know if this is the case for Stabel).

What I find more interesting about them is their simplicity (comparable only to Lisp), which makes possible writing a basic interpreter in only a few lines of code. Being more concrete, an important property of concatenative languages is that they allow a point-free programming style, which gets a bit to get used to but really makes you think in a different way.

If you already feel curious, I would suggest the book "Starting FORTH" before looking into more modern (and practical) alternatives.

This.

What I find really annoying is how many people confuse this property ("accessible to those not trained in it") with readability.

You did it wrong. In a vector drawing program, you do not change colors using the bucket fill. You should learn to use a tool before complaining it does not work.

I guess that each data point is a commit and they just made more commits in the 2014-2016 period than in 2011-2014. But it's just a guess.

There is a lot of advice in reddit at r/speedreading/ (some of it very good advice, some of it terrible).

Personally, I considerably increased my reading speed after using a speed reading application in my phone. I used the app only to read novels, but my reading speed with real non-fiction books greatly benefited too.

As many people have pointed out, reading faster does not always mean learning faster. However, reading is a skill that can be trained and, for most of us, there is quite some room for improvement. You can probably read faster than you do without any drawback.

Either Go is a horrible language that did not learn anything or it is a language developed by some of the best engineers for a long time. If you are claiming that both things are true, then how do you explain it?

There are irc channels that can also be of help.

I used to spend my time in #sed and #awk, and try to answer any short question that came up in the channel. They came up at a good pace, I don't know if this is still the case.

It was a really good exercise, and it has an additional social aspect you will not get from reading books (which is a great resource too).

Plan 9 man pages are also much more manageable than their respective GNU versions.

The tools in Plan 9 are also much simpler, with fewer options (and also a few differences), but it's a very useful subset, you will rarely need anything else.

In my opinion, both of you are right. The issue with the standard is not if it is a good or a bad standard; the whole concept of standardization goes against Chuck's approach of writing your own Forth fitted to the problem at hand. However, I think there is no discussion in that the industry preferred a standard to this unlimited freedom, so ANSI-FORTH really helped Forth in industrial settings.

In other words: the standard held back the concept of Forth by Chuck Moore, but it helped to push forward the concept of Forth as an industrial product. A very grey area...

> A candidate's expectation for salary might be lower than the advertised range, but if they see the range, they'll expect more money.

A client expected price for a product might be higher than the advertised price, but if they see the price, they'll pay less.

I do not say this is a good idea, but I do not think it is obvious that this particular issue is a reason for it to fail. This is how selling products work so, why wouldn't it work for the job market?

> Alumnis and students are not banned from contributing, as long as they use their private emails. It's the university email domain that is "radioactive".

That's not what the comment I was responding to said. It was very clear: "As far as I'm concerned this university and all of its alumni are radioactive". It does not say every kernel patch coming from this domain is radioactive, it clearly says "all of its alumni are radioactive".

You said before that alumni from the university could submit patches with their private emails, but according to what djbebs said, he would not. Do we agree that this would be wrong?

I think that is a reasonable measure by the LK team. In my opinion, it is the right solution in the short term, and the decision can be revised if in the future some student or someone else have problems to submit non-malicious patches. But I was specifically referring to this comment:

> As far as I'm concerned this university and all of its alumni are radioactive.

That is not a practical issue, but a too broad generalization (although, I repeat, I may have missed something).