Threads for emiller
-
Awesome read! I love the three classes of features.
I’ve got one to throw in the mix, Nextflow’s
file(). It just handles remote and local files the same, so the end user can use anything from a file on an FTP server, to s3. It just works and stages the files locally.
-
First, there’s the config keyword. If you write config var n=1, the compiler will automatically add a –n flag to the binary. As someone who 1) loves having configurable program, and 2) hates wrangling CLI libraries, a quick-and-dirty way to add single-variable flags seems like an obvious win.
This is not a feature I’d be thrilled about in a general-purpose programming language (although perhaps it makes sense in the context in which Chapel is used). Adding syntactic support in the language for a specific type of command-line argument parsing and mapping the result of that parse to a variable just makes me think that if I ever needed to do some kind of complicated command-line parsing with custom logic, the language would fight me on this point.
-
It has potential drawbacks, but what I’d really be interested in is a language where
maincan have any function signature: its arguments become positional command-line arguments if required or flags if optional, its documentation comment/string becomes the--helptext, and argument annotations can be used to add short option names or to bypass parsing and just read the raw argument list.-
I think you would be interested in OSes with structured commands. With this, the shell can prompt and provide help for arguments, do some basic parsing, and pass the results to argv.
Big two examples here are VMS with DCL (command definition/creation docs) and IBM i with CL (an example, though without context, there’s a lot to get used to!).
-
Raku (previously known as Perl 6) has this: https://docs.raku.org/routine/MAIN
Elvish also has this, but instead of restricting this to a main function (which Elvish doesn’t have anyway), you can do this with any function: https://elv.sh/ref/flag.html#flag:call.
-
This sounds good in theory, but will clash with the idea of sub-commands and mutually-exclusive option groups.
However, if you know what you want from such an option generator, it’s quite easy to fake is the language provides access to function type signatures. Python 3.x’s type information API is still somewhat clunky, but it allows that.
We are doing that in VyOS now. For a very simple example, here’s a function that returns system version data (either in JSON or formatted for humans): https://github.com/vyos/vyos-1x/blob/current/src/op_mode/version.py#L66-L73
The real advantage of having that as a library instead of a language feature is that you can use it for more than one purpose.
We have vyos.opmode that automatically exposes all
show_*functions (among other reserved names) as subcommands and their arguments as options, in that case asversion.py show [--funny](that we later map toshow versionandshow version funnycommands).However, we also have a GraphQL schema generator that exposes that function as
ShowVersionquery in the API.It’s a solution that only works for us and our set of special names, but everyone can make a generator for their own needs relatively easily.
-
I wrote a python library years ago to generate argument parsers from function signatures (or for subcommands, an argument parser for an object, module or class with function properties). https://github.com/cmcaine/cli
-
-
-
I wrote a python library years ago to basically do this. https://github.com/cmcaine/cli
You can use it to generate argument parsers for pretty much any function or for entire modules (then the first argument selects which function to call).
-
-
Conversely, it means that you have a language feature that doesn’t work for environments where there is no CLI. For example, WebAssembly components, bare-metal code, and so on. That’s find if you want to write a language specifically for a limited subset of deployments but it’s not ideal.
What I really want is language support for defining these things in a library. For this example, I want some simple syntax that lets me modify a data structure at compile time from different declarations in different modules. If I have that, then I can have a CLI parser library that lets me define a
Config[T, Name]in my compilation unit and have it register the type and name with the CLI parser library and have a transparent accessor for the new variable that actually queries the CLI library for the value. -
-
Yeah magical default parsing is one side of the “I don’t know how to do command line padding” coin. The instant you want to do something a bit bespoke you’re digging through incantations. All for something that is literally “take this input and give me output”!
Is writing “config n as intParam(default=1)” or something too much?
-
Agreed, it makes sense for languages that are going to be used from the command-line. Nextflow handles these under
paramshttps://www.nextflow.io/docs/edge/config.html#scope-params in a pretty elegant way!
-
-
I love the idea! As a bioinformatician, the biology portion always feels more obscure to find simple references for the biological concepts to point people towards, compared to documentation for software.
-
Syncthing maybe.
I use git, but I feel bad when I do a lame commit just to pick it up on another computer.
-
-
-
-
-
How I use git:
- Always work on a branch. Commit sloppily. Push to any other computer freely.
- When I’m ready for a “real” commit, squash, write a good change description, and merge to master.
I do this for ALL changes and it works well. I have a shell script with 6 lines in it that automates some of it.
-
It’s annoying to forget to push as well. One nice thing about rebasing is you can clean that kind of stuff up later on, but it does feel a bit like “I am having to do this for incidental reasons”
Given how the internet is nowadays, I bet a lot of people could get away with working via NFS or something for their code
-
I use Syncthing, too. I love it because it’s super reliable and easy to setup. I have to sync some stuff between Linux, macOS and Windows machines and I just can’t describe how happy I was the day I found out about SyncThing and could forget all the little gimmicks and flags that Samba needs so that files named “like this, brø” don’t end up called “الإعلان اÙعال when I copy them.
Fingers crossed I’m not summoning little Bobby Tables here…
-
I use Syncthing for basically everything other than code, where I use the git-based workflow that I mentioned elsewhere in this thread. I don’t think I have any principled reason for this, other than expecting to work with code using git-based tools and not use those with other sorts of files.
-
-
Why? Committing every time you have any reason to of any kind is good! There’s a reason git commits aren’t forever and you can amend or rebase or reset later.
-
Just going to drop this here in case it interests anyone https://github.com/Emiller88/dotfiles/blob/master/modules/services/syncthing.nix
-
-
Snakemake has added support for rust rules in case that’s of interest to anyone.
I’m thinking of starting a new technical blog in my personal site, but as usual I’ve hit the “what do I use to generate the blog from markdown files?” barrier. My current site is just an HTML file and some CSS.
In the past I’ve used
jekyll(not cool anymore?) andhugo. I could go thehugoroute, but it may be too complex for what I want… Also, the last time I had ahugoblog a lot of stuff changed betweenhugoversions and I had to make changes to my blog several months later (maybehugowas in its infancy then and changes were expected).I’ve toyed with the idea of writing a simple static site generator in Go for this, but I think it’s not worth it. I’ve looked at a simple shell script,
barf, but it’s not portable between macOS and Linux, so I’m not going to use it…So… I’m still debating what to do. Maybe I can solve that this weekend.
Do you want to write or work on a static site generator? My recommendation is to use something that works well with existing tools and is properly maintained. E.g., Jekyll + GitHub Actions would be my choice for a new blog
Oops, I see you said essentially what I did—but three hours earlier!
Yeah, that’s the thing. In the end what I want is write, not spend too much. I wanted to avoid using something complex but yeah, I’ll end up using
hugosince that’s what I’ve used in the past.If you layout needs are simple enough you could go directly with HTML?
That’s assuming you’re actually more interested in writing than with putting together a build system for your blog. I’m in the latter category, and have spent many, many more hours changing my blog’s build system, css, and CI, than actually writing.
I’ve thought abot going on directly with HTML but in the end it’s too painful having to build up my site manually (stitching together a header, footder, content, etc.) every time I write a post. Also maintaining an RSS feed in that case is also tedious.
https://www.11ty.dev/ Seems pretty nice. Seems to be as simple or as complicated as you want.
Thanks for the recommendation! I ended up using Hugo, and shipped the changes this afternoon :)