 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ilya Razmanov <ily### [at] gmail com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> 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.
Aye, lad. But we're talking about POV-Ray 4.0, dontchaknow.
Let's cast off the shackles of "backward compatibility" and do something NEW!
It's not like the old versions will be deleted from the fabric of reality.
> 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{...}
> }
I do it just to make jr twitch to the verge of seizures.
Other times I simply do things because I think they're a CAPITAL IDEA.
I think the real value of opening and terminating symbols is their utility for
future delinters and debuggers.
I have already expressed my support for MORE different kinds of brackets and
parentheses, as well as #endif, #endwhile, #endfor, #endmacro, etc.
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > ...it could break all of our
> > old scenes, going back decades.
>
> Aye, lad. But we're talking about POV-Ray 4.0, dontchaknow.
> Let's cast off the shackles of "backward compatibility" and do something NEW!
>
> It's not like the old versions will be deleted from the fabric of reality.
>
A new(?) language with new syntax rules. Arrggghh. I have enough trouble trying
to understand the NEW remote control for my recently-installed NEW AND
IMPROVED(?) cable-TV box. :-[
> > 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 other words, code-writing in POV has always been more 'relaxed' and not so
exacting; no need to worry about spaces or tabs... which I like to use liberally
:-) Of course, others might complain that this 'feature' produces a LESS
structured/exacting environment, in the context of other languages. But it sure
makes code-writing easier, in my humble opinion.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
camera:
location<0, 2, -15>
lookat<0, 0, 0>
up<0, 1, 0>
fov<60>
light:
location<500, 100, -50>
color<1, 1, 1>
intensity<1.0>
object:
sphere:
center<0, 0, 0>
radius<1>
material:
texture:
color<1, 0, 0>
reflectivity<0.2>
object:
plane:
normal<0, 1, 0>
distance<-1>
material:
texture:
color<0.2, 0.8, 0.2>
reflectivity<0.1>
;)
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" <nomail@nomail> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> camera:
> location<0, 2, -15>
> lookat<0, 0, 0>
> up<0, 1, 0>
> fov<60>
>
> light:
> location<500, 100, -50>
> color<1, 1, 1>
> intensity<1.0>
>
> object:
> sphere:
> center<0, 0, 0>
> radius<1>
> material:
> texture:
> color<1, 0, 0>
> reflectivity<0.2>
>
> object:
> plane:
> normal<0, 1, 0>
> distance<-1>
> material:
> texture:
> color<0.2, 0.8, 0.2>
> reflectivity<0.1>
>
> ;)
>
> ingo
In python you can only have tab sized (4 spaces) indents like this, which looks
more tidy/less error prone (though I understand people would like more
flexibility and perhaps more compact concision) :
camera:
location<0, 2, -15>
lookat<0, 0, 0>
up<0, 1, 0>
fov<60>
light:
location<500, 100, -50>
color<1, 1, 1>
intensity<1.0>
object:
sphere:
center<0, 0, 0>
radius<1>
material:
texture:
color<1, 0, 0>
reflectivity<0.2>
object:
plane:
normal<0, 1, 0>
distance<-1>
material:
texture:
color<0.2, 0.8, 0.2>
reflectivity<0.1>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mr" <m******r******at_hotmail_dot_fr> wrote:
>...
> In python you can only have tab sized (4 spaces) indents like this, which looks
> more tidy/less error prone (though I understand people would like more
> flexibility and perhaps more compact concision) :
>...
> object:
> sphere:
> center<0, 0, 0>
> radius<1>
> material:
> texture:
> color<1, 0, 0>
> reflectivity<0.2>
>...
Hi Mr
Python allows 1 or more extra leading spaces for each indentation level.
So you can actually write code like this:
for x in range(10):
for y in range(10):
for z in range(10):
print(f'<{x}, {y}, {z}>')
if (x % 2) == 1:
print('---------')
what is recommended in pep8 is another matter:
https://peps.python.org/pep-0008/#indentation
And BTW: Tabs are evil!
--
Tor Olav
http://subcube.com
https://github.com/t-o-k
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mr" <m******r******at_hotmail_dot_fr> wrote:
> In python you can only have tab sized (4 spaces) indents like this[...]
in addition to Tor Olav's evil tabs, a tab is just a '\t' symbol like a '\n' or
'\r'. You can tell your editor to use any tab size >0 you like. Python just
looks at the '\t' not at what your editor thinks how wide a tab is.
But that's not all, Python also looks at spaces for indentation. The mixing of
tabs and spaces is what makes things messy. Something that easily happens when
copying code. So set your editor to always convert tabs to spaces, the length is
up to your preference.
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tor and Ingo, You are right ! I had even forgotten about those eventualities
since the guiding principle in Python for me has indeed become the PEP (with
quite some personal choice for when to apply it or not :-D ! It's so much
enforced by all collective projects however (git repo settings play a role in
this too)... and also luckily the auto formatting tools such as Black/Snake8/
etc, That I forgot I may have taken different habits if I had kept learning
python by myself all along. It works well once you have used some of this at
least once... but before, it's true the language does have room for shooting
yourself in the foot. All this makes me think of another Idea then :
What if POV 4 was not developed as a version of the language itself but rather
as only a couple of new features, and a formatting tool such as black ?
Would everyone around here also frown at this?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
