So is there any instance where a dynamically typed language is ever a good idea? It seems like a horrendous mess in Python.
No. Fuck dynamic typing.
>>52078625
Is there a good scripting language that doesn't use it though?
>>52078731
This. Fuck dynamic typing.
Using dynamic typing is saying "I know that this program works, but I can't explain why to the computer."
Static typing aids in refactoring, maintenance, defect prevention. Moreover, types are the only form of documentation that doesn't go out of date.
>>52078776
Haskell
https://hackage.haskell.org/package/turtle
>>52078625
Gradual typing
>>52078914
Agreed, but only in a disciplined and principled team, when there is a large pre-existing body of dynamically-typed code to be transitioned.
>>52078625
Pretty much never. Type inference is a good idea. For the JVM: https://kotlinlang.org
>>52078780
And of course statically typed programs can be optimized much, much better by compilers.
>>52081599
Mind if I ask why?
>>52078780
>Haskell
>a scripting language
>literally the furthest you can get away from scripting
I agree with your post when it comes to most projects, but this part is seriously the toppest of the keks.
Scripting is about getting the job done quick and dirty, and being able to quickly interact with the underlying system, this bash.
Haskell doesn't even have a concept of an implicit state (side effects). There IS NO system to interact with, neither within nor without the language.
Moreover even if Haskell did have, side effects, it's still an extremely academic language that places so much weight on correctness. Again, the opposite of scripting.
i like static and dynamic typing as long it's strong
Scripting, web dev and automation. Static typing gets beneficial for big projects, but if you have small applications you are usually aware of what kind of stuff you are sending around.
Imagine you are creating some MVC code that fetches objects from a database and puts them into an object for a templating engine to render. In a dynamic language just pack all the values you want to display into an object and pass it to your template. The static way of doing this would be to create a type or class just for this collection of things. Sure you could also create a map of "string" to "object" and then cast everything back once you use it, but its usually much more boilerplate and annoying while still not having the benefits of type safety.
We are currently going through some static typing trend where everyone considers non-static languages as shitty. Just give if a little bit of time and everyone will be back, writing blog posts like "why I'm back at using a dynamic language for task XY", cause he's annoyed by arguing with type systems when just wanting to get something done.
>>52078625
Yes, when you are writing a quick and small program. That's actually the purpose of languages like Python, Perl or Ruby.
Which of course got thrown away when Python became popular and people wanted to do all the tangs.
>>52082184
Most of the time it is just one object per table. I can't see why anyone could have something against that. I always forget everything so looking up easily that User has a string called Name (for instance) in the type declaration is great!
>>52078914
http://www.ccs.neu.edu/racket/pubs/popl16-tfgnvf.pdf
"Based on the results obtained in this study, the paper concludes that, given the state of current implementation technologies, sound gradual typing is dead."
>>52078625
Not really.
>>52078776
If you like Python use Cython. I started using it recently and I love it.
The problem is conflating "static vs dynamic" with "strong vs weak".
The horseshit you get in PHP and JavaScript is all forms of fucking atrocities. Ruby for example doesn't have those problems, despite being "dynamically typed".
>>52082265
That fact that a property name is a string should be inherent from its name. Dynamic languages like Python still allow you to declare classes and members.
Just don't do any stupid things and you can get small things done much faster and with less hassle in dynamic languages.
>>52078625
I prefer dynamic for one-dimensioned projects like data extraction and for getting into programming.
Static is usually the way to go as long as we live in the ideal world where coders implement techniques and the code quality is optimized. On the other hand, spaghetti code is more frequent and obvious because of bad programming
>>52078625
Static typing introduces overhead (specifying types and type abstractions) to the programmer that are non-existent or lessened in a dynamically-typed language, which saves development time. Literature shows that type errors are among the least likely type of error that are ever caught, so it make little sense to spend time building your type system if that is the case. especially when dynamically-types languages actually check the types at runtime. If you have a script that runs in a definite time and touches all code all type errors will be caught on the first run. This set of programs is actually very large. These programs don't benefit from static type checking. So it ends up a matter of cost.
Some would say there are use cases for it though. Working on a large application between many people where parts of the code might no be run for long periods of time or only under certain conditions, type checking is very useful for catching type errors in those sections that would only error when a dynamic language goes through the code. However this argument is faulty because many other types of errors can be lurking in those corners that a type system cannot help, so unit tests are still a necessity. There is no time saving in that case except for catching improperly specified interfaces with poor documentation which is a plague in the software development field.
To make the overhead of type specification easier and more robust, over the years academics have developed technologies (inheritance and polymorphism in OOP, type classes in many functional languages, etc.) which reduce the overhead. This makes development time quicker like dynamically-typed languages by removing some of the type specification or making it more restricted so more errors can be caught earlier. However this comes at the cost of the complexity of the compiler. Yes, it is a single cost, but the larger and more complex the application the cost increases exponentially.
>>type inference
>>52082791
Type inference is a technology where the programmer doesn't specify types (or only a little) and the compiler determines and checks types at compile time using predefined rules. This is very powerful and removes some of the overhead of statically typed languages. In many ways a computer is a lot better at checking things with a determined rule set than humans are. However type inference is expensive, but I think for statically typed languages it's the future because people realize that types get in the way a lot, but are still useful.
Additionally, dynamically typed languages with optional type system (Typescript, TypedLua, etc.) give the best of both worlds. The ease of developing without types, with the additional safety of types when necessary (working on a large application between many people). These could also be the future. But pure statically-typed languages, where the programmer is in charge of developing the type system are limited because they are inflexible and programmer time expensive.
tl:dr Programming in dynamically-typed is cheaper in terms of programmer time than statically-typed languages and 90% of the time type errors aren't a problem so you might as well use the cheaper to develop technology.
>>52082791
>>52082887
Dynamic typing has a severe overhead on the run-time cost. Gradual typing even more so, as explained in the paper posted above. So that makes it unsuitable for an entire class of problems.
>Static typing introduces overhead (specifying types and type abstractions) to the programmer that are non-existent or lessened in a dynamically-typed language, which saves development time.
Except you have to build the entire type abstraction in your head, without the help of a compiler.
>so unit tests are still a necessity
Nobody has said that unit tests are not necessary. We just don't need as many of them anymore.
> However this comes at the cost of the complexity of the compiler. Yes, it is a single cost, but the larger and more complex the application the cost increases exponentially.
The complexity of the compiler doesn't matter at all, as the alternative is to push the complexity on the developer. Also, you are overestimating how much complexity a static type system adds.
> However type inference is expensive
Most type inference is cheap in terms of compilation time, unless you go overboard with you type system (i.e. make it undecidable).
>>52082887
>>52082791
These are based on the assumptions that writing out types is somehow taxing on the programmer - it's not really, especially if there's inference - and that dynamic typing means you don't have to worry about types at all - untrue, since you still need to know what kind of objects you're working with, and consequently you'll know the correct types at all times, too
>>52083076
>Dynamic typing has a severe overhead on the run-time cost.
He's never heard of JITs.
>laughinggirls.png
>without the help of a compiler.
A compiler isn't a scratch pad, it doesn't help. It's only job is to check what you've done.
>We just don't need as many of them anymore.
You need one per input class still. So no, type systems don't reduce the number at all.
>The complexity of the compiler doesn't matter at all, as the alternative is to push the complexity on the developer.
Yes the compiler complexity matters. Someone still needs to write and maintain it. And you're right, the alternative is to make the programmer write boilerplate, or they could use a dynamically-typed language and only worry about types when it errors or is necessary to make type parametric code.
Any languages using duck typing+constraints system?
>>52078776
Ruby 3 is apparently going to be statically typed.
>>52082184
Your example only requires that the template engine be dynamically typed (or even typeless), not that the language that is used to invoke that template engine be dynamically typed.
>The static way of doing this would be to create a type or class just for this collection of things.
It's possible to have statically typed values within a hash, and just pass the hash while the value within it remain statically typed, you know.
>>52078776
PowerShell.
>>52083160
>writing out types is somehow taxing on the programmer - it's not really
Yeah, writing 'int' before variable declarations isn't hard. But you are missing the point. If it weren't for advances in type system technology, specifying object relations would be impossible or a complete pain. You are always at war with the type system until someone comes along and writes a better one. It's better these days, you mentioned type inference helping and I agree, but it was something that got in the way before it. For example, in C you can compare strings more quickly by casting the char* to a pointer of teh size of your machine word and comparing them. This keeps you from having to unpack words into each character while you check them. Any good type system would never allow this, but it allows for optimization. If I had to do this within the realm of strict type correctness I would have to specify a union to alias the two pointers (still technically a no-no because of alignment issues, but it's not against the standard and the compiler doesn't complain). The union type abstraction disappears at compile time. Writing the union (although in this example easy) takes up additional time. Now extend this to writing classes. There is overhead in writing type abstractions, especially if the compiler is fighting you, not helping you (writing object relations in C is difficult, hence OOP). In dynamic languages (not all) classes are objects, relations are made simply by keeping a pointer to the other object you want to refer to.
>>52083372
>For example, in C you can compare strings more quickly by casting the char* to a pointer of teh size of your machine word and comparing them
I guess you could do that, if you're an idiot who normally writes horrific and unportable code.
PROTIP: Your C libraries micro-optimised strcmp() implementation will blow your stupid "optimisation" out of the water.
>Any good type system would never allow this, but it allows for optimization
Why not? When you cast, you are literally telling the compiler "Hey I know what I'm doing here, I got this". It's an implicit instruction.
>If I had to do this within the realm of strict type correctness...
...but C *is* statically typed?
>>52078625
Prototyping.
>>52083424
>...but C *is* statically typed?
But not type correct.
>>52083172
>He's never heard of JITs.
Even the best JITs for static languages are more than an order of magnitude slower than compiled languages.
What do we think about Scala then?
I'm told its compiler is a hellhole.
>>52078625
It's a perfectly fine idea, people just don't understand it correctly.
In python, it's perfectly possible to check that things are of a particular type by using isinstance and friends, but it's far better to just check if the object you got does what you need. It lets you implement compatible types (that don't actually subclass that type) without introducing more cruft like Java's "interfaces" system.
>>52083719
I'll just say that sbt is known as satan's build tool and compiling 2KLOC takes a few minutes.
>>52083372
You can't do any of the said optimizations if your language has no concept of explicit types. Anyway, I don't think there's anything keeping a strong type system having conversions and pointers available. A strongly typed language wouln't allow C-like pointers, but it could still allow efficient conversion if the pointer points to an array of the right size
Static all the way, forces better programming practices
Fact of the matter is, statically typed code has significantly less bugs. Dynamic typing btfo
>>52083849
>code that can't do as much has less bugs
Wow!
>>52083902
>can't do as much
Like what? I'm genuinely curious.
>>52083927
Let's say an object foo has a method that returns something. Could be anything.
Now, on the official implementation of the object, it returns something of type "doohickey" with methods getnext() and stop().
So, someone writes code like this:
mydh = foo.getdoohickey()
in a statically typed, language it might look like:
doohickey mydh = foo.getdoohickey()
But what if someone creates their own implementation of foo, and it returns something that isn't of type doohickey or a subclass of such. But, it still has getnext() and stop(), so it can be used just as well as a real doohickey can.
So now, if the programming language is dynamically typed, we don't have to do anything. mydh = foo.getdoohickey() will still work perfectly fine, and mydh.getnext() and mydh.stop() will work as implemented in my custom version.
If we absolutely needed to check to make sure the user wasn't doing something boneheaded, we could specifically check that getnext and stop exist and that they are callable.
But if it's statically typed, we have 2 options:
1. Rather than "doohickey mydh", we could use "object mydh" or whatever our language calls the most generic object class possible. However, this only works if the language makes everything subclass from object. Something like Java, where you have both objects and primitives won't be able to do this. Plus, this defeats the purpose of static typing.
2. Use something like Java's "interfaces", where you can define an abstract sort-of-class that describes that something that implements that interface will provide. The problem is that this has to be done from the start. If the original code didn't define it as an interface from the get-go, we would have to go back and change that code. This isn't always possible. Plus there's no telling what someone might want to have defined as an interface, and it's not practical to make an interface for every little bit and piece.
>>52084049
Duck typing (structural typing) vs. nominal typing is a whole different can of worms from static vs. dynamic typing.
Even then, no, it's pretty much always possible to create an interface for those functions you need. All you do is define the interface, say the original class implements it, and change the type from the class to the interface where it's being used. Either it will just werk, or it won't work and neither would a program using duck typing instead.
>>52084215
>All you do is define the interface, say the original class implements it
But again, that requires you to be able to change the original class, which may or may not be a possibility depending on the situation.
>and change the type from the class to the interface where it's being used
Easier said than done if it's used quite a bit.
Ironically, through abstract base classes and that kind of stuff, Python might actually do nominal typing better than languages that only do nominal typing.
>>52084279
I guess, yeah, if the class is in a library you'd have to work around it with a wrapper class (Adapter in OO speak).
I do prefer structural typing, myself, with subtyping based on record types.
>>52078776
Yes.
C# with scriptcs.
Picture related.
>>52084279
>>52084413
Well, row polymorphism, because that plays well with inference. It's not strictly subtyping but it works to the same end with regard to duck typing.
>>52084049
This is a dangerous route. Methods with the same name might do completely different things in unrelated classes and in inherited classes your problem wouldn't exist.
>>52084840
Exactly. If foo is written to return doohickey, shouldn't any class implementing it also return a doohickey, just as it says? Asking for a doohickey and then getting something completely arbitrary back is questionable at best. If dohickey was meant to be more general, it should have been an interface from the start, if you can't change it, write an interface + adapter class that uses the official implementation and returns an interface, but don't mess with the original foo.
>>52078776
Yes.
AngelScript, Mond & Pike.
A lot have it optional, like Perl6, Haxe, Quore, TypeScript, Dart...
>>52078776
Just use a rapid application language, like Crystal, Nim or Swift.
They are mostly like scripting languages these days.
ITT: people confusing static typing with Java and dynamic typing with Python
This is strong, static typing.newtype Base64 a = Base64 ByteString deriving (Eq, Show, Encryptable)
newtype Encrypted a = Encrypted ByteString deriving (Eq, Show, ToBase64)
class Encryptable a where
encrypt :: a -> IO (Encrypted a)
decrypt :: Encrypted a -> IO a
instance Encryptable ByteString where
encrypt msg = do
res <- PKCS.encrypt publicKey msg
case res of
Right encMsg -> return (Encrypted encMsg)
Left err -> throwM (CryptoError err)
decrypt (Encrypted encMsg) = do
let res = PKCS.decrypt Nothing privateKey encMsg
case res of
Right msg -> return msg
Left err -> throwM (CryptoError err)
instance Encryptable Text where
encrypt = fmap coerce . encrypt . encodeUtf8
decrypt = fmap decodeUtf8 . decrypt . coerce
class ToBase64 a where
toBase64 :: a -> Base64 a
fromBase64 :: Base64 a -> IO a
instance ToBase64 ByteString where
toBase64 = Base64 . B64.encode
fromBase64 = either (throwM . Base64Error) return . B64.decode . getBase64
instance ToBase64 Text where
toBase64 = coerce . toBase64 . encodeUtf8
fromBase64 = fmap decodeUtf8 . fromBase64 . coerce
With stuff like this, you can distinguish anEncrypted SigningKeyfrom anEncrypted Messageeven if both are the same thing. You can't decrypt aBase64 (Encrypted Message)either until you've base64-decoded it. This comes at zero runtime cost while significantly increasing safety.
>>52084937
>If dohickey was meant to be more general, it should have been an interface from the start
But who decides what should be general or specific?
If I implement something that is 100% compatible with something else, it shouldn't matter if it was an interface, and it shouldn't require any rewriting of the original code.
Static typing gets in the way of duck typing which is extremely useful in many situations.
>Asking for a doohickey and then getting something completely arbitrary back is questionable at best
Says who?
It's like if you ask me to give you a file on a USB flash drive, and I give it to you on a USB hard drive instead. You don't care how you got the file, you just care that you got it and it works over USB.
>>52084049
Yeah, that's not the kind of thing that should happen in good code. Just cast it or make both a child of a parent class or something. Other repliers are right.
>>52088867
It would only be "bad code" if everything was part of one project.
If someone else made all that stuff, but then I wanted to extend it with my custom class, I would have to modify the original (messy and then I have to maintain my fork of it when the original updates).
Gradual typing is best typing.
>>52081976
>Scripting is about getting the job done quick and dirty
Not necessarily. If you can get it done quickly, there's no requirement that it be dirty. Several scripts that need to work properly are written in Haskell at my workplace.
>Haskell doesn't even have a concept of an implicit state (side effects)
The benefit of Haskell for scripting is unlike almost all other programming languages, that it has IO actions as first-class values, allowing me to manipulate them.
>>52082023
Are there any dynamic & strong scripting languages?
>>52078625
Lisp
/thread
>2026-11
>falling for the dynamic typing meme
with the new optional python typing scheme it's the best of both worlds
you can add typing for large programs where it's necessary to have
and you can leave it out for simple quick and dirty scripts
>>52090836
python is strongly typed you fuck knuckle
it's just dynamically typed as well
>>52090915
python sucks
>>52090898
>with the new optional python typing scheme
Explain
>>52090836
Wren
Variables are for faggots. Name a single good lang that utilizes variables instead of pointers and registers.
Protip: you can't.
>C is outdated bullshit that nobody in their right minds would program in, considering the convoluted mess that it is
>C++ is slightly better, but it's auto mem management completely fucks it over
Basically if you program in anything but Brainfuck and Assembly, you are fucking stupid, your career is going nowhere and you will die alone and miserable you piece of shit. Stay mad.
>>52091313
>im a tryhard javashit coder
>>52082339
> Ruby for example doesn't have those problems, despite being "dynamically typed".
OHH WOW. I'm Ruby fan but I've never realized I never get the same problem with types in Ruby I get with Javascript. Why doesn't?
Could you (or someone) elaborate this?
>>52081976
He just posted a link to a library that gives you quick and clean scripting support.
>Haskell doesn't even have a concept of an implicit state (side effects)
Not sure what you mean by this, but it has "explicit" states in the sense that the types explicitly state which functions are stateful and which functions have side-effects.
>There IS NO system to interact with, neither within nor without the language.
Wat.
>if Haskell did have, side effects
It does, but only at the top level.
>extremely academic language that places so much weight on correctness
You can write essentially the same code as in other functional languages and let the type checker infer all the types for you (provided you don't use any of the wacky experimental extensions, which is what people usually refer to when they say it's academic). One of the main driving goals of Haskell has always been to make it approachable to new users, and one of the manifestations of this idea is to optionally make the type system transparent to the user. Though explicitly stating the types here and there helps guide you when writing code. And the type system literally never forbids you from writing anything except programs that are obviously incorrect. Types are an aid, not a hindrance.
That said, I don't really like Turtle for purely aesthetic reasons, so I wouldn't write any actual script in Haskell. Your preferences may vary, though.
How is that true about memory in c++? Unless he means .net, c++ isn't garbage collected. Constructors and destructors have a direct C implementation, and if you want a heap object for your class you still have to call new and delete... and new/delete is just a wrapper for the old c api.
>>52084279
The problems you're describing are only existent in OOP languages. There are other ways to do types, which avoid this.
>>52083256
D when writing template code.
>>52090898
I thought the consensus was that it was awful
>Awkward as hell syntax to maintain compatibility
>Does nothing other than help IDEs
ITT: Nobody knows the difference between dynamic strong and dynamic weak typing
>>52078625
No it's completely pointless. It doesn't even save time.
>>52078625
ITT
> People arguing over what languages are good or bad based on whether statically/dynamically strongly/weakly typed
> Not realizing programming languages are tools to get sh*t done, rather than the ends themselves (unless of course, you're an impractical academic retard who studies language for the sake of language itself)
Each language has a use case, and a reason for choosing its typing. If you think you can create a "better" language to serve your needs, you're welcome to write your own.
>>52078625
New version of Python comes with optional typing
>>52093473
Python 2.8?
>>52093657
4.4 I think
>>52094404
So Guido's breaking backwards compatibility again? Will I have to install 3 python interpreters?
>>52091451
>I don't actually read posts
Duck typing.
>>52078625
its true anon, dynamic typing is crippling
but fyi, if you ever seem autists bitching about "oh my parametric polymorphism", "my generics".
Dynamic typing is generic by nature. I don't have a static type check on the argument past. I can react based on the isinstance of the object.
As you scale up, you'll find yourself adding a lot of checks to assure your dynamic, lazy code reacts correctly.
Dynamic typing sucks because not every function you write is going to be generic abstractions. You're going to be writing a lot of code that is pretty much geared toward a narrow use case. Dynamic programming makes it harder to spec out things as your codebase grows bigger.
I pydoc the fuck out things and document param types. It's not always enough.
>>52078780
https://storify.com/realtalktech
>>52093473
3.5 has type hinting
it's not compile time type checking really.
no one's using python 3
>>52082184
This so much.
>receive a JSON object from the network
>either have to defeat the purpose of static typing by mapping it to Object's, or have to define a class for every nested JSON object
Yeah, fuck that.
>>52083771
>In python, ... , but it's far better to just check if the object you got does what you need.
>It lets you implement compatible types (that don't actually subclass that type) without introducing more cruft like Java's "interfaces" system.
Python Programmers.
>>52090898
They are unenforced type annotations, basically comments. They don't do anything.
>>52091111
Because quads.
> ... no type checking happens at runtime . Instead, the proposal assumes the existence of a separate off-line type checker which users can run over their source code voluntarily. Essentially, such a type checker acts as a very powerful linter.
>https://www.python.org/dev/peps/pep-0484/
