I have written code in untyped languages all my life and it has never been a problem for me.
The only problem I see with bigger JavaScript apps is the callback-hell.
Funny thing is, most to-JavaScript languages focus on the type aspect.
If I could write linear asynchronous code everything would be much more readable after coming back to some code a few months later.
The big one for me is inheriting other people's code bases, in dynamic languages they're a complete and utter nightmare, especially when written by incompetent programmers, which seems to make up a worryingly large number of programmers. Or someone just learning and not aware of conventions.
You just can't assume a method or function actually does what it says it does. Or returns what it says it does. And you can't even see what it's expecting or what things are being passed to it. You have to fine-toothcomb the method, it slows you down massively.
I have worked on a fair few bad code bases now and luckily for me the majority of that's been in static languages. It makes it so much easier.
Some of the other advantages of static typing include:
1. having incredibly good auto code completion
2. never having to remember or look up a method signature
3. to refactor massive chunks of code almost completely fearlessly
4. to fix crap code without any fear of breaking anything else
5. as long as you name your methods well, never having to annotate anything mundane (depending on your audience ofc)
There are also other things like that tend to go hand-in-hand because they're usually explicit, like not worrying about implicit conversion (apart from VB with option explicit off).
I've used both quite a lot over the last 10 odd years professionally programming and I've recently been thinking that I would actually prefer a mix, static typing on boundaries like method entry and new object declartion and dynamic everywhere else. I know little about compiler or language design, so I'm not sure it's even possible. C# kinda gets close with the var keyword, but the various disadvantages of static typing still rear their head quite a lot.
As a slight aside, People on HN always seem to talk as if they only write new programs, not maintain old ones. Am I the weird one for frequently having to pick up code that was written by someone else? Who often had coded themselves into a corner and then made up some excuse as to why they couldn't keep the client anymore?
When using libraries, their functions always wanted their arguments to be some strange classes or implement some of their interfaces, which always seemed like big overhead to me.
Stuff like Smalltalk, PHP and JavaScript felt much faster in development speed.
I've never used Smalltalk, but the other two you mention suffer from massive problems when you get to a certain size codebase.
I'm extremely wary of saying this, but I generally think that uni professors/tutors can't program. Basically unless they've written a large open source program or actually worked in the industry for a lot of years, they're probably going to be useless programmers. And even then, there's a good chance they're useless programmers.
That may be a slightly old fashioned view, but most lectures I've seen from unis online tend to completely miss the point of basic concepts (OO being the most common one). And it's rare to meet graduate CS who can actually program anything on their own from scratch. Google's fine, but cut & pasting code you don't understand and changing random stuff as it sounds kinda right, that's not programming, that's a bloody rain dance.
Programming is a skill that needs years of work before you're even vaguely good. And the worst part is you're almost constantly suffering from the Dunning-Kruger effect, thinking you're much, much better than you actually are. I probably still am.
It's one of the reasons we see security holes time and time again, novices don't even realise the problem exists!
For example, I have no idea what to do with crash dump in windbg. I wouldn't even know where to start. Is that a massive knowledge gap? But give me a stack trace of a problem & the source in almost any web language and I'd probably be able to fix it, even if I've never used the programming language before.
But I have to say, my programming prof. was rather fond of Java. Biggest part of the lecture on OOP was about type systems (and I hated it lol).
Most of the stuff I learned about programming, I didn't learn in university, but at work.
But since my experience with Java at university was so bad, I searched for jobs in different languages, like JavaScript.
A few years ago I tried to learn Scala, because it seemed like a better Java to me. But somehow I never got along with it. The type-system seemed logical, but it had so much other stuff around that made starting rather difficult, so I went back to JavaScript.
IMO, this is one of the major issue of javascript.
IMO, real advantages of dynamic typing vs static typing are
* Simplicity. You don't need to learn a complex type system to start coding.
* Flexibility. Dynamic type systems don't stop you from doing useful things ike polymorphism and generics. In a static type system those need to be build in from day 1.
And having to build more advanced type system features on top of a simpler type system is hardly a good thing either - type theory is not trivial and chances that you will get it wrong are large. Even experts in the field make wrong decisions, for example array covariance in Java an C#. And even if you get it right you will usually not enjoy (all) the benefits of compile time type checking and fail only at runtime.
It felt like even the implementers of those type-systems didn't get it right.
The specified classes for arguments is a good thing since you dont have to dig through piles of documentation or code review every method you use to understand their behavior.
What do you expect the arguments of the following function to be: 1. A file descriptor, or 2. A path to a file that will be opened by the function?
def print_log(file): ...
One could argue it's bad naming convention but i see shit like this way too often to think it can be solved by conventions. Documenting doesn't work either for the same reason, documentation becomes more boilerplate than specifying types in a type safe language btw.
Contrast this with the C# equivalent
void PrintLog(File file) { ... }
Bang!, You instantly know that the file parameter is a File-object and you can focus your mind on more important things.
In basic ruby ,unless you mess with classes, [1,2]+1 WILL fail , though ruby is not staticaly typed. Ruby is STRONGLY typed, and that's a great thing.
Javascript will do everything it can not to fail:
String([1,2]) => "1,2"
+ 1 => "1,21"
That's madness,because Javascript is basically making a decision for you.That was acceptable in 1995, that is not in 2013.
And that's its biggest flaw.Writing javascript means working against the language.
But there is a reason for that. Javascript is not good at throwing errors or handling them, at all.
So it's not about static vs dynamic typing.
There is no good solution for that problem unless TC39 decides to fix it. Enforcing dependency injection concepts and duck typing might work, but not always. For instance, you could check if a string is a string with
function(x){
x=x.substr(); // will throw a TypeError if I pass an Array.
}
Good static typing saves you about half the units tests. And you don't even have to worry too much about that `half' being correct, because the type machinery in your compiler has been checked by thousands of people before. Whereas your tests are normally written from scratch.
Types also make your testing life much easier. QuickCheck is about the gold standard in rules based testing, and QuickCheck in a type-inferred language is just so much less verbose than when you have to either manually add all type annotiations or have to go without types. (That's mostly because Haskell allows overloading by return type.)
So you can do stuff like this:
callToRemoteApi().then(processData)
.then(makeAnotherCallToAnotherApi)
.then(processAllTheData)Although with generators you "can use normal control flow constructs". Except in most cases you probably use map or forEach instead of loops anyway. And try-catch is really broken.