Official support for Python, Node, and Docker in Visual Studio. Full Linux shell on Windows. You know how almost every developer has a Macbook? I think that might change.
*web developer
I don't know to many good systems engineers or security/forensics people who don't use Linux.
Most embedded stuff I work on has less than 100kb memory. No way in hell it could run an OS.
But if you meant programming the devices... So many vendors compile chains simply don't work on Windows and are badly hacked up versions of gcc.
In my experience the decent vendor provided setups that actually work are all on Windows. STMCube and Keil for ST, Atmel Studio, Code Composer Studio for TI.
Yes you can absolutely compile on *Nix using GCC, but none of the vendors target their tooling for anything other than Windows.
Atmel [0] absolutely does.
ST [1] does.
TI [2] does.
You want to run that one by me again?
[0] http://www.atmel.com/tools/atmelavrtoolchainforlinux.aspx
I didn't know that ST provided STMCube for other platforms. That's the project generation tool (which is great), it's not the IDE debugging system you get with Keil (which is also great).
You've linked the 'lite' TI toolkit. CCS is available on Linux, but is even less reliable than CCS on Windows.
I'm not trying to argue that all development is done on Windows, or that it's even the best platform to do it on. I am merely pointing out that Windows is the first platform that is targeted for development by the big vendors. Also (more anecdotally) the majority of the companies that I work with and encounter do their embedded development on Windows, until you get to the size of part that is running some form of Linux.
Anecdotally, I just had Atmel recommend a switch from Windows to Linux, as their compiler toolchain "can work better there".
This space is more diverse than just Windows, and growing in that direction more and more. Atmel, Cadence and Qualcomm are just a few who welcome you with open arms.
This is across three separate startups and companies. It's infuriating.
Microsoft's definitely doing the right things these past few years so I'm definitely excited for the future. I suspect the we'll see more people adopt .NET before we see Mac/Linux though.
Example: http://www.pitt.edu/~naraehan/python2/faq.html Read the question "How do I install NLTK 3.0 (Windows)?"
edit: most of the steps in the instructions you linked to are how to install pip, which is now included if you install the latest version of python. So on a current version of python the instructions should reduce to run:
pip install pyyaml nltkIf you look at the nltk site's docs on installing on Windows [1], you see there isn't even any mention of anaconda. In fact, there is basically a set of links asking you to go and figure it out for yourself. Either the maintainers of the NLTK project are not aware that there is a better way (using anaconda like you suggest) or they are aware but haven't seen any good reason to update their documentation.
So why do they (and broadly the 'ecosystem') not update their docs to be more Windows friendly, or to even develop their software so as to be pain free to install on Windows in the first place?
That is the ecosystem effect at play here. How many people are likely to stumble on to your comment when they search "install nltk on windows"? On second thoughts, with my double quotes and all, now they might :-)
...in Silicon Valley bubble?
In my experience, Linux in Virtualbox is a lot faster then WSL. I'm not talking barely noticeable here, I'm talking operations taking 0.2 seconds vs 10-15 seconds (on an SSD) in the worst case. It's literally faster for me to do shit in Linux and rsync it back to Windows than it is for me to deal with WSL at this point. The only overhead is memory and CPU, of which I have plenty. I don't have plenty of time.
>far easier to start
I just keep my Linux virtual machine open, so it's just an alt-tab away. At work, I run it the other way around (Windows as the virtual machine). It's basically the same story.
There was a benchmark on http://phoronix.com which proves my point.
My previous attempt a while ago to run Linux on a Win7 host via Virtualbox was unsatisfactory because the performance of Linux's GUI was very slow I tried to run PyCharm but it was painfully slow with noticeable lag.
The only things I can think of that might be special about my setup is that I generally: 1. Run the VM off of a different physical disk than the host OS (only necessary if you're using HDDs) 2. Allocate generous amounts of RAM (4-8gb) even though very little RAM is required. 3. Use machines that have 4+ cores.
So maybe the biggest "pro" for the traditional linux command line way is "inertia" - but I'm sure someone else has a much more satisfying answer than mine
That does not replace continuous integration on a real Linux host but that might be a good way to do interactive development and debugging of cross-platform code directly on windows.
Which windows versions are we talking? Do they all have equally good support or are previous (Most people are still using Win7) versions crippled in some way?
actually - scratch that: its limited to the now coming version of windows 10. there are (to my knowledge) no plans to ever port it to any other system. this was stated in one of the earliest interviews about it iirc
It is not expected to be back-ported to Windows 7. (Why would it be?)
On the other hand, remember on the scale of computing, powershell is fairly recent. We used to have batch files and the 'cmd' shell, and they were fairly awful.
[1]: https://github.com/git/git/blob/master/contrib/completion/gi...
I use Microsoft products since MS-DOS 3.3 and my path into UNIX was via Xenix and DG/UX, before GNU/Linux was a thing.
Being a developer doesn't mean using UNIX, rather producing software with whatever tools our employer uses for producing business value.
Powershell is much better concept for a CLI, taken from Lisp and Smalltalk REPLs than a pure UNIX shell.
Trying to write powershell scripts without the ISE (Interactive Scripting Environment) is very hard.
Also powershell is not suitable to just open and "bash" thigs out at it. For example to download a file, you need to remember the corresponding .net package. Or to list a directory, you use -without the alias- get-child-item etc.
I think the verb+noun syntax and the ability to use all .net packages are awesome. But you first need to do your research, find the modules, look up the required parameters, put those in a file etc.
In bash, most linux users just "bash" things out, if you don't know something no problem, you just "man" that.
Although the same thing could potentially established with powershell through aliases and extra binaries/scripts for utilities like diff/curl, powershell in its nature is a different beast.
I really like powershell, writing scripts with the ISE and the object oriented design are really powerful. That's why I think powershell resembles smalltalk rather than lisp.
In order to write powershell comfortably and efficiently you need to use its development environment with GUI.
While FOSS Lisp environments are pretty bare bones text CLIs, that is not how Lisp should like since Xerox PARC, TI and Genera days.
Sadly Lisp IDEs are all commercial, but the experience is pretty much Smalltalk like, or even better, given that they also AOT to native code.
Now I see that there is. The two lisp books I read (Paul Graham's ANSI Common Lisp and gigamonkey - Practical commmon lisp) always used text editors.
Whereas for smalltalk I installed a VM (scratch) that included a GUI.
And also even in an old issue(80s?) of Byte magazine dedicated to smalltalk there were extensive toolings with GUI. https://news.ycombinator.com/item?id=7052479
"By resembling smalltalk" I wanted to mean that the user needs to interact with a development environment to get the full benefits of powershell. And that this is in its nature.
Nevertheless, I stand corrected. I never knew that there were lisp implementations designed to work with an IDE.
Lisp stop being based on text mode environments in the late 70's, when it moved out of mainframes into systems with graphical displays.
Many of the Smalltalk ideas were inspired from Interlisp-D, the Lisp workstations used at Xerox PARC.
Text mode environments for Lisp is a GNU/Linux thing.
If you wish I can provide some links.
Thanks for pointing out, I'll do some research on this topic.
If you have links easily accesible to you, I'd appreciate them, if not no problem at all.
Which really makes it a questionable choice as a scripting language, IMO, and I say this as a fan.
Or as said on Quora some time ago: "A fool with a tool is still a fool."
It's 2017 and we're still distracted by obcessing over tools, and neglecting the real goal. That is results.
NO One uses a product because of the tools (the fools?) used to build it.
In my view powershell was not designed as a shell, but more like programming tool specific for Windows administration with a REPL. Powershell looks designed for .NET programmers intending to write small administration scripts and occasionally drop to interactive shell. Bash and other Linux shells are designed for interactive use with programming features bolted on. All this makes bash much better alternative for glue between various tooling, exactly what a developer needs
I am quite happy just with XCode, Swift, Objective-C and OS X Frameworks.
It does look a bit like Apple and Microsoft are on a road to switching their attitudes and roles. Who knows.
Lack of POSIX support only bothers me when trying to compile software targeted to pure UNIX systems.