
Let’s stop copying C - heisenbit
https://eev.ee/blog/2016/12/01/lets-stop-copying-c/
======
kazinator
_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!

------
jhbadger
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.

~~~
JoshTriplett
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).

~~~
kazinator
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.

~~~
JoshTriplett
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.

~~~
kazinator
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.

------
speps
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.

