IDEas per le lingue dinamiche: fino a che punto puoi arrivare?

Smalltalk - un linguaggio altamente dinamico - ha sempre avuto un IDE superbo, in cui piccole cose come il refactoring automatico, SUnit (il nonno di tutti i framework Unit), "chi invia questo messaggio?", "chi implementa questo metodo? " e simili sono stati pionieri. Quindi sì, gli IDE possono effettivamente supportare linguaggi dinamici ad un livello che, fino a poco tempo fa, ha superato di gran lunga quelli delle lingue tipizzate staticamente.

S. Lott afferma che "I linguaggi dinamici non possono avere lo stesso tipo di completamento del codice utilizzato dai linguaggi statici. È essenzialmente impossibile."

"Essenzialmente impossibile" in un senso teorico, assolutistico? Sicuro. In senso pratico? Non proprio. Esistono molti modi per inferire il tipo per le lingue dinamiche, staticamente ( k-CFA , RoelTyper ), in fase di esecuzione ( PIC ), e altri metodi, come usare la cronologia recente di un programmatore - " In che modo la cronologia programmi può migliorare il completamento del codice ".

Certamente le community di Pharo e Squeak sono molto contente dei loro strumenti di completamento del codice .

Praticamente tutto ciò che conosci dagli IDE è stato sviluppato per la prima volta in Smalltak, che è un linguaggio dinamico. Tutto il resto li sta solo copiando. Quindi, chiaramente, tutte queste funzionalità sono possibili in linguaggi dinamici.

Oggi le lingue dinamiche sono dietro ai linguaggi statici. Ma perché?

Fino a poco tempo fa era universalmente creduto che la tipizzazione statica fosse superiore alla digitazione dinamica. Molti programmatori hanno cambiato idea più recentemente su questo punto. L'attenzione agli IDE per le lingue digitate dinamicamente non c'era.

Penso che le funzionalità per gli IDE siano meno utili nelle lingue digitate dinamicamente. Quando lavoro in Java o Objective-C, ritengo che l'IDE sia necessario per aiutarmi a lavorare con la lingua, ma lo stesso non è vero per le lingue dinamiche.

Alcune parti dell'attività sono più semplici in un linguaggio statico. È semplice per capire il tipo di un'espressione. Fare lo stesso in un linguaggio dinamico richiede l'analisi completa del programma o la registrazione dei tipi durante il runtime. Poiché molto di ciò che l'IDE ruota intorno ai tipi, questo ha un effetto.

Mi sono imbattuto in quel problema con Python, una specie di. Volevo che fosse il mio editor, ma ciò significava che non avrei avuto un ambiente IDE. Quindi, ho fatto il mio giro con i plugin vim. Attualmente, penso di avere un ambiente migliore per lo sviluppo che qualsiasi IDE ho usato in passato.

La mia configurazione è ospitata su github , sentiti libero di dare un'occhiata e di prendere ciò che ti piace. Per una rapida panoramica dei plugin:

• patogeno
• modalità python, per l'integrazione di corde, pioppi e pydoc
• vimpdb per un debugger Python
• progetto per un elenco di file in un progetto
• elenco di tag per il salto di tag
• supertab per completamento scheda
• snipmate per gli snippet
• conqueterm per una shell integrata, o prompt dei comandi, bash, python o ipython

Ci sono altre cose, ma ha tutte le caratteristiche che hanno gli IDE più popolari. Non mi è costato un centesimo e ho sfruttato tutto il potere di Vim. Divisioni, comandi di movimento, registri, salti, essere in grado di eseguire il mio intero ambiente di sviluppo con la tastiera ...

Have any particular IDEs (or less all-in-one setups) achieved a totally outstanding support for a dynamic language,

Considerando che la tua valutazione è difficile da comprendere ("totalmente eccezionale"? "clueless / overenthusiastic"?) è dubbio che qualsiasi IDE possa corrispondere allo standard implicito.

Il confronto banale con Eclipse + Java è sciocco perché i linguaggi dinamici non sono Java.

or is this still an 'unsolved' problem?

Non proprio.

Probabilmente è irrisolvibile. I tuoi requisiti ("mancanza di completamenti e altre risorse") rendono difficile essere più precisi.

Le lingue dinamiche non possono avere lo stesso tipo di completamento del codice utilizzato dai linguaggi statici. È essenzialmente impossibile.

Alcuni IDE fanno un buon lavoro di indovinare. Ad esempio, Eclipse dispone di plug-in per linguaggi dinamici.

Penso che questa presentazione di Steve Yegge sia ancora pertinente. in un guscio di noce ci sono alcuni ID di script Java decenti (intelliJ IDEA), ma le lingue dinamiche in generale stanno recuperando il ritardo, non perché c'è qualcosa di intrinsecamente più difficile nel rendere questi strumenti (o in effetti le lingue) sono solo le lingue statiche ottenute tutta l'attenzione prima.

Programma tutto il giorno in javascript / php e ruby lavorando su applicazioni web e il miglior IDE che ho trovato per questo è Aptana. Ha il completamento del codice per tutti e tre questi linguaggi (e python) raccoglie i miei vars locali e per di più quando si lavora con html e css raccoglie gli id nell'html per l'uso in css / javascript, e raccoglie i nomi delle funzioni per quando sto facendo qualcosa di veloce e sporco e scrivendo inline javascript (lo so male, ma a volte utile per la dimostrazione del concetto). Ha incorporato le attività rake e integrato nel supporto per git e una console a riga di comando. Mi ci è voluto un po 'per alzarmi, ma una volta fatto ho scoperto che non ho quasi mai lasciato il mio IDE durante la codifica e mi ha risparmiato un sacco di tempo.

Ho trovato che il supporto di Wing IDE per Python è davvero eccezionale. Fa un buon lavoro con il completamento del codice, e il suo debugger è potente come quello di Visual Studio per il C # non dinamico.

Posso attestare che non è bacato, lento o clueless. Non ho mai usato Eclipse, quindi sono ignorante su questo punto, ma penso che la domanda più grande sia: c'è qualche barriera intrinseca allo sviluppo di un IDE completo e che aumenta la produttività per i linguaggi dinamici. Data la mia esperienza con Python e Wing, sono propenso a dire che non è il caso. È, tuttavia, certamente più difficile.

Microsoft Visual Studio è un IDE utilizzato da molti programmatori e supporta IronRuby , IronPython e F #. La maggior parte considererebbe Ruby e Python un linguaggio di programmazione dinamico mentre F # lo sarebbe di meno.

In risposta al commento, F # è un linguaggio di programmazione.

F# (pronounced F Sharp) is a multi-paradigm programming language, targeting the .NET Framework, that encompasses functional programming as well as imperative and object-oriented programming disciplines. It is a variant of ML and is largely compatible with the OCaml implementation.

Mentre la definizione esatta di ciò che definisce esattamente un "linguaggio dinamico" è ancora in discussione, la maggior parte sarebbe d'accordo sul fatto che JavaScript sia più "dinamico" di C # per esempio. Secondo Wikipedia:

The definition of a dynamic language is ambiguous because it attempts to make distinctions between code and data as well as between compilation and runtime which are not universal. Virtual machines, just-in-time compilation, and the ability of many programming languages on some systems to directly modify machine code make the distinction abstract. In general, the assertion that a language is dynamic is more an assertion about the ease of use of dynamic features than it is a clear statement of the capabilities of the language.

Non voglio aprire una lattina di vermi qui. Alcuni suggeriscono che F # è più correttamente descritto come un linguaggio funzionale piuttosto che dinamico, e non ne farei un'eccezione. Quello che credo sarebbe giusto dire che è dei vari linguaggi .Net, F # è generalmente considerato il più appropriato per la programmazione dinamica rispetto a C # o VB.

Potresti voler vedere: Cosa qualifica un linguaggio di programmazione come dinamico?

La principale differenza tra i linguaggi tipizzati staticamente e le lingue digitate dinamicamente è che il sistema può sapere, di sicuro, che cosa significa un riferimento al simbolo in fase di compilazione.

Questo rende molto facile raccogliere le informazioni necessarie per creare un IDE corretto direttamente dalle informazioni generate dal compilatore in fase di compilazione (che viene spostato per la maggior parte del tempo fino all'ora di "modifica").

Se disponi di una firma del metodo stand-alone che dice solo che il metodo prende una "Cosa", come può un editor aiutarti a sapere cosa inviare? Come può aiutare a suggerire modi per utilizzare la cosa?

La tipizzazione anatra non aiuta nemmeno qui - anche l'editor più intelligente possibile non sarà in grado di dirti semplicemente perché il tuo oggetto ha un metodo .executeFooOp () che può completare il codice ".executeBarOp" su quell'oggetto (anche se potrebbe setacciare il resto della base del codice e fare alcune congetture intelligenti).

Se sai che è una "stringa" nella firma, tuttavia, conosci tutti i metodi che potresti chiamare su quella stringa E sei in grado di suggerire quella variabile quando quell'utente è nel mezzo di digitare una chiamata di metodo che richiede una stringa come parametro. Potresti anche suggerire sottoclassi in cui potrebbe essere inserito, se lo desideri.

Le informazioni non sono lì con le lingue digitate dinamicamente a meno che non sia possibile eseguire una scansione completa dell'intero codebase con qualcosa di MOLTO più intelligente del tipico compilatore.

Almeno per PHP molti IDE "capiscono" qualcosa come

/** @var $foo ClassA **/

Se documenti in modo standardizzato (in questo caso phpDocumentor ) l'IDE ne trarrà il massimo.

Da tutti gli IDE per le lingue dinamiche (lingue che risolvono il tipo al runtime) la migliore è ... Visual Studio for Python

• Informazioni sul tipo di bulling per Intellisense
• Navigazione
• debuging

Vale la pena provarlo.