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

211–220 of 225 posts

Re: The memory safety problem isn't bad coders

#211

Post by jplayer01 »

apta wrote: post #207
jplayer01 wrote: post #131

Earlier quoted context omitted.

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.

Well, we were talking about static/strong typing. Java is a bad example for static typing because of all its issues, which shouldn't be taken as proof that static typing is bad, especially when there are plenty of great languages that do use it well.

Re: The memory safety problem isn't bad coders

#212

Post by adrianhel »

ecnahc515 wrote: post #165
core-questions wrote: post #158

Earlier quoted context omitted.

Respectfully, do I care if my program works the first time, or by the deadline? I don't care if the first ten times I run it, it just bombs out with interpreter errors. Doesn't seem to result in my having slower output than anyone else I'm working with.

If you truly knew what you were doing when you started, then everything would work the first time you tried it. Since that's not the case, you're clearly making mistakes, so why wait until running it to find mistakes when you could find them before even running the program? Think of it this way: you only ran it 10 times, are you sure you found all the bugs? What about 11 times? Are you sure you found all the problems…

I agree with the sentiment, but types don't guarantee correctness. I would put such a developer on "TDD-duty", be thorough about code reviews and do some pair programming.

Re: The memory safety problem isn't bad coders

#213

Post by [deleted] »

ecnahc515 wrote: post #165
core-questions wrote: post #158

Earlier quoted context omitted.

Respectfully, do I care if my program works the first time, or by the deadline? I don't care if the first ten times I run it, it just bombs out with interpreter errors. Doesn't seem to result in my having slower output than anyone else I'm working with.

If you truly knew what you were doing when you started, then everything would work the first time you tried it. Since that's not the case, you're clearly making mistakes, so why wait until running it to find mistakes when you could find them before even running the program? Think of it this way: you only ran it 10 times, are you sure you found all the bugs? What about 11 times? Are you sure you found all the problems…

[deleted]

Re: The memory safety problem isn't bad coders

#214

Post by coldtea »

goalieca wrote: post #195
Sohcahtoa82 wrote: post #191

Earlier quoted context omitted.

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

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

Nothing in Java prevents a Java network lib from doing it in one line. In fact many third party network libs do just that.

(And Python had more or less a similar unwieldy network lib, which is why they now say "Requests is suggested" on their own standard lib documentation: https://docs.python.org/2.7/library/urllib.html ).

So again it's not the language (syntax + semantics), it's what's considered "idiomatic" and what's prevalent.

Re: The memory safety problem isn't bad coders

#215

Post by maxxxxx »

gmueckl wrote: post #205
maxxxxx wrote: post #201

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

I honestly thing that you haven't done any real work with LINQ or you are imagining problems that don't exist. The char array is not usable as string or we have to go back to 0 terminated strings like C.

Re: The memory safety problem isn't bad coders

#216

Post by pjmlp »

coldtea wrote: post #214
goalieca wrote: post #195

Earlier quoted context omitted.

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.

> 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. Nothing in Java prevents a Java network lib from doing it in one line. In fact many third party network libs do just that. (And Python had more or less a similar unwieldy network lib, which is why they now say "Requests is suggested" on their own standard lib documentation:…

Still it is possible to write J2EE on any language (wrote J2EE on purpose).

I have it seen done in Clipper, C, C++ and I bet even Go will one day have its Go2EE, it just needs a bit more enterprise love.

Re: The memory safety problem isn't bad coders

#217

Post by jcelerier »

jschwartzi wrote: post #171
jcelerier wrote: post #139

Earlier quoted context omitted.

why we can't have nice things, in one comment. auto is not a code smell on the contrary, it is used when your type system is easy enough to reason about that you don't need to write the actual type.

If it's so easy to reason about, why can't you just state the type of the variable? Doing so helps me understand what's popping out from the rvalue in assignment so that I can follow what your code is doing. If you're worried about spending time changing type names during a refactor, look at it instead as an opportunity to evaluate the correctness of the code in the context of your replacement type. Use of the auto k…

> If it's so easy to reason about, why can't you just state the type of the variable?

because : - easy to reason about and easy to type are two differents things - naming everything increases mental load

> Use of the auto keyword avoids doing that and as a result enables you to create new and exciting bugs in your code.

to the contrary, porting a lot of my code to use almost-always-auto did actually remove bugs in the form of silent type conversions happening - e.g. std::pair instead of std::pair (yay memory allocations), bad fp conversions...

Re: The memory safety problem isn't bad coders

#218

Post by weliketocode »

WilliamEdward wrote: post #26
weliketocode wrote: post #21

No need to say 'bad', but there is definitely a shortage of experienced coders. - Competition/Compensation for experienced coders has risen sharply - There are many more inexperienced SDE's coming from colleges/bootcamps/etc - Senior titles are often given to individuals who are still very early in their careers Now, these factors might be necessary/good in the short term as software continues to eat the world. But,…

Somewhat hilariously, the problem isn't lack of talent in programmers, but lack of talent in companies. Someone on this thread claims everyone is being stolen by top tech companies, that means it's you who needs to make your business more attractive, not that there's a shortage of coders. Experienced programmers know they don't have to settle for less.

The two issues aren't mutually exclusive.

The supply/demand balance for experienced engineers is such that many companies are (explicitly or not) choosing to go with less experienced engineers.

Re: The memory safety problem isn't bad coders

#219

Post by alexeiz »

> ... use a re-entrant mutex when it was acquired from the pool ... normal mutex we would be fine, we unlock it on a thread other than the one we locked it from ... re-entrant mutex remembers which thread it was locked from, we need to keep the resource on the same thread

Sounds like a "bad coders" problem to me! This design is so screwed up that no tool or smart compiler can save you from problems here.

Re: The memory safety problem isn't bad coders

#220

Post by gmueckl »

maxxxxx wrote: post #215
gmueckl wrote: post #205

Earlier quoted context omitted.

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.

I honestly thing that you haven't done any real work with LINQ or you are imagining problems that don't exist. The char array is not usable as string or we have to go back to 0 terminated strings like C.

I am not imagining problems that don't exist in the application domains I work on.

If your environment is so relaxed that aspects like signedness of an integer don't matter, so be it. But then you are also far removed from a domain where software correctness is non-negotiable.

Post reply on HN