deliverance from complicated programing languages?

This is a discussion on deliverance from complicated programing languages? within the A Brief History of Cprogramming.com forums, part of the Community Boards category; I have to agree with you CornedBee. The statement was overly simplistic. An attempt at addressing my POV that I ...

  1. #46
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,467
    I have to agree with you CornedBee. The statement was overly simplistic. An attempt at addressing my POV that I could have developed better.

    The point was - is - to address the importance hardware has on apparent software performance when all else is equal.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  2. #47
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by Mario F. View Post
    The point was - is - to address the importance hardware has on apparent software performance when all else is equal.
    Don't you mean actual software performance? Because apparent (subjective) performance has really nothing to do with hardware at all. It's about how good the programmer is at hiding delays from the end user.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  3. #48
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,467
    Quote Originally Posted by CornedBee View Post
    Don't you mean actual software performance? Because apparent (subjective) performance has really nothing to do with hardware at all. It's about how good the programmer is at hiding delays from the end user.
    Hmm... Let's see.

    I measure actual performance only when comparing to other software of the same kind. In that context, I would say actual performance will be dictated by good programming practices, code optimization, choice of language and even within the same language, choice of compiler.

    By apparent performance, I mean what is perceivable to the user. Some performance differences are so minimum that they are never perceived by the user. Conversely, some may be larger, but in the context of the application usage they have little to no impact.

    And this is the cornerstone of my reasoning. It brushes Bubba's rightful concerns. But it is not really what I'm defending here. What I'm saying is that the choice of programming language should only rarely be a matter of performance because a great part of the software being developed can be developed in "slower" programming languages with little to not impact on the user's experience. Naturally, some software types can't be so lenient.

    I do go one step further though... I also defend that some speed loss choices can be taken (the 2 seconds example) based on the fact they will have little impact on the user experience, assuming that if the choice was to move to a "faster" programming language that would complicate the life of the programmer (he doesn't know that language so well, or foresees a longer/unacceptable period of development, for instance).
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  4. #49
    l'Anziano DavidP's Avatar
    Join Date
    Aug 2001
    Location
    Plano, Texas, United States
    Posts
    2,738
    Well I decided to chime in as well now.

    I completely agree with CornedBee's statement. Some elements of speed do belong to the hardware, and others do belong to the programming language, but a lot of it relies on the programmer. If the programmer chooses a good algorithm versus a bad algorithm, then in the end the program will perform much better.

    I have sat through many interviews with various software companies, and this is what I have noticed - they want to know if you really understand how to program well, despite what language you are using! If you know how to program well, and program efficiently, then you can get the job.

    About a month or so ago I started a thread that linked to an article which primarily talked about the merits of C or C++ vs. Java. The author of that article talked about how in today's world we are producing more and more people who have Computer Science degrees, but simply don't know how to program. It is because they have not learned the essential concepts of good algorithm design, good coding techniques, and good performance optimization. This is an essential part of any programmer's education.


    Now, I noticed that Mario F. said something along the lines of "a program taking 5 seconds to start up is not slow." I completely disagree. Users want things to happen fast and instantaneous, and therefore, a good response time to a user is usually no longer than 3 seconds. Any longer than 3 seconds and the user will begin to lose concentration. This is how "splash screens" came about initially. Some programs took much longer to load, and users would lose concentration and get frustrated. In order to keep the user happy, a "splash screen" was instantaneously displayed on the screen so it looks like something is happening, and therefore the user's concentration doesn't go away as fast. For some highly intensive programs a splash screen wasn't enough, and they even put in a loading bar to keep users happy.

    The bottom line is, however, that after about 3 seconds a user's concentration begins to stray, and so anything slower than that could be considered as "slow". Of course this is different for different tasks that need to be performed. Here is a table that I saw recently:

    Name:  response times.PNG
Views: 97
Size:  26.5 KB


    Now, a programmer should do all he can to make sure his program is efficient and runs well, and does not bloat. In some cases, however, it could also be the fault of the scheduler in the OS. Maybe the scheduler needs some work.

    In the case of Firefox which was discussed earlier, I have had no problems with it. I have not actually looked at Firefox's code, but I assume (purely an assumption) that they are using multithreading, and have a seperate thread for each tab. I think having a separate process for each tab would be going overboard, especially since communication between threads is much faster and easier than communication between processes.
    My Website

    "Circular logic is good because it is."

  5. #50
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,467
    I'm still not convinced David

    5 seconds is really a long time? Firefox can take that long on a fast machine. All you have to do is to make sure it needs to be paged. Microsoft Office software takes that long. Much software does.

    The argument of user losing interest works well for websites, not just for software. I used to listen to that back in the 80s. Not much anymore. It takes certainly more than a 5 second difference between two programs loading times for it to make a difference. Especially when one of them offers a richer set of features and that has a natural impact on loading times.

    However we seem to be wanting to turn the discussion towards the quality of software development, again.

    The only thing I was - and still am - trying to comment on is the choosing of a programming language over another based on "speed". Ruby is definitely slower than C. But is that going to stop a Ruby programmer developing, for instance, a measurements converter, or a MD5 calculator, or a tile based client for a web turn based wargame?

    These type of applications have little requirements in terms of speed. It's not to say one should be sloppy coding them. I feel I have to say this again, in case we get to it again. That is simply to say I should choose a tool for programming those application based on other considerations than speed.

    I believe speed is overrated in this context. Especially because a large part of the application we develop do not have very high speed requirements.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  6. #51
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    (I don't know if I'm on the ignore list still, but I'll just say it anyway.)
    For small applications, of course it doesn't matter what language because the speed impact will be small. But for larger applications, it does indeed matter.
    And for that matter, load time is also bad and why the .NET Framework destroys so many applications. Who is to say how much faster Visual Studio wouldn't be if it wasn't built on top of the .NET Framework?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #52
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,467
    I do have to agree that I too don't see much point in developing non web based applications for the .Net framework. However this framework is not going to go away. So we might as well get used to it as yet another solution that is bound to improve with time.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  8. #53
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    Yes, this is true, but we can avoid it unless we must use it, or the advantages outweigh the disadvantages.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #54
    Registered User
    Join Date
    Jul 2007
    Posts
    88
    There ARE people who care if it takes 1 or 5 seconds. Even if it does not matter for you, it matters.

    So Mario F., if I understand right your answer is 'there "is" already deliverance from complicated programming languages because we have easy programming languages'. Or in other words 'there will be never deliverance from complicated programming languages because speed is not an issues for 99% of people".

    Well, this is an interesting way to avoid my basic question. The basic question was something like "will we get an compiler (to machine language, not just byte) for easy dynamic scripting languages such as ruby?".

    Currently compiling (to machine language) dynamic languages isn`t possible due to it`s design. Will some expert found a way anyway?

  10. #55
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    It's possible, it's just not worth the effort, because the generated machine language isn't very efficient.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  11. #56
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by sept View Post
    There ARE people who care if it takes 1 or 5 seconds. Even if it does not matter for you, it matters.

    So Mario F., if I understand right your answer is 'there "is" already deliverance from complicated programming languages because we have easy programming languages'. Or in other words 'there will be never deliverance from complicated programming languages because speed is not an issues for 99% of people".

    Well, this is an interesting way to avoid my basic question. The basic question was something like "will we get an compiler (to machine language, not just byte) for easy dynamic scripting languages such as ruby?".

    Currently compiling (to machine language) dynamic languages isn`t possible due to it`s design. Will some expert found a way anyway?
    The problem, when designing a computer language, is that things that become real easy in an interpreted language (such as Byte-code) can be REALLY difficult in a machine-language compiled language. The way that a language is designed will often determine if it's going to compile directly to machine language or not - the key here is to "make it machine language friendly". One of the keys here is "polymorphic variables" - that is, variables that are integer, string or float depending on their input value and usage. That essentially requires some sort of overhead in the compiled form. In an interpreted form, the digging out of a variable value is not machine-language directly, so it will have some overhead anyways. I picked the topic of polymorphic variables because that's usually one of the key points that people bring out that they "need" in C or C++, that other languages (such as PHP and python) allows them to use.

    The other factor is of course that you can make your own high level language in C or C++ - that is, once you have a sufficient library of functions, you can re-use those functions as part of a high level functionality.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  12. #57
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,467
    So Mario F., if I understand right your answer is 'there "is" already deliverance from complicated programming languages because we have easy programming languages'. Or in other words 'there will be never deliverance from complicated programming languages because speed is not an issues for 99&#37; of people".
    Nope. Nothing like that. "Deliverance" is conditioned by many variables like tools (programming languages, if you will) availability and functionality, programmer's knowledge or development times constraints, to name a few. Performance is also one of those variables. It's the programmer task to analyze his project constraints and requirements as well as his capacity to handle those at the light of his knowledge.

    What seems to happen sometimes is that performance requirements are not well measured and we tend to give them an importance they don't have for that particular project.


    Well, this is an interesting way to avoid my basic question. The basic question was something like "will we get an compiler (to machine language, not just byte) for easy dynamic scripting languages such as ruby?".

    Currently compiling (to machine language) dynamic languages isn`t possible due to it`s design. Will some expert found a way anyway?
    And I answered someday someone may. I also theorized the solution may not be solely based on managed to machine code translations, but may as well come from a different programming paradigm yet to be developed that allows to combine speed with easy of use.

    As such, I wasn't avoiding the question. I introduced the speed issue at the end of my reply because you did mention it in your initial post as one of the requirements and I wanted to have a say on that. Unfortunately, it became the only thing people decided to comment on.

    Quiet frankly I would have rather preferred if any comments on my post had been directed to the programming paradigm portion.
    Last edited by Mario F.; 02-25-2008 at 05:25 AM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  13. #58
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    Quote Originally Posted by sept View Post
    C is MUCH harder (I hope no one argues which this opinion?), but it`s fast.
    Since I have never worked with Ruby I have to disagree with this. It is easier to use a language that you are familiar with then to use a language you are not familiar with. Suppose there is a language with a much simpler syntax then English, it would still be harder for me to communicate in that language instead of English.

    C can be very easy to read if you purposefully work towards that goal. Meaningful variable names, good indention, and useful comments can do much more then pretty syntax.


    On algorithms:
    Knowing how to create and measure good algorithms is definitely key. But most important, IMO, is knowing how to practically apply them to your environment. For example, in my computer architecture class we took a look at two different sorting algorithms (IIRC quicksort and mergesort), now from a purely algorithm stand point one overtook the other at some N value; however, when ran on an actual machine it actually did worse because the cache wasn't able to predict what should be cached as well. There are also things like knowing what hardware is available; for instance running a lot of floating point calculations on a processor without a floating point unit is going to take you awhile.


    Last thought:
    While desktops are getting faster, beefier, and able to mask poorer programming they are far outnumbered by the amount of embedded processors (cellphone, ipod, calculators, cars, etc), which aren’t nearly as powerful. I have a project now to build an autonomous robot that can explore and navigate a maze that is using a 16 MHz processor with 4 Kb of RAM and 128 Kb of flash. You better believe that the choice of language and algorithm will be playing a big part in its performance.

  14. #59
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    Quote Originally Posted by Thantos View Post
    Since I have never worked with Ruby I have to disagree with this. It is easier to use a language that you are familiar with then to use a language you are not familiar with. Suppose there is a language with a much simpler syntax then English, it would still be harder for me to communicate in that language instead of English.

    C can be very easy to read if you purposefully work towards that goal. Meaningful variable names, good indention, and useful comments can do much more then pretty syntax.
    Nevertheless, some things such as GUI is very difficult to do in C/C++.
    This in turn makes C/C++ a very difficult language on that regard.
    Also compared to other languages, C/C++ is also very difficult due to the low level, such as pointers, arrays, bounds, etc, etc. Some may have trouble grasping it, but I agree with you that once you get to know it, it's not a difficult language itself.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  15. #60
    Registered User
    Join Date
    Jul 2007
    Posts
    88
    Quote Originally Posted by CornedBee View Post
    It's possible, it's just not worth the effort, because the generated machine language isn't very efficient.
    Ok, I see. Again wrong question from my side.

    Isn`t the goal to create machine code. My goal would be to create cod fast as code compared with C.

    And... This isn`t possible? Right... I think matsp explained the issue well.

    Also an interesting point in this topic was that our hardware becomes better and better and at some day we are no longer forced to use fast programming languages.

Page 4 of 6 FirstFirst 123456 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Why C Matters
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 136
    Last Post: 01-16-2008, 08:09 AM
  2. Strange loop
    By D@rk_force in forum C++ Programming
    Replies: 22
    Last Post: 12-18-2004, 01:40 PM
  3. Languages dying
    By Zewu in forum A Brief History of Cprogramming.com
    Replies: 31
    Last Post: 07-29-2003, 10:08 AM
  4. Programming Languages
    By DarkViper in forum A Brief History of Cprogramming.com
    Replies: 3
    Last Post: 12-12-2002, 01:28 PM
  5. How can an api be accessed through other languages
    By Shadow12345 in forum Windows Programming
    Replies: 6
    Last Post: 10-21-2002, 07:01 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21