On Sep 15, 2006, at 1:37 PM, Robert Sneidar wrote:
Actually I use comments in a fairly unique way. I pseudocode what I
want to do in comments, and then code around the comments so I can
keep track of where I am at and what I am trying to accomplish.
This is what Steve McConnell recommends
Chipp-
Monday, September 18, 2006, 3:15:21 PM, you wrote:
I remember something Mark Weider pointed us to a year or so ago. It
said something about resisting the impulse to wipe it clean and start
over from scratch. It mentioned typically there is a lot of smart
I don't remember the article,
Actually Dan, I think I got it from you years ago after having read
one of your books on Hypercard. (Or was it Pascal?) :-)
Bob Sneidar
IT Manager
Logos Management
Calvary Chapel CM
Interesting, Bob. I just posted a note on my approach to coding in
the main
thread of this discussion and
I suppose it really depends on the nature and scope of the problem.
Recently I spent a day trying to sus out RegEx in order to write a
function to determine if the + operator in Foxpro code was doing
concatenation or actually doing math. I struggled with extracting
just the portion of the
Geoff Canyon wrote:
On Sep 15, 2006, at 1:37 PM, Robert Sneidar wrote:
Actually I use comments in a fairly unique way. I pseudocode what I
want to do in comments, and then code around the comments so I can
keep track of where I am at and what I am trying to accomplish.
This is what Steve
Hi from Paris,
Getting strange messages from your computer such as :
well, am I the only one that saw:
Keyboard not found.
PRESS ANY KEY TO CONTINUE
as a very subtle joke?
reminds me of the early days of PL/1 (IBM 360 in 1967)
The guy responsable for the compiler error statements was
While I don't always follow this procedure (partcularly on small, one-off
problems), when I'm doing original coding, I frequently write the program in
pseudo-code comments and then go back and write uncommented lines of actual
executable code between the comments.
Perhaps because I'm primarily a
Interesting, Bob. I just posted a note on my approach to coding in the main
thread of this discussion and it's quite similar (identical?) to yours.
Since you're an IT Manager, I consider my approach professionally validated!
:-)
On 9/15/06, Robert Sneidar [EMAIL PROTECTED] wrote:
Actually I
I believe no human is brilliant enough to foresee all core issues
with a project, regardless of how much planning is done beforehand.
In the end, one must jump in and start coding. If you are smart, you
only have to tear the whole thing down and rewrite it a few times.
And it's usually
Josh,
I think the earlier versions of Constellation were actually quite
good, but I decided to accommodate every request (nearly) and ended
up with a product that was more difficult to use than intended.
Taking too much user feedback to heart and not sticking to my
original design
Josh,
I'm NOT saying not to plan at all, that is as deadly as overplanning...
But Revolution's huge differentiating factor as a dev tool is that:
The prototype IS
the project.
Guy Kawasaki's philosophy is:
1. stop planning, jump in
Jerry,
I wonder about this exact issue as well. I have a program that gets
feature requests continually. There is no end to the number of
features that can be added. Not long ago I put out the mother of all
updates, adding a very long list of feature requests. The goal was
to set this
Shari,
I read Getting Real a PDF book from the folks at 37signals (they
did Ruby on Rails and Basecamp). They have a strong philosophy
regarding feature creep/bloat/etc. I wish I had read this earlier in
my career. I had the same experience you did and that countless
others have had.
On Sep 18, 2006, at 2:03 PM, Josh Mellicker wrote:
stop planning, jump in and start writing
The fast interactive design of Revolution allows lots of styles that
get feedback quickly. In my case, I'd rather experiment than
prototype. I like lots of heads-up data that do not fit into a
We recently did a V2 for both ButtonGadget and eXpertSystem. While in
both cases, the interfaces changed drastically, the underlying code
didn't change that much.
I remember something Mark Weider pointed us to a year or so ago. It
said something about resisting the impulse to wipe it clean and
Often it's better to keep a product simple and pure. If more is
needed, it might be another product entirely with it's own source of
funding (sales). We try and hold the line on features and
preferences. When we make changes, we favor the type that simplify
the product.
Funny thing is... I
On Sep 18, 2006, at 3:15 PM, Chipp Walters wrote:
resisting the impulse to wipe it clean and start
over from scratch. It mentioned typically there is a lot of smart
work-arounds, bug fixes and overall business logic in legacy code, and
if one is not careful, the baby will indeed be thrown out
Andre-
Saturday, September 16, 2006, 2:05:51 PM, you wrote:
-- The next 356 lines are here because we don't have damn threads!
which are not useful, but helps me relive some stress g
...Not appropriate for this list, buy remind me sometime and I'll tell
you a story along this line...
--
Dar-
Saturday, September 16, 2006, 2:15:47 PM, you wrote:
Now as far as intentions, that is a very good point and I'll apply it
to something else. When you or another comes back in to fix bugs,
you still have to maintain the meaning of the handler. You don't
want to break something in
jbv-
Saturday, September 16, 2006, 2:23:53 PM, you wrote:
comments are useful for human beings, but are computers supposed to joke ?
Whether they're supposed to or not, I think my computers have picked
up my bad habits.
--
-Mark Wieder
[EMAIL PROTECTED]
On Sep 17, 2006, at 7:33 PM, Mark Wieder wrote:
comments are useful for human beings, but are computers supposed
to joke ?
well, am I the only one that saw:
Keyboard not found.
PRESS ANY KEY TO CONTINUE
as a very subtle joke?
Andre
___
On Sep 17, 2006, at 4:36 PM, Andre Garzia wrote:
well, am I the only one that saw:
Keyboard not found.
PRESS ANY KEY TO CONTINUE
as a very subtle joke?
This reminds me of the system messages and help notes telling me to
contact the system administrator. I take that as a snide comment
Dar,
I find the most amusing being BeOS panic thing that dumped hex on the
screen followed by the friendly message: Welcome to Kernel Debug Land.
I always found that land to be terrible.
Andre
On Sep 17, 2006, at 7:54 PM, Dar Scott wrote:
On Sep 17, 2006, at 4:36 PM, Andre Garzia wrote:
On Sep 15, 2006, at 10:37 PM, Chipp Walters wrote:
I've tried writing code where no handlers/functions are more than a
dozen lines long, and while it is an interesting excercise...it's a
real pain to debug, not to mention to go back and try and figure out
what the heck you meant to do 6 months
Mark,
why not take this seriously ?
after all Xtalk can be viewed as the most advanced step of programing
language that describes computer tasks in natural language, the ultimate
step being fully natural language, which is what comments actually are...
and therefore, a fully natural prog.
Dar-
All good ones. One of the problems with RAD tools is that they make
the task of prototyping a bit too easy. I find myself whipping up a
prototype as a proof of concept and then start building an app from
there without having thoroughly thought out the game plan ahead of
time. And then I'm at
Chipp-
Friday, September 15, 2006, 9:37:27 PM, you wrote:
I've tried writing code where no handlers/functions are more than a
dozen lines long, and while it is an interesting excercise...it's a
real pain to debug, not to mention to go back and try and figure out
what the heck you meant to do
jbv-
Saturday, September 16, 2006, 2:30:21 AM, you wrote:
why not take this seriously ?
after all Xtalk can be viewed as the most advanced step of programing
language that describes computer tasks in natural language, the ultimate
step being fully natural language, which is what comments
On Sep 16, 2006, at 11:52 AM, Mark Wieder wrote:
All good ones. One of the problems with RAD tools is that they make
the task of prototyping a bit too easy. I find myself whipping up a
prototype as a proof of concept and then start building an app from
there without having thoroughly thought
Mark,
...If you think comments in natural language are useless, try posting
a joke on a listserv without appending a smiley g...
comments are useful for human beings, but are computers supposed to joke ?
JB
___
use-revolution mailing list
I for one, curse on my comments like:
-- This think will never work...
or
-- The next 356 lines are here because we don't have damn threads!
which are not useful, but helps me relive some stress g
PS: I appended the smiley, this should work meta-g
On Sep 16, 2006, at 5:51 PM, Mark Wieder
On Sep 16, 2006, at 2:51 PM, Mark Wieder wrote:
If you really insist on taking this seriously, I'd much rather have
things the other way around. My comments usually describe my
intentions much better than my attempts at coding same.
Because my scripts tend to have small handlers. I often
Josh Mellicker wrote:
What do you think are the 3 (or 5 or 10) most common timewasters of
Rev programmers?
Don;'t know about 3 (or 5 or 10) most common, but I can tell you the
number one biggest timewaster for a Rev programmer.
1. This email list.
I can't tell you how much time I
Alex Tweedly wrote:
...I can tell you the number one biggest timewaster
for a Rev programmer.
1. This email list.
I can't tell you how much time I spend reading it, and getting
interested in other peoples' issues, problems, challenges, etc. when I
*should* be busy designing / coding /
Alex-
Friday, September 15, 2006, 6:45:10 AM, you wrote:
1. This email list.
rotfl
--
-Mark Wieder
[EMAIL PROTECTED]
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
Josh-
Thursday, September 14, 2006, 1:07:20 PM, you wrote:
Here are a few common ways I've learned to overcomplicate scripts and
slow down software development.
Josh no doubt learned these from me, so... flame suit on
1. overhandlerize
In the general case you're probably right, and I
Josh-
Thursday, September 14, 2006, 1:07:20 PM, you wrote:
If anyone else has common timewasters and app bloating techniques,
let's hear 'em!
The overuse of custom props when persistence isn't needed.
--
-Mark Wieder
[EMAIL PROTECTED]
___
On 9/15/06 11:54 AM, Mark Wieder [EMAIL PROTECTED] wrote:
If anyone else has common timewasters and app bloating techniques,
let's hear 'em!
Comments. Don't put in comment lines - they only slow down trying to
read the actual code. Code, especially xtalk, should be readable by
itself. If
Mark ,
Comments. Don't put in comment lines - they only slow down trying to
read the actual code. Code, especially xtalk, should be readable by
itself. If your code needs comments then it isn't well written.
I don't fully agree with that... I usually don't add any comments to my
scripts
Ken Ray wrote:
On 9/15/06 11:54 AM, Mark Wieder [EMAIL PROTECTED] wrote:
If anyone else has common timewasters and app bloating techniques,
let's hear 'em!
Comments. Don't put in comment lines - they only slow down trying to
read the actual code. Code, especially xtalk, should be readable by
Mark-
Friday, September 15, 2006, 9:54:56 AM, you wrote:
Comments. Don't put in comment lines - they only slow down trying to
read the actual code. Code, especially xtalk, should be readable by
itself. If your code needs comments then it isn't well written.
Sheesh. I guess I shoulda put a
Josh-
Thursday, September 14, 2006, 1:07:20 PM, you wrote:
1. overhandlerize
Here's another point about overhandlerizing...
if you have a custom prop that you use often
set the uConfigParameterFifteen of this stack to yellow
and you want to retrive that custom prop later on to use it and
Mark Wieder wrote:
Sheesh. I guess I shoulda put a smiley in there.
Argh. I shoulda known. I really shoulda known.
--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
___
Actually I use comments in a fairly unique way. I pseudocode what I
want to do in comments, and then code around the comments so I can
keep track of where I am at and what I am trying to accomplish.
Removing comments later may make the code more readable, but for code
in progress I find I
On 9/15/06 1:52 PM, Mark Wieder [EMAIL PROTECTED] wrote:
Sheesh. I guess I shoulda put a smiley in there.
Yeah, that would've helped... ;-)
Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: [EMAIL PROTECTED]
___
On Sep 14, 2006, at 6:48 PM, Josh Mellicker wrote:
If you're aware of the fame and impact the 15 minute Ruby on Rails
demo (http://www.rubyonrails.org/screencasts) has had on web
developers, you know speed is as much, if not more, an issue as ever.
I'm not aware of that fame and impact.
Josh,
I'm with you on the overdoing the handler thing.
I've tried writing code where no handlers/functions are more than a
dozen lines long, and while it is an interesting excercise...it's a
real pain to debug, not to mention to go back and try and figure out
what the heck you meant to do 6
One of the great things about Revolution is the speed of development,
and how the language can lend itself to minimalist, simple, elegant
script structures and code. One line to do the work of many.
However, even the best fall prey to bad habits, some perhaps from
other dev environments,
Josh, you have a future making presentations! Very informative and
entertaining.
Best,
Jerry Daniels
Artists, Consultants Developers
http://www.daniels-mara.com/art
http://www.daniels-mara.com/services
http://www.daniels-mara.com
Skype: jerry.daniels
On Sep 14, 2006, at 3:07 PM, Josh
On Sep 14, 2006, at 2:07 PM, Josh Mellicker wrote:
1. overhandlerize
This is true, especially in cases such as your example where the
custom command simply reiterates the underlying language semantics.
However, in my experience, apps are made overcomplicated by, uh,
underhandlerizing
Jerry Daniels wrote:
On Sep 14, 2006, at 3:07 PM, Josh Mellicker wrote:
One of the great things about Revolution is the speed of
development, and how the language can lend itself to minimalist,
simple, elegant script structures and code. One line to do the work
of many.
However, even the
I know. I've seen Josh's site and stuff.
I was just teeing the ball up for ya, Richard.
Best,
Jerry Daniels
Tool makers for the 21st century
http://www.daniels-mara.com
Voice: 512.879.6286
Skype: jerry.daniels
On Sep 14, 2006, at 7:07 PM, Richard Gaskin wrote:
Jerry Daniels wrote:
Hi Dar,
On Sep 14, 2006, at 4:13 PM, Dar Scott wrote:
I can't tell if you are being ironic or are serious.
Can't tell meeself sometimes! ;-)
I was serious though, that at least in some apps I'm working on,
these techniques slowed development down with little or no upside.
I'm sure that
53 matches
Mail list logo
