The tool I use is in Python and required considerable programming to customize it. I thought I'd need to do clever language specific commands, but in practice with vscode smart completion (which is language specific) there isn't much I needed to customize.
Over point I read that it is so true is that you spend most of the time editing, so commands to move the cursor and delete things are the biggest time sink. So in practice I just had a few keywords coded in for rust.
I use voice typing too occasionally, although I try to avoid coding when my hands are bad enough that I have to use my voice. I have specific words for every letter and symbol, e.g. pit for a p and semi for a semicolon, and other words for combinations of several symbols/keywords, e.g. in generics for <> followed by the left arrow key. There are also words for starting to dictate words, e.g. phrase <words> types those words, sentence <words> types those words with the first capitalized, and snake <words> types those words, but with underscores rather than spaces.
The tool I use, talon, has its own configuration file format for simple things, and lets you call python for more fancy things.
I could never have used my voice for typing had it not been for vim.
Maybe I should try this.
Removing semi-colons is a horrible idea.
Combined with Rust's "practically everything is an expression" it would create a bunch of ambiguity and/or force you to break lines in weird spots.
I hate when languages rely on whitespace. Not to bash on Haskell (because I like Haskell), but the way it cares about indentation is my least favorite feature.
There must be a way to delimit statements. That can be a semicolon, or it can be a newline (but then you need significant whitespace).
Using a newline as a statement delimiter not only requires significant whitespace, it also mandates only one statement per line. However, that was bad in the early days when code was printed on paper... nowadays most people have one statement per line anyway, so that's probably not a hurdle towards progress.
In Rust, it is further complicated by the feature of implicit return value for a code block. If newline is used as a statement delimiter, then each function that returns nothing must have an extra line at the end saying (). Otherwise, that function returns the value of the last statement.
IMHO this feature is probably the one big reason why we need semicolons. Imagine:
With semicolons and curlies:
fn add_to_collection(key: u64, value: String) { // returns nothing
map.insert(key, value);
}
Significant whitespace and indents:
fn add_to_collection(key: u64, value: String)
map.insert(key, value) // error: expects (), gets bool
fn add_to_collection2(key: u64, value: String)
map.insert(key, value) // OK!
()
Monitors have a finite width, just like paper does. With identifiers getting longer, I often end up with multiline statements because I like seeing the entire thing at once.
I just imagined someone replacing all function and variable names with single-character names, claiming that less code is better code. I hope no one actually does that.
Using no variables at all in many cases seems to be common with Haskell. Or at least that is my impression from reading blog post regarding Haskell.
"point-free" style.
What? Decades of programming in all kind of languages and I have never heard "point free".
Is there some concerted plan out there to totally confuse us old timers?
APL was developed in the 60s, so perhaps point-free is the real old timer paradigm.
Never met an APL programmer.
Apparently using pipes in shell scripts is an example of "point-free" as well.
Still never heard of it.
Given that FORTH was point-free literally half a century ago, no.
Ah FORTH. Stack based is an interesting example on how you can write functions without mentioning their arguments.
I are one. Actually, I was one. I did most of my scientific algorithm development in APL for nearly a decade. Back then APL was too slow for production work, so I hired students to translate the algorithms to Fortran. These days I'd use Matlab if I was still in that game.
Apparently so.
However I don't recall the term "point free" ever being used in anything I ever read about Forth back in the day.
When, and where, did the term "point free" come into existence?
Edit: This post has been hidden because somebody complained. Sadly I cannot fathom why they might do so.
How on Earth can my post there be objectionable to anyone?
It sounds like the kind of thing that comes from somewhere in mathematics. In fact, the Tacit programming page links to point-free topology (or with its much better name, pointless topology).
I don't know for sure though.
Hmm..
I don't recall any of my function's parameters having names back in the day when I wrote a lot of assembler. Except in the comments, if there were any. They were in registers or on the stack some place.
Can I claim assembler is also "point free"?
Interesting question. Things like rax or stack pointer + 16 could count as the name for an argument.
But assembly is often an interesting edge case in programming language categorizations.
I wouldn't call anything based heavily around a three-address code, like many assembly languages, point-free because you're passing arguments to things, even if those arguments are register names. Though if all your arguments are on the stack, not ever in registers, then you're using it somewhat like a concatenative language -- that's part of why it's a nice pattern for things like FORTH, because it's so easy to translate to fine-if-not-amazing assembly.
And in general, most of these categorizations depend more on how they're normally thought about than any particular technical detail. You can also argue that a stack-oriented language is a functional programming language where every function is passed a stack and returns another stack. (You generally don't think of it that way, though.)