|
|
 Up |
|
|
  |
Author: vandysvandys Date: Jan 31, 2008 12:02
Jeff M. gmail.com> wrote:> s" Hello, world!" email< me@ home.com> send-email
> It's equally brief, just as readable, and there's just as much code
> that exists underneath it,
> ...
Yes, but... what would this code look like if you wanted to append
the string in the variable "sig" to the contents? In Python it'd
go from:
smtp.sendmail(src, dests, "Hello, world!")
to:
smtp.sendmail(src, dests, "Hello, world!" + sig)
In any sort of "standard model" Forth, the would-be caller is going to
have to deal with sizing and allocating a new buffer, and copying the
contents into it. Then using it, and determining when the use was
finished and releasing the memory (IF you have a heap allocator,
otherwise you can think about a pessimistically sized static area,
blah blah blah....)
I've found that the limitations in your data model will push
themselves up into your attempt to abstract complexity.
|
| Show full article (0.94Kb) |
|
| | 16 Comments |
|
|
Author: Jeff M.Jeff M. Date: Jan 31, 2008 13:31
On Jan 31, 2:02 pm, van...@ vsta.org wrote: > Jeff M. gmail.com> wrote:>> s" Hello, world!" email< m...@ home.com> send-email
>> It's equally brief, just as readable, and there's just as much code
>> that exists underneath it,
>> ... >
> Yes, but... what would this code look like if you wanted to append
> the string in the variable "sig" to the contents? In Python it'd
> go from:
>
> [..snip example..]
>
> In any sort of "standard model" Forth, the would-be caller is going to
> have to deal with sizing and allocating a new buffer, and copying the
> contents into it. [..]
|
| Show full article (1.39Kb) |
|
| | no comments |
|
|
Author: Andreas KlimasAndreas Klimas Date: Apr 16, 2008 07:36
> Jeff M. gmail.com> wrote:>> s" Hello, world!" email< me@ home.com> send-email
>> It's equally brief, just as readable, and there's just as much code
>> that exists underneath it,
>> ... >
> Yes, but... what would this code look like if you wanted to append
> the string in the variable "sig" to the contents? In Python it'd
> go from:
>
> smtp.sendmail(src, dests, "Hello, world!")
>
> to:
>
> smtp.sendmail(src, dests, "Hello, world!" + sig)
>
> In any sort of "standard model" Forth, the would-be caller is going to
> have to deal with sizing and allocating a new buffer, and copying the
> contents into it. Then using it, and determining when the use was ...
|
| Show full article (1.45Kb) |
| 1 Comment |
|
|
Author: vandysvandys Date: Apr 16, 2008 09:25
Andreas Klimas klimas-consulting.com> wrote:
(My example:)>> smtp.sendmail(src, dests, "Hello, world!")
>> to:
>> smtp.sendmail(src, dests, "Hello, world!" + sig)
>> In any sort of "standard model" Forth, the would-be caller is going to
>> have to deal with sizing and allocating a new buffer, and copying the
>> contents into it. Then using it, and determining when the use was
>> finished and releasing the memory (IF you have a heap allocator,
>> otherwise you can think about a pessimistically sized static area,
>> blah blah blah....)
> this is the most complex way one could imagine and the source of
> the thinking that we need garbage collectors, memory mamangers
> and even object orientation.
Oh, I don't know. Don't dare me to try and imagine something more
complex. But note that it was REALLY EASY to write in Python, and
what I wrote is PROBABLY CORRECT.
|
| Show full article (2.35Kb) |
| 3 Comments |
|
|
Author: Marcel HendrixMarcel Hendrix Date: Apr 16, 2008 10:10
vandys@ vsta.org wrote Re: paul grahams arc, a new lisp, and his words about makign code ?shorter, vs forth?
> (My example:)
>>> smtp.sendmail(src, dests, "Hello, world!")
>>> to:
>>> smtp.sendmail(src, dests, "Hello, world!" + sig)
old:
src dests S" Hello, world!" sendmail
new:
src dests S" Hello, world!" sig $+ sendmail
Using the proper extensions that most good Forth have, of course :-)
-marcel
|
| |
| no comments |
|
|
Author: William JamesWilliam James Date: Apr 16, 2008 10:44
On Apr 16, 12:10 pm, m...@iae.nl (Marcel Hendrix) wrote:
> van...@ vsta.org wrote Re: paul grahams arc, a new lisp, and his words about makign code ?shorter, vs forth?
> >> (My example:)
>>>> smtp.sendmail(src, dests, "Hello, world!")
>>>> to:
>>>> smtp.sendmail(src, dests, "Hello, world!" + sig)
>
> old:
> src dests S" Hello, world!" sendmail
>
> new:
> src dests S" Hello, world!" sig $+ sendmail
>
> Using the proper extensions that most good Forth have, of course :-)
So you would have to learn a different way of doing it for
each version of Forth.
Only a low-level language, like assembly language or ANS Forth,
needs an extension for string concatenation.
|
| Show full article (0.77Kb) |
| no comments |
|
|
Author: Bruce McFarlingBruce McFarling Date: Apr 16, 2008 12:15
On Apr 16, 1:44 pm, William James yahoo.com> wrote:>> old:
>> src dests S" Hello, world!" sendmail
>> new:
>> src dests S" Hello, world!" sig $+ sendmail
>> Using the proper extensions that most good Forth have, of course :-)
> So you would have to learn a different way of doing it for
> each version of Forth.
Why would that be? You mean, a tinkerer's Forth that is not an ANS
Forth? That's like using a tinkerer's version of anything ... if I was
compiling a "portable" C source in Small C on CP/M, I'd expect to have
to do some cutting and trimming to make it compile.
|
| |
| no comments |
|
|
Author: John PassanitiJohn Passaniti Date: Apr 16, 2008 15:03
Andreas Klimas wrote:
> this is the most complex way one could imagine and the source of
> the thinking that we need garbage collectors, memory mamangers
> and even object orientation.
Complexity is not an absolute. It's a matter of perspective and
context. From the perspective of a programmer familiar with the bare
metal under a system, things like garbage collection, memory management,
and object orientation represent (potentially) complicated protocols,
complicated hardware, with more memory, processor cycles, and watts used.
But change the perspective. Take a language with garbage collection,
memory management, and object orientation-- like Smalltalk. And go back
to those experiments in the late 70's and early 80's where they taught
children how to use and build on those abstractions and to produce code
that was extremely sophisticated.
Ask these kids if they found garbage collection complicated. The
answer? No. They weren't even aware of it was going on. Ask these
kids if they found object orientation difficult to grasp? The answer?
No. They found these were very natural abstractions and metaphors that
mapped nicely into their real-world experience.
|
| Show full article (1.42Kb) |
| no comments |
|
|
Author: Andreas KlimasAndreas Klimas Date: Apr 22, 2008 17:37
John Passaniti wrote:
> Andreas Klimas wrote:
>> this is the most complex way one could imagine and the source of
>> the thinking that we need garbage collectors, memory mamangers
>> and even object orientation.
>
> Complexity is not an absolute. It's a matter of perspective and
> context. From the perspective of a programmer familiar with the bare
> metal under a system, things like garbage collection, memory management,
> and object orientation represent (potentially) complicated protocols,
> complicated hardware, with more memory, processor cycles, and watts used.
sure I'm missing the correct wording. probably "whole systemcomplexity".
where remote maintenance, packaging and distribution are also issues,
as performance and tool availability.
> But change the perspective. Take a language with garbage collection,
> memory management, and object orientation-- like Smalltalk.
I did (10years) professional programming in VisualAge and VisualWorks.
|
| Show full article (2.13Kb) |
| no comments |
|
|
|
|
|
Author: Jonah ThomasJonah Thomas Date: Apr 23, 2008 03:45
Andreas Klimas klimas-consulting.com> wrote:> John Passaniti wrote:
>> Andreas Klimas wrote:
>>> this is the most complex way one could imagine and the source of
>>> the thinking that we need garbage collectors, memory mamangers
>>> and even object orientation.
>>
>> Complexity is not an absolute. It's a matter of perspective and
>> context. From the perspective of a programmer familiar with the
>> bare metal under a system, things like garbage collection, memory
>> management, and object orientation represent (potentially)
>> complicated protocols, complicated hardware, with more memory,
>> processor cycles, and watts used.
>
> sure I'm missing the correct wording. probably "whole
> systemcomplexity". where remote maintenance, packaging and
> distribution are also issues, as performance and tool availability.
Sure. But a lot of people get to treat most of those as "somebody else's
problem".
|
| Show full article (5.00Kb) |
| no comments |
|
|
|
|
