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

EclipseFP, but really the case is that Haskell is so expressive that you don't need much from an IDE -- most of the asistace an IDE gives is already baked into the language. You don't need help writing repetitive code when the language lets you avoid repition. (E.g., type inference, point free notation, type classes, Deriving)

[coolsunglasses]

You're focusing on a different part than I was.

My point was that super fancy IDEs and plain old text editors alike could reuse the same tooling and not have to reimplement things like language parsing, analysis, and refactoring tooling.

Libraries like haskell-suite and command-line tooling like ghc-mod have succeeded in that. That ghc-mod happens to be a command-line application is utterly irrelevant to the end-user unless they want to go poking around.

And uh, you know, some people do sometimes.

Want to go poking around that is. Some people like owning and operating their tools.

I'm not saying "Hail Unix", I'm saying, "Hail IDE, Emacs, and Vim hackers not needing to write the same libraries over and over". The specific implementation is irrelevant.

Also if you refuse, on account of bias, to understand why people might find such a design (command-line application invoked from different programming environments to augment functionality) then you are damning yourself to be ignorant of how other people think and work.

This reminds a lot of the hatred some people have for the Twilight series. It's not a product designed to appeal to somebody like me, but clearly there's something to it because it has resonated with millions of people.

Is it really worth it to say "ugh yuck" and not even pause to reflect on what it is about this thing you dislike (Unix-style tooling) that so many other people have stuck with for decades? Are you feeling insecure because the average hacker these days is using a Mac or Linux machine?

>I frankly don't buy the entire interop premise,

I guess you can be that way if you want, but Emacs, Vim, Sublime Text and Eclipse all have Scion integration. Scion isn't quite like ghc-mod, note that I was talking about a general attitude that all IDE tooling should be reusable across multiple environments in Haskell, not just command-line applications.

Scion in this case is:

https://github.com/nominolo/scion

Scion is a Haskell library that aims to implement those parts of a Haskell IDE which are independent of the particular front-end. Scion is based on the GHC API and Cabal. It provides both a Haskell API and a server for non-Haskell clients such as Emacs and Vim.

You'll note that it's not actually a command-line app like ghc-mod. I use ghc-mod because it's "simple" and easily inspectable/dumpable for it's output at the terminal.

I know Emacs and vim users to both use ghc-mod.

buildwrapper mostly replaced Scion and is used by Leksah, Yi, EclipseFP (all IDEs). Buildwrapper provides its functionality via JSON.

Leksah, Yi, and EclipseFP are the primary IDEs Haskell users use, IF they're not using FPComplete's dilly which is web-based and is using the same Haskell IDE tooling as everybody else.

> Haskell has no popular IDE as far as I can tell

I don't really know that "IDEs are popular in Haskell"

but "Haskell has popular IDEs" is true.

Further, while I can't speak for vim users, the way most advanced Emacs users interact with their programming languages, especially Haskell, is an interactive hybrid IDE environment usually built on a REPL.

> How much do C and Haskell share in common?

The fuck are you talking about? I've only been talking about tool-sharing in the Haskell community this whole time.

> so why worry if IntelliJ doesn't share an architecture with Eclipse?

It's troubling because it means labor is wasted writing the same tooling (IDE) for the same language (Java). Hackers should be bothered when their colleagues are writing redundant code.

Maybe that's not an ethos at Microsoft or MSR, but it is in the various open source communities I've been in.

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

You clearly have not used Emacs or any of the Haskell tooling I use.

While some Emacs users still use things like etags/ctags, I do not. I have language-aware search/go-to-definition faculties just like any IDE in Emacs. The same goes for most other things I give a damn about. We have the same faculties as anybody else, we simply refuse to give up control over our tools because we don't buy into Microsoft's dystopian digital neo-feudalism.

I don't let that difference of vision cause me to act like a fucking prick to a perfect stranger on HN though. You are representing Microsoft and MSR - and all I've gotten from this experience is that Microsoft employees are totally out of touch with the work anybody else is doing. Unprovocatedly unpleasant to boot.

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

Haskell users aggressively leverage the types for secondary purposes, you're just not a Haskell user and are therefore ignorant to it. You're still wrong about Haskell users not using IDE-esque workflows, you just don't understand how that can manifest in a different form than being a Visual Studio customer.

>I frankly don't buy the entire interop premise,

I've conclusively demonstrated aggressive tool-sharing across different toolsets in Haskell, even with most people upgrading from Scion to buildwrapper when it became mature. It's rare for open source communities to keep up with each other that well.

> Unix was a great C dev environment, you had ed (later vi and emacs)

The proximity of mentioning ed and vi/emacs in the same sentence is not as clever as you think it is and really just shows how ignorant you are to how vimmers and Emacs users work these days.

My Emacs environment of today would be utterly alien to myself-10-years-ago. Or even 3-5 years ago. Or even 2 years ago. A lot of evolution can happen when you've been improving the same tooling over and over for multiple decades.

Emacs is nearly as old as Bill Gates's DUI arrest (1976 and '75). Do you really think people are using it the same way now as they were then?

I mean, for one thing, it starts up quickly now >:)

You should really try immersing yourself in how Emacs users work these days, you really have no idea at all. It could use a lot of work, so could everything, and there are some things that some IDEs for some languages will do better...but it bears more resemblance to those IDEs than to ed of all things.

The interactive REPL oriented workflow is something IDEs still haven't gotten right though. Pity that.

[seanmcdirmid]

> My point was that super fancy IDEs and plain old text editors alike could reuse the same tooling and not have to reimplement things like language parsing, analysis, and refactoring tooling.

Parsing and analysis are great examples: if you accept that batch is the best that can be done, they are completely reusable in lots of different contexts. As soon as you want something interactive, standardization and integration become much more tricky (I know directly from experience in writing interactive parsing and analysis tools).

> Also if you refuse, on account of bias, to understand why people might find such a design (command-line application invoked from different programming environments to augment functionality) then you are damning yourself to be ignorant of how other people think and work.

My early 90s self completely agrees with you. My current self is much more interested in non-batch interactive tooling, the mainstream is also.

> Maybe that's not an ethos at Microsoft or MSR, but it is in the various open source communities I've been in.

Along with much of the OO PL community, please don't forget (though we divide into static easy-to-tool languages and dynamic hard-to-tool languages).

> You clearly have not used Emacs or any of the Haskell tooling I use.

I was a heavy emacs user in the 90s (from about 92 to 2003 or so). It was a fine text editor, I would have never called it an IDE though.

> My Emacs environment of today would be utterly alien to myself-10-years-ago. Or even 3-5 years ago. Or even 2 years ago. A lot of evolution can happen when you've been improving the same tooling over and over for multiple decades.

Please educate me. How about your own workflow: does your emacs IDE provide code assist (I think Haskell Eclipse does right?), does it provide a nice debugger?

> You should really try immersing yourself in how Emacs users work these days, you really have no idea at all.

I used Emacs for 10 years in the 90s, early 00s, I don't miss it at all. Language-aware editing with code completion has been a huge win in PL and I don't see us going back. But these kinds of tools are complicated and not as interoperable as the old text pipe-based batch tooling was in the past.

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

[coolsunglasses]

PowerShell fans think proprietary binary object formats are somehow better than just plain old text and serialization where needed.

Bizarre.

ghc-mod's command line application has a "to lisp list" argument so that Emacs can parse the output data natively. I found that rather cute.

I know who Sean is, I still found the hostility unnecessary.