Git automatically deletes unreferenced objects eventually. Or you can trigger that immediately using git gc (“gc” for “garbage collection”).

/

That was a lot of stuff. In general, when I’m getting started with a new toolchain, I will:

  • Pick a popular editor for it and kit it out with whatever plugins the Internets likes. (Often that editor ends up being VS Code or Atom these days.)
  • Set up a linter to get style and gotcha guidance, and make sure it works with the editor.
  • Find a testing framework and some examples to crib from. Get that working so I can “ratchet” my progress on getting something working. (It never gets worse, only better.)
  • Find a logging system with channels/systems and levels, so I can dial up and down log verbosity as needed without stripping out the trace that will let me scry what happened from logs.
  • If needed, or if it’s easy (like browser JavaScript), set up and get the basics of a debugger working. I want to know how to say “stop here”, how to look at the data that’s around at that point, how to go step by step or just resume running code, and how to change data and interact with my program.

That gets things “good enough” that I rarely bake in more clever visualization and operator support.

I expect this to take a day or two when I start something completely new. I also look for style guides and exemplary code to read when I’m not actively coding, as part of acculturating.

Sounds like what I’d split up into visualization (presenting the data you care about in a meaningful way), introspection (making it easy to look inside the state of a program), and rapid feedback (“what’s this do? does this even work?”).

There are environments that try to give you those things, in varying mixes. The specific tools you’d reach for tend to vary by language. But if you get some poking around the Web time, maybe look into:

  • Jupyter / IPython Notebooks: Lets you embed “cells” of code into a notebook. The output shows below each cell. The latest version lets you “get inside” the cells even more so than before. Started with Python, but now supports seemingly everything.
  • Light Table: An editor that tries to provide simultaneous docs and feedback as you edit.
  • Elm: A Web programming environment that provides rapid, helpful feedback when you go wrong and lets you record, replay, and rewind event history as you edit the program.
  • IPython: A “smart” shell environment for Python.
  • pry: Lets you poke around inside a paused Ruby program.

More general tool categories:

  • Whatever sort of “debugger” comes with your toolset. These tend to let you look around and try stuff from inside your program.
  • Whatever sort of “REPL” comes with your toolset. This lets you try stuff, finetune it, then graduate the working snippet to your file for safekeeping.
  • Editor modes / extensions. These can provide smart autocomplete, docs for everything in situ in your editor, and “run this snippet of code” or “throw this in a REPL so I can play with it”.
  • Testing systems. Think of them kinda like a primitive Jupyter notebook if you’re working by example (given this, when I do that, then it oughta…), or an evil genius tester if you’re doing generative/property-based tests (given any filepath you can throw at this function…).

The truth is most programming environments are painfully primitive, and it sometimes seems a miracle we ever get anything working. There are some interesting “forks in the road” that might better match your needs, in the form of image-based systems like Pharo.

Re: languages, most new languages aim to be general-purpose and so are not so task-focused as say AppleScript or Snobol. It’s often then not the language itself that gives the benefit in switching languages.

Some languages are insanely complicated of themselves, but as someone who picks up languages easily, I want to direct your attention to what I view as both the source of much of the benefit and the time cost of switching languages: Mastering the standard library.

Languages with ridiculously little syntax, like Lisp, Forth, and Smalltalk, help make this distinction clearer if you try learning them. Extra clear when there is no single standard library, or that library is anemic and there’s a panoply of third-party options (hi, JS + NPM!).

(The main reason most people switch languages is probably neither language nor stdlib, though: It’s instead “what platform does it target” and “what option has the biggest community & docs for my use”.)

Seems OK here. Not lightning, but nowhere near slow enough I bail.

For expensive, there’s a $1 USD/month VPS here: https://www.chicagovps.net/services/cloud-vps

For advanced, that’s no help. I did find a VPS easier in some ways than shared hosting due to more freedom to poke around and see what’s wrong. No need to work at arm’s length using some weird control panel that is nothing like the standard interfaces an OS provides. But if I wasn’t already comfortable doing that sort of poking around, it probably would have been harder, not easier, since there’s no overall, focused list of what you can do. :\

/

That sounds good and frustrating. I’ve never bothered with Cloudflare.

I did use Dreamhost for shared hosting for a bit before migrating to a VPS on Digital Ocean. I recall finding the Dreamhost control panel kind of overwhelming and also hard to wrangle.

I now just use Dreamhost as registrar. Hurricane Electric handles my DNS, and Digital Ocean gives me a VPS to point the whole shebang at.

/

I found I am way more likely to use bagged tea, so I periodically go through and bag a bunch myself. It’s kind of calming to do.

Now that the weather is warming up, though, I pretty much just make iced sweet tea. Might shake it up with some hibiscus tea after the latest pitcher gets drunk, though, come to think.

/

Because Microsoft do?

Though I’d be tempted to switch purely for variety at this point, if I didn’t have to have a working Xcode.

/

They’re about matched to residential “broadband” speeds IIRC. Which are also mostly pretty crummy & expensive in the US.