Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

developer.apple.com

Post reply on HN
Print view View original

411–420 of 450 posts

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#411

Post by plorkyeran »

eropple wrote: post #392
saagarjha wrote: post #151

Earlier quoted context omitted.

> apple doesn't want macos to be virtualized. 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.

Can you run them simultaneously? I've never tried.

Yes, but there are some issues. For pure macOS development it's usually fine, but anything touching the simulator breaks if multiple versions of Xcode try to use it at the same time. I quickly got in the habit of always exiting Xcode before starting a different version.

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#412

Post by __full_pint »

erikpukinskis wrote: post #401
__full_pint wrote: post #137

Earlier quoted context omitted.

I’m not OP but: 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.

But you wouldn’t want to develop in that environment, right? You do integration testing in it, but development should largely happen in small modules, with unit tests and test data, no?

Of course you do that type of testing.

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.

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#413

Post by erikpukinskis »

__full_pint wrote: post #412
erikpukinskis wrote: post #401

Earlier quoted context omitted.

But you wouldn’t want to develop in that environment, right? You do integration testing in it, but development should largely happen in small modules, with unit tests and test data, no?

Of course you do that type of testing. 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 pac…

Right, that’s why you do integration testing (manual and automated) but are you saying therefore you should do all development inside a production environment?

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.

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#414

Post by em500 »

TimTheTinker wrote: post #399
em500 wrote: post #311

Earlier quoted context omitted.

There still Swift Playground, Safari JS console, not to mention old fashioned zsh/bash/ksh to tinker with. The part where the removal of the default macOS Python/Ruby/perl (which don't even have autocompletion) kills her curiosity seems far fetched.

What command-line programming language interpreters are left when those are removed? You have the shell itself, but that’s hardly enough to write anything cool. 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…

> What command-line programming language interpreters are left when those are removed?

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?

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#415

Post by TimTheTinker »

em500 wrote: post #414
TimTheTinker wrote: post #399

Earlier quoted context omitted.

What command-line programming language interpreters are left when those are removed? You have the shell itself, but that’s hardly enough to write anything cool. 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…

> What command-line programming language interpreters are left when those are removed? 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 beginne…

> 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."
That kind of stuff is perfect for Ruby and Python. I don't envision kids getting that far with shell scripts, awk, sqlite3, or elisp. They might with HTML and JavaScript, but that requires learning HTML as well as JS and is sandboxed in the web browser; it's also not as "Cool! Look what I can make the computer do!" as messing around in the terminal. (Note, I’m glad BASIC isn't as available anymore -- we're not getting kids into certain bad programming habits early-on, like use of GOTO. But BASIC would still be more approachable than shell scripting, awk, etc.)

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#416

Post by Wowfunhappy »

IshKebab wrote: post #140
Wowfunhappy wrote: post #94

Earlier quoted context omitted.

Apple could solve this problem by including python3 with macOS...

Presumably someone said that about python 2 back in the day and that turned out to be a pretty bad decision.

Isn't this the same as saying, we should never include any software, lest it become outdated someday?

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#417

Post by tty2300 »

kowdermeister wrote: post #388
ffdjjjffjj wrote: post #341

Earlier quoted context omitted.

So which companies are actually doing RoR development on Windows? Do they also deploy to Windows Server (?) in production? I guess I live in multiple bubbles because I’ve worked for tech companies in several different major metros and I’ve never heard of this as a mainstream thing.

It is not like that. My point is that there's a barrier to entry to RoR that you should own a Mac. I gave up because my home setup is Windows based and I won't change it for the sake of a hyped framework or tool. But none of this is surprising considering where RoR is coming from, I'm not sad or upset about it either :)

You don't need a Mac. RoR works perfect on Linux as well.

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#418

Post by __full_pint »

erikpukinskis wrote: post #413
__full_pint wrote: post #412

Earlier quoted context omitted.

Of course you do that type of testing. 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 pac…

Right, that’s why you do integration testing (manual and automated) but are you saying therefore you should do all development inside a production environment? 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…

OP was referring to containerizing your environment for package development.

What does connecting to a production DB have to do with any of that?

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#419

Post by silversconfused »

agumonkey wrote: post #330
t0astbread wrote: post #313

Earlier quoted context omitted.

Weird, I thought the Unix-likeness was a huge selling point of macOS ("the most user-friendly Unix on the market")

for the tech crowd that's for sure, but how much is it for their overall market ?

The jump from os 9 to OSX was about as significant as the jump from win9x to the NT based XP. Suddenly, multitasking stability without a huge dollop of luck was a reasonable expectation.

Re: macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

#420

Post by wyclif »

Sean1708 wrote: post #376
wyclif wrote: post #323

Earlier quoted context omitted.

Sure you can do that, but why would you want to install and re-install different versions of Python depending on what you needed at the moment? Pyenv manages all that nicely. You can have 2x and 3x side by side without having to reinstall and uninstall anything.

> You can have 2x and 3x side by side without having to reinstall and uninstall anything. 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.

`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.

Post reply on HN