Depending on how you are authenticating you will see URLs with various words in them.
I'm usually pretty savvy about typing information into a rando web form, but with windows logins it's a major chore to figure out what exactly I'm looking at.
I hope they staff up to meet the 18-month rewrite cycle for modern JS apps. I'll stick with my 2003 version on the desktop for now.
Source: former dev on the team.
Disclosure: Microsoft employee, but not on Groove (or anything related to appx packages for that matter)
I work on a codebase that still carries product names that stopped being meaningful almost a decade ago. No value in renaming across the codebase and it’d be expensive because of how much code has to be touched.
For Google, see the very many failings here: https://grumpy.website/post/0PU1U2r3v. Someone (me?) should do the same for MS.
Please tell me that VBA will finally die.
Is it money, fear or gatekeeping that keeps these VBA programs untouchable?
I used to be in the Medical Devices field. A couple years ago, I was told to add a feature to a massive VBA app hosted in Excel that we (S/W development) inherited from another department. It was hands down the worst code I have ever seen. Everything was a global variable. I flat out told my boss that it barely worked, didn't come close to meeting the weakest of our development standards, and since it was used to disposition product (determine whether or not it was acceptable to be used on Patients) it was an FDA audit nightmare waiting to happen. I added the features, but made some pretty unpleasant commit comments since I didn't want to have my fingerprints all over it.
In all fairness, it was originally developed by a scientist with no SW dev training (I knew him well) for his own use, and just grew over the years as he was told to add more features to it. I have no idea how a company with that level of process strictness ever allowed this fiasco to happen.
I estimated the rewrite at 6-12 months. It was really not a very complex program and since we already had the Validation tests written and documented, we at least knew what tests its replacement would need to pass. The problem was all the stuff that we knew it was doing that wasn't in any of the tests. That would have been the majority of time spent to replace it.
Since I left, I heard ownership of it was transferred to Corporate IT and they were making it into a web app to run on their intranet. Heaven help those guys.
At my last job, I developed automated processes. Some software companies sell tools to automate clicks and keypresses. The idea is then to reuse that Excel macro no one understands inside a VM on a server, and adding a friendly webservice on top of it. Users of the web services don't know an actual screen is running and and an Excel file is being clicked for them.
Having worked at a big company as a mechanical engineer and produced a few crappy VBA apps, I did it because it would take significantly more time and effort to get approval for an IT project, than to learn VBA and do it myself.
I was involved in work with a regional financial institution. They had a suite of line-of-business apps written in Access and VBA. This was in a pure support and maintenance mode. This series of apps was written over the course of a decade by one developer nee business user. It represented a literal Great Wall of Chesterton. There was so much process and institutional knowledge tied into this suite and the original developer left after being absorbed into the IT organization.
Some fun observations from work that was done on this suite of applications:
- "We can tell where the original developer learned various programming techniques and when something was written based on that."
- There was a source control and deployment app written entirely in Access DBs and VBA
- There were two scheduling applications, one designed to replace the other, but the first never fully retired. These launched jobs based on dependencies and timings.
- The applications ran in Access 2010. No upgrade was possible due to observed breakages when attempting to change.
- A Windows security update caused an outage for a day.
- Some data was centralized into a SQL Server instance and Access was a thin app layer on these tables. Others held data in the Access database.
- Different apps could reach into and run arbitrary queries on data of other apps. This was sort of RPC. Huge spooky action at a distance.
- There is a ticking time bomb based on Access database size limits. They run compaction jobs on a regular basis, with increasing frequency. One of the core apps will simply stop working one day in the not so distant future when its database cannot be compacted to be smaller than the Jet engine limit of 2GB.
I mentioned that this thing was in perennial support and maintenance mode. There were several assessments over the years for a migration to .Net. All were eventually scuttled due to cost and fear of functionality shifts. No one knew if what was there was correct, and some of the bugs we fixed demonstrated that there was plenty that was incorrect, though scope and impact were difficult to measure. No one wanted to own a migration due to the likely fallout. Different would be wrong, even in the face of huge evidence to the contrary. A C-suite executive was ousted largely over this suite of applications. The Access lives on.
Eventually a migration, in part or whole, will be necessary. It will be expensive. It will be painful. Each day increases the expense and pain. But every day, it is cheaper and easier to run and maintain.
 This thing hit commercial and customer facing processes, internal things like HR, letter generation, asset management, and basic reporting, among other things.
 See: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
Note: Throwaway because of the level of detail
And by the next "best" thing, I actually mean the next worst thing, because I've written apps that interop with VBA macros and no man or woman should ever suffer such an experience.
It adds types and constraints that have no effect on the resulting transpiled code besides an insurance that said type constraints are being met.
By this kind of logic, C++ === machine code. It compiles down to it, right?
What did he write that you did not?
Talking about the online versions of office, it is a mess. For Word and PPT they tried to replicate the desktop to the web, rewriting the code, so their current online versions are already using (mostly) new code dedicated for the web. Saying that, they also have a huge number of legacy components and features that they need to support for backward compatibility.So for word and ppt this is a mix in code, not a total re-write. They also have a substantial subset of the features that appear only in their older desktop brothers. Even the PMs don't dare to dream on features parity between the versions.
Excel is a different world and a big-big elephant that won't likely be rewritten any years soon. Think of a code that is maintained over 30 years. Literally, developers are still maintaining code written in the 90s.
Trying to bring Excel to the online world made MS create an architecture of html frontend which communicates with a dll session behind the scenes. As weird as it sounds, this dll lives as long as the browser has the spreadsheet opened. Think of it as MS raising VM for every excel file that is opened over the internet. While this is not very cost effective (saying the least) and not very performance friendly (hey ma! I made an understatement) this allowed them to move forward with Excel online very quickly by having a UI communicating with the bloatware dll that runs on the background in Azure. Summarizing Excel, it probably won't also be rewritten in js.
So this PM might be talking about the new apps - Teams or flow or something similar. Not the office cash cows. Personally I really hope he is talking about Skype which became a total garbage in the past versions.
Anyone from Google here? I'm looking for a job :-) ping me (chengmau) in the blind app
It's pretty much exactly the scenario of my nightmares.
Maybe, or maybe it would open up an opportunity for more competition. Who knows? Maybe the year of the Linux desktop is still coming :)
Not in terms of code bloat/complexity (these exist in both, as you've just described), but in terms of engine size, drive-ability, edge-case handling, etc.
It's probably a hard question to answer; it's (for some reason) hard for me to articulate exactly what I mean too.
And regarding Excel-literally-in-the-cloud... is that why Microsoft needed to make Azure? :P
I think that the C# focus of .NET is a major mistake holding the platform back, especially when we have languages like F#, Scala, Swift, ReasonML and Rust these days.
> I think that the C# focus of .NET is a major mistake holding the platform back, especially when we have languages like F#, Scala, Swift, ReasonML and Rust these days.
Yeah F# is really nice, but the IDE support is kinda meh. Also .Net expects you to embrace nil at a lot of points which doesn't gel so nice with F#. But Swift has a worse problem with Objective-C-isms but being a first class citizen really helps as they make a lot of API's really better to use with Swift.
Also see https://www.thurrott.com/cloud/office-365/161295/microsoft-r...
Also, I expect the existing code base isn’t small, so a rewrite won’t be ready soon.
Considering they are uniquely positioned to make it happen given their C# buy-in and probably more than just a bit of existing software to leverage, I'd say this is as strong a signal of non-endorsement as it gets.
I bet this is only the new stuff like Delve and the less functional, more social apps/components. I can't imagine how they could pull this off for a full version of Excel or even Word or PP..
Besides, office currently isn’t written. In .net, they would be migrating away from C++ code.
See my comments here:
Also, they're actually using Typescript.
Yes, in theory you _can_ write big projects well in dynamically typed languages, but in practice you get a mess of undocumented interfaces and unit tests that don't quite catch the plethora of errors not present when a static type system is in place.
I think Typescript is a great middle ground between the loose running JS hipsters and the Haskell loving Hindley-Milner type system CS researchers. You can enforce the type restraints that you want (I personally am strict about explicit "string | null" declarations) but you're still hip enough to draw the JS talent.
edit, since there seems to be some confusion: I am explicitly talking about the WIN32 variant, which he confirmed to be based on Electron.
"No they are not electron apps. They are compiled to native code.
It's now finally one toolchain(#webpack)
It's one codebase and it compiles to:
WIN32 (only one that uses electron)
7:52 AM · Jun 13, 2018"
It's kind of sad; all the good stuff I use is basically legacy Windows. None of what Microsoft has done since Windows 7 has appealed to me.
So, what the hell was this guy tweeting about?
Whoever makes the first neural model capable of returning interesting insights after being installed in the telephone switchboard/backbone is going to have a most unique life.
Edit: Just realized ISPs have probably been trying to do this for years. I'm talking about the first individual. It'll probably happen routinely in 20 years or so.
What's that? Win32 a second class citizen? Never!
It was a very smart move of MS to kill newer chipsets :-(
If they hadn't done that, win10 would have completely tanked
I too find it hard to believe they would drop the native Windows and OSX versions of Outlook, Word, Excel, for apps written in React Native. But Microsoft has offered many surprises lately...
> WIN32 (only one that uses electron)
which happens to be the version most people use.
The challenge here is social. The Web has fist-mover advantage. Also, I fear that doing it the right way would be equivalent to forcing standardization on a single operating system (or a family of systems).
Typo reveals essential truth.
In the best case scenario you implement something almost identical to the current web which is only slightly better, and therefore not worth moving the entire world over to your stack just to get these minor improvements.
The Second day Microsoft decide to buy GitHub and everyone were flocking off to Gitlab, everyone hates them.
May be they will even Open Source the Windows Kernel some day.
> Tip of the day.
> Scripting languages as first programming language for CS bachelors are WRONG. You are not able to write an OS, a DBMS, or even an Office suite with an scripting language.
I honestly thought this was a satire tweet. I guess I just don't associate even a CS bachelor's degree with writing that kind of software. I mean, it can, but there are more theoretical tracks that don't involve writing a OS/DBMS.
As a first practical programming language for a non-CS bachelor, scripting languages are fine. Without CS courses to support you, other approaches might be too difficult, while scripting languages often let you get (terrible) programs up and running (ish) while ignoring basically all CS aspects during the learning phase (only while you're not making anything big, though—the "high level" illusion breaks down fast as things grow).
(Also, yes, you can write a DBMS or an Office suite in a scripting language. I can't possibly comprehend why you'd want to do something like that, but it's very much possible. Bringing OS's into things is cheating, as most compiled languages can't be used there either, and those that work often only work with a subset of the full language.)
One of the nice things about so-called scripting languages is the breadth of library support. If you want to put together a GUI that displays some word-wrapped text, you can do that within the first hour of using the language, if you have some homework instructions you're following. At that point you can think about the interesting parts of writing a word processor, and not just how to put a window on screen (which tends to be more about docs and APIs and not about actual computer science). Also, importantly, at that point you've successfully done something, which is pretty important for the learning process.
The priority is deep learning of computer science, not of programming.
Not exactly OS/DBMS but still pretty low-level.
VS Code, Discord, Slack, etc., all have awful performance on older hardware where native programs like the full Visual Studio fly.
It's my personal suspicion that people cheerleading JS all are working with fantastic developer hardware, where the performance impact is pretty muted.
But if an app does it "old school" then it can definitely be very slow.
My full-time job is writing tools in React that often have to handle datasets in the >10k items range.
I work on a React project that has a faster UI than its native desktop counterpart.
Let me illustrate the DOM question with an example.
Let's say you've got an "old style" jQuery to-do app. The user types something into the field, and clicks "Add".
- The input field will be cleared
- A new element will be added to the list, containing the string
- The counts for "total items" and "items remaining" will be updated
Now let's say you rewrite this app in React. The user types something into the field, and clicks "Add".
Your code that accomplishes this will look completely different - much more readable and less fragile - but the exact same DOM API calls will be made, and it will perform exactly the same.
The "speed" we associate with React is not in comparison to "old school" libraries, but to the naiive way of achieving data-driven syntax. You could just nuke the page entirely and re-render everything from scratch each time your data changes. This would be the easiest way of achieving data-driven syntax, but it would indeed be extremely slow. React gives you (something approaching) the performance of jQuery-style mutation, with the developer experience of reconstructing the DOM from scratch every time data changes.
Very efficient, though technically MS acquihired Mark Russinovich.
He still works on them even though he's Azure CTO.
Perhaps it's your computer and not Outlook.
>> Those are one in the same thing (compiled) :-). But us TypeScript in majority at Microsoft in almost all the projects I've seen or been apart of.
(I have no idea how other formats are structured)
I know that it's common for rewrites to not approach feature parity, but I think Microsoft is aware of how much people rely on Excel and Word and will make feature parity a high priority because of that.
Meaning it's not the language the real issue , it's what you do with it.
Also Junior at school are less and less trained with Java and C# but straight up with JS or PHP , so it will be much easier to integrate juniors on this re-written version of office rather the pile of legacy C++ / COM / C# bridges mess they have right now.
Any new developers on this need to have experience working with email standards and a good knowledge of C++ / C not some fracking scripting language!
And as some one who used to do international interconnect I think I have some valid input here - this has shades of the amusing project spitfire fiasco in the late 80's.
None taken .
Great, so the UIs will continue to get slower and more broken. What a glorious future we have to look forward to.
No they are not electron apps. They are compiled to native code.
It's now finally one toolchain(#webpack)
It's one codebase and it compiles to:
WIN32 (only one that uses electron)
> how is that even possible? there are tons of legacy features in there, COM/OLE APIs, SDKs, plugin architecture, macro system, VBA interpreter, VBA IDE, graphing components etc. Almost 30 years of development. No way MS is going to rewrite all of that. (Maybe the "mobile" version)
I think this is a strong indication that all these technologies are going away.
Also, I do not know what the Linux plans are (but hey maybe a great time to voice that special love you have for Linus T. and his masterpiece)!