1. Real string manipulation is done in SNOBOL. Or would be, if anyone still used SNOBOL.

2. Java's not bad at string manipulation, but -- last I checked -- the switch() function still didn't know how to process strings. It only accepts numeric inputs. That's just head-shakingly bizarre to me.

3. That said, until recently Java was actually a pretty pleasant and powerful language for writing self-contained applications. Native compilers have pretty much eliminated any seriousness to claims that it's "too slow" (which its early bytecode versions could be, depending on the application).

4. Unfortunately, after Sun sold out to Oracle, a company (I speak here solely as a private individual) I despise, Oracle has made the last couple of versions of Java increasingly baroque, with countless bizarre little encrustations that complicate learning and using it. That's a shame.

5. Unless you need blazing speed, there's not much you can't do with JavaScript + CSS + HTML5. I recently finished a game (for Mrs. Flatfingers) that does some fairly intense number-crunching to generate complex logic puzzles. This part of the game actually runs slightly faster than the original compiled version of the game. And the cross-browser support is real -- both that game and the one I'm working on now understand how to adapt to and run on all of the major browsers. So, as a general observation, even an interpreted scripting language doesn't have to be bad.

6. Because I'm on a roll, I will add a gratuitous personal observation that while an interpreted scripting language doesn't have to be bad, it certainly can be made bad by infecting it with garbage like jQuery. jQuery looks like a Perl hacker decided to troll JavaScript users, and they still haven't gotten the joke. jQuery DOES NOT LOOK LIKE JAVASCRIPT. For all its "features" (all of which can be done with relative ease in straight-up JavaScript), it changes the "feel" of JavaScript -- learning JavaScript won't help you understand jQuery. If other people like it, OK. I don't.

7. I've used IDEs since before Visual Studio was a thing, and I've never yet found one I like. Every last stinkin' one of them insists on injecting junk into my nice clean code, and tries to force me to organize my code according to its beliefs as to how programs "should be" written. No, thank you. I will stick with my text-editor-of-choice (Zeus, a modern version of the incredibly intuitive -- and moddable! -- BRIEF text editor), which guarantees that the only top-level code that might generate a bug is mine. It's hard enough getting my own code to work; I have zero interest in also debugging whatever cruft some IDE slips into my project.

8. I appreciate the references to Python learning resources. I'm confident that, after just a few short days of study, I will find something to dislike about this language, too. (Beyond the indentation-as-scope-control silliness. )

Other than that, myself and several other people who regularly hang out on the Limit Theory IRC are Python programmers and are more than willing to help you if you have a problem, so feel free to drop by.

It's really essential that the distinction between language and implementation / execution model be made. This is especially true in the case of so-called 'interpreted' languages, since, well, it's really fundamentally wrong to call a language 'interpreted.' A language is a specification of a grammar, semantics, and the precise functionality that those semantics should provide. 'Interpreted' refers to an execution model of a piece of code, whereby the 'code' that's being interpreted is not run as native machine code, but rather by proxy through a bytecode engine, which generally is native machine code (at least, a bytecode engine is usually the form taken by interpreters, and is in the case of Python).

However, there is nothing preventing the static compilation of a language like Python. And I'm not even talking about Cython or required static typing, I'm saying that there's nothing preventing the static compilation of a dynamically-typed program. It's hard but feasible (and yes, there is always a performance hit for dynamic-typing, but it's nothing compared to the performance hit of running through an interpreter). OTOH if we restrict to static typing, it's downright easy to statically-compile Python. And on the flip-side of the coin, there are interpreted versions of C++ (AngelScript) and C (CINT).

LT's Python looks like Python and, in some places, behaves like interpreted Python. In other places, it looks like python and behaves like beautifully-crafted-and-optimized statically-compiled C.

Also, four more points:

1. Python's numpy library has been shown to match the performance of native C for large computations. That's because it's calling native C libraries...so essentially there is very little difference.

2. Python's default memory management is refcounting, GC is optional. This is, in my mind, perfect. For those who aren't great with memory management, leave the GC on. For those who know how to use refcounting without ever needing GC (aka know how to never create ref cycles), we can simply turn off the GC (as, of course, will be the case for LT) and have the performance of just refcounting (which, by the way, is what the old LT engine used, just in C++).

3. For those who want to run serious computation in Python, pypy's dynamic analysis and JITing is nothing short of magical. Use it and enjoy the order-of-magnitude performance increase for general computation.

4. Above all else, the ease of manipulating sequences, collections, strings, etc. in Python makes it an incredible choice for just about anything, if not as the language that executes the program, then as the language that generates the C that will execute the program (LT's Python-to-native magic is written in...surprise...Python! At some point, once it is powerful enough, I will be able to use it to compile itself to native code so that Python-to-native can be even faster )

(Just to balance out all this positive, there are plenty of design decisions that I don't like about Python. But above all it was the ideal choice for LT.)

“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

by now i really wonder why you don't use something like your own DSL build on top of a language like C, C++ or python maybe
or rather something that is not necessarily bound to text and code like this https://www.jetbrains.com/mps/

You know, if you're going to moan about indentation marking scope, that would lead me to believe that you're not indenting your ifs, fors, and functions in your braced-language code.

Honestly, you're going to be indenting anyway. Forcing people to indent if they mightn't otherwise means readability is forced as well, and Python is all about readability. It's a total non-issue for anyone who indents when they reach a new scope nesting level anyhow.

You know, if you're going to moan about indentation marking scope, that would lead me to believe that you're not indenting your ifs, fors, and functions in your braced-language code.

Honestly, you're going to be indenting anyway. Forcing people to indent if they mightn't otherwise means readability is forced as well, and Python is all about readability. It's a total non-issue for anyone who indents when they reach a new scope nesting level anyhow.