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

Cold Showers

github.com

Post reply on HN
Print view View original

321–330 of 363 posts

Re: Cold Showers

#321

Post by p4l4g4 »

drujensen wrote: post #101
sumy23 wrote: post #62

Earlier quoted context omitted.

It’s basically self-evident that static analysis reduces bugs. It’s trivial to construct an example of where type information would catch a bug. Unless there is some reason that including type information increases bugs, the existence of a single example where type information catches a bug would prove that overall type information reduces total bug count.

This reminds me of the studies done related to traffic lights and stop signs. Removing traffic lights and stop signs actually reduces accidents because drivers are more careful when driving through intersections which reduces speeds and drivers become more alert. Developers will adapt to their toolset. If you have a statically typed language, you trust it will deal with type related issues and you become more lax wit…

I think this analog is close to the dynamic vs static debate. However, there are probably more factors to consider, such as competence of the driver (will the driver even care to slow down?), location of the intersection (an intersection just around a shallow corner) and value of the driver's car (does the driver care about a little damage?).

In my experience similar arguments hold for software developers. Especially caring can be a big factor; i.e. the "move fast, break things" mentality.

I've been back and forth between typed and untyped languages (somewhere in the range of haskell and tcl) and personally prefer less typing when hacking things together and more typing for high quality software. I'm currently working an infra job where we use both ansible and terraform. They're not direct competitors, but I tend to prefer terraform over ansible when possible, as terraform gives me more "static" guarantees, which translates to more confidence when we apply our code.

Re: Cold Showers

#322

Post by koonsolo »

cloogshicer wrote: post #14

> Static Typing reduces bugs. At least to me, the big advantage of static typing is not that it (allegedly) reduces bugs, but that it aids my understanding and helps in navigating the program. It's a tool for thinking and communicating.

This, and especially when you have a new person in the team that needs to dig through the code.

function myFunction(user, security) { }

good luck finding out what user and security actually is. In static typing, it's all there.

Re: Cold Showers

#323

Post by jollybean »

jamal-kumar wrote: post #221
redredrobot wrote: post #218

Earlier quoted context omitted.

The argument is - engineers are expensive so why pay for the expertise to setup and run machines? There's just so many better things for your company to be spending the money on.

What if my company is pretty much all engineers? We don't let pencil pushers with MBAs anywhere near what we're doing, and it's going great. I know this isn't the most usual configuration but if undervaluing my skills and trying to bottom dollar on them is going to be their rules, then I'm just going to do my own thing, and they're just going to have to scrape the bottom of the barrel for talent. I hope the zeitgeist…

Maybe you need an MBA to help you understand that in many cases, it's incredibly more cost effective to use the cloud, because the marginal savings that could be achieved with on prem hardware are dwarfed by the cost of labour, and especially lost opportunity cost.

For most things 'local prem' is an optimization that usually needs on some degree of scale to justify, or, you have a peculiar setup i.e. a couple of well versed hardware and networking guys who have no problem with a bit of a physical setup. Which can be a bonus.

"I hope the zeitgeist changes any time soon."

No, it won't, it's going in the 'other direction' forever, because the 'economies of scale' at Amazon, it's incredibly difficult for individual engineers to compete with those efficiencies.

Just the opposite of 'being a problem for startups' , the 'cloud' has basically made entire swaths of types of startups possible where they wold not otherwise.

Like everything, you have to use think about it a bit but their costs are really, really transparent (imagine Oracle trying to do it ...).

Re: Cold Showers

#324

Post by jollybean »

oogali wrote: post #239
nemothekid wrote: post #224

Earlier quoted context omitted.

> What if my company is pretty much all engineers? I don't know how that changes the equation. No one is undervaluing your skills; it's would you rather spend your time driving to a colo center to replace a RAID array or working on $product. With AWS you are outsourcing an IT team, not just processors and how you approach pricing should reflect that.

I hear this bad argument often (“replacing hard drives”) and I don’t understand why. It’s as if we’re mentally stuck in a bad hacking movie from 1999. If you’re doing colocation to save money, you’ve also figured out that going to the datacenter sucks and it’s a terrible place to do work. You’re not building your own servers from scratch, you’re generally purchasing them from a vendor who offers a warranty and option…

So you've just explained why 'the cloud' is better than DIY.

Take all those things you just talked about, and expand them horizontally and vertically up the stack, and you have 'AWS'.

So not just 'a guy to replace the hardware' - but now it's software configurable, has all sorts of other, fancy things.

Time is money, and it's expensive to pay people to mess with things if they don't have to.

It's like this:

If your company needs 3 cars, you rent/lease them. You do not hire your own mechanics, even if technically speaking "we could change the oil for so much less!"

If your company is in the business of transportation, and you have thousands of trucks, you may want your own repair/maintenance team etc. instead of paying some service company a fat margin to change the oil.

Re: Cold Showers

#325

Post by maleldil »

falcolas wrote: post #231
maleldil wrote: post #190

Earlier quoted context omitted.

How would a "language engine" know what you can do with `item` if it has no type information? You can do that with Python (sometimes) because many libraries have type hints today, so even if you don't use types yourself, the type checker can infer them in your code and help you out.

Is this a serious question? Code analysis (both static and dynamic). The same way Rust checks for object lifespans with the borrow checker, which is distinct from the compiler and type system. The same way valgrind for C can check for use after free. The same way errorprone can look for null checks in Java. This is a well tested and proven technique. Static code analysis is a staple of the industry, when it comes to…

I still don't see how you can determine an object's attributes without type information. If you're inside the function, all you know is there's a parameter named item. How can you provide autocomplete there?

All of the examples you gave are from static languages, where the information is known at compile time (except for valgrind, which requires a runtime). The parent to my original post was claiming that you can have the same tooling for Ruby.

Also, you're wrong about Rust. Lifetimes are part of the type system.

Re: Cold Showers

#326

Post by danpalmer »

cloogshicer wrote: post #14

> Static Typing reduces bugs. At least to me, the big advantage of static typing is not that it (allegedly) reduces bugs, but that it aids my understanding and helps in navigating the program. It's a tool for thinking and communicating.

> It's a tool for thinking and communicating.

And when we understand this, we can weigh it up with alternative tools for thinking and communicating!

Would this 10 line shell script be better in a statically typed language? Well maybe not because I can hold all of 10 lines in my head, there's nothing else to communicate.

Would this CRUD app using Django/Rails be better with static types? Well the framework has defined a structure that communicates properties of the code to me, I don't need types written down because I already know them.

Would this complex parsing process of untrusted data into a trusted and verified format benefit from static types? Yeah probably, testing will be tricky and code review for security is hard, types will help reason about the possible states of the system.

There are lots of alternatives to static types: documentation, testing, frameworks, design patterns, code review, pair programming, error messages, and so much more. I'm generally a fan of static types and find them very useful in a lot of development, but they are a tool in a big toolbox.

Re: Cold Showers

#327

Post by ianbutler »

jollybean wrote: post #323
jamal-kumar wrote: post #221

Earlier quoted context omitted.

What if my company is pretty much all engineers? We don't let pencil pushers with MBAs anywhere near what we're doing, and it's going great. I know this isn't the most usual configuration but if undervaluing my skills and trying to bottom dollar on them is going to be their rules, then I'm just going to do my own thing, and they're just going to have to scrape the bottom of the barrel for talent. I hope the zeitgeist…

Maybe you need an MBA to help you understand that in many cases, it's incredibly more cost effective to use the cloud, because the marginal savings that could be achieved with on prem hardware are dwarfed by the cost of labour, and especially lost opportunity cost. For most things 'local prem' is an optimization that usually needs on some degree of scale to justify, or, you have a peculiar setup i.e. a couple of well…

I have never worked for a business with well controlled AWS costs, seems the MBA is failing a lot of people.

Re: Cold Showers

#328

Post by lijogdfljk »

jacobsenscott wrote: post #237
lijogdfljk wrote: post #130

Earlier quoted context omitted.

Depends on the specifics, but i'm betting if `IITem` is close by i know how to interact with it. I have no clue what the hell fields or methods may or may not be on `item`. Nor will i, ever. At best i have to enforce method/fields myself, at worst i subscribe entirely to duck typing and let the gods sort it out.

s/gods/tests/ - which you need even in a statically typed system.

I don't need tests to check what methods or fields are on my types though.

You need the same tests from a typed system in a non-typed. You _don't_ need all the tests from a non-typed system in a typed system.

Writing tests to enforce types just hand-rolls a type system, in my experience.

Re: Cold Showers

#330

Post by joeldo »

bjourne wrote: post #315
kdtsh wrote: post #313

Earlier quoted context omitted.

Now we are just talking about using a sane naming convention for your types. Depending on the paradigm you are working in your instance of IBlaha has a consistent definition - in a trait or a class or whatever else you like. It also likely makes simple work for your IDE during refactoring as others have observed. You don’t get this from dynamic typing. Of course you could say the same thing about sane naming dynamic…

Sure, the type IBlaha is defined somewhere just as the object(s) passed to add_item_to_cart are also defined somewhere. Again: "That it has type "Item" doesn't help you unless you have contextual information ." It has nothing to do with naming conventions. Whatever simplistic tools does is irrelevant since this sub thread was about the meaning of two declarations in HN comment. Dynamically typed languages are very po…

- Sure, the type IBlaha is defined somewhere just as the object(s) passed to add_item_to_cart are also defined somewhere.

That definition is rarely as accessible as an explicit type though. For example take an API response or any third party library. Determining the data type isn't as quick as simply scanning a function for the object definition.

- Dynamically typed languages are very popular so it seems that many developers can work their way around dynamic typing.

As someone who has spent a fairly even mix of their career using typed/untyped languages, I think this is due to a few reasons:

- Lower initial learning curve.

- Lower barrier to entry.

Those are real benefits, but I would argue most projects quickly hit a point where they benefit from static analysis.

Having worked with 100s of devs at this point, I'm yet to meet one that after learning a typed language and using it for a sufficient period of time (more than a few months) wants to use an untyped language for anything outside of small scripts.

Post reply on HN