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
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 artic
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 ou
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 wa
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 s
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
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.
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 pro
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 plannin
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 resulte
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 fast
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
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
rat
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 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
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
___
use-revo
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]
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
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
...Not appropriate for this list, buy remind me sometime and I'll tell
you a story along this line...
--
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 com
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
PS: I appended the smiley, this should work
On Sep 16, 2006, at 5:51 PM, Mark Wieder wrote:
Mark,
>
> ...If you think comments in natural language are useless, try posting
> a joke on a listserv without appending a smiley ...
comments are useful for human beings, but are computers supposed to joke ?
JB
___
use-revolution mailing list
use-r
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 out
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
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
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
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. langua
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
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 mont
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. 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]
___
use-
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
___
use-re
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 a
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
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
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
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
> 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]
___
use-r
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.
> 1. overhandlerize
In the general case you're probably right, and I wouldn't do this
every time I used a custom prop. But rev d
Alex-
Friday, September 15, 2006, 6:45:10 AM, you wrote:
> 1. This email list.
--
-Mark Wieder
[EMAIL PROTECTED]
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subs
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 / typ
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 spe
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 "
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:
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.
>>
>> Howe
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"
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 Mel
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, th
48 matches
Mail list logo