Let’s stop copying C | Hacker News Reader

Let’s stop copying C

eev.ee

46 pointsheisenbit7 comments

Quick test: if you create a new namespace and import another file within that namespace, do its contents end up in that namespace?

Included: ACS, awk, COBOL, Erlang, Forth, Fortran, most older Lisps, Perl 5 (despite that required files must return true), PHP, Ruby, Unix shells.

Common Lisp's LOAD binds the value of {star}package{star} to the value it held before LOAD was invoked. This means that the LOAD takes place in the same package, but if the file being loaded changes to a different package, that effect is lost when the LOAD completes.

In other words, the designers thought about this issue (how loading interacts with the package system) and made a clear decision: same package is used over the load, but the loaded file is prevented from altering the caller's current package: they decided that the parent being able to establish a package and read table for the loaded child is useful flexibility, but the reverse situation being error-prone.

That decision is a reasonable one. I thought about the same issue in TXR Lisp and copied the decision made by ANSI CL, recognizing its wisdom.

Note that when LOAD loads a compiled file, then the symbols in that file are not affected by the current package. They are not being read from source code any more. (That is no longer textual inclusion).

Lisp supports textual inclusion in the sense that you can load a file that is raw source code, without being forced to compile it first. That is useful and good; why not support such a thing? Being able to set up a package or read table and then do a bunch of loads which then take place in the context of that package is also useful and good.

Lisp doesn't force you into textual inclusion. Even for macros, you don't have to use textual inclusion. A module containing macros can be compiled with COMPILE-FILE. Then that file can be loaded as a compiled file, by the compiler, when other files are being compiled (files which need those macros).

Please, don't compare Lisp with C #include!

A lot of these just seem to be arbitrary preferences. The author doesn't like capitalization in variable names and thinks twoWord is "objectively wrong" preferring that languages accept two-word. Personally, I would prefer twoWord even in languages that accept two-word -- it is just too tempting to think it is subtracting "word" from "two" whether or not the language actually interprets it like that. There is no danger of ambiguity with twoWord.

I've never had the issue with "moving the shift" that the author mentions, leading to "snake-Case". I don't think the way I type would allow that typo to happen; I certainly make typos regularly, but I don't think I ever have typos that move which character a shift applies to (Caps -> cAps).

I do like languages like Lisp that let you use dashes in identifiers to avoid the need to shift, but at the same time, I also like identifiers_like_this just fine (much more so than identifiersLikeThis).

I often get errors like THis.

This is the fault somewhere between the keyboard drivers in the OS's USB stack, or decoders of events in the UI.

The problem is that I typed the H before releasing the shift key. However, the shift key is in fact released before H is released. The timing diagram is something like this:

           ___
  T     __|   |_______
              ____
  H     _____|    |____
         _____
  Shift |     |_______

The release of the Shift is a little late, so H gets it. The strict timing requirement to get this right completely non-conductive to fast typing.

For instance, if I repeatedly drum my three fingers in a natural way on the Shift, Z,X (using my ring finger, middle, and index), and do it fast, here is what I get:

   ZXZXZXZXZXZXZXZXZXZXZXZXZXZXZX

Key events should be tied to the release not to the attack, and the decision whether or not Shift applies should be made intelligently somehow based on the percent overlap.

At the very least there should be some small (configurable?) holding period after the key down event before it is converted to an input character. Only after the holding period should it be decided whether the key is shifted, based on the current shift state at that time.

Interesting; perhaps that's an artifact of specific keyboards, and I've fortunately not used such a keyboard. (I have used keyboards with other unusual issues; for instance, I briefly tested a laptop whose keyboard had a wiring issue such that if you pressed three keys at the same time, the third would type a completely different key. I never realized until then that when typing certain common things, such as "mount", I chord across 3+ keys such that I press the 'n' before fully releasing the 'o'. On that keyboard, this would result in typing "mou~t".)

That said, using a keyboard that had any lag between hitting a key and having it produce an event would rapidly break my brain and fingers; I expect a key to show up near-instantly after hitting it, nothing to do with when I release it.

Funny though how we're used to UI buttons having release-triggers semantics, though! You can click OK on that "reformat your hard drive?" dialog---and as long as you don't release that mouse button, you can change your mind by moving the pointer out of the button, so it loses focus.

It's a bit strange that some of the items don't include all languages from other items. For example Go doesn't allow "++" inside an expression, it's a statement by itself but that's not mentioned. Anyway, it's interesting but incomplete.

Reply on news.ycombinator.com