Cosa si dovrebbe prendere in considerazione nella scelta di una lingua per lo sviluppo di applicazioni Web? [chiuso]

I'd throw in:

• Idoneità al problema in questione (il progetto è incentrato sul web? Utilizza molta concorrenza? Le prestazioni in tempo reale sono importanti? C'è un sacco di numeri coinvolti? È principalmente transazionale? ecc.)
• Qualità complessiva degli strumenti disponibili e librerie di terze parti
• Collegamenti per altre tecnologie (non ha senso usare un linguaggio che non ha librerie decenti per la tua scelta DBMS)
• Problemi legali e di licenza (di solito non è un problema, ma la concessione di licenze per gli strumenti può essere un fattore di costo)
• Supporto della piattaforma (ancora più importante se devi supportare più piattaforme, o vuoi essere in grado di cambiare piattaforma per strada)
• Integrazione con altri sistemi (ad es., .NET funziona meglio se combinato con altre tecnologie Microsoft, PHP e Apache vanno bene insieme, ecc.)
• Supporto paradigma
• Filosofia
• Proprietà semantiche (statiche e dinamiche, ecc.)
• Scadenza
• Stabilità (il tuo codice si romperà tra 5 anni? Sarai in grado di risolverlo?)
• La qualità dei programmatori disponibili (è facile trovare un centinaio di programmatori PHP, ma circa 95 di essi saranno incompetenti, è difficile riunire 5 programmatori Lisp, ma quelli che trovi li conoscono bene)
• Sicurezza: nessun linguaggio di programmazione è intrinsecamente sicuro o insicuro, ma alcuni forniscono più e migliori strumenti per la programmazione sicura di altri; ad esempio, evitare XSS è molto più semplice in Haskell (usa il sistema di tipi per distinguere tra stringhe raw e HTML) rispetto a PHP (ricorda di chiamare htmlspecialchars appropriatamente)

Di solito tutto ciò che conta è ciò di cui i tuoi attuali programmatori credono. Questa è l'unica cosa che conta e ciò che viene dopo di solito sta razionalizzando questo argomento.

Ogni pagina web può essere scritta praticamente in qualsiasi lingua completa. Ho scritto i servizi web in bash, e dietro a questo c'era una logica di design.

Anche le prestazioni sono un problema, ma devo ancora vedere una persona affermare che java è semplicemente terribilmente lento su progetti di dimensioni medie a volte (e la lentezza è semplice: la risposta dovrebbe essere di circa 200 ms per l'utente finale),

Anche la facilità d'uso e l'aderenza alla piattaforma sono un problema, ad esempio a volte si ritiene che gli sviluppatori di librerie ASP.NET abbiano solo sviluppato librerie nella loro vita, ma mai applicazioni web.

Nessuno potrà mai affermarlo come se credessero in una lingua, e lo sapessero, o non credessero, e non lo sapessero. Sono finito credendo nelle tecnologie, e forse i progetti sono andati avanti (di sicuro non scriverò mai più un'applicazione web in java 1.4 e spero che il postback sia stato ucciso)

La comunità java credeva seriamente da anni che J2EE 1.4 fosse adatto allo sviluppo di applicazioni web. Oggi, Spring è molto più vicino a Ruby on Rails o PHP rispetto a J2EE. La comunità .NET credeva seriamente che il postback fosse una buona idea. È stato un disastro dell'usabilità, in grado di estinguere i pianeti.

Sappiamo tutti che queste idee erano cerebrali, le comunità sono andate avanti. Abbiamo nuove idee cerebrali e un enorme gruppo di persone che affermano che è il modo di farlo.

Non ha importanza. Tieni i limiti di tempo cognitivi, assicurati che l'interfaccia utente sia reattiva e fai tutto ciò che i tuoi programmatori si sentono a proprio agio con esso.

Quindi

• Avere un elenco delle tecnologie che i tuoi attuali programmatori conoscono su una lavagna,
• Dai a tutti 5 bastoni e chiedi loro di posizionarlo ovunque lo vedano in forma.
• Prendi i primi due o tre, crea squadre e chiedi loro di creare il prototipo
• Analizza ogni prototipo in una sessione di revisione del codice
• Prendi una decisione.

Considererei il seguente ordine come fattori importanti prima di prendere una decisione:

1. Curva di apprendimento: se il tuo team ha difficoltà ad adottare e non ci sono buone introduzioni e tutorial, meglio saltarlo
2. Comunità attiva - intorno a questa tecnologia / framework / lingua è molto importante, questa è la forza trainante
3. Strumenti: quanti strumenti di produttività esistono attorno ad esso
4. Livello di comfort - degli sviluppatori di un team o di un'azienda
5. Disponibilità di sviluppatori che hanno esperienza e costruiscono alcuni prototipi con questo linguaggio / framework

Vorrei anche prendere in considerazione la possibilità di ospitare le tue applicazioni o distribuirle in un cloud (quindi ti consiglio di controllare quali lingue e framework sono supportati dai più grandi fornitori di cloud). Inoltre, un fattore importante da considerare sarebbe i requisiti non funzionali, la dimensione delle applicazioni e il numero di sviluppatori che lavorano su di essi.

• Tooling (molto alto)
• Comunità (molto alta)
• Curva di apprendimento (molto alta; se un sistema ha un'alta barriera all'ingresso non può essere buono per le persone nuove)
• Livello di conoscenza in azienda (medio-basso, se i primi 3 sono soddisfatti, non avrai problemi qui)
• Hype (medio, può essere utile per il reclutamento)
• Disponibilità di sviluppatori (medio-basso, solitamente dettata da hype e community)
• Costo degli sviluppatori (medio-basso: se tutto il resto va bene, il capo pagherà di più per gli sviluppatori)

Hai elencato tutto tranne il più importante: quale lingua fornisce le funzionalità più necessarie per lo stesso progetto su cui lavorerai.

Questo a volte è più importante. Potresti trovare molti sviluppatori eccellenti e farli lottare con la lingua di tua scelta per implementare le funzionalità richieste. Oppure potresti assumere meno sviluppatori magari con meno esperienza, ma chi otterrebbe il progetto perché la lingua che stanno utilizzando fornisce tutto il necessario.

Il mio capo dice sempre che il problema dovrebbe determinare la tecnologia da utilizzare e non viceversa. Abbiamo avuto una brutta esperienza nella società in cui lavoro. Abbiamo avuto uno sviluppatore geniale che si è fidato di una parte importante del progetto. Scelse la tecnologia che conosceva meglio e fallì. Il suo fallimento costò alla compagnia circa 6 mesi e molti soldi.

Penso che 3 di questi fattori siano davvero la stessa cosa. Se gli sviluppatori non sono disponibili, è possibile assumerne alcuni e addestrarli, ma aggiunge un costo. Alcuni campi hanno sviluppatori più costosi, il che aggiunge costi. E allenando quelli che hai aggiunto costi. Fondamentalmente, però, penso che molti sviluppatori professionisti possano passare da una lingua all'altra senza troppi problemi, anche se la raccolta di nuovi framework può essere un problema, e questo è solitamente all'inizio quando lavorano con una tecnologia. Personalmente, non mi preoccuperei troppo di questi fattori.

Strumenti e community Penso che siano entrambi attivatori: rendono uno sviluppatore molto più efficace a lungo termine. Questo mi preoccuperebbe di più. Lavoro principalmente con Microsoft e non sono un fan dei fan, ma la dimensione degli strumenti e della community è molto utile quando la paragono ad altre cose con cui ho lavorato.

Una cosa non menzionata è anche il fattore umano di un simile cambiamento. Ad esempio, abbiamo avuto un cambio di direzione che ha causato la partenza di alcuni sviluppatori. Erano già stati investiti in una particolare suite di tecnologie e fu lì che videro la loro carriera. Quando la compagnia è cambiata, se ne sono andati. Vale la pena pensare.