>Productivity
Daily reminder that if you don't know what type your function should be returning, you shouldn't be programming
>>51521357
Fuck you and your toy language, whiny ML faggot.
>>51521357
And yet indeed productivity
>>51521357
> if you don't know what type your function should be returning
... then dynamic typing won't help you. It will just delay the inevitable error until the relevant code actually gets run.
Most of the time I prefer static typing, but dynamic typing has one concrete advantage: it doesn't stop you from writing correctly-typed functions just because their type isn't something which the language's type system can express.
Even Haskell, even a hypothetical version which contained *all* of the myriad extensions to its type system, still imposes limitations on types. Whereas a dynamically-typed language lets you tell the language "butt out, I know what I'm doing".
>>51523559
>>
>Even Haskell, even a hypothetical version which contained *all* of the myriad extensions to its type system, still imposes limitations on types. Whereas a dynamically-typed language lets you tell the language "butt out, I know what I'm doing".
wouldn't the best solution be something like C where it's statically typed, and the compiler checks your work, but lets some things slide (like promoting an into to a long int) and lets you tell it to go away and let you do what you want if you really need to by casting to void* and such?
>>51521357
>not using ROOT's C++ interpreter to prototype your C++ projects, completely deprecating python's pro of 'easy prototyping'
>>51521357
One could write python like:def foo(name: str, age: int) -> str:
print('Hello {0}, you are {1} years old'.format(name, age))
It works, but for some obscure reason, there is no option for the interpreter to check type integrity, even at a warning level. I don't get it, you could write safer code this way, if you wanted.
>>51524010
>It works
No it doesn't
>>51521357
Well, you can write recursive anonymous functions with it(otherwise they'd require infinite expansion of an argument's type)
>>51524036
It does with version 3.5, just tested the code snippet.
However, the "type declarations" are just syntactic details, benefiting the human writing and reading the code.
>>51524051fix :: (a -> a) -> a
fix f = let x = f x in x
>>51524133
Don't U MENAnewtype Fix f = Fix { unFix :: f (Fix f) }
>>51524196
not really
Easy to implement duck typing.
http://ideone.com/WdujFO
>>51524214
Mr >>51524051 is talking about types, you posted value-level generic recursion.
>>51524242
He was talking about writing recursive anonymous functions, and that's what fix is for.
>>51521357
Daily reminder you should kill yourself.
>>51524258
Oh you're right. Type-level fix does resolves his assumption of
>(otherwise they'd require infinite expansion of an argument's type)
though.
>>51524380
Oh, yeah, it's right. There's no theorical limitation for avoiding infinite types though, it would even be possible to teach GHC to reason about them (according to Richard iirc).
>>51524010
Please refrain from using Python 3 because it's deprecated by Python 2.7
>>51524051
You can easily write recursive anonymous functions in Haskell and have them infer.
It has been proven undecidable to infer polymorphic recursion, but we can quite happily type check it in Haskell if there's a type annotation.
>>51524010
The one thing I actually like about java other python is the ability to define multiple versions of a method with different types in each constructor.
You can do the same thing in python by checking isinstance() for all the different combinations, but it can quickly turn into a mess.
