[C++]Unire più file .exe

[gugoXX]

Originariamente inviato da cdimauro

pippo = open('Pippo.txt').read()

t = 0
for ch in pippo:
  if ch == 'a': t += 1

print "Ecco i caratteri 'a': ", t

Così va bene? Mi sembra comunque più semplice e leggibile di quanto hai scritto C#, e a cui manca tutto il "contorno".

A me sembrano davvero uguali. Perche' dici che e' piu' semplice o piu' leggibile?
c'e' la read di un file, un conteggio fatto anche qui su 3 righe, con concetti analoghi e una istruzione per stampare su schermo.

A me sembrano uguali a parte la print. Ripeto, il C# non e' stato studiato per stampare su console.
Ma cio' non toglie che lo si possa fare, anche se ovviamente l'astrazione ha protato alla creazione di un oggetto chiamato "Console", con dei metodi come WriteLine.

Comunque anche io ho usato Mono per motivi professionali almeno una volta.
Le richieste erano che il prodotto fosse in grado di compilare as-is sia sotto windows che sotto linux.
Addirittura gli assembly (dll) erano portabili, nel senso che li si potevano copiare da un sistema all'altro.
Anche noi potevamo figurare li'.
Peccato poi che pero' su 100 installazioni che abbiamo fatto non una e' stata fatta sotto Linux. Tutta una questione commerciale che ci ha rotto le wallas per fare le cose portabili, inutile, con il risultato che la realizzazione sotto Windows non e' stata ovviamente cosi' bella come poteva esserlo.

[cionci]

Originariamente inviato da cdimauro

Non io, ma a quanto pare qualcuno lo usa: http://www.mono-project.com/Companie...o_uses_Mono.3F

Come puoi notare si tratta appunto, per la maggior parte dei casi, di questioni di portabilità
Sono software sviluppati su Visual Studio e poi portati su Mono. Ritorna appunto l'identità Visual Studio <-> C#.

[cdimauro]

Originariamente inviato da gugoXX

A me sembrano davvero uguali. Perche' dici che e' piu' semplice o piu' leggibile?
c'e' la read di un file, un conteggio fatto anche qui su 3 righe, con concetti analoghi e una istruzione per stampare su schermo.

A me sembrano uguali a parte la print. Ripeto, il C# non e' stato studiato per stampare su console.
Ma cio' non toglie che lo si possa fare, anche se ovviamente l'astrazione ha protato alla creazione di un oggetto chiamato "Console", con dei metodi come WriteLine.

Nella tua versione c'è soltanto il corpo del codice, però: manca tutto il contorno.

A parte questo, in Python è più leggibile perché:
- non devi dichiarare il tipo delle variabili (è implicito);
- hai meno simboli da usare per racchiudere espressioni & codice (e il terminatore è il fine riga, non il ";");
- per stampare, come hai notato, c'è già l'istruzione print, che in ogni caso ha una sintassi più semplice.

Python è più vicino al concetto di pseudocodice.

Comunque finché ci limitiamo a esempietti sarà difficile far trasparire in maniera marca la differenza di "espressività" e produttività dei due linguaggio.

Comunque anche io ho usato Mono per motivi professionali almeno una volta.
Le richieste erano che il prodotto fosse in grado di compilare as-is sia sotto windows che sotto linux.
Addirittura gli assembly (dll) erano portabili, nel senso che li si potevano copiare da un sistema all'altro.
Anche noi potevamo figurare li'.
Peccato poi che pero' su 100 installazioni che abbiamo fatto non una e' stata fatta sotto Linux. Tutta una questione commerciale che ci ha rotto le wallas per fare le cose portabili, inutile, con il risultato che la realizzazione sotto Windows non e' stata ovviamente cosi' bella come poteva esserlo.

Capisco, ma allora che dobbiamo fare? Ignorare la portabilità di un'applicazione .NET?

Originariamente inviato da cionci

Come puoi notare si tratta appunto, per la maggior parte dei casi, di questioni di portabilità
Sono software sviluppati su Visual Studio e poi portati su Mono. Ritorna appunto l'identità Visual Studio <-> C#.

Perché gli ambienti di sviluppo su Windows sono più comodi.

[tomminno]

Originariamente inviato da cdimauro

Mono non è per Windows, o sbaglio?

Ti sfido ad usare Monodevelop e a paragonarlo anche solo minimamanete a VisualStudio (ma anche a SharpDevelop)

[gugoXX]

Originariamente inviato da cdimauro

Nella tua versione c'è soltanto il corpo del codice, però: manca tutto il contorno.

A parte questo, in Python è più leggibile perché:
- non devi dichiarare il tipo delle variabili (è implicito);
- hai meno simboli da usare per racchiudere espressioni & codice (e il terminatore è il fine riga, non il ";");
- per stampare, come hai notato, c'è già l'istruzione print, che in ogni caso ha una sintassi più semplice.

Python è più vicino al concetto di pseudocodice.

Anche in C# puoi non dichiarare le variabili. Io lo faccio comunque per scelta, per migliorare la leggibilita' successiva. Chiaro esempio di come talvolta preferisco scrivere di piu' per ottenere qualcosa successivamente.

Spero comunque che non si vada a preferire il Phyton al C# a causa del punto e virgola oppure del fatto che in applicazioni Console puoi scrivere Print al posto di Console.WriteLine.

Finora quello che ho capito e' che lascerei il Phyon per Console Application, e non sono neppure convinto che sia una scelta cosi' vantaggiosa rispetto al C#. Il 10x non lo vedo ancora.
Ma al lavoro io non devo fare console application. Non ne ho mai fatte in 10 anni.
Oggi devo fare
- WebService.
- Applicazioni Client Server con Gui complesse, che chiacchierno con i WebService
- WebService che chiacchierano con i database
- Pagine Web che chiacchierano con i WebService
- Installer e Updater olnline di applicazioni.
- Applicazioni MultiThread
- Applicazioni Server, quindi MultiProcess, non solo Multithread, che chiacchierano con la rete.
- Applicazioni che abbracciano strettamente il Sistema Operativo per gestire oggetti di basso livello (l'anno scorso ho dovuto usare una named Pipe di Windows, per risolvere un problema in modo semplice).
- Applicazioni che vanno a chiacchierare a basso livello con i device. Ultimo che mi e' capitato sempre l'anno scorso, interazione con un device di fingerprint e un device di retinal scan.

Sono quasi sicuro di aver migliorato di parecchio la velocita' di scrittura, di aver minimizzato gli errori e di aver migliorato anche la leggibilita' e la manutenibilita', rispetto al C++.
Ma non so se il Python mi puo' aiutare a migliorare ancora. Non sono neppure certo che Python possa risolvere questi problemi in modo altrettanto efficace.

Un esempio che sto usando proprio ora.
Usando tecnologie come AJAX.net e LINQ, sto preparando lo scheletro di un'applicazione che permettera' agli sviluppatori di creare pagine Web che interagiscono con i Database, in un ambiente 3 livelli, tutto da una singola classe di codice. Senza una riga di Javascript e senza una riga di SQL.
Tutto fortemente tipizzato e controllato a Compile-time.

fortemente tipizzato significa semplicemente che un oggetto nasce di un determinato tipo, e il tipo non cambiera' fino alla sua morte.
Ma davvero in Python capita cosi' spesso dia vere l'esigenza di cambiare il tipo di un oggetto?
Si puo' fare anche in javascript, ma ho imparato a starci lontano proprio per evitare problemi. Quali sarebbero i vantaggi di questo approccio?

Poi sono anche dell'idea che un linguaggio da solo non serve a nulla.
La parte piu' importante e' il contorno, le librerie.
E il C# ha a disposizione un'immensa libreria standard usabile nativamente da tutti, subito pronta all'uso. Il FrameWork.

Ma anche solo per un'applicazione come quella da cui e' partito questo thread, ma sei davvero sicuro che farla da zero in Python sia la cosa migliore?
In C#, nell'assembly diagnostic (gia' nativamente a disposizione per tutti) posso leggere tantissime cose del sistema operativo, e non escludo che si possano trovare anche valori come temperature e frequenze.

Non riesco a capire come faccia Python ad essere stato portato sotto .net, quando uno dei requisiti del .net e' proprio l'estremo strong-typing di tutti gli oggetti, la cui mancanza invece e' uno dei punti di forza del Python espressi nel documento che mi hai passato prima.

[fek]

Originariamente inviato da cdimauro

Non mi sembra d'aver consigliato di scrivere s.o. o driver con Python finora: il dominio applicativo è sempre stato tranquillamente alla portata di questo linguaggio.

Quando comincerò a farlo, siete autorizzati a chiamare la neuro.

Forse un SO e' l'unico scenario degli ultimi dieci che ti ho visto consigliare dove Python avrebbe magari un senso, visto che ne stanno scrivendo almeno un paio in .NET
(Sono progetti interessantissimi per altro)

Cesare, a parte gli scherzi, non credo di essere l'unico (eufemismo) ad aver notato che ultimamente il tuo zelotisimo pro-python sta raggiungendo livelli di guardia. Ogni tuo post e' una difesa di Python dagli attacchi immeritati oppure un consiglio di Python per le applicazioni piu' disparate.
Io applico una regola: quando TUTTI mi dicono che sto esegerando e forse sto sbagliando mi fermo e ci ragiono. Magari e' vero, mi sto sbagliando (raro ma capita ).

[fek]

Originariamente inviato da cdimauro

print 'Nel testo letto ci sono %s caratteri a' % len([Ch for Ch in pippo if Ch == 'a'])

Ti faccio vedere un intero gioco scritto in C su una riga sola? Non e' tanto meno leggibile di Python...

[gugoXX]

Avevo intenzione di proporre un esercizio quasi accademico.
Un simulatore di sistema solare, con pianeti definiti da coordinate e massa.
Il simulatore dovrebbe preoccuparsi di calcolare le accellerazioni e di manutenere le velocita', tutto partendo dalla legge di Newton.
Poi sarebbe anche bello stampare a video il risultato passo-passo della simulazione, disegnando dove i pianeti (e il sole) vanno a posizionarsi man mano che il tempo passa.

Cosi' anche chi dice che non c'e' soluzione per il problema dei 3 pianeti sta zitto. Anche qui matematicamente si ha una soluzione, che non e' analitica, ma precisa a piacere.
Proprio come le tanto elogiate funzioni analitiche, che tanto hanno lo stesso problema.
sin(31) sara' tanto bella scritta cosi', ma per avere il valore numerico si devono fare gli sviluppi, con tanti passi quanti sono necessari per ottenere la precisione che si desidera. Esattamente come potrebbe essere la nostra simulazione...

Stasera provo.
Ho capito che in Python non ci sara' la parte grafica, fa lo stesso.
Al C# gliela aggiungero', magari in un bel Thread separato, per non bloccare la finestra come capita a tutti i niubbi...

[fek]

Originariamente inviato da cionci

Produttività va a braccetto con manutenibilità e leggibilità, imho Posso anche essere 10 volte più veloce in Python a scrivere un programma, ma se dopo un mio collega che lo legge e lo deve modificare è 10 volte più lento ho perso qualsiasi vantaggio di produttività.

E se poi il tuo collega perde due giorni di lavoro per un errore di sintassi colto a runtime solo tre ore dopo?

[fek]

Originariamente inviato da cionci

Certo, mi riferivo proprio a Mono. Chi è tanto masochista da usare Mono su linux a livello produttivo ?

Pixar e Dreamworks :|

[cionci]

Originariamente inviato da fek

Pixar e Dreamworks :|

Ma per fare porting di programmi per Windows ?

[fek]

Originariamente inviato da cdimauro

Nella tua versione c'è soltanto il corpo del codice, però: manca tutto il contorno.

Ma questo e' un discorso capzioso. Il contorno manca anche in Python perche' e' stato gia' scritto da altri
Vuoi che ti scriva il contorno che ti permette di lanciare due righe di C# da console? Ci metto mezz'ora, probabilmente c'e' anche in giro.

[fek]

Originariamente inviato da cionci

Ma per fare porting di programmi per Windows ?

No, nativo, per lavorare con XSI all'interno del loro Linux completamente customizzato. Giuro, non ci volevo credere, ma Mono e C# stanno mangiando tantissimo terreno a Python come linguaggio per programmare sotto Linux.

[fek]

Originariamente inviato da cdimauro

A parte questo, in Python è più leggibile perché:
- non devi dichiarare il tipo delle variabili (è implicito);
- hai meno simboli da usare per racchiudere espressioni & codice (e il terminatore è il fine riga, non il ";");
- per stampare, come hai notato, c'è già l'istruzione print, che in ogni caso ha una sintassi più semplice.

- Il codice e' molto piu' leggibile se posso leggere il tipo della variabile piuttosto che cercare di comprenderlo dal codice. E c'e' meno pericolo di fare casini che poi Python rivela solo a runtime
- Meno simboli non vuol dire piu' leggibilita' quando l'indentazione ad esempio e' forzata e non ti permette di organizzare il codice in maniera piu' leggibile
- print non e' necessariamente piu' leggibile di Write

Python è più vicino al concetto di pseudocodice.

Si', lo pseudocodice illeggibile

[fek]

Interactive C#:

http://www.dcs.bbk.ac.uk/~keith/research/sIDE/
http://lists.ximian.com/pipermail/mo...ly/013230.html

Are you referring to a way to execute small C# code statements and have
them executed as if they were within a simple program, on the fly?
Because if so, then you can use the classes and methods within
System.CodeDom, specifically within System.CodeDom.Compiler, to compile
and execute code. So you can take a command such as
"string.Compare("test","testing")" from a prompt, build it up into a
simple class with an entry point, use an ICodeCompiler object (which one
depends on which language) to compile the code, and then execute the
assembly in memory, returning the result back to the prompt (without
saving any of the code or binary assembly to file, truly on the fly).

Cesare, davvero, basta

[tomminno]

Originariamente inviato da fek

Pixar e Dreamworks :|

Hanno un loro IDE interno?

[fek]

Originariamente inviato da tomminno

Hanno un loro IDE interno?

Non lo so.

[cdimauro]

Originariamente inviato da tomminno

Ti sfido ad usare Monodevelop e a paragonarlo anche solo minimamanete a VisualStudio (ma anche a SharpDevelop)

Perché, fa cacare?

Mai provato onestamente.

Originariamente inviato da gugoXX

Ma al lavoro io non devo fare console application. Non ne ho mai fatte in 10 anni.
Oggi devo fare
- WebService.
- WebService che chiacchierano con i database
- Applicazioni MultiThread
- Applicazioni Server, quindi MultiProcess, non solo Multithread, che chiacchierano con la rete.

Queste sono cose che faccio abitualmente in Python, come console application.

Sono quasi sicuro di aver migliorato di parecchio la velocita' di scrittura, di aver minimizzato gli errori e di aver migliorato anche la leggibilita' e la manutenibilita', rispetto al C++.
Ma non so se il Python mi puo' aiutare a migliorare ancora. Non sono neppure certo che Python possa risolvere questi problemi in modo altrettanto efficace.

Dipende dal problema. Io per le applicazioni di cui sopra ti posso dire che mi ha aiutato molto a svilupparle velocemente.

Un esempio che sto usando proprio ora.
Usando tecnologie come AJAX.net e LINQ, sto preparando lo scheletro di un'applicazione che permettera' agli sviluppatori di creare pagine Web che interagiscono con i Database, in un ambiente 3 livelli, tutto da una singola classe di codice. Senza una riga di Javascript e senza una riga di SQL.
Tutto fortemente tipizzato e controllato a Compile-time.

fortemente tipizzato significa semplicemente che un oggetto nasce di un determinato tipo, e il tipo non cambiera' fino alla sua morte.
Ma davvero in Python capita cosi' spesso dia vere l'esigenza di cambiare il tipo di un oggetto?
Si puo' fare anche in javascript, ma ho imparato a starci lontano proprio per evitare problemi. Quali sarebbero i vantaggi di questo approccio?

Gli oggetti non cambiano di tipo. Semplicemente le variabili in Python (ma anche in JavaScript, se non ricordo male) conservano sempre e soltanto il riferimento a un oggetto.

Quindi se scrivi prima a = 1 e subito dopo a = 'Pippo', a non ha cambiato tipo, ma soltanto "punta" a un oggetto diverso. Tutto qui.

Poi sono anche dell'idea che un linguaggio da solo non serve a nulla.
La parte piu' importante e' il contorno, le librerie.
E il C# ha a disposizione un'immensa libreria standard usabile nativamente da tutti, subito pronta all'uso. Il FrameWork.

Indubbiamente. Anche per questo Python ha avuto e sta avendo una notevole diffusione: ha un'ottima libreria standard. Infatti il suo motto è "with batteries included". Ovviamente non copre tutti i campi (è carente lato GUI, ad esempio, perché non s'è voluto legare "mani e piedi" il linguaggio a una libreria; generalmente gli utenti si scelgono la libreria grafica che gli piace di più).

IronPython, che è il porting di Python per .NET (e mantenuto dalla stessa MS ormai), unisce il meglio dei due mondi: libreria standard di Python + framework .NET.

Ma anche solo per un'applicazione come quella da cui e' partito questo thread, ma sei davvero sicuro che farla da zero in Python sia la cosa migliore?
In C#, nell'assembly diagnostic (gia' nativamente a disposizione per tutti) posso leggere tantissime cose del sistema operativo, e non escludo che si possano trovare anche valori come temperature e frequenze.

Se è così, si può usare anche con IronPython: lavoro risparmiato.

Non riesco a capire come faccia Python ad essere stato portato sotto .net, quando uno dei requisiti del .net e' proprio l'estremo strong-typing di tutti gli oggetti, la cui mancanza invece e' uno dei punti di forza del Python espressi nel documento che mi hai passato prima.

E' sbagliato: Python è fortemente tipizzato come linguaggio. Prova a sommare un numero con una stringa.

Non bisogna confondere la (forte o debole) tipizzazione con la "dinamicità" del linguaggio, che permette di eseguire il binding di un oggetto a una "variabile" in qualunque momento e più volte.

Originariamente inviato da fek

Forse un SO e' l'unico scenario degli ultimi dieci che ti ho visto consigliare dove Python avrebbe magari un senso, visto che ne stanno scrivendo almeno un paio in .NET
(Sono progetti interessantissimi per altro)

Sì, ho letto qualche notizia tempo fa, e sembrano anche a me interessanti. Comunque .NET è multilinguaggio, per cui... no comment.

Cesare, a parte gli scherzi, non credo di essere l'unico (eufemismo) ad aver notato che ultimamente il tuo zelotisimo pro-python sta raggiungendo livelli di guardia. Ogni tuo post e' una difesa di Python dagli attacchi immeritati oppure un consiglio di Python per le applicazioni piu' disparate.
Io applico una regola: quando TUTTI mi dicono che sto esegerando e forse sto sbagliando mi fermo e ci ragiono. Magari e' vero, mi sto sbagliando (raro ma capita ).

Mi fermo qui, infatti (anche perché mi sono stancato di battagliare sempre sulle stesse cose).

Sto rispondendo soltanto ad alcune cose per precisare alcuni concetti.

Originariamente inviato da fek

Ti faccio vedere un intero gioco scritto in C su una riga sola? Non e' tanto meno leggibile di Python...

Non c'è bisogno.

Originariamente inviato da gugoXX

Avevo intenzione di proporre un esercizio quasi accademico.
Un simulatore di sistema solare, con pianeti definiti da coordinate e massa.
Il simulatore dovrebbe preoccuparsi di calcolare le accellerazioni e di manutenere le velocita', tutto partendo dalla legge di Newton.
Poi sarebbe anche bello stampare a video il risultato passo-passo della simulazione, disegnando dove i pianeti (e il sole) vanno a posizionarsi man mano che il tempo passa.

Cosi' anche chi dice che non c'e' soluzione per il problema dei 3 pianeti sta zitto. Anche qui matematicamente si ha una soluzione, che non e' analitica, ma precisa a piacere.
Proprio come le tanto elogiate funzioni analitiche, che tanto hanno lo stesso problema.
sin(31) sara' tanto bella scritta cosi', ma per avere il valore numerico si devono fare gli sviluppi, con tanti passi quanti sono necessari per ottenere la precisione che si desidera. Esattamente come potrebbe essere la nostra simulazione...

Stasera provo.
Ho capito che in Python non ci sara' la parte grafica, fa lo stesso.
Al C# gliela aggiungero', magari in un bel Thread separato, per non bloccare la finestra come capita a tutti i niubbi...

Lasciamo perdere, mi sono stufato. Se hai intenzione di farti una cultura con Python, visto che conosci altri linguaggi, magari è meglio.

Originariamente inviato da fek

E se poi il tuo collega perde due giorni di lavoro per un errore di sintassi colto a runtime solo tre ore dopo?

Lasciamo perdere questi confronti, Fran. Il primo progetto (costituito da più applicazioni, con compiti diversi) che ho realizzato in Python l'ho portato a termine in 20 giorni, incluso il tempo di apprendimento di molti concetti di questo linguaggio.
Ed era un progetto che una società svedese si vantava di avere realizzato in "appena" 6 mesi...

Di esempi così potrei fartene parecchi, ma non ti direbbero nulla. Idem per i disastri che ti sono capitati con Python: non mi dicono nulla.

Possiamo soltanto prendere atto che abbiamo avuto esperienze diverse.

Io, da 3 anni e mezzo a questa parte, noto un notevole miglioramento della mia produttività personale. Opinione personalissima, sia chiaro, ma... per me è così: non posso certo nascondere quella che è la realtà che ho vissuto in tutto questo tempo, soltanto per far contento qualcuno.

Originariamente inviato da fek

Ma questo e' un discorso capzioso. Il contorno manca anche in Python perche' e' stato gia' scritto da altri
Vuoi che ti scriva il contorno che ti permette di lanciare due righe di C# da console? Ci metto mezz'ora, probabilmente c'e' anche in giro.

Originariamente inviato da fek

Interactive C#:

http://www.dcs.bbk.ac.uk/~keith/research/sIDE/
http://lists.ximian.com/pipermail/mo...ly/013230.html

Are you referring to a way to execute small C# code statements and have
them executed as if they were within a simple program, on the fly?
Because if so, then you can use the classes and methods within
System.CodeDom, specifically within System.CodeDom.Compiler, to compile
and execute code. So you can take a command such as
"string.Compare("test","testing")" from a prompt, build it up into a
simple class with an entry point, use an ICodeCompiler object (which one
depends on which language) to compile the code, and then execute the
assembly in memory, returning the result back to the prompt (without
saving any of the code or binary assembly to file, truly on the fly).

Cesare, davvero, basta

Hai tirato in ballo un intero IDE: se facciamo di questi confronti non ne usciamo più, e comunque non mi va di continuare con questa polemica.

Anche per questo, ho evitato di rispondere all'altro messaggio.

[gugoXX]

Originariamente inviato da cdimauro

Gli oggetti non cambiano di tipo. Semplicemente le variabili in Python (ma anche in JavaScript, se non ricordo male) conservano sempre e soltanto il riferimento a un oggetto.

Quindi se scrivi prima a = 1 e subito dopo a = 'Pippo', a non ha cambiato tipo, ma soltanto "punta" a un oggetto diverso. Tutto qui.

E' sbagliato: Python è fortemente tipizzato come linguaggio. Prova a sommare un numero con una stringa.

Non bisogna confondere la (forte o debole) tipizzazione con la "dinamicità" del linguaggio, che permette di eseguire il binding di un oggetto a una "variabile" in qualunque momento e più volte.

E quindi non ci sono differenze, dato che lo si puo' fare anche in C#.
L'unica differenza sarebbe quindi che in C# non posso riusare lo stesso nome di variabile? Non mi sembra un cosi' grande limite.
Una differenza potrebbe essere che il tipo di una variabile viene fissata in C# al momento della creazione dell'istanza dell'oggetto, cosa che invece mi sembra di aver capito che in Python puo' anche avvenire dopo vero? (Come in javascript, p.es.)

Lasciamo perdere, mi sono stufato. Se hai intenzione di farti una cultura con Python, visto che conosci altri linguaggi, magari è meglio.

Chiaro. I problemi sono 2 pero'. Conoscere un linguaggio di programmazione e' una fatica non nulla. Lo farei se fossi sicuro di ottenere qualcosa in cambio.
Finora il x10 rispetto al C# non l'ho proprio visto. Ma neppure x2 o x1 ad essere sinceri.
C'e' un caso, un pattern, una situazione dove e' chiaramente piu' vantaggioso l'uso di Python?
Se qualcuno me lo chiedesse tra C++ e C# saprei tirare fuori decine di esempi.

L'altro problema e' questo.

Required Skills: C#
Posted: last 7 days
1 - 25 of 353 matches.
Highest salary: Salary:£90k pa + Bonus + Benefit (120k€ anno)

Required Skills: Python
Posted: last 7 days
1 - 25 of 45 matches
Highest salary: 50k to 60k pa + benefits (80k$ anno)

E ho tolto quelli a contratto, questi sono permanent.
A contratto in C# ce ne sono parecchi (e arrivano a 1000€ al giorno), mentre per Python non ne ho trovati.
Vorrei sottolineare la differenza sui matches, non sui salari, che sono effettivamente molto simili.

Questo solo per dire che oggi il mercato richiede di piu' il C#, e se devo proprio tirare la monetina per decidere cosa imparare, ho piu' speranze che mi possa servire per lavoro il C# piuttosto che il Python.
Questo oggi, domani magari sara' invece diverso.
Rendo merito anche che il Python si conosce di meno, quindi e' possibile che io riesca piu' facilmente a trovare lavoro se lo conosco bene. Non generalizzerei neppure qui.
Ma se fossi proprio digiuno di entrambi io personalmente sceglierei C#.

Io, da 3 anni e mezzo a questa parte, noto un notevole miglioramento della mia produttività personale. Opinione personalissima, sia chiaro, ma... per me è così: non posso certo nascondere quella che è la realtà che ho vissuto in tutto questo tempo, soltanto per far contento qualcuno.

Ed e' la stessa cosa che dico io del C#.
Ma non vado a dire in giro che quindi e' 10 volte meglio di qualsiasi altro linguaggio, soprattutto di quelli che non conosco.
Magari 10 volte meglio del C, e parecchie volte meglio del C++, ma non generalizzerei.

[fek]

Originariamente inviato da cdimauro

Lasciamo perdere questi confronti, Fran. Il primo progetto (costituito da più applicazioni, con compiti diversi) che ho realizzato in Python l'ho portato a termine in 20 giorni, incluso il tempo di apprendimento di molti concetti di questo linguaggio.

Ma non lasciamoli perdere proprio per nulla, perche' e' l'unica cosa che per me conta: due giorni di lavoro persi per un errore che doveva essere trovato a compile-time. Il resto e tutti gli altri esempi, davvero, sono chiacchiere perche' nell'applicazione sul campo in un progetto ampio Python per me ha fallito. Occhio che sono due anni che lavoro con un sistema totalmente scritto in Python e so che cosa vuole dire. E infatti usero' altri strumenti.

Hai tirato in ballo un intero IDE: se facciamo di questi confronti non ne usciamo più, e comunque non mi va di continuare con questa polemica.

Ho tirato in ballo cinquanta righe di codice che posso scrivere in mezz'ora per fare esattamente quello che dici tu! C# in console.
Permettimi, come consigli ad altri di studiare meglio Python, dai un'occhiata meglio alle possibilita' offerte da .NET prima di fare certe affermazioni.