Newsgroup: it.comp.lang.visual-basic
Titolo: [Forse OT] Società che sviluppano in .NET....

Volevo sapere se già sono partiti progetti per clienti (medio-grandi) con
l'architettura .NET.
Grazie

 (medio-grandi) con l'architettura .NET.
Magari questo ti dà una idea di cosa pensano i "grandi sviluppatori" della
piattaforma .NET.
http://www.zdnet.it/zdnet/jumpNews.asp?idUser=0&idChannel=0&idNews=125714
Ciao
*Roby*



Grazie del link, molto interessante.
Il costo in termini di risorse umane per passare a .NET e' e sara'
tutt'altro che trascurabile, chissa' che tools concorrenti (es.
Delphi, che peraltro in futuro dovrebbe essere compatibile .Net, o il
C++ Builder) non approfittino della situazione di stallo per
guadagnare quote di mercato.
Stefano "HappyMan" (Lago Maggiore - NO)
--
Personal Web 
http://www.sgr.info
Email 
happyman...@libero.it
 [Togliere nospam per scrivermi]
Salsa Web 
http://web.tiscali.it/happyman
 [Foto salseri/e & I.A.B.L.A. Ring]

 guadagnare quote di mercato.
Boh, Delphi lo stanno portando a Delphi.NET.
Ciao
--
' // Initialize the expression evaluator
Engines.Evaluator = CreateObject("
http://www.neodatatype.net
")
' // you can find resources for and from the NG here!
Me.SitoComune = "
http://www.it-lang-vb.net
"


Dipende. A crude parole se si stesse parlando di puttane chi batte per prima
lo piglia in culo due volte. :)
.. io aspetterei. Non credo che chi si attarda un pò rimarrà così spiazzato.
Un pò di cautela in questo caso non fa male.
Secondo me, chi sviluppa software dovrebbe tenere *sempre* presente il
concetto che un buon programma non dipende mai dal linguaggio con il quale è
stato fatto, ma quanto più si avvicina alle esigenze del cliente. In questo
senso, per le sue caratteristiche, 
VB.NET
 potrebbe danneggiare l'utente
finale più che avvantaggiarlo. Tanto vale spremere fino all'osso VB6 e
tenere d'occhio NET, studiandolo e approfondendolo bene, prima di
distribuire 'i numeri 0' che di norma sono pieni di bachi.
Fbaio

 della situazione di stallo per guadagnare quote di mercato.
Non vedo perché il passaggio a .NET dovrebbe essere più
oneroso che il passaggio a Delphi o a Java...
Comunque Delphi, per quanto non mi piaccia affatto, posso
ritenerlo un ottimo tool, ma il C++Builder (se utilizzato come
RAD) è solo una vaccata.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 sviluppatori" della piattaforma .NET.
Spero che quel "grandi sviluppatori" tra virgolette abbia lo
stesso ironico significato che io penso...
Comunque, leggere quello che queste due persone hanno scritto,
dimostra quanto poco capiscano di programmazione (saranno
almeno, spero per loro, grandi manager)...
Voglio precisare un'affermazione di uno dei due, affermazione
sentita più volte anche sul NG.
I clienti *non* hanno nessuna esigenza di .NET, ma neppure di
VB, C++, Java, ecc...
Il linguaggio od una piattaforma di sviluppo *non* nascono per
assecondare esigenze dei clienti, ma per migliorare il lavoro
degli sviluppatori, permettendogli di realizzare soluzioni
adatte ai loro clienti, più robuste, più flessibili, più
sicure, di più facile manutenzione, e, magari, di più veloce
sviluppo.


 
http://www.zdnet.it/zdnet/jumpNews.asp?idUser=0&idChannel=0&idNews=125714
Sbaglio, o almeno una delle due aziende citate sviluppa i suoi
prodotti in cobol? Nulla in contrario al cobol, ma per passare a
dotnet ci vorrebbero dei bei investimenti interni..
-- 
ale
www.sen.it

RAD) è solo una vaccata.
Non uso il Builder ma per quel poco che ne ho sentito parlare le
opinioni non erano negative. Perche' lo dici ? Delphi e il Builder non
condividono lo stesso framework (VCL) ?


 framework (VCL) ?
Notare il "se utilizzato come RAD" che ho scritto. Come
compilatore C++ potrebbe passare, ma il C++ non è l'Object
Pascal. Utilizzarlo come RAD significa non avere compreso la
portate e l'utilizzo del C++ (RAD è male).


> framework (VCL) ?
Un'aggiunta:
lo stesso fatto che uno stesso framework (VCL) possa essere
condiviso fra due linguaggi *totalmente* diversi, con
filosofie totalmente diverse, rende lo stesso framework una
porcheria (se utilizzato in C++).
Il discorso vale anche con .NET. Utilizzare il C++.NET
significa castrare il linguaggio stesso.


 dimostra quanto poco capiscano di programmazione
La programmazione non c'entra un bel niente. E' questione di costi/benefici
sul conto economico aziendale.
Facciamo un esempio (numeri tirati a caso, eh!):
Diciamo che per migrare uno sviluppatore da "buon livello linguaggio A" a
"buon livello linguaggio .NET" servano 2 mesi.
Diciamo che .NET renda lo sviluppatore più produttivo del 10% rispetto a
quando lavorava col linguaggio A.
Il calcolo è presto fatto: lavori 10 mesi all'anno, ogni 10 ne guadagni uno,
quindi ottieni il pareggio dopo 2 anni di uso della sola piattaforma .NET.
Questo ovviamente ignorando il costo di acquisto del software, e la
malaugurata ipotesi che il tuo dipendente da te formato se ne vada alla
concorrenza (ben felice di rivendere a caro prezzo la sua nuova
professionalità) prima di aver lavorato per i fatidici 2 anni, oppure che M$
se ne esca con qualcos'altro prima dei 2 suddetti anni.
Guadagni il 20% di produttività? Serve un anno solo. Guadagni il 5%? Servono
4 anni.
C'è però anche da considerare che il guadagno di produttività tra i
lavoratori dipendenti non va comunque mai oltre una certa soglia. Se lo
sviluppatore si accorge di riuscire a fare più cose in meno tempo,
incomincia a prendersi un maggior numero di pause caffè (o a navigare di più
in Internet), tanto gli avanza comunque il tempo per fare il lavoro. Morale:
i 2 mesi di investimento non hanno reso un bel niente.
Ogni azienda che sviluppa i propri prodotti si è anche già sviluppata una
serie di librerie che risolvono le esigenze primarie di programmazione, che
sono "patrimonio" dell'azienda. Perchè decidano di cambiare linguaggio,
riscrivere le librerie, e buttare il pregresso alle ortiche, bisogna che si
aprano nuovi mercati o che si chiudano quelli vecchi.
Al momento il trend è questo: aspettare. Fare esperimenti, e aspettare che
sia il mercato eventualmente a richiedere un passaggio a .NET, oppure
aspettare che qualcun altro abbia formato il personale a sue spese, e poi
portarglielo via già bello che pronto.
Per quello .NET vende meno del previsto, indipendentemente da quanto possa
essere bello e performante.
Certo, se fosse stato _anche_ compatibile al 100% con le versioni
precedenti, la questione sarebbe stata diversa...
Ciao
*Roby*

 wrote:
[cut]
Per la mia esperienza precedente di lavoratore dipendente in una
software house mi sento di condividere al 100% quanto hai scritto.
Ciao


 passaggio a .NET,
Ecco. Il punto è qui. Ti riporto anche le frasi incriminate:
"... consiste nel 'fingere', in un certo senso, di creare
soluzioni basate su .Net,"
e
"se esista o meno l'esigenza da parte dei clienti di avere
prodotti basati sulla piattaforma .Net. In realtà è
un'esigenza poco sentita"
Il fatto è che *NON* esiste, e né *MAI* esisterà, salvo
pochissimi casi eccezionali (integrazione con sistemi
esistenti), esigenza da parte del cliente dell'utilizzo di una
specifica piattaforma o linguaggio per lo sviluppo del sw.
Se una SH decide di adottare .NET (o Java, o VB, o Delphi o
C++, ecc...) *NON* lo fa perché i clienti o il mercato glielo
richiedono, ma lo fa perché il linguaggio/ambiente di
sviluppo/piattaforma, che decide di adottare gli consente, a
seconda della tipologia di sw sviluppato, una produttività e/o
qualità del sw maggiori,.
I discorso "fingere di sviluppare in .NET" è *totalmente fuori
dal mondo*, ed è tipico dei *VENDITORI DI FUMO*, ovvero chi
deve basarsi su motivazioni inesistenti, raggirando il cliente
per giustificare la nullità del sw prodotto.


 per giustificare la nullità del sw prodotto.
Lasciamo perdere. Ne conosco alcuni, e... bah, lasciamo perdere.
potrebbero mettermi in galera solo per quello che PENSO di un
paio di 'sti tipi, gente che a suo tempo chiese _*4 milioni e mezzo
più le spese di viaggio e 2 gg di permanenza per 2 persone*_
per una patch di un programma che serviva solo a risolvere
un BUG RICONOSCIUTO dell'applicazione (c'è un inchiodamento
se si inserisce uno spazio in una textbox :-((( ).
Roba IMNSHO da denuncia per truffa.
E di tipi del genere ne esistono molti...
P.S.: inutile dire che l'app buggata è rimasta tale. >:-|
Bye, G.

 significa castrare il linguaggio stesso.
In effetti questa non l'ho capita... adesso c'è la mania di portare tutti i
linguaggi sotto net... ci manca solo un bel 
LOGO.NET
 così anche la commodore
è contenta.
Non c'era già il C# a fare la parte del "nuovo" C?
Che bisogno c'era di un C++ che è più difficile del C# da usare e meno
potente del C++ nativo?


 dal mondo*, ed è tipico dei *VENDITORI DI FUMO*,
Secondo me hai frainteso il senso della frase (lungi da me voler difendere
un (possibile) concorrente!). Voleva appunto dire che, siccome sarebbe una
stupidaggine, non ha senso fare programmi dotnet per il gusto di farli anche
a costo di fare sacchiaponi. Il problema si è posto anche a noi negli stessi
termini e per il momento usiamo dotnet solo per le nuove applicazioni
(portandoci dietro le vecchie dll, senza io non mi muovo) ma unicamente per
programmini di contorno, tanto per farci la mano. I grossi progetti sono
bloccati almeno fino a primavera. E non è che la cosa ci piaccia.
--
rumplestilskin

 produttività e/o qualità del sw maggiori.
Io credo che quello non sia sufficente.
Ho assistito in prima persona ad una riunione per decidere che linguaggio
utilizzare in una software house quando finì l'era di Clipper, col passaggio
dal Dos a Windows. C'era Delphi, c'era VB, e c'erano altre possibilità  meno
conosciute ma tecnicamente interessanti. Il criterio di scelta però non fu
affatto tecnico; si disse: "Scegliamo VB perchè è di M$ e sarà sicuramente
molto supportato e diffuso".
VB è palesemente inferiore a Delphi, quindi potrebbe sembrare che la scelta
fosse sbagliata, invece fu giusta perchè effettivamente divenne il
linguaggio più diffuso e supportato.
Ciao
*Roby*

 Io credo che quello non sia sufficente.
[cut]
In realtà è in parte un criterio tecnico, comunque utilizzare un
linguaggio ottimo ma male supportato non è una scelta "tecnica"
molto valida.


 Secondo me hai frainteso il senso della frase
[cut]
Non saprei, io l'ho interpretata in quella maniera, spero (per lui)
di sbagliarmi...


 Preciso: "fare", il che non significa "fare facilmente" :-)
Nulla. Non esiste nulla che non sia possibile fare con "qualsiasi"
linguaggio (bastano un for ed un if... non serve null'altro).
Il "valore" dei linguaggi sta nel farlo più facilmente e con meno
possibilità di errori.


 non serve null'altro).
Non erano If e Goto? ;)
Lokar
--
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt

 specifiche. Poi sarà la sh a scegliere
a proporlo, o possibilmente a proporne.
il cliente potrebbe avere preferenze, a parita' o quasi di specifiche.
un dbms me lo possono fare in vo o in vb senza sostanziali differenze,
ma potrei preferire l'uno o l'altro.


 da usare e meno potente del C++ nativo?
Dal punto di vista della M$ credo (spero) che il C++.NET
rappresenti prevalentemente una mossa commerciale.


 Non erano If e Goto? ;)
Sì, hai ragione; bastano un'istruzione condizionale ed una di
salto (quindi if e goto).


 l'altro.
Certamente, il cliente potrebbe anche obbligare la sh
all'utilizzo di un determinato linguaggio, ma difficilmente
(tranne, come detto, eccezioni) tale scelta è motivata da
esigenze reali del cliente...


 esigenze reali del cliente...
Dipende anche dal tipo di lavoro. Se lavori ad un progetto del cliente (su
'commessa', quindi dove i sorgenti sono del cliente), specialmente se molto
grande, il cliente normalmente (non come eccezione) ha grosso peso sulla
decisione del linguaggio - fino ad imporre uno specifico tool, non
genericamente "il C++" - perché ovviamente vuole un linguaggio che non sia
solo adatto alla bisogna, ma che sia anche durevole, conosciuto, etc. (così
può passare il progetto ad altre aziende, a personale interno, etc). Con
alcune aziende molto grandi questo non è neppure oggetto di trattativa (se
non sei tu il consulente che decide il linguaggio). Personalmente mi sono
già trovato nella situazione di dover scegliere fra vb6 e 
vb.net
 in un caso
del genere e non è stato facile. Per gli altri fornitori la mia indicazione
sarà legge, perché l'azienda imporrà questa scelta (qindi la responsabilità
è ancora più grande).
--
rumplestiltskin

 scelta (qindi la responsabilità è ancora più grande).
Il fatto è che generalmente il cliente è notevolmente
ignorante in materia, e le scelte che può proporre (od
obbligare) non sono dovute a sue reali esigenze, ma a
considerazioni di marketing (il solito consulente bla... bla
.. bla).
Anzi, il cliente generalmente non è neppure in grado di capire
quali siano le sue reali esigenze, ed il compito forse più
difficile è proprio capire quali esse siano, senza farsi
confondere da quelle che il cliente crede di avere.


 confondere da quelle che il cliente crede di avere.
sottoscrivo, specie il secondo comma (bello, eh? :)
aggiungiamo: a volte, cioe' sempre, girare a computer un flusso
informativo implica cambiamenti abitudini. e di conseguenze (p.e.,
pubblicita' reale e potenziale delle info). in ambedue i casi la
contrattazione diventa durissima, e tanto piu' quanto piu' a favore
del cliente. assurdo e idiota, ma reale.
questo sia che il proponente della nuova gestione sia un consulente o
una sw house esterni sia che sia un tizio qualunque coinvolto nel
flusso medesimo, ma con le idee un filo meno confuse :P
ciao,a.

 del genere e non è stato facile.
Curiosità: cosa hai scelto, e perché?
Ciao
*Roby*