Python

[chrisname]

They do provide a 2to3 script which does most of the conversion for you. Also, python does have a threading library:

import Threading

class Thread(Threading.thread):
        def __init__(self, id):
                self.id = id
        def run(self):
                print "Thread " + str(id)

threads = []
for i in range(0, 10):
        threads.append(Thread(i + 1)
        threads[i].start()

Something like that anyway.

[1yR4jE8b]

The C-based, standard version, of Python has a Global Interpreter Lock: only one thread at a time is allowed to run Python code.

[chrisname]

Well that's stupid. I didn't know about that. Does IronPython have it?

[1yR4jE8b]

No, and neither does Jython.

Although there are good reasons for and against it:

http://smoothspan.wordpress.com/2007/09/14/guido-is-right-to-leave-the-gil-in-python-not-for-multicore-but-for-utility-computing/

[rapidcoder]

I gave Python a try once, but I did it in the wrong order - I learned Python after I learned Scala. If I did it the other way round, I would probably like Python - it is quite a nice and clean language which for sure makes many things simpler than in C++ or Java. However, after learning Scala, I had a hard time finding at least one thing that could impress me in Python. Well, just for every task Python was meant to be a good tool for the job, Scala was just as good or better (= shorter code, faster code, better libraries, better IDE support, shorter write-compile-test cycle).

Ok, to be honest, Python might be better, if you need a 100 LOC long utility, that needs to execute fully in less than 0.1 seconds. Scala can't do that because it requires about 0.1s-0.2s to load.

[1yR4jE8b]

Just found this: http://boo.codehaus.org/

Boo Programming Language: a statically typed, compiled language for the CLI with syntax very similar to Python 3.

[chrisname]

That looks pretty damn good, I'm going to have to learn that.

[ascii]

I'm personally a python fan. My first language was Perl, and when I started to learn python it pretty much felt like "perl done right." However, I haven't experience with other languages like Ruby, so I can't give a full opinion. Python is also very well documented which is a great plus :)

Interesting article on the matter: http://www.linuxjournal.com/article/3882

[1yR4jE8b]

Ruby is much closer to "Perl done right" than Python, especially considering Ruby has Regular Expressions as primitives. Python is much more like "Java done right": simplified C-like syntax which abstracts away many of the lower level functions of C/C++.

[kbw]

Perl done right? Now there's a misnomer.

I initially thought it looked like a good idea, combining AWK and Shell scripting. But turning it into this monster that people go off and write trading systems and other huge financial systems in is crazy. It's like building a sky scraper from cardboard.

Back in the old days, everyone turned they're noses up at BASIC because if offered no structure to support larger projects and eventually produced monsters. But these modern BASICs are everywhere.

[Serious Sam]

I think Python is great, but it's not a general-purpose language like C++. For shorter scripts, especially if you need to manipulate strings, it's fantastic. I'm studying at the institute for computational language processing of our university and round here Python is used quite often because it is easy to use and we obviously work with strings a lot. There is also the natural language toolkit: http://www.nltk.org/ for Python, which offers a variety of natural language processing algorithms, from tokenizing to parsing and handling larger text corpora conveniently.

But kbw is absolutely right in that Python isn't good for huge, complex systems. There are just too many flaws, one is of course the type checking. I can feed a Python function a number where a string was supposed to go and it won't complain. I've never been part of writing a huge software system, but I'd guess that is not acceptable in such a system.

And I HATE the indentation. Using brackets to indicate where the body of a loop begins and ends doesn't kill your readability. When a bracket is missing the error is obvious. When you're one whitespace of it's not so obvious and it makes for an unbelievably annoying error.

[sohguanh]

I have seen a trading system written in Perl and som other monster financial management thing too. Absolutely mad.

This is the first time I read about this. Trading system in Perl? This is unbelievable! Obviously some hardcore Perl developers intend to set a precedent and prove a case perhaps? If it materialize and was successful, the strongly-held ground of C/C++ for trading systems look very shaky instead!

Man... I still thought this will take place at least 10 years down the road but it appear to occur much sooner than I expected!!!!

The next step I would be thinking is can we use Perl to code and run programs in those missiles and rockets or perhaps nuclear reactor systems ?!?!

[1yR4jE8b]

Perl done right? Now there's a misnomer.

Reminds me of Linus Torvalds talking about Subversion: "The project started off with the tagline 'CVS done right', when you start with that there's nowhere you can actually go" (paraphrasing).

Thankfully, it's not the slogan for Ruby. Ruby's is "A Programmer's Best Friend", and based from personal experience, it's damn close.

There are just too many flaws, one is of course the type checking. I can feed a Python function a number where a string was supposed to go and it won't complain. I've never been part of writing a huge software system, but I'd guess that is not acceptable in such a system.

This is riduclous, sure, it will take it at runtime. Don't people TEST their damn code before putting it into production? That's exactly what that whole phase of development is FOR.

Sure, you don't catch type errors as easily as when using the "write, compile, test" cycle, but you should still be catching them relatively quickly with the "write, test" workflow. If you aren't accounting for type errors in your unit tests, you're doing it wrong.

Personally, I prefer to have more rigid checks in unit-tests and not have to deal with memory leaks/corruption, buffer overflows, dangling pointers, etc... Especially when you are trying to just get something *finished* so you can move on to something else more important.

Neither workflow is necessarily "better", you just need a different mindset when working in each, but it all boils down to personal preference.

And I HATE the indentation. Using brackets to indicate where the body of a loop begins and ends doesn't kill your readability. When a bracket is missing the error is obvious. When you're one whitespace of it's not so obvious and it makes for an unbelievably annoying error.

Uniformed opinion: when you incorrectly indent in Python, the interpreter throws an "IndentationError" and tells you exactly which line it's on. Takes 3 seconds to fix.

How readable is this in C/C++? This code compiles just fine, how easy is it to understand though?

if(something)
  if(something)
    function1();
else
  function2();
else if(somethingElse)
  if(moreSomething)
    function3();
  else if(evenMoreSomething)
    function4();
else
  function5();
  else
    function6();

The flow of control here is so confusing, even I didn't know how it worked at first glance. And yes, code that looks horrible like this *does* exist. I've worked with dozens of so-called "professional" programmers during my career and abhorations like that are a lot more common than you think.

Monstrosities like this are *impossible* with Python because it forces you to write structured code. Just because you write nicely formatted C++ code doesn't mean everyone else does (check any code posted from beginners on this forum for examples), but by enforcing a style in the language grammar then ALL code looks the same stylistically and is much easier to read because of consistency.

Writing my code in a specific way is a small price to pay in order to have everyone else write their code in the exact same way so we can all understand eachother.

[helios]

Personally, I prefer to have more rigid checks in unit-tests and not have to deal with memory leaks/corruption, buffer overflows, dangling pointers, etc...Especially when you are trying to just get something *finished* so you can move on to something else more important.

In that case, why not use a language that provides both type safety and forbids memory errors?

As for the formatting thing, just run a beautifier through the source. If you're working on a team, it could be done automagically when someone commits code.
Output from AStyle:

if(something)
    if(something)
        function1();
    else
        function2();
else if(somethingElse)
    if(moreSomething)
        function3();
    else if(evenMoreSomething)
        function4();
    else
        function5();
else
    function6();

[ascii]

Automagic?

[1yR4jE8b]

edit: deleted double post

[1yR4jE8b]

In that case, why not use a language that provides both type safety and forbids memory errors?

You don't always get to choose the language you use.

The only dynamically typed language that I know of that does "static" type-checking is Magpie but it is a vary young language and the library support is non-existent.

As for the formatting thing, just run a beautifier through the source. If you're working on a team, it could be done automagically when someone commits code.

This is fine internally, but I am a weekend coder for open-source projects. I can just imagine how well this pull request would go: "Patch: beautified 25,000 source files".

Besides, why run a separate tool when you can just enforce it in the language? Seriously, this is nitpicking, significant whitespace is not the end of the world. Deal with it: use a different language for your toy project, pick a different open-source project, quit your job...whatever, it doesn't matter, nobody cares.

@ascii
automagically: http://www.urbandictionary.com/define.php?term=automagically

edit: tone? lol

[helios]

Couldn't you just edit your post?

You don't always get to choose the language you use.

Well, the argument of static vs. dynamic types implies that the choice exists, otherwise it doesn't even make sense to bring it up (other than to bitch about how it would have been better the other way). You just use what you have.

The only dynamically typed language that I know of that does "static" type-checking is Magpie but it is a vary young language and the library support is non-existent.

I was actually thinking something more along the lines of ML.

This is fine internally

Yes, internally. What else could we be talking about? Some random guy walking in and reformatting an entire project to Pico style isn't very likely.

Besides, why run a separate tool when you can just enforce it in the language?

The opposite argument is equally valid.

significant whitespace is NOT THE END OF THE WORLD. Deal with it: use a different language for your toy project, pick a different open-source project, quit your job...whatever, it doesn't matter, nobody gives a shit.

Whoa, there. What's with the sudden change in tone?

[1yR4jE8b]

Can I write Qt, win32, Gnome, KDE, etc... applications in ML?

Yes, internally. What else could we be talking about? Some random guy walking in and reformatting an entire project to Pico style isn't very likely.

I guess you missed the part about beautifiers being unpractical for open source projects.

Whoa, there. What's with the sudden change in tone?

edited for tone

Anyway, this argument is going nowhere. I'm out.

[rapidcoder]

The only dynamically typed language that I know of that does "static" type-checking is Magpie but it is a vary young language and the library support is non-existent.

Scala can be viewed as a dynamic language - just use the Dynamic type everywhere. But you would have to be crazy not to use the benefits of powerful type system it offers.

Anyway, what are the benefits of dynamic typing? IMHO, dynamic typing is beneficial mostly to the language designer - it is hell easier to design a dynamically typed language than to design a statically typed one. But for the programmer - there are none. Dynamic typing hinders both programmer productivity and runtime performance.

As for the statement that unit-testing solves the problem of type errors - this is total BS. Most of the code is not easily unit-testable. For example GUI layer or database layer. Also don't forget that unit tests must be maintained in any larger projects, so definitely you don't want to have a 90% test coverage. We have about 10% test coverage only for the most complex parts of the system and the software we produce is very, very stable, even the nightly builds. I haven't seen a developer version crash for months.

Can I write Qt, win32, Gnome, KDE, etc... applications in ML?

Why not?