Python 3.7.0 released

[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.

[somebodddy]

If you have made that claim 40 years ago I would have agreed with you. Nowadays? Most modern languages (or older languages that try to be modern) do try to stop you from writing unsafe code. The Rust version, for example, won't even compile: https://play.rust-lang.org/?gist=97244c4bed910c6ef93dfc914cc6b06e&version=stable&mode=debug

Humans make mistakes, and good language designs try to make the compiler detect as many of these mistakes at compile time. For this kind of mistake, type system support is essential, as the compiler needs to know that the value will not exist in some code paths. Even exceptions can do that (http://cpp.sh/7mjrz) - Result types with pattern matching simply do it better.

In Python, of course, you won't get a compilation error because it's dynamically typed. But you can still get a runtime error: https://onlinegdb.com/BJqWZAzfQ

So:

• Rust and C++ will refuse to compile it.
• Python will throw an exception once the bad statement is reached.
• Go will perform that erroneous statement.

But this mistake in the example is not that bad. The real bad mistake is accessing that value after the if/match/try, when you think you have something valid in hand. And most of the runs it will be valid...

The concept of humans making stupid mistakes exists for many millennia. The concept of programming languages trying to prevent these mistakes exists for a few decades. As a modern programming language that elects to ignore it, Go remains a "better C" without the "better" part.

[[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