If you could make breaking changes to C#, what would you do?
-
@pie_flavor said in If you could make breaking changes to C#, what would you do?:
That only showcases why braces should be required.
I have a style checker for my C code at work that enforces the braces-required rule. The language might allow them to be omitted, but I don't. As such, this is something that style guidelines can help with.
I'm less worried about the semicolons/newlines thing. Just say that newlines are statement terminators unless escaped, so there's no ambiguity (and allow for the rule to be turned off in multi-line literals and comments, of course). It does mean that longer statements will need escapes in them where they break over lines, but that's no bad thing. The key to all this is that the compiler doesn't guess; it's not an automated insertion of semicolons, but rather an alternate terminator, and so you'll get moaned at if you're sloppy.
-
@dreikin said in If you could make breaking changes to C#, what would you do?:
Because you like to make things harder on newbies, thus holding off your competition?
You think making the underlying structure of syntax more explicit is making things harder on newbies?
-
@lucas1 said in If you could make breaking changes to C#, what would you do?:
"if collection and has items loop and do { whatever in block }, if not do another thing."
Except that's not what it means in Python.
Loop statements may have an else clause; it is executed when the loop terminates through exhaustion of the list [...], but not when the loop is terminated by a break statement.
The way you say it should work makes sense to me. But it's not how it works in Python.
-
@lucas1 said in If you could make breaking changes to C#, what would you do?:
@masonwheeler That kinda defeats the whole point of doing it. You can tell I do python in my spare time.
Fuck it python is shit then ;-)
I should have read the whole thread, obviously.
I still think what you proposed is sensible.
-
@dreikin said in If you could make breaking changes to C#, what would you do?:
make sure the braces match what the indentation leads you to believe they should be
Format document FTW!
-
@jaloopa said in If you could make breaking changes to C#, what would you do?:
@dreikin said in If you could make breaking changes to C#, what would you do?:
make sure the braces match what the indentation leads you to believe they should be
Format document FTW!
Since I learned the keystroke chord Ctrl+K Ctrl+D, I've never looked back :D
-
@raceprouk said in If you could make breaking changes to C#, what would you do?:
Since I learned the keystroke chord Ctrl+K Ctrl+D, I've never looked back :D
Makes finger horns behind RaceProUK
-
@zecc said in If you could make breaking changes to C#, what would you do?:
@raceprouk said in If you could make breaking changes to C#, what would you do?:
Since I learned the keystroke chord Ctrl+K Ctrl+D, I've never looked back :D
Makes finger horns behind RaceProUK
swings over her shoulder at @Zecc :P
-
runs away glad he was behind RaceProUK's other shoulder
-
@dreikin Fun story about the calculation elves, but I have to disagree with the part where it says C# does nothing to help the poor elf avoid stack overflows. On the contrary, it does the most important thing you can do: it gives you looping control flow constructs.
In imperative, object-oriented code, stack overflows really only come from one source: when you screwed up some recursive code. And when this happens, you want to get a stack overflow error, as per the fail-fast philosophy. But situations that are naturally recursive, such as tree processing, almost always have a recursion depth significantly smaller than what it takes to exhaust a standard 1 MB CPU stack.
FP likes to do things recursively by default, due to FP's roots in pure mathematics, and prefers to avoid imperative looping due to dogmatic reasons. Unfortunately, programming is not pure mathematics; it's applied mathematics and formal logic, and it's constrained by real limits, such as call stacks. And so when you try to shoehorn naturally iterative computations into a recursive paradigm, you have to make them tail recursive as a workaround for those physical limitations.
But most iterative computations are not naturally expressed in a tail-recursive form, which means you have to transform the logic into a big mass of frankencode that forces the recursion to the end no matter how awkward that may be, a form that is often more complicated than the natural iterative loop version... so the compiler can turn it into an iterative loop for them. (And one in which they don't get the benefits of fail-fast if they coded it wrong, to boot!)
And then FP advocates wonder why the rest of us don't believe them when they claim it makes programming simpler.
-
@raceprouk said in If you could make breaking changes to C#, what would you do?:
YOU CANNOT FALL THROUGH CASES IN C#.
What if you fall from a really really high place?
-
@boomzilla said in If you could make breaking changes to C#, what would you do?:
What if you fall from a really really high place?
Then once it's all over, you'll B♭.
-
Erase it from history, along with Java, JavaScript, and PHP.
-
@scholrlea said in If you could make breaking changes to C#, what would you do?:
Erase it from history, along with Java.
Why would you do that?
You begin a rant with this sentence, you don't just post it on its own. C# is a very good language.Edit: Oh, you edited it. Javascript and PHP are absolutely worth deleting.
-
If I had to erase one language from history, it would be C. It got so many things wrong and it's set our craft back by decades. (Lisp would be a close second, for many of the same reasons. But it's bizarre enough to have limited appeal, thus limiting its potential to do damage.)
-
@blakeyrat said in If you could make breaking changes to C#, what would you do?:
@jaloopa said in If you could make breaking changes to C#, what would you do?:
Checked arithmetic by default. No point having it if the easy, error prone way is the one you get without doing anything
Seconded.
On the same vein,
DateTimeOffset
should be the default struct for storing date and time info, and should be renamed toDateTime
.(The current
DateTime
should either be chucked in the bin or given an appropriately scary name so developers understand it's very prone to causing hard-to-find bugs.)Do you have something that explains this prone to bugs bit?
I'm interesting in finding out about it.
I tried to search for information, but couldn't find any.
Also, why is offset better?
-
@xaade said in If you could make breaking changes to C#, what would you do?:
Do you have something that explains this prone to bugs bit?
Just the general problems you have when you store times without accounting for time zone.
Think about things like: PDT turned into PST as we were storing that record, so it finished being stored 59 minutes before the user hit the submit button. That's fine as-is, but now you're trying to figure out how long it takes to store records and, oops, have to account for that little nugget of joy.
Since
DateTimeOffset
contains enough information to uniquely identify that time concretely without any kind of time zone confusion, the possibility of mismatched times goes to virtually zero. This all becomes triply important now that we live in a world where the time zones can change, as they did in 2007.Basically put, the correct solution to the problem of storing dates and times is to store them in an entirely unambiguous way and, if you later need to display the local time for a particular event, re-construct the time from the unambiguous representation. Scientists/archaeologists use the Julian Day Count system for this, which even works for dates back before the Gregorian calendar was universally accepted.
-
@blakeyrat said in If you could make breaking changes to C#, what would you do?:
Think about things like: PDT turned into PST as we were storing that record, so it finished being stored 59 minutes before the user hit the submit button. That's fine as-is, but now you're trying to figure out how long it takes to store records and, oops, have to account for that little nugget of joy.
My personal favorite is how DateTime.Now is always in the server's time zone. So if your datacenter moves, or if you're in the cloud, the value you get may not be what you expect.
-
@unperverted-vixen Yeah, I worked for a previous company where we "solved" that by just ensuring all our servers ran in ET.
Problem is: there's (practically) no such thing as ET. There's EST and EDT, so we still had the "when the clock switches from one timezone to another we end up with garbage data" issue. (I guess you can toggle that off in Windows, which I suppose means you get EST year-round, but... whatever.)
Point is, it caused stupid silly problems that would never have been problems if we had been tracking times correctly in the first place.
-
@unperverted-vixen That's why they're replacing DateTime with DateTimeOffset type in newer version of EntityFramework.
Replacing every instance of DateTime in your source code to DateTimeOffset should worth it in your case.
-
@cheong I'd love to, but that would involve the NotQuiteAsWtfFramework team making that same change, which feels to me like they'll do round about the fifth of never.
(For now, we have a standard of storing UTC for everything, and doing a time zone conversion only at the time of display/input. There's been some massaging needed when using deserializing dates from third party APIs - Json.NET doesn't seem to always set the Kind correctly - but using DateTimeOffset internally and switching to DateTimes where I interact with the framework is so not worth it. If I could pick what intensive-rewrite procedure they did, my first choice would be to switch to .NET Standard...)
-
@unperverted-vixen said in If you could make breaking changes to C#, what would you do?:
For now, we have a standard of storing UTC for everything, and doing a time zone conversion only at the time of display/input.
If you switch to DateTimeOffset, you get that FOR FREE with the framework enforcing translating to a timezone on display and with no possibility of human error.
-
@blakeyrat I agree, that would be nice. Unlike @Weng's WtfFramework, I've got very little say in our core framework; just some of the apps built using it. For now, I think consistency is the lesser sin. I reserve the right to change my mind later, though. ;)
-
@blakeyrat said in If you could make breaking changes to C#, what would you do?:
Just the general problems you have when you store times without accounting for time zone.
Thanks a lot for that.
My company stores everything in UTC, but also stores the timezone used when the data was entered. That way you can reconstitute the time from when it was entered, in case the operator is viewing data from another timezone and they want the time local to the data entry.
Just goes to show how much effort people keep putting into get date/time right.
-
@masonwheeler said in If you could make breaking changes to C#, what would you do?:
If I had to erase one language from history, it would be C. It got so many things wrong and it's set our craft back by decades.
I'm rather fond of C. I do a fair bit of work with low-level systems, and the alternatives to C are assembler and C++, with the latter having to be a very restricted subset (No exceptions! No standard library! No boost!). Now of course, doing low-level work in assembler is possible, but you typically want to keep that sort of thing as short as possible as assembler is fairly miserable to code in. Not as bad as direct machine code, but even so…
C is the lowest-level mostly-portable layer available on most hardware. As long as people remember that that is its actual niche (where it is pretty close to perfect) and don't think that it is anything else, it's not a problem.
-
@pie_flavor said in If you could make breaking changes to C#, what would you do?:
Javascript and PHP are absolutely worth deleting.
QFT.
-
@dreikin said in If you could make breaking changes to C#, what would you do?:
@magus said in If you could make breaking changes to C#, what would you do?:
@raceprouk But it's limited to
short
,int
,long
, andchar
I believe. Because, as Blakey has pointed out, they have that dumb chars-can-be-ints brainworm....dammit.
New proposal:
- Enums can be (at least) any numeric type.
How fuzzy would you expect the floating-point match to work?
-
@djls45 said in If you could make breaking changes to C#, what would you do?:
@dreikin said in If you could make breaking changes to C#, what would you do?:
@magus said in If you could make breaking changes to C#, what would you do?:
@raceprouk But it's limited to
short
,int
,long
, andchar
I believe. Because, as Blakey has pointed out, they have that dumb chars-can-be-ints brainworm....dammit.
New proposal:
- Enums can be (at least) any numeric type.
How fuzzy would you expect the floating-point match to work?
-
@dkf said in If you could make breaking changes to C#, what would you do?:
I'm rather fond of C. I do a fair bit of work with low-level systems, and the alternatives to C are assembler and C++, with the latter having to be a very restricted subset (No exceptions! No standard library! No boost!). Now of course, doing low-level work in assembler is possible, but you typically want to keep that sort of thing as short as possible as assembler is fairly miserable to code in. Not as bad as direct machine code, but even so…
C is the lowest-level mostly-portable layer available on most hardware. As long as people remember that that is its actual niche (where it is pretty close to perfect) and don'tI agree with most... However, if one really understands what is happening, exceptions, STL (now part of the core libraries) and other features are quite acceptable. And I am talking about true realtime systems where timing tolerances can be in the sub uS range (though typically in the sub mS).
-
@thecpuwizard said in If you could make breaking changes to C#, what would you do?:
However, if one really understands what is happening, exceptions, STL (now part of the core libraries) and other features are quite acceptable. And I am talking about true realtime systems where timing tolerances can be in the sub uS range (though typically in the sub mS).
So am I, but with less RAM (per core) than you. You really can't put much in 32kB, and exceptions just add too much overhead. Without them, you can't really do the STL either.
Why yes, we have tried. ;)
-
@djls45 said in If you could make breaking changes to C#, what would you do?:
@dreikin said in If you could make breaking changes to C#, what would you do?:
@magus said in If you could make breaking changes to C#, what would you do?:
@raceprouk But it's limited to
short
,int
,long
, andchar
I believe. Because, as Blakey has pointed out, they have that dumb chars-can-be-ints brainworm....dammit.
New proposal:
- Enums can be (at least) any numeric type.
How fuzzy would you expect the floating-point match to work?
Not fuzzy, unless an ε is specified. They're enums - the compiler should be able to handle pretty much everything that would in other circumstances cause a problem.
-
@raceprouk said in If you could make breaking changes to C#, what would you do?:
@cheong said in If you could make breaking changes to C#, what would you do?:
Marking answers is part of her job as moderator there.
No, her job is to moderate the discussion. That's why her role is 'moderator', not 'expert' or 'specialist'.
Answers should only be suggested by people who know what the answer should be.
WHAT?!? Is this like that silly claim that mod and admin aren't the same role ??? ??? ???
You must be !!!</> :P
-
@blakeyrat said in If you could make breaking changes to C#, what would you do?:
Yeah, I worked for a previous company where we "solved" that by just ensuring all our servers ran in ET.
My company is doing that. There's been a little talk about switching, but I'm not sure whether that's in the upcoming major version or not. In the meantime, we have to deal with timezone differences and daylight savings changes during the year, especially with historical timestamps. It's because of this that I learned that British time and American time switch their daylight savings offset about a week apart. For half the year, all our data for the other half of the year appear to be timestamped an hour off. For locations in the UK, during the two week-long times in the year when one is on daylight savings and the other isn't, the historical timestamps either agree or are off by two hours instead of one.
Problem is: there's (practically) no such thing as ET.
Yeah, I don't believe flying-bicycle aliens exist, either. :P