×
all 18 comments
sorted by:
best
topnewcontroversialoldq&a

[–]kamatsu 4 points5 points  (10 children)

Gah. I hate the arrow notation. I understand the arrow type class, and I know what arrows are categorically, but the arrow notation just looks like unreadable garbage to me. I wish scoutess didn't use it.

Also, to me, this smells of overengineering. That list of desired features looks like you want scoutess to do everything including the kitchen sink.

[–]AlpMestan 2 points3 points  (0 children)

We are discussing the use of arrow in our code base. We can get rid of this, if this proves to increase contribution, and overall understanding.

So, we are open to modifications, it won't be hard to adapt the code to just a usual Scoutess monad.

[–]stepcut251 3 points4 points  (0 children)

Arrows are likely to be dropped from scoutess in the near future. Personally, I like them, because it helps me think about the various pieces as 'black boxes' which get wired together. If you were to diagram all the steps you went though to do a build.. you might end up with something that looked quite a bit like that... a bunch of stages with typed inputs and outputs.

One problem with making everything a function is that it makes everything equal. In Scoutess, we try to only use arrow notation for the high-level pieces that end users might be wiring together. (aka, the black boxes). You get all those cool little building blocks and wire them up to do what you need. (Or use a pre-wired configuration, if you need something pretty standard). Having that separation of normal functions vs arrow things helps to emphasize that idea.

But, the arrow notation seems to be an obstacle for a lot of people. Since we aren't using anything arrow specific, we don't lose any type safety or functionality by dropping them, and we make a lot of people happier. I can save my fondness for arrows for places where you can actually do things which are impossible with monads.

The list of features is intentionally 'everything including the kitchen sink'. The overall concept is to create a single 'dashboard' that you can go to every morning and monitor the overall health of your project and see what needs to be done. Having to check 10 different places to find all the information you need is tedious and error prone.

We list all those different ideas to remind ourselves that we want to keep the system extensible and flexible. But, we are certainly going to focus on only the most important features for the meantime. It is definitely better to have a system that does 1 thing well than something with does 10 things poorly. But, it is also silly to have 10 completely independent systems to do 10 different things, where 90% of the work is the same. For example, there are many tasks which start with, "check out the latest version of the source code and see if anything has changed since the last run". And there are many other tasks that end with "report this important piece of information".

The key focus at the moment is making sure we have a really solid buildbot for cabal packages. While you can use general purpose systems like jenkins for that, there are certainly a number of improvements you can make when your buildbot understands what hackage and cabal are and how they work.

[–]donri[S] 2 points3 points  (5 children)

The goal seems to be to build a modular framework that makes achieving the listed goals somewhat trivial by simply writing the "recipes" for each task. One thing that might seem a bit out of place is the "scan communities" goal but it might still make some sense because you'll already be running Scoutess bots on some servers and it'll already be connected to your IRC channels to make announcements. The whole point of scoutess is to watch out for and report on things relevant to a package maintainer, and this could include things like questions about your package on StackOverflow.

As for the arrows, we could easily have simply a Scoutess monad instead. Jeremy has this to say:

the difference is in something like, output <- foo arg <- inputs. There you know that 'arg' doesn't come from another black box..not really sure why that is useful to know though :)

So it may or may not be useful. Time will tell, refactoring it later shouldn't be too hard anyway.

[–]sopvop 1 point2 points  (4 children)

So it may or may not be useful.

YAGNI. This is why much of scoutess smells of overengineering.

[–]Davorak[🍰] 2 points3 points  (2 children)

This

So it may or may not be useful. Time will tell, refactoring it later shouldn't be too hard anyway.

Makes it sound like a experiment with some potential benefit and if there is not benefit is easy to reverse.

[–]donri[S] 1 point2 points  (1 child)

Yea. I fear people are reading too much into the use of Arrow. The Arrow is just a Kleisli, meaning that Scoutess a b ≡ a -> Scoutess' b which incidentally is exactly what models the "explicit state" the post talks about. We could easily do this without Arrow, and we could easily do it with.

Also not sure what about arrow notation kamatsu finds to be unreadable garbage. It's quite straightforward to my eye. Perhaps just taste?

[–]winterkoninkje 5 points6 points  (0 children)

One of the things I dislike about the arrow syntax is that we have too many arrow symbols going on so you end up with a which-way-is-up mess. Part of that is Haskell's fault, using -> for lambdas and case binding, vs using <- for do-notation and list comprehensions. Even if you stick with H98, mixing and matching those features can lead to ugly/unreadable code. The arrows notation also adds -< to the mix and only exacerbates the original problem.

[–][deleted] 0 points1 point  (0 children)

YAGNI

That platitude is meaningless in rubyland, it is even more so here. There is nothing wrong with designing software, or putting thought into the process. Stumbling along blindly with no foresight isn't actually a virtuous thing and worthy of praise and emulation. When presented with "it may or may not be useful", your response is "well then don't find out, just delete it now". That's not a good way to end up with the best product possible.

[–]sfvisser 0 points1 point  (1 child)

Gah. I hate the arrow notation. I understand the arrow type class, and I know what arrows are categorically, but the arrow notation just looks like unreadable garbage to me.

It's not that hard, just arrows with input and output. I don't understand any category theory at all, but have no problem comprehending arrow syntax. Actually, I use it quite frequently, because it's way more readable (to me) than using the operators like (***), (&&&) and friends.

[–]kamatsu 0 points1 point  (0 children)

This post explains why I dislike it.

[–]kstt 1 point2 points  (3 children)

The project could certainly benefit from narrowing a bit its goals.

[–]stepcut251 1 point2 points  (2 children)

Yes, and no. We definitely will not tackle everything all at once. We are going to start by addressing the most pressing issues first, such as detecting when you need to apply some patches to your project so that people can install it :)

The over arching goal is to make it easier for maintainers to spend less time doing the uninteresting tasks while providing better quality than they currently can. But, that can vary a fair bit for each project. So, I think it is valuable to put thought up front about how to make sure different maintainers can itch their particular scratches.

So, one reason we have listed a lot of things that we would like to do be able to do is so that we can try to map out what sort of flexibility we need to build into the system. But, that doesn't mean we will try to bite off everything at once.

I should note that everything on that list is something that has personally wasted my time as a maintainer. If scoutess could actually address all those issues, I would have been able to spend more time doing interesting and useful work.

We should definitely create road map that indicates what order we plan to tackle things. Feedback from existing maintainers would be incredibly useful in developing that roadmap.

[–]kstt 1 point2 points  (1 child)

Do you want scoutess to be a single executable ? One of the key success of the nagios-family monitoring software is the simple and highly modular design : probes are just executable that must report status in the return code and standard output. I have had a great experience with this type of design.

As you said, their are a lot of building blocks that should be shared. Libraries are good at that ! One that stands to my eyes is an abstraction over a haskell package. For automated processing, we don't need to know if the package sources come from hackage, or github, or patch-tag ... Also, we don't need to deal explicitly with filesystem storage.

[–]stepcut251 1 point2 points  (0 children)

Scoutess uses a model similar to xmonad in that it is shipped as a library, and doesn't really become an executable until you provide your own Main.hs The different things that scoutess does are called 'services' and you can assemble them together into one or more executables to suit your needs. You can also add additional services via 3rd party libraries.

For maintainers of small, simple projects, they might just use scoutess as a command-line tool which does some administrative work for them. For a larger scale projects, you might have a scoutess daemon that runs on server automatically monitoring sources and reporting information.

An even more complex setup might include remote buildbots for testing on different operating systems.

There is definitely no requirement that there be only a single executable.

I think that the scoutess services are intended to be a lot like probes -- in that they should be self contained modules. But, by keeping them as Haskell functions, and not requiring that they be standalone executables, we can have a richer, typed interface for the inputs and outputs required by each service.

[–]hastor 0 points1 point  (1 child)

I really like the rationale for the design and the goals. I would be interested in slightly more focus on production monitoring. Good luck though!

[–]stepcut251 0 points1 point  (0 children)

That is an excellent idea! It definitely fits in with the idea of creating a 'dashboard' that project maintainers can use to monitor the overall health of their project in a simple way.

[–]antonivs 0 points1 point  (0 children)

Login required to read this? Ugh.