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

181–190 of 225 posts

Re: The memory safety problem isn't bad coders

#181

Post by gmueckl »

scarface74 wrote: post #150
gmueckl wrote: post #124

Earlier quoted context omitted.

It would make me ask why you need a one time use struct at all and probably remove it.

More complicated example: var seniorMales = from c in customer where c.age > 65 && c.Sex == “male” select new {c.FirstName, c.Lastname, c.Age} foreach(var customer in seniorMales) { Console.WriteLine(customer.Firstname + “ “ + customer.Lastname); } Why would I create a class/struct for that use case? Side note: this is why I find ORMs in most languages besides C# useless. Here, “customers” can represent an in memory…

This us one of the cases where I would want you to write an explicit type for seniorMales. Reasoning about the LINQ expression is just complex enough that by not constraining its type to your expectations you can easily obscure a mistake in your thinking that would otherwise show up in the data types.

Re: The memory safety problem isn't bad coders

#182

Post by fenwick67 »

geofft wrote: post #115
FilterSweep wrote: post #19

> “The problem isn’t the use of a memory unsafe language, but that the programmers who wrote this code are bad.” This really goes to show how anti-worker the media is even among high-skill jobs. In my mid 20s I now mentor a bit in coding. I’ve worked with young devs that inherently know many of the obvious security pitfalls that have caused massive security breaches a la Equifax. Are devs at the front of these breach…

> This really goes to show how anti-worker the media is even among high-skill jobs. The quote was regarding "social media" as in mostly the workers themselves, not "the media" as in the independent journalists reporting on the workers. I think you're agreeing with the article in the end, and I also agree with it, but I'd like to note two things: - Grueling interviews are not necessarily correlated with skill. In part…

> "Lack of tech talent" generally refers to the number of people being insufficient for the job, not the quality of the existing people

The "we can't find enough people to do this job" complaint conveniently leaves out "...at the wage we offer".

The principles of supply and demand apply here - if a company pays well enough they will get enough quality candidates for almost any job. It's insane to believe that a company literally cannot find a good C developer.

Re: The memory safety problem isn't bad coders

#183

Post by scarface74 »

gmueckl wrote: post #181
scarface74 wrote: post #150

Earlier quoted context omitted.

More complicated example: var seniorMales = from c in customer where c.age > 65 && c.Sex == “male” select new {c.FirstName, c.Lastname, c.Age} foreach(var customer in seniorMales) { Console.WriteLine(customer.Firstname + “ “ + customer.Lastname); } Why would I create a class/struct for that use case? Side note: this is why I find ORMs in most languages besides C# useless. Here, “customers” can represent an in memory…

This us one of the cases where I would want you to write an explicit type for seniorMales. Reasoning about the LINQ expression is just complex enough that by not constraining its type to your expectations you can easily obscure a mistake in your thinking that would otherwise show up in the data types.

How so? You couldn't pass the anonymous type to another method or return it so the locality would be strong and the anonymous type is just a strongly typed POCO. Creating a class doesn't add anything semantically.

How do you feel about deconstructuring that is available in most languages?

Re: The memory safety problem isn't bad coders

#184

Post by Izkata »

m4lvin wrote: post #152
_hardwaregeek wrote: post #103

Earlier quoted context omitted.

It's amazing how little we talk about tooling, both in work and in education. I had an internship where I kept on trying to work on better tooling for the developers, only to be told that I should be working on the actual product because that's more important. Except, if I make the other developer's lives even 5-10 percent easier, then that will have a much longer effect than whatever work I can get done in 3 months.…

Hey stranger, thanks for telling me that the lecture I gave last week was the right thing to do, even though I will be told that "those things do not belong to 'Data Structures and Algorithms'" :-)

> and Algorithms

If the complaints are annoying enough, I propose cheating - for example, working makefiles into the graph algorithms part of the course.

Re: The memory safety problem isn't bad coders

#185

Post by yellowapple »

dx87 wrote: post #122
adrianmonk wrote: post #60

Earlier quoted context omitted.

Well, although it could be anti-worker, it could also be one-upmanship among programmers with fragile egos: I'm not a bad programmer; they are. And I think ego is a barrier to accepting tools that prevent errors. To accept the tool is to admit to yourself and others that you are going to make the error (sometimes) without it.

I've seen the ego issue pop up a lot in some communities. The biggest example I can think of is the OpenBSD mailing list. Any time I'd see an outsider bring up Rust or other safer languages, the overwhelming sentiment is that languages with built-in safety features are for people too stupid to write C, and that safety features restrict good coders ability to write performant code.

While that sentiment is certainly alive and well, that's not the actual reason why the OpenBSD crowd is not gung-ho about Rust: https://marc.info/?l=openbsd-misc&m=151233345723889&w=2

The takeaway of that thread is that OpenBSD's "shut up and code" mantra is applicable here. If you want a Rusty OpenBSD, then start replacing pieces of OpenBSD's C codebase with Rust (you might have to fork OpenBSD for awhile in the process).

You'll probably run into quite a few issues. Most severely, OpenBSD must be self-hosting (i.e. able to compile itself) on every hardware platform on which it runs; if a modification causes that to be no longer true, then either that hardware target must be dropped or the modification must be rejected. Considering that Rust doesn't support compiling for all the hardware platforms OpenBSD supports (let alone compiling a rustc that actually does run natively on each platform), Rust is immediately a nonstarter.

Re: The memory safety problem isn't bad coders

#186

Post by maxxxxx »

gmueckl wrote: post #181
scarface74 wrote: post #150

Earlier quoted context omitted.

More complicated example: var seniorMales = from c in customer where c.age > 65 && c.Sex == “male” select new {c.FirstName, c.Lastname, c.Age} foreach(var customer in seniorMales) { Console.WriteLine(customer.Firstname + “ “ + customer.Lastname); } Why would I create a class/struct for that use case? Side note: this is why I find ORMs in most languages besides C# useless. Here, “customers” can represent an in memory…

This us one of the cases where I would want you to write an explicit type for seniorMales. Reasoning about the LINQ expression is just complex enough that by not constraining its type to your expectations you can easily obscure a mistake in your thinking that would otherwise show up in the data types.

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.

Re: The memory safety problem isn't bad coders

#187

Post by godelski »

phaedrus wrote: post #64
_bxg1 wrote: post #6

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

The comparison with aviation instruments is apt: I remember seeing a TV special that talked about how in the early days of aviation (circa WWI) the pilots' culture of seat-of-the-pants flying and bravado was resistant to suggestions that human senses are just not equipped to differentiate between certain inertial reference frames, of which one leads to getting into a death-spiral. It was not until an early aviation s…

> (something like a spinning chair and blindfold - I forget the details)

The test they do is blindfold you and spin you in a chair. But they switch directions and you have to point your thumbs in the direction your are spinning. It is possible to determine which way you are, but it is freaking difficult and really you're probably cheating by knowing the initial spin direction and keeping track of sharp decelerations (change in direction).

Basically it is simulating how you might be spinning in clouds and not be aware of it. Unlike the chair simulation these spins are more gradual/subtle and you're not paying extremely close attention (your attention SHOULD be elsewhere, i.e. flying the plane).

Re: The memory safety problem isn't bad coders

#188

Post by Zarel »

recursive wrote: post #177
_bxg1 wrote: post #161

Earlier quoted context omitted.

> it was a meme that no one's C program ever compiled the first time they tried Ah but see, the compiler is a guard-rail. Technically, it's a static-analyzer. I don't think anyone is against making existing guard rails more helpful via editor integration; the conflict comes with adding new guard rails. Take the following example: let foo = { bar0: 12, bar1: 14, bar2: 16 } // example 1 console.log(foo.bar0); console.l…

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.

Re: The memory safety problem isn't bad coders

#189

Post by gmueckl »

maxxxxx wrote: post #186
gmueckl wrote: post #181

Earlier quoted context omitted.

This us one of the cases where I would want you to write an explicit type for seniorMales. Reasoning about the LINQ expression is just complex enough that by not constraining its type to your expectations you can easily obscure a mistake in your thinking that would otherwise show up in the data types.

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!

Re: The memory safety problem isn't bad coders

#190

Post by scarface74 »

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!

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 me an expression to use in the where clause you would send me an

>

You have no idea what that expression is going to be translated to until runtime.

Either way, you are just working with non concrete Expression Trees that could be transformed into IL, SQL, a MongoQuery etc. All of the constrainsts would be handled by your data store.

You don’t even know before hand whether you are iterating over an in memory list, or streaming from an external data source.

I could switch out Sql Server for Mongo and you as the client wouldn’t be any the wiser.

And we haven’t even gotten to the complication if the result set was the result of a LINQ grouping operation.

Post reply on HN