An Attempt for a Tooling Platform to Supersede Them All

Transcript

1. AN ATTEMPT FOR A TOOLING PLATFORM TO SUPERSEDE THEM ALL SIMON SCHÄFER
2. This talk is about finding out what a tool actually is. Everyone has their pet peeves about tools but can we nevertheless find root causes for the general fact that tools make developers often unhappy? In the end it is probably just a talk about me being unhappy.
3. THE TOOLING CYCLE
4. Isn't the landscape easy and clear? We have compilers, editors, IDEs, documentation tools, build tools and a lot of variations of them.
5. A programming language is thought out As the first component a compiler is written An integration in editors follows If enough resources and interest exist more powerful tools like IDEs and build tools arise At this point someone finds out that we are doing it all wrong and that a new programming language shall emerge
6. As if we are caught in a cycle, this pattern repeats itself Driven by enthusiasm about potential improvements we follow the path But what if this is all wrong? No one questions the cycle, we continue it without knowing if it is the right thing to do. We don't know what would happen if we would break out. Could we arrive at something better or would we fall into chaos?
7. And that is not the only assumption that people make about tools today. There is this fight about editors vs. IDEs General belief: IDEs are slow and heavy but powerful, editors are fast and lightweight but useless for big projects.
8. I belief, this cycle is the origin for numerous of problems in our tooling landscape and the source for most poisonous assumptions. In the following I want to question the necessity of the cycle and explore where we could end if we break out of it. I would like to come up with a new model for a tool.
9. MAIN GOALS
10. UNIFIED INTERFACE
11. Universal idea: There should only exist one tool. User area: There shouldn't be a distinction between IDEs, documentation tools, build tools, the command line compiler, the formatting tool, linting tools etc. Dev area: Tools should still be different.
12. +--------+ +--------------+ +---------+ +--------------+ +-------+ | Editor | | Command Line | | Browser | | IDE Frontend | | <... +---+----+ +------+-------+ +----+----+ +------+-------+ +---+---+ | | | | | +---------------+----------------+------+--------+---------------+ | +---------+--------+ | Tooling Platform | +---------+--------+ | +----------------+-----------------+---+----------------+--------------- | | | | +----+-----+ +------+------+ +------+-----+ +----------+--------+ +-- | Compiler | | IDE Backend | | Build Tool | | Command Line Tool | | +----------+ +-------------+ +------------+ +-------------------+ +--
13. In the end, this forces us to rethink what a tool actually is.
14. COMPONENT-ORIENTED ARCHITECTURE
15. Main idea: Modular platform that leads to composable and therefore reusable components. Provide query language that hides the technical details of the communication among components.
16. A query language and composable components leads to automation. Example: Vim. Commands can be composed to programs and then used as often as needed.
17. My personal pet peeve: Linting tools in Scala. There is scalac -Xlint, Scalastyle, wartremover, Abide, Scapegoat, Linter and probably even more. There is a comparison article needed to describe their strengths and weaknesses: "Review of Scala Static Analysis Tools" by Paul Bleicher
18. In the end, this finally allows us to work together.
19. DECENTRALIZED CONTENT HOSTING FOR SEMANTIC INFORMATION
20. Main goal: Abstract over physical storage location of information. There are Q&A sites, code hosting sites, library hosting sites, project specific documentation, mailing lists, forums, social netorks, search engines and and and... We need a single interface not just for programs but also for information.
21. This only works with a communication layer and asynchronous boundaries among components. Example: Cloud IDEs. Except they are done wrong. What we really need is a protocol that allows our tools to share semantic information.
22. In the end, this allows our tools to be language independent.
23. WHERE TO GO FROM HERE? Highly indefinite and abstract goals. Please forbear with me that I won't tell you for now how I came up with these goals.
24. Or: What could we do with it, what we can't do already? FURTHER GOALS
25. UNITE EDITOR WITH BROWSER
26. Probably the most controversial goal. Browser nowadays can handle all sort of things - from 2D images to 3D games. Do we not want this power in our IDEs?
27. Examples Render commit and branch history of version control as a real graph (and not just as ASCII) - and edit it. Render dependency relationships of classes as a 3D star universe. Edit rendered HTML output of Markdown/Scaladoc/whatever documents.
28. Challenge: Get performance, memory usage and operation mapping right. For Reference, have a look at , or the article prosemirror medium-editor "Why ContentEditable is Terrible"
29. Unified Interface to the rescue! The basic idea is to have a single unique data structure that covers all sort of UI representations. A mapping from UI operations onto the internal data structure is needed.
30. +------+ +-------------------+ +-------+ +-------+ | Text | | Rendered Markdown | | Graph | | <...> | +--+---+ +---------+---------+ +---+---+ +---+---+ | | | | +-----------------+---------+-------+-----------+ | +-----------+-------------+ | Internal Data Structure | +-----------+-------------+ | +-------------+-------------------+-+----------------+---------------+--- | | | | | +---+--+ +------+------+ +--------+-------+ +------+------+ +----+--- | File | | Remote File | | Multiple Files | | Web Service | | Socket +------+ +-------------+ +----------------+ +-------------+ +--------
31. FUSE DOCUMENTATION TOOLS WITH IDE FUNCTIONALITY
32. Central interchange platform for all sorts of contributions Documentation needs to be available directly in the IDE Documentation needs to be interactive Built-in quality management User feedback
33. MODAL NAVIGATION
34. Basically modal editing of Vim moved to the next level. Modal editing: Different modes are available where every mode applies operations differently. Vim has editing operations that can be composed to more complex ones.
35. However: In Vim it is not possible to add new operations nor to add new modes. Modal navigation combines modal editing with composable operations, in fact it describes modes as operations. Example: In Vim the deletion of a git commit is not a built-in feature.
36. FIRST CLASS BUILD TOOL INTEGRATION
37. All modern IDEs have their own build tools, which are completely incompatible to all external (IDE independent) build tools.
38. Problems IDE needs to build metafiles. Internal information is incompatible among build tools. A build can't be mapped from one build tool to another. Metafiles often need to be created or tweaked manually. Some people ignore IDEs completely because they don't want to "fix the IDE".
39. A build tool is needed whose design is based on an abstract protocol and not on a programming language.
40. SUMMARY Main Goals Unified Interface Component-Oriented Architecture Decentralized Content Hosting for Semantic Information Further Goals Unite Editor with Browser Fuse Documentation Tools with IDE Functionality Modal Navigation First Class Build Tool Integration ...
41. SUMMARY We need tools that are based on an abstract protocol and not on particular languages. That is the only way how we can escape the cycle.
42. WHO IS DOING ALL THE WORK? We are in Open Source land, therefore: sschaef/tooling-research The goals of the platform available as a draft document For anyone who is interested if I ever come up with something useful: I'm on Twitter @sschaef_
43. THANKS FOR LISTENING!