> Other than templates and macros, what can I do to increase my coding
> speed? I'm taking too long. :(
Get someone (or someones) else on board to help out? But as the
old saw goes when quoting for a customer:
"You can have it (a) cheap (b) quick (c) right; pick two."
You don't say what you're developing (I assume it's for DOS as
you're posting here) or what language(s) you're using -- maybe a
few more details might elicit useful responses?
Pete
--
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."
Practice!!!
There's no substitute for practice. Practice, practice, practice.
And when you're finished, practice some more.
No amount of macros or templates help in that area.
Use an existing library.
Design then code
Alex
Of course, the other suggestions before this post would be useful.
But I *do* plan ahead and use other people's libraries. ;)
>Other than templates and macros, what can I do to increase my coding speed?
>I'm taking too long. :(
Templates and Macros are worthless if a person is unproductive and plays in
newgroups asking people questions instead of programming non-stop day and
night. Try coding non-stop for several weeks and stay out of the forums and
you will probably see an improvement. Try coding non-stop for several years
like some (many) of us and you will be able to answer more questions than
you ask.
Templates and Macros are still pretty much worthless.
The necessary background information for a quality or thorough or detailed
response to the question is unmentioned.
The more tools, libraries, and algorithms that you use which were written or
developed by others, the less time it'll take. But, you'll also become
dependent on the power or flexibility of those tools or libraries, and
you'll also inherit their bugs, deficiencies, and limitations. The more you
write/code your projects from scratch or as standalone applications, the
more time it'll take. If you develop your own code base or libraries, which
you can reuse and/or "cut-n-paste" from, the less time it'll take. These
generalizations or this "big picture" description is about all I can say
without more info.
> I'm taking too long. :(
No easy solution here. It can take many many man-hours to develop even
simple programs that are actually useful. OTH, some things are so simple
and so little used a poorly coded app will do the job forever. Are you
"biting off more than you can chew"? I am with my projects... And,
sometimes you forget stuff, don't "see" the easy solutions that day or the
next..., learn new stuff, have mental blocks, are ill, sick, depressed, etc.
All of these things affect your coding. I don't think there is an
experienced programmer alive who hasn't coded some monstrosity to get the
job done today or this week or this month, only to say "Duh" at a later date
and replace the whole mess with a few lines of simple code.
Perhaps moving slightly away from what you were asking... C is my favorite
choice for a language, but CS theorists indicate it takes more work to
program than other languages. The following links provide various
comparisons of language efficiency and popularity:
http://web.archive.org/web/20061231170804/http://www.theadvisors.com/langcomparison.htm
http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
The first link (archived - original link is dead) indicates C requires more
typing (typing as in coding - not as in type system) than other languages.
I.e., it's less efficient in terms of amount of written code than other
languages. Most of languages that are ranked the highest, 20's, 50's or
60's etc., are languages no one has ever heard or likely ever used. For
reference, it ranks nearly every language that you, I, and everyone else is
actually familiar with, as being fairly low, like below 10: e.g., Java and
C++ as 6, vs. C's 2. Unfortunately, this was released in 1996 and so
doesn't include modern dynamic languages like, say Ruby, in the comparison.
The graphs in the second link indicate C is one of the fastest overall
languages, if not the fastest. Unfortunately, there is only a single
composite .png of graphs, AFAICT. So, it doesn't seem to be possible to get
a nice closeup view of the important area of the graphs of say ATS or Java 6
vs. C. It's hard for me to tell from them which is "better" in regards to
speed.
The third shows which languages are popular from statistical samplings of
languages used by corporations. You can see from the graphs that popularity
varies, sometimes wildly, over time. However, further down, it shows that
C, C++, and Java have been in the lead for some time now.
Rod Pemberton
P.S. threw on comp.lang.misc in case they find the links above useful.
Not necessarily. You have to compare the time it would take you to implement
the functionality you're going to use by yourself with the time it will take
you to learn the third-party library, work around any bugs or missing
features it may contain, and write the code using that library.
It is commonly assumed that if there is a library that does the sort of thing
that you want, using it will cost less time than implementing the desired
functionality yourself, but this isn't nearly always true.
Regards,
Bob
Perhaps not... It seems I still have more "food for thought".
The choice of languages and tools can also kill the acceptance of your
project by others, if that's important to you. There have been many
brilliant projects that have died, or never gained much acceptance, due to
their choice of language or tools. I've seen projects that use ocaml,
python, lisp, etc. die since they weren't as portable or maintainable as
projects entirely in widely used and/or popular languages like C or C++. I
can't tell you how many projects I've seen for the C language that weren't
written in C. (What's the point? What's the point of developing a tool for
C users if they can't maintain it?)
Another thing to consider is whether a library ia alive or dead. I'll
define an alive library as one that is widely used and still maintainted.
An alive library has advantages and disadvantages:
1) it's maintained:
1a) so bugs will be fixed by someone else's time and life and/or money
1b) bugs will likely be corrected by someone who knows the library well.
i.e., a quality fix
1c) you won't have control over the library. e.g., changes to the
library could require rewriting or reworking your code and may occur
frequently
2) it's likely the library is alive for a reason, e.g., has much
usefulness
A dead library has advantages and disadvantages:
1) it's unmaintained:
1a) you'll also have to fix bugs thereby consuming your time and life
and/or money
1b) the bugs will be in unfamiliar code. i.e., your fixes might not be
as good as fixes by the original authors
1c) you'll have complete control over the library. e.g., any changes by
you to the library affecting your other code will be expected and acceptable
2) it's likely the library is dead for a reason, e.g., of limited value or
usefulness
Rod Pemberton
Maybe increasing the dose of your psychiatric medication might help.
I know I'm late to this thread, but let me suggest one thing:
Find a decent editor that does what you want.
In particular, I would blindly guess VILE, VIM, JED, or especially GNU
Emacs would fit the bill (although I personally like TDE a lot). Emacs
(and JED) support dabbrev, tags, regex search/replace, syntax
highlighting, paren matching, and goto compiler errors, hence very
useful for saving time. (GNU Emacs also has dired file manager,
eshell, calc, etc.) JED and GNU Emacs also have very very good mouse
support.
http://www.jedsoft.org/
http://www.bttr-software.de/misc/jed9918d.zip
GNU Emacs 23.1 was just released recently, and it compiles again and
works great with DJGPP. (Sorry, no precompiled package yet.) Give it a
try if you haven't already. It's self-documenting and very popular, so
you shouldn't have any trouble using it. (Heck, it even emulates vi
[or others] if you really want, so it's an all-in-one solution.)
>GNU
This guy is MS Windows-Oriented. Textpad would be a better fit as a editor.
Regardless, in his particular case I doubt whether any editor will help. See
below:
----- Original Message -----
From: "Bill Buckels" <bbuc...@mts.net>
Newsgroups: comp.os.msdos.programmer
Sent: Tuesday, August 11, 2009 2:31 PM
Subject: Re: Speeding up the coding process
"Harry Potter" <maspet...@aol.com> wrote:
>Other than templates and macros, what can I do to increase my coding speed?
>I'm taking too long. :(
Templates and Macros are worthless if a person is unproductive and plays in
> Templates and Macros are still pretty much worthless.
I once wrote a program almost entirely in macros. It was in PIC assembly
language and featured a lot of repeating code that had to be inline
for timing reasons. It was harder to write, but easier to get right and
to understand, but almost impossible to maintain. It was right at the
limit of what the PIC could do at it's maximum clock frequency. I hope I
never have to do anything like that again.
The bottom line, as you indicated, is time spent programming: somewhere I
read that it takes 10 000 hours of doing *anything* to reach master level.
I'll settle for merely competent with the languages I need and use, and
since that has changed over the 25 or so years I have been programming, I
may not have managed to reach the 10 000 hour level in any one of them.
--
T.E.D. (tda...@mst.edu)
MANY years ago, I taught a second-level "assembly-language programming"
class in which we wrote macros for one assembler on one machine to
produce executable code for an entirely-different machine.
I don't recall any details after 30 years, but the first machine was
probably the then-ubiquitous IBM /360 and the second machine was probably
the MOS Technology 6502, but might have been an Intel 8008 or 8080.
--
--Myron A. Calhoun.
Five boxes preserve our freedoms: soap, ballot, witness, jury, and cartridge
NRA Life Member & Certified Instructor for Rifle, Pistol, & Home Firearm Safety
Also Certified Instructor for the Kansas Concealed-Carry Handgun (CCH) license
>I don't recall any details after 30 years, but the first machine was
>probably the then-ubiquitous IBM /360 and the second machine was probably
>the MOS Technology 6502, but might have been an Intel 8008 or 8080.
There are only some minor differences among them. The 6502 had some fine tricks
for indexed addressing. The 8008 (never worked with) must have been terrible
dumb. The 8080 is the silicon I started with. Really interesting. But some
others, like the SC/mp (forgot the correct writing) also had some nice things.
And the Cosmac walked in space. That (both Cosmac and walking in space) I did
not try.
--
Leben und Sterben im Pazifik