cb321

There is no direct argument/guidence that I saw for "when to use them", but masked arrays { https://numpy.org/doc/stable/reference/maskedarray.html } (an alternative to sentinels in array processing sub-languages) have been in NumPy (following its antecedents) from its start. I'm guessing you could do a code-search for its imports and find arguments pro & con in various places surrounding that.

From memory, I have heard "infecting all downstream" as both "a feature" and "a problem". Experience with numpy programs did lead to sentinels in the https://github.com/c-blake/nio Nim package, though.

Another way to try to investigate popularity here is to see how much code uses signaling NaN vs. quiet NaN and/or arguments pro/con those things / floating point exceptions in general.

I imagine all of it comes down to questions of how locally can/should code be forced to confront problems, much like arguments about try/except/catch kinds of exception handling systems vs. other alternatives. In the age of SIMD there can be performance angles to these questions and essentially "batching factors" for error handling that relate to all the other batching factors going on.

Today's version of this wiki page also includes a discussion of Integer Nan: https://en.wikipedia.org/wiki/NaN . It notes that the R language uses the minimal signed value (i.e. 0x80000000) of integers for NA.

There is also the whole database NULL question: https://en.wikipedia.org/wiki/Null_(SQL)

To be clear, I am not taking some specific position, but I think all these topics inform answers to your question. I think it's something with trade-offs that people have a tendency to over-simplify based on a limited view.

I tried to defend you against a hard to support "most people didn't want this" with a workload (either static or dynamic) assertion. You come back saying you don't need such charitability while simultaneously clarifying in terms of a static workload! Seemingly, "most written C++" (again charitably moving from "people writing" to "written code" because the latter is probably more relevant and surely more auditable/studyable - "source code files easier than people").

I think you should be more careful about claiming you know what people want or know. Many people I know don't seem to know what they want.. it's some melange of desiderata with various eternal tensions. As just one example, I would doubt most people even want performance above all else. I really doubt most people understand well how their various static and dynamic workloads relate to their performance. I doubt I'm alone in having known many C++ programmers who, from spoken conversation, revealed they thought STL map was a hash table, for example.

I only said "one of the main" and almost added "with pointer stability being the bigger", but it had already been observed by rurban. Delete-while-iterating has close ties with cell motion (though convoluted workarounds may exist, they may well cost more than you personally would like, it sounds). How to best explain all these things is always questionable, but I was trying to supplement. It's generally not easy without visual aids and definitely not if people are being combative. Python has ever & always since the late 80s used open addressing but only more recently tried to `raise` on dict edits during iterations.

It seems to be flip-flopping that you are now calling separately chained hash tables a "weird container type" when 3 months ago it seemed to be news to you that they were NOT the main strategy for decades before open addressing on some Nim -ish comment on a Carbon thread: https://news.ycombinator.com/item?id=44754821

Anything else I would say, such as Stepanov not even choosing a hash table in the first place, gpderetta said very well in a sibling. For the record, I still very much disagree with the early (& later) design of the STL and am no fan of WG21. Have a good weekend.

There is also https://en.wikipedia.org/wiki/HumancentiPad (which is almost surely an homage to the movie) which was 2011 and tied in all kinds of tech-aspects like licensing and iPads.

Indeed. One of the main reasons STL defaults to a non-moving hash table is because "deleting in the middle of an iteration" was viewed as an important property. Like it or not (I do not), the entire container part of the original 1990s Stepanov STL was oriented around "iteration/iterators" as the high priority abstraction.

Trying to think like a DB engineer is probably helpful here. Point or range query workloads absolutely afford different optimization/specializations than full table scan iterations.

Any mistake here is more in thinking "one size fits all workloads". That may as much be a mistake of user communities as of language designers. (E.g. 'expert' advice like "just always use X" instead of "well, it depends...".) So, the charitable reading of tialaramex's "most people" is a weakly articulated assertion about workloads (though I absolutely agree with your specific point).

For a while now, I've been summarizing the ease with which everything turns into a "Humanity Complete" problem via: "Delegation affords so much, but trust sure is tricky."

This has been observed forever in various forms/contexts. Planning & policy people call them "Wicked Problems" (https://en.wikipedia.org/wiki/Wicked_problem). The Philosophy of Science one goes by the Demarcation Problem (https://en.wikipedia.org/wiki/Demarcation_problem) { roughly, in the sense that the really hard nugget connects to "trust" }.

At least one aspect of all of it is that trust is a little like money/capital and "faking it" is a bit like "stealing". The game theory of it is that since faking is virtually always vastly cheaper there are (eventually) huge incentives to do so, at some point by someone(s). So, almost any kind of trust/delegation structure has a strong pull toward "decay", from knock-off brands to whatever. It just takes a sadly small fraction of Prisoner's Dilemma defectors to ruin things/systems thereof. 2nd law of thermo makes order cost energy and this decay feels like almost an isomorphic (maybe even the same..?) thing. It's not just product/tech enshittification, but that might be yet another special case/example.

Anyway, I have no great answers or as some responder to me a while back said, if I did, I'd "have a Nobel and possibly be the first president of the united planet".

As a slight refinement of your point, C does have storage map based N-D arrays/tensors like Fortran, just with the old column-major/row-major difference and a clunky "multiple [][]" syntax. There was just a restriction early on to need compile-time known dimensions to the arrays (up to the final dimension, anyway) because it was a somewhat half-done/half-supported thing - and because that also fit the linear data model well. So, it is also common to see char *argv[] like arrays of pointers or in numerics sometimes libraries which do their own storage map equations from passed dimensions.

Also, the linear memory model itself is not really only because of Algol/Turing machines/theoretical CS/"early" hardware and mechanical sympathy. DRAM has rows & columns internally, but byte addressability leads to hiding that from HW client systems (unless someone is doing a rowhammer attack or something). More random access than tape rewind/fast forward is indeed a huge deal, but I think the actual popularity of linearity just comes from its simplicity as an interface more than anything else. E.g.s, segmented x86 memory with near/far pointers was considered ugly relative to a big 32-bit address space and disk files and other allocation arenas have internally a large linear address/seek spaces. People just want to defer using >1 number until they really need to. People learn univariate-X before they learn multivariate-X where X could be calculus, statistics, etc., etc.

Like Python, R is a 2 (+...) language system. C/Fortran backends are needed for performance as problems scale up.

Julia and Nim [1] are dynamic and static approaches (respectively) to 1 language systems. They both have both user-defined operators and macros. Personally, I find the surface syntax of Julia rather distasteful and I also don't live in PLang REPLs / emacs all day long. Of course, neither Julia nor Nim are impractical enough to make calling C/Fortran all that hard, but the communities do tend to implement in the new language without much prompting.

[1] https://nim-lang.org/

You might enjoy https://nim-lang.org/ which has a Python-like syntax with even more flexibility really (UFCS, command-like calls, `fooTemplate: stuff` like user-defined "statements", user-defined operators, term-rewriting macros and more. With ARC it's really just about as safe as Rust and most of the stdlib is fast by default. "High quality" is kind of subjective, but they are often very welcoming of PRs.

Anyway, to your point, I think a newbie could pick up the basics quickly and later learn more advanced things. In terms of speed, like 3 different times I've compared some Nim impl to a Rust impl and the Nim was faster (though "at the extreme" speed is always more a measure of how much optimization effort has been applied, esp. if the language supports inline assembly).

https://cython.org/ , which is a gradually typed variant of Python that compiles to C, is another decent possibility.

"Popularity" probably has more to do with Apple moving to Zsh than anything else. Zsh has been more powerful than Bash for literally the entirety of the existence of both. It surely was back in like 1993 when I first looked at them. The "emacs of shells" might not be the worst summary.

Fish is a more recent addition, but I hate its `for loop` syntax, seemingly copied from BSD C Shell, which this Ion shell seems to have copied (or maybe Matlab or Julia?). Baffles me to impose a need for `end` statements in 2025. In Zsh, for a simple single command, I need only say `for i in *;echo $i` - about as concise as Python or Nim. In the minimalism aesthetic, Plan 9 rc was nicer even before POSIX even really got going (technically POSIX was the year before Plan 9 rc) for quoting rules if nothing else.

I think it's more insightful to introspect the origins of the "choosing something outside bash" rule you mentioned. I think that comes from generic "stick to POSIX" minimalism where Bash was just the most commonly installed attempt to do only (mostly) POSIX shell.. maybe with a dash of "crotchety sysadmins not wanting to install new shells for users".

Speaking of, the dash shell has been the default on Debian for a long while. So, I think really the rule has always been something "outside POSIX shell", and its origins are simply portability and all those bashisms are still kind of a PITA.

These are all big topics, but any "parametric curve fitting" like this tool uses is parameter estimation (the parameters of the various curves). That already makes strong modeling assumptions (usually including IID, Gaussian noise, etc.,) to get the parameter estimates in the first place. I agree it would be even better to have ways to input measurement errors (in both x- & y- !) per your example and have non-bootstrap options (I only said "probably"), residual diagnostics, etc.

Maybe a residuals plot and IID tests of residuals (i.e. tests of some of the strong assumptions!) would be a better next step for the author than error estimates, but I stand by my original feedback. Right now even the simplest case of a straight line fit is reported with only exact slope & intercept (well, not exact, but to an almost surely meaningless 16 decimals!), though I guess he thought to truncate the goodness of fit measures at ~4 digits.

The fit diagnostics at the top of the plot are inadequate. This needs at a minimum error estimates on the estimated parameters (probably bootstrap) and ideally some kind of "error envelope" on the plot.

Any article about this topic that does not at least mention https://arcan-fe.com/about/ feels incomplete. (Also, Arcan is already available.)

"Great" smells very subjective. I went to https://forum.nim-lang.org/ . Put "flask" in the search box. Second hit (https://forum.nim-lang.org/search?q=flask) is this: https://forum.nim-lang.org/t/11032 . That mentions not one but 2 projects (https://github.com/HapticX/happyx & https://github.com/planety/prologue).

If either/both are not "great enough" in some particulars you want, why not raise a github issue? (Or even better look into adding said particulars yourself? This is really the main way Python grew its ecosystem.)

Besides your chart, another point along these lines is that the article cites Azhar claiming multiples are not in bubble territory while also mentioning Murati getting essentially infinite price multiple. Hmmmm...

I can confirm that I just do it over ssh fine all the time -- gnuplot, img2sixel as an "image-cat", etc. (`st` with patches to add sixel support as discussed in various places in these comments.)

I 100% agree `st` is pretty great and comparing bare bones is unfair.

Thanks for that link! I suppose I should have provided a link to the variant I use which is https://github.com/bakkeby/st-flexipatch though I do have like 14 of my own private patches. :-) Because it really is a simple, hackable codebase.

I will say, though, that I doubt there are many unicode conformance patches floating about. I don't know though, and I haven't looked.

`st` used to have a patch set for sixel graphics on its web site. I use an old version all the time to do gnuplots in terminals with nice scrollback. It seems to have been retired in favor of the kitty graphics protocol.

While I agree with everything you wrote, the "better ways" have a "cap" on how effective they can be. The root causes -- both in-group preference[1] and laziness/delegation to the "smart loudmouth contemporaries/smart-enough predecessors" -- will be things for the foreseeable future among humans. Some might even call them eternal / instinctive. Our whole civilization is based upon delegation/layering, but trust sure is tricky! Even the smartest humans fall prey to Gell-Mann amnesia[2] on topics beyond their expertise. Personally, I think most of what you wrote all connects to the cluster of wicked problems[3] that I think of as "Humanity Complete" (after NP-Complete transformability).

[1] https://en.wikipedia.org/wiki/In-group_favoritism

[2] https://en.wikipedia.org/wiki/Gell-Mann_amnesia_effect

[3] https://en.wikipedia.org/wiki/Wicked_problem

Since anything/0 = infinity, these kinds of things always depend upon what programs do and as a sibling comment correctly observes how much they interfere with SIMD autovectorization and sevral other things.

That said, as a rough guideline, nim c -d=release can certainly be almost the same speed as -d=danger and is often within a few (single digits) percent. E.g.:

    .../bu(main)$ nim c -d=useMalloc --panics=on --cc=clang -d=release -o=/t/rel unfold.nim
    Hint: mm: orc; opt: speed; options: -d:release
    61608 lines; 0.976s; 140.723MiB peakmem; proj: .../bu/unfold.nim; out: /t/rel [SuccessX]
    .../bu(main)$ nim c -d=useMalloc --panics=on --cc=clang -d=danger -o=/t/dan unfold.nim
    Hint: mm: orc; opt: speed; options: -d:danger
    61608 lines; 2.705s; 141.629MiB peakmem; proj: .../bu/unfold.nim; out: /t/dan [SuccessX]
    .../bu(main)$ seq 1 100000 > /t/dat
    .../bu(main)$ /t
    /t$ re=(chrt 99 taskset -c 2 env -i HOME=$HOME PATH=$PATH)
    /t$ $re tim "./dan -n50 <dat>/n" "./rel -n50 <dat>/n"
    225.5 +- 1.2 μs (AlreadySubtracted)Overhead
    4177 +- 15 μs   ./dan -n50 <dat>/n
    4302 +- 17 μs   ./rel -n50 <dat>/n
    /t$ a (4302 +- 17)/(4177 +- 15)
    1.0299 +- 0.0055
    /t$ a 299./55
    5.43636... # kurtosis=>5.4 sigmas is not so significant

Of course, as per my first sentence, the best benchmarks are your own applications run against your own data and its idiosyncratic distributions.

EDIT: btw, /t -> /tmp which is a /dev/shm bind mount while /n -> /dev/null.

While it's ecosystem probably does not even match Julia's let alone Python's or the C/FORTRAN-verses, since Nim has been around for almost 20 years and publicly since 2008, there are still a lot of accumulated packages. Some are listed at: https://github.com/ringabout/awesome-nim for really a large (and even so still incomplete!) list of things you might be interested in. Hard to say how well maintained they are. That said, you do probably have to be prepared to do a lot of work yourself and work around compiler limitiations/bugs. Also, binding to C libs is very straightforward with a near trivial FFI.

I suppose it very much depends on the programmer & setting, but like 3 times I've looked for Rust projects similar to Nim ones and found the performance of the Rust quite lacking. Of course, any language that allows you access to assembly makes things ultimately "only" a matter of programmer effort, but the effort to get performance out of Nim seems very competitive in my experience. I've seen at least one ancient 1990s C project be more flexible and much faster in Nim at like 6% the LOC (https://github.com/c-blake/procs for the curious).

Actually echo is not a statement - Nim's syntax is just much more flexible than Python so what looks like a statement in Python is actually just a UFCS/Command-Line "call" (of macro/template/generic/procedure aka "routine"). It is super easy to roll your own print function [1] and there is no penalty for doing so except that the std lib does not provide a "common parlance". So, that wheel might get reinvented a lot.

A lot of things like this in cligen because it is a leaf dependency (the literally 1..3 identifier CLI "api") and so many "drive by" PLang tester-outers might want to roll a little CLI around some procs their working on.

Also, beyond the echo x,y is same as echo(x,y) or x.echo(y) or x.echo y, the amount of syntax flexibility is dramatically more than Python. You can have user-defined operators like `>>>` or `!!!` or `.*`. There are also some experimental and probably buggy compiler features to do "term re-writing macros" so that your matrix/bignum library could in theory re-write some bz*ax+y expression into a more one-pass loop (or maybe conditionally depending upon problem scale).

I sometimes summarize this as "Nim Is Choice". Some people don't like to have to/get to choose. To others it seems critical.

Someone even did some library to make `def` act like `proc`, but I forget its name. Nim has a lot more routine styles than Python, including a special iterator syntax whose "call" is a for-construct.

[1] https://github.com/c-blake/cligen/blob/master/cligen/print.n...

Nim compile+link times can be sub-100 milliseconds with tcc [1] (just saw 93 ms on my laptop) which can yield pretty reasonable edit-compile-test cycles.

The grandparent's scientific/Go interests suggests a need for a large, working ecosystem and there are probably several places in ArrayMancer which need some love for "fallback cases" to work with tcc (or elsewhere in the as you note much smaller Nim eco-system).

EDIT: E.g., for ArrayMancer you need to make stb_image.h work with tcc by adding a nim.cfg/config.nims `passC="-DSTBIW_NO_SIMD -DSTBI_NO_SIMD"` directive, though. And, of course, to optimize compile times, just generally speaking, you always want to import only exactly what you really need which absolutely takes more time/thought.

[1] https://github.com/TinyCC/tinycc

I mentioned a knob - it did the trick with literal mechanical friction { instead of electrical friction = potentiometer :-) }.

All very true and "balk en masse" is what I meant by "first exposé". (Ancient wisdom, even, if you think about individuals and mortages/car loans and having a steady job, etc. rather than just businesses.) Maybe we'll anyway see some market segments succeed with "pay 2x more for your screwdriver, but it will at least be your screwdriver" slogans, and then have screwdrivers to do with what we will, like the proverbial "pound sand". ;-)

I'm not an expert on the case law, but supposedly United States v. General Electric Co. et al., 82 F.Supp. 753 (D.N.J. 1949) indicates that whatever design trade-offs might have existed, corporate policy makers were really just trying to screw consumers [1] (which is why they probably had to agree on short lifespans as a cartel rather than just market "this line of bulbs for these preferences" vs. "this other line for other people" -- either as a group or separate vendors). I keep waiting for the other shoe to drop where they figure out how to make LED bulbs crappy enough to need replacement.

EDIT: and, shucks, @kragen beat me to it! :-)

[1] https://en.wikipedia.org/wiki/Phoebus_cartel#cite_ref-USvGE-...

I would say the situation is worse as this "subscription-esque" model is "spreading" to areas beyond software. Exercise equipment like ellipticals and bicycles - whose software is/could be borderline +/- resistance level trivial - has been moving to "only works with an online subscription" business models for a long time.

I mean, I have had instances that controlled resistance with like a manual knob, but these new devices won't let you set levels without some $30+/month subscription. It's like the planned obsolescence of the light bulb cartels of the 1920s on steroids.

Personally, I have a hard time believing markets support this kind of stuff past the first exposé. I guess when you don't have many choices or the choices that you do have all bandwagon onto oligopoly/cartel-like activity things, pretty depressing, but stable patterns can emerge.

Heck, maybe someone who knows the history of retail could inform us that it came to software "from business segment XYZ". For example, in high finance for a long-time negotiated charging prices that are a fraction of assets under management is not uncommon. Essentially a "percent tax", or in other words the metaphorical "charging Bill Gates a million dollars for a cheeseburger".

EDIT: @terminalshort elsethread is correct in his analysis that if you remove the ability to have a platform tax, the control issues will revert.

Being truly unordered like a set is not something you can do in a physical computer program unlike a mathematical abstraction. Anything stored is "ordered" in some way, either explicitly by virtual (or physical) memory addresses or implicitly by some kind of storage map equation (like a bitmap/bitvector or N-D C/Fortran array). It just might not be a useful ordering. (I.e., you may have to loop and compare.)

One might qualify such as "system-ordered", or in the Python insert-ordered dict, qualify with "insertion-ordered", though hash tables in general are sort of a melange of hash-ordering. The same container may also support efficient iteration in multiple orders (e.g., trees often support key order as well as another order, like VM/node pool slot number order).

So, in this context (where things are obviously elements of a computer program), it isn't obvious that hair-splitting over ordered vs. sorted in their purest senses is very helpful when what is really missing is qualification.

Of course, like in many things, people tend to name computer program elements after their abstractions. This is where confusion often comes from (and not just in computing!) .. borrowing the names without all the properties (or maybe with more properties, as in this case, though that is all probably a bit iffy with the frailty of how you enumerate/decompose properties).

EDIT: In a similar way, in a realized computer, almost any "set" representation can also be a "map". You just add satellite data. Even a bit-vector can have a "parallel vector" with satellite data you access after the bits (which could even be pointful in terms of cache access). This can cause similar confusions to the "ordered" vs. "sorted" stuff.

I used to do this, but unary kind of sucks after 3; So maybe others might like this better before their fingers get trained:

    ..() { # Usage: .. [N=1] -> cd up N levels
      local d="" i
      for ((i = 0; i < ${1:-"1"}; i++))
        d="$d/.."  # Build up a string & do 1 cd to preserve dirstack
      [[ -z $d ]] || cd ./$d
    }

Of course, what I actually have been doing since the early 90s is realize that a single "." with no-args is normally illegal and people "cd" soooo much more often than sourcing script definitions. So, I hijack that to save one "." in the first 3 cases and then take a number for the general case.

    # dash allows non-AlphaNumeric alias but not function names; POSIX is silent.
    cd1 () { if [ $# -eq 0 ]; then cd ..; else command . "$@"; fi; } # nice "cd .."
    alias .=cd1
    cdu() {           # Usage: cdu [N=2] -> cd up N levels
      local i=0 d=""  # "." already does 1 level
      while [ $i -lt ${1:-"2"} ]; do d=$d/..; i=$((i+1)); done
      [ -z "$d" ] || cd ./$d; }
    alias ..=cdu
    alias ...='cd ../../..' # so, "."=1up, ".."=2up, "..."=3up, ".. N"=Nup

and as per the comment this even works in lowly dash, but needs a slight workaround. bash can just do a .() and ..() shell function as with the zsh.

Oh, it's fine. At your leisure. I didn't mean to go against the assertions themselves, but more just kind of speak to their "unargued" quality and often sketchy presentation. Even that Simon piece has a lot of this in there, where it's sort of "by defenition of 'complexity'/by unelaborated observation".

In engineered systems, there is just a disconnect between on our own/small scale KISS and what happens in large organizations, and then what happens over time. This is the real root cause/why, but I'm not sure it's fixable. Maybe partly addressable, tho'.

One thing that might give you a moment of worry is both in that Simon and far, far more broadly all over academia both long before and ever since, biological systems like our bodies are an archetypal example of "complex". Besides medical failures, life mostly has this one main trick -- make many copies and if they don't all fail before they, too, can copy then a stable-ish pattern emerges.

Stable populations + "litter size/replication factor" largely imply average failure rates. For most species it is horrific. On the David Attenborough specials they'll play the sad music and tell you X% of these offspring never make it to mating age. The alternative is not the https://en.wikipedia.org/wiki/Gray_goo apocalypse, but the "whatever-that-species-is-biopocalypse". Sorry - it's late and my joke circuits are maybe fritzing. So, both big 'L' and little 'l' life, too, "is on the edge", just structurally.

https://en.wikipedia.org/wiki/Self-organized_criticality (with sand piles and whatnot) used to be a kind of statistical physics hope for a theory of everything of these kinds of phenomena, but it just doesn't get deployed. Things will seem "shallowly critical" but not so upon deeper inspection. So, maybe it's not not a useful enough approximation.

Anyway, good luck with your housing meetup!

That minimalist post mortem for the public is of what sounds like a Rube Goldberg machine and the reality is probably even more hairy. I completely agree that if one wants to understand "root causes", it's more important to understand why such machines are built/trusted/evolved in the first place.

That piece by Cook is ok, but largely just a list of assertions (true or not, most do feel intuitive, though). I suppose one should delve into all those references at the end for details? Anyway, this is an ancient topic, and I doubt we have all the answers on those root whys. The MIT course on systems, 6.033, used to assign reading a paper raised on HN only a few times in its history: https://news.ycombinator.com/item?id=10082625 and https://news.ycombinator.com/item?id=16392223 It's from 1962, over 60 years ago, but that is also probably more illuminating/thought provoking than the post mortem. Personally, I suspect it's probably an instance of a https://en.wikipedia.org/wiki/Wicked_problem , but only past a certain scale.