Costruito nella libreria Scala lento?

The built-in libraries should be perfect.

In un mondo ideale, sì. Ma perfetto è il nemico del bene. Ogni creazione reale è sempre una sorta di compromesso. Ad esempio, può essere un compromesso tra prestazioni e flessibilità. O le prestazioni rispetto allo sforzo di scrivere la biblioteca. Se è "abbastanza buono per ora" e ci sono più problemi critici su cui lavorare, allora è meglio concentrarsi su quei problemi più critici. L'ottimizzazione della sola velocità è in genere falsa economia.

Un punto importante nel linguaggio / biblioteca / compromessi API è che cambiare le interfacce in seguito è difficile perché di solito rompe il vecchio codice costruito in cima all'interfaccia. Ma l'implementazione (cioè la velocità) può essere migliorata in seguito, quindi inizialmente si può approfittarne, se aiuta a focalizzare l'attenzione sull'interfaccia giusta. L'ordine di importanza è:

1. Interfaccia. Sintassi. Formati di file Difficile da modificare dopo il rilascio. Deve sforzarsi di iniziare subito.
2. Stabilità, correttezza. Le cose dovrebbero ovviamente funzionare come dovrebbero. Ma se no, può essere risolto.
3. Prestazioni, velocità. A volte cruciale, il più delle volte no. Può sicuramente essere migliorato in seguito.

Does anyone know where or how a normal guy like me can voice my opinion on this, i.e. where we can go to help shape the Scala language?

Penso che la parola chiave qui sia "bottleneck". Se si dispone di un caso di utilizzo reale in cui le prestazioni della libreria JSON sono il collo di bottiglia the , è possibile portare il problema nella mailing list di Scala. Se puoi migliorarlo da solo, bene, ma se qualcun altro dovrebbe migliorarlo, ci deve essere almeno un reale bisogno di farlo.

Il parser JSON fornito con la libreria standard si basa sui combinatori di parser. I combinatori di parser consentono di creare parser facili da comprendere e modificare, e lo fanno molto rapidamente. L'intera grammatica per JSON è definita nelle righe da 134 a 140 qui . Se dai un'occhiata a Solleva JSON , non puoi nemmeno selezionare un gruppo di linee come rappresentazione della grammatica.

Tuttavia, i combinatori di parser - almeno la libreria di Scala (Haskell li ha anche) - sono lenti. Forse il parser di packrat introdotto su Scala 2.8 si comporterebbe meglio, ma quel parser JSON è molto più vecchio e, se ho i miei dati retti, è stato creato principalmente come esempio.

Ora, Scala dovrebbe rendere disponibili solo le librerie perfette? Bene, date le risorse limitate disponibili, l'alternativa non è affatto una libreria JSON. Oggi andrebbe bene - ci sono molte alternative, dopo tutto. Ma al momento JSON è stato aggiunto alla libreria, e prima che l'adozione su larga scala di JSON rendesse le prestazioni critiche, è stato qualcosa di carino.

Se i creatori di Scala non dovessero rilasciare alcun codice finché non fosse perfettamente ottimizzato per le massime prestazioni, Scala probabilmente sarebbe alla versione 0.1, non 2.9.

Praticamente tutte le nuove lingue hanno inizialmente problemi di rendimento . Ripensa a Java 1 (se ne hai esperienza). Questo perché inizialmente i creatori si concentrano maggiormente sulle funzionalità e interfacce del linguaggio rispetto ai dettagli di implementazione, ed è ragionevole in questo modo. Nessuno può prevedere come (e se) una lingua e le sue librerie di classi saranno utilizzate in futuro (a parte i casi banali come la libreria di stringhe, ecc.). Quindi è meglio ottimizzare solo quando c'è un bisogno pressante per questo, piuttosto che dedicare tempo all'ottimizzazione di un pezzo di codice che in realtà non farà alcuna differenza visibile nella vita degli sviluppatori.

Inoltre, Scala è speciale in quanto è costruito sulla JVM, quindi tutte le librerie Java esistenti sono direttamente disponibili da essa. Se preferisci le prestazioni rispetto alla purezza del linguaggio, puoi sempre scegliere e utilizzare una classe / libreria Java appropriata.

Il suo software open source. Quindi, rispetto al software proprietario, gli autori tendono ad essere più sinceri su eventuali errori. Non c'è nemmeno il pretesto che tu abbia modo di influenzare lo sviluppo se non le richieste educate, o, scrivendo tu stesso i miglioramenti e inviando rispettosamente il codice migliorato per l'inclusione nella versione generale.

Data la natura di Scala e la nicchia che occupa (elaborazione parallela su larga scala) gli sviluppatori hanno probabilmente ragione a dare priorità alle prestazioni interne del codice che possono essere eseguite diverse migliaia di volte per una singola richiesta rispetto a un parser JSON che essere eseguito solo una volta per richiesta.

Data l'abbondanza di parser JSON open source veloci per JVM, questo sembra un perfetto esempio di non inventato qui . Una funzionalità integrata che è più lenta delle implementazioni già esistenti è un'indicazione che i creatori del linguaggio non si preoccupano troppo dell'uso del mondo reale, almeno per quanto riguarda questa funzione.

Quindi aggiustalo. Questo è il modo in cui open-source funziona con il mio uomo. Hai un prurito, lo graffi. Sai che puoi eseguire parser Java JSON in Scala, giusto?