131–140 of 188 posts
> Top-level programs allow you to write the main method of your application without having to add a class with a static Main method Riveting stuff happening in .Net land! Sarcasm aside, this seems like such a small, oddly-specific, once-off feature that its like...why bother? Any C# devs want to enlighten me here?
I really love c# - one of my favrorite languages, but can any one explain the benefit of this new syntax? Person p1 = new(); Person p2 = new("Tom"); Person p3 = new() { FirstName = "Tom" };
Scala 3 kills C# by a large margin, imho. C# is not a good pursuit unless you are stuck with .Net codebase.
+1 for top-level programs -1 for target-typed expressions, it makes code unreadable, i'd rather see var used as field members
Earlier quoted context omitted.
top level is mostly going to be nice when teaching new programmers. You can just get on with hello world and now have to type all this boiler plate and explain why you have to. But yeah, for "real" programs it is probably irrelevant. But who knows, maybe we will find a use for it. I am mostly excited about the sort-of option type getting rid of nulls option.
> top level is mostly going to be nice when teaching new programmers. You can just get on with hello world Yeah it seems like kind of a weird thing? “Here’s marginally less boilerplate once , if someone is going to learn to use the language, they may as well learn how it actually works instead of hiding stuff that they’ll soon see anyways...
It have always been a clear benefit of say Python that you can provide a two-line code snippet which can actually run.
It is also step in the continuing process of removing boilerplate. C# started out like Java, but have over time removed boilerplate where possible. "public static void Main()" is also just boilerplate.
I agree it won't matter for larger real-world program.
Earlier quoted context omitted.
what do you mean by "execute it"? It's source, you need to compile it and get an executable out of it. This is not Python, an interpreter. But if you want an interpreter for C#, nobody's stopping you to write one. Me, on the other hand, I want Python to become a compiled language. And to those who's going to reply with "PyPy/Cython/Nuitka" I have a question for them: -do show me a .dll from those!
To give an example, in Swift, I can write a hello.swift with: #!/usr/bin/env swift print("Hello") And after a chmod +x, it works. Granted, anyone who I distribute this to will need a swift compiler installed, but that’s to be expected (and similar for Python.) Golang and other “compiled” languages have similar ways of making this work too.
Earlier quoted context omitted.
Yes that is possible, you can produce an .exe which contains your application's assemblies but relies on the appropriate .NET runtime being present on the user's computer. You can also build a .exe which has the .NET runtime bundled, but it can be quite big. I made a simple program that wrote "Hello World" to the console [1] and it was between 46-78MB: https://blog.mclemon.org/no-this-is-what-peak-hello-world-lo...
Yeah, it's not really a "real" native binary. You can get it down to 8kb by jettisoning all comforts: https://medium.com/@MStrehovsky/building-a-self-contained-ga... but that's not exactly practical.
Can I just create a single .cs file somewhere, and execute it by typing its name? No Visual Studio solution/project shenanigans? That’s my dream. Top-level programs to eliminate boilerplate is a nice related step.
Earlier quoted context omitted.
To give an example, in Swift, I can write a hello.swift with: #!/usr/bin/env swift print("Hello") And after a chmod +x, it works. Granted, anyone who I distribute this to will need a swift compiler installed, but that’s to be expected (and similar for Python.) Golang and other “compiled” languages have similar ways of making this work too.
Oh, I get it. You mean install some sort of interpreter that is called by the OS for that language. Sorry, I live in real world, where customers don't allow you to install a gazzilion files just to run your application, they expect a proper installer that is under strict supervision by their admin team and you only deliver executables.
Earlier quoted context omitted.
top level is mostly going to be nice when teaching new programmers. You can just get on with hello world and now have to type all this boiler plate and explain why you have to. But yeah, for "real" programs it is probably irrelevant. But who knows, maybe we will find a use for it. I am mostly excited about the sort-of option type getting rid of nulls option.
> top level is mostly going to be nice when teaching new programmers. You can just get on with hello world Yeah it seems like kind of a weird thing? “Here’s marginally less boilerplate once , if someone is going to learn to use the language, they may as well learn how it actually works instead of hiding stuff that they’ll soon see anyways...
After all, why optimise the language for "Hello world" ? How important is that case? language designers rightly decided that supporting large programs was more important.
In the code that your team has been working on for years, you'll be glad of all of those "overhead" things, that help you manage complexity and decompose the program.
But yeah, show it to a c# newbie who is used to e.g. Python where "Hello world" is literally a one-liner and they might think "what a crapsack language, there's like 6 lines of overhead per 1 line of code, argh this is as bad as Java" - I've seen pretty much this reaction. Is it justified? From my POV, not at all. But I have seen that happen.
Top-level statements (i.e. compiler-generated boilerplate instead of Visual Studio-generated boilerplate) does seem like an "on-ramp" feature that would be discarded as the program grows past a few lines though.