6 ms·

Here's an IDE idea: create an industry standard plugin protocol. Most of the cool stuff an IDE does is code analysis and transformation e.g. refactoring, error

Here's an IDE idea: create an industry standard plugin protocol. Most of the cool stuff an IDE does is code analysis and transformation e.g. refactoring, error analysis, and autofill. The other half is "makes coding pretty", "provides good shortcuts", and other UI considerations. Now for the latter - that is great, and everyone has different strengths and weaknesses. And that is just a UX issue. For the former however, I don't know why I need to use different IDEs for different languages, or even different IDEs for different transforms to the same codebase in the same language (again, for the automated bits). It would be so much better for the world if there was some common protocol between user environment and code transformer. That way I could buy some of JetBrains awesome plugins and have my trusty Vim or Emacs environments use them. I could just keep using IntelliJ with MS' plugins for C# (and resharper of course). And so on. For stuff that really needs a special UI, we are in the age of the web browser. Provide a localhost server in your tool and make the reports etc live in a browser window, big GUI IDEs can provide a webkit that can link back to their own editors, but text editor users could still get the useful output. This "everyone does their own thing" without even pretending interoperability is getting old. We've been doing this coding thing for a little while now - we should be better at tooling that plays nice.

LordBron 13y ago
I'm with you on the interoperability, if anyone in the world should understand and be 100% completely behind that, it should be coders and makers of code tools. If we don't demand it and require it, then it's pretty hopeless for the rest of the tech world.
ericHosick 13y ago
> create an industry standard plugin protocol. I feel that Software Engineering/Science is lacking a body of knowledge: something which is basically required in other professional industries (architecture, medical, physics, electrical engineering), etc. Software Engineering/Science is at a disadvantage because there is no limitation placed on us by nature: an EE can't simply change the brightness of the sun to meet a requirement. We can. To create an industry standard plugin is really saying we need to create a common way to communicate information between systems and sub-systems in software. I feel we have not really figured out the best way to do this yet. Our industry is still young. I've put a lot of thought (about 6 years now) into a way to standardization communication between software systems and even parts of software. It's a hard problem to crack. > common protocol between user environment and code transformer I feel that once we crack the problem of communication between software parts, this will come naturally.
- gngeal 13y ago
  an EE can't simply change the brightness of the sun to meet a requirement. We can. Wow, you can change the brightness of the sun to meet a requirement? BTW, there are quite a few limitations placed on you by nature: uncomputable numbers, NP-completness, ...
  - Guvante 13y ago
    > BTW, there are quite a few limitations placed on you by nature: uncomputable numbers, NP-completness, ... Not really, NP-completness is only important if you want perfect solutions, which aren't necessary. Uncomputable numbers have no usage in real world scenarios. Finally it is important to note that while a physical turing machine cannot exist due to lack of infinite tape, real machines are also more powerful than turing machines, for instance by having a real time clock and communication abilities. For these reasons saying what we can and cannot do is quite complicated. For almost every situation possible, the only answer that is negative about capabilities is "it will take a while".
  - ericHosick 13y ago
    > Wow, you can change the brightness of the sun to meet a requirement? Sure, why not? sun.brightness = sun.brightness * 2.0f; In fact, a lot of games play with physics to get cool behavior. I can adjust the "constant" G in my game to be something other than 9.8 m/s to make it interesting. One moment the G vector may be down and then suddenly it flips up. Why not?
- mdaniel 13y ago
  FWIW, there is a SEBOK ( https://en.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge https://en.wikipedia.org/wiki/Software_Engineering_Body_of_K... ) but I doubt it is what you had in mind.
- jimbokun 13y ago
  "I've put a lot of thought (about 6 years now) into a way to standardization communication between software systems and even parts of software. It's a hard problem to crack." HTTP? It's not perfect, but it seems to be what our industry has settled on as the universal way for pieces of software to talk to each other. If you are thinking in terms of the payload, JSON seems to be filling that role.
al2o3cr 13y ago
"Here's an IDE idea: create an industry standard plugin protocol. " Just what we need - now there will be N+1 incompatible protocols! (shamelessly stolen from xkcd)
- deleted 13y ago
  [deleted]
- hornetblack 13y ago
  I guess someone could make a platform for plugins then also provide a translation plugin for IntelliJ, Eclipse, Emacs, Vim, VS etc. So they can all use the same plugins.
  - judk 13y ago
    Eclipse can be used as a plugin in vim.
aerique 13y ago
I'm already pretty happy we're starting to see PL tools that aren't coupled to a specific IDE like f.e. Jedi for Python. Of course an older example of this is ctags.
coolsunglasses 13y ago
Haskell community already standardizes through the use of library APIs and command-line applications like ghcmod. Any editor/IDE can invoke these tools.
- seanmcdirmid 13y ago
  How extensible is the Haskell IDE though? Is it's plugin model standardized?
  - coolsunglasses 13y ago
    The haskell-suite exists as standard of sorts, but the IDE specific tooling generally just involves invoking them like command line applications and using stdout in your editor/IDE.
    - seanmcdirmid 13y ago
      So you are saying Haskell is still stuck at the command-line non-IDE world of tooling integrated via primitives pipes and such? Unix was great in the 80s.
      - coolsunglasses 13y ago
        Considering the alternative in the Java ecosystem where none of the IDE tooling is reusable, it seems okay to me. The basic stdout-oriented nature of it means virtually any language/editor/stack can make use of it. That it's a command-line application also means it's "start up and throw away" which is easier to get working for most users than daemon based stuff. Typically once it's configured you don't touch it again. This allows people to build on each other's work which can lead to higher levels of abstraction and more human-oriented tooling. The alternative is everybody having to write Haskell parsers and analysis tools over and over again before getting to the parts that actually make their editor/IDE different. The Clojure community has a similar ethos of tool sharing and reuse. End users do not generally invoke these command line tools themselves, their editors/IDEs integrate them and offer the native trimmings the users would expect. Why are you being so hostile? You're not making me want to share anything I know. I'm talking about the kinds of ecosystems that let people like you (that work on live-editing environments) focus on the parts that matter to you and you're behaving like a prick.
deleted 13y ago
[deleted]
interpol_p 13y ago
While it's probably possible, I can't imagine it would be an simple task to generalise that level of code analysis across languages. If you look at Xcode, it saw a significant improvement when it started using clang to build its indexes. That is purely a C, C++ and Objective-C front end to LLVM. Xcode basically requires a significant portion of a compiler to provide a decent coding environment. What you are suggesting is almost to create a compiler "protocol" that can handle all languages. I am not sure how much value you would get from such a protocol.
judk 13y ago
Eclipse has a headless mode accessible from other tools. Eclim, for example.

LordBron 13y ago

I'm with you on the interoperability, if anyone in the world should understand and be 100% completely behind that, it should be coders and makers of code tools. If we don't demand it and require it, then it's pretty hopeless for the rest of the tech world.

ericHosick 13y ago

> create an industry standard plugin protocol. I feel that Software Engineering/Science is lacking a body of knowledge: something which is basically required in other professional industries (architecture, medical, physics, electrical engineering), etc. Software Engineering/Science is at a disadvantage because there is no limitation placed on us by nature: an EE can't simply change the brightness of the sun to meet a requirement. We can. To create an industry standard plugin is really saying we need to create a common way to communicate information between systems and sub-systems in software. I feel we have not really figured out the best way to do this yet. Our industry is still young. I've put a lot of thought (about 6 years now) into a way to standardization communication between software systems and even parts of software. It's a hard problem to crack. > common protocol between user environment and code transformer I feel that once we crack the problem of communication between software parts, this will come naturally.

gngeal 13y ago
an EE can't simply change the brightness of the sun to meet a requirement. We can. Wow, you can change the brightness of the sun to meet a requirement? BTW, there are quite a few limitations placed on you by nature: uncomputable numbers, NP-completness, ...
- Guvante 13y ago
  > BTW, there are quite a few limitations placed on you by nature: uncomputable numbers, NP-completness, ... Not really, NP-completness is only important if you want perfect solutions, which aren't necessary. Uncomputable numbers have no usage in real world scenarios. Finally it is important to note that while a physical turing machine cannot exist due to lack of infinite tape, real machines are also more powerful than turing machines, for instance by having a real time clock and communication abilities. For these reasons saying what we can and cannot do is quite complicated. For almost every situation possible, the only answer that is negative about capabilities is "it will take a while".
- ericHosick 13y ago
  > Wow, you can change the brightness of the sun to meet a requirement? Sure, why not? sun.brightness = sun.brightness * 2.0f; In fact, a lot of games play with physics to get cool behavior. I can adjust the "constant" G in my game to be something other than 9.8 m/s to make it interesting. One moment the G vector may be down and then suddenly it flips up. Why not?
mdaniel 13y ago
FWIW, there is a SEBOK ( https://en.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge https://en.wikipedia.org/wiki/Software_Engineering_Body_of_K... ) but I doubt it is what you had in mind.
jimbokun 13y ago
"I've put a lot of thought (about 6 years now) into a way to standardization communication between software systems and even parts of software. It's a hard problem to crack." HTTP? It's not perfect, but it seems to be what our industry has settled on as the universal way for pieces of software to talk to each other. If you are thinking in terms of the payload, JSON seems to be filling that role.

al2o3cr 13y ago

"Here's an IDE idea: create an industry standard plugin protocol. " Just what we need - now there will be N+1 incompatible protocols! (shamelessly stolen from xkcd)

deleted 13y ago
[deleted]
hornetblack 13y ago
I guess someone could make a platform for plugins then also provide a translation plugin for IntelliJ, Eclipse, Emacs, Vim, VS etc. So they can all use the same plugins.
- judk 13y ago
  Eclipse can be used as a plugin in vim.

aerique 13y ago

I'm already pretty happy we're starting to see PL tools that aren't coupled to a specific IDE like f.e. Jedi for Python. Of course an older example of this is ctags.

coolsunglasses 13y ago

Haskell community already standardizes through the use of library APIs and command-line applications like ghcmod. Any editor/IDE can invoke these tools.

seanmcdirmid 13y ago
How extensible is the Haskell IDE though? Is it's plugin model standardized?
- coolsunglasses 13y ago
  The haskell-suite exists as standard of sorts, but the IDE specific tooling generally just involves invoking them like command line applications and using stdout in your editor/IDE.
  - seanmcdirmid 13y ago
    So you are saying Haskell is still stuck at the command-line non-IDE world of tooling integrated via primitives pipes and such? Unix was great in the 80s.
    - coolsunglasses 13y ago
      Considering the alternative in the Java ecosystem where none of the IDE tooling is reusable, it seems okay to me. The basic stdout-oriented nature of it means virtually any language/editor/stack can make use of it. That it's a command-line application also means it's "start up and throw away" which is easier to get working for most users than daemon based stuff. Typically once it's configured you don't touch it again. This allows people to build on each other's work which can lead to higher levels of abstraction and more human-oriented tooling. The alternative is everybody having to write Haskell parsers and analysis tools over and over again before getting to the parts that actually make their editor/IDE different. The Clojure community has a similar ethos of tool sharing and reuse. End users do not generally invoke these command line tools themselves, their editors/IDEs integrate them and offer the native trimmings the users would expect. Why are you being so hostile? You're not making me want to share anything I know. I'm talking about the kinds of ecosystems that let people like you (that work on live-editing environments) focus on the parts that matter to you and you're behaving like a prick.

deleted 13y ago

[deleted]

interpol_p 13y ago

While it's probably possible, I can't imagine it would be an simple task to generalise that level of code analysis across languages. If you look at Xcode, it saw a significant improvement when it started using clang to build its indexes. That is purely a C, C++ and Objective-C front end to LLVM. Xcode basically requires a significant portion of a compiler to provide a decent coding environment. What you are suggesting is almost to create a compiler "protocol" that can handle all languages. I am not sure how much value you would get from such a protocol.

judk 13y ago

Eclipse has a headless mode accessible from other tools. Eclim, for example.