I just read somewhere that for the same purpose Python code is about 2 to 10 times smaller than the corresponding c code.
How true is that?
And if true,why still majority of programmers are c programmers?
Why Python and Perl have a small share in projects on sourceforge.net
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is a bit too general to really be a practical question or a solid
statement. For example any scripting language can output to STDOUT in
about seven bytes, for example as the following in bash:
echo hi
Boom… seven bytes. C can never compare. Perl is similar:
print ‘hi’
Ten bytes! Amazing. Now on the other hand, C programs are compiled, so
everything they need to work (aside from the OS, which is not considered
in this or the scripting examples) is part of the actual program. To give
C its due you must remember that behind the ‘perl’ command is the entire
Perl language, its binary, and possibly dozens or hundreds of modules.
Now the same ‘print’ command is made up of several megabytes…
twenty-nine on my system for the ‘perl’ package alone.
So there are tradeoffs. Compiled (vs. interpreted) applications typically
run faster because there is no runtime conversion to machine language. On
the other hand it takes a lot more work to write a quick app to do
something basic, and scripting languages can also be customized to do
certain things well (Perl for system administration, PHP for web-based
stuff, awk/grep/sed for text hacking, etc.). Scripting applications will
likely never take over the world because they still need an OS on the
backend, and that OS will be written (likely) in C because it’s hard to
bootstrap enough to run Perl without native code that is ready to run
directly on the processor.
Anyway, the statement you provided is vague at best, and hopefully the
ideas above shed a bit of light on the truth.
Good luck.
nipunreddevil wrote:
> I just read somewhere that for the same purpose Python code is about 2
> to 10 times smaller than the corresponding c code.
> How true is that?
> And if true,why still majority of programmers are c programmers?
> Why Python and Perl have a small share in projects on sourceforge.net
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJKZ+mvAAoJEF+XTK08PnB5xRUP/2Ad32fgUSrl3BkO2WIpH99h
n6cRvgXlW7KygJyw93GoMsprV0M133KPY8BsFvEYg+WzcfRW5xKUZkOunFRhx6Wz
LT4VZGonyjpUH6ACpj9GYQVRTuRLFWsXlUjb1ZdiD4ZmJ3cjI0J6m/NI4bt0usuV
uvViG6OxgBWihaoKlUN1KA6sMjKMGxL8T/J+MgQd+iPr+CBtixaGKIBXFOfU/SrQ
XRDP6jIRYJpWuXTcCE/f7eQsSrLwmvxaSakkQ8uRH0IdaCauNUNIXgcZ4ExHIviZ
Lw/mK7evRi9Xnp/8I7wEd80RKugGq/ivPQEGnSvvZq+kVxclCdtgF0SjcNOsGx1B
UWe6qLfTbVTzHg3e+Xr6QiXWz6MsAh8Lu2wIFZ0RIKXXPEugYnzOw4cK0/dnt6tM
6nTtufGceddSFlJOn5mXpMiSJEJXHDfv8kpRxmVaK9v+ff7bf2UW6HKSWdwNeS+x
dH2WxVudlpR/8peIIiFPO71zHQpsYdChFtslkV6LwGwVLMqjxpJQks2avwofpVBi
hg3r9LEEilk0xqPijO8RanOD9mo/F4lFICG7tivjqBFNitD5uyJcduUOw6JCkmUG
qZ6n5891DSRGLlzZfTfHFxdjp8WCq0VJxx/XUV7g9GslzcsoPqbNscMXu6BMf6QR
7wTOesb6HufjRw41ouUR
=LcWp
-----END PGP SIGNATURE-----
(Small) size is not everything. 
What ab said.
I saw one time on the web a project for a Perl compiler.Why interpreted language have a compiler too. So that you can compile the source code for a fast application(if you want).I mean why aren’t such projects promoted?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You probably lose one of the big benefits immediately… cross-platform
support. Typically the time taken to compile is fairly small and there
are numerous ways to optimize that (like having the program run
continually instead of being loaded by something outside over and over, or
perhaps by having some other engine load it and use it over and over vs.
recompiling over and over. Whether or not it is really compiled at
runtime, I do not know, but at the very least ‘perl’ (the binary) is
compiled and setup to run a certain way at runtime.
Good luck.
ionpetrache wrote:
> I saw one time on the web a project for a Perl compiler.Why interpreted
> language have a compiler too. So that you can compile the source code
> for a fast application(if you want).I mean why aren’t such projects
> promoted?
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJKaGevAAoJEF+XTK08PnB52owQAM0iu+TtEW8JcSMLCMuNZTJK
ikE9ga0z6O8YYOdpePkDN0J0+mZwGSqOUq8kBsFBpZ1faC9fz/okeDWlRsSVygrK
cpiHqSnlhgSQU2AvY3/22VDQImY0Aen2RJNMlhRlqF3VXDsG/vqg0xPAL78LAA7v
CLgdGl/yEnlbz4x4b0k15y6w+CMKM/+WiPpUTAQpIDzUntU4yDozQWNHb5N2Ndyo
bB5bTyMRnpw3OEfDTJ6qwsxWUyrwXht+uELdHdvDTnV9TlFmmDfxZDJde0581O+5
RT2IRiZG7Fxx/3rhBgnyChHKV74tKX5V5GdKt1F/dOKhod6MHG9xTFpYK9Frgq1F
DwhV2cn0d1t+rLyGPkAZtwsw0Ruit0/UovXkT3l084AFZxbHoqUJgE/A1epKNsQx
JC4xQZTSVg3tzcAGcF4OwppWXw6Ji8BIJisvfxIZY8WZb9EaEOMKnJYR7AxWZr7l
kxy8Y16+BEDTEqUQhb05kIuuwnsKO9cRZ8QdR7ibZNPCAzlpz8nf34yOyhK3Lh10
MT6hMceuGyl9K29iovAVWt9uhM2USFoOdsg5xjaj8hMz3xRprQAKGACbfJd9+opm
O67XZMheli0tRP/eENVcwSdxIr2KzXwu0qjRw0cHF4IkVU0kQljsZdniqHwlPsof
dP5tONFkZ/sBt2IIeAsE
=sb8c
-----END PGP SIGNATURE-----
ab@novell.com wrote:
> This is a bit too general to really be a practical question or a solid
> statement. For example any scripting language can output to STDOUT in
> about seven bytes, for example as the following in bash:
>
> echo hi
>
> Boom… seven bytes. C can never compare. Perl is similar:
>
> print ‘hi’
>
> Ten bytes! Amazing. Now on the other hand, C programs are compiled, so
> everything they need to work (aside from the OS, which is not considered
> in this or the scripting examples) is part of the actual program. To give
> C its due you must remember that behind the ‘perl’ command is the entire
> Perl language, its binary, and possibly dozens or hundreds of modules.
> Now the same ‘print’ command is made up of several megabytes…
> twenty-nine on my system for the ‘perl’ package alone.
This is not how it usually works.
See e.g.
/*
* load50.c -- a simple busy-looping tool.
*
* Obviously, this runs with any kernel and any Unix
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char **argv)
{
int i, load=50;
if (argc==2) {
load=atoi(argv[1]);
}
printf("Bringing load to %i
",load);
for (i=0; i<load; i++)
if (fork()==0)
break;
while(1)
;
return 0;
}
$gcc -static -o load50 bin/load50.c
$du load50
2270 load50
$file load50
load50: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.4,
statically linked, not stripped
$gcc -o load50sh bin/load50.c
$du load50sh
12 load50sh
$file load50sh
load50sh: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.4,
dynamically linked (uses shared libs), not stripped
In C/C++ or other compiled code one can choose to link the object file to the libraries
or not, in an interpreted language, you (generally speaking) have no choice.
But most of the time, compiled objects are dynamically linked to libs, and so whether
the code runs depends on the libs to be installed or not.
>
> So there are tradeoffs. Compiled (vs. interpreted) applications typically
> run faster because there is no runtime conversion to machine language. On
the other hand, the speed that compiled programs reach is often greatly
contributed by the fact that the developer didn't bother with error-trapping,
exceptions handling or very thorough malloc() and free() handling, things that
are done by interpreter on the side too. Now back to
> the other hand it takes a lot more work to write a quick app to do
> something basic, and scripting languages can also be customized to do
> certain things well (Perl for system administration, PHP for web-based
> stuff, awk/grep/sed for text hacking, etc.). Scripting applications will
> likely never take over the world because they still need an OS on the
> backend, and that OS will be written (likely) in C because it's hard to
> bootstrap enough to run Perl without native code that is ready to run
> directly on the processor.
>
> Anyway, the statement you provided is vague at best, and hopefully the
> ideas above shed a bit of light on the truth.
>
> Good luck.
>
>
>
>
>
> nipunreddevil wrote:
>> I just read somewhere that for the same purpose Python code is about 2
>> to 10 times smaller than the corresponding c code.
>> How true is that?
>> And if true,why still majority of programmers are c programmers?
>> Why Python and Perl have a small share in projects on sourceforge.net
>
>
TheoHere’s one reason: It takes longer to write native code generators for the compiler for all the platforms you want to run it on. You need a backend that can generate assembly code for PCs, PPC, ARM, SPARC, and dozens of other CPU architectures out there. And everytime someone asks about supporting another CPU, you have to write another code generator.
You can plug into the GCC (as in GNU Compiler Collection) framework and reduce the work. Languages that have done that include the C family of course, Fortran, ADA and Java. But it’s still a lot of work.
If you use an interpreter, you just write the interpreter in C and maybe some very tight sections in assembly and if your coding is portable, the porting is done. Assuming you have a decent C compiler for that platform. If gcc runs on that platform, then you do. Well, you also have to build the runtime support for that platform. Just see how many platforms Perl runs on.
You can also have a mixed strategy where you compile to an intermediate form and then execute that more compact form. Internally that’s what Perl does. And Java of course.
And finally, it simply may not be worth it. If your interpreted language is at a fairly high level, then for many tasks the overhead of interpretation isn’t significant compared to the operations you are doing. An example would be the regular expression constructs of Perl and other languages. Those operations take more than just a few machine instructions. If you were to write the same program in C, you would end up doing the same calls to regular expression libraries.