matvore

The last time I used a leak finder, a memory allocation which still has a ptr to it is not a leak.

You are conflating unfreed memory with unreferencable memory.

I tried swapping CAPS and Ctrl, and I understand the appeal, but I guess I just like pressing Ctrl in the default row - sometimes swapped with superkey - with my palm.

Huh? People use their fingers to press ctrl? :p

For most terminal emulators (and not gVim or editors with Vim bindings), you can also use Alt+[first key you want to type in normal mode]. e.g. Alt+J to enter normal mode and go down one line. Or Alt+Space to enter normal mode and go forward one space (which usually has the apparent effect of entering normal mode without shifting the cursor backwards, which is pretty intuitive).

I sympathize a bit with the dislike of enum. We could also probably get away with replacing typedef's with either #define (for simple types) or one-field structs (for arrays and function pointers; the latter usually need a void* to go along with them anyway).

There are reasonable low-level optimizations you can do that switch is needed for. You can have cases that start or end around blocks in non-hierarchical ways. This makes it similar to a computed goto.

Would it be solved with a simple macro such that Ctrl+F2 (i.e. switch to menu bar, which is the way I mostly start to interact with UI using the keyboard) automatically reverted to Latin alphabet input? Hypothetically speaking.

Interesting. I've always preferred the input source to be global rather than scoped-to-app. I can remember one input source but I can't remember for every open app, so I always know whether I have to switch.

Are you switching between English and some other Latin alphabet language? Or non-Latin?

If you use a font which doesn't have outline data Terminal.app and you set the rendered size to whatever is the native size of the font, Terminal.app will show you the unadulterated bitmap (if you use a multiple of the size, Terminal.app should scale it up without anti-aliasing).

I generate a .dfont without outline data based on a tweaked version of my favorite bitmap font, in Font Forge.

Now, if there is a way you can pre-render your favorite outline font to a bitmap and write it as a .dfont without outlines (other extensions may be fine, not sure though), you could switch back to Terminal.app. But font tools on GitHub etc. are very very few and never work that well, if they even do what they advertise at all.

Some related trivia. The `errno` command, for looking up syscall error codes, is not installed in `/usr/bin` in macOS like on typical Linux distros. But the same information is available in `intro(2)`, e.g.

  $ man 2 intro | grep -w 17
       17 EEXIST File exists. An existing file was mentioned in an inappropriate

He's saying on that particular machine there was no video software installed.

I am saying you indeed should have descriptive function names.

I also agree that if the function's name leaves something to be desired then it should be commented.

You are conflating function names--global and relatively non-contextual--with variable names--which have limited scope and rely on the function name for their meaning.

In the setColor example, I would use setColor for the function name and c for the parameter name (with the caveat that C language doesn't have method names, so my reasoning about context has limited applicability to non-C languages)

I just did this grep for single-character function names on the Mako codebase:

    grep -r '\<[a-z](' .

And there were no matches. There were some one-character macros but they were macros repeated dozens of times in a localized area.

It seems like what's being proposed is descriptive function names with simple variable names. If the function bodies are short enough (e.g. fit on a single screen) then this seems like a good trade-off to me. IOW, the variable names are symbolic but the function names are descriptive.

The short variable names should be clear enough if you understand the purpose of the function.

I wasn't looking for something fast, as I'm happy to write some code in C anyway for something performance-sensitive, and most of the stuff I was going to write in Janet would be for interactive use. I was more interested in having a simple VM and a language that wasn't piling on new features every release like mainstream blub languages.

I also wanted a language that gave a straightforward mental model without an opinionated philosophy that tried to protect me from mutability and other real-world things (hence I didn't really want to go with Haskell and ~purely functional languages).

FWIW I also think the syntax errors in Janet are somewhat hard to grok.

  > So I feel like my time is better invested learning Racket instead?

I think it depends. If you want a language you can always rely on for 99% of use cases, something that covers many bases makes sense. For me, I wanted more of a fill-in-the-gaps language where neither C nor /bin/sh scripting make sense (e.g. stuff I may run on Windows or something heavy in string-handling).

I did not hear of it before. Glancing at the website, it looks rather appealing (simple language, C-friendly FFI) but I don't see anything about using Gerbil in the shebang line for scripting purposes?

I may give it a closer look sometime.

Thanks for the tips. I will try to keep these in mind so I can stop thinking so much about trivialities.

When I was using Java in my day job, I toyed with Clojure a bit and it was a pleasure. My favorite features were protocols and multi-arity functions.

> Is IPC Inter-Process Communication? Or is it an unrelated tool?

The former. Piping with the shell, or C subprocess hosted by the Janet script, or vice-versa.

Good question :) I actually haven't had a good excuse to use the C API yet. When I need C I just code the entire tool in C, or use IPC.

I would say that if you're interested, go for it.

My complaints about Janet are not too big. I feel like there are many ways to do some things, and they are all basically the same. Most of this excessive flexibility is inherited from Clojure.

1. It's never clear whether I need `cond` or can get by with `case` until I've waffled around a bit

2. I don't know whether to choose `if`, `and`, or `when`, for conditionals, because there are many times when all three would work. Also, if the condition expression is trivially negated (e.g. change '=' to '!=') then even `or` would work, making 4 choices.

3. It's hard to choose between `->` vs. manually-nested expressions.

EDIT: formatting

I am a happy though very new Janet user. I started migrating my existing workflow optimization scripts (e.g. Git wrappers) to--and writing new ones--in Janet as of a few months ago. I used to use Perl but I switched to Janet as it is a much simpler language and VM, and being a Lisp is ~infinitely extensible.

Janet has os/ and file/ packages, as well as a PEG system which mostly stand in for the best features of Perl. Some low-level POSIX-specific operations (like daemonizing and forking) aren't practical but I can just use C for those.

I am also using it to teach my son very simple programming. He can't type well yet, so the terseness of the language helps (there are cryptic symbols but he likes learning their names and how to type them). Its REPL and functional style I feel help a lot too.

Imperfect comparison but still valid. All lives are eventually lost causing some grief.

(If I may summarize what you've said) Saying that a large number of coincident deaths causes a collective grief that wouldn't have happened otherwise is rather subjective. I have felt nothing of the sort. I don't think it's enough of a concern to justify such an overreach of government power.

Quantifying the value of life as a number is icky but necessary if you're making decisions of this scale.

This idea doesn't apply so cleanly in Python. The meaning of this:

   if x=$(foo); then
      ...
   fi

is that the stdout of running `foo` replaces the contents of $x and the `if` evaluates the exit code of `foo`. Python doesn't see stdout as some kind of first-class language construct. I also don't think this could ever work on Windows if you expect `foo` to be a simple function that has access to the interpreter state.

`set -e` has a couple of surprising corner cases and in the details is pretty hard to understand. The documentation in `man bash` for the `set -e` flag is 28 lines in my terminal, and the other flags are 2 or 3 lines.

One such corner case is in pipelines. Only the last command in a pipeline can cause the script to terminate.

Another corner case is `foo && bar`, often used as an abbreviated `if`, will not exit when `foo` fails.

It is not a significant task to just add `|| exit $?` after any command whose failure should cause an abort.

  > edit their messages days later to gasslight you

That is a good point. I like to say `s/foo/bar/` to correct myself rather than edit the message. This is also important if people are receiving e-mail notifications for new messages but not for message edits.

  > > grep . *

  > you can "cat *"

The advantage of `grep . *` is that it omits empty lines and includes the source file on each matching line by default.

  > So it's likely that his avocados cannot be found elsewhere.

Well, according to the video, there is a 1/10k chance an avocado tree is good each time you "roll the dice." For a sense of magnitude, there are only seven types grown in California [1]. So if he is the only source of that avocado type he's sitting on a gold mine.

[1] https://californiaavocado.com/avocado101/avocado-varieties/

Interesting. Thank you for sharing.

  > The idiomatic way to solve that in rust is to re-bind to the same variable name.

OK, that's reasonable. Is the idiomatic way to use optionals to introduce a layer of nesting? I prefer keeping functions very "flat"-looking. It sounds like Rust's optionals will give people an excuse to create labyrinthine functions where I'm constantly scrolling around to remind myself of what level of nesting I'm at and whether I'm in a loop or not, etc.

As you say, you don't need a new block to shadow a previous var, so hopefully that style catches on.

  > "oh no, this isn't exactly like c, how will anyone ever understand it"

Not very persuasive, sure, but the network effect of the C/C++ culture (including its general syntax and imperative nature) is a strength in and of itself. New languages would do well to coddle the existing C++, Java et. al. users wherever it doesn't contradict the language's central mission.

  > Well if you have aesthetic objections to the way rust does it,

I agree with GP that it is harder to maintain ("messy" they say) if there is more than one variable referring to the same value. It is not so subjective as you make it to be.

  > why not just return any old pointer type?

Using a pointer type in a straightforward manner would entail allocating the object on the heap.

If allocated on the stack it has obvious lifetime limitations.

Can you give an example?

The alternatives to goto cleanup; have drawbacks too - like being less readable (cleanup code is before the main function body or destructors do things implicitly).