Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My preferred .NET console stack

devlead.se

Post reply on HN
Print view View original

41–50 of 119 posts

Re: My preferred .NET console stack

#41

Post by ripley12 »

nend wrote: post #30
bob1029 wrote: post #5

Spectre.Console looks like a really neat library. I am going to have to check this one out for some of my CLI utilities. With the advent of Blazor, you could also look at building rich UX on top of the very same business services used in the console variant. I have found that Blazor is productive enough to consider using universally for management/configuration/admin dashboards for whatever business process. You coul…

Blazor is still a bit rough around the edges but I find it so promising. I really hope Microsoft whole heartedly embraces it for front end development.

Have you seen the Blazor work planned for .NET 6? Hot reload and desktop apps with Blazor UI are both priority-0 (ultra-high priority) epics, I'm really looking forward to it.

https://themesof.net/

Re: My preferred .NET console stack

#42

Post by disgrunt »

pierrebai wrote: post #38

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

Click is great and a feature-rich option. But recommend checking out Typer, which is even simpler if you're already using type annotations. [0]

[0]: https://github.com/tiangolo/typer

Re: My preferred .NET console stack

#43

Post by wongarsu »

AnIdiotOnTheNet wrote: post #25
nick_ wrote: post #11

Earlier 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…

They do care, they've just gotten used to bloated software and therefore don't have high expectations. I submit that this is indicative of our failings as an industry.

I don't see much evidence that they care until it notably impacts their free disk space, which at current storage sizes is when you reach about 1GB (or even much later, depending on your target demographic)

Re: My preferred .NET console stack

#44

Post by janto »

disgrunt wrote: post #42
pierrebai wrote: post #38

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

Click is great and a feature-rich option. But recommend checking out Typer, which is even simpler if you're already using type annotations. [0] [0]: https://github.com/tiangolo/typer

"Typer stands on the shoulders of a giant. Its only internal dependency is Click."

Re: My preferred .NET console stack

#45

Post by bradford »

hacker_9 wrote: post #16

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

> This looks like a hefty amount of boilerplate to achieve practically nothing.

I have yet to find a good way to avoid boilerplate in handling command line input on my console applications.

My naïve self feels that it should be standard, and yet every console application operates with different nuances. It's also a part of code that I see a disproportionate amount of bugs/feedback on (for sufficiently complicated programs). I see developers consistently underestimate the work required on handling command-line input.

I don't think this guys solution is a silver bullet but I'm happy to see the methods.

Re: My preferred .NET console stack

#46

Post by jesseryoung »

erikbye wrote: post #7

Dependencies, 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.

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

To be honest, I don't think the typical use case for a template like this is to "Make software", it's to solve a problem as quickly and cheaply as possible. Building software to solve these types of problems is 99% about solving the problem and 1% about how well it performs.

Re: My preferred .NET console stack

#47

Post by DavidWoof »

bradford wrote: post #45
hacker_9 wrote: post #16

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

> This looks like a hefty amount of boilerplate to achieve practically nothing. I have yet to find a good way to avoid boilerplate in handling command line input on my console applications. My naïve self feels that it should be standard, and yet every console application operates with different nuances. It's also a part of code that I see a disproportionate amount of bugs/feedback on (for sufficiently complicated pro…

Nobody should be writing one-off command line parsing code. If you don't want something fairly heavy like Spectre, then just pull in a lighweight library like CommandLineParser.

Re: My preferred .NET console stack

#48

Post by oblio »

pierrebai wrote: post #38

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

I was using click, but it requires too much boilerplate. Fire is much simpler to use, just as powerful (or maybe 95% as powerful) and it's developed by Google devs (it's not an official Google project as far as I remember), so it seems of reasonable quality.

https://github.com/google/python-fire

Re: My preferred .NET console stack

#49

Post by throwawaybutwhy »

ripley12 wrote: post #33
erikbye wrote: post #7

Dependencies, 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…

> 'in the same ballpark as Go'

Not the lowest rung on the ladder.

Re: My preferred .NET console stack

#50

Post by danmg »

bradford wrote: post #45
hacker_9 wrote: post #16

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

> This looks like a hefty amount of boilerplate to achieve practically nothing. I have yet to find a good way to avoid boilerplate in handling command line input on my console applications. My naïve self feels that it should be standard, and yet every console application operates with different nuances. It's also a part of code that I see a disproportionate amount of bugs/feedback on (for sufficiently complicated pro…

The optparse-generic library in Haskell generates a CLI directly from a struct.
Post reply on HN