Comment by gyulai | Hacker News Reader

Comment by gyulai | Hacker News Reader

Parent Full thread

> You do not need some 3rd party library to write a command line interface for your python code. You do not need three different projects just to maintain your list of installed packages or virtual environment. And you don't need a package to wrap around loading environment variables.

Couldn't agree more.

I'm going through the experience now of switching from Python to Lua and this experience of trying to do more with less is really eye-opening. I find that lots of things where Python has trained me to expect them to be one-liners are now idioms of half a dozen lines of code. ...but as I use them, I find myself introducing a lot of variation around each half-dozen-loc-idiom. Then the thought occurs to me: Should I make this into a utility function? And the answer is usually no: Because it would have to support all this variation and create a complex interface. Having to understand the interface would introduce as much complexity for the person trying to read/maintain my code as having to tackle half-dozen-loc-idioms where there could be one-liners.

Languages that default to simplicity and make-your-own-batteries force that thought process on developers, making them better developers in the process, able to produce more maintainable code.

Languages that default to batteries-included try to spare developers the work of having to think about such things, and the end result is way more messy.

My favorite aspect of lua is that it gives you all the tools to implement anything and do it simply. Python, C#, and many languages push you to find the “right” way to do things, and spend time searching through documentation to find the shortcomings of each option and which method may be optimal for your situation. It’s like walking into a hardware store with a specialized tool for everything—you spend your time worrying if you’re really using the right thing. Lua feels like a garage workshop with all the basic tools you need to quickly implement something on your own—master a few and only go hunting for something new when you’ve got no other choice.

That is an odd take on Python particularly, which has been widely lauded as a good language for exploratory coding - easy and quick to put something together and iterate on it. You seem to be claiming the opposite here.

> That is an odd take on Python particularly, which has been widely lauded as a good language for exploratory coding - easy and quick to put something together and iterate on it.

I think the point your parent was trying to make is that, at least in Python, there is a lot of emphasis put on doing things the python way e.g. list comprehensions over loops.

For myself, the python experience is... mediocre.

Ruby feels so much better. Between the embracing of functional programming and the pry gem, it feels much nicer to use. Sadly, it's not the strong horse in the race.

Lot of emphasis by whom? Yes, certain constructs are subtly encouraged (by documentation, community blogs, etc.), but there is no python police to enforce the One True Way(tm). You can still write your quick&dirty prototype using not-quite-pythonic-python if you prefer, allowing you to move and iterate just as fast as in Lua or Ruby.

At least that's been my experience with Python (after reluctantly getting used to the indentation as part of syntax :) ). Of course, different languages will appeal to different people, so I do not doubt your claim that Ruby suits you better. But the post I was replying to above was putting Python in the same bag as C/C++, which to me seems very inaccurate.

You just described why I preferred Assembly early in my career, and C/C++ for the majority. Making your own batteries enables exponential opportunities to improve and optimize a project, simply because one knows all the parts, they are not externally sourced "batteries-included" features.

I've also fled to Lua. LuaJIT is "finished". Love2D has a few dependencies but they are big and slow. Love does releases only every couple of years. I occasionally grab some code from the internet, but I vendor it in, and now its my code.

Is the natural conclusion of this argument that we should be writing assembly because that has the fewest batteries included? Or is there a counterveiling force?

Reply on news.ycombinator.com