it's not like installing python is any more complicated than any other piece of software that needs to be installed. Windows users have had no choice but to do that for decades.
You're saying this like it's a good thing.
If someone decides they want to run a custom ruby or python script the least difficult aspect of that decision is installing the interpreter. For example, I was dealing with someone yesterday who decided they wanted to learn how to write apps for Android. Without even seeing a single line of code (or even knowing which language they would have to learn!!) they had already successfully installed Android Studio and Jetbrains IDEA.
Without coming across as some gatekeeping greybeard, I think anyone who has even a glancing interest in programming would agree if you can't follow a one-line/click installation instruction you may want to find a simpler tool for the task than writing your own code from scratch.
The hardest part for lots of people in learning to program is getting over the idea that programming is for Special People, or possibly Wizards, who know lots of incantations which are beyond mere mortals. Please stop trying to convince them they're right.
Source: I've taught lots of marketing people, admins, call center techs, etc to program in PowerShell or system Python.
Installing the interpreter is nothing special. It should be taught as such.
I definitely understand that the installation process for things like python can be confusing to non-programmers, but I think this is a bit disingenuous. You don't have to learn a build system to install it; python was the first programming language I ever learned, and I used it years before I ever even had any idea what a build system is.
If you can't even download an installer and run it, then yeah, maybe not quite ready for programming either.
Please forgive my snark, but this would be exactly my thought process as a reasonably competent computer user who wanted to learn Python.
When I was six years old, learning to program involved turning on the computer and typing
10 print “hello”
run
$ echo "hello"
Even on Windows you can open the browser console and do
> console.log("hello")
The problem is not that the environment is not available or setup is too difficult. The problem is that there's now way more competition from other shinies readily available (web, apps, games, videos). Even if you boot your home PC straight into a terminal, as soon as the kids find the way to a web browser it's game over. Even on 1980s home micros, if the kids got access to (pirated) games, practically none would volunterily keep on programming BASIC.
They previously deprecated Java runtime for similar reasons. And I can’t really blame them, roadmap is crystal clear now, they prefer to assign ressources to develop Swift/Swift UI and improve tooling for native code development.
Mind, there's still a command line and shell built-in, which I consider far more important.
I'm generally against bloating simple apps, but you'd never see this unless you opened a .py file (or .sh, .rb, etc), and if you open a .py file, you probably want syntax highlighting.
No? Oh well, I guess programming is hard, IT was right. Ok, back to excel...
You'd have to be very bored and unmotivated to not install a programming language if you had even the slightest motivation to program (IOW, not a normie consumer). I understand what you're saying, but I just don't see how this would be a huge barrier to entry.
This feels the same as when Microsoft removed QBasic from Windows 98. So many kids at home missed opportunities to be exposed to programming from them on, until a certain Terminal application appeared in Mac OS X and began to pique young curiosity again (mine included).
zsh/bash/ksh93, tcsh, awk, sqlite3, elisp (assuming emacs survives for now) and javascript console. I don't know why you'd want to limit things to pre-installed command line interpreters though.
> You have the shell itself, but that’s hardly enough to write anything cool.
What kind of cool things do you envision the curious beginner to write, using only the current preinstalled Python/Ruby/perl, that they can't do with the remaining interpreters that I mentioned?
What about the iconic 4th grader "greetings and cool things" script? Here's something like what it looked like for me (on the IBM PC in my classroom):
5 CLS
7 RANDOMIZE TIMER
10 PRINT "Hello there. I'm a computer. What is your name?"
20 INPUT G$
30 PRINT "Hello "+G$+". You are welcome to computer land."
40 PRINT "What would you like to do today?"
50 PRINT "1) Make noises"
60 PRINT "2) Make a maze"
70 PRINT "3) Exit"
80 PRINT "Enter your selection:"
100 INPUT S$
110 IF S$="1" GOTO 200
120 IF S$="2" GOTO 300
130 IF S$="3" GOTO 400
140 PRINT "Try again."
150 GOTO 40
200 SOUND 20+(RND*20000), RND*3
210 GOTO 200
300 SCREEN 1
310 IF RND>.5 THEN PRINT "/"; ELSE PRINT "\";
320 GOTO 310
400 PRINT "Bye."
10 SCREEN 9
20 CLS
30 COLOR 1, INT(RND*10)
40 SOUND 20+(RND*5000),.2
50 GOTO 30
My main gripe with Windows NT was that it would go back to the NT screen saver -- I couldn't get it to stay displaying my program, because there wasn't any true DOS mode.
clear
echo "Hello there. I'm a computer. What's your name?"
read G
echo "Hello $G. You are welcome to computer land."
while true
do
echo ""
echo "What would you like to do today?"
echo "1) Say something random"
echo "2) Make a maze"
echo "3) Exit"
echo "Enter your selection"
read S
if [ "$S" = "1" ]; then
say $( head -n $((7*RANDOM)) /usr/share/dict/words | tail -n 1 )
elif [ "$S" = "2" ]; then
for i in {1..3000}; do
if (($RANDOM>16384)); then printf '/'; else printf '\'; fi
done
elif [ "$S" = "3" ]; then
echo "Bye."
exit
else
echo "Try again."
fi
done
I honestly don't see how a Python or Ruby version would be much better than a shell version for this. Perhaps you can show by example?
I still contend that Ruby and Python are far more accessible than shell scripting, because they are very popular, especially Python, cross-platform, and less arcane.
import os
import random
import sys
os.system("clear")
print "Hello there. I'm a computer. What's your name?"
G = raw_input()
print "Hello " + G + ". You are welcome to computer land."
while True:
print ""
print "What would you like to do today?"
print "1) Say something random"
print "2) Make a maze"
print "3) Exit"
print "Enter your selection"
S = raw_input()
if S == "1":
F = open("/usr/share/dict/words").readlines()
W = random.choice(F)
os.system("say {}".format(W))
elif S == "2":
for i in range(1, 3000):
if random.random()>0.5:
sys.stdout.write("/")
else:
sys.stdout.write("\\")
elif S == "3":
print "Bye."
exit()
else:
print "Try again."
otoh, pointing people towards messing with system python... well, it's a trap. And they will get burned, and it will be a nightmare to straighten out.
In fact they probably don't even know what "deprecated" means.
It wasn't that long ago that Python 2.7 was the default on the Raspberry Pi. (That may still be true - I haven't checked recently.)
There's a huge ecosystem of Python 2.7 tutorials, introductions, and sample code out there. Very little of it is prefaced with "Of course you should use Python 3 now."
Compare that to "brew install python". Now you have the most up to date version, with the right permissions for your user, that you can always brew uninstall and reinstall later if you need a different version or a clean install.
That is the wrong way to do it. Just install pyenv/pipenv to manage different Python versions. It's dead simple to maintain system Python, Python 2.7x, and Python3.7.3 that way.
You can do that anyway, `python` is always Python 2 (except on Arch where `python` is Python 3 and the Python 2 executable is `python2`) and the Python 3 executable is called `python3`. `pyenv` is more for keeping multiple minor versions of the same major version (e.g. Python 3.6 and Python 3.7) around at the same time.
Actually, it doesn't have to be multiple minor versions, it can be any version–major or minor. It can even be Iron Python or Jython. Anyway, the point is that it's smart not to touch system Python on macOS. So when I run:
`$ pyenv versions`
My output is:
`system
`2.7.16
`* 3.7.3 (set by /Users/wyclif/.pyenv/version)
Dead simple and easy to use. Much better than overwriting and reinstalling when you need a different version for a specific project.
The alternatuve to the current decision is for apple to assign people to keep updating python and provide previous versions as packages like linux distrib does. But it has never been the way they do business.
The problem is doing something simple, like an installer. bash => zsh: fine. You can still install with the old /bin/bash. but for many cases a shell is not enough, and then you have to compile something statically for a trivial dynamic task. Which makes the download 10x larger. Not cool.
What do you mean?
When you build and package things for production you should create an environment. This ensures the packaging the right versioning of requirements for build.
Say you build using the system version but use packages based on another version. It may work for you but probably won’t work elsewhere.
The problem comes about when someone does the following:
- creates python project
- pip install some_package
- import some_package
Turns out some package was already in the path but a different version
- proceeds to test and build with the assumption of some_package @ newer
- all tests pass
- ships project with requirements of some_package @ newer
Someone attempts to use the package but it doesn’t work.
That’s what doesn’t pass muster to me. Why should I work on my CSS styles in an environment with the production database? It will be much slower than just working on that package in my desktop environment with just enough scaffolding the code runs.
But maybe I’m not understanding your suggestion.
What does connecting to a production DB have to do with any of that?
https://developer.apple.com/documentation/hypervisor https://github.com/moby/hyperkit
Does anyone actually use Docker on Mac?
Xhyve is more of a proof-of-concept than a production-ready tool.
What? We use it at work every day for local development, and my previous employer did as well. It has issues, definitely, but they have more to do with Docker than with xhyve.
I use it extensively. It is a desktop product however; it you aren't expected to put a swarm of MacBook pros into production.
Calling it “not serious” is quite wrong.
Sure, for development tasks.
Further, there's no decent solution for shipping a macOS container image to run in a VM. Linux, yes, Mac, no.
Finally, good luck getting your virtualized macOS app to interact reasonably with your main OS (no drag and drop, no OpenGL, etc.).
I would rather chroot.
IIRC the Docker implementation for OS X runs a tiny, carefully-configured Linux VM transparently in the background. This isn't that dissimilar from the Windows Subsystem for Linux from a user standpoint.
I've done plenty of Docker work on OS X; the only real weirdness is that you're running Linux in the containers and OS X outside. Eventually, though, before switching completely to a native Linux desktop, I moved deeper into the containers and would barely ever see the OS X command prompt any more.
All the interesting container stuff is on other platforms.
It might be out of fear, maybe because apple doesn't want macos to be virtualized.
It would be really nice to have say the current xcode in one container and a dev xcode in another. It would be nice to farm work out to a lot of machines.
or a dockerfile like: FROM macos:10.14
RUN installer xcode... RUN xcode-build myproject
Given that Apple is (or at least was) one of the biggest users of Mesos in the world and have invited me to interview specifically on the back of the operationalization of containers, I'm guessing that the staggeringly bright programmers they've got probably understand containers.
Just a little hunch, you know?
Maybe it's another "you're not the target market" kind of thing.
The point I'm getting at is that folks on other platforms have lots and lots of options and apple doesn't provide any.
The macOS EULA explicitly allows macOS to be virtualized if you do it on a Mac running macOS.
> It would be really nice to have say the current xcode in one container and a dev xcode in another.
This is the entire point behind xcode-select. I currently have Xcode-beta and Xcode on side-by-side on my machine, and they pretty much coexist.
- I think xcode-select just modifies a .plist.
They do offer a set of "primitives" for virtualization, which can be hooked into by third-party solutions like Docker if they want to do so.