Hacker Newsnew | past | comments | ask | show | jobs | submit | ux266478's commentslogin

> There's no hard evidence that static typing improves reliability.

I'm curious how you came to that conclusion?

https://pleiad.cl/papers/2012/kleinschmagerAl-icpc2012.pdf

https://www.deepdyve.com/lp/springer-journals/an-empirical-s...


The benefits of static typing with regard to reliability are unclear, at best:

https://danluu.com/empirical-pl/


I don't consider a human subjects study to be "hard evidence".

So, we can safely disregard these papers. They got exactly the result that they sought out to get, and the papers were published because they confirmed the preexisting groupthink.


Interesting, so you consider the entire scientific field of medicine to work without hard evidence?

You mean psychology? There’s no hard evidence there. The papers you’re citing are using human subjects in that sort of way. It’s pseudoscience at best

Medicine that involves testing human subject response to treatments is very different from the papers you’re citing and does involve falsifiable theses (usually, definitely not always).


I didn't link any studies. I'm not the person you originally replied to. I was trying to engage in your point that studies involving human subjects cannot contain hard evidence. And no I wasn't referring to psychology in my comment.

Then you’re changing context for no reason.

My point about human subjects is in the context of the linked studies.

I’m not super interested in further debating human subjects in science generally


If you're going to start citing research, you should look at the Cooley finding on verilog vs VHDL.

That's certainly an interesting data point, but it was a 90 minute programming contest, not peer-reviewed research.

The second paper shown above is firewalled.

The first paper shown above was presented at ICPC, which has a history of bias in reviewing, and typically only assigns one or two reviewers in any case.

Which makes it not surprising that the paper itself doesn't really prove anything, except that the authors themselves are good at creating dissimilar situations.

Subjects had to modify existing systems, which were provided by the experimenters.

The experimenters deliberately removed any semblance of anything that might hint at types (comments, variable names, etc.) and did who the fuck knows what else to the dynamically typed code to make it difficult to work with.

They also provided their own IDE and full environment which the participants had to use.

Now, of course, we've all seen the graphs which show that for simple problems, dynamic is better, and there's a crossover point, and, of course Cooley's experiment is on the far left of that graph, so it certainly doesn't prove that strict static typing isn't better for large programs, but it's at least honest in its approach and results, using self-selected working practitioners (and there was never any shortage of working practioners swearing by how much better VHDL is).

https://danluu.com/verilog-vs-vhdl/


I was searching for the Stefik article to argue here, thank you.

I too wish we were weaving exotic matter metamaterials out of the aether, but until then hydrocarbons are a miracle from the heavens for their uses. A modern cedar tree.

I feel they’re more a miracle from the depths of hell. Sunlight is probably the miracle from heaven.

Petroleum is a stable sunlight storage medium.

The sun is but a poor, corrupted pun on starlight. The reflecting pool of crude shimmers with thin-film interference like nebulae on the celestial expanse.

You could argue that the sun was pretty useful, quite the “essential companion” in the Stone Age as well.

In fact, it is hard to imagine there would have been enough dead trees to make oil if it were not for the sun.

You could argue (pretty soundly) that oil is just a way of consuming the energy in trees which got that energy from the sun. So oil is just a way of extracting ancient solar energy.


If you go that far, all energy sources are [ancient] solar energy though. Geothermal? Yep. Wind? Yep. Fission? Yeppers.

Oil’s potential, left deep in the crust, remains latent. Every mote of sunlight, furiously brought to life by the maelstrom, seeks inexorably for immediate purpose.

Biodiesel is a thing, there are fuel stations that sell it to the public in Europe.

https://www.neste.com/products-and-innovation/neste-my-renew...


> too wish we were weaving exotic matter metamaterials out of the aether,

We’ve known how to make hydrocarbons out of air for decades, it’s just cheaper to dig up the remains of plants that discovered the process billions of years ago.


> Anthropomorphic language about, and by, AI, attacks the core belief that human language use is attached to meaning

This is unsound. At best it's incompatible with an unfounded teleological stance, one that has never been universal.


That's not how it works. The demand for engineering hours is an order of magnitude higher than the supply for any given game, you have to pick and choose your battles because there's always much, much more to do. It's not bizarre that nobody verified texture storage was being done in an optimal way at launch, without sacrificing load times at the altar or visual fidelity, particularly given the state the rest of the game was in. Who the hell has time to do that when there are crashes abound and the network stack has to be rewritten at a moments notice?

Gamedev is very different from other domains, being in the 90th percentile for complexity and codebase size, and the 99th percentile for structural instability. It's a foregone conclusion that you will rewrite huge chunks of your massive codebase many, many times within a single year to accomidate changing design choices, or if you're lucky, to improve an abstraction. Not every team gets so lucky on every project. Launch deadlines are hit when there's a huge backlog of additional stuff to do, sitting atop a mountain of cut features.


> It's not bizarre that nobody verified texture storage was being done in an optimal way at launch

The inverse, however, is bizarre. That they spent potentially quite a bit of engineering effort implementing the (extremely non-optimal) system that duplicates all the assets half a dozen time to potentially save precious seconds on spinning rust - all without validating it was worth implementing in the first place.


Was Helldivers II built from the ground up? Or grown from the v1 codebase?

The first was on PS3 and PS4 where they had to deal with spinning disks and that system would absolutely be necessary.

Also if the game ever targeted the PS4 during development, even though it wasn’t released there, again that system would be NEEDED.


It's a completely different game, engine, etc.

Yes.

They talk about it being an optimization. They also talk about the bottleneck being level generation, which happens at the same time as loading from disk.


Gamedev engineering hours are also in endless oversupply thanks to myDreamCream brain.

[flagged]


> > you will rewrite huge chunks of your massive codebase

> You're not rewriting Unreal

Do you consider the Unreal engine code to be part of "your codebase"?


It's a dependency .. do you not consider dependencies as part of your codebase?

I think they meant the gameplay side of things instead of the engine

Unity rewrote and discontinued lots of major systems several times in a row in the last 10 years.

I’d be careful before telling people to “get a grip”.


Several times in 10 years, sure. Many times every year, certainly not. I'm getting downvoted, but I stand by my statement.

Strawman. If GP had said “full rewrite” sure. They said “huge chunks of your massive codebase” which is definitely true for unity.

Guile is an embedded scripting and configuration language. Its competition is Lua. Which is unfortunate for Guile, because it's even less attractive there.

What are the pros and cons of Guile wrt Lua?

The only pro I can think of is you get a standard scheme set of batteries, which isn't even really a pro in this space. The biggest con is implementation size and complexity. IIRC the JITter alone is twice the size of LuaJIT's entire codebase, and not for being vastly better.

License problems too, if you're not making copyleft software. Guile is GPL, both Luas are MIT.


The language is different. The changes to environments in particular are a non-starter. Sandboxing is incredibly clunky in 5.2+, and we lost a lot of metaprogramming power and dynamic behavior.

I totally get why they did, having had to support Mac for an in-house engine. Apple is by far the most painful platform to support out of the big 3 if you're not using turnkey tools, and they don't make up for it with sales outside of iOS. The extra labor is hard to justify already, and then we get to technical deficiencies like MoltenVK, plus social deficiencies like terrible support. It's just a really hard sell all around.

If someone likes you, trade secrets flow like wine. That's basic humanity. It's not unique to China, though the relationships involved are a little bit different. It's not a bad thing either, we all live in the same society.


Probably the fact that the politicians hold actual power of force, control of ownership, etc. Nobody alive today in a first world country has lived to see what happens when their own government's blood is up. Prigozhin had a personal army and he still got blown out of the air.

If the MI6 chief believed what she was saying, she wouldn't be conducting a press conference.


To be fair to C++, the only languages with actually decently debuggable metaprograms are Lisp and Prolog.

Modern C++ in general is so hostile to debugging I think it's astounding people actually use it.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: