GeneralThis forum is for non-technical general discussion which can include both Linux and non-Linux topics. Have fun!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Windows XP, yup :D Will be back onto Ubuntu probably someday
Posts: 107
Rep:
No language is productive, it is the programmer which is productive. Suppose a programmer had an in-depth knowledge of every possible construct, function and feature of every programming language known to man (including binary!). Then imagine that he (or she) would have to produce a working program using only one language.
The programmer would have to choose which language is most relevant to his problem. If it is solving a differential equation then Matlab or Octave would probably be the most productive, in that there are already libraries in Matlab which can solve the problem for him.
The saying 'Dont reinvent the wheel' is most relevant to this topic. Whichever language has the most functionality already existant that allows him to solve his problem would be used. Whichever language abstracts the hardware into a domain relevant to the problem is best suited.
... and matlab is dead easy and there are also language tools created for/by chemists and teachers and their similar specific domains and they are suppose to be really dead easy for them ...
and i heard that theres a tcl/tk developer/startups saying something along the lines of "ok ... it gonna takes me about a week or two to deliver this little tool for your office ...[hehehe]"
whatever it is , its a very good and interesting read for all kinds of people ... whether they are startups or laboratorians or hobbyists ...
>> The saying 'Dont reinvent the wheel' is most relevant to this topic ...
very true ... public opinions are very easily swayed and thats is probably why i see no reasons why cant linux and the rest of the *nix(and dont forget about our mac too) dominate all kinds of specific computing domains ... either by commercial "unscrupulous shrewdness" and by recruiting/employing really bright(and budding ones too) brains as what some have definately shown themselves down here , and they are almost probably from the linux/*nix world actually ...
No language is productive, it is the programmer which is productive.
Can't agree with you there. A thought experiment: Let's say a programmer is equally knowledgable in C++ and Python. Give him/her some specs for an app that needs to be written, and instruct to create versions in both languages. You cannot tell me with a strait face that the Python version will not be finished considerably faster than the C++ version.
By definition, an interpreted language will be more productive because there is no compile-link-test cycle to go through. Simply write and test...
Distribution: Windows XP, yup :D Will be back onto Ubuntu probably someday
Posts: 107
Rep:
An interpreted language MAY cause the PROGRAMMER to be more productive because of immediate 'compiler' messages, but then again, if the program must be designed with memory and speed in mind, C++ may take longer for a finished product, but would be desired for the fact that it suits the requirements - like I said, "have to choose which language is most relevant to (the) problem".
slantoflight - lol! I should have said it is the programmer whose productivity should be measured, not the language.
Anyway, as most things in life, its not black-and-white and a pretty subjective notion.
Not sure if this was mentioned, but I think that tools available for a given language are of a great help in productivity as well. I use Eclipse/Java a lot and I can create applications very fast with Java all thanks to Eclipse making things easier, pointing errors and a lot of neat stuff. If I was to develop the same application using Java and VI, it should take way longer time compiling, testing and debugging.
To sum up, I think the use of good IDE's (and other tools) that helps the programmer instead of getting in the way (as a lot of IDE's does) has more to do with a programmer being more productive than the language itself.
You might have a little trouble telling your computer to get a project done with just body language.
Although I guess with some effort you could write an interpreter that converts your movements to C.
For instance, if you nod, it finishes and compiles. If you have a frown, it generates a bug. If you look frustrated, it generates a really big bug. If you bang your head against the table, it generates a virus then erases all your work. If you pull out your hair, it melts your CPU to the motherboard.
Ofcourse a really good interpreter will be understand multiple expressions.
So if you frown, look frustrated, bang your head against the desk and pull out your hair, it should automatically generate windows 98.
I suspect Bill Gates of using the body language,
because when I used his product it crashed just as
many times as the number of pies thrown in his face.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.