[sophacles]

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.

[ericHosick]

> 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.

[mdaniel]

FWIW, there is a SEBOK ( https://en.wikipedia.org/wiki/Software_Engineering_Body_of_K... ) but I doubt it is what you had in mind.

[jimbokun]

"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.

[robert-wallis]

Unix communicates via text, stdin stdout stderr. That's pretty much a standard.

Windows PowerShell communicates with typed objects. COM components and .NET components are a Windows standard way of communicating between software parts. COM has been around for a long time.

Between computers, TCP/IP is a standard way of communicating. But without good documentation of the protocol adding an HTTP layer on top makes it easier to understand. But without good documentation of the protocol RESTful APIs makes it easier to understand. But without good documentation of the protocol WADL...

However I do agree about HTTP. Because I imagine there are more devs that understand HTTP than higher or lower protocols.

[ericHosick]

Http is a protocol we use to communicate between systems, that is true, but not the parts of software. For example, to print "Hello World" on the screen, we use a sub-routine like WriteLine. The standard we use to communicate between software sub-systems, in this case, is a function with parameters. So, WriteLine ("Hello World") pushes the text "Hello World" into the sub-routine WriteLine.

Parameters are, for basically all languages, the means by which information is communicated between sub-systems.

The thing is, it is really hard to standardize the communication between sub-systems because sub-routines can vary widely in how they are defined (the possible combination of parameters and types is quite high). In fact, you can end up with thousands of different sub-routines: even in the same program. Each one unique and thus "non-standard".

This is the problem we need to crack. How do we create frameworks that don't lead to thousands of specialized interfaces: each one making the framework that much harder to use.

[Nzen]

Four months ago, Bret Victor published his "Future of Programming" Talk. The most inspiring part to me was his 'prediction' of discarding brittle api`s for systems that negotiate a communication protocol dynamically. (Toy example: modem filter negotiation) http://vimeo.com/71278954 Relevant explanation @ 13:30-16:30.

[ericHosick]

Ya. I saw that and it was awesome.

> api`s for systems that negotiate a communication protocol dynamically

I think the first step is to find a very easy way to describe communication between sub-routines/processes. Once people can hook things up and compose the interaction of software with foreign/unknown systems (all in real time while the software is running) then we can get systems to start doing it dynamically (run on sentence but ya).

[gngeal]

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]

> 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]

> 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?

[coolsunglasses]

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

[seanmcdirmid]

How extensible is the Haskell IDE though? Is it's plugin model standardized?

[coolsunglasses]

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]

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]

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.

[seanmcdirmid]

> 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.

We were talking about how it would be nice to have a standard for interoperability IDE plugins, and you step in by saying Haskell gets it right by...not doing it at all. Unix was a great C dev environment, you had ed (later vi and emacs) for editing, and a bunch of command line tools for doing everything else. We tried to evolve that interoperability into Unix, but users wanted more tightly integrated tooling (hence the term "IDE"), and the unix shell model no longer cut it. Going back to the past won't help us much, especially when our tooling is increasingly interactive and not batch, where the former are very hard to write and standardize compared to the latter!

I'm sorry if my tone was hostile sounding. But as someone who works on IDEs full time, this rosy-tinted glasses belief that we were doing it the right way 30 years ago quickly annoys me.

I frankly don't buy the entire interop premise, the IDE is the language! How much do C and Haskell share in common? Not much beyond the foundation level, and people aren't really complaining about that, so why worry if IntelliJ doesn't share an architecture with Eclipse? Haskell has no popular IDE as far as I can tell; the community just isn't into them (though some exist, like Leksah), which is quite odd to me, as they have all that static type information sitting around!

[judk]

Sean works for Microsoft. They provide free kool aid.

And Visual Studio is in fact pretty handy.

Anyway, Haskell has an Eclipse plugin. EclipseFP, which integrates with some standalone programs.

But Sean's implicit claim that Power she'll style object passing is good...ew.

[al2o3cr]

"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)

[hornetblack]

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]

Eclipse can be used as a plugin in vim.

[interpol_p]

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.

[aerique]

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.

[LordBron]

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.

[judk]

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