n° 219
Novembre 2017
Dicembre 12, 2017, 08:34:03 *
Benvenuto! Accedi o registrati.
Hai dimenticato l'e-mail di attivazione?

Accesso con nome utente, password e durata della sessione
Notizia:
 
   Indice   Linux Windows Techassistance Gameassistance videogame hardware Aiuto Ricerca Agenda Downloads Accedi Registrati  


* Messaggi recenti
Messaggi recenti
Pagine: [1]   Vai giù
  Stampa  
Autore Discussione: Linguaggio di programmazione per sistema CAD  (Letto 20809 volte)
0 utenti e 1 Utente non registrato stanno visualizzando questa discussione.
stern
Newbie
*

Karma: +0/-0
Scollegato Scollegato

Messaggi: 3


Mostra profilo
« inserita:: Luglio 17, 2013, 11:49:43 »

Salve a tutti,
so che la mia richiesta può sembrare ambiziosa ma vorrei chiedervi un consiglio per il progetto di un software CAD a cui sto pensando da tempo.
Per tale progetto voi su che linguaggio puntereste? O meglio quale linguaggio di programmazione potrebbe essere efficace per far girare un motore CAD efficente?
Non ho molta esperienza in fatto di programmazione ma ho una convinzione: niente è impossibile, tutto si può imparare... e soprattutto non mi corre dietro nessuno!  Felice
Chi volesse avere qualche notizia in più e soprattutto darmi qualche dritta.... e magari chissà provare a creare una collaborazione, può scrivermi in privato.

Grazie a tutti voi!
Registrato
celeborn85
Global Moderator
Hero Member
*****

Karma: +58/-13
Scollegato Scollegato

Messaggi: 2148


Mostra profilo
« Risposta #1 inserita:: Luglio 17, 2013, 02:36:02 »

Il linguaggio che conosci meglio e con cui sei più produttivo.
Registrato

I moderatori invitano tutti gli utenti a prendere visione del REGOLAMENTO e a rispettarlo.
fermat85
Full Member
***

Karma: +6/-2
Scollegato Scollegato

Messaggi: 596


Mostra profilo WWW
« Risposta #2 inserita:: Luglio 17, 2013, 02:56:50 »

Il linguaggio che conosci meglio e con cui sei più produttivo.
per una cosa del genere non sarebbe meglio un linguaggio tipo il c/c++?
magari java risulterebbe un pò pesante ad esempio.....
Registrato

celeborn85
Global Moderator
Hero Member
*****

Karma: +58/-13
Scollegato Scollegato

Messaggi: 2148


Mostra profilo
« Risposta #3 inserita:: Luglio 17, 2013, 03:40:35 »

Quando si lavora su un progetto di queste dimensioni da soli, c'è una enorme probabilità che il progetto non sarà mai finito e allora non avrà alcuna importanza il linguaggio in cui è stato scritto e tanto meno le performance del programma. La produttività in questo caso è quindi a mio parere più importante.

Un programma scritto in linguaggi come C, C++ o Fortran (ma anche in assembly) non è inoltre necessariamente più veloce di un codice scritto in altri linguaggi normalmente considerati più lenti. È spesso possibile ottenere migliori performance con questi linguaggi, ma se non si è capaci ad ottenere queste performance, un linguaggio vale l'altro.

Probabilmente è possibile realizzare qualcosa anche in linguaggi come Javascript, eventualmente scaricando su un server o selle WebCL o su qualche servizio di cloud computing i calcoli più gravosi. E forse qualcosa esiste già.
Registrato

I moderatori invitano tutti gli utenti a prendere visione del REGOLAMENTO e a rispettarlo.
Max.Riservo
Global Moderator
Sr. Member
*****

Karma: +24/-0
Scollegato Scollegato

Messaggi: 850



Mostra profilo
« Risposta #4 inserita:: Luglio 17, 2013, 05:40:15 »

Stern wrote:
Citazione
Per tale progetto voi su che linguaggio puntereste? O meglio quale linguaggio di programmazione potrebbe essere efficace per far girare un motore CAD efficente?

Oltre a quanto già suggerito potresti anche valutare il linguaggio LISP oppure, molto più semplicemente potresti utilizzare AUTOCAD (pagando ovviamente la licenza) ed imparando il suo linguaggio di scripting (credo che abbia molti punti in comune con VBA)
Registrato

I Moderatori invitano tutti gli Utilizzatori del forum a prendere visione del REGOLAMENTO e a rispettarlo.
stern
Newbie
*

Karma: +0/-0
Scollegato Scollegato

Messaggi: 3


Mostra profilo
« Risposta #5 inserita:: Luglio 18, 2013, 01:46:55 »

Grazie a tutti per le risposte.
In effetti purtroppo non ho grande dimistichezza con la programmazione, ho solo scritto qualche routine molto basica all'università (C# e Java e alcune di basso livello assembler) e alcune per mio conto (Javascript e il vecchio basic) ma di certo non ho mai messo mano a un progetto del genere. In realtà il fatto è che... non so bene da dove partire  Che?!? Bocca cucita.
Il progetto che ho in mente nasce dalla necessità della ditta per la quale lavoro di avere un software CAD CAM per la progettazione rapida 3D. Questa idea ovviamente potrebbe voler dire beneficio per la mia ditta, beneficio per me in quanto metterei mano a un progetto unico. Ho il tempo per progettare e imparare a programmare e ottimizzare le risorse di questo progetto. Come ha già detto qualcuno, è vero che lavorare individualmente a una cosa del genere, soprattutto se alle prime armi, potrebbe voler dire portare avanti tutto con grande difficoltà ma credo anche nella flessibilità di un ambiente di sviluppo/progettazione che dia la possibilità di implementare ovvie modifiche e ampliamenti futuri step-by-step. Ci sono tantissime tematiche da elaborare con il tempo: il licensing, il multitasking, la portabilità, l'embedding sul numero maggiore dei sistemi. Mi rendo bene conto che è un progetto su cui bisogna lavorare molto e per molto tempo. Ma come dicevo non ho fretta.
Anche per questo ho postato questo messaggio: se c'è qualcuno qui in mezzo a noi che ha conoscenze, voglia e disponibilità questa può essere una base di partenza per avviare anche una partnership se possibile, sfruttando anche il mio know-how (che poi è l'idea che ho in testa).
Le prospettive di utilizzo di questa soluzione sul mercato sono molto buone.
Mi scuso per la "ridondanza".....  Ghigno
Registrato
M.A.W. 1968
** LEGGETE IL REGOLAMENTO ! **
Global Moderator
Hero Member
*****

Karma: +224/-19
Scollegato Scollegato

Messaggi: 2988


Discrete And Combinatorial Mathematics


Mostra profilo WWW
« Risposta #6 inserita:: Luglio 18, 2013, 06:53:46 »

Un progetto del genere, per quanto limitato, non può prescindere da considerazioni e stime innanzi tutto ingegneristiche.

Occorre premettere che la letteratura analitica e descrittiva sul software engineering è concorde nell'attribuire ai progetti di CAD/CAM meccanico un poco ambito piazzamento sul podio dei software più complessi e che inglobano il maggior numero di LOC, ossia di linee di codice sorgente: assieme ai moderni sistemi operativi mainstream, un paio di colossali DBMS e qualche ambiente di sviluppo integrato. Parliamo quindi, in questi casi, di singoli progetti che includono milioni di linee di codice (per fissare le idee, da due a otto/dieci) scritte direttamente dagli sviluppatori, e solo in minima parte generate automaticamente.
Una delle motivazioni più banali e intuitive di tale iperfetazione è il fatto che i software CAD/CAM sono in genere congegnati per ottenere massime prestazioni. Ne consegue il ricorso sistematico, diretto e indiretto (librerie, framework) da un lato ai linguaggi di più basso livello (Assembly e C), dall'altro a C++ per gli aspetti più propriamente OOP: ambedue gli approcci, seppure per motivi leggermente diversi, risultano molto prolissi, ossia proni a generare un elevatissimo numero di statement rispetto a linguaggi di più alto livello e quindi maggiormente concisi.

Ritengo che ciò lasci facilmente intuire, peraltro, come mai i costi di licenza dei migliori CAD siano tutt'ora attestati su cifre in dollari con quattro o cinque zeri, mentre rispetto agli anni Ottanta del secolo scorso molte altre categorie di software, partendo da livelli analoghi, sono passate ad avere a malapena un paio di zeri sul cartellino del prezzo, trovandosi anche a concorrere con un pletora di alternative del tutto gratuite dalle funzionalità non inferiori.

E' pur vero che esistono numerosi piccoli CAD dedicati ai vari settori di nicchia, e addirittura esistono semplici CAD/CAM grafici modulari bi e tridimensionali, destinati ad essere eseguiti su PC industriali(1) installati direttamente come MMI bordo di macchine a controllo numerico.

Tuttavia, per forza di cose mastodonti come Pro Engineer o Katia (in misura minore i vari ME-10, ME-30 HP o AutoCAD) sono dei punti di riferimento assai difficili da eludere, e rappresentano appunto l'emblema del progetto da vari MLOC evolutosi principalmente in linguaggi di livello basso e intermedio (Assembly e C) nell'arco di oltre un ventennio.

Questo implica conseguenze facilmente immaginabili, ma forse poco intuitive quando si passa ai grandi numeri, sul volume di anni-uomo necessari ad un progetto del genere. Con qualche concessione dal lato dei linguaggi impiegabili e forzando ampiamente le stime COCOMO sulla produttività mensile di un buon sviluppatore in un linguaggio come C++ o C#(2), supponiamo che riesca a consegnare 5kLOC collaudate error-free al mese. Facendo un conto della serva con un progetto giocattolo da 500kLOC di codice, occorrono quindi 100 mesi-uomo, poco più di otto anni. Se tale cifra, ampiamente sottostimata, rientra nella definizione di "non avere fretta" (nei progetti CAD del real world si parla tranquillamente di trenta o cinquanta anni uomo per release, a consuntivo), allora si può procedere nel discorso.

Si badi bene che 5kLOC/mese è già una stima mostruosamente sovradimensionata, i parametri usati nei più diffusi software di costing(3) sono di almeno otto/dieci volte inferiori. D'altro canto a noi qui interessa solo una primissima grossolana approssimazione, dunque si può anche equivalentemente ipotizzare di prendere in mano un progetto opensource già esistente, o almeno di derivare la maggior parte del codice da una nutrita serie di librerie e primitive di elaborazione grafica, laddove ovviamente le licenze lo consentano. Il che è comunque una falsa semplificazione, perché spesso il tempo necessario alla comprensione di codice altrui non formalmente (o semplicemente mal) documentato è nettamente superiore rispetto al tempo di scrittura ex novo, sia per i principianti che per i professionisti.

Inoltre, devo richiamare l'attenzione sul fatto che COCOMO o qualsiasi altro modello fa parte dell'ingegneria perché deve necessariamente fare i conti con l'imponderabile fattore umano: gli sviluppatori di cui si parla sono astrazioni, perfetti conoscitori del linguaggio e capaci di livelli di concentrazione superiori per un numero imprecisato di ore al mese. In questo caso la scarsa conoscenza del linguaggio da parte dell'unico sviluppatore ipoteca in modo assai pesante le assunzioni iniziali e aggiunge al progetto il rischio di non vedere mai la fine, al di là di qualche prototipo. A questo riguardo, restando ai prototipi e ai loro estimatori come Coad & Yourdon o molto più recentemente i sostenitori di Agile Development, una ultima (ma non meno importante) considerazione:
...credo anche nella flessibilità di un ambiente di sviluppo/progettazione che dia la possibilità di implementare ovvie modifiche e ampliamenti futuri step-by-step.

Purtroppo questo rischia di essere già l'epitaffio del progetto, come dimostra un numero impressionante di lavori opensource incompiuti, la cui storia è facilmente analizzabile perché pubblicamente disponibile (e c'è quindi abbondanza di letteratura analitica in merito). Un software di quel livello di complessità portato avanti senza una progettazione esaustiva a monte, quindi con una crescita non preregolata e normata da una roadmap anche massimale, rischia di arenarsi ben presto, o di dare - nel caso migliore - adito ad una serie di riscritture ex novo, come in molti progetti ancora attivi che hanno dovuto affrontare due, tre o più totali ristrutturazioni della base di codice (si pensi ad esempio ai vari browser opensource): riscritture che, nel caso del singolo sviluppatore o team ridotto, si ritraducono quasi sempre a loro volta in abbandoni forzati.



(1) Ovvero macchine con potenza di calcolo generalmente compresa tra quella di un 486 anabolizzato e di un Pentium II, ma in versione a bassissima dissipazione e range di temperatura esteso, es. Geode e suoi cloni.

(2) Trattasi ragionevolmente degli unici linguaggi adatti a mediare (nativamente, e a fortiori con qualche ottima libreria) tra learning curve e prestazioni di un'applicazione siffatta, infarcita di grafica vettoriale, rendering, trasformate, proiezioni, spline multidimensionali e innumerevoli altri calcoli matriciali in tempo reale.

(3) Nove su dieci di tali software, usati universalmente in ambito multinazionale e nelle maggiori softwarehouses, sono strettamente basati sulla revisione COCOMO del nuovo millennio o suoi immediati derivati come COSYSMO, oltre al supporto di numerose metriche che includono i miei amati function points già più volte richiamati anche su questi forum.
Registrato

I Moderatori invitano tutti gli utenti a prendere visione del REGOLAMENTO e a rispettarlo.

Un blog? Io? Occhiolino
stern
Newbie
*

Karma: +0/-0
Scollegato Scollegato

Messaggi: 3


Mostra profilo
« Risposta #7 inserita:: Luglio 19, 2013, 11:17:05 »

Grazie per la esauriente risposta M.A.W.
In generale il discorso è inattaccabile.
Tuttavia penso che, se è vero da una parte che il tempo per scrivere ex novo anche solo 1LOC di codice sia molto elevato per chi è alle prime armi, dall'altra c'è da dire che si stanno tirando delle somme che potrebbero non aderire alle necessità che questo progetto richiede. Questo progetto coprirebbe un'area di nicchia, in un settore dove di sicuro non esistono numeri immensi. La realtà è micro e le pretese (almeno in partenza) non potrebbero che essere adeguate alla realtà in cui sono calate.
Detto ciò, mi fa specie che una frase possa segnare l'epitaffio della novella. Senza l'embrione dell'idea e la volontà di perseguire gli obiettivi probabilmente ora saremmo ancora alle prese con la ruota e a giocare con l'acqua calda. Un ambiente di sviluppo dinamico è ormai la base per la maggior parte dei software commerciali che sfruttano le potenzialità degli accessi web per i servizi in live update. E di software in up-to-date via web ce ne sono. Microsoft (ed è un esempio ambizioso e probabilmente fuori luogo ma si fa per rendere l'idea) ne è l'esempio più lampante e di successo. Certo si parla di altro progetto, altri embrioni, altri sviluppi, ben altri fondi, altri cervelli......  Pianto
Registrato
M.A.W. 1968
** LEGGETE IL REGOLAMENTO ! **
Global Moderator
Hero Member
*****

Karma: +224/-19
Scollegato Scollegato

Messaggi: 2988


Discrete And Combinatorial Mathematics


Mostra profilo WWW
« Risposta #8 inserita:: Luglio 19, 2013, 04:13:17 »

Un ambiente di sviluppo dinamico è ormai la base per la maggior parte dei software commerciali che sfruttano le potenzialità degli accessi web per i servizi in live update. E di software in up-to-date via web ce ne sono.

Vedi, il problema non è la progressività dello sviluppo (se ci si pensa un attimo, nessun manufatto viene creato istantaneamente, neppure un oggetto stampato a pressofusione) né la possibilità di aggiungere nel tempo moduli o correggere eventuali errori. Occorre però progettare a priori praticamente tutte le features aggiuntive, anche solo in linea di massima, per evitare di trovarsi in situazioni altamente caotiche. In buona sostanza gli upgrade (al di là di banali bugfix) devono rispondere ad un preciso progetto, un'idea di massima di quello che sarà il software alla sua massima espansione.

Altrimenti succederà inevitabilmente, Murphy docet, che il carro armato sarà dotato di un'apertura ovale "standard" per le torrette intercambiabili, ma un bel giorno ci si troverà davanti alla necessità inderogabile di interoperare con una torretta armata a foro quadrato. Allora si costruirà un adattatore, che introdurrà ulteriori problemi di peso e stabilità, e così via... col codice non progettato esaustivamente succede esattamente lo stesso. Tanto che numerosi progetti opensource, i quali quasi per definizione non sono mai stati progettati, si sono trovati a buttare via letteralmente centinaia di kLOC per implementare alcune "semplici" features aggiuntive che avrebbero finito di rendere ingestibile il codice rappezzato più e più volte.


Personalmente trovo doveroso metterti in guardia contro simili rischi sul medio e lungo periodo. Questo fa parte di un più generale insegnamento, che istituzionalmente mi trovo spesso ad impartire: bravi sviluppatori si diventa con una certa facilità, ma progettisti e analisti si nasce. Gli aspetti più salienti di tali "mestieri", infatti, non possono essere trasmessi con l'insegnamento, e spesso neppure con l'esempio.

Poiché i miei studenti sono in genere dei trentenni laureati o addottorati, è facile fare un paragone con l'attività di fitness e altre varianti di allenamento con sovrappesi che in questi decenni vanno tanto di moda. Non è difficile, anzi è esperienza molto comune, vedere in spiaggia o in palestra ragazzotti tatuatissimi che sembrano il classico culturista delle caricature: bicipiti inutilmente e ridicolmente sovrasviluppati, deltoidi ipertrofici, tronco atletico... sostenuto però da patetiche gambette che sembrano due stecchini. Questo è, nella metafora, il tipico sviluppatore che ha passato anni ad imparare tutti i trucchi del suo linguaggio preferito, ma del tutto incapace a livello progettuale e analitico.

Tuttavia, quando stimolati a cercare un controesempio, i ragazzi non possono fare a meno di ammettere che nelle palestre è pressoché impossibile in pratica incontrare il caso opposto, ossia l'ipotetico mezzo atleta con gambe ipertrofiche da calciatore o fondista e il tronco fortemente sottosviluppato. Non ne hanno mai visto uno, probabilmente neppure tra i ciclisti. Questo per il banale motivo che gli esercizi di potenza multimuscolari per le gambe, come squat e stacchi da terra, promuovono da soli sufficiente testosterone libero a stimolare una crescita globale dell'intero sistema muscolare, anche se per assurdo si trascurassero gli esercizi complementari. Il che, al di là delle curiosità biologiche, calza perfettamente con la nostra metafora: un ottimo progettista se la cava comunque sempre ad ottenere un risultato qualitativamente armonioso, anche se all'atto pratico la sua produttività con il linguaggio X o Y è relativamente scarsa.

Dunque il miglior investimento che puoi fare consiste nell'allenare le tue capacità progettuali e metterle alla prova. Apprendere uno, due o dieci linguaggi sarà uno step secondario, comunque importante ma di minore rilevanza strategica.

Questo vale anche per chi, nella vita, probabilmente gestirà uno e un solo progetto software, quale che ne sia la dimensione e l'importanza. Lungi dal voler applicare prosaiche metriche mercatistiche per fattori che non risultano misurabili, è comunque importante ricordare che i compensi per progettisti e analisti nelle multinazionali e nelle altre grandi aziende realmente organizzate sono nettamente maggiori di quelli riconosciuti ai semplici sviluppatori, tranne casi del tutto esoterici. Il che, in linea di massima, riflette l'effettiva relazione d'ordine tra i diversi livelli di competenze e responsabilità.
Registrato

I Moderatori invitano tutti gli utenti a prendere visione del REGOLAMENTO e a rispettarlo.

Un blog? Io? Occhiolino
luigi1982
Newbie
*

Karma: +2/-0
Scollegato Scollegato

Messaggi: 40


Mostra profilo
« Risposta #9 inserita:: Luglio 19, 2013, 06:48:06 »

"Piccola" premessa: condivido pienamente le opinioni precedentemente espresse. Considero che tu abbia delle conoscenze base sulla "Computer Graphics".
Vista la voglia di "catapultarsi" in questa nuova esperienza, posso consigliarti di non fare il lavoro "sporco" ed affidarti a dei framework collaudati come:
Data la loro natura commerciale, puoi scaricare la demo e provare a fare qualche esempio. In questo modo ne potrai saggiare le funzionalità e valutare, mediante l'ausilio di uno di questi, se la tua idea è ancora fattibile Occhiolino
Inoltre, se non vuoi spendere denaro in licenze e conosci il python, puoi usare questo framework pythonOCC.

In ogni caso, buon divertimento  Ghigno!

Luigi

OT
Citazione
Occorre però progettare a priori praticamente tutte le features aggiuntive, anche solo in linea di massima, per evitare di trovarsi in situazioni altamente caotiche. In buona sostanza gli upgrade (al di là di banali bugfix) devono rispondere ad un preciso progetto, un'idea di massima di quello che sarà il software alla sua massima espansione.

Altrimenti succederà inevitabilmente, Murphy docet, che il carro armato sarà dotato di un'apertura ovale "standard" per le torrette intercambiabili, ma un bel giorno ci si troverà davanti alla necessità inderogabile di interoperare con una torretta armata a foro quadrato. Allora si costruirà un adattatore, che introdurrà ulteriori problemi di peso e stabilità, e così via...

Quanta verità, purtroppo!  Pianto
Il bello sopraggiunge quando, durante la fase di fase di sviluppo, si scopre che la nuova funzionalità cozza con le vecchie. Nel momento in cui vai ad aggiornare del problema il tuo team leader/project manager egli apostrofa: "E qual è il problema? E' così semplice, devi mettere solo un tasto!!!"  Pianto
 
Registrato
M.A.W. 1968
** LEGGETE IL REGOLAMENTO ! **
Global Moderator
Hero Member
*****

Karma: +224/-19
Scollegato Scollegato

Messaggi: 2988


Discrete And Combinatorial Mathematics


Mostra profilo WWW
« Risposta #10 inserita:: Luglio 19, 2013, 11:10:57 »

Nel momento in cui vai ad aggiornare del problema il tuo team leader/project manager egli apostrofa: "E qual è il problema? E' così semplice, devi mettere solo un tasto!!!"  Pianto

Qui si apre un capitolo doloroso per il sistema Italia, e non solo. Parte dei TL/PM nelle PMI informatiche mainstream, specialmente italiane, sono braccia rubate all'agricoltura - nel migliore dei casi.
D'altro canto, teste con siffatti requisiti si incastrano perfettamente nell'apposita scanalatura presente nelle convoluzioni cerebrali dei responsabili IT e degli uffici acquisti delle PMI e PA loro tipiche clienti. Dio li fa e poi li accoppia, come suol dirsi.

Purtroppo i primi sono sovente anche illicenziabili, essendo di norma congiunti di primo o secondo grado della proprietà, quando non direttamente i proprietari. In aziende meno bottegaie non padronali, trattasi sovente di raccomandati con peso inversamente proporzionale alla loro competenza, quindi inamovibili più di un Senatore a vita. Durante alcuni (rarissimi, che poi ho imparato a rifiutare) corsi esterni, screening di potenziali partner o audit preliminari per eventuali associazioni temporanee di imprese ho visto cose che voi umani eccetera eccetera, e più volte ho invocato la presenza di un esorcista.

Gli è che non basta l'esorcista: il diavolo si può scacciare dal suo ospite, l'idiozia no. Cretini da competizione di quel calibro sono dei buoni a nulla capaci di tutto. E come tutti gli idioti integrali, alla Clouseau o Pignon, spesso si credono pure informaticamente onniscienti, magari ostentando anche uno straccetto di laurea comprata conseguita... per anzianità chissà quando e chissà dove. Tanto che appena aprono bocca sciorinano un vero florilegio di bestialità. Tra le più garbate: confondono un linguaggio formale (come Z o LARCH) con un metodo interattivo (come quelli BDD-based) o l'interpretazione astratta; definiscono UML "un metodo formale"; non conoscono neppure le più elementari metriche di costing language-based né le definizioni a pagina 2 di una qualsiasi normativa sul software critico e altre amenità... da veri onniscienti. Il tutto davanti agli occhi sbarrati e alle espressioni di palese disgusto di tre o quattro auditor, quadri e dirigenti tecnici di una multinazionale, alcuni con cattedra parallela in prestigiosissime facoltà tecnoscientifiche (da Delft a Oxford): ovvero personaggi che, lo ricordo a chi sia abituato ai soli quasi-laureati italioti, sono non solo in possesso di master e PhD, ma hanno anche sostenuto almeno 4-5 anni di perfezionamento in un centro di formazione aziendale nel quale sgomitano almeno 1200 candidati per avere accesso a una decina di posti, e in quattro (dimensione tipica di un audit team qualificato) si suddividono almeno ottanta anni-uomo cumulativi di permanenza e di carriera in un'azienda che può permettersi di scremare tra sole eccellenze - dunque non sono certo lì per caso a pensare all'unisono "Ma questo emerito imbecille da dove diavolo viene?".
Registrato

I Moderatori invitano tutti gli utenti a prendere visione del REGOLAMENTO e a rispettarlo.

Un blog? Io? Occhiolino
ctraversa
Jr. Member
**

Karma: +14/-9
Scollegato Scollegato

Messaggi: 167


Mostra profilo
« Risposta #11 inserita:: Luglio 20, 2013, 08:40:13 »

Citazione
Parte dei TL/PM nelle PMI informatiche mainstream, specialmente italiane, sono braccia rubate all'agricoltura
Se posso permettermi di sintetizzare (da 4 parole a 2):
ZAPPATORI INFORMATICI

stern io ti consiglierei un approccio misto. Ossia invece che partire da zero per lo sviluppo di un CAD che è una tipologia/famiglia di applicativi sui quali migliaia di programmatori ci hanno già lavorato per decenni e per i quali hanno già trovato soluzioni a problemi tecnici che tu dovresti sicuramente affrontare di nuovo, piuttosto che riscoprire l'acqua calda ti consiglierei di partire da un CAD open source. Ti scegli quello che è più vicino alle tue esigenze e ci sviluppi solo le parti che potrebbero mancare. Ce ne sono molti ed alcuni davvero validi e magari più che sufficienti alle esigenze della ditta per la quale lavori. Fermo restando che essendo open source se devi aggiungerci delle funzionalità potrai sempre farlo contribuendo, se lo vorrai, col codice specificamente scritto, alla community. Il contro è che non sarai operativo nello scrivere codice dall'oggi al domani e magari non potrai utilizzare il tuo linguaggio preferito ma ti dovrai adattare a quello del CAD selezionato ma avrai da subito qualcosa di pronto da utilizzare senza dover trovare soluzioni a problemi oramai affrontati da decenni. Oggi sono finiti i tempi dei programmatori che fanno tutto da soli e potevano farsi il giochino sul mitico C64. Giusto per darti qualche nome sto pensando a nanoCAD o FreeCAD che è anche un CAD parametrico.
Registrato
M.A.W. 1968
** LEGGETE IL REGOLAMENTO ! **
Global Moderator
Hero Member
*****

Karma: +224/-19
Scollegato Scollegato

Messaggi: 2988


Discrete And Combinatorial Mathematics


Mostra profilo WWW
« Risposta #12 inserita:: Luglio 20, 2013, 06:55:02 »

Heilà Carlo! Ci sei anche tu, vecchio mio?  Ghigno

Sintetizzando, e sottolineando a parte l'assoluta necessità di una progettazione esaustiva, le principali opzioni sono:

1) Stesura ex novo in un linguaggio arbitrariamente scelto da un insieme ragionevolmente limitato (C#, C++, Python, Java...). I tempi di sviluppo si allungherebbero a dismisura, dunque è pressoché obbligatorio usare una libreria. Il che, a sua volta, influenza indirettamente la scelta del linguaggio. Nulla di insormontabile, ma occorrono alcune settimane di prove per valutare le librerie e l'ambiente di sviluppo nel complesso.
Pro: ci si muove su un terreno famigliare, anche se la geometria computazionale non è esattamente banale.
Contro: eventuali limitazioni all'uso commerciale imposte dalla varie licenze. In alternativa, costi di licenza per una valida libreria commerciale.

2) Uso di un progetto opensource esistente, già suggerito più o meno implicitamente in più post.
Pro: i tempi di sviluppo sarebbero compressi, ma forse meno di quanto ci si attenda (la lettura del codice altrui non è una passeggiata di salute).
Contro: eventuali limitazioni imposte dalla licenza, virtuale impossibilità di scegliere il linguaggio nel quale si è maggiormente produttivi (in realtà è quasi sempre possibile estendere un progetto del genere usando linguaggi multipli).
Registrato

I Moderatori invitano tutti gli utenti a prendere visione del REGOLAMENTO e a rispettarlo.

Un blog? Io? Occhiolino
Pagine: [1]   Vai su
  Stampa  
 
Vai a:  

Copyright © 2017 Edizioni Master SpA. p.iva : 02105820787

Tutti i diritti di proprietà letteraria e artistica riservati. - Privacy



powered by Simple Machines