re: What is your "Coder/Language Fit" VIEW POST

FULL DISCUSSION
 

For me that language has always been Python but I'm not sure anymore. I found a good fit in it because of its simplicity, the creators efforts to avoid complexity while creating a language that can be used to solve complicated problems. It's my "go to" language.

The thing is though, I have changed as a human and as a programmer over the years and Python has mostly been the same language (I know, it looks like I'm talking about a romantic relationship gone sour).

I do not know where my "language fit" lies. Ruby is nice but I've always liked it less than Python. JavaScript to me it's just a means to an end (frontend web) and Go feels the same way as well (lean servers).

I might be an orphan after all.

 

Maybe throw it all out of the window and go weird. Give Haskell or Clojure a shot, wear that hat for a while 🙃

 

I was at meeting yesterday and a Ruby dev I've known for years suggested I try Clojure as well :D

The universe has spoken!

I had a lot of fun with Clojure from 2009-2012 :-) Then I moved to SE Asia and the Clojure community here is small, bordering on non-existent. I still try to stay up to date though, it's a neat language and you'll have a ton of fun with it.

 

I feel like there is sometimes a thirst on people's part for change for its own sake, and that's really not great when it comes to computer languages. I think the relative stability of the core syntax of python is not a bad thing. And I'm with you that it's the language I would pick for this discussion as well.

There are aspects of the language that I would definitely change if I could, but those tend to be things that don't really apply to the basic syntax. For example, I think the import/module/package system in python has continued to be confusing from day one, and it's not really much better today than it was in python 2. I think npm is far superior for example compared to the mess we have in python.

Another thing is the infamous global interpreter lock. It's not something that is always going to be a major problem, and there are of course workarounds. And some people will even argue that it has some benefits. However I do consider it to be fundamentally inelegant and kind of weird for a modern programming language.

Finally, some of the standard libraries are better than others. I've definitely encountered some modules where I was wondering if I'd somehow stumbled into Java. It surprised me that more effort had not been put into keeping to the philosophy of python in that regard.

The basic syntax is pretty darn great though. It's simple without being too simple. When it comes to understanding open source code, it's definitely the language where I've found it the least difficult to figure out what people are trying to do.

 

I feel like there is sometimes a thirst on people's part for change for its own sake, and that's really not great when it comes to computer languages. I think the relative stability of the core syntax of python is not a bad thing.

Yeah, mine is not a criticism to Python per se, I definitely value this thing. I'm just saying that I'm not sure it fits in my brain as easily as it did when I picked it up first.

For example, I think the import/module/package system in python has continued to be confusing from day one, and it's not really much better today than it was in python 2.

I partly agree. The package system has been messy but the import and module system is quite alright. BTW I believe Pipenv covers almost every need now

I think npm is far superior for example compared to the mess we have in python.

Maybe, but in reality npm suffers by the enourmous amount of small packages with large dependencies trees that transform node_modules in a mess. The tool is solid though. "Far superior" to me means that the other tool is barely ok, but I wouldn't call Pipenv barely ok. It works.
It took too long to get there and there are still kinks but I believe we're on the right path. Finally 😅

Another thing is the infamous global interpreter lock. It's not something that is always going to be a major problem, and there are of course workarounds. And some people will even argue that it has some benefits. However I do consider it to be fundamentally inelegant and kind of weird for a modern programming language.

I disagree. The GIL was a very smart move (Python was developed at the end of the 80s, not exactly a new language), it made the Python ecosystem of libraries and packages develop faster with the added bonus of creating (mostly) thread safe extensions. Many industries ate it up because they could use its simple syntax and extend with C wrappers. I think the GIL is one of the reasons why Python popularity grew over the years and it still relevant after 30 years.

Someone thought about removing it in Python 3 (they were already breaking compatibility) but they didn't because they still didn't think it was worth it: extensions would become harder to write and single threaded Python programs without the GIL would be slower.

Keep in mind that the GIL is a real limit only with CPU bound multithread programs that do calculations in Python. If you are I/O bound you're fine. If you're CPU bound but inside the C API you're fine.

This is one of the reasons the GIL is still, with its drawbacks, a smart move for Python.

ps. there are implementations of Python that do not have the GIL like Jython...

code of conduct - report abuse