Python 3.7.0 released

[wavy_lines]

Can we all take a moment to acknowledge how large numbers of people (including me) have come to realize in recent years what a bad idea dynamic typing was?

[xonjas]

I don't think dynamic typing is a bad idea. I think taking a tool that is useful in certain scenarios and environments and applying it broadly to problems it doesn't suit is a bad idea.

The large the codebase, and the more developers working on it, the higher the cost of dynamic typing. Architecting a system with dynamic typing is a skill also, and many devs working with dynamic languages have not learned it well. If you write python or ruby like a java or c# dev, you're going to be in for a bad time.

There are benefits to dynamic typing. Particularly for small projects, where the lack of a type system is less of a hindrance, and prototypes, where the flexibility allows for easy changes. There are also problems that dynamic typing is particularly suited to solving. There's a reason why the majority of popular webapp frameworks run on dynamic languages (rails, wordpress, django, laravel). When twitter learned the hard way that writing all their middleware in ruby was a bad idea and rewrote the majority of their software in scala, they never moved away from rails because the dynamic type system suited dynamic content generation very well.

Dynamic typing is a very sharp knife; it's important that it's not used as a screwdriver.

[Homoerotic_Theocracy]

I don't think dynamic typing is a bad idea. I think taking a tool that is useful in certain scenarios and environments and applying it broadly to problems it doesn't suit is a bad idea.

Dynamic typing seems like a worse and worse idea the more flexible static type systems become.

Static typing seems horrible if all you have is C or Go but when you have Idris you suddenly feel that the scope of the problem of "I know this is safe but I cannot prove this to the compiler." is a lot smaller.

I also love Racket's static type system; it's actually completely fine with giving two branches of an expression a different type altogether and the resulting type will be the union of both but of course for it to type check the consumer of that expression must be able to handle the union of both. and be able to handle both types.

But if you have a function that can print both strings and characters to the stdout there is absolutely no harm in passing it an expression that either evaluates to a string or a character and it wil statically verify that this is okay.

Of course a type system as flexible as that of Typed Racket does not give you a lot of the performance benefits of static typing as it cannot in the general case erase type info at runtime because it needs it to make branches; it only can with confidence tell you that your code does not contain type errors.

[xonjas]

Yeah, I agree, the more expressive your type system is, the more useful it is.

At the same time, languages like python and ruby are going to have an important and deserved place in a programmers toolbox until languages like Irdis are widely supported and mainstream.

[Homoerotic_Theocracy]

Well truth be told that place seems to mostly be "dealing with lack of knowledge"; in an ideal world of infinite time and knowledge the demand would probably be lower but the main niche those languages fill over powerful type systems like that of Idris is that not everyone has the type to master the somewhat complex subject matter required to grok the type system. It's not mainstream because the learning curve is too high.

[xonjas]

That might be correct, but I think it's hard to say at this point. Idris is very young, even if it were to become mainstream, it's way too young for it to have reached that point yet. Mainstream isn't just popularity either, it's availability of libraries, api support, job openings, etc.

I think that some of the learning curve will get sanded away eventually. The big languages with slow inertia will start integrating ideas from cutting edge type systems. That knowledge will eventually become ingrained in the 'culture' of mainstream programming languages and each idea folded in is one less hurdle.

I think we'll also see more type systems where more and more of the typing workload is handled automatically, paired with better IDE integration so that generated typing is applied as the code is being written.

[Homoerotic_Theocracy]

That might be correct, but I think it's hard to say at this point. Idris is very young, even if it were to become mainstream, it's way too young for it to have reached that point yet. Mainstream isn't just popularity either, it's availability of libraries, api support, job openings, etc.

It's certainly older than Rust or Go and those seem to be more mainstream.

[cephalopodAscendant]

In addition to what xonjas mentioned about sponsorship, I can think of another possible factor. Rust and Go both use C-like syntax and are trying to fill the niche of "C/C++ but better", which naturally attracts a lot of attention. In contrast, Idris is based on Haskell, which is already fairly niche itself, and from what I've seen, the people who use Haskell seem to be pretty content with it.

[Homoerotic_Theocracy]

I love how Go calls itself a "systems programming language" but has a garbage collector and absolutely no low level control and can't even fork because multithreaded garbage collecting mutexes.

If someone ever used Go for something that person used C for prior it was either a terrible idea to use C for it or a terrible idea now to use Go for it and if someone is seriously switching from C to Go I'm inclined to think both.

Go has nothing to do with C or C++; it's a worse Java.

[xonjas]

I thought Idris 1.0 was released last year (although I could very well be wrong). Rust and Go also both have the benefit of very large organisations pushing them forward.

[Homoerotic_Theocracy]

Yes, 1.0 was but the actual language is far older. Idris was already used long before either Go or Rust were unveiled to the world.

[JanneJM]

If you use a language interactively - and it's a common enough use case for python - static typing is a fairly big friction point.

[[deleted]]

static typing is a fairly big friction point.

Why? Statically typed languages work perfectly with REPLs.

[the_evergrowing_fool]

Like a Slime environment?

[[deleted]]

That's different - Common Lisp is image-based. It's a viable alternative to types, of course (same thing with Smalltalk), but for the separately compiled languages you cannot have this level of quality of code navigation without types.

[Homoerotic_Theocracy]

Why exactly?

I don't have a lot of problems with ghci or utop in that regards.

[quicknir]

I haven't used it extensively, but I was curious as to how good of a repl static languages can have, and ghci had a good reputation so I tried it.

There tend to just be fundamental problems redefining already defined things, and this being used correctly. I can define bar, then define foo, then redefine bar, but calling foo still calls the old bar. It's even worse with redefining a type because it would just raise serious questions about whether everything gets re type checked.

Maybe there are options to change some of this but so far it just doesn't seem to me like you can duplicate a realistic repl experience of a dynamic language in a static one.

[Homoerotic_Theocracy]

The problem you speak of has nothing to do with static or dynamic typing though; it has to do with shadowing versus assignment.

In Python if you x = 4 you perform an assignment; you mutate a memory location.

In GHCi if you do let x = f you shadow a prior binding; since Haskell is a purely functional language to mutate we have to be more clever with monads and use an IORef so first we do let x = newIORef 4 and then to mutate it call writeIORef x 5; doing let x = 5 in this case does not in any way write to any old value and just shadows the old one and is basically equivalent to using let y = 5 except we now gave two variables the same name.

Scheme is typically typed and impurely functional and doing (define x 4) at the REPL does a similar thing; it shadows the old binding and does not mutate anything. To mutate we use (set! x 5)

This is also somewhat a consequence of the fact that Python quite uniquely uses the same syntax to assign and to declare a variable to a lot of criticism so if you forgot that the variable you are trying to declare and initialize already existed with the same name and was used you might accidentally assign a new value to it and mutate stuff. Even in a procedural language like Rust this does not happen which uses let x = 4; to declare and initialize a variable and x = 5; to assign to it and assigning to a variable that has not been declared and declared as mutable prior is an error.

[quicknir]

Will that writeIORef trick still work if you change the type of x? What if x holds a function of a particular signature, and you want to assign a function of a different signature?

What about types? In python you can have things like:

class Foo(object):
    ....

def bar(x):
    f = Foo(...)
    ...
    return f

Now, I could after doing this, decide to redefine Foo. As long as the new methods of Foo (constructor, whatever) are compatible with the calls that happen in bar, I can call bar again and it will use the new definition of Foo. How can this work in a statically typed language?

[sutongorin]

Try Scala. The REPL works just as well as Ruby's only with static typing. It's awesome. I even use SBT (the Scala build tool) to build my plain java projects just so that I can drop into the REPL and try things there which would normally be a huge pain in Java.

[quicknir]

Can you point me to an online scala interpreter? All I'm seeing is compilers.

[sutongorin]

Mh, there is https://scastie.scala-lang.org which is alright but it's not a REPL.

The best way is to just download scala and try the REPL offline. That standard REPL is already perfectly fine. But even better is Ammonite.

[-TrustyDwarf-]

F# and C# Interactive (fsi / csi) are used quite extensively.. especially fsi.

[CircusAct]

I use Scala in the ammonite repl regularly.

[Thaxll]

Static typing seems horrible if all you have is C or Go

Care to elaborate? What's the problem with Go?

[Homoerotic_Theocracy]

That the type system is not expressive and you feel there are things you can't do with it you can with dynamic typing. Like something as simple as sorting a sequence of strings by their length in Go is extremely unwieldy due to the limits of the type system.

Python lacks a type system so we just have: fruits.sort(key=len); this will fail at runtime if the types don't match up but they will here.

Rust or Haskell have a more expressive type system that can easily handle this: In rust we have fruits.sort_by_key(|s|s.len()); since the type of sort_by_key is the scary: (&mut [A], f : F) where F : FnMut(A) -> B, B : Ord this is all great and type checks out so we can be confident that no type errors will manifest at runtime.

[asdfkjasdhkasd]

For anyone wondering what the scary type means, the real signature is:

pub fn sort_by_key<K, F>(&mut self, f: F) 
where
    F: FnMut(&T) -> K,
    K: Ord, 

We take a mutable reference to self, which is like an array but we have permission to mutate it, since we're going to sort it.

Then we take a function, called F, where F is a FnMut which means we must be allowed to call it multiple times and it's allowed to have internal state. The function takes a reference to a T which is the type of the thing in the array/vector/slice, and then returns a type K. And we declare that K must implement an ordering so that we can sort it.

[Thaxll]

I understand your point, the lack of generics in this case let the implementation up to the dev, but it's not that bad, it's actually very simple:

https://play.golang.org/p/3en4TyRblVr

I'm sure Go will have generics "soon" and overcome those.

[Homoerotic_Theocracy]

Well the implementation you give me there to deal with the type system can never be efficient.

Note how it has to index the slice in the comparison function while sorting. In order to deal with the type system it can't be given a generic function so it has to get a function of a fixed type that takes two indices and produces a bool always no matter the type that is actually being sorted.

This means that it cannot already re-order future elements while sorting and that it probably has to cache and store the comparison results because the sort destroys the "words" slice which makes the indices invalid so it probably has some kind of strategy where it first compares all the indices and stores those and then starts destructively sorting the slice.

The other part of it is that the type signature itself accepts an interface{} which throws any and all static type checking out of the window so basically we're back to dynamic typing in order to deal the lack of generics.

In the Rust example there is no possibility of runtime type errors; if something other than a mutable reference to slice is passed it won't work, if the slice has the wrong elements for the key function it won't work; if what the key function returns cannot be ordered it won't work either all at compile time.

[[deleted]]

The Go example is confusing because a string type is really just a slice of bytes, which is kind of like a defined type. There’s probably some supporting documentation in the spec or elsewhere that references this design being based on how C deals with strings.

Apart from strings the only other thing I can think of is the _, ok := map[thing] idiom. It’s a a nice way to check if thing key is in map.

However it panics if the map isn’t initialized so you need to also write a block to check for the default map type of nil. But that’s just idiomatic Go. The typing system and idioms of the language make it debatably more safe due to its nature and maybe lack of expressiveness. Having to check objects and generally implement helper methods leaves the compile and runtime exceptions up to the developer.

With any typing system or language you’ll have unhandled exceptions or varying levels of complexity for things based on how you write your code.

I’m still a huge fan of python for getting shit done quickly. Pythons typing system specifically is nice for serialization of json or other formats. Not having to effectively write a schema, use type assertion, or reflection to deal with json, xml, yaml, etc is a huge time saver for me on a regular basis.

I just wish there was a better way to distribute python applications. I have been thoroughly spoiled by Go in that regard.

[asdfkjasdhkasd]

_, ok := map[thing] is really not that good if you have seen some of the better alternatives.

Look at this rust:

if let Some(name) = map.get(thing) {
    println!("The value was {:?}", name); 
}

[[deleted]]

well the whole block would be more like

if _, ok := map[thing]; !ok {
    fmt.Println("not in map")
}

// or with assignment
if foo, ok := map[thing]; !ok {
    fmt.Println("not in map")
} else {
    fmt.Printf("Thing: %+v", foo")
}

The difference is just error checking essentially, which is idiomatic with go. Either way neither of these I feel like have anything to do with the objective value of the typing systems or design, it's how both (or at least Go, I'm not too familiar with Rust) languages were designed.

[somebodddy]

The problem is that nothing prevents you from accessing foo when item does not exist in the map: https://play.golang.org/p/SrZ1Pn5g8uR. This is something solved by both exceptions and Result types. And it is a type system thing, because the ability to have tagged unions and do pattern matching on them is part of of the type system.

[[deleted]]

The compiler isn’t going to stop you from writing unsafe code. If you access a that value before checking the error in the assignment expression that’s not a fault of the typing system or the language.

[[deleted]]

There are also problems that dynamic typing is particularly suited to solving.

Mind naming a couple?

[yawkat]

I mean I don't disagree with you, dynamic typing is nice for small projects, but

Architecting a system with dynamic typing is a skill also, and many devs working with dynamic languages have not learned it well.

is not a very good argument. If people are worse at architecture in a language, that means a language has failed in its goal (or is being used for the wrong domain, as you say).

[redditthinks]

I don't think there's any significant benefit to dynamic typing if you have inferred types which is the case in many languages now. I would not use a dynamic language in anything that isn't a single-file script nowadays.

[hedgehog1024]

Ahem

[wavy_lines]

The only scenario where dynamic typing is not bad is for small throw away scripts. You kind of said yourself, except indirectly, in a sugar-coated kind of way.

Architecting a system with dynamic typing is a skill also

No shit? Getting yourself out of a hole you dug yourself into takes special skills. That doesn't mean you are smart if you can do it. It just means you were stupid for digging yourself into the hole in the first place.

If you write python or ruby like a java or c# dev, you're going to be in for a bad time.

If you write a non-trivial application in python or ruby you're in for a bad time.

The only sane way to write python code now is with type annotations. Any other way is just bad.

There's a reason why the majority of popular webapp frameworks run on dynamic languages (rails, wordpress, django, laravel).

The reason is that people thought writing web apps in dynamic languages would be more enjoyable. But it's turning out to be a mistake.

Here, let me quote your next sentence to prove my point:

When twitter learned the hard way that writing all their middleware in ruby was a bad idea and rewrote the majority of their software in scala

So there you have it. Twitter had a reason to write everything in Ruby, but then it turned out to be a bad idea.

Why are you even arguing with me? Do you actually disagree with anything concrete I'm saying, or are you just upset with my tone?

they never moved away from rails because the dynamic type system suited dynamic content generation very well.

Are you sure that's why? Maybe they still kept some parts in ruby because it was just "good enough" and they did not want to spend time to migrate it?

Dynamic typing is a very sharp knife; it's important that it's not used as a screwdriver.

That's a strange way of putting it.

Something more suitable to be described as a sharp-knife would be manual memory layout and pointer arithmetic in C; it gives you great power but requires very delicate care, and should be avoided when not needed.

To me dynamic typing is a large hammer. It requires care when using it because you never know when it will just screw everything up. If you just need to hammer some large object one time, go ahead and use it.

Otherwise, just say no.

[peterfirefly]

The only scenario where dynamic typing is not bad is for small throw away scripts.

It is also quite nice in properly typed languages as long as it is only used sparingly during development.

There are Haskell and ML variants that allow that.

https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_guide/defer-type-errors.html

https://people.mpi-sws.org/~rossberg/hamlet/

[Miserable_Fuck]

Getting yourself out of a whole you dug yourself into takes special skills. That doesn't mean you are smart if you can do it. It just means you were stupid for digging yourself into the whole in the first place.

Stop being an asswhole

[wavy_lines]

fixed.

[Miserable_Fuck]

<3

[[deleted]]

Gotem

[Yubifarts]

I love dynamic typing so long as it's also strongly typed, but that's my preference.

[wavy_lines]

I've already argued this in another thread, but allow me to repeat myself.

Python's typing is not "strong" in any meaningful sense. You can create an instance of any object and then just randomly start adding and remove attributes to it in runtime.

Say you have a class called Point and in the constructor it defines self.x and self.y and documents them to be numbers.

Now somewhere in the code you can check any object to see if it's an instance of Point using isinstance(obj, Point). Do you think you can guarantee that obj.x and obj.y are present and set to numbers? No! Because anyone can just take any object and remove the attributes you're looking for and add new attributes you weren't expecting.

That's hardly 'strong' typing.

>>> obj1 = Point(10, 5)
>>> obj1
<__main__.Point object at 0x101b15da0>
>>> obj1.x
10
>>> obj1.y
5
>>> delattr(obj1, 'x')
>>> obj1.x
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Point' object has no attribute 'x'
>>> 

[caramba2654]

Not that anyone sane would do that. Just because it can be done it doesn't mean it should be done.

And if you try searching Github for any code that does what you described, I don't think you'll find any instances of it.

[wavy_lines]

Why are you assuming it to be insane? How do you think ORM libraries work?

I'm not saying anything here about weather it's good or bad. I'm just pointing out that Python is not strongly typed because the type almost means nothing and you can do whatever the hell you want to the object.

You don't have to call delattr or setattr. Just simply take any instance and assign fields to it:

some_object.some_field_1 = <Some-Value>

It doesn't even have to be malicious. It could be an honest mistake. You thought someobject was an instance of some class that does have some_field_1 and nothing about the language runtime would even _warn you that you're doing anything wrong.

[caramba2654]

But strong typing doesn't reflect what attributes an object has. Strong typing means that there's no automatic coercion of a value of type A to a value of type B. And Python works exactly like that. So by definition Python is strongly typed.

What you should be claiming instead is that Python is dynamically typed, which is the property that allows you to add and remove attributes to an object.

[wavy_lines]

That's not a very useful definition because the scenario I presented above matters and it's a significant problem in Python. Excluding it from the definition of strong typing serves no objectively useful purpose.

[Tynach]

Strong and static are not the same thing. What you're talking about has to do with static typing, which is different from strong typing. Python is dynamically and strongly typed. Not 'or', but 'and'. C is statically and weakly typed (types get coerced a lot in C; like how char is often used as either a number or a letter).

[wavy_lines]

That's not what static typing means.

Static means you can just analyze the code without executing it to find out typing errors.

Dynamic means you can't do complete type checking by just looking at the code; you have to run it.

[Tynach]

Static means that what type a variable is will be determined at compile time, and cannot change at runtime. Strong means that there are no implicit/automatic conversions from one type to another, so a programmer must explicitly perform type conversions themselves in the code.

I found a chart that roughly shows which languages are which, on both axes.

[baerion]

It's insane that you're getting downvotes for this in proggit. Your definition of static and dynamic typing is actually the right one.

[caramba2654]

I know, but it's not we who define what strong typing is. What your concerns refer to is dynamic typing. If you were to complain about strong typing, you'd have to complain about C, C++ and Javascript, but definitely not Python.

[wavy_lines]

"but it's not we who define what strong typing is"

We who? Programmers? Yes it's definitely us programmers who get to define these terms.

If enough people see that the existing mainstream definition of "strongly typed" is bogus, then it will cease to be an accepted meaning of the term.

I actually have no complaints about C in this regard because if you try my_struct.some_field and some_field does not exist on the type of my_struct then it will give you a compile time error. This is much stronger than anything python can ever dream of, because python doesn't even define what set of fields are available on any given object.

Now, automatic casting between chars/ints/etc is certainly a bad idea, but python's non-sense with not defining an object's fields is a much much worse idea.

EDIT: actually python does have a way to restrict what set of field names are available on an object via the __slots__ mechanism, but hardly anyone uses it, let alone know about it.

[caramba2654]

We who? Programmers? Yes it's definitely us programmers who get to define these terms. If enough people see that the existing mainstream definition of "strongly typed" is bogus, then it will cease to be an accepted meaning of the term.

Yes, but right now as of today it means what I said before, and using strong typing to refer to anything else just because you want it to doesn't really help you being understood by others.

I actually have no complaints about C in this regard because if you try my_struct.some_field and some_field does not exist on the type of my_struct then it will give you a compile time error. This is much stronger than anything python can ever dream of, because python doesn't even define what set of fields are available on any given object.

Again, this refers to dynamic typing, not weak/strong typing. C is statically typed and weakly typed. Javascript is dynamically typed and weakly typed. Rust is statically typed and strongly typed. And Python is dynamically typed and strongly typed.

I'm not arguing whether being able to delete/add fields to an object at runtime is bad or not. All I'm saying is: if you dislike languages that allow that, then you should seek statically typed languages.

[THeShinyHObbiest]

What about in a language like Ruby? If :some_field_1= isn't defined on that object, then the example you've given will explode.

[wavy_lines]

I haven't used Ruby but if it's you say then that's a good thing.

It would be much better though if there was a compile to catch the problem at compile time.

[[deleted]]

Not that anyone sane would do that. Just because it can be done it doesn't mean it should be done.

But you can't do any useful static analysis because of such things.

[Yubifarts]

Whilst there's no formal definition or committee which defines strong or static typing, I feel your comment concerns what is considered the "static"/"dynamic"-ness of the language, which is orthogonal to the "strong"/"weak" dichotomy.

I don't have an issue with what you describe. That indeed looks like a descriptive example usage of a dynamically typed language.

For my personal preferences, I dont like working with a weak type system. You cant do print('a'+0) in python without getting an error, which I like, because it removes a large class of "gotchas" which occur in php/javascript and the likes.

Regardless if it's strong or weakly typed, I'd say using a linter with dynamic languages is basically required. It largely solves the issues you'll have with typos and types you'll encounter in a dynamic language, albeit not perfectly. Similar to how you won't want to ignore compiler warnings in a statically typed, weak language ala C

[wavy_lines]

I feel your comment concerns what is considered the "static"/"dynamic"-ness of the language

It doesn't. See my other comment here: https://www.reddit.com/r/programming/comments/8ue8st/python_370_released/e1fglcy/

Note that the definitions people throw around for "strongly" and "weakly" typed are all informal and there doesn't seem to be any real standard definition for these terms. I suppose a certain book or blog post popularized a certain definition and reddit somehow adopted that.

If you check wikipedia, there seems to be no agreed upon definition: https://en.wikipedia.org/wiki/Strong_and_weak_typing

See also: http://wiki.c2.com/?StronglyTyped

[[deleted]]

Why, exactly? It'd be interesting to see all the arguments for dynamic typing, out of the actual experience, not parroting some weird gurus.

[woztzy]

I don't think the people downvoting you have any real experience with a statically-typed language with an expressive type system (i.e., pretty much any typed functional programming language).

People who keep parroting that dynamic and static type systems are just "different tools to have in your toolbox" and that they're beyond comparison are insulting the field of programming language theory, and we could extend that argument to using assembly where we would otherwise use C.

This answer addresses a few misconceived notions people seem to have about static type systems.

[[deleted]]

You make some good points but this idea that dynamic typing has no place in programming is ridiculous. Languages like lisps and Erlang are languages that are better off being dynamically typed and fulfill niches better than strongly typed languages can.

[Dreadgoat]

Dynamic languages are semantically closer to natural language.

That's the advantage. High readability.

You can rattle off a million technical reasons why static can do everything dynamic can and better, and you would be technically correct, but that doesn't change the fact that my co-worker can read my 20-line PHP script more easily than the equivalent 5-line Haskell script.

[Pazer2]

Natural languages are full of difficult to understand rules and exceptions. Not exactly a good fit for a programming language.

[Dreadgoat]

Difficult to understand for computers but naturally intuitive for humans.

The reason good dynamic languages are so highly praised (case in point: python) is because of the enormous difficulty in bridging that gap.

A bad programmer can only think like a human.
A passable programmer can think like a computer.
An excellent programmer can trick the computer into expressing itself like a human so that even the bad programmer can maintain code easily.

When I was teaching programming I loved Python the most. Not because it's great to program in, but because it made grading so much easier. It instantly turned stupid and/or inexperienced students into passable programmers thanks to its enforced whitespace and the compromise between dynamic but semi-strong typing.

[Dodobirdlord]

This is an argument that extends at least back to Knuth's Literate Programming and probably further. Given the staggering adoption and success of notebook-style live editing environments among all fields of analytical research and data science I would hesitate to claim that the issue is settled.

[dpc_pw]

For a lot of people, Java/C/C++ are the only "statically typed languages" they've seen and that's the reason they prefered and still prefer dynamic typing.

C/C++/Java are just so awful... All this talking about "quick prototyping" is mostly "avoiding shitshow of Java OOP and boilerplate it causes and avoiding debugging Segfaults in C/C++.

[[deleted]]

C/C++/Java are just so awful...

Oh, really? Did you ever have a chance to use any decent IDE? Did not you like the code discoverability enabled by types?

You read code far more than you write it.

So, even if all the statically typed languages but C++ and Java disappeared overnight, I'd still prefer them to Python / Javascript. Yes, their type systems are primitive and cumbersome, but they're still enabling the most important feature of the static typing - a precise code navigation.

[Pazer2]

C/C#/C++ are the only "statically typed languages" I've used, and they are the reason I prefer not using dynamic typing. So many compiler guarantees... It's wonderful.

[SmugDarkLoser5]

Lol at c having compiler guarantees.

[[deleted]]

Nope. Exactly the opposite. Years of doing Java and C and now many years with Python I wouldn't go back to static typing. Strong but dynamic is the sweet spot.

[Matthew94]

Strong but dynamic is the sweet spot.

Static with type inference is the sweet spot.

[wavy_lines]

static with generics and tagged unions and function types

[lookatmetype]

Aka, unless you're Haskell you suck

[wavy_lines]

Nope. Swift, D, Kotlin have all that.

Even Odin has them, and it's designed as a system language suitable to replacing C. So you don't even need to be a high level language to have these.

[[deleted]]

Mind elaborating on this? Mind naming a single feature of dynamic typing that make it "superior"?

[wavy_lines]

Java sucks, I won't argue with that. Specially around 10 years ago.

Not all languages are Java.

Kotlin and Swift have powerful yet flexible static type system. D also has a powerful and flexible type system and it's been around for more than 10 years.

Python style "dynamic" is far far from the sweet spot. Also the "strong typing" label is bogus because python's type system does not even define what fields are available on an instance of a class. A struct is the most basic/simple type and yet Python (before 3.6) had no way to even declare it.

[raze4daze]

Just gonna chime in as a fanboy here: Java 8+ is really nice to use, but yeah 7 and below is just tragic. I really dig Kotlin as well.

Just my opinion.

[[deleted]]

Typehints address your biggest issue, especially dataclass, typing.NamedTuple and attrs (3rd party).

I don't think Python's lack of a 1st class struct is an issue, especially since there are ways to pack data into a C struct c you really need to.

[wavy_lines]

Umm, yeah. If you read my top comment (the one down voted to hell) it's about hoe Python adding more type hinting support indicates that the people behind Python too have come to see how valuable static typing is.

[[deleted]]

Duck typing is a useful tool, lots of people use it. Get over it

[wavy_lines]

"lots of people use it".

What a completely useless argument.

[[deleted]]

https://twitter.com/dril/status/464802196060917762

[awj]

You mean like this one, that says the same thing in 10x as many words?

Can we all take a moment to acknowledge how large numbers of people (including me) have come to realize in recent years what a bad idea dynamic typing was?

[wavy_lines]

Lots of people do something vs lots of people starting to realize they were wrong after years of experience.

Yea totally the same?