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

Have Static Languages Won?

pointersgonewild.com

Post reply on HN
Print view View original

101–110 of 120 posts

Re: Have Static Languages Won?

#101

Post by nrinaudo »

JunkDNA wrote: post #99
realharo wrote: post #54

Earlier quoted context omitted.

Question is, how many real-world cases there are where duck typing is super beneficial. Usually if you need a bunch of differently-typed objects to fulfill the same contract, you can just make them implement an interface (said interface can also be documented, etc., it makes the intent very explicit). I do believe there are cases where dynamic typing is genuinely useful, but those make up a very small portion of real…

One place where I ran into this was when I was building an ETL framework in Scala. The scenario was that I wanted to be able to move data from one database system to another and not have the end user of the DSL have to care about the types. The use case was essentially that you should be able to show up to an arbitrary database, run a query, and then pump that output somewhere else (e.g. another DB, flat file, transf…

That sounds like a perfect use case for type classes, have you tried that? If so, I'd be interested to know why it failed, if you can find the time.

Re: Have Static Languages Won?

#102

Post by agentultra »

ldrndll wrote: post #92
agentultra wrote: post #55

Earlier quoted context omitted.

I assure you that even if you wrote it in Haskell you'd have a few unit tests and integration tests in there.

I don't think he claimed otherwise. There's a difference between a code base that makes judicious use of tests to validate business logic and one that relies on the test suite just to keep it from falling apart. I've worked on the latter, so I know ;) I'm not making any representations as to whether or not this is true of OpenStack. I honestly wouldn't know.

I can assure you, as an active technical contributor, that the testing infrastructure in Openstack is verifying business logic, ensuring consistent coding standards, running unit tests and code coverage, and all of the usual activities associated with delivering reliable software. The difference for many projects is the scale at which it is automated thanks to the Openstack Infra and QA teams.

Any suggestion that Python code cannot possibly execute without it is an exaggeration.

Re: Have Static Languages Won?

#103

Post by dllthomas »

tachyonbeam wrote: post #43
realharo wrote: post #8

> You can have statically compiled languages that use type inference to realize what is effectively dynamic typing. Just because you don't have to explicitly write out the type does not make it any less static. I believe that the usual arguments against languages with static typing such as verbosity and lack of flexibility are largely eliminated by the more modern languages such as Scala, Kotlin or Typescript (though…

It's not just "not having to write out the type". It's that the compiler can automatically insert typed unions to make the typing dynamic where you need it. If a variable can have different types at different times, that's dynamic typing.

One way of looking at a union type is "this variable can have different types at different times." Another is "this variable has a single type - the union type."

Especially if actions are restricted to those valid on all parts of the union, I'd say it is correct to consider that to still be static typing.

Re: Have Static Languages Won?

#104

Post by dllthomas »

jayvanguard wrote: post #100
brianwawok wrote: post #66

Earlier quoted context omitted.

So a big project with optional typing. How do you handle it? Each person picks a level? Or make rules that all services are strongly typed but within a method is loosy goosy? I see the project going one of two ways. One all loosy goosy. One all statically typed. At which point what did optional typing add? Pick a side and go for it.

I see it as a gradual thing. Early in the project loosey and then as the software matures add in more typing. But yeah, everyone needs to agree on the right level for that stage in the project.

You seem to be under the impression that types are for late stage development. I find them indispensable early on. First, because they let me feel out where my assumptions conflict, often before I've gotten to writing the bit of code that will make it obvious. Second, because when my assumptions are wrong, the type checker is a tremendous help refactoring - telling me all the places my old code is incompatible with my new assumptions. Both of these mean I don't need to be quite as sure that I've got things exactly right as I start coding.

Re: Have Static Languages Won?

#105

Post by sanderjd »

nrinaudo wrote: post #82
realharo wrote: post #54

Earlier quoted context omitted.

Question is, how many real-world cases there are where duck typing is super beneficial. Usually if you need a bunch of differently-typed objects to fulfill the same contract, you can just make them implement an interface (said interface can also be documented, etc., it makes the intent very explicit). I do believe there are cases where dynamic typing is genuinely useful, but those make up a very small portion of real…

I agree that duck typing is rarely critical, you can always work around it when you find you'd like to have it. On the other hand, I disagree with the scenario you describe: if you have multiple types that come from an external, closed-source library , you won't be able to have them extend a new interface. If you're lucky and they've not been marked final, you'll need to wrap them in another type that extends the rig…

Those sound like implementation details of a specific language (C# I'm guessing?) rather than a fundamental attribute of statically typed languages.

Re: Have Static Languages Won?

#106

Post by nrinaudo »

sanderjd wrote: post #105
nrinaudo wrote: post #82

Earlier quoted context omitted.

I agree that duck typing is rarely critical, you can always work around it when you find you'd like to have it. On the other hand, I disagree with the scenario you describe: if you have multiple types that come from an external, closed-source library , you won't be able to have them extend a new interface. If you're lucky and they've not been marked final, you'll need to wrap them in another type that extends the rig…

Those sound like implementation details of a specific language (C# I'm guessing?) rather than a fundamental attribute of statically typed languages.

I don't think so, but I'd be happy to be proven wrong.

If you have a function that expects a type A, and you want to pass an object of type B that doesn't have A as a supertype, I don't know of many ways to do so. Either you wrap your B in a type that extends A, or you create a new implementation of B that extends A (this is often the same solution as the first one), or you use type classes or some variant of the concept. Is there an other option that I'm not seeing?

Re: Have Static Languages Won?

#107

Post by drewgross »

nrinaudo wrote: post #106
sanderjd wrote: post #105

Earlier quoted context omitted.

Those sound like implementation details of a specific language (C# I'm guessing?) rather than a fundamental attribute of statically typed languages.

I don't think so, but I'd be happy to be proven wrong. If you have a function that expects a type A, and you want to pass an object of type B that doesn't have A as a supertype, I don't know of many ways to do so. Either you wrap your B in a type that extends A, or you create a new implementation of B that extends A (this is often the same solution as the first one), or you use type classes or some variant of the con…

In Haskell, you declare that a type is an instance of a typeclass, and provide implementations for the required functions. You can do this anywhere for any type. Then, you have your functions accept any type that is an instance of you typeclass you need. Go has a vaguely similar concept. This is incompatible with subtyping, but not incompatible with static typing, and is one of the reasons fans of functional programming languages can so derisive of languages that allow subtyping.

Re: Have Static Languages Won?

#108

Post by drewgross »

nrinaudo wrote: post #106
sanderjd wrote: post #105

Earlier quoted context omitted.

Those sound like implementation details of a specific language (C# I'm guessing?) rather than a fundamental attribute of statically typed languages.

I don't think so, but I'd be happy to be proven wrong. If you have a function that expects a type A, and you want to pass an object of type B that doesn't have A as a supertype, I don't know of many ways to do so. Either you wrap your B in a type that extends A, or you create a new implementation of B that extends A (this is often the same solution as the first one), or you use type classes or some variant of the con…

In Haskell, you declare that a type is an instance of a typeclass, and provide implementations for the required functions. You can do this anywhere for any type. Then, you have your functions accept any type that is an instance of you typeclass you need. Go has a vaguely similar concept. This is incompatible with subtyping, but not incompatible with static typing, and is one of the reasons fans of functional programming languages can so derisive of languages that allow subtyping.

Re: Have Static Languages Won?

#109

Post by [deleted] »

drewgross wrote: post #107
nrinaudo wrote: post #106

Earlier quoted context omitted.

I don't think so, but I'd be happy to be proven wrong. If you have a function that expects a type A, and you want to pass an object of type B that doesn't have A as a supertype, I don't know of many ways to do so. Either you wrap your B in a type that extends A, or you create a new implementation of B that extends A (this is often the same solution as the first one), or you use type classes or some variant of the con…

In Haskell, you declare that a type is an instance of a typeclass, and provide implementations for the required functions. You can do this anywhere for any type. Then, you have your functions accept any type that is an instance of you typeclass you need. Go has a vaguely similar concept. This is incompatible with subtyping, but not incompatible with static typing, and is one of the reasons fans of functional programm…

[deleted]

Re: Have Static Languages Won?

#110

Post by dllthomas »

nrinaudo wrote: post #106
sanderjd wrote: post #105

Earlier quoted context omitted.

Those sound like implementation details of a specific language (C# I'm guessing?) rather than a fundamental attribute of statically typed languages.

I don't think so, but I'd be happy to be proven wrong. If you have a function that expects a type A, and you want to pass an object of type B that doesn't have A as a supertype, I don't know of many ways to do so. Either you wrap your B in a type that extends A, or you create a new implementation of B that extends A (this is often the same solution as the first one), or you use type classes or some variant of the con…

Why aren't type classes the solution you're looking for?
Post reply on HN