scott_s

I think you overestimate the ability of a tiny community of curators to generate examples to meet the curiosity of students.

My first program was indeed C++. In 1998, my high school had a computer lab setup with Turbo C++, and I took a non-AP computer science class. In college, starting in 1999, after entering as a computer science major, we were guided to use Visual C++ on Windows. We got Visual C++ from our department - I can't remember if we paid or if it was just provided to us.

I actually think Scratch is fine for 10ish year olds, mainly because all of my above holds true: scratch.mit.edu is an online community where kids can copy, tweak and in general be inspired by and learn from what other kids have done. Your universe can expand with your curiosity. When my nephew was 10, he started with Scratch. My brother guided him towards using Python on a Raspberry Pi soon after.

For kids around 10, I think it's all about what the kid thinks is more fun.

I find the core position of the author unconvincing - that is, the author advocates for non-professional languages for beginners, instead using languages designed specifically for teaching. The main argument put forward in favor of professional languages is crossover: if a student learns a language in class, they may be able to use that language professionally. The author then argues against that main point.

I think students should be taught in "professional" languages, but crossover is not my main reason. Rather, it's that professional languages have an enormous corpus of examples that students can look up. If a student is learning on a teaching language without much adoption, there's just not much else a student can do but use the materials that part of the course. Teaching languages don't let students expand their universe of examples.

I agree with the author's point about real insight coming on learning the second (and third, etc.) language and systems. But I don't find it as a compelling point in favor of teaching languages - quite the opposite. To me it means there's no need to obsess over first languages.

Designing programming languages is fun. Designing a programming language which meets some platonic ideal of teachability is moreso because it feels possible to "solve" the design and craft the perfect jewel of a language. But I'm unconvinced it's useful research.

For the record, my first language was C++, and I'd default to teaching beginners in Python.

Allocating virtual memory is distinct from actually consuming physical memory (RAM).

If a process allocates many pages of virtual memory, but never actually reads or writes to that memory, then it's unlikely that any physical memory backs those pages. In this sense, allocating memory is really just bookkeeping in the operating system. It's when you try to read or write that memory that the operating system will actually allocate physical memory for you.

When you first try to access the virtual memory you've allocated, there will be a page fault, causing the OS to determine if you're actually allowed to read or write to it. If you've previously allocated it, then all is good, and the OS will allocate some physical memory for you, and make your virtual memory pointers point to that physical memory. If not, well, then that's a segfault. It's not until you first try to use the memory that you actually consume RAM.

Agreed with the technical content and conclusion. However, I think it is worth pointing out that since C++11, it has had a mechanism to specify (maybe) compile-time computations that are written in plain C++: constexpr, https://en.cppreference.com/w/cpp/language/constexpr

(My parenthetical "maybe" is that I don't think compilers have to compute constexpr expressions at compile time. The compiler will be forced to when such expressions are used in contexts that require values at compile time. But I think it would be permissible for a compile to defer computation of a constexpr to runtime if the value isn't needed until runtime.)

Yes, the technique is obviously predated by Ultima Online. The question we're trying to answer is specifically about the etymology of sharding in the database context.

I found that paper title as well when looking into this exact question. That paper does not have the number of citations I would expect if it is the source of the term. It's possibly the source, but it's not obviously the source.

Potentially. I was also skeptical of this four years ago, and said as much on here (https://news.ycombinator.com/item?id=22972538).

However, I then dug into it a bit. From my digging 4 years ago (https://news.ycombinator.com/item?id=23460200):

> I spent some time crawling through the proceedings of Very Large Databases (VLDB) and the ACM Digital Library, and I could find no instances of "shard" used to mean the partitioning of a database prior to 2001. (That paper is "Minerva: An automated resource provisioning tool for large-scale storage systems" in Transactions on Computer Systems, free-to-read at https://dl.acm.org/doi/abs/10.1145/502912.502915.)

> Other the other hand, I found many papers citing the SHARD paper - more than the official count. That's a difficulty with citation counts of old papers: a lot of the papers citing it are also old papers, and we're not consistent at tracking the citations of old papers. Personally, I don't have a conclusion. The SHARD paper is decently cited, and its usage is close to the modern one. On the other hand, I can't find any smoking gun pre-1997 usage of "shard" in the modern meaning.

I started my digging thinking I would quickly find a paper using "shard" in the modern database context that predated Ultima Online. I could not find it, so now I think it's plausible.

I'm less likely to continue this conversation over email. Such is life. :)

I think that bringing in CSS is a bridge too far for the case of writing a book. Authors are no longer just writing HTML, they're writing HTML and CSS. And CSS is intimately tied to actual web browsers - you're now going to need a browser display engine to be an integral part of how you render your book. (Or you're going to need to implement just enough of that yourself, which is a big undertaking.)

The point of comparison is Markdown, which is relatively straight-forward and simple. HTML and CSS is not that.

That construct has been called a “record” since, I believe, 1970 in Pascal.

If I understand you correctly, you want to throw out rST, and just have users write HTML directly? I see two issues with that:

1. HTML is designed for representing webpages, not books. Your intermediate representation will become HTML's DOM, which is likely not well suited to the book use case. You'll either need to use an existing HTML-to-DOM parser or build your own. One big limitation of the DOM, as I see it, is that it doesn't have the concept of a page number.

2. HTML is not extensible in the way the author talks about. This is the "semantic linking" thing I meant. In rST, you can define entirely new top-level constructs: he defines an exercise which has a solution and will be a part of a solution list. The semantic linking part is that other parts of the document will refer back to these solutions. Some output formats will have all solutions inline, with the exercises, while other output formats will collect all solutions in one place at the end. HTML is not flexible in that manner.

What is extensible is XML. It's entirely feasible for XML to be the input, but for better-or-worse, most people are even more turned off by XML than they are by something like rST.

I love the code-first approach. It was a revelation to me when I first read Mark Pilgrim's Dive Into Python (https://diveintopython3.net/).

In case the author reads this: please explicitly cite all of Nystrom's figures. A link is not enough.

Even with a citation, I'm not quite comfortable just reusing someone else's figures so many times when they're doing so much heavy lifting. But an explicit citation is the minimum.

The author wrote an entire article explaining their use case which answers your question. Short version: they’re writing a book which they want to render to multiple formats with semantic linking between items and different rendering based on formats.

First, "computer engineering" is already a name for an established discipline. And regarding academic computer scientists, a significant amount of them are on the "systems" side; it would be inaccurate to call their work a specialization of math.

A similar thing happened to me recently with Target. What I received was obviously damaged, broken seal, broken canister, formula spilling out. I initiated a "damaged product" problem, and they wanted me to return it. So I dumped the rest, rinsed it, and returned an empty can to a physical Target store. The clerk was confused, but they didn't challenge me on it. I got the refund.

(I started ordering the formula online because there was a severe shortage recently due to a potentially contaminated batch. Finding it in a physical store was not possible for a while, and not practical even when it was available.)

I read the article, and I think the take you're replying to is still valid. As a company, you need good quality control. What this incident reveals is that Amazon does not do good quality control. If you outsource that part of your business to Amazon, your business has an existential risk.

Any source on that? It sounds unlikely to me. There was a supercomputer that IBM built for Los Alamos that used the Cell processor: https://en.m.wikipedia.org/wiki/Roadrunner_(supercomputer)

Yes. My research lab in grad school had a cluster of 24 PS3s. The back of that rack was hot.

I found the arguments compelling. The discussion on "Effective types" and C not having a proper concept of objects is key.

Another way to think about it: even if you had defined constructors and destructors for a struct, you have not solved when to call them. C++'s answer to that question is its sophisticated object model. C does not have one, and in order to answer that question, it must. It's worth noting that RAII was not a feature that was intentionally created in C++. Rather, astute early C++ developers realized it was a useful idiom made possible by C++'s object model.

Many computer scientists could literally show you a git history. All of the papers I have written were done so in Latex, and tracked in some version control system. More recent ones have been git.

Ah, in my context, N is the number of live allocated objects that the memory allocator knows about. If you use a data structure like a red-black tree to track the metadata, the work you do traversing and maintaining the tree will grow log N with the number of live allocated objects you're tracking. The radix tree specialization I presented is constant with respect to the number of live allocated objects.

I'm really not sure what you're overall point here is. Yes, I agree with you. Your function is O(2^64) which is technically O(1). Your point, which I agree with, is that's completely useless information. It does not help our understanding of performance at all. Calling such a function O(1) is technically true, but both misleading and not informative. What I'm not clear on is how that relates to the discussion we're having here.

The original poster said they wanted a O(1) solution to a problem. I presented one. That solution happens to be based on a data structure whose algorithms are, in the general case, O(log n). But we're not dealing with a general case, we're dealing with a specific case. And because of that specific case, we can write algorithms that are O(1). Unlike your example, these algorithms have a very small n; 3, to be exact. That is meaningful to describe as O(1) in this case because we can reduce the work down to a small constant.

This function is O(1): https://github.com/scotts/streamflow/blob/master/streamflow..... All other tree operations are also constant, because the fact that it is a 3-level tree is hardcoded.

Asymptotic bounds are useful when your input can grow arbitrarily large. When your input is fixed, the bounds become less useful and you should focus on the particulars of your case. In the case I'm presenting, the work done traversing the tree will be the same every time; it is O(1). That doesn't necessarily mean it's fast enough! It still may do too much work for the use case. For instance, I can imagine someone saying that the function above does too much pointer chasing for their use case.

> In a general purpose allocator, you can just store allocation metadata next to a payload so the lookup from a pointer address becomes O(1).

Yes, but the downside is that now allocator metadata pollutes the cache. It's super efficient for the allocator, but it may harm efficiency of the actual use of that memory. I believe most production allocators don't use object headers for this reason.

> For that it would be necessary to make a reverse lookup from pointer address to allocation handle, which would require something like a red-black tree covering the address space, which would no longer be 0(1). If anyone has ideas on this front, I would be happy to hear them.

A radix tree can solve this: https://en.wikipedia.org/wiki/Radix_tree

I used one way, way back to do exactly the same thing: upon a free, I needed to look up all of the metadata for an address. For a 32-bit address space, you can just allocate a giant array up front, and use the address as an index. For a 64-bit address space, it's obviously way too big to statically allocate it up front. A radix tree neatly solves the problem. An arbitrarily sized radix tree is not constant lookup, but for reasons I honestly cannot remember, for a 64-bit address space, it's guaranteed to only be 3 levels deep.

See my implementation, which (I believe) I borrowed from tcmalloc: https://github.com/scotts/streamflow/blob/master/streamflow....

No disagreement here. Do you think your point is in conflict with mine?

I'm not saying balance was a problem - quite the opposite. It turns out balance is not a problem. I'm saying that in a world without bicycles, I don't think it's obvious that balance is not a problem. My point is that I find it quite reasonable that people just didn't even think about a two-wheeled vehicle for a long time because it's not obvious that it will be stable.

What people did try to make work was a four-wheeled cart, which I think is in line with a tricycle. I also agree there were other factors - I think there is no single answer to this question, but rather a constellation of factors. My claim is that I believe it reasonable to include people's lack of imagination that two-wheels could work in that list of factors.

I think the author should give more credence to it not being intuitive that people could easily learn to balance on a bicycle. The other examples he gave - horse, canoe - are stable without a rider. If you put a canoe in the water, it will stay upright. Horses, obviously, are stable without a rider. A bicycle without a rider will fall over.

I don't think it's obvious that putting a human on a long, two-wheeled vehicle will make it more stable than that vehicle is on its own. I think it's also not obvious that most humans can quite easily and quickly learn how to balance a bicycle.