Stack Overflow Explores Why Developers Love TypeScript More Than Python (stackoverflow.blog) 93
Stack Overflow asked 65,000 programmers for their favorite programming language, and this year Microsoft's TypeScript knocked Python from the #2 spot. So they interviewed Microsoft's principal engineering lead for the language "to find out what about TypeScript makes it so dang lovable."
Q: Do you remember why the team came up with TypeScript, why you wanted to release something like this?
A: When I joined the team, there were a lot of people at Microsoft who wanted to develop JavaScript at what we call "application scale." Teams like TFS and Office wanted to build large JavaScript applications. A lot of those people had familiarity with statically-typed languages — C++, C#, Java, that kind of thing. They wanted to have that static typing available both for conceptual scalability and for the tooling...
Q: Was there a point where you saw an adoption point of no return? Was there something that came along where people were like, oh, yeah, we do TypeScript now?
A: Oh, it was definitely Google announcing that they were going to use TypeScript with Angular. That's kind of lost to time now. But if you look at the graphs for TypeScript, literally any graph — GitHub stars, downloads, pull requests — you can see the exact point when that Angular announcement came out. And the graph just changes. It never looks back... TypeScript shores up that last rough edge on JavaScript and gives you something that's just really fun to work with and runs everywhere. I think if TypeScript were a language that was built on top of a less universal language or a less fun language, I don't think it would be as successful. It's really taking something that's great and making it better...
I think my favorite thing that I see is people on the Internet saying, 'I did this huge refactoring in TypeScript and I was refactoring for three hours. And then I ran my code and it worked the first time.' In a dynamic language, that would just never, ever happen....
I would just say to people, if static types aren't a good fit for you, for either your programming style or the problem you're working on, just skip it. That's fine. It's okay. I won't be offended. If someone can get a thirty thousand line application that gets its job done without static types, I'm very impressed. That just seems really difficult. But kudos to those people who make it work. Python's the same way. Very few people have working Python type annotations, but Python is incredibly popular. I think the data speaks for itself — I think Python is number three in the survey... I guarantee you that a very small proportion of those Python developers have static types. Whatever your problem domain is, that might be the best fit for you.
A: When I joined the team, there were a lot of people at Microsoft who wanted to develop JavaScript at what we call "application scale." Teams like TFS and Office wanted to build large JavaScript applications. A lot of those people had familiarity with statically-typed languages — C++, C#, Java, that kind of thing. They wanted to have that static typing available both for conceptual scalability and for the tooling...
Q: Was there a point where you saw an adoption point of no return? Was there something that came along where people were like, oh, yeah, we do TypeScript now?
A: Oh, it was definitely Google announcing that they were going to use TypeScript with Angular. That's kind of lost to time now. But if you look at the graphs for TypeScript, literally any graph — GitHub stars, downloads, pull requests — you can see the exact point when that Angular announcement came out. And the graph just changes. It never looks back... TypeScript shores up that last rough edge on JavaScript and gives you something that's just really fun to work with and runs everywhere. I think if TypeScript were a language that was built on top of a less universal language or a less fun language, I don't think it would be as successful. It's really taking something that's great and making it better...
I think my favorite thing that I see is people on the Internet saying, 'I did this huge refactoring in TypeScript and I was refactoring for three hours. And then I ran my code and it worked the first time.' In a dynamic language, that would just never, ever happen....
I would just say to people, if static types aren't a good fit for you, for either your programming style or the problem you're working on, just skip it. That's fine. It's okay. I won't be offended. If someone can get a thirty thousand line application that gets its job done without static types, I'm very impressed. That just seems really difficult. But kudos to those people who make it work. Python's the same way. Very few people have working Python type annotations, but Python is incredibly popular. I think the data speaks for itself — I think Python is number three in the survey... I guarantee you that a very small proportion of those Python developers have static types. Whatever your problem domain is, that might be the best fit for you.
Why? (Score:1)
No stack overflow.
yeah ... (Score:1, Informative)
'I did this huge refactoring in TypeScript and I was refactoring for three hours. And then I ran my code and it worked the first time.' In a dynamic language, that would just never, ever happen....
that's simply because you don't refactor often/soon enough.
which is gross because refactoring is one of the fundamental pillars of the agile snake oil, often the most ignored.
ts is just the current fad.
Re: (Score:2)
Re: (Score:3)
that's simply because you don't refactor often/soon enough.
Refactoring too often is a code smell.
Re: (Score:2)
Refactoring too often is a code smell.
what does that even mean? :p
i could answer that refactoring too late is neglect. tfs describes a 3 hour long refactor ... considering it's a pretty automatic process with, say, vs-code and typescript. that's A LOT of refactor in one go, or the guy was dealing with quite crappy code to begin with (static and all) or watching netflix while at it.
refactoring can also be an integral part of everyday coding as in: write test, make it fail, code for it to pass, refactor. which is imo a quite sound approach in som
Re: (Score:2)
Re: (Score:2)
that last statement is too generic to be useful for me, but i guess i get the idea.
there are many reasons to refactor. adapting to a new requirement is just one of them. code has a purpose, which is to meet requirements. how flexible will you be for any requirement that can come along out of the blue? what if it isn't a new requirement, but a change in an old one? how would you prepare for that?
refactoring can also be the simple process of revisiting your design and approach to make your code more solid, mo
Re: (Score:2)
Re: (Score:3)
you do have a point there. i've been lucky enough to be in some really pioneering projects but it definitely isn't the norm, let alone in the broad sector. i've had my more than fair share of boring stuff too.
all in all, this was mostly me ranting about your first assessment ('too much refactoring is a code smell') sounding quite like dogmatic, but i realize now my initial statement could be seen that way as well. i guess the truth is somewhere in-between, and depends on the circumstances.
and i've no idea w
Re: (Score:2)
it means you've got no design and you are in hack-shit-together hell.
If you didn't have those automated unit tests, you simply wouldn't be able to make anything work at all. It'd be an amateur hour bodge of useless awfullness that even the bad code on DailyWTF would laugh at.
In a system that you knew what was going on, and knew the vision and design for what you were building, you simply don't need to refactor. Its the way we wrote code decades ago, and it worked very well, assuming you actually thought abo
Re: (Score:2)
Also a developer smell. Is the developer actually being productive, or just doing a lot of busy work that disguises the inability to get stuff done? "Sorry honey, I can't mow the lawn this week, I'm too busy researching new lawn mowers!"
We don't, this is marketing BS. (Score:5, Insightful)
We hate typescript and the only reason Typescript even exists is because JavaScript is so badly designed. Nobody I know likes it, and everybody I know would rather be using python.
Re: (Score:2, Informative)
I love typescript and hate python, I work with dozens of people that feel the same way
Python in a webbrowser (Score:2)
and everybody I know would rather be using python.
You mean, like this [github.com] ?
(Mozilla's project [mozilla.org] to port the python interpreter to web assembly).
There are other similar ideas [almarklein.org].
Why would you want to use javascript server side? (Score:5, Insightful)
Really, why? It's not designed for it and it's not really up to it. Unless all you've got is javascript webdevs so it's a hammer and everything is a nail scenario.
Re: (Score:3)
I used to think this then I needed to implement a server for my Angular app that implemented authentication. My choices were Java or Node.js.
I could not believe how easy it was and how few lines of code it took. And how easy it was deploy. And I used Typescript instead of plain ECMAscript.
I know how to do this all in Java running with the Jersey framework but it is a fair amount of labor. And I have to host it in some container like Tomcat or Glassfish. And configure all that and ... you get the
Re: (Score:1)
Just because getting punched in the gut is less painful than being kicked in the nuts that doesn't make getting punched in the gut "all win".
Re: (Score:2)
Re:Why would you want to use javascript server sid (Score:4, Funny)
Hence you should always use Erlang!
Re:Why would you want to use javascript server sid (Score:4, Interesting)
"docker"
"tiny"
someone has drunk the kool-aid without understanding what the hell actually happens in a computer. I expect they also deploy these "tiny containers" to a cloud that charges by the CPU second.
Re:Why would you want to use javascript server sid (Score:4, Informative)
My choices were Java or Node.js.
You'd be better off in Java in anything but write-once toy apps. Java is harder in the initial setup (much less than it used to be) but for everything else Node backend is worse. Refactoring, security, stability, scaleability, backwards compatibility: Java wins in all those categories.
And if you're going after quick write-once toy apps, Ruby on Rails will do better for you than Node.
Easy answer: (Score:2)
Because there is a solid and strong advantage in using the same programming language on the client and the server side.
Typescript - it's the new Rust! (Score:5, Funny)
Throw out that crufty old Rust code boyes, time to shift all code to TypeScript!
Python needs to give a syntax for explicit nesting (Score:2, Insightful)
Re: (Score:2)
Semantic whitespace is a stupid idea and there needs to be a syntactic alternative that makes the nesting explicit.
No need to post that Anon on Slashdot, where many share that exact opinion.
The only place semantic whitespace made sense was on punch cards.
Re: (Score:2)
Are you kidding? WHITEspace? Why did he have to bring his racist ideology here?
/sarc
Re:Python needs to give a syntax for explicit nest (Score:4, Funny)
Tab Lines Matter!
Re: (Score:2)
Re:Python needs to give a syntax for explicit nest (Score:4, Insightful)
Technically, "semantic whitespace" exists in all modern programming languages, it's just a question of who it is semantic for. It's used by humans as the *first* and *strongest* indicator of the structure of the program. Secondary to that are e.g. the curly braces, and yet in those languages those are of course the official structure delimiters.
Python's stance is basically "it's odd to have one thing that is the primary way humans tell structure at a glance and a separate thing that is the official way to define structure, and since code is read more often than it is written, let's choose the one that favors humans". You may not like the idea, but it's far from stupid, and lots of people really, really like it. (if you don't want to use Python, more power to you, but you can come up with much better reasons than this one)
An enlightening experiment is to watch a few dozen people whiteboard pseudocode and note how many use curly braces plus indentation, how many use just braces, and how many use just indentation, and then think through the implications of what you observe.
Re:Python needs to give a syntax for explicit nest (Score:5, Informative)
Python's stance is basically "it's odd to have one thing that is the primary way humans tell structure at a glance and a separate thing that is the official way to define structure, and since code is read more often than it is written, let's choose the one that favors humans".
That's nice, but as easy as it is to screw up existing indention, white-space block delimiters are a potential problem with no easy fix. At least with other languages, the editor (especially ones like Emacs) can easily re-indent all the code with a keystroke. Remove or alter all/some the leading white space from a Python script and you'll have to fix most of it manually.
This "feature" exists solely because the language developer thought it was elegant, and it is, to some extent, but it's completely unnecessary and offers no actual benefit. Code using braces is just as readable. I'd have no problem with Python if this was optional and braces (or another printable character) were simply allowed for block delimiting.
Re: (Score:2)
This "feature" exists solely because the language developer thought it was elegant, and it is, to some extent, but it's completely unnecessary and offers no actual benefit. Code using braces is just as readable. I'd have no problem with Python if this was optional and braces (or another printable character) were simply allowed for block delimiting.
Bingo. This times 1000.
Guido van Rossum's prissy aversion to whitespace was an affectation that became a "feature".
Re: (Score:1)
> Guido van Rossum's prissy aversion to whitespace was an affectation that became a "feature".
What do you mean 'aversion'? He elevated whitespace to the rank of syntax!
Re:Python needs to give a syntax for explicit nest (Score:5, Interesting)
That's nice, but as easy as it is to screw up existing indention, white-space block delimiters are a potential problem with no easy fix
To some extent I agree, but in reality the typical operations on indentation aren't ones that result in this being an issue, e.g. increasing or decreasing the indentation on a block of code, and less commonly converting between tabs and space or changing the number of spaces used for indentation - all things that are simple to do without introducing error. Changing indentation on a block of code is an incredibly common operation, and pretty much never results in problems.
This "feature" exists solely because the language developer thought it was elegant, and it is, to some extent, but it's completely unnecessary and offers no actual benefit
The language designer did think it was elegant, but included it because it improves readability (this and several other features of Python came from it's predecessor - ABC - in which they did a few studies to see what effect this had on readability, and they kept it because it improved readability and also reduced variability, which in turn further improves readability.
Not only does it also result in slightly higher vertical efficiency in terms of how much code cleanly fits on the screen, it sidesteps the debate of where the opening curly brace lives (a major driver for needing the "reformat my entire file" feature in the first place).
There are other (minor) benefits beyond these - the braces are superfluous, you can't have the error where somebody puts a semicolon on the end of an 'if' or 'while' line, you can't have the error where a line is indented to include it in single-line body, etc. (most IDEs/editors these days help you avoid these, so that's why these are more minor benefits).
Code using both indentation and braces is just as readable
FTFY; it's the indentation that primarily impacts readability, braces alone doesn't come close, and braces offer a subjective or at best incremental increase of readability (though they cost some in terms of vertical space, so arguably still a net negative).
I'd have no problem with Python if this was optional and braces (or another printable character) were simply allowed for block delimiting.
Actually, you can do that today. Somebody once (jokingly, at first) pointed out that you can do e.g. #{ and #} delimiters to your heart's content, and somebody ran with the idea more seriously even went and made a linter for it, and then you could do all of the reformat-this-file-with-a-single-keystroke type of stuff you want.
The reason why stuff like this never catches on for real, though, is because it's simply not needed. I constantly move back and forth between C/C++, Javascript, and Python and have done so on a daily basis for about 20 years now, and before that a decade or so of C/C++. Prior to using Python, the braces were just a thing you did and I didn't give it much thought; once I started using Python a lot I realized they don't actually help much. Not once - not a single time in these 20 years - have I run into a case where I just wish I had braces in Python. Interesting though, is that the opposite is true: pretty much every time I do work in those other languages, I'm constantly reminded that I'm doing work because the language needs it and not because it provides me, the programmer, any real net benefit.
Obviously some of this is subjective, but I've done major projects in various languages and while Python has some things that bug me, I keep using it for practical reasons: even though there are some languages I've used longer, my productivity in Python ends up being significantly higher, the code has fewer bugs, it's easier to refactor, it seems to gather dust more slowly (i.e. coming back to old code after a long time, I find that getting my bearings is faster), it's easier to test code, the distance between idea/ps
Re: (Score:3)
Code using both indentation and braces is just as readable
FTFY; it's the indentation that primarily impacts readability, braces alone doesn't come close, and braces offer a subjective or at best incremental increase of readability (though they cost some in terms of vertical space, so arguably still a net negative).
Using both indentation and braces was implied -- literally *no one* uses braces alone, ever. I'm sure you know that. The rest of your dissertation is nice, but offers no convincing practical argument that white-space block delineation is superior to using something like a brace. The former is inferior as it literally provides less information and protection than the latter. It's as simple as that. All other arguments are secondary.
I also am skeptical that you are more productive and your code has fewe
Re: (Score:3)
Code using both indentation and braces is just as readable
FTFY; it's the indentation that primarily impacts readability, braces alone doesn't come close, and braces offer a subjective or at best incremental increase of readability (though they cost some in terms of vertical space, so arguably still a net negative).
Using both indentation and braces was implied -- literally *no one* uses braces alone, ever. I'm sure you know that. The rest of your dissertation is nice, but offers no convincing practical argument that white-space block delineation is superior to using something like a brace
Yes, increased readability, less variability, vertical efficiency, a few less common bugs that can't exist, a smaller gap between pseudocode and working code, and decades of experience using both and finding one way to be a win and the other to be just busy work are all practical reasons, but you're right that you are free to not find them convincing, and of course I really don't care all that much if some random internet person agrees or not. I took the time to respond only because it has provided actual v
Re: (Score:2)
Using both indentation and braces was implied -- literally *no one* uses braces alone, ever. I'm sure you know that
Doesn't this kind of make his point though? If you always indent then there is no need for braces.
Re: (Score:2)
Not once - not a single time in these 20 years - have I run into a case where I just wish I had braces in Python.
Oh, I do, even though I generally like indentation for block delimiting for long-living code. If I want to experiment in the console, one-line definitions of functions and classes would come in handy.
This won't work, and leaving out the braces won't work either.
Re: (Score:2)
Re: (Score:2)
#1 is a solved problem in so many ways (Python already warns on inconsistent mixing of tabs and spaces, so typically it's a file-wide concern and is either handled automatically by the editor or by e.g. coding conventions). It's far more of a problem in theory than in practice.
#2 Can definitely be a problem, sure (although if you're transferring data thru a medium that is allowed to alter the data it's transmitting, I'm not sure that's the data's fault).
All language features have tradeoffs - for me, these a
Re: (Score:2)
An enlightening experiment is to watch a few dozen people whiteboard pseudocode and note how many use curly braces plus indentation, how many use just braces, and how many use just indentation, and then think through the implications of what you observe.
Pseudo code and actual code aren't the same thing and conflating them is a mistake. Take that pseudo code you just mentioned and remove all the leading white-space and watch those people have to re-figure out how to re-indent it. Not something I'd like to have to do with actual code. Now do the same thing with brace-delimited pseudo/actual code -- much easier.
Pseudo code is meant for sketching out concepts and ideas. It may be nice, especially for inexperienced programmers, to have that code closely rel
Re: (Score:2, Interesting)
> semantic whitespace" exists in all modern programming languages, it's just a question of who it is semantic for
In most languages whitespace serves TWO purposes:
1. READABILITY for humans; i.e. IMPLICIT structure as you mention, and
2. To separate tokens for the parser.
It does NOT change the semantics of the REST of the non-whitespace.
i.e.
If you indent with 2 or 4 spaces or N spaces the program FUNCTIONS the SAME. It is up to the programmer to decide the block structure -- NOT the compiler.
In Python whit
Re: (Score:2)
Obviously the only whitespace we're talking about is that used for indentation, so your example of the a= and b= lines doesn't make sense.
And no, the fact that many people like the way Python does it isn't a fallacy. The point was simply that many people have used it for a long time and found out that it works really, really well in practice - it's less clutter, it doesn't actually create problems, etc. If you're not in that boat, that's fine, move on.
Re: (Score:2)
Did you miss the word analogy ?
The example of glBegin() and glEnd() shows there are legitimate reasons to indent code.
You write code for other people NOT the compiler / interpreter.
Re: (Score:2)
Technically, "semantic whitespace" exists in all modern programming languages
Like COBOL 2014.
Re: (Score:2)
Semantic whitespace is a stupid idea and there needs to be a syntactic alternative that makes the nesting explicit. (Posted anonymously because you guys are religious freaks.)
I suppose one could create a syntactic superset language of python that uses squiggly brackets for code blocks that compiles down to whitespace delimited python - squigglethon.
Re: (Score:1)
you describe exactly my biggest complaint about python
Re: (Score:2)
I propose we specify a character the Python interpreter completely ignores. We'll call it "placebo", you can use it for nesting.
The only disadvantage is you can't create confusing source code where you indent half the time and outdent the other half.
It probably wouldn't be that hard to hack a text editor to do the right thing with a character like that. Certainly no harder than syntax highlighting, automatic curley braces in C++, or automatically including the kitchen sink in a Java IDE.
Re: (Score:2)
There are already several projects that let you use braces with Python code. For example, there's bython [github.com]. There doesn't seem to be much interest in this sort of thing, however. There have been several translators over the years, but for the most part they all faded away.
Re: (Score:2)
The bython code example is terrible. Braces denoting a block should be vertically aligned, not one of them stuck of at the end of a line. I make an exception for blocks that are a single line long where one can legitimately type:
{ x = 1; }
rather than:
{ x = 1;
}
or
{
x = 1;
}
Re: (Score:2)
Actually, it looks like the Bython examples use the One True Brace Style [wikipedia.org] while you prefer the BSD bracing style.
So, if we ever get braces in mainstream Python, we'll get flamewars about which of the dozen brace styles should be used.
*TYPE*Script (Score:2)
It's all about the ecosystem (Score:5, Insightful)
People tend to use the programming language with which they most quickly can get to the result they need. Whether the language is good or not doesn't actually matter that much, just how fast you can achieve your goals with it. That's why these "popularity rankings" are somewhat misleading -- they don't measure how well languages are liked by their users, but how many people use them because they are the best option for them, regardless of how they feel about them. Case in point: the interview mentions that Google's decision to use TypeScript with their Angular framework made the language. Had Google decided upon another language than TypeScript for their framework, that language would now have the same ranking, and TypeScript would have been a footnote.
To illustrate this further: I think the SH language (for shell scripts) is just awful when it comes to programming. It's great when you want to do something quickly on the command line in a not-too-verbose manner, but for anything more complex, especially if you need proper error handling, it starts to become awful. Still, I've written a huge amount of shell scripts because the shell was simply the easiest tool available to achieve my goals. I don't like the language (in fact, I actively dislike it), but anything else was just not even remotely as convenient for specific circumstances. If you were to do statistically analyse all of the code I've ever written, SH would be quite high on the list, but not because I like it more than other languages I've used more rarely, but because it was simply the most effective tool in the circumstances where I used it.
Hence I dislike the term "popularity" here: just because something sees quite a bit of usage doesn't mean that people actually like to use it. Don't get me wrong, these usage statistics do have value, and if you're looking for a job, it's more likely that you'll find one if you know at least a couple of the languages higher up on the list, but the list only weakly correlates with how liked/loved a language is.
Re: (Score:3)
To illustrate this further: I think the SH language (for shell scripts) is just awful when it comes to programming. It's great when you want to do something quickly on the command line in a not-too-verbose manner, but for anything more complex, especially if you need proper error handling, it starts to become awful.
Programming languages are tools with some more appropriate for some tasks than others. For example, shell is a great language for systems administration programming. I was software lead on a project that spanned 10+ years to perform automated unattended software installation and configuration (OS and applications) from bare metal to user-ready across Windows (NT->10/2016), Solaris (Unix) and Linux systems. We used several different programming languages, depending on the need (including Assembly, Bash,
Re: (Score:1)
For example, shell is a great language for systems administration programming.
I have to disagree here somewhat: I believe shell is a truly awful language, period. Sure, some shells such as ksh have added some improvements that make it slightly less awful. The only thing shell does right is that it is a very good domain-specific language for starting other programs, that's the one job it does really well. The real pain in my eyes comes when you want to do both: complex logic and starting lots of programs. In that case you have do choose your pain: either you use shell (makes starting
Re: (Score:1)
Maybe I'm misunderstanding what you're saying about it being a royal pain to start another program. To me, as an old time C-programmer, it seems easy enough to do in C using the system() function. The last time I remember trying to come up with anything at all fancy was when I wanted to set up a quick and dirty way to record programs with my TV card, a sort of DVR back when TV cards were still new and there weren't a lot of software options. I used sprintf to print out a formatted command string with use
Re: (Score:2)
ad Google decided upon another language than TypeScript for their framework, that language would now have the same ranking, and TypeScript would have been a footnote.
Maybe, but Microsoft was pushing it really hard before that, so it would have been popular in the .NET ecosystem.
Re: (Score:1)
ad Google decided upon another language than TypeScript for their framework, that language would now have the same ranking, and TypeScript would have been a footnote.
Maybe, but Microsoft was pushing it really hard before that, so it would have been popular in the .NET ecosystem.
I was being a bit hyperbolic. ;-) And while I think that TypeScript would have had some place in the .NET ecosystem, I still believe it would not have taken off even within .NET as much as it has taken off now. As it stands now, because there's a lot of intersectionality with the Browser ecosystem due to Angular you now have a language where people can cross over between .NET and the Browser world, making it more useful even within .NET -- but if TypeScript had stayed a mostly .NET only affair, I think that
Re: (Score:2)
Look at how much effort it took Apple to push Swift in its ecosystem, how long it took for that to have a measurable effect, and only because they effectively deprecated Objective-C.
That's because Swift sucks (Objective-C has all the warts of C, but Swift has all the warts of C, Objective-C, and adds its own. For example, enums egh). Swift programmers have Stockholm syndrome. To see it in effect, ask them to say anything they don't like about the language. They will preface it with 'but,' saying something like, "Swift is the perfect language and Apple is the best company, but....." If they don't do that, then they get modded down by angry Apple fans.
No thanks (Score:2)
Good to have this research, anything stackoverflow users like should be avoided like the plague.
Re: (Score:2)
Although I myself resort to stackoverflow once in a while :(.
Bad metric for popularity (Score:5, Insightful)
Every time I see a popularity report from Stack Overflow, I just like to remind everyone of something very important.
Tools that have great documentation and resources? Those people don't go to Stack Overflow, because they already have the resources they need.
Tools that have shit documentation and resources? Rely on other people in the community, usually Stack Overflow, to figure out how shit actually works.
The popularity of languages and tools on Stack Overflow should be seen as a flaw in those resource's documentation, not as a success of those languages.
Billions and billions served (Score:4, Insightful)
The most popular burger in the world is McDonald's , by a large margin.
The BEST burgers? McDonald's isn't in the top 500 list.
Re: (Score:2)
You left out the category of languages that are too complicated for their own good. C++ has endless pages of documentation, but there exists a certain level of complexity that is sometimes hard to overcome. This year I had to go and look up some stuff on how to munge const correctness so I didn’t have massive code duplication. The casting that you have to do is a bit delicate, and it would have taken me so much longer to construct my own solution straight from the documentation.
C++ is its own special
Re: (Score:2)
while I get why some people like TS (Score:2)
Re: (Score:2)
wanted to make JS look more like a backend language without actually doing anything.
laziness is not the reason for ts being a preprocessor. the whole point was to add "feature x" (static typing) to the language without giving up the whole infrastructure and platform it already has, which is a huge deal. this is the same reason why e.g. scala compiles to java bytecode, to profit from binary compatibility with the whole java ecosystem. same for kotlin. i'm afraid nobody would be talking about those if they had chosen to reinvent the wheel. this is actually a pretty good idea, and typescript
I have never heard of TypeScript before this (Score:2)
Re: (Score:2)
yeah, ignorance is a common driver for hate.
no disrespect, just gently trolling you. if you could give some objective reasons for your dislike of js (a language that makes possible this very conversation plus 99% of what you do on the internet ... should we have written all that in assembly?), maybe your feelings about something you never heard of would be easier to empathize with. :-D
Re: (Score:1)
Why bother with a language no one is using at employer and their partners, and I never heard of? Add to that it's a Microsoft language that costs money and then I have good reason to hate it.
Re: (Score:2)
Well, at least your ignorance is boundless.
Don't know who your employer is, but they use Office? So, then they use stuff written in Typescript for sure.
I am so sorry you've been locked in your basement for so long. Here's how the world has changed since last time you were out: The US has had an African American president. Microsoft is the biggest contributor to Open Source in the world, and almost everything they have is now FOSS. Their dev t
I have a solution (Score:4, Funny)
When I joined the team, there were a lot of people at Microsoft who wanted to develop JavaScript at what we call "application scale." Teams like TFS and Office wanted to build large JavaScript applications.
Apply beatings liberally until the desire goes away.
Re: (Score:2)
Those teams are the ones happily beating themselves already. They were just given a slightly different paddle.
on my phone (Score:2)
Re: (Score:2)
The 1990s called and wanted their Microsoft MEMEs back. Almost everything Microsoft offers today is FOSS.
Re: (Score:2)
Re: (Score:2)
As I said - you live in the 1990s, that is a long, long time ago. Please come join the rest of the world in todays world. Check license comparisons here [wikipedia.org]
Re: (Score:2)
Popular or most difficult/complex? (Score:4, Insightful)
Please STOP using Stack Overflow as an indicator of anything except the number of problems people are having with a particular language.
To make a car analogy, that's like saying Ford makes the most popular vehicles because they're always in the shop for repairs.
Is this because... (Score:2)
Most of the developers are web developers and Python isn't really a web dev language? I can't forsee using Typescript anywhere other than in web development. But I'll use Python in lots of places TS can't go.
They're probably coming from Java. (Score:2)
Python is an awesome programming language. But if you're coming from Java, which many programming people are, then Typescript just seem like a godsend in this newfangled Javascript / webtech craze.
Typescript is also a very neat language and since a lot of contemporary programming work revolves around complex Web-centric development, it's only natural that folks will gravitate towards a language built around that domain.
My 2 eurocents.
IDE dependence risk? (Score:2)
One risk of type-centric languages is that they depend on an IDE to get most of the benefits type-centricism (to counter the down-sides, such as slow re-compiles). While Microsoft has open-sourced most of their programming languages and libraries, Many orgs are still highly dependent on their IDE's. The IDE competition for MS-oriented languages is somewhat weak, and switching has a learning curve. I'm not claiming here that MS is being evil, only that their IDE share makes it easier for them to be evil.