.NET for Beginners (2020) • Hacker News Board

Re: .NET for Beginners (2020)

#181

Post by wvenable » Wed, Apr 21, 2021, 9:24 PM UTC

setr wrote: post #180

wvenable wrote: post #172

Earlier quoted context omitted.

> So the framework to pick for a new application is... I don't know. You just described all UI the frameworks, what replaces what, and what the limitations are! Microsoft also lays that out here: https://docs.microsoft.com/en-us/windows/apps/desktop/choose... I've answered this question for myself: WPF. It's neither bleeding edge nor is it obsolete. You can complain about the current state of things but I don't think…

>You just described all UI the frameworks, what replaces what, and what the limitations are! Microsoft also lays that out here The problem is that all options lack some core fundamental expected feature. From that chart, WinForms lack High DPI awareness and customizable UI (tbh I'm not sure what customizable means here -- that custom controls/views are difficult or just skinning is difficult?), WPF also lacks High DP…

> WPF also lacks High DPI

WPF is system-DPI aware but it's not aware of per-monitor DPI as that feature didn't exist at all when WPF was conceived. I guess these days Microsoft doesn't consider that good enough to be called High DPI aware.

> I've just been looking at the charts like that, and my ultimate answer is "???"

I don't know -- I guess find it much less difficult than picking a web framework. The problem is that GUI frameworks (in any platform) are a complex mix of trade-offs. .NET and Windows is not the unique in this regard.

> The high rate of churn in the MS ecosystem can be blamed on MS.

I'm not sure you can call frameworks that have been around for multiple-decades a high rate of churn. The problems that Microsoft have is no different any of other platforms you've discussed. Yes, it's one organization but the problems are all the same. New developments require new framework but developers have lots of existing code. The fact that Winforms still exists is the same reason jQuery still exists.

Microsoft wanted everyone to move over to UWP -- this is kind of exactly what you're suggesting -- but developers just weren't interested. So they had to go back and take a more broad approach. But UWP is/was supposed to be the future.

> it's quite clearly a result of constantly changing vision of how the .NET ecosystem should look like

Not just the .NET ecosystem but the broader software industry as well. Many of the changes that Microsoft is making to .NET relate to changes made in mobile and on the web. As the world changes, .NET changes, and thus Microsoft maybe adds a new GUI framework to fit that world. Without that sort of change, we'd all still be using Winforms.

But I don't disagree. Microsoft has been in a long transition period to .NET core and they're finally started to come out the other side. With that done, there will be renewed effort to bring everything else together as well. I suspect in another couple of years this mess will be a lot more cleaned up. But I expect, unlike with other platforms, that most of my code written today will still work with whatever Microsoft comes up with in the future.

Re: .NET for Beginners (2020)

#182

Post by akra » Wed, Apr 21, 2021, 9:27 PM UTC

kaba0 wrote: post #148

akra wrote: post #46

Anecdotally when I've had to show developers how to start with .NET Core the problem isn't the SDK (install dot.net at the website) or which template to use (i.e. just tell them to pick that one) its C#. This is especially true if they come from a JS, Python or Go background. I say this as someone who does doesn't mind C# and thinks its pretty capable once the learning curve has passed. At one stage I had a JS develo…

I think your comparison is not fair. Maybe your vision of beginner C# is just much much higher than on F#? Like, dependency injection, mocking and the like are not at all beginner concepts, and are not made particularly easier with more modern languages.

I'm just stating the experience I had, and the observations I encountered in that job that formed that opinion. To clarify I'm talking about a beginner that needs to be productive quite quickly to earn their paycheck so their code has to somewhat scale to a medium sized solution and get accepted by a senior dev in a PR process. If they aren't beginner concepts as you state why are they in most "Getting Started" templates and their use is mandatory? As an example many of the common app types use a DI framework straight away following its own standard (e.g. ASP.NET, Spectre.Console, etc) and while an experienced person picks this up quickly someone new to the language from what I've seen struggles. These are concepts I had to explain to a beginner I had to mentor at the time pretty quickly.

Most F# code bases I've seen that make it to prod don't use frameworks for those concepts even as they scale; basic functional patterns seem to scale up to reasonable sized solutions. If they do use mocking/di/etc its only to make the code more C# consumable at the edge for some other C# framework they are required to use. I'm not talking about toy projects here. My point was more that at some point with C# you will need to learn these things quite quickly even for basic use cases or find yourself writing clunky boilerplate (which most new developers will default to - the you don't know what you don't know problem). However with some other languages you may never need to until much later in the learning cycle - I was working for a very successful large business that built the whole stack without ever using some of these things. If you want to encourage people onto your platform these are some of the people you need to win.

IMO It just seemed the standard to get nice code that was prod ready in F#, even JS or Go, doesn't require as much learning's as a C# app. It's not just a C# problem mind you but from what I've experienced first hand it has scared developers away.

Re: .NET for Beginners (2020)

#183

Post by kaba0 » Wed, Apr 21, 2021, 11:15 PM UTC

akra wrote: post #182

kaba0 wrote: post #148

Earlier quoted context omitted.

I think your comparison is not fair. Maybe your vision of beginner C# is just much much higher than on F#? Like, dependency injection, mocking and the like are not at all beginner concepts, and are not made particularly easier with more modern languages.

I'm just stating the experience I had, and the observations I encountered in that job that formed that opinion. To clarify I'm talking about a beginner that needs to be productive quite quickly to earn their paycheck so their code has to somewhat scale to a medium sized solution and get accepted by a senior dev in a PR process. If they aren't beginner concepts as you state why are they in most "Getting Started" templ…

But that’s a problem with a specific framework, not C#. It’s true that some frameworks are quite hard to avoid using, but you could just as well create a lean vanilla project (which I gather the F# one was closer to), and you can choose not to use DI. I doubt F# would be all that much more expressive than C#, that you could not recreate whatever you did there.

Re: .NET for Beginners (2020)

#184

Post by akra » Wed, Apr 21, 2021, 11:44 PM UTC

kaba0 wrote: post #183

akra wrote: post #182

Earlier quoted context omitted.

I'm just stating the experience I had, and the observations I encountered in that job that formed that opinion. To clarify I'm talking about a beginner that needs to be productive quite quickly to earn their paycheck so their code has to somewhat scale to a medium sized solution and get accepted by a senior dev in a PR process. If they aren't beginner concepts as you state why are they in most "Getting Started" templ…

But that’s a problem with a specific framework, not C#. It’s true that some frameworks are quite hard to avoid using, but you could just as well create a lean vanilla project (which I gather the F# one was closer to), and you can choose not to use DI. I doubt F# would be all that much more expressive than C#, that you could not recreate whatever you did there.

From what I've experienced code based frameworks are often used because the language itself doesn't handle that case well on its own. In the case of F#, JS, etc, using DI again as an example, partial completion/currying once you get your head around it means that quite often programs are just chained one line factories (similar to the one line you used to register your singleton/instance in a DI framework so no more code bloat). As a bonus you learn something that is multi applicable, not just for DI and doesn't bring in any more "magic" or runtime errors if a registration is missing because the compiler catches it. Everything is just functions/modules which means mocking is a breeze too, refactoring is easier, etc.

This is my own personal experience here mentoring dev's in both technologies, especially when they come from different backgrounds. YMMV.

Re: .NET for Beginners (2020)

#185

Post by tonyedgecombe » Thu, Apr 22, 2021, 8:13 AM UTC

manigandham wrote: post #83

imgabe wrote: post #71

Earlier quoted context omitted.

I'm currently trying to write a windows app and coming from web development (Python/Django and React) it is bewildering. Part of the problem is with web development, complicated as it is, the tutorials at least get you to a complete, working example. The windows tutorials seem to be very piecemeal where you start with a mostly complete app and fill in a couple things, but never get the whole picture. And like in your…

Desktop UI is very different from web, and most languages have multiple choices. WPF is the latest Windows-only, Windows Forms is legacy (from Windows XP era), Xamarin is cross-platform. These is in the descriptions on the page, or you can click on the documentation and follow the breadcrumbs to the main topic for the Desktop Guide: https://docs.microsoft.com/en-us/dotnet/desktop/?view=netdes... However you can just…

>WPF is the latest Windows-only

No it isn't. WinRT, UWP and WinUI are all later than WPF.

Re: .NET for Beginners (2020)

#186

Post by citrin_ru » Thu, Apr 22, 2021, 11:12 AM UTC

kaba0 wrote: post #128

Traubenfuchs wrote: post #125

Earlier quoted context omitted.

Because winforms is an incredibly easy and solid technology. It's a joy to work with.

CPU rendering should not be a thing in 2021

CPU GUI rendering was reasonably fast for Win32 apps on Pentium III. Modern CPU many times faster and I expect GUI rendering to use negligible fraction of CPU resources. Why this is not the case? Display resolution nowadays is higher, but the difference in pixel numbers is smaller than difference in CPU performance.

Re: .NET for Beginners (2020)

#187

Post by kaba0 » Thu, Apr 22, 2021, 11:41 AM UTC

citrin_ru wrote: post #186

kaba0 wrote: post #128

Earlier quoted context omitted.

CPU rendering should not be a thing in 2021

CPU GUI rendering was reasonably fast for Win32 apps on Pentium III. Modern CPU many times faster and I expect GUI rendering to use negligible fraction of CPU resources. Why this is not the case? Display resolution nowadays is higher, but the difference in pixel numbers is smaller than difference in CPU performance.

Older graphics were much more simpler, like draw a line here and here, where you have to iterate through like 400px per line of a window border. Also, smaller resolution.

CPUs are fast, and rendering could be multithreaded, but 4-16 very fast cores will still be slower than the very very wide SIMD of GPUs that can simultaneously operate on many many pixels. GPUs can also change to a different “lane” to compute while it waits on IO like some graphics. You also got gradients, transparency and the like, so you basically always have to do a full pass over every pixel, so on the order of 1000*1000 pixels. So GUI rendering definitely doesn’t use negligible CPU resources. It is the canonical example for a task that can be parallelized, so it only makes sense to do so.

Re: .NET for Beginners (2020)

#188

Post by citrin_ru » Thu, Apr 22, 2021, 2:37 PM UTC

kaba0 wrote: post #187

citrin_ru wrote: post #186

Earlier quoted context omitted.

CPU GUI rendering was reasonably fast for Win32 apps on Pentium III. Modern CPU many times faster and I expect GUI rendering to use negligible fraction of CPU resources. Why this is not the case? Display resolution nowadays is higher, but the difference in pixel numbers is smaller than difference in CPU performance.

Older graphics were much more simpler, like draw a line here and here, where you have to iterate through like 400px per line of a window border. Also, smaller resolution. CPUs are fast, and rendering could be multithreaded, but 4-16 very fast cores will still be slower than the very very wide SIMD of GPUs that can simultaneously operate on many many pixels. GPUs can also change to a different “lane” to compute while…

> smaller resolution

In early 2000s I've used a PC with 800x600px CRT monitor and one of early Intel Celerons. My memory is fuzzy, but at best it was cheapest Coppermine Celeron (more likely Mendocino). Nowadays I use notebook with Intel Core i5 2540M (quite old) and the biggest display I use has 2560x1440 pixels (much newer than notebook).

Now I have at most (2560x1440)/(800x600) ~ 8 times more pixels. I didn't find numbers from the same benchmark for Coppermine and i5 2540M, but I expect 2540M to be at least 10 times faster than slowest Coppermine.

So I think modern CPU are fast enough to render GUI at least as fast as 15-20 years ago. GPU of course can do this much faster, cannot argue with this.

> You also got gradients, transparency and the like

I wonder if users really want this or we have it for other reasons (like developers want to show-off and companies want to sell new OS/App). For me the peak GUI was around Windows 2000 - most of what come next was not really an improvement for me. I'm not representative (and mostly use i3 WM, not Windows), but the fact that Widnows XP was used well beyond official support ended and many users around the world still use Windows 7 tells that many users don't really want to follow the latest GUI trends, but instead they are forced to.

Re: .NET for Beginners (2020)

#189

Post by tracker1 » Thu, Apr 22, 2021, 2:45 PM UTC

okareaman wrote: post #68

tracker1 wrote: post #36

Earlier quoted context omitted.

Mono was an implementation of the CLI ... the "Design" of the language, and CLI were absolutely designed to be cross-platform.

You've gone from saying "C# and .Net (CLR) were absolutely written/meant to be portable" to "CLI was absolutely designed to be cross-platform." I feel you are not arguing in the spirit of my assertion that "C# was never intended to run everywhere" Sure, it was designed cross-platform so it would run on Dos/Windows ME and Windows NT.

CLR was designed to be cross platform from the beginning. Sorry for mistyping in the response.

The fact that Microsoft mgt never ran/supported that prior to Satya and .Net Core had nothing to do with the platform and language design.

Re: .NET for Beginners (2020)

#190

Post by kaba0 » Thu, Apr 22, 2021, 3:12 PM UTC

citrin_ru wrote: post #188

kaba0 wrote: post #187

Earlier quoted context omitted.

Older graphics were much more simpler, like draw a line here and here, where you have to iterate through like 400px per line of a window border. Also, smaller resolution. CPUs are fast, and rendering could be multithreaded, but 4-16 very fast cores will still be slower than the very very wide SIMD of GPUs that can simultaneously operate on many many pixels. GPUs can also change to a different “lane” to compute while…

> smaller resolution In early 2000s I've used a PC with 800x600px CRT monitor and one of early Intel Celerons. My memory is fuzzy, but at best it was cheapest Coppermine Celeron (more likely Mendocino). Nowadays I use notebook with Intel Core i5 2540M (quite old) and the biggest display I use has 2560x1440 pixels (much newer than notebook). Now I have at most (2560x1440)/(800x600) ~ 8 times more pixels. I didn't find…

Well, drawing GUIs one pixel (okay with SIMD 4-8) at a time on a CPU core is still way too big of an overkill, especially that for display it usually gets through a GPU, so it gets written to memory and then copied over vs being generated into video memory itself. A CPU core is way too expensive for these “easy” calculation, like paint it black.

And I’m not sure about the dates, but iGPUs have been around for quite some time now. Also, Windows 7 (I think the change happened at Vista) most definitely uses a compositor, so there is no CPU rendering at that level.