[Python] .net e visual studio open source e versione community

[enrico franchi]

2015-01-22 11:20 GMT+00:00 Vincenzo Campanella <vinz65 a gmail.com>:

> Il 22.01.2015 11:39, enrico franchi ha scritto:
>
>> Dopo di che... non parlerei di codice "scritto in Visual C++".
>> Semplicemente se scrivi codice C++ *standard* che fa uso di una libreria
>> non presente su una certa piattaforma, beh, quel codice non potrai
>> compilarlo su quella piattaforma finche' non trovi quella piattaforma.
>>
>
> Sarò limitato io, ma non ho mai conosciuto sviluppatori che utilizzassero
> VC++ e scrivessero codice standard e cross platform; ho conosciuto
> sviluppatori che scrivono codice cross platform in C e C++, ma nessuno di
> loro usa VC++, che anzi aborriscono in quanto il codice che genera di
> default non è esattamente pulito (eufemismo), salvo quando devono scrivere
> del codice che sicuramente girerà solo su macchine Windows.
> Da qui la mia affermazione.
>

Che appunto e' strana, perche' mette insieme cose che non sono
necessariamente correlate.

Per esempio qui "aborrono VC++ in quanto il codice che genera non e'
pulito." Che voglio dire... e' un bel po' che si sa che usare wizard che
*generano* codice e' un approccio con enormi problemi e limiti (ma non e'
questione di VC++ e' proprio questione dell'approccio). Quindi stiamo
parlando dell'IDE. Ma prima usavi il termine per riferirti al linguaggio...
e nota bene, puoi scrivere software che compili con cl.exe che usa o non
usa tutto l'ambaradan di MFC o altra roba windows only usando o non usando
l'IDE.

Quindi capisci la confusione...

eravamo ancora ad:

"""
Intendo nel senso che il codice scritto in C/C++ può essere compilato, e
quindi eseguito, su qualsiasi sistema operativo abbia un compilatore per
quei linguaggi (parlo della totalità o quasi); naturalmente, da questo
discorso va escluso codice scritto in Visual C++.
""""

Ovviamente il problema non e' Visual C++ (inteso come IDE? adesso non
vorremo sostenere che sia il programma con cui scrivi a determinare la
portabilita' / inteso come "linguaggio"? come dicevo, non ha senso) sono
semplicemente le librerie su cui linki. Cioe' se linko ad inotify
probabilmente girero' solo su linux. E grazie (oh, poi magari hanno fatto
anche qualche port, non ho voglia di controllare ora, sostituire con una
qualunque libreria linux only)



> Io comunque VC++ non l'ho mai utilizzato (ho iniziato con C su
> CodeWarrior, bei tempi che furono...), per cui riferisco per sentito dire
> (cose cui comunque credo data la storica tendenza di M$ a cercare di creare
> e imporre degli standard tutti suoi, vedi per esempio la fu macchina
> virtuale Java di M$ o Internet Exploder per quanto concerne le pagine web).


Ma no... alla fine solo in tempi recentissimi anche il mondo degli IDE ha
cominciato a capire che dovevano staccare l'IDE dalla maggior parte delle
cose (per esempio dal build system). Ma sono anni recenti. Ora, io non ho
Windows e non saprei dirti, ma in questo caso non tirerei in ballo
cospirazioni microsoft... si sono scritti le librerie per il loro OS e se
vuoi programmare per quello puoi usare quella roba e fine della storia.


 Ma non vedo assolutamente perche'. Questa distinzione e' tutta tua. Ci
>> sarebbe prima di tutto da aprire una piccola parentesi su quanto sia
>> scorretta la pratica comune di parlare di "linguaggi compilati" e
>> "linguaggi interpretati"; per il resto "cross-platform" non e' in relazione
>> con compilazione vs. valutazione. Prova a rifletterci: salta fuori che
>> niente sarebbe cross-platform se fosse come dici e tutto lo sarebbe solo in
>> potenza.
>>
>
> Guarda che io non ho detto che c'è una correlazione fra l'essere
> interpretato o compilato e l'essere cross platform.
>

""""
Chiaramente però in questo caso parliamo di potenzialità cross-platform,
dato che C e C++ sono linguaggi compilati e non interpretati; poi, il fatto
che scrivere nativamente un programma cross-platform in C/C++ sia un casino
della miseria rispetto a ciò che va fatto in Python o Java, soprattutto per
quanto concerne l'interfacciamento ai servizi e alle librerie del sistema
operativo su cui deve girare, lo sappiamo tutti... ;-)
""""

Allora non capisco come si legge la tua frase sopra che riporto.


> Io ho solo detto che C e C++ sono compilati (e su questo non ci piove),


E come dicevo nella postilla... il concetto di *linguaggio* compilato e'
una fallacia diffusa, ma pur sempre una fallacia. Ogni linguaggio puo'
essere indifferentemente compilato o interpretato.


> per cui fra la scrittura del codice e la sua esecuzione sul computer
> (indipendentemente dal sistema operativo) c'è un passo in più rispetto a
> quello che c'è in Java o Python, fra l'altro non un passo di poco conto.


Che per inciso sono altri due linguaggi le cui principali implementazioni
*compilano* su bytecode (in un caso in modo trasparente, nell'altro no).

E su questo penso si possa essere d'accordo.


Non so quale sia il punto, ma sulle affermazioni, no, non sono molto
d'accordo.


>  Anche qui, ovviamente dipende. Sempre dicendo cose note a tutti: Java e'
>> notoriamente un casino maggiore per quanto concerne l'interfacciamento ai
>> servizi e alle librerie del sistema operativo in tutti i casi in cui
>> suddetti servizi e librerie non sono state ficcate nella JVM o nello
>> standard di Java (o almeno fornite come estensione). Cioe' e' proprio un
>> casino: tra l'altro e' tipicamente anche il caso in cui si rompe di brutto
>> la decantata portabilita' di Java. E chi gliene fa una colpa eh....
>>
>> Python ovviamente e' una cosa a simile/dissimile. Da un lato
>> interfacciare Python a servizi e librerie del sistema operativo e'
>> parecchio piu' facile che farlo per Java, se non altro usando CPython (vuoi
>> che scrivere moduli Python in C e' piu' facile che usare JNI) o addirittura
>> grazie a ctypes.
>>
>
> Qui casca l'asino: in linea di massima la portatilità di Python e Java è
> sì più immediata rispetto a C/C++, però la loro portatilità è limitata da
> quanto la macchina virtuale è in grado di fare e ti consente di fare,
> mentre su C/C++ questo problema non esiste (tant'è che il workaround si
> basa su C e C++); quindi il tutto dipende sempre da che software devi
> creare.
>

Guarda, il problema e' che "portabilita'" e' una parolona e ognuno la usa a
modo suo. Non a caso quello che tu sembravi legare al concetto di
portabilita' (ovvero interfacciarsi a servizi dell'OS) e' tipicamente quasi
l'opposto di quello che normalmente si intende.

 Nota, la questione non e' di lana caprina... e' proprio importante capire
cosa si intende. Per esempio Java da garanzie molto piu' forti su un grosso
numero di aspetti di basso livello (Python si limita a dire che si appoggia
alla libreria C sottostante per molte questioni). Poi ci sono parti della
libreria standard di Python che non sono disponibili su tutte le
piattaforme.

La stessa questione in C non e' rilevante: la libreria standard e' minimale
(e poi ci sarebbe tutto il discorso hosted vs. freestanding), ci sono un
sacco di dettagli in piu' e altri in meno. E ci sono standard aggiuntivi
(vedi POSIX).

Sono tutti modelli diversi, bisogna capire cosa si intende.


> Comunque, sempre per quanto ne so, comunque, anche in Java è possibile
> includere moduli scritti in C/C++.


Si appunto... JNI, gia' menzionato.



-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150122/97ea4fcf/attachment-0001.html>