Office 365 is being completely rewritten JavaScript(twitter.com)
twitter.com
Office 365 is being completely rewritten JavaScript
https://twitter.com/thelarkinn/status/1006746626617008128?s=21
30 comments
Previously posted, original discussion here: https://news.ycombinator.com/item?id=17300893
I have a strong issue with the whole taxonomy. How do we decide what is a scripting language and what is not?
What are other languages, enterprise languages?
The same goes for "systems languages" and to all those making a flag of these definitions.
They are meaningless.
In keeping with the UNIX philosophy, everything under /bin is a system software, no matter what language it is written in.
What are other languages, enterprise languages?
The same goes for "systems languages" and to all those making a flag of these definitions.
They are meaningless.
In keeping with the UNIX philosophy, everything under /bin is a system software, no matter what language it is written in.
"How do we decide what is a scripting language and what is not?" -> John K Ousterhout decided in 1997 (because, IFAIK, he invented the term). It was quite brilliant at the time, IMHO.
Now, 20 years, later, I consider his dichotomy outdated on several levels. I did a talk about this 7 years ago ( https://fr.slideshare.net/sfermigier/four-python-pains ).
Now, 20 years, later, I consider his dichotomy outdated on several levels. I did a talk about this 7 years ago ( https://fr.slideshare.net/sfermigier/four-python-pains ).
I would define a script as a program for automating tasks otherwise performed by a person. A scripting language such as Bash is primarily used to automate tasks which a user would otherwise manually perform on a shell.
I would say that JavaScript is not a scripting language, nor did it begin as a scripting language, as its main use case has always been in providing interactivity to users, not in automating the tasks conventionally performed by users.
I would say that JavaScript is not a scripting language, nor did it begin as a scripting language, as its main use case has always been in providing interactivity to users, not in automating the tasks conventionally performed by users.
> How do we decide what is a scripting language and what is not?
I'd say a "scripting language" is one that was designed to run "scripts". Where a "script" is a set of instructions executed against an API provided by a containing program, like your CAD software, to automate things. Javascript was created to automate the browser DOM API.
I'd say a "scripting language" is one that was designed to run "scripts". Where a "script" is a set of instructions executed against an API provided by a containing program, like your CAD software, to automate things. Javascript was created to automate the browser DOM API.
Just about everything uses an API to the CPU/OS/GPU. We're really just drawing lines in the sand and placing goalposts. Sometimes it shifts back and forth.
Honestly the distinction is pretty useless as far as reading/writing production code goes. What really changes in your development mindset between compiled vs. scripting languages? You still want to write working, maintainable, and performing code in both.
It's a useful distinction when teaching programming to show the different ways things boil down to primitive instructions.
Honestly the distinction is pretty useless as far as reading/writing production code goes. What really changes in your development mindset between compiled vs. scripting languages? You still want to write working, maintainable, and performing code in both.
It's a useful distinction when teaching programming to show the different ways things boil down to primitive instructions.
Careful that you are conflating scripting and interpreted.
Mostly we think of scripting as "interpreted and dynamically typed", but it's just an habit with no base.
Notice that interpreted and dynamically typed are two independent properties.
Mostly we think of scripting as "interpreted and dynamically typed", but it's just an habit with no base.
Notice that interpreted and dynamically typed are two independent properties.
Yeah, the original "starting with scripting languages is wrong" is just cheap pedantry.
But accurate?
When I was at uni my degree course was basically
Year 1: C Year 2 and on: C++ Year 3 and 4: We touched on java and javascript (although JS wasn't taken seriously, rightly IMO regardless of where dev is now).
The degree had courses on things like writing interpreters, compiler theory and you actually had to understand how it all worked.
I look at that same curriculm today and the starting development course is javascript (and also Java in year 1). All the stuff that I would have said was fundamental for any developer to know seems to have been dropped entirely.
I don't believe you can start with Javascript as your first introduction to programming and become a good programmer. I see this in devs nowadays a lot that they work at a higher level of abstraction than we had to and yes they are productive. Take those abstractions away though and they are completely lost because they lack the fundamental knowledge that those abstractions were insulating them from.
I've seen devs that graduated relatively recently (last 5 years) not understand the difference (and therefore the implications) of value types versus reference types. Not understanding immutability. I could go on and on.
When I was at uni my degree course was basically
Year 1: C Year 2 and on: C++ Year 3 and 4: We touched on java and javascript (although JS wasn't taken seriously, rightly IMO regardless of where dev is now).
The degree had courses on things like writing interpreters, compiler theory and you actually had to understand how it all worked.
I look at that same curriculm today and the starting development course is javascript (and also Java in year 1). All the stuff that I would have said was fundamental for any developer to know seems to have been dropped entirely.
I don't believe you can start with Javascript as your first introduction to programming and become a good programmer. I see this in devs nowadays a lot that they work at a higher level of abstraction than we had to and yes they are productive. Take those abstractions away though and they are completely lost because they lack the fundamental knowledge that those abstractions were insulating them from.
I've seen devs that graduated relatively recently (last 5 years) not understand the difference (and therefore the implications) of value types versus reference types. Not understanding immutability. I could go on and on.
Just C in year 1 seems a bit limiting. What was the focus? Electronic engineering a big part also?
My year 1 was Turing, Haskell, Fortran, Mathematica (certainly a language); tackling problems with multiple methodologies. Prolog in year 2, and then go from there depending on what you select. Java was not yet 'a thing' though I understand it took over the role of Turing for year 1 quickly later.
My year 1 was Turing, Haskell, Fortran, Mathematica (certainly a language); tackling problems with multiple methodologies. Prolog in year 2, and then go from there depending on what you select. Java was not yet 'a thing' though I understand it took over the role of Turing for year 1 quickly later.
I think students who know they don't want to do mostly web dev need to avoid computer science and go for a computer engineering degree instead. They'll get the engineering depth they need there. I was able to get my BsCpE with a SE concentration and avoid some of the EE classes because I knew I wanted to do mostly software anyway.
[deleted]
No, not accurate
Me and multiple others have started with scripting languages and can understand pointers just fine.
While understanding things at a deeper level is important, it is not for all, and certainly not the fault of which language the person studied first.
That being said even C abstracts a lot of things and I don't see many pushing for assembly programming because of that.
Me and multiple others have started with scripting languages and can understand pointers just fine.
While understanding things at a deeper level is important, it is not for all, and certainly not the fault of which language the person studied first.
That being said even C abstracts a lot of things and I don't see many pushing for assembly programming because of that.
> The degree had courses on things like writing interpreters, compiler theory and you actually had to understand how it all worked.
You do understand that you can write interpreters and compilers in any language, right? That includes all the scripting languages. JavaScript is actually one of the languages used most often for writing compilers.
> I look at that same curriculum today and the starting development course is javascript (and also Java in year 1).
That's a problem with the curriculum, if anything, and not JavaScript nor Java.
> I don't believe you can start with Javascript as your first introduction to programming and become a good programmer.
In other words, you can never learn to ride a bike if your "introduction to locomotion" happens to be walking. That's harsh...
> nowadays [...] they work at a higher level of abstraction than we had to
That's called progress. And "nowadays" is misleading - the same has been continuously happening since the sixties, and the exact same argument was repeated again and again along the way. Assembler is too high-level, you can't become a good programmer by learning it before microcode (and how to hold a soldering gun!). Structured programming is too high-level, you can't become a good programmer by learning it before free-form assembly. Function calls are too high-level, you can't become a good programmer by learning them before goto. Object-oriented concepts are too high-level (and so inefficient!), you can't become a good programmer by learning OO before procedural or functional approach. It goes on and on and I honestly don't understand what makes people rehashing the same argument so often when even a very basic understanding of computing history would show that it's futile.
> I've seen devs that graduated relatively recently (last 5 years)
Check back in 5-10 years time and see if they still don't understand immutability or references. Not to mention that it could be caused by any number of factors (like, for example, a lower percentage of people coding from childhood in the recent graduates).
Anyway, learning programming takes vast amounts of time and a lot of sustained effort over the years. The bright side is that if you don't slack off, you'll become a good programmer eventually, no matter what you started with. Keep doing it, keep expanding your horizons, and at some point, you'll get to wherever you wanted to be.
You do understand that you can write interpreters and compilers in any language, right? That includes all the scripting languages. JavaScript is actually one of the languages used most often for writing compilers.
> I look at that same curriculum today and the starting development course is javascript (and also Java in year 1).
That's a problem with the curriculum, if anything, and not JavaScript nor Java.
> I don't believe you can start with Javascript as your first introduction to programming and become a good programmer.
In other words, you can never learn to ride a bike if your "introduction to locomotion" happens to be walking. That's harsh...
> nowadays [...] they work at a higher level of abstraction than we had to
That's called progress. And "nowadays" is misleading - the same has been continuously happening since the sixties, and the exact same argument was repeated again and again along the way. Assembler is too high-level, you can't become a good programmer by learning it before microcode (and how to hold a soldering gun!). Structured programming is too high-level, you can't become a good programmer by learning it before free-form assembly. Function calls are too high-level, you can't become a good programmer by learning them before goto. Object-oriented concepts are too high-level (and so inefficient!), you can't become a good programmer by learning OO before procedural or functional approach. It goes on and on and I honestly don't understand what makes people rehashing the same argument so often when even a very basic understanding of computing history would show that it's futile.
> I've seen devs that graduated relatively recently (last 5 years)
Check back in 5-10 years time and see if they still don't understand immutability or references. Not to mention that it could be caused by any number of factors (like, for example, a lower percentage of people coding from childhood in the recent graduates).
Anyway, learning programming takes vast amounts of time and a lot of sustained effort over the years. The bright side is that if you don't slack off, you'll become a good programmer eventually, no matter what you started with. Keep doing it, keep expanding your horizons, and at some point, you'll get to wherever you wanted to be.
Yup, and that really was what the tweet was trying to portrait. JavaScript, and many scripting (or maybe author meant interpreted languages), are incredible languages to start with.
I have a love for the "sharper" langs like Rust, and AssemblyScript, however the ease of use, hyper backwards compatible, super super accessible package manager, and OSS Ecosystem for JavaScript are what make it world-eating. Plus its only 7-11% slower then C++ execution (last I checked).
I have a love for the "sharper" langs like Rust, and AssemblyScript, however the ease of use, hyper backwards compatible, super super accessible package manager, and OSS Ecosystem for JavaScript are what make it world-eating. Plus its only 7-11% slower then C++ execution (last I checked).
I am finding it a bit hard to follow the Twitter thread, so for the sake of avoiding confusion - does this mean that the version of Word running on my Windows 10 laptop will soon be written in JavaScript?
Could be! Didn't we just announce (and got meme'd to death by InfoSec world) that Excel is going to be able to _run_ JavaScript.
BTW this isn't breaking news, we have been talking about our love, bets, and use of ReactNative and ReactNativeWindows for a while now!
BTW this isn't breaking news, we have been talking about our love, bets, and use of ReactNative and ReactNativeWindows for a while now!
The high level source code – yes. But in the end almost everything (except one app implemented as an electron app) will be compiled to native code. They're using multiple forks of react native for various platforms – that's what he basically means by "written in JS".
Are they actually compiling JavaScript (or TypeScript) ahead of time to native code? I was under the impression that AOT compilation wouldn't work well for JS because of its dynamism, hence the JIT compilers in all the web browsers.
Or are they merely compiling TypeScript to JavaScript and minifying/bundling/etc. the source code, the way React Native normally works?
Or are they merely compiling TypeScript to JavaScript and minifying/bundling/etc. the source code, the way React Native normally works?
It's actually a bit confusing, in that thread he says everything is compiled to native, though...
[deleted]
Except they actually use Typescript for all those things, no?
For sure! That's our preferred way of using JavaScript. TypeScript in the end is just a static type linter that compiles to JS. Heck you can even "use" TypeScript's typechecker without even using a .ts file. We do this for the webpack project using JSDOC Annotations (Project: https://github.com/webpack/webpack, Example: https://github.com/webpack/webpack/blob/master/lib/ChunkTemp...) because we didn't want a build step.
> It's one codebase and it compiles to: Web Android IOS MacOS UWP WIN32 (only one that uses electron)
So unless I decide to switch to Windows 10, I will have to use the Electron version of Microsoft Office? I don't have many issues with JS itself, but frankly, looking what you did to Skype, I'm afraid of the final result.
So unless I decide to switch to Windows 10, I will have to use the Electron version of Microsoft Office? I don't have many issues with JS itself, but frankly, looking what you did to Skype, I'm afraid of the final result.
Those are product decisions someone like me can't actually confirm right? I just know that the purpose or the goal is having a single code base, single toolchain, many targets. I just know I've heard of all of those targets being experimented with! A bit early to assume anything, especially from lowly me!
If you cannot provide actual information, why would you start rumors and make vague claims?
Why is somebody "lowly like you" doing PR and insulting people [1] on hacker news?
[1] https://news.ycombinator.com/item?id=17302135
Why is somebody "lowly like you" doing PR and insulting people [1] on hacker news?
[1] https://news.ycombinator.com/item?id=17302135
Sorry I offended. These aren't rumors just things we've been blogging about, etc. and I'll own being unclear. The Electron and UWP bits are things we've tossed around internally. I don't want to give more details because then it's more then I really know, which is unfair to the teams really working on it, etc.
That's using JS as a compilation target, through. Increasingly, it's very rare to actually write JS - even when one writes JS, one is mostly running it through Babel or some other com(trans)piler, so that one can use a nicer dialect.
I can write .NET IL assembly. But I prefer to write C# and use csc.exe to output that IL.
I can write .NET IL assembly. But I prefer to write C# and use csc.exe to output that IL.
Then please state it how it is: without Typescript, JS would be unusable for projects of this scope.
> JS would be unusable for projects of this scope
Blanket statements don't really make great arguments. That aside, in my experience (webpack for one), projects at scale with JavaScript, are harder to maintain without some type safety and are a bit more bug prone and slower to refactor.
But at the end of the day, its still compiled to JavaScript, whether you chose to slap a .ts file in there, or just use the typechecker standalone is a mere implementation detail.
Blanket statements don't really make great arguments. That aside, in my experience (webpack for one), projects at scale with JavaScript, are harder to maintain without some type safety and are a bit more bug prone and slower to refactor.
But at the end of the day, its still compiled to JavaScript, whether you chose to slap a .ts file in there, or just use the typechecker standalone is a mere implementation detail.