Slashdot Mirror

← Back to Stories (view on slashdot.org)

Microsoft Announces R Tools For Visual Studio (technet.com)

Posted by Soulskill on from the languages-you-keep-meaning-to-try-out dept.

theodp writes: A year after its acquisition of Revolution Analytics, Microsoft announced a slew of R-related product offerings, and noted that Revolution R Open is giving up her maiden name and will henceforth be known as Microsoft R Open. Tucked away in the announcement was the news that R is coming to Visual Studio. Microsoft has released a teaser video for R Tools for Visual Studio (RTVS) and is taking sign-ups for early access.

73 of 105 comments (clear)

  1. Holy Shit! by Anonymous Coward · · Score: 3, Interesting

    Damn, I am beginning to think that MS might actually be starting to take this whole free software thing seriously.

    1. Re:Holy Shit! by alvinrod · · Score: 3, Insightful

      Not that seriously though. Like most large companies they're more than willing to open source their software when it doesn't cost them anything or there's no practical benefit to keeping the source closed, but Microsoft isn't going to open source their OS or other products that make them the bulk of their money. This is true of others like Apple or Google that contribute to various open source projects or have open sourced some of their code, but the software that's responsible for most of their income is still locked down tightly.

    2. Re:Holy Shit! by Anonymous Coward · · Score: 1

      I'm loving some of the stuff they're doing to their dev tools (everything apart of their "universal" or "metro" garbage). But their OS is very quickly turning into a huge turd with their mobile-first approach and that is quickly turning me to other platforms.

    3. Re:Holy Shit! by SoftwareArtist · · Score: 4, Insightful

      I've got no problem with that. These companies are in business to make money. They aren't charities, and I wouldn't expect them to give away the software that provides most of their income. If they did, they'd go out of business.

      But consider what you said. Just because it costs them nothing to open source something, and there's no benefit to keeping it closed, that still isn't a reason to open source it. They could just as easily keep it closed anyway. And in the old Microsoft, which saw open source as evil and did everything they could to discredit it, that's exactly what they would have done. Their new attitude seems to be, "If it doesn't hurt us to open source something, then sure, let's go ahead and do it." That's a big change.

      --
      "I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
    4. Re:Holy Shit! by tlhIngan · · Score: 4, Insightful

      I've got no problem with that. These companies are in business to make money. They aren't charities, and I wouldn't expect them to give away the software that provides most of their income. If they did, they'd go out of business.

      But consider what you said. Just because it costs them nothing to open source something, and there's no benefit to keeping it closed, that still isn't a reason to open source it. They could just as easily keep it closed anyway. And in the old Microsoft, which saw open source as evil and did everything they could to discredit it, that's exactly what they would have done. Their new attitude seems to be, "If it doesn't hurt us to open source something, then sure, let's go ahead and do it." That's a big change.

      Well, it's because they have a new boss on top. The first boss said sharing was bad and you're an evil person if you did (Bill's famous letter to hobbyists in the 70s). The second one basically kept "Microsoft is dominant and we will rule" while the current one is more humble and akin to "OK, we have PCs, but PCs are not the be-all-end-all computing device anymore, and while we make a lot of money here, it's a mature product and it won't last". It's why they're putting Office everywhere - even on non-Windows things - you can have it on your smartphone, your tablet, etc. And while it's not necessarily great for producing content, if you need to update a slide on the way to the customer, well, that's a sale of Office365 subscriptions, because they can do it in under a minute, rather than try to dig out their laptop, start it up, etc.

      If anything, the new Microsoft realizes its no longer the central part of everyone's lives - you don't need a PC for everyone in the household (and likewise a Windows and Office license) - a lot, if not most, are perfectly happy to just use a smartphone and tablet, and maybe from time to time, use the shared PC.

      So it's busy finding new ways to be a part, to make itself relevant again. Not a bad thing, really - if you were wedded to a Microsoft solution, it just means Microsoft is now offering more ways to stay Microsoft only. If you're not, well, maybe it will attract you into the fold.

    5. Re:Holy Shit! by shutdown+-p+now · · Score: 1

      To be fair, though, for Microsoft to be even considered in the same league as Google when it comes to taking open source seriously is a big change from even 5 years ago. So if your assessment is how you really feel about it, I think we (I am a developer at Microsoft, working on open source software) have made considerable progress.

    6. Re:Holy Shit! by shutdown+-p+now · · Score: 1

      The attitude can actually go even further on some teams. On mine, we approach it as, "this should be open source unless there's a damn good reason for it not to, and even then we should first see if we can fix that reason".

      Why? We mainly do developer tools (including Python and R Tools for Visual Studio, just to bring this back on topic). In 2015, if you want respect from the developer community, you have to be open source, and in a real way (i.e. not just dumping the code as an incomprehensible tarball); and this is doubly true for existing communities around open source languages and frameworks like Python and R.

    7. Re:Holy Shit! by Xest · · Score: 1

      The problem seems to be what Microsoft has lost along the way. Whilst it's great that Microsoft has moved towards openness it also seems to have been accompanied by more freedom for developers at Microsoft dicking around on pet projects rather than focusing on things that actually help their customers.

      So for example, it's all well and good that they have R Tools for Visual Studio, but it's an absolute travesty that they have this, and yet no up to date managed framework for building modern Windows desktop applications. It should, in theory, be WPF, and yet WPF's ribbon control, the control that the Windows team is pushing as the new standard for Windows applications seems to have died a death circa Office 2007/2010.

      Even projects that are actively maintained though seem to have become a bit of a clusterfuck - ASP.NET MVC has always been excellent, and always been maintained, but somewhere between the release of MVC4 and MVC5 we seem to have gone through about 4 different ways of doing authentication and authorisation, starting with the classic role and membership providers, switching to the WebMatrix libraries, then onto Identity 1.0, and now Identity 2.0 and 2.1. That's all well and good, but what have we gained? Sure we can now do "social" authentication against Facebook etc. but for some god unknown reason all the configuration now looks like it has to be done in code, and the code isn't even consistent between authentication mechanisms. Writing a web application that can be trivially configured between AD and SQL authentication has gone from trivial to a massive pain in the ass.

      Microsoft needs to calm the fuck down with all the hipster technologies it's desperate to support, because giving their devs free reign to work on whatever the fuck they want (or at least, that's how it appears) seems to mean that they no longer have anyone working on the things they need to work on.

      Not everything can be a web application written using whatever the new cool is, there is still a massive body of industry that needs the stability and confidence that Microsoft used to provide. I'd always hoped that the mess that was Microsoft graphics/games libraries over the year was confined to that area of Microsoft, but rather than that getting better, the problem seems to have spread throughout.

      I just wish Microsoft could've managed it's transition towards openness without seemingly fucking up everything that made it successful in the first place. I can very well see why Java has become resurgent despite Oracle's poor stewardship - it's hard to have much confidence in modern Microsoft's development lineup.

      If you want respect from the developer community, you need to have a look at what built you one of the largest development communities on the planet, not what some hipster is telling you is the new cool, but that relatively few people use in practice (relative to what have been historically your main technologies). Microsoft needs to take a step back and ask who is the customer, is it the people who have always been the customer, or is it a handful of vocal bloggers telling us to use some shitty poorly designed technology that fuck all of value gets built in in practice?

      I'm not referring to R here, I know what R is, and have a lot of respect for it. I'm just fed up of the fact that Microsoft seems to have it's priorities completely wrong now. Openness is good, but not if it means you're producing nothing worthwhile to open up - the internet already provides me with loads of stuff that's open, but shit or of minimal use. Why would I need more?

    8. Re:Holy Shit! by shutdown+-p+now · · Score: 1

      Microsoft needs to calm the fuck down with all the hipster technologies it's desperate to support, because giving their devs free reign to work on whatever the fuck they want (or at least, that's how it appears) seems to mean that they no longer have anyone working on the things they need to work on.

      I've heard this many times, but you need to understand one simple thing. Developers aren't just fungible resources to be arbitrarily assigned to projects. They have their own preferences, and the same guy that's doing X won't suddenly start doing Y if X is cut (I've seen people leave over such things before); and even if they do, there is a big difference in productivity between working on something you love, and working for a paycheck, no matter how big.

      Then, of course, even ignoring personal interests, people have vastly different backgrounds and proficiencies. You can't take a guy who is, say, an expert in writing client-side JS code, and put him to work on the WPF low-level graphics layer (which is mostly C++) to optimize it; and the reverse is also true. Well, you can, but you're effectively wasting a valuable resource for very little gain elsewhere.

      And in places as big as diverse as MS, people often acquire very specific, narrow experience that is rare and valuable, but nearly useless elsewhere. For example, I'm a debugger guy - I wrote two dynamic language debuggers (for Python and now for R) from scratch pretty much all by myself, and have maintained and significantly contributed to two others (another one for Python, and Node.js). Give me another language, or another platform to target, and I'll crank one out in record time. Something tangentially related to that area - basically anything involving deep understanding of programming languages, the corner cases of their specs and intricacies of their VMs etc - sure, no problem. But I have pretty much zero clue how web authentication and authorization works beyond using existing libraries on the most basic level, for example. Sure, I can learn it if need be, but it'll take a while to get to the level of implementing such things, and I won't be producing much value in the meantime.

      So if you want to boost some tech, you need to somehow get more people with the specific background for that tech; and such people within the company are usually found on specific other projects, that may very well not be in the "fad of the day" category. And money is not usually as much of a problem as people - when it comes to the requisite level of experience, the market is undersupplied today in general, and it's the employees who shop around more so than the companies.

      (Speaking of, if there's anyone around with good knowledge of .NET and/or C++ - both is even better - with some Linux background, and interested in working on Python tooling and/or a cloud-based highly scalabe IPython/Jupyter service, ping me.)

    9. Re:Holy Shit! by Xest · · Score: 1

      "I've heard this many times, but you need to understand one simple thing. Developers aren't just fungible resources to be arbitrarily assigned to projects. They have their own preferences, and the same guy that's doing X won't suddenly start doing Y if X is cut (I've seen people leave over such things before); and even if they do, there is a big difference in productivity between working on something you love, and working for a paycheck, no matter how big."

      I don't disagree with the general idea that it'd be awesome if developers could work on only what they wanted, and in fact, if anyone could only do the job they wanted, but it's just not reality. Whilst I sympathise with your arguments I think there are two problems with them in practice - Microsoft does have the requisite people, and Microsoft does pay enough to get developers on board who should be capable of being fairly flexible. My reasoning? Windows RT - Microsoft has been investing in UI development but it's been doing it on things that have failed, rather than things that work.

      I've long held the belief that the advantage of commercial software over software developed as say, spare time FOSS projects is that pay actually acts as an incentive to do the things that are necessary to produce good software but are otherwise less interesting. This is in large part why so much FOSS software is fucking atrocious in terms of usability - most programmers have no interest in learning about UX stuff, they just want to write code and they do that. That doesn't work in a commercial environment, you provide money to get people with UX experience in to do that stuff that otherwise wouldn't get done.

      So this reiterates my concern with Microsoft now in that they seem to be blowing an awful lot of money to get what are, in large part, spare time projects.

      That aside though, does Microsoft really struggle to recruit these people? Is it really so hard to find people to sort out say WPF and keep it uptodate? With Microsoft's pay and benefits I can think of plenty of people that would more than happily do exactly that and wouldn't be competent enough to boot. Is Microsoft really looking to hire people like that? I believe most people would assume that Microsoft would be inundated with people with that sort of skillset, and so have simply never bothered to look to apply.

      As I say I don't really have a problem with a move to openness, god only knows Microsoft needed it. My problem is that they seem to have gone from one extreme to the other, when they really need to move back to the center - we had this large stuffy monolithic secretive corporation where everything seemed to be tightly controlled including pushing of standards, and now we've gone to this completely laissez faire company that seems to offer no stability, or assurance that it's customers have come to depend on.

      P.S. You may be as good as anyone to ask, I'm intrigued if you can offer any thoughts, we have a setup that allows customers to define process flows, and a server application that executes them. We have our own development environment and as part of defining these flows they can use Lua scripts for logic. This is all fairly legacy stuff, and I've taken on the stuff recently and am beginning to look at replacing it (not least because some of it is just plain awful - the Lua isn't sandboxed in any way, so customers can pretty much call out and do whatever they want to the server with their scripts. Yes. Really.). Moving forward we want to move away from just purely supporting Lua, but we do wish to maintain Lua support. Part of the problem also is performance on the server, I think we're taking quite a hit martialling between the managed and unmanaged Lua libraries because there are a hell of a lot of scripts and variables being passed between managed and unmanaged. I've been pondering the possibility of using .NET, and simply having our development environment compile scripts (in various languages so we can support things like Python, R, and C# as well as Lu

    10. Re:Holy Shit! by shutdown+-p+now · · Score: 1

      That aside though, does Microsoft really struggle to recruit these people? Is it really so hard to find people to sort out say WPF and keep it uptodate? With Microsoft's pay and benefits I can think of plenty of people that would more than happily do exactly that and wouldn't be competent enough to boot. Is Microsoft really looking to hire people like that? I believe most people would assume that Microsoft would be inundated with people with that sort of skillset, and so have simply never bothered to look to apply.

      I can't speak specifically for WPF, not knowing that team closely. But there are two points. First, it does actually have a team (again!), and they are actually doing things. The real problem is that they have a lot of accumulated work from the period when it was neglected, and a lot of it is the rather unglamorous stuff like bug fixing, perf improvements, and supporting the more recent underlying tech (to remind, the existing renderer still uses D3D9, which becomes more of a problem as new drivers focus their primary support to D3D10+, and ship more bugs in D3D9, especially for patterns of usage that aren't similar to what games do).

      I think that very long-term, the bet is still on the WinRT stuff, which should be more palatable now that these apps can actually run in a window rather than fullscreen, and sandbox restrictions have been significantly relaxed. Obviously, the prerequisite here is widespread adoption of Win10+, so it'll take quite a while longer.

      But whatever option we take, we need to make it possible to compile Lua to bytecode, or make it run on the DLR. All projects to date seem pretty shite on this front (unless something has changed since I last looked), and whilst I recognise it'd be incredibly time consuming I do have the time and budget to pursue this (and even open it up as an open source project). This isn't too dissimilar to the sort of work you're doing, although our needs are much more basic. Do you have any overall advice, or decent references for implementing languages on the .NET platform? resources seem few and far between and even a brief MSDN article on the topic seems to have vanished (and was grossly out of date anyway) or is this one of those things that you really just have to dive in and learn through trial and error? Overall programming language design and compiler design is less of an issue (I've been working my way through programming language pragmatics on and off for some time now anyway).

      For DLR, I don't think there are any really good docs. There's the existing implementations, and there are people around who made them who are basically the sole experts in that area, like Jim Hugunin; but unless you're one of those guys, the learning curve is rather steep. And because the demand for this stuff is not particularly high (which is why the original IronPython and IronRuby work had wound down), you see all those projects that get started on sheer enthusiasm, and then die because of the lack of interest before getting to anything stable enough.

      So if you want to do it, it's either a lot of trial and error, or finding and hiring one of those guys who know it.

      Compiling to bytecode is, on balance, a step up in difficulty. The good thing is that CLR bytecode and runtime is fairly well documented by the ECMA spec (and then there's the version with MS-specific implementation detail commentaries). The bad thing is that it's pretty low-level when you're using it as a basis for a dynamic language like Lua, so you will need to build a lot of scaffolding on top, especially for the interop with .NET.

      Also, the problem with the DLR approach is compatibility with the stock implementation. For example, you want to let them run Python scripts? That's great, but it's highly likely that they'll also want to use some popular Python packages at some point, and those packages are at least partially implemented in C - so you don't just need compatibility wit

    11. Re:Holy Shit! by Xest · · Score: 1

      "I think that very long-term, the bet is still on the WinRT stuff, which should be more palatable now that these apps can actually run in a window rather than fullscreen, and sandbox restrictions have been significantly relaxed. Obviously, the prerequisite here is widespread adoption of Win10+, so it'll take quite a while longer."

      Where does this leave Microsoft's own products like Visual Studio and Office etc.? These sorts of applications just don't seem to fit the RT format, and Microsoft's own reluctance to move to them from a more classical desktop format seems to be an admittance in itself that if nothing else RT just isn't a format that is going to work for every desktop application. Maybe it's me that's at fault, but I just can't see how I can build our application decently to suit this "app" format that RT pushes - it's like switching Visual Studio to this "app" format, I just don't see it happening without crippling the product. In fact, Visual Studio hasn't of course even made the switch to ribbons and so presumably there must be at least some recognition at MS that not everything can be a tablet friendly app and that more classic development support is still going to be necessary for the foreseeable future? Unless we regress back to MFC, which does of course seem to be supported at least I don't see how WPF or at least something very much like it can ever go away.

      "Also, the problem with the DLR approach is compatibility with the stock implementation. For example, you want to let them run Python scripts? That's great, but it's highly likely that they'll also want to use some popular Python packages at some point"

      Yes, I think this is really my biggest concern, but our user's needs aren't that complex. We essentially support decision making processes for the financial sector and typically all they really therefore need is the ability to manipulate strings and numbers and to call various bespoke interfaces- I think therefore it'd be sufficient that whilst we support the languages they're most comfortable with to provide our own .NET standard library. For the most part though I think we can generally move away from them writing code altogether, the people using our system aren't developers, they're typically underwriters and so whilst they have some programming knowledge from technologies like R, SAS and so forth I suspect we can eventually build them a tool that ultimately just generates code from a WYSIWYG process flow editor.

      In terms of sandboxing therefore, I think it'd be sufficient to merely restrict the methods they can call to those in our standard library.

      All this still bothers me somewhat, I feel like we're reinventing the wheel in many ways and I don't like the fact we'll be pushing our clients down a very bespoke path (although they already are and it doesn't seem to bother them), but I don't really see any other way to defining these sorts of things whilst giving them freedom of language choice, yet restriction of actions within that language and whilst also making sure it all executes on a common platform. One thing is for sure though and that's that we can't simply persist with a setup that allows execution of arbitrary Lua using the standard unmanaged interpreter and all the problems that brings.

      I appreciate your response!

    12. Re:Holy Shit! by david_thornley · · Score: 1

      Releasing software as open source isn't free. You need to verify that you're not releasing anything you got from a third party and are not allowed to release, you need to go through the code and comments and make sure they'd all be acceptable when read on prime time TV, and typically pretty things up.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    13. Re:Holy Shit! by shutdown+-p+now · · Score: 1

      Where does this leave Microsoft's own products like Visual Studio and Office etc.? These sorts of applications just don't seem to fit the RT format, and Microsoft's own reluctance to move to them from a more classical desktop format seems to be an admittance in itself that if nothing else RT just isn't a format that is going to work for every desktop application. Maybe it's me that's at fault, but I just can't see how I can build our application decently to suit this "app" format that RT pushes - it's like switching Visual Studio to this "app" format, I just don't see it happening without crippling the product. In fact, Visual Studio hasn't of course even made the switch to ribbons and so presumably there must be at least some recognition at MS that not everything can be a tablet friendly app and that more classic development support is still going to be necessary for the foreseeable future? Unless we regress back to MFC, which does of course seem to be supported at least I don't see how WPF or at least something very much like it can ever go away.

      Well, the boundaries of the "app format" have been vastly expanded in Win10 compared to the severely crippled sandbox that was there in Win8/8.1,and I'm hoping that it will continue to the point where something like VS actually can fit just fine. And if you look at the Win10 desktop today, WinRT apps actually feel much less "tablet-y" also - part of it is running windowed rather than fullscreen, but there are smaller changes in the same vein, too - e.g the shift away from all these hidden panels that you had to swipe out to clickable controls (for charms, app bar etc), and just generally scaling down of controls in non-touch modes. It still encourages writing apps that work well with touch, but if you wanted to ignore that and go for mouse-only, you could.

      But yes, for near future, and for managed desktop UI apps, it's definitely WPF.

      In terms of sandboxing therefore, I think it'd be sufficient to merely restrict the methods they can call to those in our standard library. ... One thing is for sure though and that's that we can't simply persist with a setup that allows execution of arbitrary Lua using the standard unmanaged interpreter and all the problems that brings.

      If all you want to do is lock down which functions it calls, then I'm not sure why stock Lua is an issue? It's deliberately designed to be very lockable in that fashion.

      Or are you concerned more about perf after all?

    14. Re:Holy Shit! by Xest · · Score: 1

      Yes, it's not just about sandboxing with regards to Lua, there are a number of factors, performance is indeed a key issue - right now there's just far too much of a performance hit martialling between Lua's unmanaged responses and our managed caller (part of the performance issue is our fault, the legacy code base is atrocious in the way it passes stuff back and forth with no caching of the scripts either meaning a full parse for every call) but of course, as I say the other issue is that we want to support more than just Lua, and ideally without having to have a plethora of different managed and unmanaged libraries for each language in the server that all require their own interfaces. That's why I was quite keen on the concept of compiling to something common like CLR bytecode, and executing that, but whether it's practical is what I'm still not really sure about.

  2. Managers Hate Niche Languages by Anonymous Coward · · Score: 2, Insightful

    Many Visual Studio shops are also Microsoft only shops where open source is frowned upon and use of tools not included in the standard install is verboten. Microsoft is doing this to try and get tools into the hands of people who otherwise wouldn't be able to access them on closed corporate networks. However, even this isn't always effective since some managers are in the nasty habit of banning certain languages, features or other parts of an otherwise "standard" install that they don't like, probably because they're worried that some new hire will write some mission critical program in "R" and that when he's gone in a year or two they will have to pay consultants huge amounts of money to maintain or re-write the app in a language that's easier to hire for.

    1. Re:Managers Hate Niche Languages by Anonymous Coward · · Score: 1

      I can say from personal experience that some managers on proprietary software projects are deathly afraid of the GPL and consequently frown on open-source anything just in case some obscure component is GPL.

    2. Re:Managers Hate Niche Languages by phantomfive · · Score: 1

      , probably because they're worried that some new hire will write some mission critical program in "R" and that when he's gone in a year or two they will have to pay consultants huge amounts of money to maintain or re-write the app in a language that's easier to hire for.

      I'm somewhat suspicious of 'programmers'' who find it a challenge to learn a new language. I know some programmers are afraid of it,but I've taken those kinds of programmers and trained them in strange languages they were afraid of.

      It's more a matter of overcoming your fear, and digging in. If you work at it eight hours a day, a new language won't take you too long to learn.

      --
      "First they came for the slanderers and i said nothing."
    3. Re:Managers Hate Niche Languages by i.r.id10t · · Score: 3, Insightful

      You mean you've never said "hey, I have a spare weekend, wonder if I can (or how long it will take) to learn $language well enough to implement $some_project in it?"

      Some of us like hobbies to be challenging, thought provoking, and mentally stimulating....

      --
      Don't blame me, I voted for Kodos
    4. Re:Managers Hate Niche Languages by phantomfive · · Score: 1

      ok, maybe instead I should have said:
      "I'm somewhat suspicious of 'programmers'' who don't believe they can learn a new language."

      --
      "First they came for the slanderers and i said nothing."
    5. Re:Managers Hate Niche Languages by Aighearach · · Score: 1

      And I know from personal experience that some managers are deathly afraid of hippies. They frown on anything that could be construed as polite behavior, because it could lead to a slippery slope and in the end the company would be left with a bunch of lazy hippies and go out of business. Gosh darn Obama ruining everything!

      Luckily, managers don't know enough about statistics to even figure out which charts are being produced from R. And it isn't used for applications, so even a product manager might never find out it is lurking in the other room.

      I'd like to see expanded use of R because there is Postgres support these days, and it is really powerful. Statistics and data go together like peanut butter and bananas.

    6. Re:Managers Hate Niche Languages by Aighearach · · Score: 1

      I'm very suspicious of people who claim, without any shame at all, to be so narrow in their interests that their weekend hobbies are the exact same thing that they're doing at their day job all week.

      If I got a job doing one of my hobbies full time... I'd switch my weekends to a different one. Duh.

      There are lots of things that are challenging, thought provoking, and mentally stimulating. If a person can only find a small number of things, I question their ability to become mentally stimulated.

      The reason for a programmer to find it challenging to learn a new programming language is that they're expected to use it at work. If they were using it as part of a hobby, it wouldn't be challenging in that way because they'd be going at whatever their own pace is. More like, they don't have a "spare" weekend to spend learning stuff their employer wants them to train on. If it was because of a hobby, there wouldn't be any complaint, or any need for somebody to "take [them] ... and [train] them in strange languages." You do your hobby in one language or fifty, as you desire.

    7. Re:Managers Hate Niche Languages by i.r.id10t · · Score: 3, Informative

      "If you enjoy what you do, you'll never work a day in your life"

      --
      Don't blame me, I voted for Kodos
    8. Re:Managers Hate Niche Languages by Kjella · · Score: 1

      "If you enjoy what you do, you'll never work a day in your life"

      Said nobody who had a shitty day and wished they weren't obliged to show up. If you don't have days like that, you take too many happy pills.

      --
      Live today, because you never know what tomorrow brings
    9. Re:Managers Hate Niche Languages by shutdown+-p+now · · Score: 2

      R is not quite in the same boat. Yes, it's a niche language, but it's a niche language with a niche that's actually different from regular software development. It's used for stuff like statistical modeling, data science and machine learning. And in those areas, it is dominant.

    10. Re:Managers Hate Niche Languages by shutdown+-p+now · · Score: 1

      It depends a lot on the language. If you know Java, you can be expected to pick up C# in matter of days, but something like Python might get some more time to adjust to, for example. And going from Java to, say, Lisp or Haskell, is a serious mental challenge, and that Java knowledge may well hinder you more than it'll help.

      R is actually kinda similar, and in some ways worse. It looks reassuringly familiar with its C-like syntax, and in many ways it will even behave the same if you write code in C style (though you'll quickly get frustrated with the standard library being very counter-intuitive). But the resulting code will be extremely bad R code - mainly because it would be horribly slow. And writing it fast means writing it the "R way", which is very different from how you normally do things in Java or C++.

      Also, under the hood, R is actually very much like Lisp, with a layer of syntactic sugar on top giving it that C-like appearance. But in truth, everything is a function call, literally - even assignments and function definitions themselves. Idiomatic R code, especially in the libraries, often uses that fact to great effect, but to someone coming from a C-style language the result is usually utterly incomprehensible.

      The type system is also very alien. I mean, it's a language that doesn't even have a notion of scalar types - everything is a vector (or other kind of collection), it's just that some vectors only have 1 element, and most operators are vectorized. Which means that e.g. something as simple and familiar as if (a == 0) ... can, and eventually will, fail with mysterious errors like "argument is of length zero" or produce incoherent results - because "a" was an empty or a multiple-element vector, and == got vectorized.

    11. Re:Managers Hate Niche Languages by phantomfive · · Score: 1

      Of course it's different, but I still don't have much respect for a programmer who is afraid to pick up a new language (or believes they can't in a reasonable amount of time).

      --
      "First they came for the slanderers and i said nothing."
    12. Re:Managers Hate Niche Languages by shutdown+-p+now · · Score: 1

      Well, in that sense it's not really just about languages, right?

      As the old joke goes, to determine if someone is a good programmer or a bad programmer is to ask them if they can do something extremely complicated. A bad programmer will say that they can't do it. A good one will say that they can do it, they just don't know how yet.

    13. Re:Managers Hate Niche Languages by phantomfive · · Score: 1

      Exactly true.

      --
      "First they came for the slanderers and i said nothing."
    14. Re:Managers Hate Niche Languages by thegarbz · · Score: 1

      There are lots of things that are challenging, thought provoking, and mentally stimulating. If a person can only find a small number of things, I question their ability to become mentally stimulated.

      Unless your weekday job is a factory hand, and your weekend hobby is to move boxes around the living room most fields have ample opportunity to mentally stimulate people. In fact many are widely varying that the hobby and work are completely different despite being unrelated. I know software engineers who spend all week working on reports and specs, and barely any coding, then throw together hobby software on the weekend. I personally spend a lot of my electrical engineering degree doing reliability analysis and I leave the hobby electronics projects for the weekend. Though there have been many many times where the weekend activity and the workplace activity have crossed over, sometimes to the point where I would bring in equipment from home to work and visa versa.

    15. Re:Managers Hate Niche Languages by Aighearach · · Score: 1

      *woosh*

      The thing is, you have a different opinion than me but you phrase it as if you're correcting me. That shows you didn't actually understand the perspective I was putting forth, and so your comment doesn't address it.

      If they're called something different than what they actual do, then duh, my comment would cover them doing on the weekend the same thing they're doing during the week.

      Did you consider that my statement was probably about the cases where my statement is true, and not about edge cases where there isn't enough specificity to claim it applies? Read the thread first, figure out the context. Until then, get off my lawn little sprout, before I get out the weed killer.

    16. Re:Managers Hate Niche Languages by Aighearach · · Score: 1

      As much as I love word games, they're just laugh lines and don't really add anything. Like in business books, they use your quote as the quote at the start of a chapter, but in the actual text they use the normal word meanings, because to actually discuss how to make it all work you have to go back to the real meanings of the words.

      And in this case, it seems to assist mostly in missing the point.

      If you enjoy your work, it is still unhealthy for the brain if you're doing the same thing on your off time. It is physically unhealthy for the brain. And if you're telling yourself you enjoy it so much that you don't have time for other things you enjoy, that is probably some sort of compulsive disorder and you'd benefit from a vacation.

      Or put it another way. If we lived in a Star Trek type of world where all the necessities were free, and the main reason to work was for entertainment, and you could mostly do anything you were able to understand, it would still be unhealthy to do the same thing every day without variety. Entertainment doesn't stay entertaining without variety. And just because there is enough variety in your job that you don't get bored during the week, that doesn't in any way refute this. Specialization is required to be advanced at anything, and there is huge physical value for the brain in including things outside what you're going to need during the week.

      If you work 40 hours at Awesome Job Foo, and then go home and do 10 hours doing Foo at home in your garage, you're doing 50 hours of Foo a week. Your efficiency at task Foo will likely be lower than if you were doing Foo for only 40 hours a week. It is just the way it works. I know, I know, "I'm different, I'm a special snowflake wondernerd and my efficiency doesn't go down until I hit 80 hrs."

    17. Re:Managers Hate Niche Languages by Aighearach · · Score: 1

      I've had those sorts of days. But after the age of about 21, the rare times it happened I simply quit the job. Life is too short, and I'm worth more than that.

      The reason a lot of people keep doing it is because they misunderstand money, and they think being willing to be treated that way will reward them financially. But a little more arrogance might not only improve their lifestyle, it might improve their pay too.

      Your willingness to associate "happy pills" with happiness suggests you have an irrational belief in the effectiveness of drugs to make people happy. My advice, stop taking them, stop wishing for stronger ones. Just say no.

    18. Re:Managers Hate Niche Languages by jader3rd · · Score: 1

      I'm confused by what side of the argument you come down on. The impression I get from the first few sentences is that you hate corporate culture, and how it can restrict developers desires to try new things to solve new problems. But then you make a very convincing argument for why the people who are invested in the business get to make the rules on how their business is run. If anything you made me a believer on why development shops should only have standard installs.

  3. R vs. Python vs. other by jmcbain · · Score: 1

    Can anyone comment on R vs. Python vs. something else for data science? I'm talking in terms of usefulness, maintainability, and finding enough candidates who know it (even hires straight from college)?

    1. Re:R vs. Python vs. other by Viol8 · · Score: 1

      I don't know anything about R but if its specifically designed for statistical analysis then its probably better at it out the box than Python. Having said that I can guarantee you'll find far more candidates with Python skills than you will R.

    2. Re:R vs. Python vs. other by i.r.id10t · · Score: 4, Informative

      R is pretty much pure statistics. While it has a built-in interpreter to load data from csv files or user input or whatever and then run its functions against the data set, it really shines as a library to be used in other "real" programming languages where you have logic, loops, etc. available to you.

      And since there are R interfaces for Python (http://rpy.sourceforge.net/) it isn't a "versus" situation.... what a bargain!

      --
      Don't blame me, I voted for Kodos
    3. Re:R vs. Python vs. other by bangular · · Score: 5, Informative

      R is preferred by statisticians. Many statisticians are on the leading front of creating new traditional machine learning algorithms (not the GPU driven or map reduce stuff "hip" companies are dealing with right now). Things like supervised classification tasks and clustering algorithms. This usually means you have access to a researchers implementation of a new algorithm fairly quickly, long before it's in a commercial package. It also means you have to deal with a lot of 1-off code and deciding whether their function wants a row-vector or column-vector.

      Python seems to be much more popular with those having a computer science background. There are far fewer machine learning algorithms available in Python. However, if you are going to design a large system, it's generally much more convenient to do in Python. There are Python interfaces to R as well.

      Julia is new on the scene and attempts to solve the shortcomings of Python and R (insert xkcd comic here). Performance is good and has interfaces to many languages. I've used it a few times and it's maturing, but it's definitely risky doing any long term project in Julia.

      Then there's Java. Weka is a popular machine learning package with a GUI and all of the algorithms available as jar files. Very consistent API and includes pre-processing tools. Weka also has a marketplace for new algorithms. However, many times you just have to write a 1-time script for data cleanup or to compare algorithms, and it's definitely not convenient to do in Java. I haven't seen many pure Java people doing this type of work in the wild. The final implementation may end up in Java, but the initial work seems to almost always be in R and Python.

    4. Re:R vs. Python vs. other by Anonymous Coward · · Score: 1

      It's no so much which mainstream language (they're all useful, maintainable and learnable) but how well you put it to use. If you're starting from a blank slate I would start with the availability of FOSS in your specific problem domain(s) then factor in relative popularity and of course licensing cost if that's an option. Also I'd be open to using more than one.

    5. Re:R vs. Python vs. other by Anonymous Coward · · Score: 2, Informative

      If you know both a Scripting language eg. Perl or even bash, and a spreadsheeting program, then R is almost unbelievably easy to learn, I was doing semi "advanced" stuff in less than a day, and I am not that bright.
      The real problem will be understanding the specific statistics you are wilding, which can be a lot harder.

      this is one of the nicer intro's I have found but tastes vary
      http://www.statmethods.net/

    6. Re:R vs. Python vs. other by Anonymous Coward · · Score: 1

      '... you'll find far more candidates with Python skills than you will R.'

      Perhaps; but you'll find more people who know statistics amongst the R crowd.

    7. Re:R vs. Python vs. other by ottothecow · · Score: 4, Interesting
      R is kind of a shitty language compared to Python. It is based on S, which is itself an old statistics language. It isn't awful, but it lacks the refinement of a language that was developed from the ground up in the modern era. Syntax can be wonky or inconsistent....

      But, R is all about stats. It has great charting and analysis libraries, far exceeding those that exist in Python or any other general purpose language.

      SAS is kind of the corporate standard if you want long term maintainability and a large selection of potential workforce...but it is expensive and if I were starting out today, I am not sure I would pick it. It is however much more easy to scale to huge datasets than R...SAS pretty much works as long as you can fit the data on your hard drive. No need to fuck with breaking up projects into small pieces or investing in boxes with 1TB of RAM. Millions and billions of observations are totally OK as long as you are willing to wait for the program to finish running.

      R has been making inroads at replacing SAS and Stata as the teaching language of choice (mostly because it is free)...so it is probably easiest to find straight college grads with some R experience than anything else.

      --
      Bottles.
    8. Re:R vs. Python vs. other by reve_etrange · · Score: 5, Informative

      MATLAB is amazing for general 'data science,' and is very widely used for certain tasks, such as image processing. It provides a huge array of already-implemented algorithms for computer vision, statistics, machine learning, and simulation. Many academic labs use it, and many students receive MATLAB training. On the other hand, MATLAB is proprietary and quite expensive. (It's semi-open source because most of it's functions are MATLAB scripts themselves). The language is very readable, except maybe the native array syntax, and comes with extremely good documentation, but it's clunky for general purpose programming. It has an OK IDE and one of the best debuggers in any language. The runtime is redistributable, so you *can* make portable applications, but again, it's a little clunky. The open-source GNU Octave and Scilab environments are also (mostly) code-compatible with MATLAB. All-in-all, it scores highly in all three aspects you mentioned, but it's very expensive.

      Python is also very good, once numpy, scipy, matplotlib, pandas and ipython/jupyter packages are installed. Like MATLAB, Python is widely used in academia, and lots of students receive training. There are many function/algorithms already available, but somewhat less so than in MATLAB. For example, the statistics capabilities are similar, but MATLAB has more image processing functions. Plotting and visualization also haven't quite caught up to MATLAB yet. Python has the great advantage of being totally free and open-source, and there are a large number of IDEs and debuggers available. Python is also a great general purpose language for self-contained, portable applications that may grow out of data analysis code. The documentation can be lacking in some modules, but there's good free support online via e.g. stackoverflow. Python is readable and easy to learn. It scores about the same as MATLAB, weaker in some areas, stronger in others, and is completely free. There's active development of the analytics modules and going forward Python will probably become more popular for data science.

      R is a bit of a special case. It has excellent statistics and machine learning capabilities, and there are a lot of extension packages available with specialized features, but it's really not as general as MATLAB or Python. I'm unaware of anyone using R for image processing, for example. As a language, it's very declarative, and the analyst doesn't need to understand statistics methods or their implementations in order to use them. That's great for beginners and convenient for experts, but can lead beginning/intermediate users astray if they don't appreciate the distinctions between significance and effect size, between different measures of significance/effect size, independence of variables, etc. Plots and visualizations in R tend to look nice when printed as PDF, but they're essentially non-interactive. R isn't general purpose at all, and personally I don't like its language conventions. I had the same experience with Mathematica, some people really like it and it's great for certain things, but I just can't stand the language. Back to R, I think the usefulness is great for statistics, less so for other tasks. Maintainability is OK - IMHO the language is not as intuitive as MATLAB or Python. My impression is that fewer people receive training with R, and it's a little less popular in general. It's the only one of these three languages I didn't see until grad school.

      My first choice for any new data analysis task is Python. I think it has the brightest future, and it's available to everyone for free. I'll use MATLAB if one of its built-in functions will save me a ton of time, or if I need to prototype something very rapidly (I guess it's still my strongest language). R I only use if I absolutely need something from one of its third-party modules. Lately, I've been experimenting with Julia, but it's not close to mature enough for my academic projects, let alone commercial ones. Sometimes I use external visualization tools, like LLNL VisIt, if I need to make high-quality, interactive visualizations of very large data sets. Hope that helps, sorry for the wall of text.

      --
      .: Semper Absurda :.
    9. Re:R vs. Python vs. other by AchilleTalon · · Score: 2

      Exactly, nobody really care that much about skills with a language when the set of skills you are really looking at is statistics. The R user is doing statistics while most of the python users don't know a fuck about statistics. So, if you are seeking for a stats guy and are too stupid to ask for it namely, you may ask for a R guy and get someone who knows stats. With python, you will get someone knowing python.

      --
      Achille Talon
      Hop!
    10. Re:R vs. Python vs. other by Aighearach · · Score: 1

      The thing about R is that the standard way of looking at data is in sets, and generally the most concise commands are applied to whole sets. So the utility is largely in these implicit loops and grouping that are along statistical lines of interest. One line of R might be 20 lines of C or python, but one line of C or python might be 20 lines of R.

      Because of that, it is mostly used on a command like REPL to generate one-off charts and diagrams after combining data sets by hand. It is also used as an embedded language for generating reports.

      R is an implementation of S, and they've been heavily used in academia for decades. There are lots of people with math or economics degrees who worked with S in school. (generally the language is called "S" and the most popular implementation is "R", but newcomers call the whole thing "R" because that is the direction it is going)

    11. Re:R vs. Python vs. other by cryptolemur · · Score: 1

      My experience is very different, but probably because I had to support R users in academia. Quite often they didn't really understand either statistics or programming -- they just read an article that used some freely available R script for something similar to their studies. And they happily demanded me to solve the unsolvable dependency hells, find resources that were able to survive scripts designed for completely different size of datasets and sometimes (although rarely) to explain what the results of their run were...
      In a few clear cases of attempting an statistical overkill we solved their problem with twenty lines of python and thousand times faster execution. In those cases everybody came out happier and smarter.
      I dislike R because it is a resource hog, and it hides a helluva lot of things that "my users" should actually be very aware of.

    12. Re:R vs. Python vs. other by shutdown+-p+now · · Score: 2

      In my opinion, if you're coming from a generic software development background, you will really prefer Python over R for pretty much anything that GP has listed. R is a very... quirky language, with an even quirkier standard library, and will quickly drive someone used to the familiarity and comfort of most mainstream languages nuts.

  4. Re:Embrace by ranton · · Score: 3, Insightful

    Embrace, Extend Extinguish

    'nuf said.

    I read the Embrace, Extend and Extinguish article on Wikipedia looking for examples of this actually happening, and it had to go back 15 years to find an example. I think you need to find new things to complain about.

    --
    -- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
  5. R is the wild wild west by bangular · · Score: 1

    The R ecosystem seems to be the opposite of Microsoft's traditional ecosystems. About the only thing R library designers can agree upon is "dataframe is good." Packages that try to put a consistent front-end on other packages (i.e. caret) definitely helps. However, even something as simple as "does this algorithm want a factor or dummy variables?" may require examining the source code. Other more subtle things like "Does it was the data to be centered and scaled?" may slip by.

    I hope Microsoft addresses this. As a researcher, a common task is to compare the performance of many algorithms against a new dataset or a new algorithm that you are developing, and it can be a pain to do in R. Weka is WAY more consistent in handling these sorts of things, but Weka only handles a subset of the tasks people do in R. Something as simple as style-guide docs would go a LONG way.

  6. Re:Embrace by bangular · · Score: 2

    Microsoft actually has no other product like R, so I would imagine the real reason they bought R was so they could add an additional layer to their data analysis tools inside SQL server. It's actually a no-brainer. Do a SQL server query, store results in a data frame, run a clustering algorithm against the data to see purchasing habits.

  7. Re:I R interested... by Koen+Lefever · · Score: 3, Insightful

    Billions of dollars, and they can't think-up a name that sounds a bit less stupid?

    'S' (for "Statistics" - originally with single quotes, those are usually being dropped now) is a programming language created in 1975-1976 at Bell Labs (which had a tradition of single letter named programming languages, such as C) on General Electrics GCOS mainframes and since 1979 on UNIX.

    R is an implementation of 'S' (with lexical scoping semantics inspired by Scheme) since 1993.

    --
    /. refugees on Usenet: news:comp.misc
  8. Re:Embrace by Hognoxious · · Score: 2

    Embrace, Extend Extinguish

    Not 'nuf. You missed a 'omma and an 'eriod.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  9. Re:Embrace by Anonymous Coward · · Score: 1

    They did not buy R though, it is an open source language that "Revolution Analytics" worked with, it would make more sense for them to try to tie this sort of function to exell, hence the suspicion

  10. Looks cool... but... yet another language tool? by ze_foster · · Score: 4, Insightful

    I remember back when Cobol was going out of style, and I was an early adopter of C++ (1987-ish). ADA was going to change the world, C++ was doomed to never go anywhere, and C was going to vanish. Yourdon wrote a book about the fall of the American programmer. I wept over my keyboard. I told everyone I was crying because my C++ compiler was so frigging slow. But I knew the world was going to change, that ADA was going to kill all the other languages, and I really loved working in C and C++. So I waited for the world to change. Prolog was a big deal about the same time, and I didn't want to miss out, so I jumped on it for functional. And the "wow" thing of the day was Expert Systems. They were going to change the world. So I wrote some interesting diggers with Prolog. And I waited for the world to change. In around 1992 I entered the CHICAGO beta with Microsoft in preparation for Windows NT (which was going to change the world). I even wrote a device driver for CHICAGO to operate a RHETOREX PCM telephony board, and a printer driver for an old ATARI thermal printer. Fun projects, actually. Didn't make a dime, though. OS/2 WARP came out around then. It was going to change the world. It was 1994 when I first saw Java. It was going to change the world. I looked at the language, and it didn't interest me: I had C++, and C++ was starting to grow. And I couldn't even imagine not having pointers, not being able to talk to the CPU or devices directly (sans imported libraries). 1995 came along, a friend handed me a stack of floppies (I think about 20), and installed SLACKWARE LINUX over my Windows partition. "This is going to change the world," he said. It was funny, but I really and for truly was convinced this time that the world would be changed, and I didn't wait. I jumped into Linux with everything I had, and I've been working in C and C++ in linux ever since. I'm not trying to be funny or anything. The truth of the matter is that I've listed only several languages here, but I've worked in at least two dozen others that probably most people have never heard of (e.g. SPL for MTM/32). I keep seeing language come and go, that are supposed to change the world. As a young engineer I'd jump on every new language that came out, but most of the time the language turned out to be raspy in some way, was good at exactly one thing, and pretty sucky at everything else. And here we are. 2015. I still work in C and C++ every day of the work week, but I don't see ADA anywhere, I haven't cranked a line of FORTRAN since 1993, I never had to write RPG for a living, I've avoided Cobol altogether, HASKELL never took off like it was supposed to (ditto EIFEL), MATLAB costs too much (even though it is a heck of a tool), I like Python and don't much care for Perl, and on and on and on. And I've debugged way more Java code than I ever wanted to, but I haven't written a single line of Java, yet. And here's what I wanted to get to... I opened up Slashdot today and found the OP's article, and watched the video. And you know what? THIS ISN"T ANYTHING NEW! Not the features, not the tools, not the results. It is yet another language, yet another IDE, and I'm seeing the same kind of features I was using back in the 90's. Funny thing... I use gcc/g++ for my compilers; I use VIM for my editor; and I do quite well. I hate IDE's with a passion; and any time I've been sentenced to use a product with "code completion" or "intellisense", I feel like I've joined some kind of Commune of the Damned. I've quit jobs to escape the transition so the baloney world of IDE productivity. Maybe that means I'm out of touch or old fashioned or "stuck in the 80's". But I've never wanted for a job. And the kids we interview today mostly know the current "hip" language(s) and/or IDE (Hey! lets write a web page, yah!), but if you ask them about superscalar architectures, or how to write a Fibonacci generator using C++ templates, or what a 3-way handshake is for, you get a deer-in-the-headlilghts stare.

  11. Re:Embrace by Aighearach · · Score: 1

    R already embraced, extended and extinguished S.

    There is nothing to be afraid of though, because R is already entrenched in serious use cases that are not otherwise reliant on MS. And MS doesn't have a monopoly anymore.

    As an R user who uses emacs, I see this as a good thing. Demand for R will increase, and the problems it is good at solving are real PITAs using C or Java or Python or whatever.

  12. Re:Wondering how long by Aighearach · · Score: 3, Funny

    Same amount of time it took Visual Studio to kill gcc.

  13. Re:I R interested... by TeknoHog · · Score: 1

    'S' (for "Statistics" - originally with single quotes, those are usually being dropped now) is a programming language created in 1975-1976 at Bell Labs (which had a tradition of single letter named programming languages, such as C) on General Electrics GCOS mainframes and since 1979 on UNIX.

    I guess back then they didn't worry about the name being easy to google, unlike today's new languages with unique and descriptive names such as "go".

    --
    Escher was the first MC and Giger invented the HR department.
  14. Re:I R interested... by ClickOnThis · · Score: 1

    The name 'R' was chosen partly as a play on the 'S' language that it emulates, and as a reference to the first letters of the first names of its first co-developers, Ross Ihaka and Robert Gentleman.

    --
    If it weren't for deadlines, nothing would be late.
  15. RStudio by jma05 · · Score: 1

    So why has no one mentioned RStudio yet? We just seem to be talking R. This is pretty much a clone of RStudio so far, with *slightly* better code-completion. MS tools for open languages rarely give anything I can't get elsewhere, just the same stuff over their own tooling. I remember them pitching Python tools as if they invented the first IDE with code-completion for Python while I had been using tools with equivalent functionality for 10 years prior.

    1. Re:RStudio by shutdown+-p+now · · Score: 2

      Full disclosure: I am a developer on both PTVS and RTVS (different but intersecting subsets of the same team work on both).

      So why has no one mentioned RStudio yet? We just seem to be talking R. This is pretty much a clone of RStudio so far, with *slightly* better code-completion.

      And a license that is not Affero GPL v3.

      I think you will find that there are other differences that you may find interesting and useful beyond that, though. The video is a very brief overview, and doesn't show everything in detail, but some things are already visible. For example, notice how at 1:15, the history brings up the entire multiline expression, that is editable as such (rather than scrolling through each individual line of it).

      MS tools for open languages rarely give anything I can't get elsewhere, just the same stuff over their own tooling. I remember them pitching Python tools as if they invented the first IDE with code-completion for Python while I had been using tools with equivalent functionality for 10 years prior.

      With respect to "first IDE with code completion" - I'm not aware of it having ever been pitched like that.

      What it had been pitched like - and what was true - is that it's the IDE with the best code completion, especially on large volume of pure Python code (as opposed to C modules where all the completion data comes from doc comments anyway). Until it and PyCharm showed up, most Python IDEs were doing very basic completion based on function names and such.

      The big difference we made was adding an analysis engine that actually keeps track of the flow of values throughout the source code, across module boundaries even; and tracking more than just classes, but also e.g. individual values of tuples and dicts. This enables good completion for many common dynamic patterns that conventional identifier-matching approach cannot handle. And because the flow goes both ways, you can, for example, call a function in one place of your program, and then when you're editing the function, you will see the types of arguments, and the corresponding members, based on all its call sites.

      Have a look at this, and tell me which IDE that you've used 10 years ago could do it back then. Heck, most Python IDEs out there can't do it today! Code completion for a dynamic language is hard.

      As far as "give anything I can't get elsewhere" - how about this?

    2. Re:RStudio by jma05 · · Score: 1

      OK then. I stand corrected. I really appreciate you taking the time. I was recalling from a conference/podcast from some years ago where an MS rep was speaking on how surprised all the Python folks were at a Python conference at the very idea of code-completion for Python. But it was unfair for me to talk of it as if it was an official pitch because I have seen no docs to that claims. That ticked me off then. Perhaps it was just one rep speaking off the cuff.

      I will take a look at the tooling again. Back then, I was comparing it to PyDev and WingIDE (with much earlier and more basic use of code completion use dating back to PythonWin IDE and SPE). These days, I am on Spyder (for better IPython integration for interactive work, than for code-completion) and PyCharm. I haven't given a look at MS tools for Python in at least 5 years.

  16. Re:Embrace by shutdown+-p+now · · Score: 1

    Also, R is GPL.

  17. Re:Wondering how long by shutdown+-p+now · · Score: 1

    Which is an especially ironic comparison in light of e.g. this.

  18. Re:Embrace by thegarbz · · Score: 1

    That's not entirely the way I remember it. Microsoft didn't touch ODF, didn't extend or extinguish it. They tried to bypass the need for it.
    There were calls for an open and standard format from many fronts and then ODF got a foothold. Microsoft then said but look we're open and standard and then quickly rushed OOXML through the standards committee, got rejected, made a minor amendment, and then rushed it through again and rigged the system to get it approved, all the while poorly supporting OOXML and barely supporting ODF at all.

    That's not Embrace, Extend, Extinguish, that's just typical big player trying to stamp out small player through influence. It certainly wasn't like the complete and fully functional adoption of standards, extending them to become number one, and then retrospectively making them incompatible which is what the old process was like.

  19. Most insightful comment in a long time by tomhath · · Score: 1

    I don't have any mod points, but this is the most insightful comment I've read on slashdot in a long, long time. Granted, it's probably Marketing 101 that every MBA knows though.

  20. Re: Embrace by Hognoxious · · Score: 1

    First, R is an open source language.

    Well, there goes my "pirate R" joke.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  21. Re: Embrace by jonnyj · · Score: 1

    No-one will use Excel instead of R for big data analysis. Excel maxes out at 1m rows and spreadsheets that size takes minutes to open while R takes seconds or less. All R users also use spreadsheets as a complementary tool and, in a commercial environment, that's always Excel.

    Microsoft's vision for R appears to be completely different. They want to integrate R with their existing big data tools - Azure, SQL server, etc - to put their offering ahead of the likes of Amazon and Oracle.

  22. Re:Embrace by turbidostato · · Score: 2

    "That's not entirely the way I remember it. Microsoft didn't touch ODF, didn't extend or extinguish it. They tried to bypass the need for it."

    You don't think Microsoft people are stupid, nor their marketing guys haven't thought on what made Microsoft a successful company and what "embrace, extend, extinguish" really means and how it works, right?

    Embrace: Oh! you people really want "open standards"? Like ODF? I'll give you one.

    Extend: Here you have an open standard just like you want them: docx. And I'll make sure I get docx to be approved and to be in a position of being chosen by EU governments and whoever says that needs and open standard. Certainly I'll add little things to these kind of standards, like binary blobs or "this is to be implemented just like in Word 6" paragraphs, so it becomes impossible to re-implement.

    Extinguish: Oh, by the way, in the process of making docx an open standard, I'll corrupt the standard-approval process so much that no one ever will ask for anything-open again.

  23. Re:Embrace by Rob+Y. · · Score: 2

    In addition, they 'embraced' ODF itself by providing an ODF format option in MSOffice that didn't work with any other ODF implementation - by intentionally 'interpreting' vague aspects of the spec as 'anything but what's already been implenented in OpenOffice'. At the same time, releasing an MSOffice implementation of OOXML that differs from the published standard.

    Not exactly playing nice. More like polluting an existing standard while waiting for their monopoly magic to entrench their new pseudo-standard. Kind of like Java vs C#. And for the C# fans out there, it's not necessarily that their stuff isn't ever any good (though if excess complexity is a negative, OOXML's gotta be one of the worst standards ever). The point is that Microsoft could well embrace true open standards - even while keeping its implementations closed source, and even possibly coming out on top with the best implementation. But time and again, they try to subvert open standards. The simple fact that they're losing some of their ability to do it these days doesn't change a thing IMHO.

    --
    Posted from my Android phone. Oh, I can change this? There, that's better...
  24. Re:Embrace by thegarbz · · Score: 1

    Historically embrace has been about specific compatibility with the product or protocol, not some standard business activity of creating a competitor to something that exists.

    You're not remotely describing embrace extend extinguish as it has been applied to the Microsoft model, but you're describing standard business practices, which given when Microsoft came up with the strategy was very different.

    But while we're debunking, giving people exactly what they want which a competitor has already got or is in the process of is not extending.
    Doing something feely about a process without actually doing anything to destroy or make the competitor's system incompatible is not extinguishing.

  25. Re:Embrace by thegarbz · · Score: 1

    Yes this was more like it. Except they only embraced and attempted to extinguish. They missed the extend step which is critical as you need a critical mass and a critical number of users tied in to your system before you attempt the final step.

  26. Re:Wondering how long by Aighearach · · Score: 1

    That is the opposite of "irony," though.

  27. Re:Looks cool... but... yet another language tool? by jader3rd · · Score: 1

    It is yet another language, yet another IDE

    I don't think you can call Visual Studio, yet another IDE.