Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The memory safety problem isn't bad coders

medium.com

Post reply on HN
Print view View original

191–200 of 225 posts

Re: The memory safety problem isn't bad coders

#191

Post by Sohcahtoa82 »

coldtea wrote: post #147
mhink wrote: post #76

Earlier 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,…

> 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. I don't think that's fair. I'd say that "half the code only existed in order to" use patterns and OO hierarchies for the sake of it. Java can be programmed as lightly as Python or as a full-o…

> Java can be programmed as lightly as Python or as a full-on J2EE monstrosity. The difference is cultural ("idiomatic") not brought about by types.

I wish I had the money to burn to buy a billboard in Silicon Valley to broadcast this.

I find that the extreme majority of the hate Java gets isn't really about Java itself, but the extreme adherence to the worst paradigms and idioms I've ever seen in the programming world.

Stop writing so many classes. I'm sure everyone here has seen FizzBuzz Enterprise Edition [0]. Sure, it's a parody, but a lot of truth is said in jest. There's too much Java code that looks like FizzBuzz EE, and there's no damn reason for it.

> I'd say that "half the code only existed in order to" use patterns and OO hierarchies for the sake of it.

I really wish I could understand why so many Java programmers feel like you can't just write a class. Nope, you have to make an Interface, with an abstract class that implements it, followed by your Implementation class that extends the abstract. But directly calling that constructor is verboten! You need to create a Factory class (With associated abstract class and interface, of course!) that returns instances!

[0] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Re: The memory safety problem isn't bad coders

#192

Post by maxxxxx »

gmueckl wrote: post #189
maxxxxx wrote: post #186

Earlier quoted context omitted.

I think the anonymous type is much better. It's type safe, you can easily see how it's defined but you don't pollute the rest of your code with one-off classes that make only sense within the function. If I had to review the code and saw an explicit type I would recommend an anonymous type.

It is not better. I don't know what type FirstName or Age is. Can Age be negative? Is FirstName an array of char or a string? Can FirstName be more than 10 characters long? It could be a double value for all I can tell from that line of code!

How do you want to model this in C#? Write a full class with all kinds of checking for a single LINQ operation? That will be a very bloated codebase.

Re: The memory safety problem isn't bad coders

#193

Post by Sohcahtoa82 »

msla wrote: post #110
noir_lord wrote: post #30

Earlier quoted context omitted.

Which isn't bad if the type inference is good . Nearly all the type errors I see are things like var foo = "Hello World"; bar = foo + 10; That should scream it's head off.

The kind of errors I'm interested in preventing are more like this: var foo = 5; var bar = 100; baz = foo + bar; Why is that bad? Well... what do 5 and 100 mean in that program? Did you just add age in years to pixels from edge? How do you know? Appending an integer to a string is comparatively sensible next to adding age in years to pixels from edge.

> Why is that bad? Well... what do 5 and 100 mean in that program? Did you just add age in years to pixels from edge? How do you know?

You know because you should be using sensible variable names that make it obvious.

Re: The memory safety problem isn't bad coders

#194

Post by gmueckl »

scarface74 wrote: post #190
gmueckl wrote: post #189

Earlier quoted context omitted.

It is not better. I don't know what type FirstName or Age is. Can Age be negative? Is FirstName an array of char or a string? Can FirstName be more than 10 characters long? It could be a double value for all I can tell from that line of code!

The select statement is projecting the Customer type from either an external data source or an in memory source. That information wouldn’t be encoded into the POCO whether or not it was anonymous. Changing select new {...} to Select new SeniorPeople {...} wouldn’t give you any more information. At most if I was writing that as part of a repository class I would be sending you back an IEnumerable . If you were to send…

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 from whatever LINQ does internally to produce that return value. Otherwise, the LINQ providers wouldn't be as exchangeable as you claim.

Re: The memory safety problem isn't bad coders

#195

Post by goalieca »

Sohcahtoa82 wrote: post #191
coldtea wrote: post #147

Earlier 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. I don't think that's fair. I'd say that "half the code only existed in order to" use patterns and OO hierarchies for the sake of it. Java can be programmed as lightly as Python or as a full-o…

> Java can be programmed as lightly as Python or as a full-on J2EE monstrosity. The difference is cultural ("idiomatic") not brought about by types. I wish I had the money to burn to buy a billboard in Silicon Valley to broadcast this. I find that the extreme majority of the hate Java gets isn't really about Java itself, but the extreme adherence to the worst paradigms and idioms I've ever seen in the programming wor…

Java itself makes things a pain. Compare establishing a tls connection with a client certificate in python and in java. Guess which language has a secure one line way to do it.

Re: The memory safety problem isn't bad coders

#196

Post by scarface74 »

gmueckl wrote: post #194
scarface74 wrote: post #190

Earlier quoted context omitted.

The select statement is projecting the Customer type from either an external data source or an in memory source. That information wouldn’t be encoded into the POCO whether or not it was anonymous. Changing select new {...} to Select new SeniorPeople {...} wouldn’t give you any more information. At most if I was writing that as part of a repository class I would be sending you back an IEnumerable . If you were to send…

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 immediate feedback.

Re: The memory safety problem isn't bad coders

#197

Post by maxxxxx »

gmueckl wrote: post #194
scarface74 wrote: post #190

Earlier quoted context omitted.

The select statement is projecting the Customer type from either an external data source or an in memory source. That information wouldn’t be encoded into the POCO whether or not it was anonymous. Changing select new {...} to Select new SeniorPeople {...} wouldn’t give you any more information. At most if I was writing that as part of a repository class I would be sending you back an IEnumerable . If you were to send…

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…

Do you actually work with C#, LINQ and generics?

Re: The memory safety problem isn't bad coders

#198

Post by recursive »

Zarel wrote: post #188
recursive wrote: post #177

Earlier quoted context omitted.

In case anyone missed it, example 2 is allowed in typescript.

It's not, not without an assertion: https://i.imgur.com/DJjzPDF.png Well, it's allowed in that it will still compile the code (because TypeScript is a superset of JavaScript), but it'll still yell at you.

Yes, without an assertion. Just change your compiler options.

https://www.typescriptlang.org/play/#src=%20%20let%20foo%20%...

Re: The memory safety problem isn't bad coders

#199

Post by applesvsoranges »

scottlamb wrote: post #157
applesvsoranges wrote: post #106

>> With a normal mutex we would be fine, since you only one lock can exist and it doesn’t matter if we unlock it on a thread other than the one we locked it from. Sorry if this is a dumb question, but I'm confused. Aren't mutexes always supposed to have ownership which implies that only the locking thread can unlock them?

> Sorry if this is a dumb question, but I'm confused. Aren't mutexes always supposed to have ownership which implies that only the locking thread can unlock them? Mutexes are supposed to ensure that exactly one thread can accesses resource ("have the lock") at a time. There's no fundamental reason you can't pass the lock from one thread to another, as long as they don't both have it at once. But it may not be support…

Thanks, this adds a whole new perspective for me wrt mutexes. I wasn't aware of all these other usage patterns for them at all.

Most of my work is in the OS, drivers and low level space, and I'm a beginner there as well, hence the short critical sections under a single owner are the only places I had encountered them before.

Re: The memory safety problem isn't bad coders

#200

Post by gmueckl »

maxxxxx wrote: post #197
gmueckl wrote: post #194

Earlier 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…

Do you actually work with C#, LINQ and generics?

Yes. I am quite familiar with them.
Post reply on HN