Jump to content
You must now use your email address to sign in [click for more info] ×

Still no javascripting or python support in Photo???


Recommended Posts

3 minutes ago, CM0 said:

If they could pull off something like WASM integration, I think it would pay future dividends by bringing in a much larger ecosystem of integrations.

WASM reminds me of Rust hype, which reminds me of HTML hype which reminded me of Ruby hype which reminded me of thin client hype which reminded me of Lawn Mower Man hype for VR etc etc etc.

C is here to stay.

Forever.

And that's Ok.

-- Embedding Lua is also light, fast and easy.

end

On 11/12/2022 at 11:32 PM, IPv6 said:

Really hoping there will be possibility to work with curves and brushes at low level - add/edit/sample splines/nodes, peek into layers content, draw strokes with specific brush/settings, etc

this is what the "for" in "make plugins for Affinity products" means. ie API access.

Link to comment
Share on other sites

4 minutes ago, deeds said:

WASM reminds me of Rust hype, which reminds me of HTML hype which reminded me of Ruby hype which reminded me of thin client hype which reminded me of Lawn Mower Man hype for VR etc etc etc.

C is here to stay.

Forever.

And that's Ok.

-- Embedding Lua is also light, fast and easy.

end

So is Assembly, but the rest of the world has moved on to higher productivity languages with much lower cost of development while maintaining very high performance.  None of that is hype, but reality.

Link to comment
Share on other sites

3 minutes ago, CM0 said:

So is Assembly, but the rest of the world has moved on to higher productivity languages with much lower cost of development while maintaining very high performance.  None of that is hype, but reality.

Except games, audio, motion graphics, visual effects, 3D modelling apps and real time renderers, high performance charting, analysis and realtime trading software, embedded systems in just about everything, specialised equipment and just about everything else that cares about stability and cycles.

Link to comment
Share on other sites

16 minutes ago, deeds said:

C is here to stay.

Forever.

And that's Ok.

So is cyanide, but I don't recommend consuming it.

I also remember the old Apple slogan "Apple II Forever" (referring to the line of computers which predated the Mac) - so where is it now?

Link to comment
Share on other sites

3 minutes ago, fde101 said:

So is cyanide, but I don't recommend consuming it.

I also remember the old Apple slogan "Apple II Forever" (referring to the line of computers which predated the Mac) - so where is it now?

C is much older than the Apple II, and also stands for Chomsky, who is much older!

Link to comment
Share on other sites

6 minutes ago, deeds said:

Except games, audio, motion graphics, visual effects, 3D modelling apps and real time renderers, high performance charting, analysis and realtime trading software, embedded systems in just about everything, specialised equipment and just about everything else that cares about stability and cycles.

Everything you mention is moving to newer tech.  Yes, much is still written in older tech, but that is not where the momentum is for good reason.

Link to comment
Share on other sites

2 minutes ago, CM0 said:

Everything you mention is moving to newer tech.  Yes, much is still written in older tech, but that is not where the momentum is for good reason.

And yet, just as always has occurred, they and many other endeavours revert to C whenever each new round of ambitious newness flails and/or fails to realise its claims.

Link to comment
Share on other sites

Just now, deeds said:

And yet, just as it always has, they and many other endeavours revert to C whenever each new round of ambitious newness flails and/or fails to realise its claims.

Most do not.  Even for the exceptions, it never justifies the cost of development of the entire platform in a low level language when only less than 1% will benefit.

Link to comment
Share on other sites

7 minutes ago, deeds said:

C is much older than the Apple II,

Actually only about five years older.  It is so terrible that there have been numerous attempts to replace it with corrected versions over the years, in languages like C++ and D, but they all share the same flawed foundation so they are always flawed themselves, giving people little incentive to switch from one bad language to another.

Most allegedly modern game engines are actually written in C++, not C.

Link to comment
Share on other sites

29 minutes ago, fde101 said:

Most allegedly modern game engines are actually written in C++, not C.

allegedly is the right word.

Most of them use a bare minimum of C++ objects, and actually code in C for all the crucial stuff, surfacing an object oriented API for ease of use and bridging/binding to any required/needed scripting languages.

The most important part of a game engine is the rendering which is all done in barely more than variations of C -  the shading "languages" for GPUs.

Link to comment
Share on other sites

39 minutes ago, CM0 said:

Most do not.  Even for the exceptions, it never justifies the cost of development of the entire platform in a low level language when only less than 1% will benefit.

Wait till you find out that Functional languages and most of the latest trends in ECS and DOD are merely really C-like usage of modern languages. And that this cycle has been gong on forever.

 

And that it usually costs less to just do it in C from the beginning. Whatever that is. 

Link to comment
Share on other sites

Lua, please.

Not JavaScript, and especially not Python.

Arrays, in Lua, start from 1. So it's easy for newer users to think in terms of Layer 1, Object 1, Effect 1, etc. 

If they ever get around to using arrays. 

Not that that's nearly a crucial reason to use Lua for scripting, but it is a nice extra, easy thing for direct relationships with software worlds of objects that don't begin at 0

The main reason to use Lua is that it's objectively the best of the lightest scripting languages with the easiest syntax to teach and preach, embeds incredibly easily and is familiar to anyone with a passing interest in Lightroom. And those coming up from Roblox.

And the tragics afflicted by World of Warcraft.

Link to comment
Share on other sites

1 minute ago, deeds said:

And that it usually costs less to just do it in C from the beginning. Whatever that is. 

Only in the short term, at the start of the project, when it is new.  Even then, not always.

In practice, once a solution is written, developers and others involved in the process spend far more time reading old code than writing new code.  The more cryptic languages based on C-like syntax cause errors not only in the code that was written, but also in people's interpretation of that code.

This makes it more difficult to maintain that code in the long term, resulting in more time being spent fixing bugs that often resulted from incorrect assumptions based on misreadings of what was previously there.

Languages such as Ada which promote making code more readable can significantly reduce the long-term cost of a project by making it easier to maintain with fewer bugs existing in the first place - fewer bugs means more hours spent creating new things rather than fixing all the issues with the old things.

 

 

 

Link to comment
Share on other sites

50 minutes ago, deeds said:

Wait till you find out that Functional languages and most of the latest trends in ECS and DOD are merely really C-like usage of modern languages. And that this cycle has been gong on forever.

 

And that it usually costs less to just do it in C from the beginning. Whatever that is. 

Doing most projects in C would be the most costly implementation compared to far better options available today.

Link to comment
Share on other sites

On 11/19/2022 at 2:48 AM, CM0 said:

Doing most projects in C would be the most costly implementation compared to far better options available today.

We aren't talking about most, though, are we. We're talking about accessing a performance critical API in a performance critical manner in a performance critical environment. In this scenario, and others wherein realities of performance and stability of performance are significant factors, this transition away from C to "easier" has yet to occur without significant compromises in... you guessed it.. performance, cost, stability and maintainability. This despite decades of this kind of mantra-ish advocation for "superior" approaches.

C is THE superior approach for that which C is most suited. Which this is. And it's simpler to use, too.

Learning to love pointers is a lifelong affair.

Link to comment
Share on other sites

40 minutes ago, deeds said:

this transition away from C to "easier" has yet to occur without significant compromises in... you guessed it.. performance, cost, stability and maintainability.

Precisely the opposite.  All these things have improved by orders of magnitude over C.  Even performance.

Take RipGrep as an example - https://blog.burntsushi.net/ripgrep/

Link to comment
Share on other sites

7 hours ago, deeds said:

Linux and Rust. What a combination. I can't wait for them to make something for end users. 

Since that is not a critique of any of your original value statements, I assume you have then accepted this counterpoint.  FWIW, it is also available on all platforms.

If you want an example of something more commonly used everyday, then the look to Servo and Stylo.  Servo was developed following game rendering engine architecture for the Mozilla browser used to render HTML and Stylo handles the CSS.  https://www.tomshardware.com/news/firefox-57-beta-project-quantum,35541.html

Link to comment
Share on other sites

  • 2 weeks later...

I love how these thread without exception end as a "this language is superior to that language"-situation. JK :D 

But seriously though, please give us some kind of api. Any will do. A horrible API is better than no API. Be it Python, Javascipt, C#, Cobol, Lolcode - anything, I'll take it. 

 

 

... also +1 for python :P 

Link to comment
Share on other sites

20 hours ago, herrkjeldsen said:

A horrible API is better than no API

Can not agree. Better to wait for something ok, than rush to horrible, because this will became a "legacy" in 2-3 months and.... serif never change "legacy" thingy. Any horribility will stay forever.

Horrible API == constant search for alternatives. And they will be around the corner, if the pressure remains

 

Link to comment
Share on other sites

  • 3 months later...
  • Staff

Readers of this topic may by interested in this post be the lead developer on scripting

https://forum.affinity.serif.com/index.php?/topic/64885-scripting/&do=findComment&comment=1067052

Patrick Connor
Serif Europe Ltd

"There is nothing noble in being superior to your fellow man. True nobility lies in being superior to your previous self."  W. L. Sheldon

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.