advantages of forth over other languages
Andreas Klimas
probably my statements are obvious to the most of you. but
after a long time of struggle with different languages it
seems that forth is most best suited for my needs.
I have a couple of years (20+) experience in software
development with Smalltalk, C, C++, Java and a little Lisp.
I never have been working with embedded stuff.
I'm working in the area of Bank, Insurance, Chemistry and others.
there always have been things which disturbing me.
*) I want to execute functions on compiletime, C preprocessor
is a shame, by far too less powerfull. so I wrote C
codegenerator (and even Smalltalk Code generator)
which also was not that perfect. Makefile has become more
complex then.
*) statically typing is more a problem than help. I think
it's more a feature to support optimizing code generation.
in forth you are free to use a number as integer, pointer
or what ever. no more casting - yep.
*) syntax of C is complex with all that funny rules that
one has to know. (priority of operators, left to right
or right to left - or implementation dependent).
Forth does not have any syntax.
*) not even gcc does have anonymous functions. no problem for
Forth. I can switch from compile to interpret on the
fly - which language support this.
*) I can't simply work with anonymous arguments and dispatch
those to other anonymous functions. a mechanismus like printf's
formatstring is needed to collect stackdata with va_arg.
(expect with Smalltalk and Lisp, of course)
to have an explict datastack like Forth is quite exciting
*) I can't (simply) compile code at runtime. Smalltalk vendors
even strip out the compiler while building the deployment.
*) GarbageCollection is not needed. I even gave up (since 4
years now) using malloc/free to implement the needed data
structures. there are always other/simpler ways.
*) to inspect my running code it must be compiled, linked, started
in an debugger environment. setting breakpoints and starting
the application. singlestep to the place in question (not
debugging, simply showing if it does what I expect) and
might see a wrong thing. okay, leave debugger, start editor
change text - compile, link ... and so on.
to have an interactive language like Forth where I could
check things quickly is the most striking feature, for me.
interactivity in Forth is even better than in Smalltalk.
there are many more small deficiencies which of corse are manageable,
but I'm no longer willing to buy that.
Forth does solve all those problems. one would expect that
such a great tool have to have some megs in size, but it's
the smallest one anyway.
as with every unfamiliar paradigma, practice is needed to grasp
the advantages. it's better not to use the old habits.
one must be willing to master all those _different_ concepts.
well, what I'm doing anyway. most of my work is writing web
applications for many customers in the Unix environment.
I started 20 years ago with C, then C++ then came Smalltalk then
Java, then back to C and now (2 years) with Forth (C as Backend).
hope this text will help some people to decicde to give forth
a shot.
best wishes
Andreas Klimas
Celime
"Andreas Klimas" <kli...@k-r.de> a écrit dans le message de news:
Q4BMi.684$zh6...@fe10.news.easynews.com...
> hi,
>
> probably my statements are obvious to the most of you. but
> after a long time of struggle with different languages it
> seems that forth is most best suited for my needs.
Todays programmings languages are so distant from Forth that it appears
impossible to me to explain the advantages of Forth to the young
programmers.
One becomes old!
John Passaniti
> Todays programmings languages are so distant from Forth that it appears
> impossible to me to explain the advantages of Forth to the young
> programmers.
So much of the discussion in comp.lang.forth is about Forth's
advantages, but I rarely see anyone talking about Forth's disadvantages.
Could it be the "young programmers" you are talking to fully grok
Forth's advantages, but they may see disadvantages that you don't?
Could it also be that you're assuming that advantages in one domain
equates to advantages in another? Forth is a great language for
embedded systems. That doesn't mean that Forth is necessarily a great
language for web-based applications.
Another question: Many times in comp.lang.forth we see Forth compared
to "other languages." But in reality, there is rarely a comparison to
"other languages." Usually the comparison is with C, ignoring the much
larger universe of languages out there. And certainly, when comparing
Forth and C, there are a number of advantages. But when you start
looking outside C, some of the features that were traditionally seen as
unique in Forth are actually common.
Jason Damisch
Oh, it's Pissanti again.
FLAME-SUIT DON FLAMETHROWER ARM FLAMETHROWER AIM
> Celime wrote:
> > Todays programmings languages are so distant from Forth that it appears
> > impossible to me to explain the advantages of Forth to the young
> > programmers.
>
> So much of the discussion in comp.lang.forth is about Forth's
> advantages, but I rarely see anyone talking about Forth's disadvantages.
Forth has no disadvantages that I see except for the fact that the
people in power have damned it to hell. It provides too much freedom
and they hate freedom.
> Could it be the "young programmers" you are talking to fully grok
> Forth's advantages, but they may see disadvantages that you don't?
No, it's just that the establishment has become so good at programming
the youth that youth can never see past the directives of the empire.
Double Plus Good. ++
> Could it also be that you're assuming that advantages in one domain
> equates to advantages in another? Forth is a great language for
> embedded systems. That doesn't mean that Forth is necessarily a great
> language for web-based applications.
Forth is a multipurpose language like C, it can and should be used for
everything.
> Another question: Many times in comp.lang.forth we see Forth compared
> to "other languages." But in reality, there is rarely a comparison to
> "other languages." Usually the comparison is with C, ignoring the much
> larger universe of languages out there. And certainly, when comparing
> Forth and C, there are a number of advantages. But when you start
> looking outside C, some of the features that were traditionally seen as
> unique in Forth are actually common.
There is really in my mind only two langauges, Forth and Algol.
If you want to be a gaming pagan about it, Forth is Chaotic Good, and
all other languages are Lawful Evil.
Jason
hel...@gmail.com
> Celime wrote:
> > Todays programmings languages are so distant from Forth that it appears
> > impossible to me to explain the advantages of Forth to the young
> > programmers.
>
> So much of the discussion in comp.lang.forth is about Forth's
> advantages, but I rarely see anyone talking about Forth's disadvantages.
> Could it be the "young programmers" you are talking to fully grok
> Forth's advantages, but they may see disadvantages that you don't?
Many of the seen disadvantages are the advantages someone else sees.
> Could it also be that you're assuming that advantages in one domain
> equates to advantages in another? Forth is a great language for
> embedded systems. That doesn't mean that Forth is necessarily a great
> language for web-based applications.
I seriously think that Forth needs to go away from that "only good for
embedded applications" image. Also in embedded world memory and
processor power gets cheaper and cheaper and the need for a small i.e.
Forth decreases with every month.
> Another question: Many times in comp.lang.forth we see Forth compared
> to "other languages." But in reality, there is rarely a comparison to
> "other languages." Usually the comparison is with C, ignoring the much
> larger universe of languages out there. And certainly, when comparing
> Forth and C, there are a number of advantages. But when you start
> looking outside C, some of the features that were traditionally seen as
> unique in Forth are actually common.
But how common are these languages? And I fear you mean the "C" up to
C# or even Perl and such ;)
-Helmar
John Passaniti
> On Oct 3, 10:35 am, John Passaniti <n...@JapanIsShinto.com> wrote:
>
> Oh, it's Pissanti again.
Wow, that's incredibly clever. Last I heard that was when I was 10.
> Forth has no disadvantages that I see except for the fact that the
> people in power have damned it to hell. It provides too much freedom
> and they hate freedom.
Wow, conspiracy theories. How compelling.
> No, it's just that the establishment has become so good at programming
> the youth that youth can never see past the directives of the empire.
> Double Plus Good. ++
Wow, 1984 references. Works well with the conspiracy theories.
> Forth is a multipurpose language like C, it can and should be used for
> everything.
Good luck with that.
> There is really in my mind only two langauges, Forth and Algol.
You sure you want to expose your lack of experience and apparent lack of
depth in programming languages in such an obvious and brazen way?
> If you want to be a gaming pagan about it, Forth is Chaotic Good, and
> all other languages are Lawful Evil.
I have no idea what that means, but since your comments in reply are so
weak, I'll assume it's just more typing practice for you. When you
actually have something to say on the subject, I'd love to hear it.
John Doty
I don't think I agree. Programming in Mathematica has much the same
"feel" as programming in Forth. You produce comprehensible code by
composition of functions ("factors") rather than by procedural
narrative. The syntax differences are superficial, I think. The
semantics of the underlying engine are profoundly different, but that
represents the difference in the application domains of the languages.
>
> One becomes old!
>
>
There we agree!
--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
Specialization is for robots.
John Passaniti
> Many of the seen disadvantages are the advantages someone else sees.
Sure. But that doesn't make it any less of a disadvantage to the person
evaluating it. My point is simply that you can't approach comparing
languages in terms of absolutes. When a Forther proudly declares that
with Forth you can have direct access to the hardware, that's a clear
advantage for embedded systems programming, but is little advantage to
someone doing (for example) web-applications. That's a singular example.
> I seriously think that Forth needs to go away from that "only good for
> embedded applications" image. Also in embedded world memory and
> processor power gets cheaper and cheaper and the need for a small i.e.
> Forth decreases with every month.
Forth gets away from the "only good for embedded applications" when
there is demonstrated evidence to the contrary. Don't tell me that
Forth can compete favorably in those other domains-- show me the
applications. What most people in comp.lang.forth seem to be doing is
to say, "Forth works well for me in my embedded systems work, so clearly
it must scale well and be competitive in other domains." Prove it.
> But how common are these languages?
Depends on the problem domain, doesn't it? Take one problem domain--
web applications-- and you'll find that C is a minority language there.
Most anything serious in that problem domain is based on a scripting
language (or if you believe Sun, Java).
> And I fear you mean the "C" up to
> C# or even Perl and such ;)
Three of the most common features of Forth that people point to when
comparing against C is interactivity, extensibility, and the ability to
do run-time evaluation. And yes, when you compare against C, that's
true. But most scripting languages give you all that and more. And
beyond the world of scripting, we have languages like Smalltalk and Lisp
(and the family of languages that come from them) that either pre-date
or were concurrent with Forth that provide the same features.
My point is that for people who are limited by Forth and C, the
advantages of Forth are clear. For those without such limits, the
advantages of Forth are less strong.
Marcel Hendrix
[ .. agreed with ..]
> *) to inspect my running code it must be compiled, linked, started
> in an debugger environment. setting breakpoints and starting
> the application. singlestep to the place in question (not
> debugging, simply showing if it does what I expect) and
> might see a wrong thing. okay, leave debugger, start editor
> change text - compile, link ... and so on.
> to have an interactive language like Forth where I could
> check things quickly is the most striking feature, for me.
> interactivity in Forth is even better than in Smalltalk.
I acknowledge this for my Linux environment (how I hate/dread gdb!),
but MS's Visual C++ environment under Windows is almost nice enough
to be useful. And some things I have to do to debug DLL's would be
nearly impossible with *only* Forth tools. OTOH, the Forth side of a
DLL interface problem is always lots and lots simpler than the C side.
I would say that the Visual studio toolset is at least as nice as
a good Forth compiler environment. However, once you have a difficult
compiler problem, in VC you may have absolutely no idea what is wrong
or how to fix it. Recent example: I found that with full optimization
the realft() function of Numerical Recipes in C gave the wrong results,
namely all NaN's (of course I tested from the Forth side :-)
Other NRC functions tested ok. Without optimization the code was
correct, but 3 times slower (for all the 200+ functions!). So how would
a newby know how to ferret out this problem, fix it, and retain speed
where it matters (it can't be done by just staring a wizzard, point
and click)? And do they teach young programmers nowadays how CPU's and
FPU's work, and what a phrase like "improve float constistency" might
mean? As a Forth person, you (have to) know all about the bits and
the bytes from day one...
> as with every unfamiliar paradigma, practice is needed to grasp
> the advantages. it's better not to use the old habits.
> one must be willing to master all those _different_ concepts.
I think this is a good one. Choose your weapons, and *really* learn
how to use them. Too many layers, and you may get stuck without
a clue how to make things work when something is not (yet) right
in the shiny bright machinery.
[..]
-marcel
hel...@gmail.com
> hel...@gmail.com wrote:
> > Many of the seen disadvantages are the advantages someone else sees.
>
> Sure. But that doesn't make it any less of a disadvantage to the person
> evaluating it. My point is simply that you can't approach comparing
> languages in terms of absolutes. When a Forther proudly declares that
> with Forth you can have direct access to the hardware, that's a clear
> advantage for embedded systems programming, but is little advantage to
> someone doing (for example) web-applications. That's a singular example.
Well, I do have applications far from "embedded" market. You can see
them. Send me a private mail and I dont have any problems to show you.
For some reasons I can not publish it freely (even I want it!), since
it uses databases that are not in public now.
> > I seriously think that Forth needs to go away from that "only good for
> > embedded applications" image. Also in embedded world memory and
> > processor power gets cheaper and cheaper and the need for a small i.e.
> > Forth decreases with every month.
>
> Forth gets away from the "only good for embedded applications" when
> there is demonstrated evidence to the contrary. Don't tell me that
> Forth can compete favorably in those other domains-- show me the
> applications. What most people in comp.lang.forth seem to be doing is
> to say, "Forth works well for me in my embedded systems work, so clearly
> it must scale well and be competitive in other domains." Prove it.
I'd have no problem. I use Forth for language research - mainly
ancient egyptian. One of the problems is that of course most people
can not estimate how interesting the software really is since they
dont do research in ancient egyptian language...
> > But how common are these languages?
>
> Depends on the problem domain, doesn't it? Take one problem domain--
> web applications-- and you'll find that C is a minority language there.
> Most anything serious in that problem domain is based on a scripting
> language (or if you believe Sun, Java).
Well the problem with Forth seems more that it is too unknown. More
publically available information, free of fee, systems free of fee are
needed. Most implementors follow their own problem domain. That's also
what I do (while I try to cover as much problem domains as possible or
at least that make sense for me). Gforth unfortunately is not really
the solution imho. There is the difference between say gcc and gforth
that your application does not run without the GPL-covered system...
> > And I fear you mean the "C" up to
>
> > C# or even Perl and such ;)
>
> Three of the most common features of Forth that people point to when
> comparing against C is interactivity, extensibility, and the ability to
> do run-time evaluation. And yes, when you compare against C, that's
> true. But most scripting languages give you all that and more. And
> beyond the world of scripting, we have languages like Smalltalk and Lisp
> (and the family of languages that come from them) that either pre-date
> or were concurrent with Forth that provide the same features.
>
> My point is that for people who are limited by Forth and C, the
> advantages of Forth are clear. For those without such limits, the
> advantages of Forth are less strong.
Oh, Forth has also very strange disadvantages. No matter that also a
small HTTP-server is possible with gforth, I still prefer to use Perl
for simple "text tasks". As I prefer Tcl/Tk for quickly writing a
graphical interface (also interfacing Forth-programs) ( - that's a
reference to a recent post on this list I'm thinking about how to
answer...).
Forth is good if you have to make your own domain specific language.
If for your problem domain there is a language out there, dont use
Forth if you dont have good reasons...
-Helmar
hel...@gmail.com
Andreas Klimas
> Celime wrote:
>> Todays programmings languages are so distant from Forth that it appears
>> impossible to me to explain the advantages of Forth to the young
>> programmers.
>
> So much of the discussion in comp.lang.forth is about Forth's
> advantages, but I rarely see anyone talking about Forth's disadvantages.
> Could it be the "young programmers" you are talking to fully grok
> Forth's advantages, but they may see disadvantages that you don't?
adavantage or disadvantage is only in the eye of the beholder.
one migh argue that the most important feature is to have a
garbage collecter. I was one of them. but GC is not a general
solution. because now you have to manage carefully your references
otherwise all objects hold on one. and it could be extreme
difficult to find this object. well, you might implement caching
for database object but you wouldn't that those object would
in memory all the time. such requirement are the reason why weak
references were introduced - you see.
so I decided to not make garbage in the first place.
> Could it also be that you're assuming that advantages in one domain
> equates to advantages in another? Forth is a great language for
> embedded systems. That doesn't mean that Forth is necessarily a great
> language for web-based applications.
Forth is a language or better a concept to express the solution
to any given problem. it's free in all directions, so I didn't see
why other languages (say PHP, Perl, Jave) should be better. one have
to master this freedom - this is probably one of the worst disadvantages
of forth. in order to write successful programs in Forth one have
to switch on his brain.
> Another question: Many times in comp.lang.forth we see Forth compared
> to "other languages." But in reality, there is rarely a comparison to
> "other languages." Usually the comparison is with C,
I gave examples to Smalltalk and Java, where I have worked successfully
for many years.
> ignoring the much
> larger universe of languages out there. And certainly, when comparing
> Forth and C, there are a number of advantages. But when you start
> looking outside C, some of the features that were traditionally seen as
> unique in Forth are actually common.
don't forget to compare the price for those features compared to
other languages. how expensive is lexical scoping in lisp, compared to
forth, where you simply use the stack.
I don't see your problem. you are lucky, you know about forth. you
know how to work with and you probably know about other languages
as well. take this experience to write better and simpler programs
in any language you must use and bring more comfort to your
development system. I for me did it.
best wishes
Andreas Klimas
Andreas Klimas
I disagree. if your business is textprocessing you build your
best suited vocabulary for that. is not much work in Forth
to do so, and than you have it - forever.
> Forth is good if you have to make your own domain specific language.
> If for your problem domain there is a language out there, dont use
> Forth if you dont have good reasons...
again, if GUI Scripting is what you need, build your 'domain specific
language'. I did it for web development. first for Smalltalk, than
for Java then for C and now for Forth. is the smallest and best
implementation I did. far better and simpler than JSP or PHP.
but, you must do it yourself.
>
> -Helmar
>
best wishes
Andreas Klimas
sl...@jedit.org
> adavantage or disadvantage is only in the eye of the beholder.
> one migh argue that the most important feature is to have a
> garbage collecter. I was one of them. but GC is not a general
> solution. because now you have to manage carefully your references
> otherwise all objects hold on one. and it could be extreme
> difficult to find this object. well, you might implement caching
> for database object but you wouldn't that those object would
> in memory all the time. such requirement are the reason why weak
> references were introduced - you see.
I don't see how any of this is connected with having a GC. Whether you
have GC or not, you still have to think carefully about object
lifecycle, and who references who. The difference is that GC
eliminates boilerplate code.
> Forth is a language or better a concept to express the solution
> to any given problem. it's free in all directions, so I didn't see
> why other languages (say PHP, Perl, Jave) should be better. one have
> to master this freedom - this is probably one of the worst disadvantages
> of forth. in order to write successful programs in Forth one have
> to switch on his brain.
Can you point me at some web frameworks and web applications written
in Forth which are used in production?
> don't forget to compare the price for those features compared to
> other languages. how expensive is lexical scoping in lisp, compared to
> forth, where you simply use the stack.
Both Lisp and Forth implementations can achieve very good performance
close to that of C. Many techniques exist to optimize lexical scope
and closures -- there has been extensive research on this topic since
the 70's.
Slava
sl...@jedit.org
> I disagree. if your business is textprocessing you build your
> best suited vocabulary for that. is not much work in Forth
> to do so, and than you have it - forever.
> again, if GUI Scripting is what you need, build your 'domain specific
> language'. I did it for web development. first for Smalltalk, than
> for Java then for C and now for Forth. is the smallest and best
> implementation I did. far better and simpler than JSP or PHP.
> but, you must do it yourself.
How come there are no free, well-debugged, well-documented libraries
for Forth which perform the tasks you describe, such as text
processing, web application development, GUIs, etc? If it's so easy,
why do some people in this very newsgroup admit to using Perl for text
processing, Tcl/Tk for GUIs, and so on?
Slava
Andreas Klimas
I'm looking in what people do or have done, ask questions, learn the
business, take those things and ideas and implement the stuff I need
by myself. so I would become better and better. this practice is not
unique to Forth.
I don't know why people in this newsgroup admiting Perl and Tcl but
they probably will have their reasons.
best wishes
Andreas Klimas
Andreas Klimas
> On Oct 3, 7:41 pm, Andreas Klimas <kli...@k-r.de> wrote:
>> adavantage or disadvantage is only in the eye of the beholder.
>> one migh argue that the most important feature is to have a
>> garbage collecter. I was one of them. but GC is not a general
>> solution. because now you have to manage carefully your references
>> otherwise all objects hold on one. and it could be extreme
>> difficult to find this object. well, you might implement caching
>> for database object but you wouldn't that those object would
>> in memory all the time. such requirement are the reason why weak
>> references were introduced - you see.
>
> I don't see how any of this is connected with having a GC. Whether you
> have GC or not, you still have to think carefully about object
> lifecycle, and who references who.
it's near impossible if you are using foreign frameworks to
predict where references of your objects were keept. we had
a couple of troubles with some Smalltalk peristent frameworks.
Java isn't better.
> The difference is that GC
> eliminates boilerplate code.
IMHO: no
>
> Can you point me at some web frameworks and web applications written
> in Forth which are used in production?
content management system.
www.cmslight.eu, it's german.
there are other applications as well, but it's pointless without
login and password.
might I should write a tutorial and post it to this
newsgroup.
>
>> don't forget to compare the price for those features compared to
>> other languages. how expensive is lexical scoping in lisp, compared to
>> forth, where you simply use the stack.
>
> Both Lisp and Forth implementations can achieve very good performance
> close to that of C. Many techniques exist to optimize lexical scope
> and closures -- there has been extensive research on this topic since
> the 70's.
I counted 250000 LOC in src directory.
best wishes
Andreas Klimas
Andreas Klimas
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
sorry, I missed to say CLISP
John Doty
> Celime wrote:
>> Todays programmings languages are so distant from Forth that it appears
>> impossible to me to explain the advantages of Forth to the young
>> programmers.
>
> So much of the discussion in comp.lang.forth is about Forth's
> advantages, but I rarely see anyone talking about Forth's disadvantages.
I'll have to post more often ;-)
> Could it be the "young programmers" you are talking to fully grok
> Forth's advantages, but they may see disadvantages that you don't?
Was Forth ever widely understood by programmers? Most Forthers I've
actually known have been scientists or engineers.
Stephen Pelc
>How come there are no free, well-debugged, well-documented libraries
>for Forth which perform the tasks you describe, such as text
>processing, web application development, GUIs, etc? If it's so easy,
>why do some people in this very newsgroup admit to using Perl for text
>processing, Tcl/Tk for GUIs, and so on?
Because they cost money to develop, debug and document.
Many of the libraries you want actually exist. The're just not free of
cost.
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
John Doty
> On Wed, 03 Oct 2007 16:54:14 -0700, "sl...@jedit.org"
> <sl...@jedit.org> wrote:
>
>> How come there are no free, well-debugged, well-documented libraries
>> for Forth which perform the tasks you describe, such as text
>> processing, web application development, GUIs, etc? If it's so easy,
>> why do some people in this very newsgroup admit to using Perl for text
>> processing, Tcl/Tk for GUIs, and so on?
>
> Because they cost money to develop, debug and document.
>
> Many of the libraries you want actually exist. The're just not free of
> cost.
But other languages have communities that distribute such libraries for
free. Some of this stuff is *really* good. These communities find
various ways to fund the work. Your model isn't the only one that works.
That Forth lacks this is a severe weakness.
John Doty
> Three of the most common features of Forth that people point to when
> comparing against C is interactivity,
Very important in the past. But these days the *systems* are interactive
and I can get around the edit/build/test loop in a few seconds even with
a compile/link language. Faster than I can think ;-)
> extensibility,
But if you value straightforward code (as scientists and engineers
generally do), extensibility is also an invitation to obfuscation. It's
only a positive feature when used with great discipline.
> and the ability to
> do run-time evaluation.
I assume you mean compile-time: I know of few languages that prevent
run-time evaluation!
But here, C folks again use the *systems* that support C: generate C
code with a script or another C program during the build. You can have
whatever build-time computation you want that way.
> My point is that for people who are limited by Forth and C, the
> advantages of Forth are clear.
Are they? It seems to me that the Forthers of the 70's mostly turned to
C in the 80's.
To me, the big advantage of Forth is the way it facilitates breaking
down the code into easily understood and tested factors. But Standard
Forth doesn't do this as well as it could. Locals and nested control
structures inhibit factoring in Standard Forth, as they also do in C.
Bernd Paysan
> Because they cost money to develop, debug and document.
>
> Many of the libraries you want actually exist. The're just not free of
> cost.
Or they are not well-enough documented (like MINOS, which is free software).
I don't think MINOS needs so much documentation, since those people who
actually had a look got on quite well with Theseus and without large amount
of documentation. There are 13 pages in the English documentation of
bigFORTH, and they explain the basics of this framework.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Marcel Hendrix
> How come there are no free, well-debugged, well-documented libraries
> for Forth which perform the tasks you describe, such as text
> processing, web application development, GUIs, etc?
Wait a minute, free AND well-debugged AND well-documented?
What do these buzz words like "free" and "well" mean exactly?
Take for instance the Bessel functions of 0 and 1st kind, for any
complex argument < 5. How many implementations of these Forth words
do you think there are available?
What kind of (e.g.) text processing were you thinking off? What I
have invariably found is that only very few of these words actually
get used. (In my case PLACE PLACE+ $+ Split-At-Char, Split-At-Word.)
> If it's so easy,
> why do some people in this very newsgroup admit to using Perl for text
> processing, Tcl/Tk for GUIs, and so on?
Well, speaking for myself, if it is relatively unimportant, I use
what is available (e.g. runtime link to a standard package). If the tool
breaks, try something else. And when that fails, grit your teeth and write
it in Forth. (Which means it will be free, debugged-for-a-single-purpose
and undocumented).
And when it *is* important, it will be free, debugged-for-a-single-purpose
and documented for a domain expert. (And most probably, so tightly integrated
with the Forth system itself that it would be a dreadful job to unhook it.)
How would we, e.g., get a Forth GUI toolkit that fits your description?
Evidently Bernd Paysan wrote Minos, which is free, debugged-for-his-purposes,
and documented for domain & bigForth experts. To debug that further, we'd
need (1) lots of Forth programmers that want to use a GUI but (2) haven't
got a clue how to write one and (3) without strong preferences how it should
work. To document it, we'd need people that like Forth, can write, can't debug
their way out of a wet paper bag but have a strong desire to do something
useful. Raise hands everybody, who feels they are in these categories :-)
-marcel
John Passaniti
> Was Forth ever widely understood by programmers? Most Forthers I've
> actually known have been scientists or engineers.
That old theme again. You must come from that generation where people
were specialists and stayed in their narrowly-defined roles for their
entire career. I'm glad I don't, and I'm glad the vast majority of the
people I work with don't. Maybe in your industry people are strictly
defined by "programmer" and "scientist" and "engineer." But most people
I know are hyphenated-- they may primarily be a scientist, but they also
have strong programming skills. Or they might be an electrical
engineer, but also be conversant in the world of programming. I started
the other way, starting off as a programmer and moving more towards
electrical engineering.
But this is nothing new-- we've talked about this before, and I've been
deeply thankful that the kind of regimented professional roles you seem
to observe in your work don't apply universally.
Regarding knowing Forth, it may be a geographic thing, but here in
Rochester, New York, it's hard to talk to a local experienced programmer
who doesn't know about Forth. They may not be actively using it
professionally, but they know Forth.
I also have seen programmers who know Forth without... knowing Forth.
Most of the recent graduates may not know the syntax, common idioms, and
best practices of Forth, but they certainly understand the components
that make up Forth, understand how it works, and can appreciate the
essential qualities of it. This comes out in various ways; I see it
most often in job interviews.
My company currently has a position open and I usually conduct technical
interviews for software engineers. One of the questions I often ask
during such interviews is what languages the candidate knows. The point
of the question is to determine the breadth of the candidate. If for
example they answer "C, Pascal, BASIC" then I know they are probably
only conversant in imperative, procedural ALGOL-esque languages. If
they answer "C, Lisp, Smalltalk, Haskell, Java, Prolog" that says
something completely different. And if they toss in VHDL or Verilog in
there, it at least suggests even more. Further questions then might go
into how deeply they know these languages.
The candidate I interviewed had a good grasp of both procedural and
functional languages, and so I asked if he knew Forth. He stated he
didn't, but was interested. So I gave a brief overview and then turned
it around-- I asked him to describe the essential qualities of Forth
based on what I just described. He got the major themes: imperative,
procedural, deals with raw addresses so probably low abstraction levels,
dictionary and interpreter means interactive and extensible, untyped,
and so on.
Obviously, this doesn't mean he could sit down and start writing Forth
code. But it does mean that if properly introduced, he wouldn't have a
problem picking it up and eventually being proficient in it.
John Doty
> John Doty wrote:
>> Was Forth ever widely understood by programmers? Most Forthers I've
>> actually known have been scientists or engineers.
>
> That old theme again. You must come from that generation where people
> were specialists and stayed in their narrowly-defined roles for their
> entire career. I'm glad I don't, and I'm glad the vast majority of the
> people I work with don't. Maybe in your industry people are strictly
> defined by "programmer" and "scientist" and "engineer." But most people
> I know are hyphenated-- they may primarily be a scientist, but they also
> have strong programming skills. Or they might be an electrical
> engineer, but also be conversant in the world of programming. I started
> the other way, starting off as a programmer and moving more towards
> electrical engineering.
Most programmers I've known just do programming. But lots of others do
programming.
>
> But this is nothing new-- we've talked about this before, and I've been
> deeply thankful that the kind of regimented professional roles you seem
> to observe in your work don't apply universally.
You misunderstand what I'm trying to say. To me, a "programmer" is a
narrow specialist by choice. It's like being a writer. But lots of
people write without being "writers", and lots of people program without
being "programmers". Forth was once the language for those.
>
> Regarding knowing Forth, it may be a geographic thing, but here in
> Rochester, New York, it's hard to talk to a local experienced programmer
> who doesn't know about Forth. They may not be actively using it
> professionally, but they know Forth.
>
> I also have seen programmers who know Forth without... knowing Forth.
> Most of the recent graduates may not know the syntax, common idioms, and
> best practices of Forth, but they certainly understand the components
> that make up Forth, understand how it works, and can appreciate the
> essential qualities of it. This comes out in various ways; I see it
> most often in job interviews.
Yes, I understand how that can be. I've commented before here that
Mathematica programming has much in common with Forth programming. And
long ago someone at MIT surprised me by claiming that Forth is similar
to Lisp. But if you look from the right angle...
>
> My company currently has a position open and I usually conduct technical
> interviews for software engineers. One of the questions I often ask
> during such interviews is what languages the candidate knows. The point
> of the question is to determine the breadth of the candidate. If for
> example they answer "C, Pascal, BASIC" then I know they are probably
> only conversant in imperative, procedural ALGOL-esque languages. If
> they answer "C, Lisp, Smalltalk, Haskell, Java, Prolog" that says
> something completely different. And if they toss in VHDL or Verilog in
> there, it at least suggests even more. Further questions then might go
> into how deeply they know these languages.
>
> The candidate I interviewed had a good grasp of both procedural and
> functional languages, and so I asked if he knew Forth. He stated he
> didn't, but was interested. So I gave a brief overview and then turned
> it around-- I asked him to describe the essential qualities of Forth
> based on what I just described. He got the major themes: imperative,
> procedural, deals with raw addresses so probably low abstraction levels,
> dictionary and interpreter means interactive and extensible, untyped,
> and so on.
Pretty good. When I was at MIT I found it very difficult to find
professionals of that quality to hire: the salary structure wasn't
adequate, I think. Did you hire him?
>
> Obviously, this doesn't mean he could sit down and start writing Forth
> code. But it does mean that if properly introduced, he wouldn't have a
> problem picking it up and eventually being proficient in it.
John Passaniti
> Because they cost money to develop, debug and document.
>
> Many of the libraries you want actually exist. The're just not free of
> cost.
No software-- not even open source software-- is free of cost. The
question is how are those costs recovered. Increasingly, other
companies are finding they can release their software as open source,
and make money not from the software itself, but the support and
consulting services they provide.
Educate me and explain why this wouldn't work for MPE. And if Elizabeth
is reading this, I'd appreciate the same answer for Forth, Inc. That
is, what would be the downside of releasing your software for free,
bootstrapping the community, and ultimately leading to what would be
increased sales of support and consulting services? Note that I'm not
saying to run the clock backward and pretend you are just now starting
your respective companies. The year is 2007, and you've both got a
solid history behind you and resources you likely didn't have when you
started.
Elizabeth D Rather
That business model works for software that *needs* support. Most of
our customers are self-sufficient; occasionally we get questions from
brand new customers, but rarely. We have email groups, which get
occasional questions, but they are usually answered by other customers
who have encountered similar needs or situations.
We do derive significant revenue from custom software development, but
as we study where these opportunities arise (which we have done), they
relate more to companies with specific development needs which we can
meet, and we don't see how releasing the software for free would
increase that workflow (which is already running near our capacity).
Our software product sales cover our development costs; without them,
we'd have trouble justifying taking time away from work that brings in
hourly revenue to do product development.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Elizabeth D Rather
> John Passaniti wrote:
>> John Doty wrote:
>>> Was Forth ever widely understood by programmers? Most Forthers I've
>>> actually known have been scientists or engineers.
>>
>> That old theme again. You must come from that generation where people
>> were specialists and stayed in their narrowly-defined roles for their
>> entire career. I'm glad I don't, and I'm glad the vast majority of
>> the people I work with don't. Maybe in your industry people are
>> strictly defined by "programmer" and "scientist" and "engineer." But
>> most people I know are hyphenated-- they may primarily be a scientist,
>> but they also have strong programming skills. Or they might be an
>> electrical engineer, but also be conversant in the world of
>> programming. I started the other way, starting off as a programmer
>> and moving more towards electrical engineering.
>
> Most programmers I've known just do programming. But lots of others do
> programming.
>
>> But this is nothing new-- we've talked about this before, and I've
>> been deeply thankful that the kind of regimented professional roles
>> you seem to observe in your work don't apply universally.
>
> You misunderstand what I'm trying to say. To me, a "programmer" is a
> narrow specialist by choice. It's like being a writer. But lots of
> people write without being "writers", and lots of people program without
> being "programmers". Forth was once the language for those.
I believe you use the term "programmer" rather differently from the way
John and I and most others here do. Certainly my experience is the same
as John's: most of our customers (and, indeed, our staff as well) are
people with significant expertise in other fields (typically various
fields of science and engineering, including related skills such as
design of electronic components) who also do a lot of programming. In
fact, I don't know *any* programmers who are narrow specialists or write
software without understanding the application domain in which it will
be used.
John Doty
I've known programmers who *thought* they had the domain knowledge
necessary, but didn't, and refused to do the studying necessary to
really obtain it. And a Forth-only programmer is surely an *extremely*
narrow specialist.
Elizabeth D Rather
> Elizabeth D Rather wrote:
>> John Doty wrote:
>>> John Passaniti wrote:
>>> You misunderstand what I'm trying to say. To me, a "programmer" is a
>>> narrow specialist by choice. It's like being a writer. But lots of
>>> people write without being "writers", and lots of people program
>>> without being "programmers". Forth was once the language for those.
>>
>> I believe you use the term "programmer" rather differently from the
>> way John and I and most others here do. Certainly my experience is
>> the same as John's: most of our customers (and, indeed, our staff as
>> well) are people with significant expertise in other fields (typically
>> various fields of science and engineering, including related skills
>> such as design of electronic components) who also do a lot of
>> programming. In fact, I don't know *any* programmers who are narrow
>> specialists or write software without understanding the application
>> domain in which it will be used.
>
> I've known programmers who *thought* they had the domain knowledge
> necessary, but didn't, and refused to do the studying necessary to
> really obtain it. And a Forth-only programmer is surely an *extremely*
> narrow specialist.
Well, I won't attempt to remotely judge folks you've known if you'll
refrain from judging people you've never met, whom I have worked with
for years and have seen successfully design and implement both hardware
and software in a number of fields.
ken...@cix.compulink.co.uk
(John Passaniti) wrote:
> Could it be the "young programmers" you are talking to fully grok
> Forth's advantages, but they may see disadvantages that you don't?
I don't know about the commercial systems but the free ones I have come
across can not really compete in terms of development systems. Compare
the IDE of Delphi with that of WinForth. It is possible to write a
simple database in Delphi without having to do any coding at all.
Personally I prefer Forth to Object Pascal as a language to program in
but for Windows apps at least Delphi is far easier to use as a
development tool.
Ken Young
Celime
"John Passaniti" <nn...@JapanIsShinto.com> a écrit dans le message de
news: JpQMi.18118$B25....@news01.roc.ny...
> Celime wrote:
>> Todays programmings languages are so distant from Forth that it
>> appears
>> impossible to me to explain the advantages of Forth to the young
>> programmers.
>
> So much of the discussion in comp.lang.forth is about Forth's
> advantages, but I rarely see anyone talking about Forth's
> don't?
>
I cannot say because there was no discussion: "...impossible to me to
explain
the advantages of Forth..."
> Could it also be that you're assuming that advantages in one domain
> equates to advantages in another? Forth is a great language for
> embedded systems. That doesn't mean that Forth is necessarily a great
> language for web-based applications.
>
Sure, but I wanted to speek about the advantages of Forth. (the good
side,
if you prefer).
> Another question: Many times in comp.lang.forth we see Forth compared
> to "other languages." But in reality, there is rarely a comparison to
> "other languages." Usually the comparison is with C, ignoring the
> much larger universe of languages out there. And certainly, when
> comparing Forth and C, there are a number of advantages. But when you
> start looking outside C, some of the features that were traditionally
> seen as unique in Forth are actually common.
>
I agree, some langage have Forth features and more. Or more but the
Forth features. It seems to me you like speek about generality.
>
Celime
"John Doty" <j...@whispertel.LoseTheH.net> a écrit dans le message de
news: 2sednRACw_e4QZ7a...@wispertel.com...
> Celime wrote:
>> "Andreas Klimas" <kli...@k-r.de> a écrit dans le message de news:
>> Q4BMi.684$zh6...@fe10.news.easynews.com...
>>> hi,
>>>
>>> probably my statements are obvious to the most of you. but
>>> after a long time of struggle with different languages it
>>> seems that forth is most best suited for my needs.
>>
>> Todays programmings languages are so distant from Forth that it
>> appears
>> impossible to me to explain the advantages of Forth to the young
>> programmers.
>
> "feel" as programming in Forth. You produce comprehensible code by
> composition of functions ("factors") rather than by procedural
> narrative. The syntax differences are superficial, I think. The
> semantics of the underlying engine are profoundly different, but that
> represents the difference in the application domains of the languages.
>
Mathematica is now old.
>>
>> One becomes old!
>
> There we agree!
>
Thank you,
Charles
Bernd Paysan
> I don't know about the commercial systems but the free ones I have come
> across can not really compete in terms of development systems. Compare
> the IDE of Delphi with that of WinForth. It is possible to write a
> simple database in Delphi without having to do any coding at all.
But you can do a more complex database program in Access without any coding
as well - if you are looking for an IDE where you don't have to code at
all, you shouldn't be looking for a programming language.
> Personally I prefer Forth to Object Pascal as a language to program in
> but for Windows apps at least Delphi is far easier to use as a
> development tool.
You might want to have a look at MINOS if you want to do GUIs in Forth.
Celime
<ken...@cix.compulink.co.uk> a écrit dans le message de news:
9YydnVDnrsvwhJva...@pipex.net...
Delphi IDE is not a programming langage in the common sense, it's an
IDE with one langage (Pascal). I don't see the point to compare two
so differents things.
I liked Pascal until I was tired to write "begin end begin end begin
end".
Charles
>
> Ken Young
>
John Doty
> (either another programming language or a thought given in mathematial or
> tehnical terms) into the needed programming language.
> It is said that a good intepreter needs to have a good knowledge in the
> language from he interpretes and an even better knowledge in the language
> into he interpretes.
That's my experience. I work a lot with the Japanese space program, and
often going back and reading the original documents is better than
working from the English translation, despite my poor command of
Japanese. But because I know the subject matter, I pick up things the
professional translators miss.
> This gives that you can't make a good program unless you have at least
> some understanding of the basic technology/mathematics of the algorithm.
More than just some: a lot.
> If you haven't the result will at best be as all these automaticly
> translated texts that you can find...
I was at community get-together a couple of days ago, and found myself
next to somebody who employs web designers. He complained that while
they are very good at making things look nice, they are clueless about
how ordinary people actually perceive navigation through the web. And
they don't know they're clueless, the vigorously deny it. Sounds
familiar to me...
ken...@cix.compulink.co.uk
cm17...@scarlet.be (Celime) wrote:
> Delphi IDE is not a programming langage in the common sense, it's an
> IDE with one langage (Pascal). I don't see the point to compare two
> so differents things.
Well that is not correct the same IDE was used for C#, however I am
comparing development environments as much as languages. At the moment
for RAD Delphi is better than Forth or for that matter than Visual
Studio. Forth has it's advantages but until the tools get as good as
mainstream commercial RAD ones it's appeal is limited.
Ken Young
ken...@cix.compulink.co.uk
(Bernd Paysan) wrote:
> But you can do a more complex database program in Access without any
> coding as well
Possibly but my experience of earlier Microsoft languages was not that
encouraging. I would probably end up using Paradox.
> You might want to have a look at MINOS if you want to do GUIs in
> Forth
Thanks for the tip.
Ken Young
Bernd Paysan
> In article <2lnht4-...@annette.mikron.de>, bernd....@gmx.de
> (Bernd Paysan) wrote:
>
>> But you can do a more complex database program in Access without any
>> coding as well
>
> Possibly but my experience of earlier Microsoft languages was not that
> encouraging. I would probably end up using Paradox.
I didn't want to suggest a particular product, just that if you want a
database without much real coding, there are specialized applications for
that. Access, Paradox, OpenOffice.org Base, or whatever.
znmeb
> There is really in my mind only two langauges, Forth and Algol.
Well ... actually ... you have the right number of languages ...
two ... and you have one of them right ... Forth. But the other
language isn't Algol, it's Scheme.
David Thompson
wrote:
<snip other points>
> *) syntax of C is complex with all that funny rules that
> one has to know. (priority of operators, left to right
> or right to left - or implementation dependent).
> Forth does not have any syntax.
>
I don't think C's syntax is that complex, although Forth's is
maximally simple. Operator 'precedence' in C -- a slight
oversimplification, since there isn't quite a linear order -- is
standard and I have never heard of any implementation varying it.
Could you be thinking of the fact that _other_ algolian languages like
Fortran COBOL PL/I Pascal Ada have somewhat different rules?
- formerly david.thompson1 || achar(64) || worldnet.att.net
Jean-François Michaud
So...... wholistically coherent and not entirely uninterresting. What
part of John's quoted text are you addressing again? :). He simply
stated what he perceived from his own experience. Why the pragmatic
rant?
Regards
Jean-Francois Michaud
John Passaniti
> So...... wholistically coherent and not entirely uninterresting. What
> part of John's quoted text are you addressing again? :). He simply
> stated what he perceived from his own experience. Why the pragmatic
> rant?
1. Intelligent quoting trims text to just what is necessary to know the
context of a reply. Stupid quoting makes no such effort and merely
quotes the entire message. If you want to know what else John wrote
that provoked my reply, you are invited to explore Google Groups or your
favorite newsgroup archive.
2. You are replying to a message that is nearly a month old and that
has had subsequent discussion. It is not my role to summarize the
discussion that occurred both prior and after the message you quoted.
3. Context doesn't end when the subject line changes. You'll note that
the first sentence of my message was "that old theme again" which should
suggest that I am not just replying to John's then-current message, but
to larger themes he has offered in past discussions. Even if you didn't
know what those themes are, you should have been able to deduce them
from my reply.
gavino
> hel...@gmail.com schrieb:
>
> > On Oct 3, 9:42 pm, John Passaniti <n...@JapanIsShinto.com> wrote:
> >> hel...@gmail.com wrote:
> > Oh, Forth has also very strange disadvantages. No matter that also a
> > small HTTP-server is possible with gforth, I still prefer to use Perl
> > for simple "text tasks". As I prefer Tcl/Tk for quickly writing a
> > graphical interface (also interfacing Forth-programs)
>
> I disagree. if your business is textprocessing you build your
> best suited vocabulary for that. is not much work in Forth
> to do so, and than you have it - forever.
>
> > Forth is good if you have to make your own domain specific language.
> > If for your problem domain there is a language out there, dont use
> > Forth if you dont have good reasons...
>
> again, if GUI Scripting is what you need, build your 'domain specific
> language'. I did it for web development. first for Smalltalk, than
> for Java then for C and now for Forth. is the smallest and best
> implementation I did. far better and simpler than JSP or PHP.
> but, you must do it yourself.
>
>
>
> > -Helmar
>
> best wishes
> Andreas Klimas
you like your web panguage better than jsp or php?
and it runs on forth?
gforth?
really awesome!!
Andreas Klimas
> John Passaniti wrote:
>
>> Three of the most common features of Forth that people point to when
>> comparing against C is interactivity,
>
> Very important in the past. But these days the *systems* are interactive
> and I can get around the edit/build/test loop in a few seconds even with
> a compile/link language. Faster than I can think ;-)
and it is still clumsy.
you need a C-File, probable H-File, edit Makefile, take
care of dependency have to link a lot of libraries every
time only to get a small (test) function running.
>> extensibility,
>
> But if you value straightforward code (as scientists and engineers
> generally do), extensibility is also an invitation to obfuscation. It's
> only a positive feature when used with great discipline.
>
>> and the ability to do run-time evaluation.
>
> I assume you mean compile-time: I know of few languages that prevent
> run-time evaluation!
>
> But here, C folks again use the *systems* that support C: generate C
> code with a script or another C program during the build. You can have
> whatever build-time computation you want that way.
more complex dependency for makefile. C code generators tend to
be more complex as those little building words in Forth.
best wishes
Andreas Klimas
John Passaniti
>> Very important in the past. But these days the *systems* are
>> interactive and I can get around the edit/build/test loop in a few
>> seconds even with a compile/link language. Faster than I can think ;-)
>
> and it is still clumsy.
> you need a C-File, probable H-File, edit Makefile, take
> care of dependency have to link a lot of libraries every
> time only to get a small (test) function running.
Yes, if you have C code, you're probably going to put it in a C file.
Thanks for pointing that out. I'm going to take a wild guess here and
say you're storing your Forth code somewhere. So I'll bravely suggest
this is a wash.
There is nothing intrinsic about writing C applications that forces the
programmer to create header files. But again, considering that the
purpose of header files is to pull in references, there isn't much of a
conceptual leap from including modular Forth files. So again, I'll
bravely suggest this is a wash.
Makefiles exist only if you need them. For small C programs, I need
nothing more than a command-line "cc somefile.c" to get the job done.
Putting libraries in my default list means I don't have to specify them.
The point here isn't that C is better than Forth. The point is that the
notion that C programmers are constantly spending oodles of time dealing
with trivia is nonsense. For mediocre C programmers who don't know how
to effectively use the language and the tools associated with it, yeah,
it's a struggle. And so it doesn't surprise me that in a Forth
newsgroup where people who talk about C often display poor knowledge of
the language and tools of C, there is a perception that this is difficult.
The same can be said of Forth. If you don't know how to effectively use
the language, it can be complex. But again, complexity here is not an
absolute. It's relative to your experience and expectations.
>> But here, C folks again use the *systems* that support C: generate C
>> code with a script or another C program during the build. You can have
>> whatever build-time computation you want that way.
>
> more complex dependency for makefile. C code generators tend to
> be more complex as those little building words in Forth.
There is no question that C's limitations make some things more clumsy
than in Forth. Of course, Forth's limitations make some things more
clumsy than in other languages. This shouldn't be a controversial
statement, but for some reason, the reflexive Forth fanboys of
comp.lang.forth can't stand the notion.
Richard Owlett
> Andreas Klimas wrote:
>
>>> Very important in the past. But these days the *systems* are
>>> interactive and I can get around the edit/build/test loop in a few
>>> seconds even with a compile/link language. Faster than I can think ;-)
>>
>>
>> and it is still clumsy.
>> you need a C-File, probable H-File, edit Makefile, take
>> care of dependency have to link a lot of libraries every
>> time only to get a small (test) function running.
>
>
> Yes, if you have C code, you're probably going to put it in a C file.
> Thanks for pointing that out. I'm going to take a wild guess here and
> say you're storing your Forth code somewhere.
[snip sillyness ]
OK so I did not bother reading it
why should I
Am I treating his comments any differently than he did OP ?????????
less sarcasm
more reason
plz
John Passaniti
> [snip sillyness ]
>
> OK so I did not bother reading it
> why should I
You shouldn't. If you don't like my style, you are free to put me in
your killfile. If you need assistance in doing this, please ask and I
will be happy to help you.
> Am I treating his comments any differently than he did OP ?????????
Do I care? Should I?
> less sarcasm
> more reason
> plz
Thank you for your comments on my style. I'm sorry that you wasted your
time in trying to modify my behavior.
Aleksej Saushev
> John Doty wrote:
>> John Passaniti wrote:
>>
>>> Three of the most common features of Forth that people point
>>> to when comparing against C is interactivity,
>>
>> Very important in the past. But these days the *systems* are
>> interactive and I can get around the edit/build/test loop in a
>> few seconds even with a compile/link language. Faster than I
>> can think ;-)
>
> and it is still clumsy.
> you need a C-File, probable H-File, edit Makefile, take
> care of dependency have to link a lot of libraries every
> time only to get a small (test) function running.
If you have pretty widespread BSD system (NetBSD, OpenBSD, FreeBSD),
you only need to type "make this", and it will compile "this.c",
link it, and bring you executable without even asking you to
write Makefile. If you want more complex things, you have plenty
of examples in your /usr/src, and once you learn it, you get plenty
of libraries to suffice your needs, which you can't say about Forth.
>>> and the ability to do run-time evaluation.
>>
>> I assume you mean compile-time: I know of few languages that
>> prevent run-time evaluation!
>>
>> But here, C folks again use the *systems* that support C:
>> generate C code with a script or another C program during the
>> build. You can have whatever build-time computation you want
>> that way.
>
> more complex dependency for makefile. C code generators tend to
> be more complex as those little building words in Forth.
Oh really? This so trivial, that you even can't imagine.
For instance, this is Makefile for expr(1) tool from NetBSD
empty lines removed:
# $NetBSD: Makefile,v 1.14 2000/09/19 17:20:00 jdolecek Exp $
PROG= expr
SRCS= expr.y
.include <bsd.prog.mk>
Really complex, isn't it?
--
BECHA...
CKOPO CE3OH...
Clever Monkey
have meant: you've described a situation where you not only have to know
C, you also have to know about the public interfaces and exports of
those libraries, and you have to learn the extremely arcane syntax of
another language: make. Sure, once you know how to make that basic
Makefile, you know it. But, how do you get to that knowing? This is
part of the "cognitive load" required to work with that language
environment.
Technically, one may have to learn the shell language they use as the
basis for the edit-compile-test loop, as well.
None of this stuff comes for free.
When comparing and contrasting languages, we should be careful to
compare apples with apples. In the case of C we should recognize that
the entire development system often includes much more than the core
language and compiler, and each component adds to the potential
cognitive load, and is not a "freebie." Each one has to be figured out
as you go.
One need only remember those first-year students who knew [insert some
language here] but were confronted with an unfamiliar development
environment. Around my school, this made for some tense end-of-semester
projects as many people struggled with everything /other/ than the code!
Not an impossible hurdle, of course, but it is unfair to simply
hand-wave this part of the C experience as trivial, because it most
certainly is not.
In fact, if you survey some of the threads over on comp.lang.c you will
find a not insignificant percentage of them are related to folks trying
to figure out the linker, the environment or something completely
separate from the language and compiler.
I would note that the entire language environment is precisely what we
want when we choose a language, so it is this total environment
(including how build artefacts are created and deployed) that should be
considered when comparing and contrasting. The "compiler" or whatever
is often only a small part of the considerations we have to make as
working coders.
This is why the much-maligned Java is so successful in some ways: it
offers a near-total source-to-artefact development and deployment
solution, along with a Good Enough OO language spec and compiler. With
all its failings it offers all sorts of non-language related tools that
make it very attractive for (certain types of) enterprise development.
So, by all means, let's talk about how the different toolsets we can use
as developers helps or hinders our work. But lets not be naive about
the full scope of understanding needed to really get the most out of a
particular language. C is an excellent cross-platform object code
generator. Actually getting that object code and doing anything useful
with it requires a whole set of tools that is not part of the ISO C
standard.
--
clvrmnky <mailto:spam...@clevermonkey.org>
Direct replies to this address will be blacklisted. Replace "spamtrap"
with my name to contact me directly.
Albert van der Horst
Clever Monkey <spam...@clevermonkey.org.INVALID> wrote:
>Aleksej Saushev wrote:
>> Andreas Klimas <kli...@klimas-consulting.com> writes:
>>
>> Oh really? This so trivial, that you even can't imagine.
>> For instance, this is Makefile for expr(1) tool from NetBSD
>> empty lines removed:
>>
>> # $NetBSD: Makefile,v 1.14 2000/09/19 17:20:00 jdolecek Exp $
>> PROG= expr
>> SRCS= expr.y
>> .include <bsd.prog.mk>
>>
>> Really complex, isn't it?
>>
>Well, I think you've highlighted at least one issue that the OP might
>have meant: you've described a situation where you not only have to know
>C, you also have to know about the public interfaces and exports of
>those libraries, and you have to learn the extremely arcane syntax of
>another language: make. Sure, once you know how to make that basic
>Makefile, you know it. But, how do you get to that knowing? This is
>part of the "cognitive load" required to work with that language
>environment.
There is a huge difference between the above Makefile and using
Visual studio. If I have a similar project I can just copy the
include statement without much idea what the hell bsd.prog.mk is.
If you look into my Makefile's for the ciforth project, you
see commands for making archives, tests, get bits of information
from the source, sort it and shape it in different kinds of
documentation and builds for a zillion configurations and versions.
This was a lot of work to figure out, and little of it had to do
with knowing about make. So the Makefile is an invaluable condensation
of all there is to know about the project, shaped in a form very
well adapted to a project. And, by the way, you see very little
of ``very arcane syntax''. I'm just too lazy too learn that.
You can't do that with windows. I mean it: full stop.
My renesas environment on Linux sports building it out of a version
control system, in different versions, an automatic test using
kermit, tailored documentation. This is vastly superior to the
Studio like official Renesas environment for building.
*That* can hardly build my Forth and put it into flash.
Adding other features there amounts to finding the correct tools,
buying them, having them cooperate. But graphics tools are just
not flexible enough. How to get rid of lines starting with a '!' ?
( |sed -e '/^!/d'| ). If the tool builders didn't have the foresight
to build that in, at the place you need, you're toast.
If they have, chance is that bugs crop up if you want to loose Forth
comments, because '\' is a character they didn't test for.
Graphic tools only work for just another run of the mill
program, of the sort the tool builders foresaw.
I don't agree. If you add domain knowledge to a hello.c program
you have something useful.
The hello.c program you can steal, if you can't type it in by
heart.
The rest amounts to
make hello
This is the innocence Bill Gates stole from us.
May I talk again about ciforth? There is one library file, and one
executable for interpreting, scripting and stand alone executables.
Even if there are some things that are awkward to use, at least you
need not find out which (if any) of a number of very alike icons does
what you want it to do. You can just bloody read it. Great invention,
language. Much better than icon language: the drawings of spears and
mammoths on the walls of caves.
>clvrmnky
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Clever Monkey
development toolchain, especially when your team is larger than one. In
fact, I took pains to be as non-specific about the many and varied tools
we can use as developers, except to note:
- Languages often have their typical and common support tools, which are
often languages in their own right. As developers we use "little
languages" all the time. Each one must be grokked.
- When comparing and contrasting languages it is easy to fall into the
trap of comparing specific and personal development environments vs. a
bare language. This is, of course, unfair and misleading.
> If you look into my Makefile's for the ciforth project, you
> see commands for making archives, tests, get bits of information
> from the source, sort it and shape it in different kinds of
> documentation and builds for a zillion configurations and versions.
> This was a lot of work to figure out, and little of it had to do
> with knowing about make. So the Makefile is an invaluable condensation
> of all there is to know about the project, shaped in a form very
> well adapted to a project. And, by the way, you see very little
> of ``very arcane syntax''. I'm just too lazy too learn that.
>
This actually seems to prove my point that the toolchain goes beyond the
language, and that each language has an explicit or implicit reliance on
any number of other stuff.
Someone had to learn Make well enough to grow this build system you
describe. It did not come for free, it did not spring fully formed from
your forehead and it was not copied verbatim off the internet.
A trivial makefile is just that: trivial. It can't do much, and if you
want more, you have to learn the arcane syntax and solve the problems
and generally debug the build system as you would a program.
I said "arcane" and I meant it. Make has a syntax all its own, and
learning how to even get by with make is a good skill that is almost
required to be a good C coder on most platforms. Especially if you do
cross-platform development on a large applications suite with a large
team, as I do.
> You can't do that with windows. I mean it: full stop.
>
I have no idea what you mean. Nothing you describe in the previous
paragraph is platform-specific. I do what you describe and more with
Make on Windows every day.
I'm not entirely sure what part of the rest of my comments you
specifically disagree with (you quote a long passage of mine, and then
simply say you disagree -- but with what?), but I don't think I'm making
any earth-shattering assertions here.
Being working developers means having to invest learning time into a
variety of non-language specific domains. These domains are somewhat
shaped by the language itself, and can often be considered part of the
language when it makes sense to do so.
If we are to compare HelloWorld, let's compare HelloWorld. If we are to
compare solving real-world problems for customers and maintaining a code
base for decades, lets talk about that. Context is everything.
Anyway, everyone knows that after the Language Wars are over we will all
be forced to use COBOL in re-education camps. I, for one, welcome our
wordy and punctuation-filled overlords.
John Doty
> I said "arcane" and I meant it. Make has a syntax all its own, and
> learning how to even get by with make is a good skill that is almost
> required to be a good C coder on most platforms. Especially if you do
> cross-platform development on a large applications suite with a large
> team, as I do.
It's a lot easier to coax physicists into using make than Forth these
days. So make can't be so bad.
--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
History teaches that logical consistency is neither sufficient nor
necessary to establish practical, real world truth. Those who attempt to
use logic for that purpose are abusing it.
Clever Monkey
> Clever Monkey wrote:
>
>> I said "arcane" and I meant it. Make has a syntax all its own, and
>> learning how to even get by with make is a good skill that is almost
>> required to be a good C coder on most platforms. Especially if you do
>> cross-platform development on a large applications suite with a large
>> team, as I do.
>
> It's a lot easier to coax physicists into using make than Forth these
> days. So make can't be so bad.
>
the sort of the technologies that we should include when we discuss how
"easy" or "appropriate" one language is over another.
Coders love to learn new languages. After all, it's what we do!
I stand by my remark that debugging complex Makefiles that have a lot of
history associated with them is one of the least satisfying jobs one can do.
John Doty
> Coders love to learn new languages. After all, it's what we do!
Yes, but the people who actually accomplish things with computers have
other priorities.
John Passaniti
>> Coders love to learn new languages. After all, it's what we do!
>
> Yes, but the people who actually accomplish things with computers have
> other priorities.
No, it's the same priorities. But like so many discussions in
comp.lang.forth, you take an overly-literal interpretation of what
people write and make no attempt to understand the meaning.
Take "learn new languages" as an example. The purpose of a programming
language is to express a solution within the paradigms, abstractions,
models, and idioms supported by that language. In that sense, "learn
new languages" means understanding different ways to conceptualize and
create a solution for a problem.
In other words, the point of "learn new languages" is to be able to
"accomplish things with computers" by enlarging the choices one has and
the techniques one might use. A programmer who only knows one language
and is stuck within what that language may certainly "accomplish things
with computers," but it may not be the best solution.
The more naive and inexperienced programmers don't get this because they
are stuck within a paradigm and think that describes the world. To
them, the differences between languages is nothing more than syntax.
You don't suffer from this-- at least I don't think you do. You've
mentioned experience with languages that suggest you understand at least
two different paradigms (procedural and functional) and there may be
others. So your experience must be broad enough and your mind must be
agile enough to envision solutions that may be quite different from each
other, and not just in terms of syntax.
So yeah, you must at some level understand that "learn new languages"
isn't just a no-op in terms of what programmers do and that has direct
relevance toward "accomplish things with computers." At least it does
for good programmers who care about their work. Bad programmers who are
stuck inside the mental boxes the languages they use surround themselves
with (including Forth) don't care. Possibly because they don't know
enough to care.
John Doty
> John Doty wrote:
>>> Coders love to learn new languages. After all, it's what we do!
>>
>> Yes, but the people who actually accomplish things with computers have
>> other priorities.
>
> No, it's the same priorities. But like so many discussions in
> comp.lang.forth, you take an overly-literal interpretation of what
> people write and make no attempt to understand the meaning.
>
> Take "learn new languages" as an example. The purpose of a programming
> language is to express a solution within the paradigms, abstractions,
> models, and idioms supported by that language. In that sense, "learn
> new languages" means understanding different ways to conceptualize and
> create a solution for a problem.
Sure. So the problem solver is looking to what might be helpful in
solving the problem. But that doesn't indicate any love for learning new
languages. Often, the old ones work fine.
>
> In other words, the point of "learn new languages" is to be able to
> "accomplish things with computers" by enlarging the choices one has and
> the techniques one might use. A programmer who only knows one language
> and is stuck within what that language may certainly "accomplish things
> with computers," but it may not be the best solution.
At the cutting edge, the best solution is unobtainable. The choice is
solution or no solution. Later on, when you understand what you're
doing, you can work on "best". But again, programming knowledge is of
limited use in judging what "best" means in a real application. The
domain rules.
>
> The more naive and inexperienced programmers don't get this because they
> are stuck within a paradigm and think that describes the world. To
> them, the differences between languages is nothing more than syntax.
>
> You don't suffer from this-- at least I don't think you do. You've
> mentioned experience with languages that suggest you understand at least
> two different paradigms (procedural and functional) and there may be
> others. So your experience must be broad enough and your mind must be
> agile enough to envision solutions that may be quite different from each
> other, and not just in terms of syntax.
Thanks. But this stuff comes easily to me (one minor project I'm working
on these days is learning Verilog). It *doesn't* come so easily to
others whose expertise I must rely on. Genius takes many forms. So it's
important to keep the methodology as straightforward as possible, even
if something more sophisticated might be "best" by some irrelevant metric.
>
> So yeah, you must at some level understand that "learn new languages"
> isn't just a no-op in terms of what programmers do and that has direct
> relevance toward "accomplish things with computers." At least it does
> for good programmers who care about their work. Bad programmers who are
> stuck inside the mental boxes the languages they use surround themselves
> with (including Forth) don't care. Possibly because they don't know
> enough to care.
Or because they are free from the mental box of programming, and have
other priorities outside of it. That can make someone extremely
effective at getting work done with a computer, even if their programs
are chaotic messes. Of course, cleaning up after such people is a
valuable skill, too.
John Passaniti
> At the cutting edge, the best solution is unobtainable. The choice is
> solution or no solution. Later on, when you understand what you're
> doing, you can work on "best". But again, programming knowledge is of
> limited use in judging what "best" means in a real application. The
> domain rules.
Well, we're back to this nonsense. As we've all seen countless times
before, you appear to live in a world where someone with the job title
"programmer" is little more than a code monkey, hired only because they
can take the ideas of the "domain expert" and express them in code. The
extent of how much this strict stratification is real or is the product
of artificial barriers you construct in your mind is anyone's guess.
All I can tell you is that companies that run on that model (strict and
limiting roles described by job titles) is increasingly rare in my
experience.
> Thanks. But this stuff comes easily to me (one minor project I'm working
> on these days is learning Verilog). It *doesn't* come so easily to
> others whose expertise I must rely on. Genius takes many forms. So it's
> important to keep the methodology as straightforward as possible, even
> if something more sophisticated might be "best" by some irrelevant metric.
We also seem to have a different definition of "genius." For you, it's
apparently someone who is completely invested in some domain and never
strays outside that narrow role. Your "genius" can't take on the role
of programmer, because gosh, that's a completely different title. And
we all know how important titles are to you.
That to me isn't a genius. That's someone who knows a lot about
something. Real genius is interdisciplinary. Real genius is not only
coming up with brilliant ideas and insights, but in being able to
realize them competently.
> Or because they are free from the mental box of programming, and have
> other priorities outside of it. That can make someone extremely
> effective at getting work done with a computer, even if their programs
> are chaotic messes. Of course, cleaning up after such people is a
> valuable skill, too.
A "genius" who is "free from the mental box of programming" is someone
who is next to useless. What we're ultimately talking about here are
systems that must be expressed in terms of hardware and software. A
"genius" who can't conceptualize their design in terms of real-world
hardware and software is engaging in something abstract.
Nearly as useless is the "genius" who "gets work done with a computer"
but that work is impractical. I worked with a "genius" who came up with
a beautifully elegant way to express a digital signal processing task.
He even came up with software that did the signal processing to show it
operating. The only problem was that his software didn't run in real
time (a requirement), and he and I later proved that his software
couldn't run in real time on the hardware we had available at the time.
Physical limits like cost, processor and memory bandwidth made it
impossible.
If that is a genius to you, then you have a low threshold for genius.
Again, the true genius is one who can cut across disciplines and realize
systems from the bottom to the top. True genius is a mixture of both
scientist and engineer, and sometimes marketing and management.
John Doty
> John Doty wrote:
>> At the cutting edge, the best solution is unobtainable. The choice is
>> solution or no solution. Later on, when you understand what you're
>> doing, you can work on "best". But again, programming knowledge is of
>> limited use in judging what "best" means in a real application. The
>> domain rules.
>
> Well, we're back to this nonsense. As we've all seen countless times
> before, you appear to live in a world where someone with the job title
> "programmer" is little more than a code monkey, hired only because they
> can take the ideas of the "domain expert" and express them in code. The
> extent of how much this strict stratification is real or is the product
> of artificial barriers you construct in your mind is anyone's guess.
In my experience it's barriers in *programmers'* minds. I see powerful
evidence that that barrier exists in *your* mind, but you are blind to
it. It does not exist in mine. If a program is the right solution, I'll
write a program. But I might also compute a logarithm with a diode (what
fraction of programmers would ever consider that alternative?).
You give lip service to the idea that programmers are also domain
experts, but then you also refer to programmers as masters of
specialized arcana like "design patterns". Very few real domain experts
know what a design pattern is.
I mostly work with experimental physicists. Compared to them, 99% of
people who call themselves "programmers" are just code monkeys. But
physicists can write pretty good code.
You're like the fish that has reached the surface of the water and
thinks he's reached outer space. You have a long way to go.
>
> All I can tell you is that companies that run on that model (strict and
> limiting roles described by job titles) is increasingly rare in my
> experience.
Sure. But do the programmers actually master the domain, or do they just
pretend? Do you even know how to tell?
Programming as a profession seems to be particularly attractive to
narrow minds. I guess the artificial world of the computer is less
threatening than the real world.
>
>> Thanks. But this stuff comes easily to me (one minor project I'm
>> working on these days is learning Verilog). It *doesn't* come so
>> easily to others whose expertise I must rely on. Genius takes many
>> forms. So it's important to keep the methodology as straightforward as
>> possible, even if something more sophisticated might be "best" by some
>> irrelevant metric.
>
> We also seem to have a different definition of "genius." For you, it's
> apparently someone who is completely invested in some domain and never
> strays outside that narrow role.
No. Usually it's somebody with multiple strengths. But nobody is good at
*everything*, although gaining skills even in areas where you can't be
excellent is valuable.
> Your "genius" can't take on the role
> of programmer, because gosh, that's a completely different title. And
> we all know how important titles are to you.
You choose to completely misunderstand my point.
>
> That to me isn't a genius. That's someone who knows a lot about
> something. Real genius is interdisciplinary. Real genius is not only
> coming up with brilliant ideas and insights, but in being able to
> realize them competently.
Indeed. And that's why programming systems must cater to the broad needs
of genius rather than to the narrow prejudices of code monkeys.
>
>> Or because they are free from the mental box of programming, and have
>> other priorities outside of it. That can make someone extremely
>> effective at getting work done with a computer, even if their programs
>> are chaotic messes. Of course, cleaning up after such people is a
>> valuable skill, too.
>
> A "genius" who is "free from the mental box of programming" is someone
> who is next to useless.
You just contradicted yourself. "Real genius is interdisciplinary." How,
then, can someone restricted to programming be a genius?
> What we're ultimately talking about here are
> systems that must be expressed in terms of hardware and software. A
> "genius" who can't conceptualize their design in terms of real-world
> hardware and software is engaging in something abstract.
And programming is the most abstract form of engineering.
>
> Nearly as useless is the "genius" who "gets work done with a computer"
> but that work is impractical. I worked with a "genius" who came up with
> a beautifully elegant way to express a digital signal processing task.
> He even came up with software that did the signal processing to show it
> operating. The only problem was that his software didn't run in real
> time (a requirement), and he and I later proved that his software
> couldn't run in real time on the hardware we had available at the time.
> Physical limits like cost, processor and memory bandwidth made it
> impossible.
That's pretty much what happened with the Hubble planning software but
the other way around: a team of professional programmers at a NASA
contractor developed, at enormous expense, a system that could not keep
up with real time. The software that worked was written by an
astrophysicist with spacecraft operations experience. "Real genius is
interdisciplinary."
I can think of quite a few other examples of this sort. Programmers tend
to overvalue elegance and logic. They also tend to optimize the wrong
things. Domain experts with problems to solve tend to be more practical.
>
> If that is a genius to you, then you have a low threshold for genius.
> Again, the true genius is one who can cut across disciplines and realize
> systems from the bottom to the top. True genius is a mixture of both
> scientist and engineer, and sometimes marketing and management.
I agree. But I have rarely encountered anyone like that who would call
themselves a "programmer".
Alex McDonald
>
> In my experience it's barriers in *programmers'* minds. I see powerful
> evidence that that barrier exists in *your* mind, but you are blind to
> it. It does not exist in mine. If a program is the right solution, I'll
> write a program. But I might also compute a logarithm with a diode (what
> fraction of programmers would ever consider that alternative?).
A very small fraction. I've often advocated this kind of lateral
thinking to colleagues. I say to them, why write a complex program to
do logs when there are alternatives like a slide rule smeared with
some raspberry jam? I keep a number of these small one portion jars in
my top drawer, but none of my colleagues ever has any. How
shortsighted is that?
--
Regards
Alex McDonald
John Passaniti
> In my experience it's barriers in *programmers'* minds. I see powerful
> evidence that that barrier exists in *your* mind, but you are blind to
> it. It does not exist in mine. If a program is the right solution, I'll
> write a program. But I might also compute a logarithm with a diode (what
> fraction of programmers would ever consider that alternative?).
That's a painfully stupid question because it ignores both the domain
the programmer works in and their ability to affect the system. So if
we're talking about a database programmer or a programmer writing
scripts to automate financial calculations in Excel, chances are their
training and experience wouldn't lead them to an analog solution. But
even if they did have that background, what good would it be? Where
exactly would they stick the diode in MySQL or Excel to act as a
logarithm coprocessor? Duh.
If we're talking about a embedded systems programmer, then that is a
different matter. Embedded systems programmers by and large are very
much aware of the analog world and the few who aren't quickly learn.
Where I've worked, we often will use analog insights to simplify our
designs. I replaced the digital logic used to read a 16-position
encoder with a resistor ladder hooked to a A/D converter, saving pins
and simplifying the code. A fellow engineer who needed a high-quality
white noise source noted that by adding a reverse-biased Zener diode to
the system, he could eliminate code for a pseudorandom noise source.
But these analog insights wouldn't matter if embedded systems
programmers had the limited role you believe they have. I and most
embedded systems programmers have the ability (role, responsibility, and
experience) to direct the system's hardware.
Your fundamental problem seems to be that you're stuck in some old model
of what a programmer is. To you, a programmer does nothing more than
program; he has no insights beyond how to line up braces and know where
the semicolon goes. And to the extent that is true in your experience,
all it tells me is that where you work must be a truly awful place,
especially for those with the job title of "programmer." You must treat
those guys like crap. Or perhaps in a fit of self-fulfilling prophecy,
you create your reality by only hiring programmers who are limited to
just coding, and reject those who have experience and insights outside
that as overqualified. Either way, sounds awful.
> You give lip service to the idea that programmers are also domain
> experts, but then you also refer to programmers as masters of
> specialized arcana like "design patterns". Very few real domain experts
> know what a design pattern is.
A design pattern is nothing more than a way to communicate the elements
that produce successful systems. When I first came across design
patterns, I was struck by how familiar it all was. And that's because
the same kinds of patterns that I had independently discovered in my own
work were also discovered by others. The only thing the design pattern
did was to give the pattern a name, a context, usually an example, and a
discussion about it's relationship to other patterns.
So design patterns are only "arcane" in the weakest sense of the word--
if I use a design pattern name like Observer or Chain of Responsibility,
you might not know specifically what that means. But chances are very
good you've implemented those patterns. The value of design patterns
then is that you can communicate designs easier because you're speaking
the same language.
> I mostly work with experimental physicists. Compared to them, 99% of
> people who call themselves "programmers" are just code monkeys. But
> physicists can write pretty good code.
>
> You're like the fish that has reached the surface of the water and
> thinks he's reached outer space. You have a long way to go.
And you're the fish who has swam in the same school for years and
believes every school is exactly like his. Your programmers are code
monkeys, so to you, all programmers are code monkeys.
>> All I can tell you is that companies that run on that model (strict
>> and limiting roles described by job titles) is increasingly rare in my
>> experience.
>
> Sure. But do the programmers actually master the domain, or do they just
> pretend? Do you even know how to tell?
>
> Programming as a profession seems to be particularly attractive to
> narrow minds. I guess the artificial world of the computer is less
> threatening than the real world.
That's funny. When I'm flipping on the oscilloscope to capture signal
reflections or to measure the rise-time of a analog signal, I seem to be
pretty much in the real world. Your jab against programmers fails for
embedded systems programmers. We're so much in the real world that it
hurts-- sometimes literally.
It also fails against for programmers in other domains. When the
programmer who writes financial applications notices that the
specifications he's been handed would lead to a system that conflicts
with Sarbanes-Oxley, how is that not being in the real world? When the
game programmer who is optimizing a shading algorithm to take advantage
of the spectral sensitivity of the human eye, how is that not being in
the real world?
> And programming is the most abstract form of engineering.
Weird. So when I'm measuring the EMI produced by my code, that's
abstract? When I'm profiling code to identify hotspots that would be
more efficiently handled in a FPGA, that's abstract? When I'm comparing
the current draw of different routines, that's abstract?
Care to qualify your statements any?
>> If that is a genius to you, then you have a low threshold for genius.
>> Again, the true genius is one who can cut across disciplines and
>> realize systems from the bottom to the top. True genius is a mixture
>> of both scientist and engineer, and sometimes marketing and management.
>
> I agree. But I have rarely encountered anyone like that who would call
> themselves a "programmer".
Then you need to start swimming away from the school you're in and look
at the larger world.
Bruce McFarling
> You give lip service to the idea that programmers are also domain
> experts, but then you also refer to programmers as masters of
> specialized arcana like "design patterns". Very few real domain experts
> know what a design pattern is.
Excepting, I presume, real domain experts from the problem domains
where design patterns originated, before being adopted into computer
programming.
Bernd Paysan
> You just contradicted yourself. "Real genius is interdisciplinary." How,
> then, can someone restricted to programming be a genius?
Here it is again, your strange idea that a the only being that is worth
called "programmer" is the code monkey - the person that is *restricted* to
programming, and can do nothing else (including, but not limited to "have
no social live" and "doesn't know which end of the screwdriver is the right
one"). I don't call your experimental physicists "restricted to
experimental physic", because they certainly aren't (they also can write
programs, build hardware, do advanced math, etc.).
The job description "programmer" certainly is a simplification, but you put
in some implicit "restricted to", which is nowhere in there. You are not
the only one who uses this limited definition of "programmer", because WP
writes "A programmer is not a software developer, software engineer,
computer scientist, or software analyst. These professions typically refer
to individuals possessing programming skills as well as other software
engineering skills. For this reason, the term programmer is sometimes
considered an insulting or derogatory oversimplification of these other
professions."
I actually don't want to get into discussions like this - all colloquial
words tried out for this profession have already ended up as derogatory, or
even worse (like "hacker"), but that's a society problem. If you like,
translate the word "programmer" as we use it here into "software engineer"
or whatever you think a higher-valued person who's main job still is to
develop software (but not limited to enter code into the machine) could be
called.
John Passaniti
> Excepting, I presume, real domain experts from the problem domains
> where design patterns originated, before being adopted into computer
> programming.
My grandmother enjoyed making clothing, quilts, and the like. She would
do this for fun as well as gifts, and she would often start with a
pattern. For those that don't know, you can get patterns for common
things-- shirts, pants, dresses, coats, etc. These patterns effectively
capture a lot of past experience in making clothes-- how to attach a
lapel, the proportions to match different sizes of people, places to
leave things loose, where to reinforce for strength, etc.
But these were patterns, not kits. She added her own special touches.
She sometimes combined patterns together, picking and choosing the parts
she liked from both. And sometimes, she would completely ignore the
pattern because she wanted to do something different or experimental.
When she was done, you could look at the patterns she used and see them
in the completed garment. These patterns had names, and she would say
"I took an sleeve from X and used a Y base for the shirt."
...
The computer science notion of design patterns largely evolved from the
architectural notion of pattern languages. But the larger concept has
existed in many forms prior to that. Computer science came fairly late
to the party. Other areas that had their own pattern languages were
typesetters, stage directors, choreographers, and chefs.
My first exposure to design patterns happened when I was debugging some
code with a fellow engineer. I was in the middle of explaining how some
core parts of my system worked, and he interrupted me and said, "oh,
you're using an Observer pattern.
I didn't know what he was talking about. So we talked about it, and I
was intrigued by the notion of being able to describe high level design
concepts in an abstract way.
So I went out and bought the classic "Gang of Four" Design Patterns book
and started to go through the 23 patterns the book describes. In it, I
found familiar ideas that I either have been implementing or that I have
seen in other's code. But now, I had a name for them, and I had a
language for communicating my designs to others. And by studying design
patterns I was unfamiliar with, I started to see ways to apply those
ideas to simplify or improve my systems.
If my grandmother was still alive, it would be great to describe design
patterns to her and get her reaction. Knowing her, she would probably
say, "well, duh, how else would programmers talk about what they do--
everyone needs a common language to describe their work." She would
then make me the best cheese-salad sandwiches in the world.
Jonah Thomas
> My grandmother enjoyed making clothing, quilts, and the like. She
> would do this for fun as well as gifts, and she would often start with
> a pattern. For those that don't know, you can get patterns for common
>
> things-- shirts, pants, dresses, coats, etc. ....
Thank you! That made perfect sense!
Bruce McFarling
h...@JapanIsShinto.com> wrote:
\>If my grandmother was still alive, it would be great to describe
design
> patterns to her and get her reaction. Knowing her, she would probably
> say, "well, duh, how else would programmers talk about what they do--
> everyone needs a common language to describe their work." She would
> then make me the best cheese-salad sandwiches in the world.
Note that for this, a pattern language that is "good enough" to allow
people to talk about their design activity, and is widely understood,
is superior to a pattern language that is "ideal" for a particular
design activity, but is not widely understood.
That is, after all, was the rationale for a Scientific Interactive
Command Language with Forth as its assembler ... something that looks
much like a common pseudo-code but can be interpreted, incrementally
compiled and run, and that when you crack the hood allows you to get
as close to the metal as the host Forth allows ... which for many
hosts would be quite close to the metal indeed.
John Passaniti
> Note that for this, a pattern language that is "good enough" to allow
> people to talk about their design activity, and is widely understood,
> is superior to a pattern language that is "ideal" for a particular
> design activity, but is not widely understood.
I'm not sure how to interpret this. I'm reading it as a concern about
the structure of design patterns. Do you think that design patterns are
in some sense too complicated?
Design patterns (at least as they apply to computer science) are nothing
more than documentation that provides a name, an intent (goals for the
pattern), context (where the pattern would be used), and discussion.
More formally, design patterns have a common recommended structure to
them. The Wikipedia article on design patterns gives a good overview of
the usual sections found in a design pattern:
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)#Documentation
Not every section is necessarily important, and many times, these
sections are nothing more than a single sentence or a list.
> That is, after all, was the rationale for a Scientific Interactive
> Command Language with Forth as its assembler ... something that looks
> much like a common pseudo-code but can be interpreted, incrementally
> compiled and run, and that when you crack the hood allows you to get
> as close to the metal as the host Forth allows ... which for many
> hosts would be quite close to the metal indeed.
Again, I'm not sure what you're addressing here.
A design pattern is not pseudocode. The purpose of pseudocode is to
describe abstractly an implementation. The purpose of a design pattern
is to describe abstractly a design.
The difference may be clearer if I take a specific example.
One common pattern is "Chain of Responsibility" (COR). The basic idea
in COR is that you have some notion of a command and you pass this
command on down through code that either acts on the command or passes
the command on to other code that can act on the command. An example
might be a help system in a GUI. I might point my cursor to some
on-screen element and issue a "help" command. The system using COR
would then pass this request for "help" up through the hierarchy of
controls on the screen. So I might point to a number, and ask help. If
that control didn't have specific help, it would pass my help command up
to it's parent, which might be a frame. If that frame didn't have a
specific help command, it might pass it up to it's parent.
That, in a paragraph is the essence of Chain of Responsibility and
that's where the design pattern effectively stops.
The programming looking at this may next need a suggestion of how to
actually implement this. This is where pseudocode might come in.
given a command:
if the object can respond to command:
do command
end
else
if object has a parent:
pass command to object's parent
else
end (command not handled)
The difference between the design pattern and the pseudocode is that the
design pattern is more abstract and thus can be applied to a larger set
of problems. The pseudocode is making an explicit requirement that
we're dealing with objects that have a sense of their parent. This
wasn't required by the design pattern.
Now, one could certainly look at the psuedocode above and be able to see
how the basic idea might be applicable to a wide variety of things. You
don't need objects with notions of parents. You could express the chain
as an array-- passing the command through an array of handlers for the
command. Or you might have a system that didn't have lists or arrays
but some kind of dynamic discovery of how things are connected in a system.
But in that case, one is taking pseudocode (which is more tightly
coupled to a particular implementation) and generalizing it-- arriving
at where the design pattern started.
Or put another way, the best design patterns tend not to come from
people sitting around thinking abstractly about a problem, but from
observing actual real systems, identifying the common ideas, and the
abstracting from there. Indeed, if a design pattern didn't start this
way, it's probably suspect.
Clever Monkey
mechanisms. I suggest jelly of some sort, or seedless jam.
Bruce McFarling
> Bruce McFarling wrote:
> > Note that for this, a pattern language that is "good enough" to allow
> > people to talk about their design activity, and is widely understood,
> > is superior to a pattern language that is "ideal" for a particular
> > design activity, but is not widely understood.
> I'm not sure how to interpret this. I'm reading it as a concern about
> the structure of design patterns. Do you think that design patterns are
> in some sense too complicated?
As a caution against the "not invented here" mentality ... people who
are
used to rolling their own solutions from scratch have to be careful
that
they do not fall into "can I improve this design?" mode when learning
the pattern language in common use.
So, in other words, interpret it directly in terms of what it
explicitly
says, rather than trying to read between the lines.
Bruce McFarling
> > Note that for this, a pattern language that is "good enough" to allow
> > people to talk about their design activity, and is widely understood,
> > is superior to a pattern language that is "ideal" for a particular
> > design activity, but is not widely understood.
> I'm not sure how to interpret this.
> > That is, after all, was the rationale for a Scientific Interactive
> > Command Language with Forth as its assembler ... something that looks
> > much like a common pseudo-code but can be interpreted, incrementally
> > compiled and run, and that when you crack the hood allows you to get
> > as close to the metal as the host Forth allows ... which for many
> > hosts would be quite close to the metal indeed.
> Again, I'm not sure what you're addressing here.
As states, that the rationale behind the first statement is the same
as
the rational for a previously sketched "Scientific Interactive
Command
Language".
I'm not sure where you got that the second statement is about pattern
languages. Its the rationale that is said to be common between the
two statements, not the subject matter.
John Passaniti
> As a caution against the "not invented here" mentality ... people who
> are
> used to rolling their own solutions from scratch have to be careful
> that
> they do not fall into "can I improve this design?" mode when learning
> the pattern language in common use.
Yes, I agree with this.
I think a problem a lot of people have with design patterns is to view
them as a kind of "cookbook solution" to a problem. An example of a
cookbook solution would be the kind of thing we see in comp.lang.forth
all the time. Someone asks a question ("how can I efficiently calculate
the quadratic equation") and then people provide and discuss solutions.
There's nothing wrong with cookbook solutions, but as they are about
implementation and not higher-level design, the NIH-mind can usually
find ways to improve them.
Design patterns on the other hand tend to be things that you can't
improve as much, because they aren't tied to a particular implementation.
The distinctions here are sometimes subtle and will be lost to anyone
who confuses design with implementation.
> So, in other words, interpret it directly in terms of what it
> explicitly says, rather than trying to read between the lines.
I'm sorry, but even going back and reading your initial message with
this new information, I'm still don't see that meaning as being obvious.
John Passaniti
> I'm not sure where you got that the second statement is about pattern
> languages. Its the rationale that is said to be common between the
> two statements, not the subject matter.
I'm one of those crazy people who assumes that two sequential
sentences-- especially one where the second references the first-- are
related.
When people write and tell me that they didn't understand what I wrote,
I usually take it that I didn't express myself well enough to be understood.
Bruce McFarling
> Bruce McFarling wrote:
> > I'm not sure where you got that the second statement is about pattern
> > languages. Its the rationale that is said to be common between the
> > two statements, not the subject matter.
> I'm one of those crazy people who assumes that two sequential
> sentences-- especially one where the second references the first-- are
> related.
Yes, they are related.
"That ...[typo-deleted], after all, was the rationale for a Scientific
Interactive Command Language with Forth as its assembler" was intended
to indicate that the rationale for the former and the rationale for
the latter are the same rationale, and that their relationship is that
they have the same rationale.
If you prefer:
*The rationale for* preferring pattern language in common use over
some modification, *the rationale for* the idea of the Scientific ICL,
those two rationales are the same rationale.
Brad Eckert
> I actually don't want to get into discussions like this - all colloquial
> words tried out for this profession have already ended up as derogatory, or
> even worse (like "hacker"), but that's a society problem.
grandmother wanted to know what systems analysts do:
Q: "What do you do?"
A: "I push buttons."
Robert Spykerman
Ok, I'm really curious, you got me baited. I have to ask:
Tell me about slide rules and raspberry jam, is there some great
secret I am not aware of?
I didn't grow up in the era of slide rules but I've got a perfectly
good one that does logs perfectly well without the aid of jam in any
shape or form.
Is your slide rule so well worn that you need raspberry jam to keep it
from slipping? :P
> Alex McDonald
Robert Spykerman
Doug Hoffman
> Ok, I'm really curious, you got me baited. I have to ask:
>
> Tell me about slide rules and raspberry jam, is there some
> great
> secret I am not aware of?
>
> I didn't grow up in the era of slide rules but I've got a
> perfectly
> good one that does logs perfectly well without the aid of jam
> in any
> shape or form.
The transition from slide rules to pocket calculators happened
while I was an engineering student (mechanical). IMHO the only
value of knowing how to use one is one becomes adept at
estimating. I threw mine away the same day I bought my HP-35.
--
-Doug
** Posted from http://www.teranews.com **
Alex McDonald
wrote:
I just don't find many programmers that use slide rules, raspberry jam
or diodes to work out logs. John Passaniti got to the nub of it when
he said;
<quote>
That's a painfully stupid question because it ignores both the domain
the programmer works in and their ability to affect the system. So if
we're talking about a database programmer or a programmer writing
scripts to automate financial calculations in Excel, chances are their
training and experience wouldn't lead them to an analog solution. But
even if they did have that background, what good would it be? Where
exactly would they stick the diode in MySQL or Excel to act as a
logarithm coprocessor? Duh.
</quote>
Quite. My poor attempt at humour was to point out that there may be a
solution domain for jam and diodes, but most programmers have a
limited supply of both. And slide rules are in scarce supply too.
--
Regards
Alex McDonald
Jerry Avins
I still keep one in my pocket. I had it when I paid $400 for my hp-35.
That no longer works, but my little Pickett does.
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
John Passaniti
> I still keep one in my pocket. I had it when I paid $400 for my hp-35.
> That no longer works, but my little Pickett does.
I have a slide rule too, and in fact, I used it just a couple days ago.
I dropped a tiny screw in a narrow space. I couldn't get my fingers in
that space. So I opened up my junk drawer and saw two old slide rules I
keep there. I picked the longer of the two (I needed the precision),
put a loop of adhesive tape on the end, and then carefully used it to
pick up the screw. Success!
I'm sure in some abstract way, knowing how to use a slide rule has
helped me and my career. For example, the primary benefit of knowing
how to use a slide rule was that it enabled me to gain some instant
respect from older engineers who spoke with sentimentalized nostalgia
about how great slide rules were. Had I not known how to use a slide
rule, I'm sure that I would have been treated the same way I now treat
junior engineers-- with a cynical sense of "you kids don't know
anything." Instead, I was able to bootstrap professional relationships
with older engineers based on being able to be as pretentious as they were.