To please adherents of all programming styles, nested code blocks have to be indented exactly 1 space, then 2 spaces, then 4 spaces, then a tab, then 3 spaces, then with a dot à la MUMPS, then no indentation, then turtles.
IDEA Ultimate (aka IntelliJ IDEA). I last wrote Java (and it wasn’t much then) checks notes 5 years ago, and I still don’t get why each of the language-specific JetBrains editors exists, but apparently this is the only one that will support plugins for any other random language (e.g. PHPStorm can’t install the python language plugin, and PyCharm can’t install the PHP language plugin).
Vagrant. From a shared single-VM dev environment, to an 8-10 VM simulation of a ‘production’ site. Yes it has a few rough edges, but realistically everything does, and I’m mostly familiar with these rough edges now.
A pretty vanilla zsh on macOS, the only really ‘custom’ thing is a little script to setup & store dotfiles & similar in iCloud drive.
TablePlus (for SQL)
Kaleidoscope because command line diffs are insane for anything beyond about 2 files.
About the different JetBrains products, my guess is that you only pay for the features you really use. It’s still weird that you have to install different applications if you want to mix and match e.g. Python and PHP, but not Java.
I don’t think I ever got the hang of a GUI for doing SQL. I’ve used DB Visualizer a bit, but too many times there are situations where the command line is just a few keystrokes away.
I get the pricing difference - but why not just have the different licences enable different plugins then - and they even acknowledge this weird behaviour with both a “all products” licence and a dedicated desktop tool, just to install/update/launch all the various tools.
Re: SQL - the GUI part is 99% about viewing results more easily - the vast majority of the time it’s just showing me the result of a query I wrote (or occasionally copied from an error log).
Very simple syntax, but I’m not sure I like these constructs. Unless I remember the specification, my knee-jerk reaction is to be surprised and suspicious upon seeing that kind of code. Is it going to be executed or not? Is it a merge conflict resolution gone bad? Especially if there are neighbouring if/else blocks with almost correct indentation.
Although, I must admit the for/else variant is great for simplifying searches in iterables :)
This is one of those cases where I think the Python solution is elegant but impractical. I find it much harder to reason about (and consequently I strongly suspect it is more error prone) than (for example) the Go solution to the same problem, which is to continue LABEL (example). That said, I recently screwed up some Go code by typing goto instead of continue, thereby creating a surprising infinite loop.
I predict that your knee-jerk surprise and suspicion will give way to mild feelings of approval as you get more comfortable with Python idioms. Other languages I’ve known have much stranger idioms, which also become ‘intuitive’ with familiarity. Language is a wonderful thing.
In my opinion, the most basic requirement of someone working on Python code is to know Python’s syntax. And in fact that goes for any programming language. One of the best things about Python is that it has really simple syntax for a language of its type (nothing approaching Lisp’s simplicity). It requires only a single token of lookahead to parse, which I think helps humans and computers. There are no “garden path” syntactic constructs where you only realise half way along a line that you need to go back to the beginning and start parsing that line again, like you can get in C++:
x * y = z;
So when you say ‘Unless I remember the specification’, it makes me wonder whether you actually know the language properly or whether you’re just cargo-culting code based on some sort of surface-level knowledge of the language that you’ve gained only by reading a lot of code. Python’s grammar is right there in the documentation, all these constructs are well-documented and I remember them being covered in the first Python book I ever read, so there’s really no excuse not to be familiar with them.
I know a lot of people aren’t really fond of Django’s template language, but its for tag uses an optional empty block instead of an else block to clarify that it’s only for things you want to do when the thing you tried to iterate was empty.
While it’s true that Python’s for/else is not quite identical to the Django template language’s for/empty, handling an empty iterable is the primary use case I’ve seen in the real world for people using Python’s for/else, and avoids some of the confusion of what Python’s for/else actually does (which is, I’d argue, a poor fit for else).
Finding resources, either human or technical, is boring
For commercial or enterprise projects, I want the least amount of surprises. Will devs be able to work on the project? Yes. Will it run? Yes. Will I be able to find people, frameworks and libs to do their tasks? Yes.
Because I work on enterprise stuff with microservices and other delicious buzzwordy things, I would add:
Monitoring is (almost) boring
Testing is boring and fun!
Monitoring a Java process is… not exactly smooth? In my opinion it’s not as plug’n’play as it ought to be, with wildly different techniques being involved depending on the context.
Testing is dead simple. JUnit with Mockito, maybe some Cucumber. TDD all the things!
On another note, I guess all of my points could also be applied to Go. I can’t say for sure because I haven’t learnt the language yet, so I can’t compare.
Python is amazing for scripts and glue, and also for integration testing! Our team uses Pytest and Behave to make sure our services play well together.
This is a good article that showcases pain points I’m currently having developping with Python (along with my sympathetic teammates). The following sentence synthesizes how I feel about it now:
It’s great to be implicit when you just want to pump out some code to get a prototype working, but especially when building larger applications it can bring a lot of trouble.
Having done dynamic languages and static ones, nominal versus structural, professional and hobby, academic and enterprise, anything static trumps dynamic when you want to be able to grow and maintain a project past the prototype stage.
You don’t have any guarantee that “paid_date” is available in the dictionary.
There is no guarantee indeed. Even with type annotations, they are suggestions. On the plus side, typing is explicit and helps a lot understanding code.
That is not to say that Python is all bad in my opinion. I love its modern improvements, and just being able to whip out a dataclass in a few seconds does 80% of the job. Also, working with pytest is a charm.
Next step: convincing my team that rewriting in Rust is a good idea…
anything static trumps dynamic when you want to be able to grow and maintain a project past the prototype stage.
I wouldn’t go that far. I still very much love Python, especially for projects where requirements change often, where you need a diverse feature set or many integrations to different tools and platforms. E.g. tools to automate internal tasks.
Short development cycles and the vast ecosystem guarantee that you can deliver something useful before it becomes obsolete. And an application with occasional hiccups or bugs is still far better than people manually working in excel files on repetitive tasks ;)
To please adherents of all programming styles, nested code blocks have to be indented exactly 1 space, then 2 spaces, then 4 spaces, then a tab, then 3 spaces, then with a dot à la MUMPS, then no indentation, then turtles.
Depends on the machine I’m working on, but common elements are:
I do customize all the tools I use. For now I settled on:
Desktop is on Manjaro, work machine is on MacOS.
IDEA Ultimate (aka IntelliJ IDEA). I last wrote Java (and it wasn’t much then) checks notes 5 years ago, and I still don’t get why each of the language-specific JetBrains editors exists, but apparently this is the only one that will support plugins for any other random language (e.g. PHPStorm can’t install the python language plugin, and PyCharm can’t install the PHP language plugin).
Vagrant. From a shared single-VM dev environment, to an 8-10 VM simulation of a ‘production’ site. Yes it has a few rough edges, but realistically everything does, and I’m mostly familiar with these rough edges now.
A pretty vanilla zsh on macOS, the only really ‘custom’ thing is a little script to setup & store dotfiles & similar in iCloud drive.
TablePlus (for SQL)
Kaleidoscope because command line diffs are insane for anything beyond about 2 files.
About the different JetBrains products, my guess is that you only pay for the features you really use. It’s still weird that you have to install different applications if you want to mix and match e.g. Python and PHP, but not Java.
I don’t think I ever got the hang of a GUI for doing SQL. I’ve used DB Visualizer a bit, but too many times there are situations where the command line is just a few keystrokes away.
I get the pricing difference - but why not just have the different licences enable different plugins then - and they even acknowledge this weird behaviour with both a “all products” licence and a dedicated desktop tool, just to install/update/launch all the various tools.
Re: SQL - the GUI part is 99% about viewing results more easily - the vast majority of the time it’s just showing me the result of a query I wrote (or occasionally copied from an error log).
Very simple syntax, but I’m not sure I like these constructs. Unless I remember the specification, my knee-jerk reaction is to be surprised and suspicious upon seeing that kind of code. Is it going to be executed or not? Is it a merge conflict resolution gone bad? Especially if there are neighbouring if/else blocks with almost correct indentation.
Although, I must admit the for/else variant is great for simplifying searches in iterables :)
This is one of those cases where I think the Python solution is elegant but impractical. I find it much harder to reason about (and consequently I strongly suspect it is more error prone) than (for example) the Go solution to the same problem, which is to
continue LABEL(example). That said, I recently screwed up some Go code by typinggotoinstead ofcontinue, thereby creating a surprising infinite loop.I predict that your knee-jerk surprise and suspicion will give way to mild feelings of approval as you get more comfortable with Python idioms. Other languages I’ve known have much stranger idioms, which also become ‘intuitive’ with familiarity. Language is a wonderful thing.
Is it an idiom (as in, commonly used pattern)? I’ve known about this for years, but never used or seen it in any code.
In my opinion, the most basic requirement of someone working on Python code is to know Python’s syntax. And in fact that goes for any programming language. One of the best things about Python is that it has really simple syntax for a language of its type (nothing approaching Lisp’s simplicity). It requires only a single token of lookahead to parse, which I think helps humans and computers. There are no “garden path” syntactic constructs where you only realise half way along a line that you need to go back to the beginning and start parsing that line again, like you can get in C++:
So when you say ‘Unless I remember the specification’, it makes me wonder whether you actually know the language properly or whether you’re just cargo-culting code based on some sort of surface-level knowledge of the language that you’ve gained only by reading a lot of code. Python’s grammar is right there in the documentation, all these constructs are well-documented and I remember them being covered in the first Python book I ever read, so there’s really no excuse not to be familiar with them.
I know a lot of people aren’t really fond of Django’s template language, but its
fortag uses an optionalemptyblock instead of anelseblock to clarify that it’s only for things you want to do when the thing you tried to iterate was empty.…which is not the same as what for/else does.
While it’s true that Python’s
for/elseis not quite identical to the Django template language’sfor/empty, handling an empty iterable is the primary use case I’ve seen in the real world for people using Python’sfor/else, and avoids some of the confusion of what Python’sfor/elseactually does (which is, I’d argue, a poor fit forelse).A lot of template engines support this. Actually, I think pretty much all of the ones I’ve worked with over the years across a variety of languages.
alwaysneveralways be used. A great source of contention in the team.We have a “build –for-checkin” that does a precheckin sanity test of the most common product / platforms / tool chains to go wrong.
Naturally, it’s universally pronounced as “build –for-chicken”, which naturally I have wired to playing the wonderful Chicken Yodel!
Turn the volume up to LOUD.
https://www.youtube.com/watch?v=Ppm5_AGtbTo
Java for a commercial project because:
For commercial or enterprise projects, I want the least amount of surprises. Will devs be able to work on the project? Yes. Will it run? Yes. Will I be able to find people, frameworks and libs to do their tasks? Yes.
Because I work on enterprise stuff with microservices and other delicious buzzwordy things, I would add:
Monitoring a Java process is… not exactly smooth? In my opinion it’s not as plug’n’play as it ought to be, with wildly different techniques being involved depending on the context.
Testing is dead simple. JUnit with Mockito, maybe some Cucumber. TDD all the things!
On another note, I guess all of my points could also be applied to Go. I can’t say for sure because I haven’t learnt the language yet, so I can’t compare.
Elixir for web-based projects, medium-to-large programs, and programs that need to be reliable, or will benefit from parallelism (so: most projects).
Python for extremely small programs or scripts, or when I’m on a team (everyone in my life uses Python for pretty much everything).
OCaml for when I can luxuriate a bit, want it to go fast, and hate myself a little.
Python is amazing for scripts and glue, and also for integration testing! Our team uses Pytest and Behave to make sure our services play well together.
This is a good article that showcases pain points I’m currently having developping with Python (along with my sympathetic teammates). The following sentence synthesizes how I feel about it now:
Having done dynamic languages and static ones, nominal versus structural, professional and hobby, academic and enterprise, anything static trumps dynamic when you want to be able to grow and maintain a project past the prototype stage.
There is no guarantee indeed. Even with type annotations, they are suggestions. On the plus side, typing is explicit and helps a lot understanding code.
That is not to say that Python is all bad in my opinion. I love its modern improvements, and just being able to whip out a dataclass in a few seconds does 80% of the job. Also, working with pytest is a charm.
Next step: convincing my team that rewriting in Rust is a good idea…
I wouldn’t go that far. I still very much love Python, especially for projects where requirements change often, where you need a diverse feature set or many integrations to different tools and platforms. E.g. tools to automate internal tasks.
Short development cycles and the vast ecosystem guarantee that you can deliver something useful before it becomes obsolete. And an application with occasional hiccups or bugs is still far better than people manually working in excel files on repetitive tasks ;)