Ilya Razmanov <ily### [at] gmailcom> wrote:

> ...and those newcomers will quickly find themselves producing mixed
> syntaxis, then trying to understand what the heck is this.

As I use Nim, I agree with this aspect very much. I chose Nim because it looks
like Python, but it is nothing like it. It takes a while to forget Python, but
then it's all fine.

For the rest of it, a well designed language should need "no" tooling. Imagine
that all books where printed colour coded, verbs in green etc. And then users
start to nag that it should be printed in dark mode .... Colour does not matter
for me as I mostly have set Windows to greyscale, Ctrl+win+C.

What Python has shown is that readability counts and that there is very little
need for line noise, arrows, squiggles and what not. In some aspects Nim takes
it even further. And the they broke it with the @ and type stuff in python and
{.pragmas.} in Nim.

POV-Ray has a lot of '#', I never liked that, nor the constant need to
#declare/#local. In Nim and probably others too, that is solved in an elegant
way :

var
  chicken ...
  swan ...
  duck ...

Post a reply to this message

hi,

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> I'm sure more expert people in various languages will be able to teach me
> something important from what is probably a naive question :  What if in POV 4
> we had the possibility to use spaces or tabs as a synonym to what curly braces
> currently do, but we could still use those braces themselves ?

I'd be interested to learn what (tangible) gain(s) you see in that.


> That way new comers would feel at first glance that the language is as easy to
> learn as Python, and would rapidly understand as they do in Python, that what
> matters is that they do know what scope they're in.

right, and Icelanders and Germans could simply switch to English :-).


>
> and eventually, depending on *whichever* option gets to become the most popular
> among core developers and power users, it can become a maintenance cost
> reduction to drop one or the other?
>
> Inspiration for this idea? of course, python... I love how it has grown able to
> do type annotations, switch cases, etc. and while across versions leverage many
> advanced concepts teaching them to me as it went, and now they are there, I love
> how a new comer could still pick it up exactly the way I did, with a human
> readable almost fiction-book like syntax, and still produce scripts that do
> work, syntactic-sugar-free.  BUT I know there must be a reason why those curly
> braces are still there isn't there? so I trust people to tell me... maybe so
> that POV acts as a launching pad to learn C-like languages in which it is itself
> developed?

I'd like to see you post a bit of "mocked up" scene code to illustrate the
benefits; I guess you'd like something like 'union box 0 1 sphere 0 .5 ' ?

fwiw, even _if_ I thought Python a good language I'd endorse Ilya's view:
"...and those newcomers will quickly find themselves producing mixed syntaxis,
then trying to understand what the heck is this."


regards, jr.

Post a reply to this message

On 18/03/2025 10:00, Ilya Razmanov wrote:

> ...and those newcomers will quickly find themselves producing mixed 
> syntaxis, then trying to understand what the heck is this.
> 
> And, frankly, I don't see anything good about Python identation. To me 
> it only takes more screen space than necessary, produce weird linewraps 
> on display, and so on. I believe everything one need to control brackets 
> and braces of all kinds it syntax highlight, and, ideally, a linter. 
> Well, we already have a POV extension for VSCode, it's not perfect but I 
> think it's a way to go, it would be definitely better than spending time 
> for creating new POV editor. So we may get syntax highlight and stuff 
> this way. What as to linter and stuff like that, that's a different 
> story and more complicated one.
> 
              ____
     .__     /_   |
   __|  |___  |   |
  /__    __/  |   |
     |__|     |___|



Nothing good about pyhton.
Definitely bad language.



After that, of course, everyone has their own preferences and affinities.





-- 
kurtz le pirate
compagnie de la banquise

Post a reply to this message

Le 2025-03-18 à 04:01, Mr a écrit :
> I'm sure more expert people in various languages will be able to teach me
> something important from what is probably a naive question :  What if in POV 4
> we had the possibility to use spaces or tabs as a synonym to what curly braces
> currently do, but we could still use those braces themselves ?
>

That would be a pretty BAD idea. It'll make the code uselessly hard to 
understand, introduce a LOT of ambiguity. That can only lead to code 
that is nearly to totally impossible to debug.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> I'd like to see you post a bit of "mocked up" scene code to illustrate the
> benefits; I guess you'd like something like 'union box 0 1 sphere 0 .5 ' ?

clipka once proposed a YAML like structure. I didn't like that at all, fun
thing, many macro generated DSL's made in Nim use that kind of syntax.

ingo

Post a reply to this message

On 18.03.2025 13:54, ingo wrote:

> For the rest of it, a well designed language should need "no" tooling.
And it should look like obscene Russian, for my convenience. That means 
it must be flexible and extendable beyond any recognition.

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

On 18.03.2025 20:07, kurtz le pirate wrote:
> Nothing good about pyhton.
> Definitely bad language.

Well, I'm not considering it especially bad, and even use it for my 
POV-Ray scene creating stuff. But I'm not considering it extremely good 
and easy either, and all this indentation stuff is definitely not what I 
like, specifically. After all, if you take a look at my Python-based 
img2mesh POV export stuff, you'll see something like:

resultfile.write(f'\n    triangle {{<{x_out(x, 0)}, {y_out(y, 0)}, 
map({v1})> <{x_out(x, 1)}, {y_out(y, 0)}, map({v2})> <{x_out(x, 0.5)}, 
{y_out(y, 0.5)}, map({v0})>}}')

and don't tell me it is low on braces ;-)

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

Ilya Razmanov <ily### [at] gmailcom> wrote:
> On 18.03.2025 20:07, kurtz le pirate wrote:
> > Nothing good about pyhton.
> > Definitely bad language.
>
> Well, I'm not considering it especially bad, and even use it for my
> POV-Ray scene creating stuff. But I'm not considering it extremely good
> and easy either, and all this indentation stuff is definitely not what I
> like, specifically. After all, if you take a look at my Python-based
> img2mesh POV export stuff, you'll see something like:
>
> resultfile.write(f'\n    triangle {{<{x_out(x, 0)}, {y_out(y, 0)},
> map({v1})> <{x_out(x, 1)}, {y_out(y, 0)}, map({v2})> <{x_out(x, 0.5)},
> {y_out(y, 0.5)}, map({v0})>}}')
>
> and don't tell me it is low on braces ;-)
>
> --
> Ilyich the Toad
> https://dnyarri.github.io/

As I mentioned Python does have an obscure syntax for the advanced features
indeed the @, etc...  I was referring only to entry level first scripts that one
can do on day one, and dictionaries (Python's curly brace use) are not necessary
for these first baby steps. This makes it a language you can teach to kids...
not as much as scratch of course, so maybe David Buck's project is the way to go
for that.
(https://www.kickstarter.com/projects/pigeontalk/pigeontalk-a-programming-environment-to-explore-computing)

Back on topic, I'm honestly surprised by the hate for space based indentation
here ! I thought, given they are doing exactly what these curly braces do in a
less forgiving but in what subjectively appears to me to be a more pleasing and
print-friendly look. they would not be that despised... I was wrong apparently.

But to me current curly braces feel almost like the python @ or the "morse"
operator
:=  somewhat rough ... Would anyone have any other suggestions than these {...}
then?


"ingo" <nomail@nomail> wrote:
> Ilya Razmanov <ily### [at] gmailcom> wrote:
>
> > ...and those newcomers will quickly find themselves producing mixed
> > syntaxis, then trying to understand what the heck is this.

When thinking of people who learn programming, I assumed a first time user tends
to pick one alternative, not burden with mixing two options for one meaning,
where you are right is that the copy pasting practice would make it very hard to
keep things not mixed. unless a parsing warning maybe could reduce the
inconvenience.

> What Python has shown is that readability counts and that there is very little
> need for line noise, arrows, squiggles and what not. In some aspects Nim takes
> it even further. And the they broke it with the @ and type stuff in python and
> {.pragmas.} in Nim.
>
> POV-Ray has a lot of '#', I never liked that, nor the constant need to
> #declare/#local. In Nim and probably others too, that is solved in an elegant
> way :
>
> var
>   chicken ...
>   swan ...
>   duck ...

I, too, find '#',  ugly, And I also especially dislike having to type "end" for
anything... I wouldn't mind that much typing var before listing several
variables together but before any one of them seems tedious. Also is anything
wrong in declaring a variable without saying its a variable? using equal sign or
column. (I'm not referring to type here which is another issue, just the
"declare" or "var" keyword... I don't see why it's important.

Post a reply to this message

"Mr" <m******r******at_hotmail_dot_fr> wrote:
>I'm not referring to type here which is another issue, just the
> "declare" or "var" keyword... I don't see why it's important.

A "big" difference is that in POV-Ray you have to tell a variable whether it is
local or not. In many languages this is different. Every variable declared
inside a block is local and it can't escape that block.

So in Nim:

var chicken = 1

for i in 0 ..< 10:
  let n = i + i
  chicken += n

echo chicken
echo n # fails compilation, Error: undeclared identifier: 'n'

it fails not because it is let (immutable), but because it's local.

There is quite a body of research on what a good beginners language should look
like. Python scores very high on these. One aspect in several of these
researches made me chuckle, as I had the same problem decades ago. It is hard to
grasp 'while' and 'for' loops (Warp wrote a tutorial on it). Using the keyword
'every 'makes it more understandable for novices. Another hard one is OOP except
for the composition of records/objects.

The main problem in POV-Ray is that there are two aspects to it, the 'scripting'
part and the 'objects' part and that is actually well done. Compare it with the
javascript 3D stuff, or Vapory https://github.com/Zulko/vapory . If one would
repurpose an existing language for POV-Ray SDL then look for a language with
extensive macro abilities to build a DSL so one can have a distinct render
object sections an distinct script/code sections, similar to POV-Ray now.

ingo

Post a reply to this message

"Mr" <m******r******at_hotmail_dot_fr> wrote:
>
> What if in POV 4
> we had the possibility to use spaces or tabs as a synonym to what curly braces
> currently do, but we could still use those braces themselves ?
>

If spaces and tabs were to suddenly have real meaning in POV 4, and depending on
how we each write POV code-- the layout of the text-- it could break all of our
old scenes, going back decades.

For example, I personally write code with tabbed indents, just to make the
various constructs clear in my mind. Like...

sphere{0,1
     texture{
          pigment{rgb 1}
          finish{...}
            }
     normal{...}
      }

This is especially helpful to me in very complex scenes. (Others here probably
have their own ways of writing such stuff.)

If those tabs or spaces were to take on a syntactical importance going forward,
it would wreak havoc with old scenes. Chaos! :-(

Personally, I have always liked the fact that POV-ray's SDL syntax did not
impose any meaning on tabs or spaces; it would have been one more 'layer of
abstraction' to add to the learning of the syntax, in my opinion. I am not a
'programmer' in the strict sense, though, so I don't know how other languages'
syntax rules make it easier or harder for beginners to learn those languages.
POV's syntax 'made sense' to me from the get-go.

Post a reply to this message