On 18.03.2025 11:01, Mr 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 ?
> 
> 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.

...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.

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

Post a reply to this message

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

So we may get syntax highlight and stuff

Was anyone aware that in the ini directory, there is a file named
"user-keywords.txt" ?


"
# user-defined keywords may be placed in this file
# these keywords do not affect parsing or SDL; they are only used by the editor
# for syntax highlighting and keyword completion (i.e. ctl-space or tab)
#
# the syntax is one keyword per line. spaces are not permitted within keywords
# (leading or trailing spaces are allowed but will be stripped). any line
containing
# more than one token will be ignored, as well any line starting with a '#'.
"

:O

(I haven't tried it yet)

Post a reply to this message

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