Python o JavaScript?

[Mario Alexandro Santini]

Ciao a tutti,

mi sono appena imbattuto in questo progetto che fonde Python con JavaScript:

https://github.com/Distributive-Network/PythonMonkey

In pratica, se ho capito bene, si possono lanciare script JavaScript dalla vm Python, utilizzando il motore SpiderMonkey.

La posto come una curiosità, perché non utilizzo molto Python e non riesco ad immaginarmi uno scenario in cui qualcuno possa avere questa necessità.

Forse uno, quando un povero sviluppatore Python viene assegnato ad un progetto Node.js e rimane l'ultimo e unico sviluppatore attivo...

:)

Ma vi lancio la domanda: che cosa ne pensate dei progetti multi linguaggio?

Mario

[Chris Mair]

> Forse uno, quando un povero sviluppatore Python viene assegnato ad un progetto Node.js e rimane l'ultimo e unico sviluppatore attivo...
> :)

O viceversa :)

> Ma vi lancio la domanda: che cosa ne pensate dei progetti multi linguaggio?

Sinceramente l'unico use case che potrei immaginare e` che assolutamente
vuoi utilizzare una libreria popolare che esiste solo per l'altro linguaggio?

Altrimenti mi sembrerebbe piu` facile semplicemente mettere insieme script
in lingue diverse che comunicano via rete / database condiviso / IPC o cosa
mai.

Mi sfugge la necessita` di mescolare i linguaggi a livello dei singoli statement...

Bye,
Chris.

[Mario Alexandro Santini]

On Thu, Apr 18, 2024 at 11:46 AM 'Chris Mair' via Socraten <socr...@googlegroups.com> wrote:

Altrimenti mi sembrerebbe piu` facile semplicemente mettere insieme script
in lingue diverse che comunicano via rete / database condiviso / IPC o cosa
mai.

Ciao Chris,

concordo.

Ho lavorato in molti progetti multilinguaggio, anche il mioprogetto attuale lo è:

Julia,

Golang,

Python,

Rust,

TypeScript

... e bash scripts

:)

Ma ognuno viene utilizzato in un ben determinato contesto, ovvero un modulo o microservizio.

 

Mi sfugge la necessita` di mescolare i linguaggi a livello dei singoli statement...

Anche io faccio fatica a pensare ad uno scenario del genere.

In passato abbiamo messo assieme Rust + Python.

Rust ha un crate che permette di eseguire un interprete Python.

Il business case era quello di eseguire delle regole che venivano definite dall'utente del sistema e che potevano essere modificate a runtime.

Per questo era necessario utilizzare un qualche linguaggio di scripting come il Python.

Ma usare un interprete Python per eseguire anche altri linguaggi di scritping assieme.... 

C'è anche il progetto Java graal polyglot https://www.graalvm.org/latest/reference-manual/polyglot-programming/

 

Bye,
Chris.

Mario

[Guido Brugnara]

Il 18/04/24 11:27, Mario Alexandro Santini ha scritto:

Ciao a tutti,

mi sono appena imbattuto in questo progetto che fonde Python con JavaScript:

https://github.com/Distributive-Network/PythonMonkey

In pratica, se ho capito bene, si possono lanciare script JavaScript dalla vm Python, utilizzando il motore SpiderMonkey.

La posto come una curiosità, perché non utilizzo molto Python e non riesco ad immaginarmi uno scenario in cui qualcuno possa avere questa necessità.

A me è capitato di dover usare Java da una applicazione Perl in quanto le API non le trovavo disponibili in altri linguaggi o usare Inline::C  per le performance.

Nel caso in oggetto potrebbe essere usato, ad esempio, per usare lo stesso codice JS di validazione lato WEB e nel backend sviluppato in Python.

bye
gdo

Forse uno, quando un povero sviluppatore Python viene assegnato ad un progetto Node.js e rimane l'ultimo e unico sviluppatore attivo...

:)

Ma vi lancio la domanda: che cosa ne pensate dei progetti multi linguaggio?

Mario

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Socraten" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a socraten+u...@googlegroups.com.
Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/socraten/CAMUoZecJVXs-qWEOGc2pQDxUCpJ3YqwDoc6%2BSLp2fRhLF9hC%3DQ%40mail.gmail.com.

[Luca Guadagnini]

Ciao!

Non ho simpatia per i progetti multi linguaggio :D soprattutto quando vengono inseriti senza troppa cognizione di cause, ma solo perché potrebbe essere interessante usare X. Poi nasce il debito tecnico di volerlo rimuovere, perché alla fine si poteva fare lo stesso con i linguaggi o il linguaggio che si conosceva già.

Inoltre c'è poi il problema dell'on-boarding del nuovo sviluppatore di turno, come fai a introdurlo ogni volta a n linguaggi differenti? Già deve imparare il funzionamento dell'ecosistema costruito e in più deve spaccarsi la testa per imparare n linguaggi che possono essere molto differenti nella loro natura (statici, dinamici, compilati, interpretati, funzionali, ad oggetti, imperativi, ...).

A me pare poco funzionale.

Ma a parte questo, la libreria da te mostrata mi pare che sia una di quelle situazioni in cui esiste qualche sistema di plugin, e tali plugin si possono scrivere in un linguaggio diverso da quello dell'applicativo principale. Di esempi così ce ne sono a bizzeffe, se non ricordo male Andrea Selva, che lavora su ElasticSearch, mantiene la parte di plugin sviluppati in JRuby.

On Thu, 18 Apr 2024 at 12:32, Mario Alexandro Santini <alexm...@gmail.com> wrote:

On Thu, Apr 18, 2024 at 11:46 AM 'Chris Mair' via Socraten <socr...@googlegroups.com> wrote:

Altrimenti mi sembrerebbe piu` facile semplicemente mettere insieme script
in lingue diverse che comunicano via rete / database condiviso / IPC o cosa
mai.

Ciao Chris,

concordo.

Ho lavorato in molti progetti multilinguaggio, anche il mioprogetto attuale lo è:

Julia,

Golang,

Python,

Rust,

TypeScript

... e bash scripts

:)

Questo non è un progetto, è l'idra mitologica, 5 linguaggi di programmazione perché? (tralascio bash)

Il carico cognitivo e lo shift mentale che devi fare ogni volta non mi sembra così salubre. Ovviamente pensare di allineare a meno linguaggi è infattibile immagino. 

Ma ognuno viene utilizzato in un ben determinato contesto, ovvero un modulo o microservizio.

A me sfugge ancora la necessità. I linguaggi che hai elencato, sono ben supportati che non credo che abbiano bisogno di vicendevole supporto per fare una qualsiasi operazione «da microservizio». Anche nel caso di data science, Python non ha bisogno di Julia presumo.

 

 

Mi sfugge la necessita` di mescolare i linguaggi a livello dei singoli statement...

Anche io faccio fatica a pensare ad uno scenario del genere.

In passato abbiamo messo assieme Rust + Python.

Rust ha un crate che permette di eseguire un interprete Python.

Il business case era quello di eseguire delle regole che venivano definite dall'utente del sistema e che potevano essere modificate a runtime.

Per questo era necessario utilizzare un qualche linguaggio di scripting come il Python.

Ma usare un interprete Python per eseguire anche altri linguaggi di scritping assieme.... 

Io credo che sia lo stesso discorso dei plugin, c'è solo l'incredibile consumo di memoria e computazione da considerare... usare Python, un linguaggio interpretato per interpretare un altro linguaggio interpretato come Javascript...

 

C'è anche il progetto Java graal polyglot https://www.graalvm.org/latest/reference-manual/polyglot-programming/

 

In questo caso usufruisce anche della compilazione nativa per usare altre librerie che non sono presenti magari in Java, oltre a un possibile utilizzo di linguaggi di scripting per inventarsi un sistema di plugin.

 

Bye,
Chris.

Mario

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Socraten" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a socraten+u...@googlegroups.com.

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/socraten/CAMUoZeeE84FLYxqFQjC2kdYTFdbKvhgSHEJjukHpzB2Yd%3D-wig%40mail.gmail.com.

[Mario Alexandro Santini]

On 4/18/24 23:35, Luca Guadagnini wrote:

Ciao!

Ciao Luca,

Non ho simpatia per i progetti multi linguaggio :D soprattutto quando vengono inseriti senza troppa cognizione di cause, ma solo perché potrebbe essere interessante usare X. Poi nasce il debito tecnico di volerlo rimuovere, perché alla fine si poteva fare lo stesso con i linguaggi o il linguaggio che si conosceva già.

Inoltre c'è poi il problema dell'on-boarding del nuovo sviluppatore di turno, come fai a introdurlo ogni volta a n linguaggi differenti? Già deve imparare il funzionamento dell'ecosistema costruito e in più deve spaccarsi la testa per imparare n linguaggi che possono essere molto differenti nella loro natura (statici, dinamici, compilati, interpretati, funzionali, ad oggetti, imperativi, ...).

A me pare poco funzionale.

Concordo. :)

Questo non è un progetto, è l'idra mitologica, 5 linguaggi di programmazione perché? (tralascio bash)

:)

Ci sono motivi di varia natura.

Golang -> è stato riciclato un servizio da un'altro progetto dismesso.

Rust -> scelto per le performance e si occupa della parte infrastrutturale.

Julia -> sostanzialmente calcoli milioni di calcoli....

Python / bash -> automazione, configurazione e altri job periodici

TypeScript -> parte web, forse era superfluo, ma ci sarebbe comunque stato JavaScript :)

Il carico cognitivo e lo shift mentale che devi fare ogni volta non mi sembra così salubre. Ovviamente pensare di allineare a meno linguaggi è infattibile immagino. 

Non c'è alcun carico cognitivo, visto che i linguaggi sono utilizzati in domini differenti e le persone che lavorano su un linguaggio non usano gli altri.

Tranne me, che mi occupo della parte web, ma per noi del front-end usare un linguaggio solo è un utopia...

Ad esempio io uso Rust quando devo fare qualche utility da linea di comando, e anche se devo fare qualche servizio web minimale al di fuori dell'ambiente di produzione (se non adotta già Rust).

Potrei usare Node.js con JavaScript, ma con Rust ho il vantaggio mi porto dietro solo un binario.

A me sfugge ancora la necessità. I linguaggi che hai elencato, sono ben supportati che non credo che abbiano bisogno di vicendevole supporto per fare una qualsiasi operazione «da microservizio». Anche nel caso di data science, Python non ha bisogno di Julia presumo.

Già, Python è forte, soprattutto con Pandas, ma purtroppo, per il nostro caso d'uso non scala a sufficienza.

Ecco perché lo abbiamo rimosso ed abbiamo scelto Julia.

Poi abbiamo delle piccole parti in Python, perché lo si usa anche come linguaggio per l'automazione e per creare dei task periodici di varia natura.

In un progetto che lavora a microservizi, è difficile mantenere lo stesso linguaggio, perché nell'evoluzione del sistema, dipende da chi si occupa di sviluppare il servizio, che può essere qualcuno che arriva ora, che non conosce gli altri linguaggi usati.

Ad esempio, le web app, che faccio solo io, uso TypeScript + Vue 3 + Vuetify dappertutto, abbiamo 4 diverse webapp.

Altri progetti, dove la parte front-end è sviluppata da fornitori, hanno situazioni differenti, c'è un progetto con una 30ina di app che contiene app in AngularJS, Vue 2, React, Angular 12 >, jQuery...

Perché in un ambiente simile, non riesci ad imporre una tecnologia, visto che la gente cambia, che le cose si fanno nell'arco di anni, e intendo decenni.

Mario

[Luca Guadagnini]

Tutto più chiaro, contento che qualcuno faccia presente che Python non scala :D

Mica male 30 webapp fatte con n framework Javascript diversi, un giorno arriverà il tristo mietitore a reclamare le anime di quegli sviluppatori che hanno reso la nostra vita un delirio nel momento in cui dovevamo scegliere una framework solo per mettere un bottone sullo schermo.

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "Socraten" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a socraten+u...@googlegroups.com.

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/socraten/6eef48b1-e4ad-446a-9b61-a6a40c570942%40gmail.com.

[Mario Alexandro Santini]

On Fri, Apr 26, 2024 at 3:36 PM Luca Guadagnini <luca.gu...@gmail.com> wrote:

Tutto più chiaro, contento che qualcuno faccia presente che Python non scala :D

:)

 

Mica male 30 webapp fatte con n framework Javascript diversi, un giorno arriverà il tristo mietitore a reclamare le anime di quegli sviluppatori che hanno reso la nostra vita un delirio nel momento in cui dovevamo scegliere una framework solo per mettere un bottone sullo schermo.

In realtà è la situazione normale nei sistemi a microservizi, dato che ogni microservizio è sviluppato, potenzialmente, da un team diverso ed ogni team utilizza lo stack tecnologico che conosce meglio.

Mario