Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sometimes I've wished that Sublime Text's API used JS so that I didn't have to know Python just for one program.

It seems a waste having to keep a battalion of imperative OO languages in one's head just for incidental use.



Learning other languages is not a waste. It actually makes you a better developer.


Across different paradigms, sure. But many languages are very similar to one another while only differing a bit in syntax.

If you use a language with a similar paradigm, learning yet another language in that paradigm will not teach you much, it'll mostly just annoy you with its subtle differences (I'm talking to you, stored and mutable default variables of python functions).


Python and JavaScript are at very different ends of the OOP spectrum. JS encourages a functional approach while Py is more procedural. That small difference can - and does - have a profound effect of who you structure your code.

These different designs will teach you different techniques for problem solving that can be borrowed in different languages when you’re trying to solve a problem that isn’t easily solved using its classic idiom.


I’ve never seen two languages so similar there was no didactic value to learning both. Hell I’ve never seen any language that offered nothing unique.

Except perhaps Java and early C#. before Linq.


That's true if learning meaningfully different languages, but much less so if it's a 5th imperative OO language.


Python and JavaScript have vastly different idioms, and learning both makes you think different. Learn both still makes you a better programmer, even considering they're both OOP languages


Like someone with keys to the world should spend time living in both Scotland and England to absorb the vast cultural differences?


Living in both? Certainly not. However I would advocate visiting Scotland if you’re English. It’s a beautiful country.

Likewise nobody says you need to be a full time developer in every language to get benefit from learning them.


The original comment that is evidently so objectionable mentioned keeping a language (and by implication its libraries) in one's head. It's a known fact that this type of knowledge is use-it-or-lose-it. So drawing on it only occasionally is terribly suboptimal.


I’ve not found that to be the case even after learning probably close on two dozen different languages.

I won’t deny that there is a short upskilling time where you need a quick refresher but that’s no different to picking up old code you’ve not touched in a while in a language you do use regularly. In fact often the time you spend familiarising yourself with an existing codebase or new API also serves as a catch up for the language too.

That said, I have personally found that it gets easier the more languages you learn because you get good at spotting similarities. Much like with spoken languages: people who are multilingual adapt to new languages quicker because they spot patterns to stuff they’ve learned previously.


You’re probably trying to be flippant but you’ve actually made an interesting point.

Americans and Canadians, for example, usually find uncanny-valley differences between their nations that get washed out if you visit somewhere radically different instead. The small-magnitude “it could’ve been something else” realizations are just as important.


I understand the concern, but how many scripting languages are really used embedded in applications? It's usually python or Lua.


... or Lisp.


I would say the same about JS, which I've never used once in my life.

Not everything is done in a browser.


Then we agree on the generalized problem.


1990s Microsoft solved this problem with COM. For example, cscript.exe exposes both VBScript and JS, and they can talk to c++ via the same COM interfaces.


Not the OP, just wanted to say that what you are suggesting is extremely unpopular and controversial here, would you care to expand on your reasoning?


My favourite language is guile scheme which makes me all too familiar with your feelings.

Not only that: embedding python is a shitty experience compared to embedding lua or guile, and you have to work around the fact that python has no threads and that it is borderline impossible to run multiple independent interpreters in the same process.


> Not only that: embedding python is a shitty experience compared to embedding lua or guile...

That's a "feature", they prefer for people to extend python over embedding it in other applications.

That said, it isn't too bad unless you maintain the python c-api binding by hand since there's a lot of boilerplate and they like to change the api often.

Almost all my blender hacking was on the python API and that's crazy complicated compared to a terminal emulator. For example, all of the (context sensitive) operators are callable from python since the UI is controlled by python scripts.

> ...and you have to work around the fact that python has no threads and that it is borderline impossible to run multiple independent interpreters in the same process.

Pretty sure python has threads;P and has had subinterpreters[0] for a long time. Haven't really messed with either one other than making sure my C extensions release the GIL though.

I did attempt to embed lua in an application once and from what I can remember it was...interesting. Having to control the stack took some getting used to and their boilerplate was just as full featured as python's. I also don't remember being able to find useful automation scripts, with python I usually just bang out a quick prototype with pybindgen then hand edit it until I'm happy.

[0] https://docs.python.org/3/c-api/init.html#sub-interpreter-su...


No proper concurrent threads was of course what I meant. In that light the subinterpreter feature is also not very good, since all sib-interpreters share a GIL (but iirc there is a PEP out there that might make python properly multi-core through some kind of CSP-approach and independent subinterpreters).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: