Thread: Which language?

Originally Posted by MK27

They are simply much more pronounced in python, so people who like to program in C++ often enough end up liking python even better.

Except me
I don't like python.

Originally Posted by MK27

Only in your mind are those languages "more suited" to complex tasks than interpreted ones. As a rule they are built on a C/C++ foundation and are capable of accomplishing more high level activity in a more compressed fashion == greater complexity.

If the Google Search Engine back-end were in Python, I would imagine it would be down more than these forums. It probably wouldn't even run. Sorry to break it to you. Three words: GIL. Honestly, Python just isn't fast enough for the massive amount of data Google processes (it's quite astounding), generates algorithmically, etc. It's much better at scripting the actions of an already existing solution, working with the data, etc.

I'm not saying run to the lower level at the first sign of any complexity, it's really a rare case, especially in web dev.

Nothing has been directed at you yet, that you have missed... don't worry.

Originally Posted by MK27

Consider web technology: since server side interpreted programs remain on the server and are not exposed to the public, the source can remain secure. And lo and behold, the biggest realm for interpreted language programming is server side programming!

There's indeed a problem with distributing your work if it's based on web technologies. Python wasn't a good example for the reasons Laserlight mentioned. But you can argue for PHP for instance, and I would agree.

However, companies wishing to distribute projects developed in, say PHP, can protect themselves by adopting different methods of distribution and making use of properly written EULAs. Ultimately, they may not even distribute the software, but instead just the service. On the other hand, these type of languages do not respond well to just any type of development. Their problem domain is very limited and not that well compatible with the notion of software distribution in the first place.

[quote]The REAL reason you need to use a compiled language with commercial software is so you can distribute product with no source code.[quote]

No. The real reason is probably an historical one. Compiled languages simply had a stronger impact in software development history. C and C++ specifically, took the development community by storm and contributed enormously to increase the focus on compiled solutions as a "standard" for performance and control over the end result.

Interpreted languages (which can also be distributed without source) are still struggling to get accepted as de facto solutions to real-life computing by even the open source community on most cases. There's no reason whatsoever for, say Firefox, to not have been developed in Java. But the end result would probably not have made it one of the most successful OS projects to date.

But, while the realm for compiled language programming will (by necessity) always exist, it is shrinking, just like the realm for assembly did. As DAE points out, Google loves python and it is rapidly replacing C++ in a lot of other areas too, me thinks -- like a lot of new projects that once upon a time would have been C++ are now python, but of course they are generally open source (and probably pre-empt or replace closed source alternatives). This is precisely because of the "development advantages" Elysia has been plugging. They are simply much more pronounced in python, so people who like to program in C++ often enough end up liking python even better. Or else they skip C++ (skip C!) and go straight into that new niche.

There is nothing in the compiled nature of C++ that is making it less useful. What is displacing C++ in certain areas is not the fact it is compiled. Instead it's the emergence of high-level languages (interpreted or not) that can produce similar results in a lot less development time in key problem domain areas. And this is not Python for sure. Python's problem domain is rather small in comparison. Instead generic programming languages like Java, Delphi, VB, or C#. Some more successfully than others.

What really moves languages about the ladder of "popularity" is their ability to deliver more in less time and with less effort. Many of the languages that can compete with C++ are themselves compiled and this has no effect on their ability to displace C++.

A programming language like C#, being marketed the way it is and by who they are, has the potential to all but completely wipe out C++ from traditional GUI-based software in the Microsoft platforms. It's just impossible to negate the advantages of C# (supported by the .Net Framework) over C++ on this area. It's overwhelming. And even more because if there is a need for a performance-critical backend, C# can interface with C++ on those areas where it will make a difference.

This has nothing to do with the fact C# is interpreted or not. Programmers don't really give a rat's arse to that. They don't even care about the fact the resulting MSIL that gets distributed is a dead giveaway to their source code. There's enough tools to obfuscate and even compile to native code. It is simply the fact they can build a complex GUI application in a fraction of the time it would take them in C++ with any of the current frameworks and without the complexity involved in library dependency that is the hallmark of C++ development.

Originally Posted by Dae

If the Google Search Engine back-end were in Python, I would imagine it would be down more than these forums. It probably wouldn't even run. Sorry to break it to you. Three words: GIL. Honestly, Python just isn't fast enough for the massive amount of data Google processes (it's quite astounding), generates algorithmically, etc.

I have no doubt about that, I just brought up Google to point out to Mario that programming the web is not all kiddy stuff. Altho "generates algorithmically" kind of implies the data is somehow too complex to deal with any other way, as opposed to simply being of incredible volume. You keep trying to slyly imply that python (which I have no personal attachment to) is maybe too simplistic to do grown up work when the issue is not related to that at all. This is more of that mystique++ malarky. The same algorithms are possible either way, just what is a barely noticeable performance issue under normal circumstances might be somewhat more severe if you are talking about dynamically indexing the entire WWW.

Like I have seen more than one person cboard who has absorbed some piece of nonsense about the limitations of using interpreted languages, and now they are real neophyte C++ programmers no one can tell them anything different (the "see no hear no speak no" monkey).

How many people are currently working on a project that involves the amount of data Google processess? How many people have ever worked on a project of that scale?

There will always be a need for compiled languages. There is the real and obvious need that somewhere along the line you need a compiled executable. But this does not account for their general predominance -- I think that is more because of tradition and the time it takes to develop programming expertise, and very significantly because of the closed source issue.

I guess I thought it was a little more structured in what language you use for what, it seems that you can use lots of different languages for one purpose. I think I'm after a language to learn to get me into programming, hopefully one I'll use so it can be my main one. I can see myself learning C among others (I know some of the equipment at work uses Oracle/SQL) aswell but I think I'm gonna use C++ as my entry point.

And just to be clear I'm not trying to mess with what is a wise decision, I just get tired of the C++ glee club pretending that this is part of the Divine order and thank God they've saved another poor soul from the clutches of the Devil and the deep blue ____. I like programming; for me it is about more than my allegiance to one language over another and people should not be taught this attitude.

Originally Posted by laserlight

Possible inconsistencies in the exact version of the Python interpreter aside, it is possible to distribute a Python program without distributing the source code, i.e., by distributing the compiled bytecode.

I wasn't aware of that about python, in which case it may end up getting genuine "market share".

Ever seen a javascript obfuscator?
Free Javascript Obfuscator

They get almost obscene. But all this only supports my point about how significant issue of restricting source distribution is and how significant a historical factor it has been. And how all this "in the best of all possible worlds" stuff is slightly fantastic idealization.

Originally Posted by Mario F.

There is nothing in the compiled nature of C++ that is making it less useful. What is displacing C++ in certain areas is not the fact it is compiled. Instead it's the emergence of high-level languages (interpreted or not) that can produce similar results in a lot less development time in key problem domain areas. And this is not Python for sure. Python's problem domain is rather small in comparison. Instead generic programming languages like Java, Delphi, VB, or C#. Some more successfully than others.

Well, I think you are downplaying the advantages of interpreted languages, such as easy portability and such. I'd count Java and most/all of those others as interpreted in that sense. They use some kind of interpreter.

Otherwise, I totally agree/was informed by your last post, Mario. The reason I used python as an example is because even in my short programming career I would say over the last 6-12 months I just keep noticing more and more python projects popping up (nb., of course what it is most likely to "replace" is perl, tho the perl interpreter I believe has a number of technical advantages, such as no GIL/concurrency issue). My impression of python is that it looks much more like C/C++, so C/C++ students have probably taken to it. Plus it's new-fangled and has a scarey cool name.

Actually, why are we classing interpreted languages as more portable than compiled ones? Both require that there exists software, one way or another, for the target platform. This Java portability nonsense is rubbish, I say. I have no good evidence of the contrary.
I wouldn't say interpreted languages are more portable than compiled ones...
Rubbish, I say. Rubbish! Let's turn this thread into a 3rd direction too, shouldn't we? It will be fun!

Originally Posted by Elysia

I wouldn't say interpreted languages are more portable than compiled ones...

If the makers of an interpreted language want to make it portable, they concentrate the efforts on their runtime interpreter, leaving (for the most part) the programmers free of that task. Conversely, if the makers of a compiled language want to make it portable, they will have an hard time doing it in the run-time library and the end result is a generic language that puts on the programmer the weight of such task.

This is what is meant generally when it is said "interpreted languages are more portable than compiled ones", and not that compiled languages cannot be equally or more portable than interpreted ones.

Originally Posted by Mario F.

If the makers of an interpreted language want to make it portable, they concentrate the efforts on their runtime interpreter, leaving (for the most part) the programmers free of that task. Conversely, if the makers of a compiled language want to make it portable, they will have an hard time doing it in the run-time library and the end result is a generic language that puts on the programmer the weight of such task.

All the code in the runtime essentially has to be the same as for any compiled language, so I see no difference here. Both the compiled and interpreted languages must define a function in their framework as a series of OS calls.

Originally Posted by _Mike

Don't you think you are generalizing a bit to much here? By that logic all programming languages are interpreted in the sense that the cpu interprets the opcodes it is given.
I wouldn't call C# (or any other .net language) interpreted because it is compiled to native code at runtime.
As for java; I don't know how sun's official java vm handles java bytecode, but I have read about other VMs using a JIT compiler.

They are called interpreted because there is a middle-software, ie a program between the code and the OS, that reads the instructions in the instructions and converts them to machine-specific instructions.
This is as opposed to native binaries where the instructions are machine instructions which are natively fed to the cpu. So I would definitely call C# and Java interpreted languages.

Originally Posted by _Mike

But this is more about implementations than the languages themselves.

I'm not sure what you mean. The implementation is not going to solve any portability issues. These do not steam from a language specification that works differently from one implementation to another. That would be a bad language design. Instead portability issues that arise from compiled languages translate into lack of immediate access to certain portable facilities. For instance, file access.

The solution has to be given by the programmer or the library developer. So it can be said in general that portability issues are easier to deal with in interpreted languages that can develop a language specification that includes all the needed functionality and handle differences between each platform in the runtime layer.

Originally Posted by Mario F.

No. It's like saying "payroll software is one of the most complex business applications you can develop".

But because you never done any payroll software and don't even know the requirements for such software, you estimate WRONGLY that you can produce an usually accepted argument about generalizations. Problem is, there's no generalization.

I'll say it again just in case your head is still up your arse: Payroll software is one of the most complex business applications there is.

Not wanting to dip my toes into this particular boiling pot but I would like to add large-scale insurance systems to payroll systems. Same level of complexity WRT laws, regulatory bodies and so forth and absolutely no place for C b/c C keeps you glued to the code-level whereas C++ or any language that really supports things like OOP from the ground up lets one consider the larger architectural problems and frankly simplifies maintenance. This opinion is based on my experience; yours may vary. I use C for embedded and C++ for larger scale apps. If all you learn or become proficient with is a single language your tool box will only have one tool and you will be forever trying to pound a screw into a board with a hammer....to awkwardly twist an old analogy...

The other misconception I would like to do away with here is that this forum is only populated by C++ 101 programmers....some are and some are not.