vaclav · December 20, 2015 00:18
diff --git a/GPars Questions b/GPars Questions
 Hello GPars community,
 
 I am currently writting my bachelor thesis "Comparison of Concurrency Frameworks for the JVM"
 at the university of ulm in Germany. Since one qualitative property of an framework is also its
 community and support I decided to check that by myself by asking this questions. This Gist repo
 is thought to gather your ideas and oppinions about GPars relating to the questions below in oder
 to improve my comparison. Feel free to answer as controversial as you want :). Just add the points 
 you miss. Thank you very much.
 
 1.  Why do you prefer GPars over other frameworks such as Akka?
 Since I created it and since it well integrates with Groovy - the language I use frequently.
 Also, it helps me teach concurrency abstractions to both students and practicioners due to Groovy's familiarity to the Java falks.
 Being a multi-paradigm framework, GPars gives you more options to pick an abstraction from that fits best the problem at hands and also allows you to combine them in a single algorithm.
  -
  -
 2.  In which uses cases or type of use cases did you use GPars?
 Education
  -
  -
 
 3.  In which use cases is GPars especially good ? 
 GPars aims primarily at becoming a language-level concurrency library extending the core capabilities of Groovy as seamlessly as possible. Concepts, such as Agents, Tasks, Promises, Asynchronous Functions or Dataflow operators are meant to be low ceremony basic code building blocks, almost on the same abstraction level with, for example, while-loops, method definitions or locks. The purpose is to minimize the distraction to the programmer and her focus on encoding the application logic. 
 While many concurrency frameworks concentrate on performance, in GPars we pay extra attention to ease-of-use, intuitiveness and developers' performance, which is a common-place philosophy in the Groovy community, after all.
  -
  -
 4.  In which use cases is GPars not the best choice relating to performance or even feasibility?
 The STM support is very basic at the moment. Also, GPars doesn't address the domains of distributed systems and enterprise-level middleware. This is beyond the scope of the project, at least for the time being.
 On the other hand, it is encouraging to see frameworks like Nextflow (https://github.com/paoloditommaso/nextflow) to be created on top of GPars to expand into new areas. It validates the position of GPars as a solid corner-stone of bigger and more ambitious endeavors.

  -
  -
 5.  What features do you miss about GPars? (e.g. special development tools, further concepts,
    language support etc.)
  -
  -
  -
 6.  The next question can only be answered by the developers of GPars. What does the Future of 
    GPars will look like?(actual plans, ideals.... )
 The areas of further expansion include GPU programming, STM support improvement, better utilization of new Groovy capabilities, such as static compilation, @DelegatesTo or the planned MOP and perhaps a way to distribute computations across network.

  -
  -
	Hello GPars community,

	I am currently writting my bachelor thesis "Comparison of Concurrency Frameworks for the JVM"
	at the university of ulm in Germany. Since one qualitative property of an framework is also its
	community and support I decided to check that by myself by asking this questions. This Gist repo
	is thought to gather your ideas and oppinions about GPars relating to the questions below in oder
	to improve my comparison. Feel free to answer as controversial as you want :). Just add the points
	you miss. Thank you very much.

	1. Why do you prefer GPars over other frameworks such as Akka?
	Since I created it and since it well integrates with Groovy - the language I use frequently.
	Also, it helps me teach concurrency abstractions to both students and practicioners due to Groovy's familiarity to the Java falks.
	Being a multi-paradigm framework, GPars gives you more options to pick an abstraction from that fits best the problem at hands and also allows you to combine them in a single algorithm.
	-
	-
	2. In which uses cases or type of use cases did you use GPars?
	Education
	-
	-

	3. In which use cases is GPars especially good ?
	GPars aims primarily at becoming a language-level concurrency library extending the core capabilities of Groovy as seamlessly as possible. Concepts, such as Agents, Tasks, Promises, Asynchronous Functions or Dataflow operators are meant to be low ceremony basic code building blocks, almost on the same abstraction level with, for example, while-loops, method definitions or locks. The purpose is to minimize the distraction to the programmer and her focus on encoding the application logic.
	While many concurrency frameworks concentrate on performance, in GPars we pay extra attention to ease-of-use, intuitiveness and developers' performance, which is a common-place philosophy in the Groovy community, after all.
	-
	-
	4. In which use cases is GPars not the best choice relating to performance or even feasibility?
	The STM support is very basic at the moment. Also, GPars doesn't address the domains of distributed systems and enterprise-level middleware. This is beyond the scope of the project, at least for the time being.
	On the other hand, it is encouraging to see frameworks like Nextflow (https://github.com/paoloditommaso/nextflow) to be created on top of GPars to expand into new areas. It validates the position of GPars as a solid corner-stone of bigger and more ambitious endeavors.

	-
	-
	5. What features do you miss about GPars? (e.g. special development tools, further concepts,
	language support etc.)
	-
	-
	-
	6. The next question can only be answered by the developers of GPars. What does the Future of
	GPars will look like?(actual plans, ideals.... )
	The areas of further expansion include GPU programming, STM support improvement, better utilization of new Groovy capabilities, such as static compilation, @DelegatesTo or the planned MOP and perhaps a way to distribute computations across network.

	-
	-