It's a "double quarter pounder" because it has two quarter pound patties. It does not have a half pound patty. I don't think this was because they didn't want to say "half" but because it literally has two patties.
The permission for microphone usage? Yes. The microphone permission was added in iOS 7 in 2013. On Google you can find timestamped references (on Stack Overflow, etc.) to the microphone permission that are more than 10 years old.
The heap stuff is new I guess, we didn't have that back when I was writing programs in it. So, yea, not so safe anymore. :D I take back what I said about it being safer then. I can't go back and edit my original post, it's been too long.
The compiler did normally warn for data bounds checking, so I figured it would in this case. If that's not the case anymore then I'm wrong.
Do you mean something other than "terse" here? Or are you perhaps thinking of a different language? I cannot possibly imagine that adjective being used to describe COBOL. It is the #1 textbook example of a verbose language--the opposite of terse.
There isn't much obvious benefit in using TUIs, but writing TUIs has a big upside: it's easier in most ways. It's trivially cross-platform, you don't have to make pixel-perfect GUIs (because it's impossible), you don't need icons or graphics (because you can't show graphics), etc.
That's the main reason. TUI programs can be created quickly, and they're mostly developer-oriented, so they just need to be useful enough and don't need to be optimized as much as a GUI program.
I'm glad they're simply turning C# into F#. They're coming to us where we are, rather than forcing us to make a jump. I'm a relatively "blue collar" developer, I know a little about FP (not enough to be productive in F#) but I have tons of C# experience. I appreciate them taking the good stuff from F# and making it understandable to C# developers. It's been a delightful progression; no big jumps, no paradigm shifts, just the steady addition of useful new features that I can understand.
I agree with you, as far as adding new features to C# from F#. When I have the time to refactor larger codebases, I'm often finding new C# features/syntax makes the code easier to understand and reason about (often due to decreasing the number of lines needed to accomplish the same thing, without overcomplicating things). I do make sure that if I'm introducing new language features, that I'm refactoring related portions of code, so I'm not leaving behind the "old" way of doing things while also introducing the "new" way for the same functionality. I'm always thinking of the next developer with anger issues coming into the codebase after me.
So the issue for those of us in F# land, is that it's really not a big jump from C#. I've taught it (lightly) to at least one C# dev who basically picked it up in a weekend.
Something that helps, a ton, is as you're transitioning, you can write code almost identically to how you did before. It doesn't force FP on you at all. It's less useful if you try to do that, because you're not taking advantage of the language, but it makes testing your beliefs on how things work SUPER easy because you can set it up in the OOP way, get the result you expect, then set up in what you think is the correct FP way, and see if it matches.
The only issue is there's a severe lack of beginner friendly documentation (although it's leagues better than it used to be). I honestly think that if you're a C# dev, it's probably worth giving it a weekend or two to play with. ESPECIALLY if you like linq syntax.
HTML5's HTML syntax is no longer SGML-based. It's still invalid but no longer because of anything related to SGML; now it's simply because the HTML5 spec says so.
Microsoft does officially call their implementation of the C++ Standard Library in MSVC "the STL." This is due to historical confusion, of course, but it persists to this very day in official materials. Check out the name of this repository and the way that they refer to it in the readme text. Always the acronym "STL" and never "Standard Template Library" so we can all pretend it simply stands for "C++ Standard Library" now.
One thing I especially like about developing data-heavy financial apps in Windows Forms is the DataGridView control. High density and high performance with filtering, sorting, and drag-and-drop column reordering and resizing. No paging required; if you want to stick 10,000 rows in there, that's fine. Most of the UIs we write are screens full of DataGridView panes. Ugly? Yes. Fast? Also yes.
My attempts to write similar UIs in React have mostly been failures due to poor performance. I resorted to bypassing React entirely for data tables in order to get acceptable render performance. Even then, I have to minimize the number of DOM elements per row so that the browser rendering itself isn't unacceptably slow.
WinForms is still probably my favorite UI framework. It's absolutely a blunt tool but by god can you swing it around. Incredibly flexible, reasonably easy to use, pretty fast, and ugly as all hell.
Hell, you can even throw arbitrary Objects at it and it will just work. You can nest PropertyGrids within PropertyGrids, extend them to collections of objects, build arbitrarily deep nests of controls. All without touching or even caring about the underlying structure of the objects your UI connects to (within limits).
WinForms is my platonic ideal of a UI framework. It's exactly how I would design things.
reply