HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
nominolo
scion
Haskell2012–2013
nominolo / scion · Archived

scion

OLD, DEPRECATED: Use this instead https://github.com/haskell/haskell-ide-engine

2Distinct people
4Mentions
0Explicit recommenders
177GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

OLD, DEPRECATED: Use this instead https://github.com/haskell/haskell-ide-engine

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month4 dated mentions

Observed mentions: 2012-07-27 07:00:03 UTC to 2013-12-23 04:41:20 UTC.

012012-07-01 00:00:00 UTC to 2012-08-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJul 20122012-08-01 00:00:00 UTC to 2012-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2012-09-01 00:00:00 UTC to 2012-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2012-10-01 00:00:00 UTC to 2012-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2012-11-01 00:00:00 UTC to 2012-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2012-12-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-01-01 00:00:00 UTC to 2013-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-02-01 00:00:00 UTC to 2013-03-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2013-03-01 00:00:00 UTC to 2013-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsMar 20132013-04-01 00:00:00 UTC to 2013-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-05-01 00:00:00 UTC to 2013-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-06-01 00:00:00 UTC to 2013-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-07-01 00:00:00 UTC to 2013-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-08-01 00:00:00 UTC to 2013-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-09-01 00:00:00 UTC to 2013-10-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2013-10-01 00:00:00 UTC to 2013-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-11-01 00:00:00 UTC to 2013-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-12-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsDec 2013

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Jul 20122012-07-01 00:00:00 UTC2012-08-01 00:00:00 UTC101
Aug 20122012-08-01 00:00:00 UTC2012-09-01 00:00:00 UTC000
Sep 20122012-09-01 00:00:00 UTC2012-10-01 00:00:00 UTC000
Oct 20122012-10-01 00:00:00 UTC2012-11-01 00:00:00 UTC000
Nov 20122012-11-01 00:00:00 UTC2012-12-01 00:00:00 UTC000
Dec 20122012-12-01 00:00:00 UTC2013-01-01 00:00:00 UTC000
Jan 20132013-01-01 00:00:00 UTC2013-02-01 00:00:00 UTC000
Feb 20132013-02-01 00:00:00 UTC2013-03-01 00:00:00 UTC101
Mar 20132013-03-01 00:00:00 UTC2013-04-01 00:00:00 UTC000
Apr 20132013-04-01 00:00:00 UTC2013-05-01 00:00:00 UTC000
May 20132013-05-01 00:00:00 UTC2013-06-01 00:00:00 UTC000
Jun 20132013-06-01 00:00:00 UTC2013-07-01 00:00:00 UTC000
Jul 20132013-07-01 00:00:00 UTC2013-08-01 00:00:00 UTC000
Aug 20132013-08-01 00:00:00 UTC2013-09-01 00:00:00 UTC000
Sep 20132013-09-01 00:00:00 UTC2013-10-01 00:00:00 UTC101
Oct 20132013-10-01 00:00:00 UTC2013-11-01 00:00:00 UTC000
Nov 20132013-11-01 00:00:00 UTC2013-12-01 00:00:00 UTC000
Dec 20132013-12-01 00:00:00 UTC2014-01-01 00:00:00 UTC101

What Hacker News says

4 sources
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
Read the rest
(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.
In IDEas: Tools for Coders
I know of two modes for OCaml: TypeRex[1] and Merlin[2]. I've used both, and they both work reasonably well. The problem with TypeRex is that it requires changing your build, so it's not an easy option for companies that have some sort of custom build system in place. Happily, by the time I got around to working at a company like that, somebody had written Merlin which does not need anything like that. It even worked with js_of_ocaml, which was very impressive. I thought it was a very good tool. [1]: http://www.typerex.org/ [2]: http://kiwi.iuwt.fr/~asmanur/blog/merlin/ Emacs also has good support for a few other languages. Haskell has ghc-mod[3] and scion[4], for example. [3]: http://www.mew.org/~kazu/proj/ghc-mod/en/ [4]: https://github.com/nominolo/scion Similarly, there is ENSIME[5] for Scala. [5]: https://github.com/aemoncannon/ensim
Read the rest
e You can also use eclim[6] with Emacs, which integrates with Eclipse to offer rich functionality for Java. [6]: https://github.com/senny/emacs-eclim Of course, Emacs has language-aware editing for Emacs Lisp by default :). You can get similar support for most other popular dynamically typed languages as well. So yes, Emacs does support plenty of languages like that, although almost always through a plugin. Happily, with the new package manager, installing and managing plugins is now trivial.
In Why we're supporting Typed Clojure
Well, I'm a little biased, but I would learn Haskell. It's the one I learned first--in fact, I learned it during my very first college CS course. (The course, coincidentally, was in Scheme.) If I managed it as a freshman, it can't be all that difficult :P. Haskell has a couple of very good freely available books: Learn You a Haskell[1] and Real World Haskell[2]. I also found Write Yourself a Scheme in 48 Hours[3] very helpful. When I was learning OCaml, I could not find any terribly good resources. That said, it wasn't much of an issue, so I didn't look too hard--learning OCaml after knowing Haskell is very easy. There is going to be a Real World OCaml book at some point, but I think it's still a work in progress. [1]: http://learnyouahaskell.com/ [2]: http://book.realworldhaskell.org/ [3]: http://en.wikibooks.org/wiki/Write_Yourself_a_Sc
Read the rest
heme_in_48_H... I also think Haskell is good because it's more of a departure from languages you're probably used to. You can't sink back into your old habits, because everything is done completely differently. Of course, some people find it helpful to have less of a departure from what they're used to, so perhaps you might prefer OCaml because it's less different from normal languages. I use Haskell for my own projects (and, this semester, for research), and I used OCaml for an internship this summer. I think that for most tasks, they're roughly equally suited. If you want to do multicore concurrent or parallel code, I think Haskell has the edge, but I have not really done much of that in either language. OCaml has a very good JavaScript compiler called js_of_ocaml[4]. While Haskell does have some options for JavaScript as well like Fay[5] or UHC[6], I don't think it's quite as nice. I used js_of_ocaml during my internship and was very happy with it. So for web stuff, I'd probably go for OCaml. Both OCaml and Haskell have good backend web frameworks, but I haven't really used any of them. [4]: http://ocsigen.org/js_of_ocaml/ [5]: http://fay-lang.org/ [6]: http://www.cs.uu.nl/wiki/UHC If you happen to be on windows, installing OCaml is a pain. Haskell, with the Haskell Platform[7] should be much easier, but I haven't tried it myself. [7]: http://www.haskell.org/platform/ OCaml has a really good Emacs mode called typerex[8]. Haskell has some alternatives like ghc-mod[9] and scion[10], but I've never been able to get them to work. Admittedly, typerex was not easy to install either. [8]: http://typerex.org/ [9]: http://www.mew.org/~kazu/proj/ghc-mod/en/ [10]: https://github.com/nominolo/scion Ultimately, you wouldn't go wrong with either one. Moreover, the core ideas are fairly transferable between the two: you'll find that learning OCaml after Haskell or Haskell after OCaml is relatively easy. I would lean towards Haskell, but it's not a big deal. I just realized that I've written a whole bunch of paragraphs to say very little: either language is a great choice and I just happen to like Haskell more. Hopefully this is not too much of a deluge of information :P.
In Racket v5.3.2
I think GHC does something like that. At the very least, it exposes an API that lets you do all sorts of fun things. There are projects like Scion[1] that let you integrate that into an editor. [1]: https://github.com/nominolo/scion/ However, there is simply less drive to develop tooling like that for Haskell than there is for Java. Haskell is a much easier language to use given just a moderately intelligent text editor and a REPL than most others. Java, on the other hand, it verbose and annoying even with a very good IDE. So Haskell can have good support, but since it isn't terribly necessary it isn't anything like a top priority.
In Go is boring

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.