matvore

> it’s basically unreadable to very most of developers

The ubiquity of parenthesis has a purpose - it lets you treat code as data. Your argument only makes sense if syntax choice were 100% based on taste. But it's not (simplicity of syntax brings with it practical features), so it's great that some people are exploring other options.

And it's not intrinsically less readable than say, something like: https://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a0111...

So you have linked me to a list of security vulnerabilities - are you suggesting all security vulnerabilities need to be addressed by the language spec and the compiler? I doubt such a wide and diverse range of problems be addressed at such a low level.

At a glance, most of those look like bounds checking problems. tcc (Tiny C Compiler) allows you to compile in bounds-checking with all pointer dereferences.

C++ STL implementations generally have bounds checking all over the place - this requires compiling in debug mode IIRC, but it is evidence of the possibilities of safety without language or compiler support.

Lisp-style meta-programming can get you basically anything you want from a language without language or compiler support.

Why should any of what you talk about be the responsibility of the language as opposed to the linter, an annotation library and static analyzer, a library, or clean design? Remember the Unix philosophy.

when thou least expect it.

Should be “when thou expectest it least”

lest thou tear thy hair

Should be “lest thou tearest thine hair” as I seem to recall the h sound acting like vowel for words that sound different based on what follow them.

lest grievous harm befall thy program.

Should be “befalleth”

Thanks for the link - that's an interesting read which I'll have to work through more thoroughly later.

  > GPL never says you can't charge for software.

My point is not that the GPL is contradicting itself, but that the GNU philosophy contradicts the GPL.

There is a quote in item 4 at that link you shared, which says:

  > I think that to try to own knowledge, to try to 
  > control whether people are allowed to use it, or 
  > to try to stop other people from sharing it, is 
  > sabotage.

Putting a paywall up is a method of control. I think I represented GNU's position fairly.

  > What makes telling you to wear different shoes any different? I am just
  > asking you to abide by my rules if you're going to make use of my resources.
  >
  > The GPL does the same.

Couldn't agree with you more, but Microsoft and other proprietary software makers have the same right (to dictate what people can do with their software). For some reason, GNU believes (as RMS has stated in various talks) that not sharing software is immoral.

Now, is not sharing software immoral because (1) it can be copied at no cost, or (2) because you can't morally tell people what to do with the bits once they have a copy of it ?

(1) is nonsense because creating the software has a cost, and anyway, just because something was free to you doesn't mean you can't charge others for it.

(2) is contradicted by the GPL if it tells you what you can do with the bits after you have them.

You can make the argument that free software results in higher quality software, but it's wrong to make a case for it morally as GNU does.

  > * access modifiers (public/private)

I think you can omit the "public"s in the Java hello world (thereby making everything package protected, and sneakily sidestep the issue), but I don't want to ruin this machine by installing Java on it to make sure.

To be super thorough, you would also have to understand:

- semicolons (and the related issue of newlines being semantically equivalent to normal spaces)

- naming conventions (to explain why it's not "System.Out.Println" and "Main")

Is it possible you don't need the book as much as the book's target audience, and that's why it seems overpriced?

It may be because some people are starting to feel modern languages are bloated.

  > With regards that anything can be streamlined: sure, but it’s also about the amount of investment 
  > that would take.

Yes, I can't deny there is more up-front cost in C for some things.

  > The fact that you hate function pointers and void* context pointers is an
  > exact confirmation of my premise: people think it’s too much of a hassle.

My point was that there's usually a better way to get around a language's (in this case, C) limitations, and it's not necessarily macros every time. At least for the problem of abstract base classes, I rather liked your hinting of the linker swapping out the desired implementation for test binaries. That makes sense, since I think I've never seen an abstract base class (which is abstract for testing purposes) have more than one implementation per binary.

As for mocks, the fact that they're hard to do in C may be a feature in disguise...

  > it takes a crazy amount of effort

I agree with basically everything you've said but I don't buy that it takes a crazy amount of effort to do anything. You have C. If it's hard to do in C, you have a Makefile. If it's hard to do with a Makefile, you can run a script during the build process. Anything can be streamlined.

  > it's also possible to have dependency injection in C by using structs with function 
  > pointers, but I think we can all agree that it's a lot less pleasant to use than C++ 
  > abstract base classes

I hate function pointers, and void* context pointers even more, so I wrote macros to do binary search and sorting so I didn't have to pass a void* to qsort(3) and bsearch(3) (also, bsearch(3) doesn't tell you the insertion point of a missing element)

If you want to sort an array:

  int arr[] = {5, 10, 15, 17, 20};
  size_t size = sizeof(arr) / sizeof(*arr);
  QSORT(arr, size, arr[a] < arr[b]);

If you want to find the value 5 in that array:

  ssize_t index;
  BSEARCH_INDEX(index, size, arr[index] - 5);
  // Now 'index' has the result.

edit is not working. I meant my native format is mdy.

You're technically correct. However, to a large number of people it not only appears novel, it is ambiguous for ~40% of dates of the year with their native format (MM/DD/YYYY). Even if it's convenient for the majority, it may cause so much friction for the minority that it's not worth using anymore.

My native format is mdy but I dislike it almost as much as dmy.

Modern programming language features are overrated. I prefer to choose the tools that are the most portable and involve the least social friction (i.e. something that is widely understood by people I work with).

For "fun" projects (stuff I'm not paid for) and workflow optimization, I just care about portability, which means C (with heavy use of the C stream library, a simple collections library of about 200 LOC, and occasionally POSIX syscalls) and shell scripting. After spending a lot of time learning languages as a hobby, I just don't believe the dark corners and warts of C and shell scripting are any worse than other languages.

(2 ^ (N - 1)) grains of rice on the N'th square.

That means (2 ^ N) - 1 cumulative grains of rice on the N first squares.

So 63 total grains of rice on the first 6 squares is correct.

There is no such thing as “intrinsic” value. Value requires an evaluator.

Maybe you mean that bitcoin doesn’t have value outside of its ostensive monetary value. Bitcoin has that too. It can back up data to thousands of locations and be censorship resistant and have a verifiable timestamp.

No, it's still O(N) amortized. Imagine if the hashmap doubles in capacity whenever it is full or hits its max load factor. Then you end up having O(N) copy operations. O(2 * N) = O(N)

I also didn't feel that anything was wrong with using 入れる instead of 入れてください. If it's already clear a process or instruction is being explained, sometimes you don't use a grammatical command - I've seen it before.

I don't think "ko is informal" is entirely true. Based on my few years in Japan, plus just now looking up "ko" dictionary to look for any nuance I've missed, it seems like "ko" is fine even in formal contexts, especially if it's used for (semi) mathematical purposes.

If I search Google for "リンゴ１つ" (one apple) it automatically matches it with pages that use "リンゴ１個". Also, the latter is much more common than the former looking at the first 10 results, and the latter appears in otherwise formal-sounding phrases like "りんご1個は、中くらいのサイズで300g前後なので、1個あたりのカロリーは、約183kcalとなります。"

s/无/五/ You spelled it in pinyin right, but your IME chose the wrong character. That may be deliberate censorship by the conversion dictionary compilers.

Why can't you bear it? Being wrong is not that bad.

Japan doesn't really need complex or quota-based immigration laws because foreigners are not super happy to live there forever once they've tried it. More so than legal barriers, there are cultural ones. And there are borders in our minds just as much as on maps (e.g. preconceptions that we're stubborn to let go of).

The US is different, of course. People like it here once they've arrived. I can't say why, nor do I buy the stereotype that US culture is more open or individualistic. But the US arguable needs laws quota-based and micro-managey, since they are managing a huge amount of people from more diverse backgrounds. Japan is managing fewer potential immigrants and guests, and most of their immigrants are geographically close to Japan.

Despite the immigration laws being easier to grok and less authoritarian on paper, Japan is pretty strict in its enforcement of those laws. Put all I've said together and I don't know if one country is more reactionary than the other, but I think both countries are moving toward a more balanced, less eccentric immigration system at the moment.

(why you should listen to me: I'm an American and lived in Japan for four years and had to go through the process of getting my wife a spouse visa 2 years into my stay. I dealt with immigration a few times. I went to many different cities and vacations and such, and talked to people that don't speak English and don't have a passport, so I have a representative sample set.)