Live data from Hacker News

My preferred .NET console stack

devlead.se

11–20 of 119 posts

Re: My preferred .NET console stack

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

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 solutions way down.

Re: My preferred .NET console stack

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

>it should be about making things easy, small, and FAST for the user.

If that would be true people would be using IRC, not Slack or Teams. Users don't care and your statement is completely false.

Re: My preferred .NET console stack

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

In photography they say the best camera you can own is the one you have on you when you want to take a picture. Most cameras these days are cell phones.

In software, the best software is one that was built and works to solve a problem, not necessarily one that is engineered perfectly.

Otherwise slack, chrome, etc... wouldn’t routinely eat up 1GB of ram just to open.

They do, they are well liked.

Re: My preferred .NET console stack

#14
post #11
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.

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 software tends to be faster. Weird correlation? I think not.

Re: My preferred .NET console stack

#15
post #10
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.

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…

Who said you have to? In fact you don't at all. He's only pulling in 5 dependencies. One is a command line option parser which you'd have to pull into a python project as well. The second is a bridge for that parser to integrate with the dependency injection - which you arguably may or may not need. Third & Fourth are for logging. The last one is completely unnecessary and can be ignored. Again it's just his way of doing things.

But lets not create this false narrative that somehow .NET has become super complex. Anyone can create a console application with -

dotnet new console -n TestConsoleApp

Re: My preferred .NET console stack

#17
post #10
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.

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

Net tooling used to be horror. Now its good. Speaking as someone who does CI/CD work on it for a long time. You seem to speak as someone who doesn't have .net muscle memory.

Programming is complex, unless you finish with hello world (even hello world is complex in enterprise environments).

Re: My preferred .NET console stack

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

>it should be about making things easy, small, and FAST for the user. If that would be true people would be using IRC, not Slack or Teams. Users don't care and your statement is completely false.

I am not sure most users would agree with your assessment that IRC is easy. To many it is arcane.

If you created two Telegram alternatives, that was identical except for performance, would users not choose to use the most performant one?

Statistics like these (I just found at random, but there are many like it available) demonstrates that your average user do in fact care a lot about performance:

https://www.marketingdive.com/news/google-53-of-mobile-users...

Re: My preferred .NET console stack

#19
post #10

Earlier quoted context omitted.

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…

Who said you have to? In fact you don't at all. He's only pulling in 5 dependencies. One is a command line option parser which you'd have to pull into a python project as well. The second is a bridge for that parser to integrate with the dependency injection - which you arguably may or may not need. Third & Fourth are for logging. The last one is completely unnecessary and can be ignored. Again it's just his way of d…

https://docs.python.org/3/howto/argparse.html

Python has an argument parser in the standard library

Re: My preferred .NET console stack

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

It makes a lot of sense to make development and maintenance easy, because that is where all the costs are. Size of the resulting app only matters in certain circumstances (say, distribution of ios apps) and rarely matters for Console stuff.

Dependencies, dependencies, dependencies = Reuse, modularisation, standardisation of boilerplate

Post reply on HN