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

221–225 of 225 posts

Re: The memory safety problem isn't bad coders

#221

Post by Sohcahtoa82 »

pjmlp wrote: post #216
coldtea wrote: post #214

Earlier quoted context omitted.

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

> Still it is possible to write J2EE on any language

Right. The difference is that for some reason, writing Java in the J2EE style seems to be the default, and rather than stopping the practice, people choose to hate the language instead, as if they think the J2EE style is required by the language.

Re: The memory safety problem isn't bad coders

#222

Post by pjmlp »

Sohcahtoa82 wrote: post #221
pjmlp wrote: post #216

Earlier quoted context omitted.

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.

> Still it is possible to write J2EE on any language Right. The difference is that for some reason, writing Java in the J2EE style seems to be the default, and rather than stopping the practice, people choose to hate the language instead, as if they think the J2EE style is required by the language.

Yep, I love how Java bashers get to deploy micro-services at scale, using Docker containers, managed via Kubernetes, with DSLs written via Terraform APIs.

Re: The memory safety problem isn't bad coders

#223

Post by jakevn »

msla wrote: post #178
jakevn wrote: post #138

Earlier quoted context omitted.

Then you should not use a general numeric when you really should be using Pixel and Age types.

My broader point is that low-level representation doesn't matter nearly as much as semantics, and yet by default type systems are obsessed with low-level representations. Appending a number to a string is a perfectly sensible thing to do when you're displaying information to a user, yet adding two numbers or concatenating two strings could be completely senseless and proof that the development process has gone off th…

Your dream type system is out there, yet not manifest in any popular or somewhat-popular language.

I've yet to see a strictly/strongly typed language that makes this easy to do. Through some combination of plugins, esoteric languages, macros, or boilerplate, sure.

We're decades behind what is possible due to the practical.

Re: The memory safety problem isn't bad coders

#224

Post by scarface74 »

gmueckl wrote: post #220
maxxxxx wrote: post #215

Earlier quoted context omitted.

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.

It’s not aspects “like signednes” that’s the only constraint that you could embed in your defined POCO and still use as a select projection that would survive a LINQ expression that was turned into an expression tree. Your data store would enforce the other constraints. Your C style character array as a string wouldn’t work with either LINQ nor any of the standard library.

Are you really trying to go back to the bad old days with Microsoft C/MFC/WIN32/COM where you had over a dozen ways to represent a string that you had to convert to and from depending on which API you were using?

Re: The memory safety problem isn't bad coders

#225

Post by apta »

jplayer01 wrote: post #211
apta wrote: post #207

Earlier quoted context omitted.

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

> Java is a bad example for static typing because of all its issues,

So are C and golang, even more so arguably.

Post reply on HN