matvore

I love using Perl too (the real one, not Raku) for the same reasons, except I haven't even been using it as long as you (only 4 years or so).

One other thing you can do with Perl is transition very smoothly from one-liner, to stand-alone script, to multi-module systems, as your requirements get more and more complex.

I think the visceral reactions people claim to have to the syntax and other warts are rather sad. Perl certainly has warts but with some determination you can get used to them and become much more productive as a result.

I am not a big fan of OO in general, and it seems the major complaints against Perl include the object system and nested references. I happily avoid those features, and this may be why I don't resonate with the Perl criticisms.

If bitcoin causes the value of fiat currency to fall enough, the government will not be able to print money to fund wars. A war will require overtly billing the people for it or raising taxes. So it will be less likely the people will consent to start a war.

I agreed with the part of the first paragraph that says that most uses of blockchain are deadends or solutions looking for problems. I'm coming from "Bitcoin blockchain + POW is a store of value," and "LN is the fast, convenient transaction mechanism" that sits on top.

Dabbling in other cryptocurrencies with comparable POW's and blockchains to Bitcoin is basically speculation and gambling. I don't think they have very compelling use cases that Bitcoin+LN doesn't solve already. I assume non-BTC cryptocurrencies will survive in the long run, but who knows which ones, and eventually the LN will make swapping and conversion of currencies trivial and/or automatic.

  > - I don't get lisp's (lisp-2) dynamic scoping (a big reason I haven't switched from vim to emacs). I'm much more comfortable with the lexical scoping of scheme (lisp-1).

Lisp-1/2 has to do with functions and other identifiers living in separate namespaces. So in a Lisp 2 requires special functions that live in the function namespace to call functions that exist as a local variable, (i.e. funcall or apply in Common Lisp)

If you're having a hard time coming to terms with dynamic scoping (and I think most Lispers don't like it) and you're interested in metaprogramming, try writing a macro in a dynamically-scoped lisp that lets you use lexical scoping. This is kind of a fun exercise and you can do it in Elisp.

I used to be interested in Lisp - in particular Clojure - for metaprogramming and mini-kanren mostly - so you're mindset reminds me of my own. But I realized I could get much the same thing as metaprogramming with data-oriented programming, or making an interpreted language to do what I needed. The performance of raw native code is comparable in some cases. Where that fails, you could theoretically use Perl or Python to generate C code that just has to be performant but is very repetitive. The benefit of that is that mere mortals will understand what you're doing better, and you're not forced to bear the burden of a garbage collected runtime.

Cryptocurrency promotion implies to some extent that central control of money is a bad thing. So it is somewhat political.

I think most HN folks are against it for political reasons to a certain extent. Even if they say they aren't, they are getting their information from and socializing in a bubble with a political bias.

There are some news topics on HN that i will never read the comments of because of how motivated and biased the reasoning is behind them. Bitcoin comments I will still read though, since it's fun to see everyone's tone and reasoning evolve as Bitcoin slowly gets more traction and rises in price over time.

  > But bitcoin is a waste of resources by design. The whole point is to waste resources.

The miners run POW (i.e. waste resources), and requires specialist hardware (ASICs). Validating blocks is done by "nodes" and is within the capabilities of typical consumer hardware. Both operations serve different purposes in securing the network.

  > Who can argue with amazing arguments like "Bitcoin is the 
  > money of the future because it will allow a fraudster to keep 
  > the proceeds of his crimes!"

The benefits outweigh the costs. Fiat currency is used for plenty of bad things, like funding wars and proxy wars. It would be a net gain if, for instance, fraudsters were a little more able to steal from gullible people but governments couldn't fight as many wars. Gullibility can, with proper education, be fixed, after all.

> What I _don't_ like is his coding style. If he's writing C++, let him use modern C++.

In situations like this, I recommend acclimating yourself to the unusual style as a mental exercise. You will likely have to read a lot of quirky and/or legacy code in your career.

Did you consider using more traditional macros like VEC_ADD which works for all types rather than generating e.g. vec_<type>_add? The latter approach doesn't work with cscope and ctags, which is a pretty big drawback in my book (I like it when my super trivial IDE configuration works, which is only possible with C).

See the comment and following 4 macros for how this would work with a (add-only, not growable) hashmap:

https://github.com/matvore/nusort/blob/master/src/util.h#L16...

  >  The written-spoken language is very regular so it's very easy so "sound out" words.

I don't know where I stand on your thesis (I was mostly arguing against the idea that Japanese people are demotivated to read more than English speakers because of kanji), but the main reservation I have about this is that it's pretty easy to fake knowledge of words this way. The pronunciation of something is secondary to its definition. But with a phonetic language, it's easy to fool yourself as well as others of an understanding that is not very deep.

I remember once in middle school I elicited a laugh from my classmates when during group reading, I mispronounced "awry" (I had put the stress on the wrong syllable as well as pronounced the "y" as "ee"). However, I had a very good idea of what it meant at that time. OTOH, in that same class, it was a very unusual occurence for the teacher to interrupt group reading and confirm everyone knew what a word meant, so I believe many misunderstood words were glossed over routinely.

I'm not saying being phonetic is a net loss, of course, just that "understanding" is a tricky thing to gauge, and may be harder as a side effect of some language being phonetic.

> https://japaneseruleof7.com/are-japanese-people-retarded/

That is not exactly an academic source and it's from someone living in Japan that doesn't read Japanese very well (check the comment section where they admit that themselves) so this is far from authoritative as a source.

I heard that after WWII the US occupation administered a national literacy test to see if Japanese people were as literate as their US counterparts, as it was becoming a serious idea to replace the existing writing system with the US alphabet. It was found that their literacy level was comparable so they didn't change anything so drastically.

Consider that learning to read kanji is much different from (easier than) learning to write them. There are a ton of contextual clues when reading, and furigana inserted by the publisher if the kanji would be hard to read for the target demographic. There is also the option of just substituting kana for hard-to-read kanji. Publishers and writers will obviously add furigana to any kanji that are hard to read as they have a monetary motivation to make their content as accessible as possible.

So you tend to pick up a lot of kanji based on these contextual clues and furigana over the years if you read anything, similar to how English speakers learn spellings of words when they read a word they've only "heard" before.

Writing is harder because when writing you will sometimes struggle to remember the correct kanji to use, or sometimes forget a small portion of the kanji. This is the why schools need to spend so much time teaching kanji as a subject of itself.

  > if list elements are stored contiguously, is there any advantage to using a linked list

Storing them contiguously probably implies that you consider "freed" space in the middle to also be part of the contiguous area. Otherwise you can't remove in O(1) time.

It is straightforward to maintain a list of freed nodes which you can add back later.

If you don't mind not being able to remove in O(1) time, you still have the advantage of passing the handi-capped (contiguous) linked list to interfaces that expect a linked list, but still get the cache locality of a plain vector.

I also found "WebAsm" a bit jarring to see.

I imagine they are referring to Rust.

  > The best C programming trick is to use no tricks.

Yes! C's monotony is its killer feature. Take away power when you are coding and you have more power to share the code and debug it.

This is used by the Ganesha project (userspace NFS server). Look for the symbol "container_of" and usages of it in https://github.com/nfs-ganesha/nfs-ganesha/ (disclaimer: I'm a minor contributor).

The way it's used is that Ganesha supports defining of alternate filesystem backends and serving them as NFS shares. Handles to objects (e.g. files) would exist as pointers which live inside the struct of the backend's handle struct. i.e.:

  struct my_file_data {
    struct ganesha_file_data {
      // generic data
    };

    // data specific to my module
  };

The "my" module would take pointers to ganesha_file_data when the NFS core code calls it. The "my" module then uses container_of to convert ganesha_file_data ptr to my_file_data ptr.

My favorite C trick is not related to programming - but to debugging and disassembly. Unlike C++, there is no name mangling, so stack traces are a breeze to read, especially with -fno-inline-functions and -O0 or -O1. There is no implicit action at all (i.e. no exception handling or destructors) so there is a simple mapping between the assembly and source code.

My favorite "programming" trick only applies if I'm not sharing my code. I just forego header files entirely, and just #include the .c source files. Also, put `#pragma once` in all the .c files to avoid double-inclusion without the hassle of #if ... etc. This requires a bit more diligence since you can't have mutual recursion between source files.

I suspect there is an element of truth to it. I agree they will keep the Unix core and allow you to use clang and ld however you want. I suspect, however, they're not interested in supporting alternate OS's nor are they interested in allowing typical users to download normie GUI apps from anywhere.

Eminent Internet speculation about Apple is correct surprisingly often.

EDIT: I'm getting downvoted, maybe because I was too cryptic. To clarify, it seems like the rumors that gain traction with mainstream sites and Apple-focused YouTube channels and forums tend to have strong correlation with something that will happen later.

> It would be if they take some effort to support it.

Oh, definitely. But the Linux (or alternate OS) fans are not really on Apple's radar. OTOH, they do a good job of keeping some core binaries up-to-date, like zsh and Vim, and they did appeal about getting good compile times during the M1 release event, so they consider POSIX users part of their target market.

I get why this idea of becoming iOS-like is uncomfortable for a lot of people, but will they take away the POSIX-ness of the OS? What about all the people that spend all their time in Vim, TMUX, Emacs, and/or zsh? I think these people will continue to be pretty happy on macOS if they already are.

In my experience, installing alternate OS's on Mac hardware has never been frictionless or satisfying anyway.

The `/bin/bash` on macOS is severely out of date. So a script that starts with `#!/bin/bash` will be unable to use a lot of features.

If you only rely on `/bin/sh` the user has the flexibility to point `/bin/sh` to whatever shell on their system is fastest and most up-to-date (e.g. `/bin/dash` is a pretty good choice for performance).

  > Consider that in Unicode ... there isn't really such a thing as a 'character' 

This is a really important consideration, since it helps you realize the immense difficulty of wrapping your own logic for character-aware handling - unless you are deliberately limiting your scope, like only handling NFC-normalized text of a limited number of languages.

I still use caps lock since I regularly code in POSIX shell, C, C++, and Perl, which all have naming conventions that use all-caps names.

Also, as a VIM user, I only have to use Alt when I’m dealing with GUI apps, which is definitely common, but a time when I don’t mind moving my hands around.

So for me, Esc is Alt. Alt is caps lock. And of course caps lock is Esc.

And I swap Super key and Control, since the Super key is easier to press with my palm on my ergonomic keyboard. And Ctrl does have a lot of uses in Vim.

I also map the Windows Menu key (not the Super key, but the other one which is used for showing context menus) To underscore. That helps me type C identifiers with multiple words in them. This one remapping is a huge benefit, almost as important as mapping caps lock to Esc.

> Just wanted to let you know that you are discouraging.

It didn't strike me as discouraging at all. Discouraging would be something like "QM is so hard that 80% of people reading this are too stupid to learn it" (which I don't think is true, FWIW, so don't be discouraged by that)

Just because youngsters don't have critical thinking skills does not mean they will read words that aren't even there. If anyone does that, it's on them, the reader, and no psycho-analytical word smithing will fix that.

I believe the plan behind the Chinese characters in Unicode was always that different hanzi-using languages had different renderings of certain characters, and that rendering it properly would be up to the font.

According to Google Translate, in Italian, "potenza" means strength, ..., potency

I wonder if the doctors in the article used this word to describe the loss of potency, but the media and translators are equivocating this to mean "strength" (which is a more intrinsic quality, and suggests a mutation).

My first guess was that because summer is starting, people are getting more Vitamin D, and this is making the virus less effective. Alternatively (as others have stated in this topic), the virus could mutate to spread more effectively but lose its strength on individual people, and this would still be considered an evolutionary advantage.

For diffs that include the common ancestor, add this to .gitconfig:

  [merge]
  conflictStyle = diff3

I think the problem is the teacher moved from one type of "fraction problem" to another kind.

The example of drinking 4 bottles of water to only have 2/6 left of the original pack is doing an integral problem and wrapping up the answer as a fraction. Same deal with the pack of 12 pencils.

The students can grasp those problems as e.g. (1+1)/6 rather than (1/6 + 1/6). In other words, there is only one "whole" in the problem.

When you're adding the fractions of desks filled with students, the fraction is counter-intuitive because both desks have to have the same number of students for it to make sense. (1/3 of a 5000-student round table is different from a 3-student table). And to say "the units are wrong" is kind of a limited way of explaining this. The units also need to have the table capacity as part of the unit identity (i.e. the units would have to be 3-student-table). That's a pretty sophisticated way of thinking about units.

I think that after the pencil/water examples, transitioning from the pencil/water pack examples to a more "pure" fraction example would be better. e.g. one group of students eats 2/3 of a pizza, and another group eats 2/3 of a pizza. Now you can throw away one of the original pizza boxes and put the two remaining 1/3 in a single box which is 2/3 full. Now the "whole" for each fraction is no longer arbitrary (like 6 bottles of water or 12 pencils).

   > This sounds impossible, there's not enough information in 
   > the C type system to know in the general case what the 
   > bounds are.

Good point. My thought was that the runtime could keep track of all the mallocs and then make dereferences check whether the memory accessed was in a valid region of the stack or the heap. But this doesn't sound workable. You'd have to resolve every single dereference to a list of ranges in memory (`O(log n)` for every `foo[bar]` I would imagine).

Perhaps every pointer could be implemented not only as a raw pointer but one with a "valid" range attached, which indicated how many bytes prior and following the pointer that were part of the block original block the pointer was calculated as an offset from. Any dereference would check that it is within the range, and that is only O(1) for every `foo[bar]`.

   > This wasn't true last I checked for libc++ (the most "modern" implementation)
   > ...
   > I'm not aware of anybody who enables this in production 
   > because the culture of C++ is all about performance.

This conversation is happening in the context of what is possible without language (and maybe without even compiler) support. The original comment I replied to was saying neut had fatal flaws because it didn't address borrowing and lacked some features that Rust has. The fact that some people refuse to use C++ in certain ways is interesting but doesn't detract from my original point.

   > Meta-programming cannot remove features from a language, which is 
   > typically the problem here.

The simplest type of Lisp macros only add features, but it is possible to create a new kind of "top-level context" (for want of a better term). Your macro system does have to be aware of all the primitives in your Lisp dialect, though, for this to work. There is a certain term for this that I can't recall at the moment.