State of the art - vascogrilo/LDE GitHub Wiki

State of the Art

Page dedicated to the research and writing of the State of the Art.

What to search for

  • JavaScript
  • Dynamic languages
  • Integrated development Environments
  • Possible approaches on Live Development Environments
  • REPLs
  • Worksheets concept

A literatura que deves pesquisar sobre IDE's é apenas para os contextualizar: o que são, como são usados, quais as suas vantagens, etc. Podes também, caso arranjes referências, comparar IDEs de linguagens estáticas e dinâmicas. Acredito que aí vais notar que os IDE's de linguagens estáticas são consideravelmente mais capazes e aí ganhas argumentação quanto à necessidade de evoluir os IDEs de linguagens dinâmicas. Javascript penso que não precisas de entrar em pormenores da linguagem em si, mas generalizar para as linguagens dinâmicas, numa análise semelhante à dos IDE's: o que são, onde diferem das estáticas, onde são recomendadas e seria interessante destacar as facilidades e dificuldades em adoptar esta linguagens face às estáticas (acredito que aqui vais encontrar quem fale da falta de ferramentas de qualidade).

Useful Samples found on web searches

Static vs. dynamic issues in object-oriented programming languages

This article tries to establish a trade-off between static and dynamic perspectives both to help programmers choose the most convenient OO language/environment for their applications and to help designers introduce static/dynamic property melding into their project developments. Well-known OOPLs are used to exemplify static and dynamic properties—the chosen languages are Smalltalk-80, Eiffel, C++, and Java.

Static properties stem from any choice made at development time, i.e., before program execution, while dynamic aspects depend on choices and options that can be validated only at runtime, i.e., during program execution. One can assert that dynamic properties favor a perspective more oriented toward rapid application development 7 ; on the other, static characteristics, associated with intrinsic control, enable the detection of problems in the early development phases of programs

Even typed OOPLs should not neglect dynamic properties (and corresponding runtime overhead) for object creation, client/server binding, and server operation dispatching, as Eiffel, Java, and C++ do. The importance of dynamicity in OO environments is recognized by the extension of the basic Wegner's properties (objects, classes, inheritance) with polymorphism and dynamic binding. 46

However, the static perspective tends to determine a rigid programming development cycle that misses the notion of an integrated OO programming environment. Only such a programming environment could recognize classes as objects and permit class modifications by taking care of global consistency and by allowing incremental definition of new classes, as in Smalltalk-80.

Light Table - A New IDE Concept

Even with all of these things at our disposal, we're stuck in a world of files and forced organization - why are we still looking all over the place for the things we need when we're coding? Why is everything just static text?

Bret Victor hinted at the idea that we can do much better than we are now - we can provide instant feedback, we can show you how your changes affect a system.

Light Table is based on a very simple idea: we need a real work surface to code on, not just an editor and a project explorer. We need to be able to move things around, keep clutter down, and bring information to the foreground in the places we need it most

In Inventing on Principle, Bret showed us that we could live-edit games and write binary search in an editor that is constantly evaluating and showing you what's going on. The lispers among us are used to using the REPL to have an environment where we can try things out. But we can do better - we can do it in place and instantaneously. Light Table takes this idea as far as it can and doesn't just show you variables to the side, but actually shows you how the code is filled in. This lets you see how values flow through arbitrarily complex groups of functions. This level of real-time evaluation and visualization basically creates a real-time debugger, allowing you to quickly try various inputs and watch it flow through your code.

The first two languages it will support are Javascript and Clojure, but the application will be written in such a way that adding new languages can happen through plugins.

Adobe Brackets
Adobe Brackets App

This is a very early version of Brackets, a code editor for HTML, CSS and JavaScript that's built in HTML, CSS and JavaScript.

Tools shouldn't get in your way. Instead of cluttering up your coding environment with lots of panels and icons, the Quick Edit UI in Brackets puts context-specific code and tools inline.
Brackets is in sync with your browser. With Live Development, Brackets works directly with your browser to push code edits instantly, set breakpoints, and jump back and forth between your real source code and the browser view.
Do it yourself. Because Brackets is open source, and built with HTML, CSS and JavaScript, you can help build the best code editor for the web.

Languages Dimensions/Dementia

During the previous two years and this year, during January and February, the biggest declines were seen with Java ~5.5% down, C/C++ ~4.5% down, Visual Basic ~2% down and Perl ~1.5% down. The reason I point these out, is that is is market share for books, the unit sales numbers, which I will not supply, are a bit more alarming if you are on the declining list. During the previous two years and this year, during January and February, the winners seem to be: Javascript ~5.5% [almost exactly what Java lost], Ruby ~5.25%, .Net Languages ~3% and C# ~2.75. So when you look at the top for both lists, the totals are a bit different. There is a 3% difference on the winners side. What is says to me, is that most of the growth was seen in the four top languages, while the decline was spread a bit wider.

Dynamic Languages: Who Needs Them?

Systems language has strong static typing and a compile step which allow for improved performance but can reduce portability and definitely reduces flexibility

Dynamic languages are well suited to a variety of tasks, and this certainly includes the dynamic nature of the web and web applications. You will find them used across all industries, from gluing together backend systems to network-aware applications to desktop and web user interfaces. You will find them in embedded devices and controlling large manufacturing systems.

An IDE for dynamic languages should have similar features as that for any other language. The dynamic nature of these languages is a key advantage as well as a disadvantage. Since dynamic languages lack a compile step which typically does static analysis, an IDE can help users deal with this.

ActiveState’s Komodo IDE in particular has edit-time syntax checking for the main dynamic languages. This allows users to be aware of possible errors before testing occurs. When it comes to web development in particular, developers often find themselves dealing with multiple languages (e.g., PHP on the server and JavaScript on the client). Komodo again excels here by providing extensive support for web development languages and browser-side technologies. For example, you can simultaneously edit and publish server and client code, then debug both sides using Komodo.

Dynamic Languages Strike Back

Popular opinion of dynamic languages: slooooow! They're always talking about how Python is really slow, right? Python is, what, like 10x to 100x slower? And they have bad tools.

The two... sort of qualities that people associate with "dynamic": one would be sort of... runtime features, starting with eval, and the other would be the lack of type tags, the lack of required type tags, or even just escapes in your type system. These things work together to produce the tools problems and the performance problems, ok?

we're gonna talk about dynamic languages because people are out there today using them. They're getting stuff done, and it works. All right? And they really do have performance and tools issues.

So! The last [bullet point] is really interesting. Because nobody has tried, for this latest crop of languages, to optimize them. They're scripting languages, right? They were actually designed to either script some host environment like a browser, or to script Unix. I mean the goal was to perform these sort of I/O-bound computations; there was no point in making them fast. Except when people started trying to build larger and larger systems with them: that's when speed really started becoming an issue.

I mean obviously you can start with Squeak, sort of the latest Smalltalk fork, and it's beautiful. Or you can talk about various Lisp implementations out there that are smokin' fast, or they're smokin' good. Or in one or two cases, both. But also there's, like, the Boo language, the io language, there's the Scala language, you know, I mean there's Nice, and Pizza, have you guys heard about these ones? I mean there's a bunch of good languages out there, right? Some of them are really good dynamically typed languages. Some of them are, you know, strongly [statically] typed. And some are hybrids, which I personally really like. And nobody's using any of them!

So that brings us full circle back to the point of this topic, which is: the languages we have today, sorted by popularity at this instant, are probably going to stay about that popular for the next ten years.

So! I'm gonna talk a little bit about tools, because one interesting thing I noticed when I was putting this thing together, right, was that the ways you solve tools problems for dynamic languages are very similar to the way you solve perf problems. OK? And I'm not going to try to keep you guessing or anything. I'll tell you what the sort of... kernel of the idea is here.

So it's actually one of the few static-analysis that's actually carrying over in this new dynamic world where we have all this extra information. But you can actually use it in JavaScript to figure out function declarations that didn't actually get declared until way later in the code.

Another big point that people miss is that the Java IDEs, you know, that are supposedly always right? They're wrong. If you miss one time, you're wrong. Right? In Java Reflection, obviously, the IDE has no information about what's going on in that string, by definition. It's a string: it's quoted; it's opaque. And so they always wave their hands and say "Ohhhhh, you can't do Rename Method!" Even though Rename Method came from the Smalltalk environment, of course, right? And you say, "It came from the Smalltalk environment, so yes, you can do Rename Method in dynamic languages." And they say "NO! Because it'll miss sometimes!" To which, I say to you people in the screen, you'd be astonished at how often the Java IDEs miss. They miss every single instance of a method name that shows up in an XML configuration file, in a reflection layer, in a database persistence layer where you're matching column names to fields in your classes. Every time you've deployed some code to some people out in the field... Rename Method only works in a small set of cases. These Refactoring tools that, really, they're acting are like the Holy Grail, you can do ALL of that in dynamic languages. That's the proof, right? [I.e., static langs miss as often as dynamic – Ed.]

"hey, you say that you're ten times as productive in Python as in your other language... why aren't you using Python?" Slow? Admittedly, well, we'll get to that. And tools. Admittedly. But I think what's happened here is Java has kind of shown the new crop of programmers what Smalltalk showed us back in the 80s, which is that IDEs can work and they can be beautiful.

OK. So! Moving right back along to our simple dynamic languages, the lesson is: it's not actually harder to build these tools [for dynamic languages]. It's different. And nobody's done the work yet, although people are starting to. And actually IntelliJ is a company with this IDEA [IDE], and they... my friends show off the JavaScript tool, you know, and it's like, man! They should do one for Python, and they should do one for every single dynamic language out there, because they kick butt at it. I'm sure they did all this stuff and more than I'm talking about here.

And everybody else went and chased static. And they've been doing it like crazy. And they've, in my opinion, reached the theoretical bounds of what they can deliver, and it has FAILED. These static type systems, they're WRONG. Wrong in the sense that when you try to do something, and they say: No, category theory doesn't allow that, because it's not elegant... Hey man: who's wrong? The person who's trying to write the program, or the type system?

Bibliography found

List available at Literature Search Results.

Useful Samples

  • Ungar, D. (2007). "Dynamic languages (in reactive environments) unleash creativity [programming languages]." IEEE Software 24(5): 72, 74.

For the sake of creativity, let’s concentrate more on inventing new and better dynamic languages and environments and less on improving static languages. In programming, creativity thrives if the language gets out of your way and the environment submerges you in a sea of live objects.

Self, Smalltalk, or a Lisp Machine give you the sense of building—not writing—software. Instead of setting down text in a file, you create objects, link them up, and add slots one by one. You watch your program emerge before your eyes—not inside a window or two in a text file but in concrete pieces such as methods, attributes, and objects. Concentrating on dynamic behavior and freed from worrying about static properties (types), your ideas arrive and get recorded in a torrent.

Static typing invariably distracts from creative work, even when using the best available interactive development environments (IDEs). And despite the dynamicity of popular scripting languages such as JavaScript, Perl, and Ruby, the shortcomings of their development environments also hamstring creativity.

Each time they want to try something, they must write it in an editor, step through the type-checker complaints, and finally hit the debug button. This action takes them to another world, where all the windows change. They restart the program with breakpoints. If they think they’ve found the problem, they can make the change, stop the running program, pacify the type system, and take another trip around the statically typed maypole._

  • Nierstrasz, O., A. Bergel, et al. (2005). On the revival of dynamic languages. 4th International Workshop on Software Composition,SC 2005, April 9, 2005 - April 9, 2005, Edinburgh, United kingdom, Springer Verlag.

One may interpret this as a sign that the state-of-the-art in programming language design is stabilizing, or even that research in programming languages is essentially dead. Another interpretation, however, is that language design is in a rut due to our fixation with a certain style of language design. We have argued in this paper that static languages have hampered innovation, and furthermore that the death of file-based languages is the first step towards a new generation of dynamic languages.

We need to come to terms with persistency, inconsistency and change in programming languages. This means that dynamic programming languages should support the notion of software as living, changing systems, they should provide support multiple and possibly inconsistent viewpoints of these systems.

In many ways, we are still in the dark ages of programming language design. Consider, for example, the great innovations in programming languages over the past fifty years. To a large extent, most of these innovations were achieved in the 1950s and 1960s.

  • Paulson, L. D. (2007). "Developers shift to dynamic programming languages." Computer 40(2): 12-15.

Programmers want to shed unneeded complexity and outdated methodologies and move to approaches that focus on making programming simpler and faster, said Stephan Deibel, chair of the Python Software Foundation and cofounder of Wingware, a Python development environment vendor. With this in mind, many developers are increasingly using dynamic languages such as JavaScript, Perl, Python, and Ruby.

Dynamic languages are flexible and can let developers write more tothe-point code quickly and easily, said Python creator Guido van Rossum, who works on development research for Google.

Dynamic languages let developers get results quickly, said Blackfriars’ Howe.

Bray, like many other industry observers and programmers, predicted that dynamic languages will continue developing and growing in popularity and support. Bray noted that many dynamic languages don’t have the tools or performance necessary for building large software.

  • Kienle, H. M. (2010). "It's about Time to Take JavaScript (More) Seriously." IEEE Software 27(3): 60-62.

And then there’s JavaScript, which has gained considerable importance in realizing client-side functionality on Web apps. In a survey on the most popular programming languages, JavaScript made it to the Top 10.

While JavaScript is mostly written and hand-tuned by programmers, it may be increasingly generated by sophisticated tools. For instance, the Google Web Toolkit (GWT) lets developers write client-side code in Java that’s then automatically translated to JavaScript for execution._

  • Tiago Boldt Sousa, Ademar Aguiar, Hugo Sereno Ferreira (2011). Live Development Environments Concepts and Pragmatics for Runtime Development in Dynamically Typed Languages

Integrated Development Environments (IDE) for statically typed languages are mature and capable of helping developers to be more productive in their work. On the other hand, dynamically typed languages have been growing in popularity and adoption but their tools still follow concepts from static languages, some of which may not be so appropriate and e ective in these environments.

Following the same values of the language itself, the LDE becomes part of the runtime environment that hosts the developed code. It allows programmers to bene t from the extreme reflectivity in dynamic languages, easing the process of creating, debugging, maintaining, and automatically documenting their code through dynamic code inspection and LDE extensibility.

IDE simplify tasks associated with code production that otherwise had to be manually executed with several independent tools. IDE are usually composed with features such as: improved text editors, project navigation, code refactoring, compilation/execution, build automation, code versioning, debugging and more.

Ted Leung [7] describes such tools with the need to support most refactorings described in the book \Refactoring: Improving the Design of Existing Code"[4] while still maintaining performance and a small footprint. Bernstei wrote on the relevance of dynamic debuggers for dynamic languages[2].

Understanding dynamic types [1] is also very hard, if not impossible, to analyse with static parsing. A common practical example is the impossibility to understand a variable type in dynamic languages due to dynamic typing and the lack of type identi ers

A 2008 research [5] puts Visual Studio and Eclipse on the top of the most adopted IDE for .NET and Java, while still supporting other languages. By looking at both IDE and comparing the support for static against popular dynamic languages such as Ruby, Python or JavaScript, support for the later is rather weak. This is a direct implication of the attempt to apply design concepts that were created to solve problems in a static language context to dynamic languages

  • Bayne, M., R. Cook, et al. (2011). Always-available static and dynamic feedback. 2011 33rd International Conference on Software Engineering (ICSE 2011), 21-28 May 2011, Piscataway, NJ, USA, IEEE.

Most attempts to layer a static type system atop a dynamic language [3, 19, 34] support only a subset of the language, excluding many dynamic features and compromising the programming model and/or the type-checking guarantee.

Our work aims to integrate dynamic and static type systems in a single language. Previous work on this topic generally falls into two categories: strengthening a dynamic type system without losing the feel or expressiveness of the dynamic language, and adding a Dynamic type to a statically-typed language while retaining as many guarantees as possible about the statically-typed portion of a program. There is significant variation within the two categories, and also some notable outliers.

They are further confined to the static typing discipline during times in the development process where it does not yield the highest productivity.

A developer who chooses a dynamically-typed language forgoes the many benefits of static types entirely. A developer who chooses a statically-typed language is denied the ability to obtain dynamic feedback during the periods when their program fails to type-check. Most statically-typed languages embody the philosophy that an ill-typed program is of zero value—the compiler simply rejects it. We consider such programs to have value, in that a developer may be interested in execution paths that do not traverse the type-incorrect code or that are not affected by the inaccuracies in the source code’s type annotations.

Our goal is to enable programmers to work faster than they can with statically-typed languages, and to produce more reliable code than they can with dynamically-typed languages. Our approach enables the programmer to obtain either static or dynamic feedback whenever the programmer chooses. This overturns current IDE paradigms, putting the programmer in charge of the analysis tools rather than the analysis tools in charge of the programmer.

Bibliography found on articles read

List available at Other Literature.