271–280 of 459 posts
Earlier quoted context omitted.
I'm guessing that in this case they're only talking about the "office software running in the browser" version of Office 365, not the "subscription pricing model for the desktop suite" version.
Except they actually are talking about all the versions, including desktop apps.
Earlier quoted context omitted.
This was kind of true with OneNote up until recently. There are currently two desktop versions. One that comes with Office and looks/feels like the rest of the Office suite, and one that is made with UWP and available for free from the Windows Store. That one looks/feels a lot like the Android/iOS OneNote app. However, they've announced that they're EOLing the Office version, with bug fixes through 2020 and security…
https://www.thurrott.com/cloud/office-365/161295/microsoft-r...
It does say users will be able to enable the full ribbon UI still, so I suppose I will have to do that. Hopefully they don't deprecate that feature.
Oh, just what Office needed: a rewrite that will almost certainly not even approach feature parity
Actually, I think the opposite is true. Instead of seeing new desktop versions without feature parity, we will finally see the iOS/Android/MacOS/Web versions of the Office Suite get feature parity with the Win32 versions because they will all be built from the same codebase. 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 an…
The tweet that the OP is quoting/responding to is interesting: https://mobile.twitter.com/jdgarciauc3m/status/1005768121230... > 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…
I very much agree that this is a broken line of argumentation. However, I find the opinion to be correct: Scripting languages might not be a good first programming language for a CS bachelor, where priority is deep learning of programming. I'd also argue that JavaScript would be a bad candidate, as it is a very "unclean" language, being a poor way to teach language/compiler theory. As a first practical programming la…
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.
Earlier quoted context omitted.
Thank you for illustrating my point. All of the dynamic languages made different decisions on how to handle type conflicts, there simply is no right or wrong answer. Oh, and JavaScript is single-threaded. It's impossible to share resources in a single process.
> Oh, and JavaScript is single-threaded. It's impossible to share resources in a single process. DBs, files, etc etc. in-process memory isn't the only resource you're sharing.
Why not C#? Seems a bit of a missed opportunity to feed some of the APIs undoubtedly created for this into the new .net core stuff. I guess i'll just keep dreaming of the day when i can reliably convert a docx into a pdf without using office interop.
Reading this thread, with all the Javascript talk, makes me feel like I should be scared of continuing to be a C# developer..
This guy confirms all my prejudices against JavaScript hipsters, ruining computing for everyone since 1995. The beard, the super-fun-happy demeanor instead of thoughtfulness and competence. Please Wasm, save us from this nightmare! And nuke the hipsters from orbit.
Surprised they didn’t opt for Typescript. Then again, it’s a tweet - looking forward to a longer blog post with technical details when they’re willing to talk about it more.
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.
Surprised they didn’t opt for Typescript. Then again, it’s a tweet - looking forward to a longer blog post with technical details when they’re willing to talk about it more.
Javascript can still mean that Typescript is used.
Earlier quoted context omitted.
Really the choice of language is unlikely to be the cause of any slowness you are experiencing in different versions. JS can be faster than a native experience, all depends on program architecture. The main JS engines are blazing fast and a low-latency UI is perfectly possible; sluggishness is not a sacrifice you must accept when coding in nearly any language in 2018. But bad practices in any language can lead to a p…
Technically true, but in practice, the culture matters. JS ecosystem is what it is - based on past and current experience, you can't expect efficiency coming from there.