The Joys Of Programming

Tried codingame, yet?

exercism.io
I like using their sets of examples to motivate my learning. Once you submit a solution you can see other people's. See what is idiomatic for that language.

because my previous jobs have had me working in Java, Node.js, Ruby, PHP, C#, and a few other languages but never Python!

If you've worked with that many, you'll find Python exceptionally easy. The language itself is simple, and the available libraries are typically written to a very high usability standard, and tend to be very nicely designed. It's a very pleasant, comfortable language.

It's not very fast, and the way it evolved means that the internal implementations of things end up being kind of weird when you examine them (ie, damn near everything is a dict, no matter how it looks when you use it), but those are more artifacts of the way they added features to the original design (like object orientation, which wasn't in the earliest versions), and really none of that is visible until you start seriously digging. And none of that is a problem, even when you do, it's just.... kind of, "huh, what an odd way to do that" was a thought I had pretty frequently. Perfectly fine, mind, just not at all what I was expecting. (dicts, dicts everywhere.)

Ruby covers many of the same bases, and since you learned that one first, you may always prefer it. But I'm pretty sure you'll find yourself productive in Python quite quickly.

And I’m going the other way. From a Python shop to a Ruby shop (and Chef instead of Puppet) so I have some learning to do myself.

I’d recommend going to https://learnxinyminutes.com and looking at the Python primer. Most of those are super clear, and since you’re already a Software Dev, it might help to see the syntax in an easily digestible format.

Goodness knows I’m hitting that up and book hunting today/tomorrow.

My biggest Python advice is to use a text editor that understands the indents, which will save you a lot of time lining stuff up while you're editing code. (I used Spyder and Jupyter Notebook for a lot of my personal stuff, via Anaconda.)

And if you're coming from Java/C# there are going to be a lot fewer classes than you're used to.

Other than that, the basics are mostly the same, just with the indents implying stuff the curly braces would make explicit.

(Weirdly, Lisp has approximately the same indenting as Python, when it is formatted according to the common conventions (Though it's optional, because the parentheses go the other way and make everything super-explicit (Whereas Python is all about The Line and how far it's indented (Use spaces, not tabs)))).

Malor wrote:

But I'm pretty sure you'll find yourself productive in Python quite quickly.

IMAGE(https://i.imgur.com/unN3SDM.png)

EDIT: At the same time, there's a lot of truth in this one too, at least for Python on MacOS:

IMAGE(https://imgs.xkcd.com/comics/python_environment.png)

I know some people at work have had a lot of success with pyenv.
Since I use debian for my work system I settle for symlinks to 2.7 and several 3.* installs (or really a --python opt when creating a project virtualenv).
We've used python for webapps, rest services, etls and an internal CLI to manage deployment bits. I know for a new project people are trying out GOLANG again (its nice!), but we still use python a good deal.
I know homebrew can f*ck up your installs so try to avoid.

Oh and while I'm at it lemme pimp debinate an open source tool made by one of my coworkers we use to make nice little packaged virtual envs for deployment.

boogle wrote:

I know some people at work have had a lot of success with pyenv.

I use pyenv, as it's pretty much a direct clone of Ruby's rbenv.

Yeah I guess I don't notice it a ton as I'm normally specifying a python install when creating my VEs, but all the OSX devs love it.

I've been stuck on virtualenv, should I switch to pyenv?

DanB wrote:

I've been stuck on virtualenv, should I switch to pyenv?

they are not mutually exclusive and work well together e.g.

Yeah, most Python shops I've been in use one or the other, because otherwise there's no reliable way to have a clean environment. In the end I think it makes a lot of sense. We live in a world of virtualization on the server-side anyway.

DSGamer wrote:

Yeah, most Python shops I've been in use one or the other, because otherwise there's no reliable way to have a clean environment. In the end I think it makes a lot of sense. We live in a world of virtualization on the server-side anyway.

Nah bro, you gotta run everything in its own Docker container.

EVERYTHING

The Seismic group here settled on Anaconda, so I moved from virtualenv to that and .... it's fine. I dunno, I tend to be obsessive about keeping my envs (and my entire system for that matter) clean, so I've never had an issue. On the other hand, I've had to troubleshoot python issues for a seismic analyst with no computing background and my advice to him ended up being to just take a full backup and start his entire OS install from scratch. He had python installs all over the place, multiple versions of multiple libraries in multiple places on his drive (not in an env, just scattered around). It was a disaster.

Yeah, I like Python but its virtual environments can become a real mess.

On the plus side, at least it has a package management ecosystem.

If any of you are VIMmers, you may be interested in this pretty nice vimrc file: https://github.com/mattboehm/dotfile...

I met the author at a VIM users group this week. He wrote accordion and unstack, which are a couple of really nice plugins.

Hah, that guy does one of the things I do with my vimrc (or nvim/init.vim these days): add settings/bindings for a plugin as an indented block underneath the Plug line for the plugin.

Does anyone else feel like submitting their dot files for review/borrowing purposes?

I did a complete revamp recently, throwing away around 11 years of stuff. There was too much cruft, so I decided to start from scratch. For various reasons tcsh had been my shell of choice for awhile, but I've switched to bash and kept my now-pretty-ancient bash-prompt from the cruft.

Then I realized that was going to take more time than I wanted, so I looked at what my various co-workers had made available and chose the one I liked the most as a base to start with. For vim in particular I've borrowed pretty heavily from Damian Conway.

https://github.com/klp2/dot-files

IMAGE(https://i.redd.it/ud9zc7cx26x01.jpg)

I don't understand that sort of analysis paralysis. You write code. If it's wrong, you fix it. If it's too wrong, you gut it and rearchitect.

Also, if you are forced to use Python, pipenv solves most of its problems by sitting on top of virtualenv and mostly not ruining your day. Mostly. Sometimes Python does anyway. (I feel bad for the data science types, but its increasing irrelevance outside of that space is heartening. Maybe Golang next?)

Ed Ropple wrote:

Also, if you are forced to use Python, pipenv solves most of its problems by sitting on top of virtualenv and mostly not ruining your day. Mostly. Sometimes Python does anyway. (I feel bad for the data science types, but its increasing irrelevance outside of that space is heartening. Maybe Golang next?)

no. All Julia all the time

DanB wrote:
Ed Ropple wrote:

Also, if you are forced to use Python, pipenv solves most of its problems by sitting on top of virtualenv and mostly not ruining your day. Mostly. Sometimes Python does anyway. (I feel bad for the data science types, but its increasing irrelevance outside of that space is heartening. Maybe Golang next?)

no. All Julia all the time

Dart today, Dart tomorrow.

My brain must be broken correctly because I haven't had python env issues for years.

Neither has Kenneth Reitz.

muraii wrote:

Neither has Kenneth Reitz.

Uh good lord.
If you are packaging your python thing (and thus using pipenv) you should really be hardcoding the python version.
Dependency graphs are messy at times in python (we ran into this with dependencies of an internal common code module getting overwritten by the main project's dep's deps) and supporting > for the py version is uh gross? Especially when you are testing on your CI.
You should be explicitly exporting what the pip and python are in the ENV vars of the build or at the head of the build script or in the Make.

f*ck that noise my bruh.

Who wants to read a nerdy discussion of why current CPU design is bad?

Of course you do:
https://queue.acm.org/detail.cfm?id=...

DanB wrote:

Who wants to read a nerdy discussion of why current CPU design is bad?

Of course you do:
https://queue.acm.org/detail.cfm?id=...

Eric S Raymond’s follow on post is pretty good as well. Link

DanB wrote:

Who wants to read a nerdy discussion of why current CPU design is bad?

Of course you do:
https://queue.acm.org/detail.cfm?id=...

Hmm strange using Spectre and Meltdown to complain about the C abstract machine. Those defects are only defects when they break the sandbox. One can be fixed by not having OS put kernel space in user space (those who considered OS calls to be slow and avoided them in our code were kind of shocked to discover the OS engineers had broken the memory protection to make OS calls faster) and the other can be fixed by not running multiple VM language instances in the same OS process.

That said I really do wish the hardware engineer's would give us stronger ways to annotate memory usage. Marking memory as read-only and enforcing that in hardware and similarly with thread local storage, these concepts existing in the C++ memory model but you can't rely on them.

There was a nice talk on optimisation at BoostCon on recently that feeds into this: