bakul

You should always verify every little thing for any new language you’re thinking of using, if only to understand its behavior in details, warts and all. I did the same when I first learned C, C++, Go etc. etc. But one must separate (what I consider) marketing fluff from reality. Evaluate for yourself whether the new language is worth learning, whether its development is going in the direction you can mostly agree with, whether it has promise, whether it is developing an ecosystem etc.

This is the default but can be changed. I use clang on FreeBSD as a few tests break under tcc.

Ignore all the pro/con noise. git clone its repo, compile it locally and play with it. Write some code. You’ll be pleasantly surprised (at least I was). Its progress is pretty good (few tests break now and then and once in a while the self-compile breaks and I have to run make). If you know Go, it is very easy to pick up but don’t expect it to be exactly like go and it has its own idioms.

Note: I’m interested in V but not involved in V development.

I like many things about the language but haven’t yet written a significant amount of code in it to properly evaluate it. V feels a lot like Go. Plus a language that can replace C/C++ for bare metal programming.

Processor "optimizations" can produce surprising effects. The problem is these optimizations are not programmatically accessible to C (or most modern programming languages) given their simple memory model. Deterministic performance is not easy to obtain. My view is to not bother with such tricks unless absolutely necessary (and be prepared that your changes may actually pessimize performance on a future processor or a compatible processor by a different vendor).

If you are interested in this sort of thing, check out comp.arch!

From a Guardian article: A Foreign Office spokesperson said: “Since 2015 the UK has given no financial aid to the government of India. Most of our funding now is focused on business investments which help create new markets and jobs for the UK, as well as India. UK investments are also helping tackle shared challenges such as climate change.”

https://www.theguardian.com/global-development/2023/mar/14/u...

One consequence of this in nvi (& IIRC vi) you can do <n>i<txt><esc> to repeat <txt> <n> times, just as you can repeat most any command with prefixing it with a count.

Which part? Designing or implementing or something else?

I'd love to see an OS with a Unix API but plan9 like kernel! I will never get around to writing one myself though!

Thanks. rxv64 kernel (the much harder part), syslib and ulib are in rust. Replacing userland C with rust would not be hard. Ideally a general purpose OS should support programs written in any of the common programming languages so it would make sense to have some programs in another language to keep the OS API "honest"!

How does this compare with https://github.com/dancrossnyc/rxv64 ? From its README.md:

rxv64 is a pedagogical operating system written in Rust that targets multiprocessor x86_64 machines. It is a reimplementation of the xv6 operating system from MIT.

Behlendorf's comment in that thread seems to be talking about linux integration. My point was this is an older issue, going back to the Sun days. See for instance this thread in where McVoy complains about the same issue! https://www.tuhs.org/pipermail/tuhs/2021-February/023013.htm...

I suspect the underlying issues for not unifying the two have more to do with the ZFS design than anything to do with Linux. It may be the codebase is far too large at this stage to make such a fundamental change.

Is integrating ARC with the page cache a lost cause? If not, may be Netflix can fund it!

They could have just asked.... Most who grew up in the subcontinent know this.

Not sure what kind of problem you are talking about but there are a few things you can try:

Look at it from different angles to understand the problem better. Understand its properties better.

Look for its underlying causes. That is, may be you need to solve different problems!

Nibble at it. That is, solve sub problems so that you are left with a smaller (but possibly harder) problem.

Work on them subconsciously. That is, when you learn something new, let it sink in by walking away and doing something else.

Conversely, focus on the problem 100% when you are working it. If necessary, block out all distractions, including mental ones.

Look at it from a potential solution point of view. That is, if there is a solution, think of what properties it must have.

Never give up! Assuming the problem is worth solving.

Conversely, try to prove it is unsolvable so that you give up on it ASAP!

Keep notes and review them often. You may find clues in something you have already noted.

Try to explain the problem, what you have learned and your attempts to an interested person who can act as your sounding board. The process of explaining will force you to organize your thoughts and the other person can ask questions that will force you to think about cases you may not have considered. Without a sounding board and without writing down your observations you may end up going in circles.

Nothing wrong with spending one's life building a boat if that is what floats your boat. It is the journey, not the destination, where you spend the most time so might as well make it a happy one!

The idea is quite old -- See for instance https://en.wikipedia.org/wiki/Formal_methods

For an example see https://en.wikipedia.org/wiki/Vienna_Development_Method#Bank...

The idea is to model the key aspects as mathematically rigorously as possible while ignoring lower level details. But even if you are not as rigorous, the process of creating such a model can help clarify things. As an example, if you are developing a file system you can abstractly define operations on it (read, write, create file, dir, etc.) and one can come up with a huge number of implementations satisfying this but as you add other requirements or constraints, quite a few choices are no longer meaningful. For example you want to implement a FS that takes advantage of NVMe SSDs, they put certain constraints. So then you need a model for an SSD (erase blocks are multiples of data blocks, write must be preceded by erase, etc. etc.). The idea is to model all this using a few abstract data types and state. You need not strive to programmatically derive an implementation from such a spec for it to be useful.

There is a third way: define, explore and build a model of the problem space your program is supposed to be addressing. This forces you to understand its properties much better. Once you understand it better you can likely implement in any of the common programming languages. This is also why I like languages like Scheme or APL or k for exploration.

Often the UI addresses only a subset of this space -- it is only the visible part of the iceberg as it were! There is a lot going on under the UI surface. Not to mention you may want more than one (kind of) UI.

how would the “rape culture” be influenced by india stopping its space program?

This is like saying the US should stop spending money on lots of things until the gun violence problem is solved.

Thanks! In Gujarati we call it "meettho limdo" or sweet neem. It is dark green but not black (except when left in the 'frig for a few days or on the plant when it is sick!).

Supposedly curry comes from the tamil word (transliterated as) "kaRi" which may be related to black pepper (native to India) to spice things up. In all Indian languages the color black has a very similar name (in Gujarati Kāḷī (feminine) or kāḷo (masculine) etc. -- also the goddess Kāli -- the one who is black or death!). More generally associated with something burnt (blackened). Anyway, a spicy sauce would be kaRi. In restaurants in South India you may find various dishes named curry (such as kozhi curry or kozhi kari). But when most everything is spicy, why even say that? Indians would rather know what is in a recipe than how it tastes! [Lot of speculation here: perhaps some knowledgeable Tamil will correct this without getting all upset!]

I should also point out "curry leaves" -- not sure if there is a connection with curry. They are not spicy but are put in many Indian dishes to give them a certain flavor.

Recently I became aware of “FAC: A Functional APL Language” a 1986 paper by Hai-Chen Tu and Alan Perlis[1]. Unlike traditional APLs it allows you to define your own “operators” (second order functions), such as “x (F SWAP) y: y F x”, where x and y can be congruent arrays. It even allows infinite arrays, which can be evaluated lazily and provides a powerful operator on them (let’s call it “$”) such that “1 (+ $) 1” is the Fibonacci sequence! Since FAC functions are pure, in principle you can evaluate things in parallel.

It occurs to me that operators can be considered connectors!

[1] https://ieeexplore.ieee.org/document/1695470

Very rarely jain monks would fast unto death (sallekhana), but not set themselves on fire, as that would be considered a form of violence. And ahimsa (non-violence) is absolutely fundamental to Jainism. Sallekhana would be somewhat akin to maha-samadhi in Hinduism (where the person leaves their body after attaining samadhi). The Śramana (श्रमण) tradition is more common in Jains but can also be in Buddhists.

I don't think the author is necessarily excluding FP as much as saying intrinsically it doesn't provide anything more than functional composition for what the author calls "architecture oriented programming". That is, while "structured programming" mainly focused on on modularity, how these components are connected (and communicate) is equally important. At least that is what I got from the article!

I think the author is saying that in order to build larger structures out of modular structures you connectors (you can think of glue as one kind). As an example think of the many different connectors that Lego Technic provides. Unix pipes can be considered connectors as well. So can tcp/ip connections (for the largest distributed system in the world, the Internet).

> James Gosling, being much older than I was, he had lots of experience with SmallTalk and Simula68, which we also borrowed from liberally.

Simula67. It was an almost superset of Algol60 & had nothing to do with Algol68. Smalltalk was also influenced by Simula67.

Not even that as it doesn't have function calls or even print!

See Feeley's response for the proper context.

This doesn't have types, functions, arrays or much error checking. It has one char identifiers. I don't think we should read into this any more than a tiny example or experiment by the author.

May be not with filesystem semantics but I would think providing atomic updates would be a very useful thing.