Può sopravvivere un linguaggio di programmazione a codice chiuso? [chiuso]

La risposta è sì, e no. Dipende dalle motivazioni commerciali dei potenziali clienti e dagli attributi della lingua e dai problemi che risolve.

No, il mondo non ha bisogno di un altro linguaggio informatico per scopi generici creato da un singolo o da una piccola squadra. Quando Perl, Python, Ruby, Java e Javascript sono stati creati, c'era un vuoto da riempire, le lingue proprietarie erano costose e la barriera all'ingresso era bassa. Rebol è uno che ha iniziato a pagare ed è ora gratuito. Guarda C # e vai a vedere quanto è più difficile ora e quanto sono più grandi le squadre, anche per le lingue più o meno libere.

Ma sì, il mondo ha bisogno di linguaggi di nicchia per riempire tutta una serie di ruoli specifici e pagherà bene per loro. Non posso citare esempi in quanto né tu né io ne abbiamo mai sentito parlare, ma vengono usati abitualmente in situazioni altamente specializzate e fanno soldi per i loro creatori. Risolvi un problema e verrai pagato.

Quindi per il tuo amico per fare soldi ha bisogno di una o più delle tre cose.

1. Una nicchia tecnica identificabile per la quale la sua lingua è la migliore soluzione disponibile, preferibilmente con una barriera ragionevolmente elevata all'ingresso per rallentare i concorrenti.
2. Un segmento di clientela identificabile con un problema che il suo linguaggio può risolvere e la capacità di pagare per risolverlo.
3. Un corpo di codice, documentazione, tutorial e competenze pre-scritti che consentirà ai clienti di metterlo immediatamente in azione e di iniziare immediatamente a risolvere i problemi.

I problemi menzionati nel fare affidamento su piccole aziende non sono specifici dei linguaggi di programmazione e sono facilmente risolvibili con mezzi commerciali.

Divulgazione: sono l'autore di un sistema di linguaggio di programmazione commerciale (Powerflex) che ha aiutato molte persone a creare aziende di software. Quella finestra si chiuse quando la finestra di Internet si aprì.

Una lingua non è open-source o closed-source in quanto tale. Ad esempio, G ++ è open source mentre MSVC ++ è closed source. ISO C ++ non è né, è uno standard non proprietario non libero.

Il tuo amico potrebbe rilasciare un'implementazione non ottimizzante Open-Source e vendere il fantasioso compilatore di ottimizzazione. L'interessante proprietà intellettuale non sarà necessaria per un'implementazione semplice.

Un linguaggio esistente che funziona con questo modello è PHP / Zend Server

Il suo linguaggio fa qualcosa per cui la gente pagherà?

Questa è davvero l'unica cosa che decide se un modello di business funzionerà. Avete un ampio mercato di utenti abbastanza grandi da non preoccuparsi dei costi di licenza? La lingua supporta dispositivi o standard che i clienti non possono vivere senza e che nessun altro supporta? È così incredibilmente bello che i clienti saranno in grado di assumere i programmatori più brillanti e più brillanti e ottenere enormi aumenti di produttività usando semplicemente questo linguaggio, e la direzione comprende questo scambio ?

Se qualcuno di questi o qualcosa di simile è il caso, allora il modello di business probabilmente funzionerà. Altrimenti, probabilmente non lo farà: prima o poi, qualcuno sta per escogitare una misura di riduzione dei costi che comporta il passaggio a un'alternativa più economica.

Credo che no, non c'è spazio per una nuova lingua con un'implementazione proprietaria venduta da una piccola azienda.

Innanzitutto, gli sviluppatori hanno molte altre implementazioni linguistiche gratuite (almeno come "in birra" e spesso "in speech") e non si preoccuperanno di provare un linguaggio (caro).

In secondo luogo, qualsiasi manager obietta immediatamente: cosa succederebbe - alla nostra codifica codificata nella nuova lingua - se la piccola azienda che fornisce l'implementazione della lingua fallisce? Questo argomento probabilmente proibirebbe a chiunque di acquistare l'implementazione della lingua!

^{Al contrario, un'implementazione del linguaggio del software libero può essere valutata grossolanamente dai clienti, che potrebbero sempre gestire il suo servizio con un altro provider, se la società originale che lo ha scritto va in bancarotta.}

Dal punto di vista del cliente, il costo dell'adozione di una nuova lingua non è nella licenza dell'implementazione, ma nelle competenze necessarie per utilizzarlo.

E ci sono molte implementazioni linguistiche di software libero che sono quasi inutilizzate.

Una lingua non può essere closed-source. Il suo compilatore e le sue librerie run-time possono essere closed-source. Una grammatica formale di una lingua può essere tenuta segreta ed essere protetta legalmente (NDAs, ecc.) E le tasse raccolte per l'uso.

Il tuo amico potrebbe rivendicare proprietà intellettuale o brevetti se la lingua è così nuova e originale. Io stesso dubito strongmente che ciò valga la pena.

Oggigiorno, la maggior parte delle aziende sceglie le tecnologie disponibili pubblicamente, non importa quanto sia laborioso lavorare per ottenere lo stesso effetto di un approccio closed-source. Successivamente, se il sovraccarico è molto grande, allora vanno a una soluzione standard di settore - linguaggi proprietari standardizzati (ad esempio Matlab), con una buona penetrazione e supporto.

Le lingue interne vengono solitamente create come DSL (lingue specifiche del dominio), e in questi giorni lo sforzo è minore rispetto all'acquisto di una DSL di qualcun altro e ad adattarlo. Inoltre, i DSL sono molto specifici per il dominio del problema.

Ora, non scoraggiamo il tuo amico dalla monetizzazione della sua lingua. Ci sono modi per farlo - venderlo ad una grande azienda, o far acquisire ad alcuni investitori l'idea e investirci -, ma il suo problema principale nell'approccio è che ha sviluppato una soluzione senza ricorrere al problema dello sviluppo. E questo non è il problema che lui considera il problema, è ciò che i suoi potenziali clienti considerano il problema. Quindi potrebbe uscire e parlare con questi amici senza dare dettagli sulla sua soluzione e convincere quei ragazzi a pagare - questo non è impossibile ma non molto probabilmente.

Ho avuto questa discussione personalmente quando uno dei miei clienti ha preso in considerazione lo sviluppo di applicazioni importanti utilizzando ColdFusion. Personalmente non riesco a pensare ad alcun motivo per usare CF (e pagarlo) quando posso usare PHP (e non pagare per questo). Tuttavia, CF ha una grande azienda dietro di sé che pacifica i fobiac OSS (gestisci abbastanza manager IT e sei destinato a imbattersi in alcuni di essi) ed è abbastanza buono che gli sviluppatori lo preferiscano.

Tuttavia, il problema è, ovviamente, che il tuo amico ha bisogno di trovare qualcosa di abbastanza buono e con sufficiente sostegno dietro di esso. Il primo non è un trucco banale in questi giorni con tutte le piattaforme open source completamente mature in giro, e il secondo richiede il supporto di una parte almeno delle dimensioni, ad esempio di Adobe.

Per non parlare del fatto che anche CF ha una quota di mercato marginale in questi giorni rispetto all'OSS.

In breve, se il tuo amico è abbastanza geniale da inventare qualcosa che faccia ombra a PHP, Python e agli amici e abbastanza esperto di business da venderlo a uno dei giocatori più grandi e stimabili del mercato , la risposta è "forse". Altrimenti, è un clamoroso "no".

Penso che la risposta sia decisamente no in questo caso. Avere un nuovo linguaggio guidato da una piccola entità causa un alto rischio di errori critici o funzionalità chiave mancanti.

Se quella lingua è proprietaria, allora come utente sei assolutamente fregato se la lingua non si evolve nella direzione in cui ne hai bisogno per il ritmo che ti serve. Se la lingua è libera, puoi gettare denaro o potere umano sul problema (che almeno per le grandi aziende è un'opzione).

Il tuo amico sarebbe molto meglio a vendere servizi o prodotti complementari. Fornire supporto, formazione, consulenza. Ricevi il pagamento per l'aggiunta di funzionalità specificatamente richieste. Fornire strumenti (ad esempio sotto forma di plugin commerciali per IDE popolari). Fornire alcune librerie sotto un modello di licenza commerciale (ma ancora con la fonte inclusa in opportune restrizioni).

Anche se odio scoraggiare il tuo amico, penso che sia improbabile che riesca a convincere la gente a pagare gli strumenti di sviluppo in questi giorni a meno che questo strumento non abbia un enorme guadagno in termini di produttività (come "produce software di lavoro facendo sembrare manager con gli occhi strabici sullo schermo mentre penso a buoni pensieri !!! "). Nel bene e nel male c'è pochissimo mercato per gli strumenti di sviluppo "pay-for-play" in questi giorni poiché la quantità e la qualità degli strumenti gratuiti è eccellente. (Linguaggi di testimoni come Java, Ruby, Python, Clojure - IDE come Eclipse e LightTable - database come MySQL e PostgreSQL - l'elenco può andare avanti e avanti e avanti e avanti e avanti ...). Gli auguro buona fortuna con questo sforzo.

Può. Se è:

• buono e / o abbastanza utile
• se è applicabile abbastanza facile e
• se non è troppo costoso

In realtà - per i principianti dovrebbe essere davvero strong su 2 primi elementi e molto scontato rispetto al suo vero valore.

Vedo che la maggior parte delle persone si lamenta dei manager malvagi che non vorranno pagare grandi somme per questo - non hai mai detto che il tuo amico sta chiedendo una fortuna per la licenza. Cosa succederebbe se chiedesse $ 500 all'anno e si risparmia un paio di centinaia di ore lavorative all'anno? Qualsiasi gestore intelligente potrebbe prenderlo.

Dipende dal fatto che la lingua offra qualcosa di abbastanza ingegnoso che io (rappresentante il cliente) sono disposto a pagare per questo.

Come project manager devo prendere in considerazione:

• Il tempo necessario per imparare / padroneggiare quella nuova lingua.
• Il guadagno di efficienza (tempo fino alla consegna) rispetto ad altre lingue. E supera il tempo per impararlo?
• Questo linguaggio risolve un problema che difficilmente può essere risolto con altri linguaggi?
• Questa lingua sarà ancora supportata in 5 anni, nel caso in cui il cliente effettui un'altra richiesta?

I primi 3 punti si applicano a tutte le lingue e in particolare il primo è difficile da superare per ogni nuova lingua, perché devo ragionare sul tempo di produttività molto bassa con qualcosa, e che è meglio che sia buono.

Il quarto punto è quello che si applica solo alle lingue a codice chiuso, come con quelle che sono dipendenti da terze parti, che potrebbero o non potrebbero esistere tra 5 anni a partire da ora. 5 anni prima da oggi, le app mobili non erano così importanti come oggi, la lingua da allora si adatterà alla situazione attuale e mi consentirà di scrivere anche app per dispositivi mobili? Sarà anche compatibile con i nuovi requisiti? Se esiste un tale requisito per il mio cliente, posso contattare lo sviluppatore di tale lingua e presentare una richiesta di aggiornamento?

Se a una di queste domande viene data una risposta con "no", allora può essere la migliore lingua del mondo, non posso usarla. E se sento che c'è una sola persona che ha inventato questa lingua nel suo "tempo libero" e ora lavora come una compagnia individuale, sarei molto sospettoso a riguardo e piuttosto non uso la lingua, a meno che non mi vengano promesse molto solide e il linguaggio offre qualcosa che nessun altro mi consente di fare.