The point of TypeScript is to add static typing to the language. And if you can't see the merits of this... well... I don't know what to tell you. I'm convinced that people who don't see the advantages of static typing never had to maintain other people's code.
Lack of types is also unhelpful. I'd rather a compiler tell me I'm trying to equate integers and giraffes than having to completely rely on a test harness that might not try to pass in a giraffe until the fifth hour of the testing process.
Python 3 has standardized type hints now. So a linter can yell at you if you try to equate integers to giraffes.
For example, I like 2 spaces for tabs for tighter indentation, but I can't do that in Python because the language designers decided that 4 spaces is exactly right for everyone. That type of thing shouldn't be inherent in the language design.
You can use however many spaces you want to indent with in Python, so as long as you are consistent. Unless you are one of those folks who indent using 4 spaces one minute, then 8, and then drop down to 2 just for the hell of it all within the same function, I can't see how this is that big of a deal.
What Python doesn't have is strong type enforcement. Unless you pre-compile the whole app, entire source files could be filled with monkey-typed gibberish and until the fateful day came that the defective modules were referenced (say, once a Leap Year), they'd be serpents in the grass.
Even pre-compiling won't help if there are insufficient cues to ensure that you won't be passing a dingus to a module that expects to use a wackdoodle.
Well the standard retort to that is "unit tests!!!11". It's like they think implementing something yourself what a compiler would do for you for free is supposed to be satisfactory. Eventually, your unit tests will need unit tests if we take this argument to it's logical conclusion.
The good news is that PEP484 gives Python3 "type hints" so that, theoretically, one could develop a tool that does exactly what a compiler does with respect to checking types. If I'm not mistaken, pylint already does this. Better late than never. I guess the "Unit Tests Will Solve Everything" crowd were wrong after all.
RemObjects makes a free Swift compiler that targets.NET, and thus the binaries would run on Windows. It targets Android too, so you can do Swift on Android as well.
Of course, none of the OSX/iOS frameworks are provided on non-Mac platforms. You're expected to to use the frameworks already provided by the platform you are targetting.
Personally, I only call myself a "Software Engineer"(tm) when I'm talking to non-programmers. If I'm talking to fellow programmers, I just call myself a programmer or a developer. Seems too pretentious otherwise.
For #6 (reinventing data structures), gimme a frickin' break - I will not pull in a 3rd party library just to implement a data structure I can write in my sleep. Fortunately, most languages include just about every standard type imaginable in their standard libraries; but hell will get pretty frosty before I resort to an external dependency for something like a boring ol' red/black tree.
Just curious, but are you saying here that if a language's standard library provides a data structure you need, you'd still implement it yourself or would you just use the one provided by the standard library? If the former, I personally wouldn't call using the one that comes with a language "3rd party". Also, in my experience, nobody really cares that you can implement data structure code from scratch every time except maybe other developers, and even in that case it's kind of iffy. They only care that you deliver a product on time, to spec, and relatively bug free. How you actually accomplish this is largely a don't-care.
Slashdot Mirror
The point of TypeScript is to add static typing to the language. And if you can't see the merits of this ... well ... I don't know what to tell you. I'm convinced that people who don't see the advantages of static typing never had to maintain other people's code.
Lack of types is also unhelpful. I'd rather a compiler tell me I'm trying to equate integers and giraffes than having to completely rely on a test harness that might not try to pass in a giraffe until the fifth hour of the testing process.
Python 3 has standardized type hints now. So a linter can yell at you if you try to equate integers to giraffes.
For example, I like 2 spaces for tabs for tighter indentation, but I can't do that in Python because the language designers decided that 4 spaces is exactly right for everyone. That type of thing shouldn't be inherent in the language design.
You can use however many spaces you want to indent with in Python, so as long as you are consistent. Unless you are one of those folks who indent using 4 spaces one minute, then 8, and then drop down to 2 just for the hell of it all within the same function, I can't see how this is that big of a deal.
What Python doesn't have is strong type enforcement. Unless you pre-compile the whole app, entire source files could be filled with monkey-typed gibberish and until the fateful day came that the defective modules were referenced (say, once a Leap Year), they'd be serpents in the grass.
Even pre-compiling won't help if there are insufficient cues to ensure that you won't be passing a dingus to a module that expects to use a wackdoodle.
Well the standard retort to that is "unit tests!!!11". It's like they think implementing something yourself what a compiler would do for you for free is supposed to be satisfactory. Eventually, your unit tests will need unit tests if we take this argument to it's logical conclusion.
The good news is that PEP484 gives Python3 "type hints" so that, theoretically, one could develop a tool that does exactly what a compiler does with respect to checking types. If I'm not mistaken, pylint already does this. Better late than never. I guess the "Unit Tests Will Solve Everything" crowd were wrong after all.
Anybody know how well this can be Hackintoshed?
RemObjects makes a free Swift compiler that targets .NET, and thus the binaries would run on Windows. It targets Android too, so you can do Swift on Android as well.
Of course, none of the OSX/iOS frameworks are provided on non-Mac platforms. You're expected to to use the frameworks already provided by the platform you are targetting.
Personally, I only call myself a "Software Engineer"(tm) when I'm talking to non-programmers. If I'm talking to fellow programmers, I just call myself a programmer or a developer. Seems too pretentious otherwise.
For #6 (reinventing data structures), gimme a frickin' break - I will not pull in a 3rd party library just to implement a data structure I can write in my sleep. Fortunately, most languages include just about every standard type imaginable in their standard libraries; but hell will get pretty frosty before I resort to an external dependency for something like a boring ol' red/black tree.
Just curious, but are you saying here that if a language's standard library provides a data structure you need, you'd still implement it yourself or would you just use the one provided by the standard library? If the former, I personally wouldn't call using the one that comes with a language "3rd party". Also, in my experience, nobody really cares that you can implement data structure code from scratch every time except maybe other developers, and even in that case it's kind of iffy. They only care that you deliver a product on time, to spec, and relatively bug free. How you actually accomplish this is largely a don't-care.