Earlier quoted context omitted.
Do you actually work with C#, LINQ and generics?
Yes. I am quite familiar with them.
Then tell me how you can model in C# a type where a property can’t be negative or a certain length.
The memory safety problem isn't bad coders
201–210 of 225 posts
Re: The memory safety problem isn't bad coders
#202Earlier quoted context omitted.
You are comstructing an elaborate strawman that does nothing to work in your favor. If anything, yur essay just makes it clear that it is impossible to glean the data type from the LINQ expression itself. Yet, any code using its result will contain implicit assumptions about that data. Therefore, in order to maintain type safety, the expected type of the return value must he stated. That type must also be independent…
You also included information about “constraints” like is it a positive or negative number and string length. That wouldn’t be encoded in the type. Why would I go look up the types either way? I’m using a strongly typed language, the IDE would tell me that anyway. While I am writing code, I see a red dot showing me immediately if I’m using the type incorrectly. Any assumptions that were incorrect, I would get immedia…
Not necessarily. Is Age unsigned or not? This constrains the possible range of values. In other contexts, there is a lot more information inferred by the integer type used.
Re: The memory safety problem isn't bad coders
#203Earlier quoted context omitted.
C/C++, and in many cases Lisp, seem to be the most entrenched communities when it comes to the "culture of seat-of-the-pants flying and bravado". For contrast, JavaScript has as much flexibility and nearly as many foot-guns as those languages, but its community has been much more receptive to safety rails and static analysis. (Hopefully this doesn't start a flame-war; that isn't my intention)
It's hard to stereotype the "C/C++ community." The C++ community popularized RAII for safer management of mutex locks, reference counts, and other resources; smart pointers for null checking; and other ergonomic improvements motivated by the knowledge that getting those things right in plain C required an unrealistic and/or wasteful level of vigilance. When I encountered Rust I immediately recognized the same desire…
I put a form of RAII into TXR Lisp, unified with GC finalization:
Re: The memory safety problem isn't bad coders
#204Earlier quoted context omitted.
The devil is in the details usually here. Bloat can absolutely affect your bottomline in many ways.
One man's 'bloat' is another man's features. Consider both Microsoft Word and Notepad. Which is more bloated? Which is more light weight? Which has more powerful features, some that you don't even notice right away, like spellcheck, grammar check, etc? Which has fewer features? People usually complaining about 'bloat' in a high level language or its runtime are really complaining about features that they either don't…
> Which is more bloated?
Microsoft Word
> Which is more light weight?
Notepad
> Which has more powerful features, some that you don't even notice right away, like spellcheck, grammar check, etc?
Microsoft Word
> Which has fewer features?
Notepad
Users who are complaining about bloat are usually complaining about either application performance, ease of use and basic task completion complexity and/or general cluttering of the UI. Longer than expected load times can lead users to believe an application is bloated as well. It's true that all these things might be caused by something other than bloat, but these are typical repercussions of adding general cruft and also these tend to be design decisions and implementation details separate from the feature that the bloat was added for.
Developers complaining about bloat (not the ones on HN giving a critique of a github repo after browsing it for a couple minutes, but the ones who are actually knee deep in source code trying to meet a deadline for a specific feature or bug fix and to whom the bloat is literally a gravity well affecting their development pace and agility) are usually referring to previous development cycles that they believe unnecessarily introduced complex libraries for simple tasks or outsourced application logic to dependencies that are not under control of the in-house development that have unnecessarily made the code base unwieldy and created more rotten code overall from a maintainability/extensibility vantage.
In both these cases, a good early signal of detrimental bloat would be someone taking out a PR that introduces 500MB to the application. Justifying it as I'm maximizing for DOLLARS makes me think of someone who just won the lottery deciding that as a result of their net worth increasing a thousand fold, they're going to start willingly paying 1000x the price for things and also buy 1000x the amount of things. Should anyone try to convince them of how this logic is going to work out (perhaps someone stuck behind them in line at the store as they ring out the tens of thousands of grocery items, each of which provides a special value most people don't use, understand, or even realize is edible), the lottery winner calmly explains to the well-meaning individual (who happens to have just as high a net worth as the lottery winner it turns out but has achieved this over time and will have a higher net worth going forward from here) that perhaps this well-meaning simpleton just don't realize how much money has just been won.
And sure, an application like Microsoft Word that has been actively developed for more than 35 years will likely have bloat, especially when maintained to preserve backward compatibility. There's a statistical minimum in this regard. Whether or not the bloat is as bad as it needs to be is another thing.
If the development team behind Word has simply been adding 500MB here and 500MB there and defending it with "we're not going to write the new features in assembly" or "this helps me as a programmer be more productive" or "this source modification is so large because of all the features you don't know about" or "what?! we're not in North Korea" or all of the above, they are 100% creating more work for themselves and this extra work definitely comes with a price tag. In fact, without really have much insight into the general culture or incentives over there, it's a reasonable bet they've taken steps to prevent developers from introducing tech debt and bloat with this sort of defense.
Either way, it's weird to point to Microsoft Word's accumulated debt and overall decreasing performance specs as a result of multiple decades of evolving development as a reason to dismiss bloat as a non-issue. If I were a career non-bloat advocate, traveling from university to university on my canola oil powered moped I'd be pointing to Word as a reason to take bloat seriously and a reminder that the feature your adding now will likely be on the opposing force of a future person's battle with bloat and you should fight it with all the flower power you can muster or risk them tracking you down with a vendetta after they realize it was your commit making their job shit right now.
Re: The memory safety problem isn't bad coders
#205Earlier quoted context omitted.
Yes. I am quite familiar with them.
Then tell me how you can model in C# a type where a property can’t be negative or a certain length.
class Foo {
public uint Bar { get; set; }
private char[] _baz;
public char[] Baz { get { return _baz;} }
public Foo() { _baz = new char[5]; }
}
Re: The memory safety problem isn't bad coders
#206Earlier quoted context omitted.
Although I mostly agree with you, it's worth noting that static typing only goes so far. When I worked in a large-scale Java codebase, it always seemed like half the code only existed in order to "work around" the type system. (Don't even get me started on Spring, which might as well be a whole additional language on TOP of the actual application code.) I'm perfectly willing to grant that might just be a Java thing,…
I am beginning to suspect that Java is almost singlehandedly responsible for the prevailing opinion that static typing doesn't do anything useful and mostly gets in the way. Which is sad, because I'm also hard-pressed to think of a worse poster child for static typing than Java. It's like a stereotypical bureaucrat, asking you to fill out a mountain of paperwork before it can proceed to do a whole lot of nothing usef…
> of a worse poster child for static typing than Java.
C, golang
Re: The memory safety problem isn't bad coders
#207Earlier quoted context omitted.
Although I mostly agree with you, it's worth noting that static typing only goes so far. When I worked in a large-scale Java codebase, it always seemed like half the code only existed in order to "work around" the type system. (Don't even get me started on Spring, which might as well be a whole additional language on TOP of the actual application code.) I'm perfectly willing to grant that might just be a Java thing,…
Java is really the worst example for a typing system. It's basically the way you shouldn't do it. There are much better type safe languages like Haskell, Erlang, Rust, etc., even just Kotlin because it drops so much of the boilerplate and excessive unnecessary verbosity, while retaining the static typing and its benefits.
> the worst example for a typing system
Not nearly as C or golang.
Re: The memory safety problem isn't bad coders
#208I think this argument grants too much to the C-believer crowd by presenting a case where even an infallible programmer would have ended up making the mistake. The author is arguing with people divorced from reality on their terms.
Next, you'll get counterarguments from the peanut gallery proposing that the merging the changes was just the fault of bad process, and as long as people don't make the mistake of applying a bad process, evrything would be fine.
Re: The memory safety problem isn't bad coders
#209Earlier quoted context omitted.
Then tell me how you can model in C# a type where a property can’t be negative or a certain length.
class Foo { public uint Bar { get; set; } private char[] _baz; public char[] Baz { get { return _baz;} } public Foo() { _baz = new char[5]; } } This is cheating a bit on the array part. But the length of that char array is set in stone and cannot be changed from the outside. However, the Bar property uses a standard C# datatype.
And your class wouldn’t work as part of the LINQ example. EF for example wouldn’t know how to translate it.
Re: The memory safety problem isn't bad coders
#210I remember when I first added ESLint to our large JavaScript codebase, and then again when I added Flow. I'm a perfectionist when I code, but it was shocking to see some of the things I'd written. Mistakes that I thought were so unlike me, but had been sitting there for months anyway, waiting to blow up. The human brain wasn't designed to handle the complexity of large codebases. There are just too many compounding i…
I did a review of the entire backend of a pretty big project just now. Very very worth it. I'm going to plan for that every 6 months or so from now.