forum.vdsworld.com

[Skit3000]

I just created the script below to test which is faster: a lot of functions on the same line, or the same amount of functions spreaded over multiply lines, to see how to create your program so that it works as fast as possible. Over here, the "longline" test is much faster then the "spreaded", about 20%. Maybe it's something to think about when programming?

[FreezingFire]

Interesting

[Hooligan]

Very interesting... (Good job, Skit!)

Hooligan

[Hooligan]

Whats even more interesting, is that you're doing one more @succ() operation in the one-liner. (Yet it's still faster?!?!?) Or did I count wrong?

Hooligan

[Skit3000]

Both scripts should have just as many @succ commands, 20 in total...

[jules]

On the whole, I think it is better to write code that is easy to understand and debug, than sacrifice this for a 20% speed gain that will probably never be noticed. If there is an error somewhere in that bunch of nested functions, you'll have a hard job finding it. If speed is that much of an issue, you probably shouldn't be doing it using an interpreted script language in the first place.

[Skit3000]

Julian, I created this code to see which option is faster, so it can be used in DSU files which need to be fast (like my database DSU). But I agree with you that if you create code of which speed is not the biggest problem, you should use the first method, which is far more easier to understand...

[Serge]

good find skit

serge

[vdsalchemist]

Skit,
You have stumbled upon a known issue with all programming languages. It requires less memory to be searched and parsed when used in a single line of code but the trade off is not worth it. Not even in a DSU. Spegetti code is never good. Let me know 6months from now if you can still read that DSU's code when your customers need it upgraded. When you try to put as much as you can on one line of code what will happen is errors will creep in and since it is so jumbled you will not be able to locate it. You will then have to figure out how to either separate the line into multiple lines or re-write the code.
IMHO no one should ever take this route when programming todays computers since they are so much faster than machines used 20 to 30 years ago or even 10 years ago. Actually there are many things I have seen in others VDS code that if it was not for the fact that everyone does it I would have never done it that way. For instance I would not use the goto command so much if it was not for the fact that just about no one here really understands the importance of structured programming. Under other languages it is tabo to use the goto unless it is absolutely nessary to bring the US Space Shuttle back down to earth safely and there just is no other option. Luckily most everyone that uses the goto command at least has a goto that returns to the label that originally called the first goto command. That is the only reason I have not really said anything about it before but when you program has more than 5000 lines you may need to start using Structured Programming technics.

Well I guess I can get off of my Soap Box for awhile but I did try to submit demo's with my DLL's that used structured programming but I kept getting so many questions about how they work that I had to drop the notion with my demos and go back to using goto's.

[JRoza]

Hear, hear!

I fully agree with Dragonsphere.
My coding was never the shortest when compared to that of some collegue programmers, but mine could be interpreted by anyone in a short time whereas the coding of the "turbo-whizzkids" was very fast and compact but no one knew what the hell was going on after a year after the original programmer left the company.
And since my hair turned gray and even i had some trouble getting into old code in a short time I started using inline documentation in my code.
So now my code reads like a storybook and everyone should be able to get to grips with it in a flash.


"Gray dove" Jan

[jules]

I entirely agree. One of my memories of when I started as a programmer, 30 years ago, was of trying to find a bug in a program written by someone who had left, in which there were no comments, and many of the variables were named after characters in Star Trek!

One of the reason VDS has never allowed more than one command on a line, is because of my memories of trying to figure out programs in other languages that were written like that.

VDS was really not designed for structured programming, and I think that is actually one of the benefits of it, because it enables you to knock together little applications very quickly, much quicker than you could do in another language where you are forced into using a structured approach.

[vdsalchemist]

Jules,
I agree that VDS was originally meant to be a simple language to allow a programmer or non-programmer to knock together a simple utility. You have to agree though that the VDS today is not the VDS that you originally wrote. It has changed and grown. Now people are using it in business more and more. We are no longer just using it as a hobbiest language. We are writting real applications with it and building bigger and bigger programs with it. A program with a few 100 lines of code is no big deal but programs like some of those I have seen written here are too long to not apply structure to them.
A 20% increase in speed is not worth days of scratching ones head. I may combine 2 or 3 functions into a single line but only when processing events and only if I comment them. Anyway one of my issues I have with most of the code I see here is like the line of code below.

[Skit3000]

Dragonsphere, I agree with you code needs to be commented, and like your @sendmsg example, numeric values should be stored in variables, but I don't do both a lot because I just don't know how to write down the comments... Most of the time, when I dó try to put comments on every line, I remove them a few minutes later, just because they are unnecessary (or well, that is what I think of them). That is why today I mostly only add comments at the beginning of functions, subs, labels and big blocks of code which do special things.

For school I had to work on a Visual Basic .NET project in which we created a huge customer database and everything related with it. Because only 2 of the 6 people of our project group knew enough about programming/databases/VB, we put comments everywhere. Unfortunately, because these other people don't understand the logic about programming, the comments were overwhelming. For every line in our program, we had to add two or more lines of comments for letting them understand what it does. Lines which combined VB functions and SQL queries even took 8 or 10 lines!

Maybe one could give some examples about how to comment a program well, so it is readable for other people? Not only for Visual Basic, but for all programming languages in common?

[vdsalchemist]

[Skit3000]