nemesis <nam### [at] nospam-gmailcom> wrote:
> Errata: read v as vec. :P

Ah, yes, maybe *that's* why I didn't get it?! ;P

> Let's put c and my scheme idiom side-by-side:
>
> ((range 0 9) '() (lambda (i o) (vector-set! vec i (* i i)) o))
> for(int i=0;i++<10;)vec[i]=i*i;

Well, that's (1) not plain C but C++, and (b) obfuscated. Plain, common-style C
would be:

int i; for (i=0;i<10;i++) vec[i]=i*i;

> (for i 0 9 => (@! vec i (* i i)))
>
> Much better. :)

Um... for an obfuscated code contest - yes, I guess so :P

I don't claim the C family of languages to have a less obfuscated syntax - but I
have a feeling that at least the basic concept is much more "digestible" to the
average programmer...

Post a reply to this message

clipka wrote:
> nemesis <nam### [at] nospam-gmailcom> wrote:
>> Errata: read v as vec. :P
> 
> Ah, yes, maybe *that's* why I didn't get it?! ;P

LOL. ok...

> int i; for (i=0;i<10;i++) vec[i]=i*i;

Excellent.  Just beat it. ;P

>> (for i 0 9 => (@! vec i (* i i)))
>>
>> Much better. :)
> 
> Um... for an obfuscated code contest - yes, I guess so :P

Hmm, I could be more verbose, but then C folks would pick on it not 
being concise.
(for i from 0 to 9 => (vector-set! vec i (* i i)))

Nevertheless, don't you find it amazing to be able to simply churn out 
new syntax as you see fit?

> I don't claim the C family of languages to have a less obfuscated syntax - but I
> have a feeling that at least the basic concept is much more "digestible" to the
> average programmer...

Frankly, is the above syntax truly hard to figure it out?  But yes, C is 
digestible simply because of sheer familiarity.  It's like Windows.

Post a reply to this message

nemesis <nam### [at] nospam-gmailcom> wrote:
> (for i from 0 to 9 => (vector-set! vec i (* i i)))
>
> Nevertheless, don't you find it amazing to be able to simply churn out
> new syntax as you see fit?

#define FROM for(int
#define TO ;!(
#define INCREMENT );
#define BEGIN ++){
#define END }

FROM i = 1 TO i = 10 INCREMENT i
BEGIN
END

didn't test it, but if I'm not mistaken it should be perfectly valid C++ code.

I have one word for that:

    Inconsistency.

*You* can read it, but someone else must first learn your brand-new churned-out
syntax to grasp your code.

Yes, great for obfuscating. No, bad for anything that requires teamwork.

> Frankly, is the above syntax truly hard to figure it out?

Yes - not primarily because the syntax is hard to read, but primarily because
I'm not accustomed to this kind of basic approach. The shorthand syntax just
makes things worse by not giving any clue (just like for someone just learning
C, I guess).

> But yes, C is digestible simply because of sheer familiarity.
> It's like Windows.

No, its higher digestibility lies not only in the sheer familiarity of C itself
(and its heirs), but mainly in that the basic *concept* is probably familiar to
*any* programmer. I can't imagine a programmer who has in his whole life never
ever gotten in touch with imperative programming. But I know a whole bunch of
software developers who, confronted with the question what functional
programming languages they know, would probably answer with a puzzled "what?"

So it's not like Windows. It's like GUI. Everyone has seen it, and everyone
knows at least a *bit* of how to get along in it somehow; even if all your
computer experience was from a Mac, you'd have at least some vague idea of how
to do *something* in Windows - and vice versa; even those who prefer to work
with vi typically know at least a bit about how to operate a GUI. - But place a
random person in front of a console with vi running, and they'll be lost.
Utterly. They wouldn't even be able to shut down the computer (well, unless
they have access to the power switch).

Post a reply to this message

clipka wrote:
> nemesis <nam### [at] nospam-gmailcom> wrote:
>> (for i from 0 to 9 => (vector-set! vec i (* i i)))
>>
>> Nevertheless, don't you find it amazing to be able to simply churn out
>> new syntax as you see fit?
> 
> #define FROM for(int
> #define TO ;!(
> #define INCREMENT );
> #define BEGIN ++){
> #define END }
> 
> FROM i = 1 TO i = 10 INCREMENT i
> BEGIN
> END
> 
> didn't test it, but if I'm not mistaken it should be perfectly valid C++ code.

It's a very cheap and limited preprocessing trick which won't work if 
you want to place things differently.  In Scheme/Lisp you have true 
syntatic abstraction and it's used for very good purposes.  Macros are 
an intrinsic part of Lisp.

For instance, I can rewrite the same syntax for various purposes:

(define-syntax for
     (syntax-rules (=> from to in resulting initially do:)
       ; simple list iteration
       ((for i in ls do: body ...)
        (for-each (lambda (x) (let ((i x)) body ...)) ls))
       ; imperative iteration over numeric range
       ((for i from x to y do: body ...)
        ((range x y) #t (lambda (i o) (begin body ...) o)))
       ; functional iteration over numeric range
       ((for i from x to y resulting j initially init do: body ...)
        ((range x y) init (lambda (i o) (let ((j o)) body ...))))))

and then use :

 > (for x from 1 to 2 do:
       (for y from 1 to 3 do: (display x)(display y)(newline)))
11
12
13
21
22
23
true
 > (for item in '(1 2 3) do: (display item)(newline))
1
2
3
 > (for x from 5 to 1 resulting y initially () do: (cons (* 2 x) y))
`(2 4 6 8 10)

And the real bad deal:  your example looks more like pascal than C. 
Lisp code is extremely regular, it always look alike, despite new handy 
syntax.

Plus, if I want to DECREMENT in your example I'm screwed, most likely 
having to resort to a different "begin" to try to get around the fact 
that the new "syntax" has its semantics fixed in place but scattered all 
around the labels.


> I have one word for that:
> 
>     Inconsistency.

Indeed.

> *You* can read it, but someone else must first learn your brand-new churned-out
> syntax to grasp your code.

Not a problem in Lisp culture, where people read the code by scope.

 > No, its higher digestibility lies not only in the sheer familiarity of
 > C itself (and its heirs), but mainly in that the basic *concept* is
 > probably familiar to *any* programmer.

Funnily enough, and except for the syntatic abstraction, my example 
dealt only with function definition and function application.  I thought 
those concepts were flying around for ages now.

well, ok, functions returning functions is not generally mainstream...

> So it's not like Windows. It's like GUI. Everyone has seen it, and everyone
> knows at least a *bit* of how to get along in it somehow; even if all your
> computer experience was from a Mac, you'd have at least some vague idea of how
> to do *something* in Windows - and vice versa; even those who prefer to work
> with vi typically know at least a bit about how to operate a GUI. - But place a
> random person in front of a console with vi running, and they'll be lost.
> Utterly. They wouldn't even be able to shut down the computer (well, unless
> they have access to the power switch).

It's an interesting comparison.

Here's a more interesting one:  put a novice with no knowledge of 
programming languages in front of the monitor and ask him/her what 
he/she figures out of this one:

(for x from 1 to 5 do: (display x)(newline))

and then this one:

int i; for(i = 1; i <= 5; i++) printf("%d\n", i);

What is the point of this little experiment?  To show that creating your 
own syntax clearly has many benefits (specially for DSLs) -- like making 
it more suited for the audience/domain or if you simply don't dig the 
basic cryptic one -- and that awkwardness is in the eyes of the 
beholder.  Lisp folks are known to create the language most well suited 
and then program in that.

Scheme is often taught in first year compsci courses because of its 
simplicity:  function definition and function application is all there 
really is to it, predefined syntatic details is minimal.  So, I feel 
astonished when people find it overwhelming.

That said, I wasn't *seriously* proposing Scheme for povray's scripting 
language in the first place although I do believe it could be beneficial 
in many ways.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> nemesis <nam### [at] nospam-gmailcom> wrote:
> > Errata: read v as vec. :P
>
> Ah, yes, maybe *that's* why I didn't get it?! ;P
>
> > Let's put c and my scheme idiom side-by-side:
> >
> > ((range 0 9) '() (lambda (i o) (vector-set! vec i (* i i)) o))
> > for(int i=0;i++<10;)vec[i]=i*i;
>
> Well, that's (1) not plain C but C++, and (b) obfuscated. Plain, common-style C
> would be:
>
> int i; for (i=0;i<10;i++) vec[i]=i*i;
>
> > (for i 0 9 => (@! vec i (* i i)))
> >
> > Much better. :)
>
> Um... for an obfuscated code contest - yes, I guess so :P
>
> I don't claim the C family of languages to have a less obfuscated syntax - but I
> have a feeling that at least the basic concept is much more "digestible" to the
> average programmer...

If it can be useful the point of view of a non-programmer and a beginner in
POV-ray...

POV language is simple and intuitive, and there are not hateful things, like:

- *<>* or *</>* for each line...
- long word, filled with *__*, etc.

- billion of brackets of all types that disorientate...

Here, would it be possible to make the POV-language more powerful while
preserving the characteristics of simplicity?
:-)

--
Carlo

Post a reply to this message

clipka <nomail@nomail> wrote:
> > for(int i=0;i++<10;)vec[i]=i*i;

> Well, that's (1) not plain C but C++

  That has been valid C for 10 years now.

-- 
                                                          - Warp

Post a reply to this message

"Chambers" <ben### [at] pacificwebguycom> wrote in message 
news:49cd21cc$1@news.povray.org...
>
> In fact, if that's the case then the current parser could be kept for 
> backwards compatability, activated by an appropriate #version directive 
> (or whatever the equivalent would be in the new language) but remain 
> static and disallowing access to features exclusive to the new language.
>

This would make a lot of sense, at the very least as a transition strategy. 
Otherwise the cutover is likely to leave most of the existing community 
using the scene files, macros and utilities that they know work with the old 
software and a small new community that learns the new software.

Having such a transition would permit teething problems with the new 
unproven approach to be ironed out and omissions, where the new software 
can't do all that the old software did, to be bridged. It would also allow 
time for a reasonable proportion of the assets developed for POV-Ray to be 
migrated across. A process that won't really even be able to start in 
earnest until V4 is demonstrably stable (unless of course we build 6 years 
of Beta testing in the plan :-)).

Regards,
Chris B.

Post a reply to this message

"Mueen Nawaz" <m.n### [at] ieeeorg> wrote in message
news:49cbd590$1@news.povray.org...
> Chris B wrote:
>> Backwards Compatibility
>> There's a lot of time been invested in tutorials, interfaces, macros and
>> objects.
>> Much of the written information out on the Internet (including the years
>> of newsgroup postings) doesn't specify which version it relates to, so
>> if this material is rendered largely redundant it's probably going to be
>> wise to totally change the product name. Otherwise there's a risk of
>> years of confusion that may create difficult barriers to new users.
>
> I doubt a product name change is necessary. However, it should be made
> clear all over the place (docs, Web site, etc) that the latest Pov will
> break compatibility with anything before v4.

When you say "all over the place" you may be able to access a few sites, but
when newbies do a Google and discover thousands of sites containing
materials most of which just inexplicably don't work and can't readily be
made to work then it's likely to have a very negative effect on their
impression of the software.

> I personally don't think there's a great need to maintain backward
> compatibility as far as syntax/code goes. I think the hope is that the
> new SDL will provide "nicer"/"better" ways to do stuff than the old SDL
> - and so we wouldn't want people being hampered by tutorials from the
> past - but force them to learn the new way of thinking.

Well yes. Hope springs eternal :-) But reality depends upon people who hope
that they will show an aptitude for developing a fantastic new computer
language (when they've probably never done that before) realising their
particular dreams in a way that other people can stomach.

> One possibility is to try to find lots of good tutorials, put them onto
> the Wiki (if permission can be acquired), and before POV4 is released,
> update the tutorials to show how to get each effect using POV4.

As one of the few who has added stuff to the Wiki I can testify to how
quickly that sort of thing falls onto the shoulders of a very small number
of people. The amount of such work that can be realistically completed is
invariably tiny compared with initial expectations.

In this case there are some very practical problems with this as it would
require people with a reasonable knowledge of the old SDL and a good
knowledge of how the future SDL would best achieve the same results. Doing
this before the code is finished might require a disproportionately high 
number
of genius level experts.

Also, this misses the point a bit in that you can create up-to-date 
tutorials
but they'll be competing for prominance in Google with a greater number of
better established, but out of date tutorials that don't contain any 
indication
that they may be out of date.

Regards,
Chris B.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote in message 
news:49ce0c87@news.povray.org...

> Well yes. Hope springs eternal :-) But reality depends upon people who 
> hope
> that they will show an aptitude for developing a fantastic new computer
> language (when they've probably never done that before) realising their
> particular dreams in a way that other people can stomach.
>

No offense intended :-)

Regards,
Chris B.

Post a reply to this message

nemesis <nam### [at] nospam-gmailcom> wrote:
> Funnily enough, and except for the syntatic abstraction, my example
> dealt only with function definition and function application.  I thought
> those concepts were flying around for ages now.
>
> well, ok, functions returning functions is not generally mainstream...

Nor is functional programming in general.

Sure, Pascal has functions. Basic has functions. In C, the whole program is
comprised of functions, and the methods omnipresent in its heirs like C++ and
Java can be seen as another flavor of the same thing.

But if you look closer at these languages, you will find that those functions
are still both defined and used in an imperative fashion. (And all of these
languages actually have not only functions, but also procedures, that don't
return a value at all but just cause side effects. Even C has "functions" that
return "void", i.e. nothing.) It's only recently that design patterns borrowed
from functional programming are gaining popularity.

> Scheme is often taught in first year compsci courses because of its
> simplicity:  function definition and function application is all there
> really is to it, predefined syntatic details is minimal.  So, I feel
> astonished when people find it overwhelming.

Maybe it's a bit like Go: The rules are mind-boggingly simple. But winning a
game of Go takes more than knowing the rules.

And first years compsci courses are given to people who have time to dig into
new concepts. Many programmers I know don't come from a compsci background. And
you don't learn functional programming in places where there's work to do. Not
typically, at least.

> That said, I wasn't *seriously* proposing Scheme for povray's scripting
> language in the first place

I never really assumed you were ;)

Post a reply to this message