Cocona [1] is my command line parsing library of choice.
My preferred .NET console stack
31–40 of 119 posts
Re: My preferred .NET console stack
#32Dependencies, dependencies, dependencies. All for a simple console program. And you end up with a console app that is 20-100MB. Traditionally this program was a few KB. It can still, if you use the right language(s). Making software should not be about making the life of the developer as easy as possible, it should be about making things easy, small, and FAST for the user.
Beyond that, the fact that you have to do any of this is silly. The .Net tooling used to be easy, now you’ll be able of building your entire application in python before you’re even done configuring your .Net environment. I know I’m grossly exaggerating, but the fast movement and the lack of ease of use has been one of the primary reasons to see us slowly move toward python and powershell after nearly two decades of…
> The .Net tooling used to be easy, now you’ll be able of building your entire application in python before you’re even done configuring your .Net environment.
> I know I’m grossly exaggerating...
I do not even think it is an exaggeration. Even the non-performant Python still feels like a hacker's, get-shit-done language compared to .Net. Anything .Net still feels like slow, enterprise bloat. Even "dotnet build/run" is slow, no matter size of your project.
Re: My preferred .NET console stack
#33Dependencies, dependencies, dependencies. All for a simple console program. And you end up with a console app that is 20-100MB. Traditionally this program was a few KB. It can still, if you use the right language(s). Making software should not be about making the life of the developer as easy as possible, it should be about making things easy, small, and FAST for the user.
> And you end up with a console app that is 20-100MB.
FWIW, this is sort of a legacy of .NET's "enterprisey" history. Code size and trimming wasn't really a priority when most .NET code ran server-side or inside enterprises, now it is.
There's been a lot of work happening recently to trim .NET executables and publish them as single files, and it looks like .NET binary sizes will eventually be in the same ballpark as Go: https://blog.kalalau-cantrell.com/2021/01/make-smaller-conso...
Re: My preferred .NET console stack
#34Earlier quoted context omitted.
https://docs.python.org/3/howto/argparse.html Python has an argument parser in the standard library
Yes it has, but argparse is not even comparable to [1] Click, or similar libraries. [1] https://click.palletsprojects.com/en/7.x/
Yes but I was responding to the “have to” in: “...a command line option parser which you'd have to pull into a python project...”
Re: My preferred .NET console stack
#35As a .Net developer I've.. never seen people write code at work like this. This looks like a hefty amount of boilerplate to achieve practically nothing. I'm guessing this guy learned Asp.Net first.
Yes and no, I definitely write throwaway C# console apps all the time and just go through the hassle of generating a solution and boilerplate so I might use this kind of thing.
It's a bit heavy, I'd have to invest some time learning his framework but could be worth it. I've certainly written lots of command line parsing and logging code I'm not proud of.
Re: My preferred .NET console stack
#36Earlier quoted context omitted.
That is demonstrably untrue. Very few users care at all about the size of an app, and even fewer devs care to put in all the extra effort to use some unfamiliar tech stack just to save their ambivalent users' machines from using up some extra, but (usually) imperceptible CPU and RAM resources. EDIT: That said, I do wish that the trimming/tree-shaking systems could do more to get the size and speed of easy-to-code sol…
> Very few users care at all about the size of an app That depends on the target audience. IME the target audience of console/CLI programs are more likely to care about size. CLI apps tend to cater more to power users. And many users do definitely care about resource usage, and smaller size apps do in fact tend to use less resources. All users definitely care about performance. A fast app feels nicer. Smaller-sized s…
I deeply care about performant and small apps. I definitely don't want to have 100GB+ games on my disk, 150MB+ Electron based messaging apps, Docker images with 1GB+ node_modules/ folders, or even worse, Docker images with 600MB+ of binaries (looking at Terraform and it's plugins.)
However, I care even more about having apps/tools that help me achieve the desired goals, in an easy, clear, and elegant way.
If having bigger apps means that developers have more time to implement or improve features, and solve bugs, I'm all for it.
Re: My preferred .NET console stack
#37As a .Net developer I've.. never seen people write code at work like this. This looks like a hefty amount of boilerplate to achieve practically nothing. I'm guessing this guy learned Asp.Net first.
You clearly don't work in a large enterprise. Or if you do, you're doing it wrongly.
This is barely any "boilerplate" which he's had to write. As he's extracted this in to a template.
The advantages of having standardised oob validation and options parser for cli is huge.
If you don't recognize that. Meh. I guess just get more experience.
Re: My preferred .NET console stack
#38For Python, I've standardize on click.
It provides simple decorator to turn functions into commands, sub-commands, etc, with easy options and built-in help.
Re: My preferred .NET console stack
#39As a .Net developer I've.. never seen people write code at work like this. This looks like a hefty amount of boilerplate to achieve practically nothing. I'm guessing this guy learned Asp.Net first.
Kind of my line of thinking as well. I would never pull in a library with a 100 features when my software only needs 2 of those features. I write those 2 features myself.
That's dumb. What a waste of time.
Re: My preferred .NET console stack
#40Dependencies, dependencies, dependencies. All for a simple console program. And you end up with a console app that is 20-100MB. Traditionally this program was a few KB. It can still, if you use the right language(s). Making software should not be about making the life of the developer as easy as possible, it should be about making things easy, small, and FAST for the user.
> And you end up with a console app that is 20-100MB What are you talking about? It's 1.4MB. This is the easiest thing in the world to verify: $ dotnet publish -c Release Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET Copyright (C) Microsoft Corporation. All rights reserved. Determining projects to restore... All projects are up-to-date for restore. ConsoleApp -> /tmp/ConsoleApp/bin/Release/net5.0/Conso…
> And no, I don't want to hear about any figures for self-contained builds.
Then what is your point? When talking about the size required for a program to run, you have to weigh all of its dependencies.
For anyone interested, such a binary ends up at least 50MB, if we include the dependencies mentioned in the article in question.