Sup Forums

Sup Forums
What do you think of dynamic typing in programming and script languages? All modern languages have this feature.

My colleagues appreciate dynamic typing. I hate it.

What do you think about it?

Other urls found in this thread:

docs.python.org/3/library/typing.html
twitter.com/AnonBabble

Dynamic strong typing is okay. It's convenient for a lot of scripting purposes. Dynamic weak typing should be violently removed imo.

This

Why do you hate dynamic typing? It’s never bothered me desu

Why is dynamic strong typing okay, but dynamic weak typing not?

it exemplifies the modern philosophy of "who cares if its correct, if it probably works most of the time, then ship it"

Because dynamic weak typing has a tendency to lead to situations such as this:

a = "2"
b = 2
console.log(a + b) // "22"
console.log(a - b) // 0


Whereas strong typing will not allow implicit conversion between types.

Oh okay now I get what you mean. It's all about the implicit casting. I don't like implicit casting. It's not transparent enough for me.

I think optional typing is nice. That way you can have quick prototyping and type safety.

I don't understand why is it so hard to write "int a". I like it when it's obvious from the code what type this and that is, although I suppose for some people knowing types is too complicated or something?

Sure, sometimes type flexibility can be nice, but I'd rather have it when I want it than always there, in 99% of cases you want strong static typing.

Dynamic typing is shit, we just need good type inference on strong statically typed languages.

>>I don't understand why is it so hard to write "int a"
have you met any of the webdev/JS people out there these days? do you know how stupid they are?

imo go handles it a pretty good way.

without type inference it just gets really gross really quick, do you really want to write

Scanner sc = new Scanner(System.in)

or shorthand it as

sc := new Scanner(System.in)

It is nice in SOME specific cases.

For example a function that outputs a value might accept strings, integers, flats or whetever.
Or a recursive function that can be called with an object or a primitive.

But it should be the exception rather than the default.
Maybe by using a special "type" like "anything" or "int,float"?

It's not about "hard to write type declarations hurr durr", it's about generic code.

Consider this Python code, for example:
def sort(a):
return a.sort()


You can call this function with any type that supports sorting, for example strings or lists.

In C, however, you'd have to do something like this
void sort_int(int* v);
void sort_char(char* v);
void sort_float(float* f);


Of course, you can do C++ template style generic programming, but that again leads to a totally different set considerations.

You can have type inference without dynamic typing though, C++11 and newer has this for example.

AFAIK Go isn't dynamically typed, but it supports type inference? Can you reassign sc to a different type?

And that leads to undefined or unexpected behaviors, like when you call sort on a list of numerical strings in Javascript and it sorts them lexicographically, which would be fine but due to the nature of weak typing in Javascript leads to completely accidental mis-sorts.
Sorting is literally the worst example of how generics are useful, because every sorting method or function should be explicit to the type you're sorting on.

>And that leads to undefined or unexpected behaviors, like when you call sort on a list of numerical strings in Javascript and it sorts them lexicographically,
You need to differentiate between dynamic strong typing and dynamic weak typing. Python is dynamically strongly typed. JS is weakly typed.

>because every sorting method or function should be explicit to the type you're sorting on.
Cnile please.

std::sort

Depends on the project and size of the team, right? Large teams of mediocre programmers - strong typing is best where you can catch many errors before checking in your code, but you have to write more code. Small teams with senior developers, you can rely more on dynamic typing, but you have to write more testing code (which can be passed off to junior devs).

I’ve recently learned Swift was very impressed. You can use it on small or large teams.

Gradual typing bro. Best of both worlds.

>Because dynamic weak typing has a tendency to lead to situations such as this:

only a brainlet retard would do something like that.

a = "2"
b = 2

//I want an string as result
console.log( (a+"") + b)
//I want a number as result not caring about checking for NaN
console.log( (a*1) + (1*b));

console.log( (a*1) - (1*b));

There is also parseInt, parseFloat, regular expressions, etc.

only pajeets could have a trouble with that kind of dynamic typing.

It sucks.

It's actually SLOWER to write since you have to browse through the code much more to actually find out what types a function takes as arguments.

Shit also blows up into your face much worse.

>print the variable
>see type
takes 5 sec max

Or even better
>use IDE
>it infers type

Type inferrence is not dynamic typing, it's still static.
Also with Java you have much worse boilerplate than just the typing.

t. someone who's never written or used an external API

You can do that with generics, too.
You don't need dynamic typing for this.

This. Hipsters, morons, and street-shitters.

That's what I said in my post.... My point was that dynamic programming allow generic programming in a different way than template-style generic programming.

I hope you're not involved in developing anything critical.

1 / 2

What? How do you print an argument a function takes?

Example:

def foo(bar):
lotsastuff

How do you know the type of bar?

Generics and templates are not the same. Generics are type safe and calling a generic function with an incompatible type gives you a error. Your solution blows up at runtime.

ok fag, whatever you say, keep using, + - directly without forcing your types or use a language more suited for brainlets like python.

>Generics are type safe and calling a generic function with an incompatible type gives you a error.
Explain to me how a function template specialisation does not behave in this exact way?

Python is shit and I'd definitely not use it for anything important.

It's probably you who's the shitty JS-dev.

2 / 2

It is the #1 source of bugs and Hindley-Milner typed languages are simply better-designed and easier to use.

It works by specializing on a certain type of types, so to speak. You can specialize on different kinds of numbrs, containers, etc.

>not use it for anything important.

implying you can code shit.

>How do you know the type of bar?
The point of duck typing is that you're not supposed to pass a specific type, only a specific type-interface.

>keep using, + - directly without forcing your types
Why would you even use a dynamic weakly typed language if you have to add a bunch of additional code to add artificial type-safety in the first place?

>It works by specializing on a certain type of types, so to speak.
>You can specialize on different kinds of numbrs, containers, etc.
And you can do this with templates in C++, can't you? So how is it different?

>The point of duck typing is that you're not supposed to pass a specific type, only a specific type-interface.
What do you mean by that? Imagine you have a function "calculate_distance(speed)". How do you know if it's km/h,m/s,mp/h or whatever without looking at the code?

>Why would you even use a dynamic weakly typed language i

I don't know, I don't care, I was just answering the fag who can't understand something as simple as type convertion in JS.

>ow do you know if it's km/h,m/s,mp/h or whatever without looking at the code?
How would you know that by just looking at the type. double speed doesn't give you any additional information.

He clearly understood it. He was making a point that it is horrible default behaviour.

There are more languages than just C++, you know. It's possible to do without metaprogramming trickery, that's what I wanted to say.

There's right and wrong ways of doing it. For example, lua is dynamically typed but will not cast between types except where only one cast is possible, i.e. print(num). It also uses .. as the concat operator, which ensures that you won't confuse adding with concats.

>There are more languages than just C++, you know.
I'm just wondering why you would say that template metaprogramming isn't generic programming, because it clearly is.

>It's possible to do without metaprogramming trickery, that's what I wanted to say.
How is that not the very exact thing I said in my original post when I said that dynamic typing allows for generic programming?

it's perfectly reasonable to have types for different units of things, if the language doesn't make defining types a pain

Are you slow? I'm saying you can have statically type checked generics without template metaprogramming.

I would prefer not to use such a library, reason is .

>it's perfectly reasonable to have types for different units of things,
You can define custom types in Python as well.

def calculate_distance(speed, time):
return speed * time

class km_per_hours(object):
def __init__(self, unit):
self.unit = unit
def __mul__(self, time):
return self.unit * time.hours

def km_per_second(object):
def __init__(self, unit):
self.unit = unit
def __mul__(self, time):
return (self.unit * time.seconds) / 3600.0

>I'm saying you can have statically type checked generics without template metaprogramming.
Wow, you bring fucking nothing to the table then.

See

>(self.unit * time.seconds) / 3600.0
Err, this should be

self.unit * time.hours * 3600.0

That still doesn't give you static type checking. Your shit will blow up at run time instead of telling you LOLNO at compile time.

Are you trolling me?

>That still doesn't give you static type checking.
That was never the point. You're moving the goalpost.

The question I answered was "how would you deal with different units for speed, it's perfectly reasonable to have types for different units of things" and to the guy that asked "How do you know if it's km/h,m/s,mp/h" as a question to my duck typing statement.

I don't know what the hell you're talking about, you must have invented your own separate thread or something... or you're moving the goalpost like the little dishonest cunt you are.

Go is not dynamically typed, and it supports only the most basically type inference (DUH TYPE ON DA RIGHT MUS BE DA TYP ON DA LEF), not Hindley-Milner.

Original post:
>"say you have this function signature foo(bar), how would you infer what kind of type foo expects without looking at the implementation of the functions"

My answer:
> "well, you shouldn't really look at specific types, but rather what type-interface is expected [duck typing]"

His reply:
>"okay, but say you have this function signature calculate_distance(speed), how would you determine what unit for speed it expects"

My reply to the unit question:
>"you should still rely on interface rather than type, see this example on how you would define custom type for two different units"


You, completely out of the blue and apparently replying to a completely different discussion chain:
>BUT WHAT ABOUT COMPILE-TIME TYPE CHECKING!!!

Right, thanks for the info. I'd probably have to look into Go some day.

It might frustrate you because it often focuses on simplicity over feature count. For instance, at some point some Pajeet using Go will wonder how exactly types are inferred, and will have to grasp all the complexities of Hindley-Milner and type theory to get an answer to their question. Instead, they realize (probably without even Googling) that the type inference just uses the type on the right.

Despite these choices I think it's a good language that makes a lot of good choices. It's my go-to language for almost anything.

> forcing your types

Wow I just had a great idea. Wouldn't it be great if the FUCKING COMPILER DID THAT FOR YOU

As of python 3.6.3 typing is being phased in as an option
docs.python.org/3/library/typing.html

iiiiinteresting

Mind you, it's still not enforced static typing, but it provides enough hints for a checker to do a good enough job.
If the project manager / workplace enforces this standard and requires you pass the tests, you get effectively the same result.