I think the usage of BASIC, BeanShell, and Python seems redundant and possibly old-fashioned because there is already one very popular scripting language: JavaScript. It's of course possible that Python has been added due to the availability of libraries while BASIC and BeanShell are possibly for historical reasons. However, I think a FOSS project can both take risks and lower costs. Therefore I think it could make sense to discard all the other languages and allow only JavaScript via QuickJS and use this initiative to: -support the migration of other ecosystems to be accessible via JavaScript -allow the development of a BI pipeline (a very important use case) with web appeal -discourage the growth of ecosystems in dynamic languages other than JS (unless it's necessary). The benefit of this might be less maintenance in the long term.
Further: It's not necessary to remove the support for existing languages but make them seem deprecated. E.g. by allowing new scripts in only JS.
You can fork LibreOffice and do there in your fork any manipulations around scripting language support. LibreOffice supports many programming languages for scripting and it works for many people in the World. I don't see any reasons for changing of current state in our project.
(In reply to Roman Kuznetsov from comment #2) > You can fork LibreOffice and do there in your fork any manipulations around > scripting language support. > > LibreOffice supports many programming languages for scripting and it works > for many people in the World. I don't see any reasons for changing of > current state in our project. So you suggest trialing the appeal of JS-only macros in an unofficial fork?
And yes it obviously may seem like it works for many people. Python does too, but there's also the side where development becomes much harder if there's a significant investment in a particular ecosystem that turns out to be limited. This is the case for Python in the context of BI, which is quite clearly very web-oriented. There are already also promising projects that attempt to migrate data science libraries to JS/TS. The question could then be about choosing between (informed) authoritative development vs user-led.
I don't know the state of Javascript support in LO but whatever it is, no need to deprecate Python cause it's still widely spread or Basic since it allows compatibility with VB from MsOffice. About Beanshell, I don't know if it's really used or not, I wouldn't be against its deprecation. About Javascript, I'm just a spectator of the race of the frameworks, reactJS, nodeJS, Angular, ... and wonder if this domain is mature enough or if we should wait more.
(In reply to Julien Nabet from comment #5) > I don't know the state of Javascript support in LO but whatever it is, no > need to deprecate Python cause it's still widely spread or Basic since it > allows compatibility with VB from MsOffice. About Beanshell, I don't know if > it's really used or not, I wouldn't be against its deprecation. > > About Javascript, I'm just a spectator of the race of the frameworks, > reactJS, nodeJS, Angular, ... and wonder if this domain is mature enough or > if we should wait more. These are valid concerns, but my arguments against them are: -There is some momentum to replace or support Python with JS/TS. For example, because JS/TS is syntactically nicer language (curly brackets etc.). -Having two fairly similar languages requires ~ double the support, but does it give double benefit? -It's not necessary to maintain compatibility with MS Office, and taking this goal limits the prospects of LO. It's then a choice between whether support for MS Office is a better goal than designing an independent office software.
(In reply to zuebgirl from comment #6) > (In reply to Julien Nabet from comment #5) > > I don't know the state of Javascript support in LO but whatever it is, no > > need to deprecate Python cause it's still widely spread or Basic since it > > allows compatibility with VB from MsOffice. About Beanshell, I don't know if > > it's really used or not, I wouldn't be against its deprecation. > > > > About Javascript, I'm just a spectator of the race of the frameworks, > > reactJS, nodeJS, Angular, ... and wonder if this domain is mature enough or > > if we should wait more. > > These are valid concerns, but my arguments against them are: > > -There is some momentum to replace or support Python with JS/TS. For > example, because JS/TS is syntactically nicer language (curly brackets etc.). I don't see any information about "momentum to replace or support Python" so could you add some refs? "syntactically nicer language" thanks to curly brackets, isn't it a bit subjective? Just a matter of taste for me. Personnally, I'm not against curly brackets, lots of languages use it (including C++ used for LO) but I appreciate the elegant way to make block just by indenting in Python. > -Having two fairly similar languages requires ~ double the support, but does > it give double benefit? For those who use Python, it's not a matter to double benefit or not, it's a matter to be able to program LO or not in Python so 0 or 1. > -It's not necessary to maintain compatibility with MS Office, and taking > this goal limits the prospects of LO. It's then a choice between whether > support for MS Office is a better goal than designing an independent office > software. Since LO wants to support docx, xlsx, etc. in addition to odt, ods, ... I suppose it's necessary. If it's not the case, it would mean to dump OOXML support completely since quite some people, above all in companies, use macros, so not sure LO people would be ok but I may be wrong.
(In reply to Julien Nabet from comment #7) > (In reply to zuebgirl from comment #6) > > (In reply to Julien Nabet from comment #5) > > > I don't know the state of Javascript support in LO but whatever it is, no > > > need to deprecate Python cause it's still widely spread or Basic since it > > > allows compatibility with VB from MsOffice. About Beanshell, I don't know if > > > it's really used or not, I wouldn't be against its deprecation. > > > > > > About Javascript, I'm just a spectator of the race of the frameworks, > > > reactJS, nodeJS, Angular, ... and wonder if this domain is mature enough or > > > if we should wait more. > > > > These are valid concerns, but my arguments against them are: > > > > -There is some momentum to replace or support Python with JS/TS. For > > example, because JS/TS is syntactically nicer language (curly brackets etc.). > > I don't see any information about "momentum to replace or support Python" so > could you add some refs? > "syntactically nicer language" thanks to curly brackets, isn't it a bit > subjective? Just a matter of taste for me. Personnally, I'm not against > curly brackets, lots of languages use it (including C++ used for LO) but I > appreciate the elegant way to make block just by indenting in Python. Consider for example: https://github.com/javascriptdata/scikit.js Then consider any of the opinion articles that you can find by searching for "typescript for data science" or similar. Finally, consider that the web browser is dominated by JS/TS. In the case of deploying to the web browser, people have used e.g. Flask for Python and a REST API. This is certainly less elegant than having the pipeline in a single language technology. The curly brackets etc. may make it easier to create advanced tools for the language. https://cjshaver.com/bl0172 > > -Having two fairly similar languages requires ~ double the support, but does > > it give double benefit? > > For those who use Python, it's not a matter to double benefit or not, it's a > matter to be able to program LO or not in Python so 0 or 1. https://xkcd.com/927/ > > -It's not necessary to maintain compatibility with MS Office, and taking > > this goal limits the prospects of LO. It's then a choice between whether > > support for MS Office is a better goal than designing an independent office > > software. > Since LO wants to support docx, xlsx, etc. in addition to odt, ods, ... I > suppose it's necessary. If it's not the case, it would mean to dump OOXML > support completely since quite some people, above all in companies, use > macros, so not sure LO people would be ok but I may be wrong. This could also motivate separate projects. For those that use only open formats, there's no need for MS Office compatibility.
Buovjaga can provide an up-to-date reference to the "let us use a better JS library" idea, which itself is fine, but not easy. But the idea that BASIC or Python support could be deprecated (let alone, dropped) is a no-go. Breaking infinite user documents, extensions, home-made or paid-for macros and other automation tools; breaking internal functionality that depends on e.g. Python (e.g., NumberText and its spell-number used in numbering)... As said, if you want to experiment with dropping them, you are free to fork it. Note that it doesn't men that you are advised to fork just to enhance JS support - these are orthogonal. INVALID.
One small addendum: the idea of zuebgirl could stem from the perception that support of different languages is costly for the project. No it is not; the architecture of the pluggable scripting machinery only requires a reasonably compact binding layer, allowing to use the internal published UNO API. The UNO API, used *universally*, is both the weak and the strong side of OOo/LO; and the cost of supporting the binding layers is acceptable. The xkcd reference and everything else is an elitist attitude, allowing OP to think they can disregard everyone else's needs who use the suite; and is like saying that every person on the planet must abandon their native language in favor of language X - just because it's similar to xkcd 927.
(In reply to Mike Kaganski from comment #10) > One small addendum: the idea of zuebgirl could stem from the perception that > support of different languages is costly for the project. No it is not; the > architecture of the pluggable scripting machinery only requires a reasonably > compact binding layer, allowing to use the internal published UNO API. The > UNO API, used *universally*, is both the weak and the strong side of OOo/LO; > and the cost of supporting the binding layers is acceptable. The xkcd > reference and everything else is an elitist attitude, allowing OP to think > they can disregard everyone else's needs who use the suite; and is like > saying that every person on the planet must abandon their native language in > favor of language X - just because it's similar to xkcd 927. Yes, but the added cost is seen, for example, in the ports that are attempted to JS/TS now. Fewer people are interested in them now when they can already use them from Python, regardless of what benefits there might be. The result is then two stagnated ecosystems.
(In reply to zuebgirl from comment #11) There is no benefit of JS over any other language, except when someone knows one better than another. Python is the *world's #1* programming language - see today's TIOBE index [1]; the idea that the project has a goal to force people to learn some other programming language *just because zuebgirl has an idea it has an abstract benefit* is another daydreaming. [1] https://www.tiobe.com/tiobe-index/
(In reply to Mike Kaganski from comment #12) > (In reply to zuebgirl from comment #11) > > There is no benefit of JS over any other language, except when someone knows > one better than another. Python is the *world's #1* programming language - > see today's TIOBE index [1]; the idea that the project has a goal to force > people to learn some other programming language *just because zuebgirl has > an idea it has an abstract benefit* is another daydreaming. > > [1] https://www.tiobe.com/tiobe-index/ But also, just because something is popular does not mean it's right or the best.
(In reply to zuebgirl from comment #13) > But also, just because something is popular does not mean it's right or the > best. Again: the LO project has *no* goal of *deciding* which programming language is "right" or "best"; the popularity tells the only one metric that matters for this project: the number of people who potentially can benefit from the support; it shows that dropping this support would make much harm (and there are other metrics telling about harm from dropping such support); and trying to force your idea on the project is trying to shift the project's goals, that are fixed and defined in the TDF legal statutes. I'm off of this useless discussion.
(In reply to Mike Kaganski from comment #14) > (In reply to zuebgirl from comment #13) > > But also, just because something is popular does not mean it's right or the > > best. > > Again: the LO project has *no* goal of *deciding* which programming language > is "right" or "best"; the popularity tells the only one metric that matters > for this project: the number of people who potentially can benefit from the > support; it shows that dropping this support would make much harm (and there > are other metrics telling about harm from dropping such support); and trying > to force your idea on the project is trying to shift the project's goals, > that are fixed and defined in the TDF legal statutes. > > I'm off of this useless discussion. Yes, so how will LO Calc implement a BI workflow with a front-end in the browser? Flask?
(In reply to zuebgirl from comment #15) > (In reply to Mike Kaganski from comment #14) > > (In reply to zuebgirl from comment #13) > > > But also, just because something is popular does not mean it's right or the > > > best. > > > > Again: the LO project has *no* goal of *deciding* which programming language > > is "right" or "best"; the popularity tells the only one metric that matters > > for this project: the number of people who potentially can benefit from the > > support; it shows that dropping this support would make much harm (and there > > are other metrics telling about harm from dropping such support); and trying > > to force your idea on the project is trying to shift the project's goals, > > that are fixed and defined in the TDF legal statutes. > > > > I'm off of this useless discussion. > > Yes, so how will LO Calc implement a BI workflow with a front-end in the > browser? Flask? Further, I've thought that the DOM model makes much more sense for LO applications than Python's generic abstractions.
(In reply to zuebgirl from comment #15) > ... > Yes, so how will LO Calc implement a BI workflow with a front-end in the > browser? Flask? LibreOffice is an Office Suite, not a BI software. Now you can (or pay someone) to create an extension. Now there are scripting possibilitiess which allow to automatize some actions (eg: file conversion from line command) but won't go further here since I'm not an expert.
(In reply to zuebgirl from comment #16) > ... > Further, I've thought that the DOM model makes much more sense for LO > applications than Python's generic abstractions. ??? LO is written in C++ at 95% at min, the rest is in C, Javsome assembly, Java, Objective C (for macOs part), Perl and I must forget some.
(In reply to Mike Kaganski from comment #12) > (In reply to zuebgirl from comment #11) > > There is no benefit of JS over any other language, except when someone knows > one better than another. Python is the *world's #1* programming language - > see today's TIOBE index [1]; the idea that the project has a goal to force > people to learn some other programming language *just because zuebgirl has > an idea it has an abstract benefit* is another daydreaming. > > [1] https://www.tiobe.com/tiobe-index/ There's also another such benchmark: https://survey.stackoverflow.co/2023/#technology-most-popular-technologies Here JS leads by about 30%.
(In reply to Julien Nabet from comment #18) > (In reply to zuebgirl from comment #16) > > ... > > Further, I've thought that the DOM model makes much more sense for LO > > applications than Python's generic abstractions. > ??? LO is written in C++ at 95% at min, the rest is in C, Java, some assembly, Objective C (for macOs part), Perl and I must forget some.
(In reply to zuebgirl from comment #19) > ... > There's also another such benchmark: > > https://survey.stackoverflow.co/2023/#technology-most-popular-technologies > > Here JS leads by about 30%. Whatever, it doesn't justify the fact to remove VB or Python knowing they're still quite used + already existing files (as Mike indicated). If you think something's lacking about Javascript binding, don't hesitate to contribute after reading https://wiki.documentfoundation.org/Development/GetInvolved. You can also try to submit a patch to remove Python or VB binding, but I'm pretty sure it'll be refused (and I would understand). So please, no need to insist here to remove VB or Python binding. They're far to be deprecated.
(In reply to Julien Nabet from comment #21) > (In reply to zuebgirl from comment #19) > > ... > > There's also another such benchmark: > > > > https://survey.stackoverflow.co/2023/#technology-most-popular-technologies > > > > Here JS leads by about 30%. > > Whatever, it doesn't justify the fact to remove VB or Python knowing they're > still quite used + already existing files (as Mike indicated). > > If you think something's lacking about Javascript binding, don't hesitate to > contribute after reading > https://wiki.documentfoundation.org/Development/GetInvolved. > You can also try to submit a patch to remove Python or VB binding, but I'm > pretty sure it'll be refused (and I would understand). > > So please, no need to insist here to remove VB or Python binding. They're > far to be deprecated. No one has still suggested removal, but suggesting that further additions to these technologies are unofficial and not recommended. Like they do in any other project when they think something is not worth supporting anymore.
(In reply to zuebgirl from comment #22) > ...No one has still suggested removal, but suggesting that further additions to > these technologies are unofficial and not recommended. Like they do in any > other project when they think something is not worth supporting anymore. You indicated in your initial description: "Therefore I think it could make sense to discard all the other languages and allow only JavaScript via QuickJS and use this initiative to" so you wanted clearly to keep only Javascript and remove all the other languages. Python is largely used so I don't understand why we would stop supporting it. VB is still the macro language for Microsoft so we can't stop supporting it. For the moment, only you consider it's not worth supporting these languages. It's getting quite boring this attitude of JS fanboy so again please stop about this.
(In reply to Julien Nabet from comment #23) > (In reply to zuebgirl from comment #22) > > ...No one has still suggested removal, but suggesting that further additions to > > these technologies are unofficial and not recommended. Like they do in any > > other project when they think something is not worth supporting anymore. > > You indicated in your initial description: > "Therefore I think it could make sense to discard all the other languages > and allow only JavaScript via QuickJS and use this initiative to" > > so you wanted clearly to keep only Javascript and remove all the other > languages. > > Python is largely used so I don't understand why we would stop supporting it. > VB is still the macro language for Microsoft so we can't stop supporting it. > For the moment, only you consider it's not worth supporting these languages. Well, surely it depends on how one wants to view it. I thought LO seemed like a project that has just enough scope for such trials, but not too much (not like Autodesk -scale). However, we may also see how e.g. Autodesk uses JS: https://help.autodesk.com/view/OARX/2023/ENU/?guid=adsk_jsdev_autocad_javascript_api_about
(In reply to zuebgirl from comment #24) > (In reply to Julien Nabet from comment #23) > > (In reply to zuebgirl from comment #22) > > > ...No one has still suggested removal, but suggesting that further additions to > > > these technologies are unofficial and not recommended. Like they do in any > > > other project when they think something is not worth supporting anymore. > > > > You indicated in your initial description: > > "Therefore I think it could make sense to discard all the other languages > > and allow only JavaScript via QuickJS and use this initiative to" > > > > so you wanted clearly to keep only Javascript and remove all the other > > languages. > > > > Python is largely used so I don't understand why we would stop supporting it. > > VB is still the macro language for Microsoft so we can't stop supporting it. > > For the moment, only you consider it's not worth supporting these languages. > > Well, surely it depends on how one wants to view it. I thought LO seemed > like a project that has just enough scope for such trials, but not too much > (not like Autodesk -scale). > > However, we may also see how e.g. Autodesk uses JS: > > https://help.autodesk.com/view/OARX/2023/ENU/ > ?guid=adsk_jsdev_autocad_javascript_api_about Ok don't hes(In reply to zuebgirl from comment #24) > (In reply to Julien Nabet from comment #23) > > (In reply to zuebgirl from comment #22) > > > ...No one has still suggested removal, but suggesting that further additions to > > > these technologies are unofficial and not recommended. Like they do in any > > > other project when they think something is not worth supporting anymore. > > > > You indicated in your initial description: > > "Therefore I think it could make sense to discard all the other languages > > and allow only JavaScript via QuickJS and use this initiative to" > > > > so you wanted clearly to keep only Javascript and remove all the other > > languages. > > > > Python is largely used so I don't understand why we would stop supporting it. > > VB is still the macro language for Microsoft so we can't stop supporting it. > > For the moment, only you consider it's not worth supporting these languages. > > Well, surely it depends on how one wants to view it. I thought LO seemed > like a project that has just enough scope for such trials, but not too much > (not like Autodesk -scale). > > However, we may also see how e.g. Autodesk uses JS: > > https://help.autodesk.com/view/OARX/2023/ENU/ > ?guid=adsk_jsdev_autocad_javascript_api_about Again, nothing against improving LO by adding some useful features, if you want to contribute, you're welcome! We're just against the fact to remove something which is widely used. Autodesk has an API about JS, ok great for them! Had they something about Python and they would have throw it just to keep JS? Concerning VB, Autodesk doesn't have to deal with MsOffice docs so they don't need to care about it. Please compare softwares which can really be compared, Autodesk is not an Office suite. You may compare with MsOffice, OnlyOffice, Calligra Suite. (I haven't taken a look about JS, Python, VB or any other language support for them)
(In reply to Julien Nabet from comment #25) Just FYI: https://help.autodesk.com/view/OARX/2024/ENU/?guid=GUID-E6429154-36DF-4D84-8ABC-9FCA15B66158 - it is funny to see someone appealing to Autodesk product language support (spoiler: for more than 10 years, I created scripts for AutoCAD, mostly using AutoLisp - but also other things, including C#; and I see that for some puzzling reason, they still haven't dropped support for it ;)) Anyway, this person just spams the topic, providing irrelevant comments, comparing well-known and recognized TIOBE to some "survey.stackoverflow.co" (was it a phishing attack after all? did someone look at that ".co"?), wasting time of people reading it and trying to answer...