The quest for the perfect programming language for massive concurrency.

classic Classic list List threaded Threaded
55 messages Options
123
Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

kraythe .
Ok right up front, I'm a Java Guru, not a Scala or Erlang one. What that
means is that I know more than most debs about the core java language, but
enough to know where the problems are. And certainly java has many issues
but it also has massive momentum. I think one of the issues with Java can
be expressed in one little programming puzzle I came across recently:

*In a relevant language, create an array of 1000 numbers. Initialize all of
the values in the array to zero. Create two threads that run concurrently
and which increment each element of the array one time.*


Interesting? The solution in Scala that I came up with is the following.

def mtmap[A](data : List[A], threads: Int, f: (A) => A) = {
  import scala.concurrent.{ExecutionContext, Future, Await}
  implicit val executor =
java.util.concurrent.Executors.newFixedThreadPool(threads)
  implicit val context =  ExecutionContext.fromExecutorService(executor)
  val futures : Future[List[A]]= Future.traverse(data)(x => Future{f(x)})
  import scala.concurrent.duration._
  import scala.language.postfixOps
  val results : List[A] = Await.result(futures, 1 minute)
  results
}


Just thinking of doing this in Java will bring up some of the big problems
with Java; I will leave it as a mental exercise for the reader. The problem
is that Scala inherits some of them from the JVM and that has made me look
into Erlang. The goal being to select a language for the development of a
concurrent TCP/IP based application with thousands of users interacting in
a small space.

So far I think the contenders I have are Scala with Akka or Erlang. And
yes, I know there are evangelists to both and I will post this to an Scala
list to get their feedback as well (or something similar). Now, right up
front I am not peeing on either language. They both rock or they wouldn't
be on the list. The question is which should win the prize. There is no
going back once development is 1000 hours down the road.

*Scala: *
*Pros:*

   1. Based on Java Ecosystem so easier to staff because good Java devs can
   convert to Scala.
   2. Decent tools (which are getting better). Many libraries.
   3. Static typing with type inference.

*Cons:*

   1. Based on Java Ecosystem and inherit the problems of that ecosystem
   (i.e. immutable is a function of the design of a class, not of the language
   so it can't be guaranteed.), Also library code under the hood is not as
   rigorous as scala code in enforcing immutability so at some point you are
   rolling dice here.
   2. Scala is also more heavyweight than Erlang when it comes to spawning
   thousands of processes. Erlang was built from the ground up to do
   concurrency. For Scala its an Akka bolt on can carries the Java threading
   nightmare (shared memory, etc).
   3. Scala is not as fast. My server will be doing billions of vector math
   calculations per day and they have to be in the terms of milliseconds of
   latency. It has to be that if I have a user R in the server at position V
   where V is a vector, I need to calculate all other actors within 50 units
   and get that answer in milliseconds so that only the network latency is the
   bottleneck. Some of this can be helped with algorithms like spatial grids
   and so on but still we are looking at a couple of hundred vector math calls
   per second.
   4. Scala is harder to hook up to dozens of nodes and move actors from
   node x to node y than Erlang, mainly because that was one of the design
   goals of Erlang.


*Erlang:*
*Pros:*

   1. Built for concurrency. Can handle dozens of hardware nodes, build
   massive applications of the kind I am trying to deploy. Think of 100k users
   connecting to the cluster with a TCP connection and interacting over that
   connection which interacts with any or all of the other 100k actors.
   2. Built from the ground up with immutability in mind. Immutability is a
   language feature, not compromisable. Its not JVM based and so is not under
   the same issues as Java is.
   3. There is merit in the thought that static typing is sometimes a
   hinderance to a language.

*Cons:*

   1. The tools are, well frankly, garbage. Sorry, in 2014 to be pushed
   back to coding with VIM and makefiles is primitive. Rebar is crytptic and
   just the pet project of a guy on GIT. Compared to Gradle, Maven and even
   (though I don't care for it much) SBT, rebar is ... lacking. I want to
   spend time working on my business logic, not fighting tools. There are
   plugins for eclipse and intellij but they have minimal functionality and i
   keep reverting back to vim.
   2. Much harder to staff than Scala because it is not Java based.
   3. Fewer general purpose libraries and no major central repositories.
   I don't want to write code to create JSON, that isnt part of my business
   scope. I will pick that one of the shelf If i can.
   4. Records as the only structured data type is ... annoying.


The problem I have is I can't find the perfect solution. Erlang is
compelling but also is Scala.

Opinions?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140130/fe4609fc/attachment.html>

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Aaron France
Then what about Clojure?

You can stay on the jvm, use Java  code and it has a focus on concurrency.

Whilst it fails hard on fault tolerance it could be an escape hatch for
those stuck with the jvm

Aaron
On 30 Jan 2014 17:22, "kraythe ." <kraythe> wrote:

> Ok right up front, I'm a Java Guru, not a Scala or Erlang one. What that
> means is that I know more than most debs about the core java language, but
> enough to know where the problems are. And certainly java has many issues
> but it also has massive momentum. I think one of the issues with Java can
> be expressed in one little programming puzzle I came across recently:
>
> *In a relevant language, create an array of 1000 numbers. Initialize all
> of the values in the array to zero. Create two threads that run
> concurrently and which increment each element of the array one time.*
>
>
> Interesting? The solution in Scala that I came up with is the following.
>
> def mtmap[A](data : List[A], threads: Int, f: (A) => A) = {
>   import scala.concurrent.{ExecutionContext, Future, Await}
>   implicit val executor =
> java.util.concurrent.Executors.newFixedThreadPool(threads)
>   implicit val context =  ExecutionContext.fromExecutorService(executor)
>   val futures : Future[List[A]]= Future.traverse(data)(x => Future{f(x)})
>   import scala.concurrent.duration._
>   import scala.language.postfixOps
>   val results : List[A] = Await.result(futures, 1 minute)
>   results
> }
>
>
> Just thinking of doing this in Java will bring up some of the big problems
> with Java; I will leave it as a mental exercise for the reader. The problem
> is that Scala inherits some of them from the JVM and that has made me look
> into Erlang. The goal being to select a language for the development of a
> concurrent TCP/IP based application with thousands of users interacting in
> a small space.
>
> So far I think the contenders I have are Scala with Akka or Erlang. And
> yes, I know there are evangelists to both and I will post this to an Scala
> list to get their feedback as well (or something similar). Now, right up
> front I am not peeing on either language. They both rock or they wouldn't
> be on the list. The question is which should win the prize. There is no
> going back once development is 1000 hours down the road.
>
> *Scala: *
> *Pros:*
>
>    1. Based on Java Ecosystem so easier to staff because good Java devs
>    can convert to Scala.
>    2. Decent tools (which are getting better). Many libraries.
>    3. Static typing with type inference.
>
> *Cons:*
>
>    1. Based on Java Ecosystem and inherit the problems of that ecosystem
>    (i.e. immutable is a function of the design of a class, not of the language
>    so it can't be guaranteed.), Also library code under the hood is not as
>    rigorous as scala code in enforcing immutability so at some point you are
>    rolling dice here.
>    2. Scala is also more heavyweight than Erlang when it comes to
>    spawning thousands of processes. Erlang was built from the ground up to do
>    concurrency. For Scala its an Akka bolt on can carries the Java threading
>    nightmare (shared memory, etc).
>    3. Scala is not as fast. My server will be doing billions of vector
>    math calculations per day and they have to be in the terms of milliseconds
>    of latency. It has to be that if I have a user R in the server at position
>    V where V is a vector, I need to calculate all other actors within 50 units
>    and get that answer in milliseconds so that only the network latency is the
>    bottleneck. Some of this can be helped with algorithms like spatial grids
>    and so on but still we are looking at a couple of hundred vector math calls
>    per second.
>    4. Scala is harder to hook up to dozens of nodes and move actors from
>    node x to node y than Erlang, mainly because that was one of the design
>    goals of Erlang.
>
>
> *Erlang:*
> *Pros:*
>
>    1. Built for concurrency. Can handle dozens of hardware nodes, build
>    massive applications of the kind I am trying to deploy. Think of 100k users
>    connecting to the cluster with a TCP connection and interacting over that
>    connection which interacts with any or all of the other 100k actors.
>    2. Built from the ground up with immutability in mind. Immutability is
>    a language feature, not compromisable. Its not JVM based and so is not
>    under the same issues as Java is.
>    3. There is merit in the thought that static typing is sometimes a
>    hinderance to a language.
>
> *Cons:*
>
>    1. The tools are, well frankly, garbage. Sorry, in 2014 to be pushed
>    back to coding with VIM and makefiles is primitive. Rebar is crytptic and
>    just the pet project of a guy on GIT. Compared to Gradle, Maven and even
>    (though I don't care for it much) SBT, rebar is ... lacking. I want to
>    spend time working on my business logic, not fighting tools. There are
>    plugins for eclipse and intellij but they have minimal functionality and i
>    keep reverting back to vim.
>    2. Much harder to staff than Scala because it is not Java based.
>    3. Fewer general purpose libraries and no major central repositories.
>    I don't want to write code to create JSON, that isnt part of my business
>    scope. I will pick that one of the shelf If i can.
>    4. Records as the only structured data type is ... annoying.
>
>
> The problem I have is I can't find the perfect solution. Erlang is
> compelling but also is Scala.
>
> Opinions?
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140130/ba24a0ca/attachment.html>

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Loïc Hoguin-2
In reply to this post by kraythe .
Some replies inline.

On 01/30/2014 05:19 PM, kraythe . wrote:

> Ok right up front, I'm a Java Guru, not a Scala or Erlang one. What that
> means is that I know more than most debs about the core java language,
> but enough to know where the problems are. And certainly java has many
> issues but it also has massive momentum. I think one of the issues with
> Java can be expressed in one little programming puzzle I came across
> recently:
>
>     /In a relevant language, create an array of 1000 numbers. Initialize
>     all of the values in the array to zero. Create two threads that run
>     concurrently and which increment each element of the array one time./

That's not the kind of problem Erlang solves. That specific problem
requires a parallel solution, not a concurrent one. Plus Erlang
processes are isolated so they don't have access to the same data
without a third party (another process, an ets table, ..). Really for
that kind of problem I would instead suggest something like Haskell or
OpenCL.

> The goal being to select a language for
> the development of a concurrent TCP/IP based application with thousands
> of users interacting in a small space.

Well that's completely different from your problem. And that's actually
something you get pretty much for free with Erlang. I had no problem
getting 10K connections with absolutely no load on the server in a
production application. And since there was two of them, that means 20K
connections, no load and about no distributed programming required.

>  2. Built from the ground up with immutability in mind. Immutability is
>     a language feature, not compromisable. Its not JVM based and so is
>     not under the same issues as Java is.

Immutability is a language and VM feature. You can have a mutable
language on top of the BEAM VM, Elixir is an example of that.

>  1. The tools are, well frankly, garbage. Sorry, in 2014 to be pushed
>     back to coding with VIM and makefiles is primitive. Rebar is
>     crytptic and just the pet project of a guy on GIT. Compared to
>     Gradle, Maven and even (though I don't care for it much) SBT, rebar
>     is ... lacking. I want to spend time working on my business logic,
>     not fighting tools. There are plugins for eclipse and intellij
>     but they have minimal functionality and i keep reverting back to vim.

Well that's very much your opinion. Many would say Eclipse and the Java
ecosystem is garbage. I use Makefiles, and when I pull my project from
github the only thing I need to do is type 'make' and wait for it to
fetch dependencies, compile everything and generate the release which I
can then send to any server and it will just work with no extra
configuration or package needed (not even Erlang!). All this in just
under a minute. I would definitely not call that primitive.

>  3. Fewer general purpose libraries and no major central repositories.
>     I don't want to write code to create JSON, that isnt part of my
>     business scope. I will pick that one of the shelf If i can.

Well good for you then because there's about a dozen JSON libraries.

>  4. Records as the only structured data type is ... annoying.

Maps are coming. They're even in master now.

Besides them you also have proplists, dicts, sets, etc. etc. Erlang
comes with tons of structured data types, they just don't have a special
syntax. Maps have their own syntax, though.

> The problem I have is I can't find the perfect solution. Erlang is
> compelling but also is Scala.
>
> Opinions?

If you like Java so much, use it, but do note that because of the global
GC your application will have to stop for a few seconds from time to
time, which is problematic when you have 100k users doing stuff (and the
more users you have, the bigger the problem). Erlang has per-process GC
so this particular issue doesn't happen. Personally that's a deal breaker.

--
Lo?c Hoguin
http://ninenines.eu

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Sean Cribbs-3
In reply to this post by Aaron France
*In a relevant language, create an array of 1000 numbers. Initialize all of
the values in the array to zero. Create two threads that run concurrently
and which increment each element of the array one time.*

Sometimes the framing of the problem is the problem. In Erlang, which has
no shared memory (except maybe ETS? But that's an entirely different
issue), and no mutability, you would make two processes with lists of 1000
0's, which would map them into 1's. Maybe if they all need to be 2's, you
might have a pipeline/chain of processes, each receiving messages and
incrementing by 1. The issue is really the framing of the problem doesn't
make sense in Erlang.


   1. The tools are, well frankly, garbage. Sorry, in 2014 to be pushed
   back to coding with VIM and makefiles is primitive. Rebar is crytptic and
   just the pet project of a guy on GIT. Compared to Gradle, Maven and even
   (though I don't care for it much) SBT, rebar is ... lacking. I want to
   spend time working on my business logic, not fighting tools. There are
   plugins for eclipse and intellij but they have minimal functionality and i
   keep reverting back to vim.

This is really just a matter of familiarity. Yes, rebar could be better, I
know because I use it every day. However, you might be surprised at how
mature the OTP ecosystem is (it has 10 years on Java, by the way). IDEs are
not the way to go with Erlang generally, but Emacs has support for Wrangler
which does automated refactoring and Distel which lets you fire up and
interact with Erlang nodes directly from the editor (including debugging!),
and much more. Dialyzer lets you introduce gradual typing into your program
so you can find many bugs, a thing I've grown attached to lately.

It seems you are just comfortable in your IDE. When you started doing Java
or Scala were you immediately familiar with all the tools in its ecosystem?
I doubt it. Any new language ecosystem will have its own ramp-up time.

   1. Much harder to staff than Scala because it is not Java based.

Actually we have found this to be an advantage. Yes, it's harder to find
*any* programmer, but *good* programmers will try out new things because
they have an interest in learning and are adaptable. Head-count isn't
always the answer. One of our best Erlang devs at Basho came from a shop
where he did mostly Clojure. I think our CTO Justin Sheehy said it more
eloquently here: http://basho.com/erlang-at-basho-five-years-later/

   1. Fewer general purpose libraries and no major central repositories.
   I don't want to write code to create JSON, that isnt part of my business
   scope. I will pick that one of the shelf If i can.

Erlang/OTP contains most of what you need, but there are also plenty of
libraries for mundane things like JSON codecs, etc, and often the top
Erlang projects use them already! Many times a quick search on Github or
Google will help you find what you need.

   1. Records as the only structured data type is ... annoying.

Records aren't "structured data types", they're a compile-time syntax sugar
over tagged tuples. I suspect this criticism comes from your background as
an OO programmer.

I hope you won't dismiss Erlang for the wrong reasons. Yes, it is a totally
different world from JVM projects, but it's one I have enjoyed working in
for a long time.


On Thu, Jan 30, 2014 at 10:26 AM, Aaron France <aaron.l.france>wrote:

> Then what about Clojure?
>
> You can stay on the jvm, use Java  code and it has a focus on concurrency.
>
> Whilst it fails hard on fault tolerance it could be an escape hatch for
> those stuck with the jvm
>
> Aaron
> On 30 Jan 2014 17:22, "kraythe ." <kraythe> wrote:
>
>> Ok right up front, I'm a Java Guru, not a Scala or Erlang one. What that
>> means is that I know more than most debs about the core java language, but
>> enough to know where the problems are. And certainly java has many issues
>> but it also has massive momentum. I think one of the issues with Java can
>> be expressed in one little programming puzzle I came across recently:
>>
>> *In a relevant language, create an array of 1000 numbers. Initialize all
>> of the values in the array to zero. Create two threads that run
>> concurrently and which increment each element of the array one time.*
>>
>>
>> Interesting? The solution in Scala that I came up with is the following.
>>
>> def mtmap[A](data : List[A], threads: Int, f: (A) => A) = {
>>   import scala.concurrent.{ExecutionContext, Future, Await}
>>   implicit val executor =
>> java.util.concurrent.Executors.newFixedThreadPool(threads)
>>   implicit val context =  ExecutionContext.fromExecutorService(executor)
>>   val futures : Future[List[A]]= Future.traverse(data)(x => Future{f(x)})
>>   import scala.concurrent.duration._
>>   import scala.language.postfixOps
>>   val results : List[A] = Await.result(futures, 1 minute)
>>   results
>> }
>>
>>
>> Just thinking of doing this in Java will bring up some of the big
>> problems with Java; I will leave it as a mental exercise for the reader.
>> The problem is that Scala inherits some of them from the JVM and that has
>> made me look into Erlang. The goal being to select a language for the
>> development of a concurrent TCP/IP based application with thousands of
>> users interacting in a small space.
>>
>> So far I think the contenders I have are Scala with Akka or Erlang. And
>> yes, I know there are evangelists to both and I will post this to an Scala
>> list to get their feedback as well (or something similar). Now, right up
>> front I am not peeing on either language. They both rock or they wouldn't
>> be on the list. The question is which should win the prize. There is no
>> going back once development is 1000 hours down the road.
>>
>> *Scala: *
>> *Pros:*
>>
>>    1. Based on Java Ecosystem so easier to staff because good Java devs
>>    can convert to Scala.
>>    2. Decent tools (which are getting better). Many libraries.
>>    3. Static typing with type inference.
>>
>> *Cons:*
>>
>>    1. Based on Java Ecosystem and inherit the problems of that ecosystem
>>    (i.e. immutable is a function of the design of a class, not of the language
>>    so it can't be guaranteed.), Also library code under the hood is not as
>>    rigorous as scala code in enforcing immutability so at some point you are
>>    rolling dice here.
>>    2. Scala is also more heavyweight than Erlang when it comes to
>>    spawning thousands of processes. Erlang was built from the ground up to do
>>    concurrency. For Scala its an Akka bolt on can carries the Java threading
>>    nightmare (shared memory, etc).
>>    3. Scala is not as fast. My server will be doing billions of vector
>>    math calculations per day and they have to be in the terms of milliseconds
>>    of latency. It has to be that if I have a user R in the server at position
>>    V where V is a vector, I need to calculate all other actors within 50 units
>>    and get that answer in milliseconds so that only the network latency is the
>>    bottleneck. Some of this can be helped with algorithms like spatial grids
>>    and so on but still we are looking at a couple of hundred vector math calls
>>    per second.
>>    4. Scala is harder to hook up to dozens of nodes and move actors from
>>    node x to node y than Erlang, mainly because that was one of the design
>>    goals of Erlang.
>>
>>
>> *Erlang:*
>> *Pros:*
>>
>>    1. Built for concurrency. Can handle dozens of hardware nodes, build
>>    massive applications of the kind I am trying to deploy. Think of 100k users
>>    connecting to the cluster with a TCP connection and interacting over that
>>    connection which interacts with any or all of the other 100k actors.
>>    2. Built from the ground up with immutability in mind. Immutability
>>    is a language feature, not compromisable. Its not JVM based and so is not
>>    under the same issues as Java is.
>>    3. There is merit in the thought that static typing is sometimes a
>>    hinderance to a language.
>>
>> *Cons:*
>>
>>    1. The tools are, well frankly, garbage. Sorry, in 2014 to be pushed
>>    back to coding with VIM and makefiles is primitive. Rebar is crytptic and
>>    just the pet project of a guy on GIT. Compared to Gradle, Maven and even
>>    (though I don't care for it much) SBT, rebar is ... lacking. I want to
>>    spend time working on my business logic, not fighting tools. There are
>>    plugins for eclipse and intellij but they have minimal functionality and i
>>    keep reverting back to vim.
>>    2. Much harder to staff than Scala because it is not Java based.
>>    3. Fewer general purpose libraries and no major central repositories.
>>    I don't want to write code to create JSON, that isnt part of my business
>>    scope. I will pick that one of the shelf If i can.
>>    4. Records as the only structured data type is ... annoying.
>>
>>
>> The problem I have is I can't find the perfect solution. Erlang is
>> compelling but also is Scala.
>>
>> Opinions?
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>
>


--
Sean Cribbs <sean>
Software Engineer
Basho Technologies, Inc.
http://basho.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140130/90624cb0/attachment.html>

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Sergej Jurecko
In reply to this post by kraythe .
Addressing the cons:

1. You're looking at it from a Java developers perspective. Java, C# and others have well developed tools, because without them those platforms would be unbearable to develop for. I don't know about others, but rebar has been working just fine for me. I write code in sublime and don't miss anything. This speaks to the strength of the platform. You can get very very far without needing any special tools.

2. Yep

3. Yeah there is no central repository. But google does a fine job of finding various libraries. For json especially.

4. Until frames/maps arrive in R17.


There is also one pro for Erlang when compared to Java/C# that is rarely mentioned. Once you are proficient with the language the code is very readable much shorter. Makes it easier to work with your code and understand what your dependencies are doing.


Sergej

On Jan 30, 2014, at 5:19 PM, kraythe . wrote:

> Ok right up front, I'm a Java Guru, not a Scala or Erlang one. What that means is that I know more than most debs about the core java language, but enough to know where the problems are. And certainly java has many issues but it also has massive momentum. I think one of the issues with Java can be expressed in one little programming puzzle I came across recently:
>
> In a relevant language, create an array of 1000 numbers. Initialize all of the values in the array to zero. Create two threads that run concurrently and which increment each element of the array one time.
>
> Interesting? The solution in Scala that I came up with is the following.
>
> def mtmap[A](data : List[A], threads: Int, f: (A) => A) = {
>   import scala.concurrent.{ExecutionContext, Future, Await}
>   implicit val executor = java.util.concurrent.Executors.newFixedThreadPool(threads)
>   implicit val context =  ExecutionContext.fromExecutorService(executor)
>   val futures : Future[List[A]]= Future.traverse(data)(x => Future{f(x)})
>   import scala.concurrent.duration._
>   import scala.language.postfixOps
>   val results : List[A] = Await.result(futures, 1 minute)
>   results
> }
>
> Just thinking of doing this in Java will bring up some of the big problems with Java; I will leave it as a mental exercise for the reader. The problem is that Scala inherits some of them from the JVM and that has made me look into Erlang. The goal being to select a language for the development of a concurrent TCP/IP based application with thousands of users interacting in a small space.
>
> So far I think the contenders I have are Scala with Akka or Erlang. And yes, I know there are evangelists to both and I will post this to an Scala list to get their feedback as well (or something similar). Now, right up front I am not peeing on either language. They both rock or they wouldn't be on the list. The question is which should win the prize. There is no going back once development is 1000 hours down the road.
>
> Scala:
> Pros:
> Based on Java Ecosystem so easier to staff because good Java devs can convert to Scala.
> Decent tools (which are getting better). Many libraries.
> Static typing with type inference.
> Cons:
> Based on Java Ecosystem and inherit the problems of that ecosystem (i.e. immutable is a function of the design of a class, not of the language so it can't be guaranteed.), Also library code under the hood is not as rigorous as scala code in enforcing immutability so at some point you are rolling dice here.
> Scala is also more heavyweight than Erlang when it comes to spawning thousands of processes. Erlang was built from the ground up to do concurrency. For Scala its an Akka bolt on can carries the Java threading nightmare (shared memory, etc).
> Scala is not as fast. My server will be doing billions of vector math calculations per day and they have to be in the terms of milliseconds of latency. It has to be that if I have a user R in the server at position V where V is a vector, I need to calculate all other actors within 50 units and get that answer in milliseconds so that only the network latency is the bottleneck. Some of this can be helped with algorithms like spatial grids and so on but still we are looking at a couple of hundred vector math calls per second.
> Scala is harder to hook up to dozens of nodes and move actors from node x to node y than Erlang, mainly because that was one of the design goals of Erlang.
>
> Erlang:
> Pros:  
> Built for concurrency. Can handle dozens of hardware nodes, build massive applications of the kind I am trying to deploy. Think of 100k users connecting to the cluster with a TCP connection and interacting over that connection which interacts with any or all of the other 100k actors.
> Built from the ground up with immutability in mind. Immutability is a language feature, not compromisable. Its not JVM based and so is not under the same issues as Java is.
> There is merit in the thought that static typing is sometimes a hinderance to a language.
> Cons:
> The tools are, well frankly, garbage. Sorry, in 2014 to be pushed back to coding with VIM and makefiles is primitive. Rebar is crytptic and just the pet project of a guy on GIT. Compared to Gradle, Maven and even (though I don't care for it much) SBT, rebar is ... lacking. I want to spend time working on my business logic, not fighting tools. There are plugins for eclipse and intellij but they have minimal functionality and i keep reverting back to vim.
> Much harder to staff than Scala because it is not Java based.
> Fewer general purpose libraries and no major central repositories. I don't want to write code to create JSON, that isnt part of my business scope. I will pick that one of the shelf If i can.
> Records as the only structured data type is ... annoying.
>
> The problem I have is I can't find the perfect solution. Erlang is compelling but also is Scala.
>
> Opinions?
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140130/5676bd9b/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Ulf Wiger-5
In reply to this post by kraythe .

On 30 Jan 2014, at 17:19, kraythe . <kraythe> wrote:

> The tools are, well frankly, garbage. Sorry, in 2014 to be pushed back to coding with VIM and makefiles is primitive.
So use Emacs. ;-)

Seriously, there are a few reasons why the tools are garbage compared to e.g. the Java community?s, but here?s the main reason:

For one thing, they are not needed as much. I once participated in a code kata track, where (as it happened) the same problem was solved in several different languages. The idea was to let the audience lead, but the only ones who did that were I and the Ruby guy - and we and the Clojure guy were the only ones who completed the task on time. This, even though we stuck to Emacs and had no other fancy tools. The Java team and the C# guy ran out of time.

The Java guys - two experts, pair programming rather than involving the audience - ripped through with IntelliJ, but still didn?t finish the task on time. Still, it was amazing to see what the tool could do. Talking to some Java experts afterwards, the consensus seemed to be that ?yeah, the tools are fantastic, but the problem is that you?re dead in the water without them?. Also, some complaints were raised that the tool support distances you as a developer from the raw implementation, especially when the tool automatically generates a lot of your code for you.

To some extent, this also applies to the libs question. You might well get done faster even if you end up having to do work that you wouldn?t have to in Java, since writing your own lib in Erlang can often be less work than using an existing lib in Java. ;-)

Since most Erlang programmers are quite comfortable using Emacs or Vim, it?s hard to get traction for a tool development project. There have been attempts, but overall, most (?) Erlang devs don?t feel that they need such tools to be productive.

But mostly, the things to look for are the major snags - the ones that could kill your project. How much support can you get from the respective communities for the kind of application you have in mind? How mature are the components you will have to rely on? Etc.

Depending on your application domain, the anwers to those questions are likely to vary.

BR,
Ulf W

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140130/9366dae1/attachment.html>

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

José Valim
In reply to this post by Loïc Hoguin-2
>
> Immutability is a language and VM feature. You can have a mutable language
> on top of the BEAM VM, Elixir is an example of that.
>

Small correction: immutability is a VM feature. Elixir has the same amount
of mutability as Erlang. It is common to confuse rebinding with mutability
but it is still compiled to static single assignment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140130/b455af80/attachment.html>

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Steven Gravell-2
In reply to this post by Ulf Wiger-5
I'll chip in on the part about the tooling - I was a C# / Visual Studio dev
for 10+ years when I switched to erlang. For the first perhaps 4 weeks, I
missed hitting 'dot' and having the computer tell me what to do; then I
started noticing that I was actually remembering what stuff did, rather
than relying on the IDE.

I also found the build tool chain awkward, but it turned out that 'make'
was rather good - and the total lack of black magic made it obvious how to
fix build / release issues when they did occur (ignoring here the rather
arcane syntax for retool!)

Within a couple of months I've no doubt that I was more productive than I'd
been in Visual Studio, and now, 3+ years on, you'd have to pay me
significant sums of money to go back to those 'advanced' tools.

Cheers,

Steve
On 30 Jan 2014 17:58, "Ulf Wiger" <ulf> wrote:

>
> On 30 Jan 2014, at 17:19, kraythe . <kraythe> wrote:
>
>
>    1. The tools are, well frankly, garbage. Sorry, in 2014 to be pushed
>    back to coding with VIM and makefiles is primitive.
>
> So use Emacs. ;-)
>
> Seriously, there are a few reasons why the tools are garbage compared to
> e.g. the Java community's, but here's the main reason:
>
> For one thing, they are not needed as much. I once participated in a code
> kata track, where (as it happened) the same problem was solved in several
> different languages. The idea was to let the audience lead, but the only
> ones who did that were I and the Ruby guy - and we and the Clojure guy were
> the only ones who completed the task on time. This, even though we stuck to
> Emacs and had no other fancy tools. The Java team and the C# guy ran out of
> time.
>
> The Java guys - two experts, pair programming rather than involving the
> audience - ripped through with IntelliJ, but still didn't finish the task
> on time. Still, it was amazing to see what the tool could do. Talking to
> some Java experts afterwards, the consensus seemed to be that "yeah, the
> tools are fantastic, but the problem is that you're dead in the water
> without them". Also, some complaints were raised that the tool support
> distances you as a developer from the raw implementation, especially when
> the tool automatically generates a lot of your code for you.
>
> To some extent, this also applies to the libs question. You might well get
> done faster even if you end up having to do work that you wouldn't have to
> in Java, since writing your own lib in Erlang can often be less work than
> using an existing lib in Java. ;-)
>
> Since most Erlang programmers are quite comfortable using Emacs or Vim,
> it's hard to get traction for a tool development project. There have been
> attempts, but overall, most (?) Erlang devs don't feel that they need such
> tools to be productive.
>
> But mostly, the things to look for are the major snags - the ones that
> could kill your project. How much support can you get from the respective
> communities for the kind of application you have in mind? How mature are
> the components you will have to rely on? Etc.
>
> Depending on your application domain, the anwers to those questions are
> likely to vary.
>
> BR,
> Ulf W
>
> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
> http://feuerlabs.com
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140130/c06c29ae/attachment.html>

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Steven Gravell-2
I?m an emacs guy, and most of what you want is in there - however, completely understand the pain in switching editors, so some vim-specific comments below...  

--  
Steve Strong
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Thursday, 30 January 2014 at 19:10, kraythe . wrote:

> I would pose a couple of questions tool wise then. Keep in mind that there are likely answers to these questions I don't know so please don't detect attitude but rather inquisitiveness. With my tools I want the following as a must:  
>  
> 1) Code completion. Sorry but I can't be bothered to type the same flipping method name in its entirety 40 times.  
>  
looks like vim can do this: http://blogs.gnome.org/lharris/2008/07/20/code-completion-with-vim-7/.  I?m sure there are other options as well...
 

>  
> 2) Redeploy in running app or quick restart. I worked a tutorial on a rebar based application and then when I changed it I had to do:  
>  
> --> (ctrl-G) q
> $ myapp stop
> $ myapp start
> $ myapp attach
>  
>  
>  

Try something like https://github.com/rustyio/sync (reloads beam files whenever they change) combined with something like https://github.com/mynyml/watchr (watches a directory, and runs a command (such as ?make?) whenever anything changes).  That way, you save the file and then test the results.  No need to stop / start the VM in the majority of cases.  Even better would be to have a test suite rather than an interactive prompt and just have the tests automatically execute.
>  
> That is a development cycle that would drive me NUTS.
>  
> 3) Automatic dependency fetching. I understand rebar can do some of this but how do I fix versions of modules and so on? Do I have to compile every third party lib?  
rebar.config (and erlang.mk is you wanted a pure make approach) can both fetch deps, and both support fixing the version of the deps that are pulled, by tab, by branch, by commit hash etc.  And yes, you do need to compile them - but the occasional ?rebar compile? doesn?t seem much overhead.

>  
> 3) Syntax coloring. (VIM color codes a file so that is there, emacs I don't know AT ALL.)
I don?t know of any editor that doesn?t do this - even github displays syntax colouring on erlang files.  
>  
> 4) Editor easiness, files window, project overview, configuration, etc.  
not a user of VIM (emacs does this stuff just fine), but a single google search reveals http://vimdoc.sourceforge.net/htmldoc/windows.html - which suggests it can do pretty much everything  
>  
> 5) Refactoring. This is one of the tools I am reluctant to give up. If I change the signature of a method I do not want to have to go change 40 files manually. NO thanks.  
This is something that?s harder - there?s a plugin for Emacs called Wrangler that can do some refactoring, don?t know of anything for VIM.  That said, although I?m an emacs guy, I don?t bother with Wrangler.  If changing a method signature means I have to edit 40 other files, then I think I?ve got *much* bigger problems.  The insanely good refactoring support in Visual Studio (particularly with Resharper) enables the hiding of a multitude of sins, allowing code to become far too closely coupled without noticing until way too late in development.  Not having that kind of support makes me write better code in the first place.  The only time I?d be needing to edit a lot of files is if I?m changing so very low level utility - typically, these tend to be so trivial that they rarely if ever change, so it?s not often a problem.  
>  
> It could be I have to learn Emacs. Being a vi guy for 20 years, that will take some adaptation I can tell you.  
>  
I certainly wouldn?t suggest switching editors - although the religious zealots will insist that one is far better than the other, the reality (imo) is that both are highly capable and can do the bulk of what people need with a few hours work on google and with the configuration.

Hope that helps!

Cheers,

Steve
 

> LinkedIn: http://www.linkedin.com/pub/robert-simmons/40/852/a39
>  
>  
>  
>  
> On Thu, Jan 30, 2014 at 11:12 AM, Steve Strong <steve (mailto:steve)> wrote:
> > I'll chip in on the part about the tooling - I was a C# / Visual Studio dev for 10+ years when I switched to erlang. For the first perhaps 4 weeks, I missed hitting 'dot' and having the computer tell me what to do; then I started noticing that I was actually remembering what stuff did, rather than relying on the IDE.  
> > I also found the build tool chain awkward, but it turned out that 'make' was rather good - and the total lack of black magic made it obvious how to fix build / release issues when they did occur (ignoring here the rather arcane syntax for retool!)
> > Within a couple of months I've no doubt that I was more productive than I'd been in Visual Studio, and now, 3+ years on, you'd have to pay me significant sums of money to go back to those 'advanced' tools.
> > Cheers,
> > Steve
> > On 30 Jan 2014 17:58, "Ulf Wiger" <ulf (mailto:ulf)> wrote:
> > >  
> > > On 30 Jan 2014, at 17:19, kraythe . <kraythe (mailto:kraythe)> wrote:
> > > > The tools are, well frankly, garbage. Sorry, in 2014 to be pushed back to coding with VIM and makefiles is primitive.  
> > > So use Emacs. ;-)
> > >  
> > > Seriously, there are a few reasons why the tools are garbage compared to e.g. the Java community?s, but here?s the main reason:
> > >  
> > > For one thing, they are not needed as much. I once participated in a code kata track, where (as it happened) the same problem was solved in several different languages. The idea was to let the audience lead, but the only ones who did that were I and the Ruby guy - and we and the Clojure guy were the only ones who completed the task on time. This, even though we stuck to Emacs and had no other fancy tools. The Java team and the C# guy ran out of time.  
> > >  
> > > The Java guys - two experts, pair programming rather than involving the audience - ripped through with IntelliJ, but still didn?t finish the task on time. Still, it was amazing to see what the tool could do. Talking to some Java experts afterwards, the consensus seemed to be that ?yeah, the tools are fantastic, but the problem is that you?re dead in the water without them?. Also, some complaints were raised that the tool support distances you as a developer from the raw implementation, especially when the tool automatically generates a lot of your code for you.  
> > > To some extent, this also applies to the libs question. You might well get done faster even if you end up having to do work that you wouldn?t have to in Java, since writing your own lib in Erlang can often be less work than using an existing lib in Java. ;-)  
> > >  
> > > Since most Erlang programmers are quite comfortable using Emacs or Vim, it?s hard to get traction for a tool development project. There have been attempts, but overall, most (?) Erlang devs don?t feel that they need such tools to be productive.  
> > >  
> > > But mostly, the things to look for are the major snags - the ones that could kill your project. How much support can you get from the respective communities for the kind of application you have in mind? How mature are the components you will have to rely on? Etc.  
> > >  
> > > Depending on your application domain, the anwers to those questions are likely to vary.
> > >  
> > > BR,
> > > Ulf W
> > >  
> > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
> > > http://feuerlabs.com
> > >  
> > >  
> > >  
> > >  
> > >  
> > > _______________________________________________
> > > erlang-questions mailing list
> > > erlang-questions (mailto:erlang-questions)
> > > http://erlang.org/mailman/listinfo/erlang-questions
> > >  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140130/bf0164ea/attachment.html>

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Jachym Holecek-2
# Steve Strong 2014-01-30:
> > It could be I have to learn Emacs. Being a vi guy for 20 years, that
> > will take some adaptation I can tell you.  
>
> I certainly wouldn?t suggest switching editors - although the religious
> zealots will insist that one is far better than the other, the reality
> (imo) is that both are highly capable and can do the bulk of what people
> need with a few hours work on google and with the configuration.

FWIW the Viper mode of Emacs provides tolerable (not ideal) Vi emulation,
so you don't necessarily have to change habits if you decide to give Emacs
a go.

BR,
        -- Jachym

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Loïc Hoguin-2
In reply to this post by Loïc Hoguin-2
CCing back the mailing list as I would like my response to be archived
for future users.

On 01/30/2014 07:22 PM, kraythe . wrote:

>              /In a relevant language, create an array of 1000 numbers.
>         Initialize
>
>              all of the values in the array to zero. Create two threads
>         that run
>              concurrently and which increment each element of the array
>         one time./
>
>
>     That's not the kind of problem Erlang solves. That specific problem
>     requires a parallel solution, not a concurrent one. Plus Erlang
>     processes are isolated so they don't have access to the same data
>     without a third party (another process, an ets table, ..). Really
>     for that kind of problem I would instead suggest something like
>     Haskell or OpenCL.
>
>
> I put that in only as an example of why NOT java. But I would be
> interested in your take on how to solve it in erlang. Theoretically
> parallel = concurrent. The only question is how to break up the task to
> federate it. Shared memory is one way, but not the only way. Introducing
> more than one language to this mix is something I would like to avoid.

Well I would simply not use Erlang for it. Erlang is good at pretty much
anything except CPU-bound problems. Thankfully these are very specific
to certain fields and types of applications so Erlang does the job just
fine most of the time.

If I had that kind of problem to solve inside my application I would use
Erlang to manage OpenCL or similar. Erlang is very good at running in a
mixed environment, including C libraries, external programs, and can
easily speak to any other language thanks to C/Java nodes. So there's
really no need to bother trying to solve that problem efficiently in
Erlang. Just use something more appropriate and make Erlang speak to it.

> Naturally its my opinion. :) One subject to change I might add. Either
> the tools are not there or not readily findable. A critique of Erlang is
> that if you don't make the ecosystem accessible, you inhibit adoption.
> IMHO there should be a "getting started in erlang" tutorial that takes
> you from nothing installed to setting up tool set to your first app
> running and then modified. I googled until my fingers bled and found
> nothing like that, only other smaller tutorials and entirely language
> and shell tutorials (which were great btw). That "new to erlang? Start
> here," tutorial should be prominent on the first page of erlang.org
> <http://erlang.org>.

You come from a very different world, most languages don't have their
specific IDE and graphical tools to do things. Erlang does come with an
Emacs mode
(http://www.erlang.org/doc/apps/tools/erlang_mode_chapter.html) but
that's only good for Emacs people.

The shell tutorials are the best getting started you'll get. Erlang is
unique, there's absolutely nothing that comes close to it, you have to
learn how it works before you can get started. And the shell can be used
to learn a lot of it. One time I spent the first day of teaching a 3
days training using nothing but the shell.

If you want a getting started to OTP applications and releases, you can
take a look at this:
http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ - That's
pretty much what a "getting started with writing Erlang applications"
would look like, and as you can see it doesn't cover much of what is
covered when learning Erlang.

>           3. Fewer general purpose libraries and no major central
>         repositories.
>
>              I don't want to write code to create JSON, that isnt part of my
>              business scope. I will pick that one of the shelf If i can.
>
>
>     Well good for you then because there's about a dozen JSON libraries.
>
>
> Oh good. I googled for a vector math library. In java I can go to a
> maven Repo and get an index of thousands of libs. Where is the erlang
> equivalent ? And do I have to compile them? Can I just use the binary
> beam files?

Like I said earlier, CPU-bound operations, write a binding to a C vector
math library and call it from Erlang.

Erlang code is almost exclusively obtained from source. There are no
central repository, despite many attempts, for two main reasons:

  *  It is very common to run your own fork of a project with a specific
set of additions, fixes or performance improvements you can't live without.

  *  What you push to production is called a release, and is a self
contained package containing everything your node needs to run. You can
just push it to a new system without anything Erlang installed, start
the release and it just works (you might still need openssl on some OS).

What follows from that is that you won't install much Erlang libraries,
you just mark them as dependencies to your release and the build tool
fetches everything as needed.

To illustrate, I do have a package index file in my erlang.mk build
tool, but no open source author sent a PR to put their project there.
(Of course this index file has other uses so it's not a wasted feature.)

The package manager question comes back regularly, and there's a new one
from time to time, but what these projects try to solve is generally
what they think is a technical issue of previous package managers that
failed to get traction, while the actual issue is entirely cultural.

> Maps would be good and solve much of my record tuple annoyance. +1 for
> that. What I would really want, though, is a constrained map. A map
> where I can bind the keys to only a certain set of atoms. Records aren't
> too horrible except their syntax is ... weird.

You can create a map with a default for all the keys you accept and then
update using only := which requires the key to already exist in the map.

--
Lo?c Hoguin
http://ninenines.eu

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Vlad Dumitrescu-5
On Thu, Jan 30, 2014 at 8:49 PM, Lo?c Hoguin <essen> wrote:

> You come from a very different world, most languages don't have their
> specific IDE and graphical tools to do things. Erlang does come with an
> Emacs mode (http://www.erlang.org/doc/apps/tools/erlang_mode_chapter.html)
> but that's only good for Emacs people.
>

Just a gentle reminder: there is an IDE for Erlang, http://erlide.org. It
can do a lot of helpful things, among others integration with the debugger
and with Wrangler. It's based on Eclipse, so it's on the heavy side, and
the list of things to be done is long, but I'm working hard to improve it.
The next big thing (coming soon!) will be building with make/emake/rebar,
so that more projects can use it.

If anybody tries it, even if it doesn't get many stars, please let me know
what is bad and what is missing, with a use case or two. I can only do a
few things at a time and it would be best if these were what people need
the most.

best regards,
Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140130/fdbcb1f9/attachment.html>

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Michał Ptaszek
In reply to this post by kraythe .
On Thu, Jan 30, 2014 at 5:19 PM, kraythe . <kraythe> wrote:

> Ok right up front, I'm a Java Guru, not a Scala or Erlang one. What that
> means is that I know more than most debs about the core java language, but
> enough to know where the problems are. And certainly java has many issues
> but it also has massive momentum. I think one of the issues with Java can
> be expressed in one little programming puzzle I came across recently:
>
> *In a relevant language, create an array of 1000 numbers. Initialize all
> of the values in the array to zero. Create two threads that run
> concurrently and which increment each element of the array one time.*
>
>
> Interesting? The solution in Scala that I came up with is the following.
>
> def mtmap[A](data : List[A], threads: Int, f: (A) => A) = {
>   import scala.concurrent.{ExecutionContext, Future, Await}
>   implicit val executor =
> java.util.concurrent.Executors.newFixedThreadPool(threads)
>   implicit val context =  ExecutionContext.fromExecutorService(executor)
>   val futures : Future[List[A]]= Future.traverse(data)(x => Future{f(x)})
>   import scala.concurrent.duration._
>   import scala.language.postfixOps
>   val results : List[A] = Await.result(futures, 1 minute)
>   results
> }
>
>
> Just thinking of doing this in Java will bring up some of the big problems
> with Java; I will leave it as a mental exercise for the reader. The problem
> is that Scala inherits some of them from the JVM and that has made me look
> into Erlang. The goal being to select a language for the development of a
> concurrent TCP/IP based application with thousands of users interacting in
> a small space.
>

A benchmark that tells you how concurrent array updates works won't tell
you anything about
well sockets work.

Erlang was explicitly designed for managing thousands of simultaneous
sessions (ie telecomms applications) - (that's why things like WhatsApp is
programmed in Erlang)
try Googling "whatsapp+erlang".

Java was designed for set-top boxes - both languages are good for what they
were designed to be good at. Consequently Erlang is good at handling large
numbers of parallel connections and java is really good for set-top boxes.
Both languages suck when used outside their design domains. So Erlang is
crap
at programming small memory footprint embedded devices and java is not
stunning good at handling
concurrency.


>
> So far I think the contenders I have are Scala with Akka or Erlang. And
> yes, I know there are evangelists to both and I will post this to an Scala
> list to get their feedback as well (or something similar). Now, right up
> front I am not peeing on either language. They both rock or they wouldn't
> be on the list. The question is which should win the prize. There is no
> going back once development is 1000 hours down the road.
>
> *Scala: *
> *Pros:*
>
>    1. Based on Java Ecosystem so easier to staff because good Java devs
>    can convert to Scala.
>    2. Decent tools (which are getting better). Many libraries.
>    3. Static typing with type inference.
>
> *Cons:*
>
>    1. Based on Java Ecosystem and inherit the problems of that ecosystem
>    (i.e. immutable is a function of the design of a class, not of the language
>    so it can't be guaranteed.), Also library code under the hood is not as
>    rigorous as scala code in enforcing immutability so at some point you are
>    rolling dice here.
>    2. Scala is also more heavyweight than Erlang when it comes to
>    spawning thousands of processes. Erlang was built from the ground up to do
>    concurrency. For Scala its an Akka bolt on can carries the Java threading
>    nightmare (shared memory, etc).
>
>
How about millions of processes - "thousands" of processes is in the "tiny"
league table


>
>    1.
>    2. Scala is not as fast. My server will be doing billions of vector
>    math calculations per day and they have to be in the terms of milliseconds
>    of latency. It has to be that if I have a user R in the server at position
>    V where V is a vector, I need to calculate all other actors within 50 units
>    and get that answer in milliseconds so that only the network latency is the
>    bottleneck. Some of this can be helped with algorithms like spatial grids
>    and so on but still we are looking at a couple of hundred vector math calls
>    per second.
>
> I don't get a feeling for what "billions of vector math calculations per
day" means. How long does
one "vector math calculation" take - or is this what you were trying to
measure?

If you're doing really heavy number crunching Julia seems the way to go.
Julia is outperforming Fortran on many benchmarks - and Fortran always set
the gold standard for number crunching.

Something like Erlang for orchestration, Julia for number crunching and 0MQ
for messaging would be what I'd look at.



>    1. Scala is harder to hook up to dozens of nodes and move actors from
>    node x to node y than Erlang, mainly because that was one of the design
>    goals of Erlang.
>
>
> *Erlang:*
> *Pros:*
>
>    1. Built for concurrency. Can handle dozens of hardware nodes, build
>    massive applications of the kind I am trying to deploy. Think of 100k users
>    connecting to the cluster with a TCP connection and interacting over that
>    connection which interacts with any or all of the other 100k actors.
>    2. Built from the ground up with immutability in mind. Immutability is
>    a language feature, not compromisable. Its not JVM based and so is not
>    under the same issues as Java is.
>
> What's immutability got to do with anything? If you want to do fast vector
operations things like
Fortran is king - and that's mutable as hell.

The kind of immutability that Erlang has is for reasons of fault tolerance
- we don't want programs to crash and run wild - fast math needs mutable
structures



>
>    1. There is merit in the thought that static typing is sometimes a
>    hinderance to a language.
>
> *Cons:*
>
>    1. The tools are, well frankly, garbage. Sorry, in 2014 to be pushed
>    back to coding with VIM and makefiles is primitive. Rebar is crytptic and
>    just the pet project of a guy on GIT. Compared to Gradle, Maven and even
>    (though I don't care for it much) SBT, rebar is ... lacking. I want to
>    spend time working on my business logic, not fighting tools. There are
>    plugins for eclipse and intellij but they have minimal functionality and i
>    keep reverting back to vim.
>
> Tools are no substitute for thought. None of the tools you mention help me
think - the thing that takes
time in programming is deciding exactly what problem to solve. Once you
know you can usually knock out the program in a few hours.

The best tool we have is (or course) maths - ie logical reasoning and
proofs.

The average programmer produces about 10 lines of code per day, but they
might write hundreds or
even thousands of lines of code per day that never makes it to the final
product. If they knew what to
do they could just write these ten lines in a few minutes, but they don't
know so they have to write
thousands of lines to help try and figure out what the problem is. It also
creates the illusion of work
and they can get paid for it.

The big problem in programming is understanding the problem. "programming
is understanding"
The tools we have today are no better than they were 40 years ago. My brain
is still far far better at
debugging that any fancy tool. I have no idea my brain works - all I know
is that I often work on
a problem and then give up. I go to sleep and wake up with the solution.
Now that is far far better
than *any* IDE on the planet.

I like to spend my time figuring out *exactly* how things related to my
applications, there would be
no point in figuring out (say) eclipse works - since editing text is not a
problem for me - I'm happy
with emacs - and even happier with a pen and paper (which boots far
quicker, is far more portable,
and far more flexible)

I spend 65% of my programming time fixing stuff that I need that is broken.
Every time a program
does not install or work exactly as advertised I have to pull it apart and
fix it. None of these tools
are of any use when they break. Rebar/Maven/Git etc are great when they
work.

Even emacs is crashing randomly on my mac - the problem is not the tools
but that fact that
broken tools take a long time to fix. (this is why I try to use as little
as possible - emacs, make and bash, do it for me)

In the good old days programmers could talk to each other - everybody who
could program knew how to write makefile and bash scripts. Now a guy who
speaks Maven is floored when sent a rakefile.

And as for eclipse etc. these are unbelievably horrible.


>    1. Much harder to staff than Scala because it is not Java based.
>    2. Fewer general purpose libraries and no major central repositories.
>    I don't want to write code to create JSON, that isnt part of my business
>    scope. I will pick that one of the shelf If i can.
>
> It's often far quicker to write code than a) find a library b) install it
c) fix the bugs in the library.
Creating JSON is trivial:

     io:format("{'firstname':'joe', 'lastname':'armstring'}").

Parsing it is a wee bit messy.


>    1. Records as the only structured data type is ... annoying.
>
>
> The problem I have is I can't find the perfect solution. Erlang is
> compelling but also is Scala.
>
> Opinions?
>

There is no easy path.

    - choose your languages
    - write the benchmarks in all the languages
    - measure
    - don't believe what other people say - base the results on your
personal experience
    - understand your problem - write a detailed English description of the
problem and
      give to to your friends - get them to read it and explain the problem
back to you

There are also tradeoff to consider.

    You want super fast math (this implies mutable data)
    You want safety (this implies non-mutable data)
    You mention JSON (implies inefficient data transfer)
    You want massive communication
etc.

    These pull in different directions.

Cheers

/Joe

>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140130/81b954eb/attachment.html>

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Richard A. O'Keefe
In reply to this post by kraythe .

On 31/01/2014, at 5:19 AM, kraythe . wrote:
> In a relevant language, create an array of 1000 numbers. Initialize all of the values in the array to zero. Create two threads that run concurrently and which increment each element of the array one time.

Does that mean something like

        a := (1 to: 1000) collect: [:each | 0].
        b := [1 to: a size do: [:i | a at: i atomicUpdate: [:x | x + 1]].
        b fork.
        b fork.

(Bog standard Smalltalk except for #at:atomicUpdate:, which is
exclusive to my Smalltalk implementation, but would fit easily enough
into others and was trivial to implement.)

The Scala version is, well, it makes me even fonder of Smalltalk...

The thing is that this exercise is a very imperative one.
>
> Scala:
> Pros:
> ? Based on Java Ecosystem so easier to staff because good Java devs can convert to Scala.

Scala is different enough from Java that I think anyone who can
adapt to Scala can adapt to Erlang about as easily.  Data would
be nice of course.

> ? Decent tools (which are getting better). Many libraries.
> ? Static typing with type inference.

Erlang has the Dialyzer.

I often think that if you *need* powerful modern tools to work
with a language, your language is doing something wrong.

> ? Fewer general purpose libraries and no major central repositories. I don't want to write code to create JSON, that isnt part of my business scope. I will pick that one of the shelf If i can.

There are plenty of JSON libraries; your only problem is choosing
the shelf to pick one off.

> ? Records as the only structured data type is ... annoying.

You may have missed the announcement of maps.


Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Richard A. O'Keefe
In reply to this post by Steven Gravell-2

On 31/01/2014, at 7:49 AM, Steve Strong wrote:
> On Thursday, 30 January 2014 at 19:10, kraythe . wrote:
>> 1) Code completion. Sorry but I can't be bothered to type the same flipping method name in its entirety 40 times.


There are three causes for "completion" in languages like
Prolog and Erlang:

(a) Definitions with multiple clauses.
    Your editor should be able to turn "add a clause" into a
    single command.

(b) Recursion.
    Your editor should be able to turn "add a recursive call"
    into a single command (basically the same as (a), just
    different stuff wrapped around it).

    A programming style using higher order procedures can
    eliminate a lot of this.

(c) Repetitive patterns of code.

    A programming style using higher order procedures can
    eliminate a lot of this.

There's a thing I find myself saying more and more often:

        Why can't I see the structure?

I was reviewing a page or two of Prolog code for someone the
other day.  By the end of three hours, I'd made some progress,
but I was troubled.  The code was clean, but it wasn't OBVIOUS.
What finally dawned on me would have been instantly obvious to
a real functional programmer:  the code was an interweaving of
a "compute argmax of a partial function over a finite domain"
and "here is this partial function".  Actually introducing the
higher order function in question let me explore several ways
of implementing that *without* any effect on the rest of the
code.  Breaking the specific partial function out and naming
it let me see that memoising *that* function -- which hadn't
previously existed -- stood an excellent chance of reducing
the overall cost of the algorithm down *hugely*.

So I say, if you find yourself _wanting_ a method name to
appear 40 times in a day's work, you are doing something
badly wrong.

For another data point, as part of building up my Smalltalk
skills, I used to pick up Java code and rewrite it in Smalltalk.
There were two invariable results:  first, the code would
shrink by about a factor of six, and second, it would become
painfully obvious that the original code was really really
bad design, and that in a *good* OO design, most of the
classes wouldn't just shrink, they'd disappear.  A good part
of this is down to Smalltalk's support for and extensive use
of higher order functions from day 1.

>
> 3) Syntax coloring. (VIM color codes a file so that is there, emacs I don't know AT ALL.)
To which Steve Strong replied
> I don?t know of any editor that doesn?t do this -
> even github displays syntax colouring on erlang files.

My own text editor doesn't do syntax colouring.
Frankly, I hate syntax colouring.  I could give you
a long rant about why.  One big issue is that the
name is a lie.  It's *lexical* colouring; the colour
depends on what kind of token something is.  But I
can *see* that.  If you offered me an editor where
calls to functions whose definitions had been edited
recently were brightly coloured, or where the functions
imported from a particular module were brightly coloured,
or where slicing was used to colour the places where a
particular variable could be *changed* and *used*, I'd
find that really really helpful.  Why waste colour
telling me something that is already obvious at a glance?
I once came across a compiler (written in Finland) where
several passes had had to be woven together because of
the language it was written in, so they had coloured
each declaration and statement according to which pass
it was logically part of.  Now _that's_ good use of colour!

>

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Richard A. O'Keefe
I'd like to point out that static type systems
are not always the help you might expect.
Here's a puzzle from Jon Skeet's blog:

        using System;

        class X {
            static int M(Func<int?, byte> x, object y) { return 1; }
            static int M(Func<  X,  byte> x, string y) { return 2; }
            const int Value = 1000;
            static void Main() {
                var a =               M(X => (byte)X.Value, null));
                unchecked {
                    Console.WriteLine(a);
                    Console.WriteLine(M(X => (byte)X.Value, null));
                }
            }
        }
The expression M(X => (byte)X.Value, null) is the same sequence
of tokens in each case.  The same identifiers are in scope.  The
output is
        1
        2

The explanation makes my head hurt.



Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

kraythe .
In reply to this post by Richard A. O'Keefe
Well I think after seeing the arguments and the response of the community I
am trending seriously towards Erlang. I will probably make the mental
investment to learn and become good with emacs. And then move on from
there. I may still have a ton of questions. I would still, for example,
love to know who to 'reload' my application once it is started.


On Fri, Jan 31, 2014 at 12:24 AM, kraythe . <kraythe> wrote:

> Well I think after seeing the arguments and the response of the community
> I am trending seriously towards Erlang. I will probably make the mental
> investment to learn and become good with emacs. And then move on from
> there. I may still have a ton of questions. I would still, for example,
> love to know who to 'reload' my application once it is started.
>
> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> *Author of: Hardcore Java (2003) and Maintainable Java (2012)*
> *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
> <http://www.linkedin.com/pub/robert-simmons/40/852/a39>*
>
>
> On Thu, Jan 30, 2014 at 10:29 PM, Richard A. O'Keefe <ok>wrote:
>
>>
>> On 31/01/2014, at 7:49 AM, Steve Strong wrote:
>> > On Thursday, 30 January 2014 at 19:10, kraythe . wrote:
>> >> 1) Code completion. Sorry but I can't be bothered to type the same
>> flipping method name in its entirety 40 times.
>>
>>
>> There are three causes for "completion" in languages like
>> Prolog and Erlang:
>>
>> (a) Definitions with multiple clauses.
>>     Your editor should be able to turn "add a clause" into a
>>     single command.
>>
>> (b) Recursion.
>>     Your editor should be able to turn "add a recursive call"
>>     into a single command (basically the same as (a), just
>>     different stuff wrapped around it).
>>
>>     A programming style using higher order procedures can
>>     eliminate a lot of this.
>>
>> (c) Repetitive patterns of code.
>>
>>     A programming style using higher order procedures can
>>     eliminate a lot of this.
>>
>> There's a thing I find myself saying more and more often:
>>
>>         Why can't I see the structure?
>>
>> I was reviewing a page or two of Prolog code for someone the
>> other day.  By the end of three hours, I'd made some progress,
>> but I was troubled.  The code was clean, but it wasn't OBVIOUS.
>> What finally dawned on me would have been instantly obvious to
>> a real functional programmer:  the code was an interweaving of
>> a "compute argmax of a partial function over a finite domain"
>> and "here is this partial function".  Actually introducing the
>> higher order function in question let me explore several ways
>> of implementing that *without* any effect on the rest of the
>> code.  Breaking the specific partial function out and naming
>> it let me see that memoising *that* function -- which hadn't
>> previously existed -- stood an excellent chance of reducing
>> the overall cost of the algorithm down *hugely*.
>>
>> So I say, if you find yourself _wanting_ a method name to
>> appear 40 times in a day's work, you are doing something
>> badly wrong.
>>
>> For another data point, as part of building up my Smalltalk
>> skills, I used to pick up Java code and rewrite it in Smalltalk.
>> There were two invariable results:  first, the code would
>> shrink by about a factor of six, and second, it would become
>> painfully obvious that the original code was really really
>> bad design, and that in a *good* OO design, most of the
>> classes wouldn't just shrink, they'd disappear.  A good part
>> of this is down to Smalltalk's support for and extensive use
>> of higher order functions from day 1.
>>
>> >
>> > 3) Syntax coloring. (VIM color codes a file so that is there, emacs I
>> don't know AT ALL.)
>> To which Steve Strong replied
>> > I don't know of any editor that doesn't do this -
>> > even github displays syntax colouring on erlang files.
>>
>> My own text editor doesn't do syntax colouring.
>> Frankly, I hate syntax colouring.  I could give you
>> a long rant about why.  One big issue is that the
>> name is a lie.  It's *lexical* colouring; the colour
>> depends on what kind of token something is.  But I
>> can *see* that.  If you offered me an editor where
>> calls to functions whose definitions had been edited
>> recently were brightly coloured, or where the functions
>> imported from a particular module were brightly coloured,
>> or where slicing was used to colour the places where a
>> particular variable could be *changed* and *used*, I'd
>> find that really really helpful.  Why waste colour
>> telling me something that is already obvious at a glance?
>> I once came across a compiler (written in Finland) where
>> several passes had had to be woven together because of
>> the language it was written in, so they had coloured
>> each declaration and statement according to which pass
>> it was logically part of.  Now _that's_ good use of colour!
>>
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140131/ada1e813/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Michael Turner-2
One thing I've gotten out of this excellent thread: given what some
people (but not Joe, I guess) want out of a programming environment,
and what some people like in programming languages (Joe, for example),
somebody should do an Erlide for Elixir.

Regards,
Michael Turner
Executive Director
Project Persephone
K-1 bldg 3F
7-2-6 Nishishinjuku
Shinjuku-ku Tokyo 160-0023
Tel: +81 (3) 6890-1140
Fax: +81 (3) 6890-1158
Mobile: +81 (90) 5203-8682
turner
http://www.projectpersephone.org/

"Love does not consist in gazing at each other, but in looking outward
together in the same direction." -- Antoine de Saint-Exup?ry


On Fri, Jan 31, 2014 at 3:25 PM, kraythe . <kraythe> wrote:

> Well I think after seeing the arguments and the response of the community I
> am trending seriously towards Erlang. I will probably make the mental
> investment to learn and become good with emacs. And then move on from there.
> I may still have a ton of questions. I would still, for example, love to
> know who to 'reload' my application once it is started.
>
>
> On Fri, Jan 31, 2014 at 12:24 AM, kraythe . <kraythe> wrote:
>>
>> Well I think after seeing the arguments and the response of the community
>> I am trending seriously towards Erlang. I will probably make the mental
>> investment to learn and become good with emacs. And then move on from there.
>> I may still have a ton of questions. I would still, for example, love to
>> know who to 'reload' my application once it is started.
>>
>> Robert Simmons Jr. MSc. - Lead Java Architect @ EA
>> Author of: Hardcore Java (2003) and Maintainable Java (2012)
>> LinkedIn: http://www.linkedin.com/pub/robert-simmons/40/852/a39
>>
>>
>> On Thu, Jan 30, 2014 at 10:29 PM, Richard A. O'Keefe <ok>
>> wrote:
>>>
>>>
>>> On 31/01/2014, at 7:49 AM, Steve Strong wrote:
>>> > On Thursday, 30 January 2014 at 19:10, kraythe . wrote:
>>> >> 1) Code completion. Sorry but I can't be bothered to type the same
>>> >> flipping method name in its entirety 40 times.
>>>
>>>
>>> There are three causes for "completion" in languages like
>>> Prolog and Erlang:
>>>
>>> (a) Definitions with multiple clauses.
>>>     Your editor should be able to turn "add a clause" into a
>>>     single command.
>>>
>>> (b) Recursion.
>>>     Your editor should be able to turn "add a recursive call"
>>>     into a single command (basically the same as (a), just
>>>     different stuff wrapped around it).
>>>
>>>     A programming style using higher order procedures can
>>>     eliminate a lot of this.
>>>
>>> (c) Repetitive patterns of code.
>>>
>>>     A programming style using higher order procedures can
>>>     eliminate a lot of this.
>>>
>>> There's a thing I find myself saying more and more often:
>>>
>>>         Why can't I see the structure?
>>>
>>> I was reviewing a page or two of Prolog code for someone the
>>> other day.  By the end of three hours, I'd made some progress,
>>> but I was troubled.  The code was clean, but it wasn't OBVIOUS.
>>> What finally dawned on me would have been instantly obvious to
>>> a real functional programmer:  the code was an interweaving of
>>> a "compute argmax of a partial function over a finite domain"
>>> and "here is this partial function".  Actually introducing the
>>> higher order function in question let me explore several ways
>>> of implementing that *without* any effect on the rest of the
>>> code.  Breaking the specific partial function out and naming
>>> it let me see that memoising *that* function -- which hadn't
>>> previously existed -- stood an excellent chance of reducing
>>> the overall cost of the algorithm down *hugely*.
>>>
>>> So I say, if you find yourself _wanting_ a method name to
>>> appear 40 times in a day's work, you are doing something
>>> badly wrong.
>>>
>>> For another data point, as part of building up my Smalltalk
>>> skills, I used to pick up Java code and rewrite it in Smalltalk.
>>> There were two invariable results:  first, the code would
>>> shrink by about a factor of six, and second, it would become
>>> painfully obvious that the original code was really really
>>> bad design, and that in a *good* OO design, most of the
>>> classes wouldn't just shrink, they'd disappear.  A good part
>>> of this is down to Smalltalk's support for and extensive use
>>> of higher order functions from day 1.
>>>
>>> >
>>> > 3) Syntax coloring. (VIM color codes a file so that is there, emacs I
>>> > don't know AT ALL.)
>>> To which Steve Strong replied
>>> > I don't know of any editor that doesn't do this -
>>> > even github displays syntax colouring on erlang files.
>>>
>>> My own text editor doesn't do syntax colouring.
>>> Frankly, I hate syntax colouring.  I could give you
>>> a long rant about why.  One big issue is that the
>>> name is a lie.  It's *lexical* colouring; the colour
>>> depends on what kind of token something is.  But I
>>> can *see* that.  If you offered me an editor where
>>> calls to functions whose definitions had been edited
>>> recently were brightly coloured, or where the functions
>>> imported from a particular module were brightly coloured,
>>> or where slicing was used to colour the places where a
>>> particular variable could be *changed* and *used*, I'd
>>> find that really really helpful.  Why waste colour
>>> telling me something that is already obvious at a glance?
>>> I once came across a compiler (written in Finland) where
>>> several passes had had to be woven together because of
>>> the language it was written in, so they had coloured
>>> each declaration and statement according to which pass
>>> it was logically part of.  Now _that's_ good use of colour!
>>>
>>> >
>>
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Vlad Dumitrescu-5
On Fri, Jan 31, 2014 at 7:50 AM, Michael Turner <
michael.eugene.turner> wrote:

> One thing I've gotten out of this excellent thread: given what some
> people (but not Joe, I guess) want out of a programming environment,
> and what some people like in programming languages (Joe, for example),
> somebody should do an Erlide for Elixir.
>

That's on my list too, but so far there are other things with higher
priority. The good news is that many things can be shared with the Erlang
support.

regards,
Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140131/a4d43c4f/attachment.html>

Reply | Threaded
Open this post in threaded view
|

The quest for the perfect programming language for massive concurrency.

Michał Ptaszek
In reply to this post by Michael Turner-2
On Fri, Jan 31, 2014 at 7:50 AM, Michael Turner <
michael.eugene.turner> wrote:

> One thing I've gotten out of this excellent thread: given what some
> people (but not Joe, I guess) want out of a programming environment,
>

What I want in a programming environment would take a book to describe.

For starters, I would like it to be precisely documented.

It should be textual not GUI based - the reason for this is automation - I
cannot
easily automate things if they are GUI based. I can automate things if they
are text based.
Also It's very difficult to describe what to do in a GUI - the descriptions
need pictures
to tell you what to do.

I currently think Knuth was right.

The version numbering of TeX (using successive digits of Pi) is brilliant
TeX it at version  3.14159265 - Knuth also pays a reward (in cash) for
every new bug. The reward
doubles for each new error.

This scheme means that the project will be abandoned if there are more then
15 or so bugs - because the
version number would be too long, and the cost too great - and it probably
should be abandoned
if it had this number of errors.

Knuths way of working - Literate programming - with patch files - enforces
an incredibly disciplined way
of working. TeX (as a literate program) is just about the only example I
know of a large complex program
that is understandable and has no known errors.

TeX was produced without fancy editors and revision control systems and
IDEs and all that stuff.

The only downside of Knuths way is that it takes a long time to write the
program.

At a guess 80% of software costs are in maintenance of legacy code - so in
the long term
Knuthian development pays off. Being early to market with buggy software is
however the
way to make money. What earns you most money in the short term costs you
most in the long term.

TeX is interesting in a sense that (say) eclipse is not. I feel it is
possible to learn how TeX works

(aside I have started on this journey
      "Hello \end"
is a minimal TeX program that I can understand. All I need to do is
understand what
the primitives do, and then how the macro expansion works, ...
)

There is no way I can understand something like eclipse - there is no
documentation of what it does and how
it works - only documentation of how to use it.

I only like doing things I can understand.

emacs is in the TeX category - I can "in principle" read the code and see
what it does

(another aside - reading code to see what it does is highly overrated -
reading my own code
that I wrote years ago is difficult - reading other peoples code is doubly
difficult - reading undocumented
code in a language I don't really understand to fix a bug that I didn't
want to fix into order to solve a problem
that I do want to solve is an incredible waste of time - and that's why I
like Kuthian rigour in software)

Nowhere have I said that this is easy - but I believe that IDEs etc make
matters worse by hiding
what should not be hidden. If it's such a mess that it needs tool support
to write then the solution is
to clean up the mess not provide tools to hide the mess.

As I said - I could write a book on this :-)

Cheers

/Joe


> and what some people like in programming languages (Joe, for example),
> somebody should do an Erlide for Elixir.
>
> Regards,
> Michael Turner
> Executive Director
> Project Persephone
> K-1 bldg 3F
> 7-2-6 Nishishinjuku
> Shinjuku-ku Tokyo 160-0023
> Tel: +81 (3) 6890-1140
> Fax: +81 (3) 6890-1158
> Mobile: +81 (90) 5203-8682
> turner
> http://www.projectpersephone.org/
>
> "Love does not consist in gazing at each other, but in looking outward
> together in the same direction." -- Antoine de Saint-Exup?ry
>
>
> On Fri, Jan 31, 2014 at 3:25 PM, kraythe . <kraythe> wrote:
> > Well I think after seeing the arguments and the response of the
> community I
> > am trending seriously towards Erlang. I will probably make the mental
> > investment to learn and become good with emacs. And then move on from
> there.
> > I may still have a ton of questions. I would still, for example, love to
> > know who to 'reload' my application once it is started.
> >
> >
> > On Fri, Jan 31, 2014 at 12:24 AM, kraythe . <kraythe> wrote:
> >>
> >> Well I think after seeing the arguments and the response of the
> community
> >> I am trending seriously towards Erlang. I will probably make the mental
> >> investment to learn and become good with emacs. And then move on from
> there.
> >> I may still have a ton of questions. I would still, for example, love to
> >> know who to 'reload' my application once it is started.
> >>
> >> Robert Simmons Jr. MSc. - Lead Java Architect @ EA
> >> Author of: Hardcore Java (2003) and Maintainable Java (2012)
> >> LinkedIn: http://www.linkedin.com/pub/robert-simmons/40/852/a39
> >>
> >>
> >> On Thu, Jan 30, 2014 at 10:29 PM, Richard A. O'Keefe <ok
> >
> >> wrote:
> >>>
> >>>
> >>> On 31/01/2014, at 7:49 AM, Steve Strong wrote:
> >>> > On Thursday, 30 January 2014 at 19:10, kraythe . wrote:
> >>> >> 1) Code completion. Sorry but I can't be bothered to type the same
> >>> >> flipping method name in its entirety 40 times.
> >>>
> >>>
> >>> There are three causes for "completion" in languages like
> >>> Prolog and Erlang:
> >>>
> >>> (a) Definitions with multiple clauses.
> >>>     Your editor should be able to turn "add a clause" into a
> >>>     single command.
> >>>
> >>> (b) Recursion.
> >>>     Your editor should be able to turn "add a recursive call"
> >>>     into a single command (basically the same as (a), just
> >>>     different stuff wrapped around it).
> >>>
> >>>     A programming style using higher order procedures can
> >>>     eliminate a lot of this.
> >>>
> >>> (c) Repetitive patterns of code.
> >>>
> >>>     A programming style using higher order procedures can
> >>>     eliminate a lot of this.
> >>>
> >>> There's a thing I find myself saying more and more often:
> >>>
> >>>         Why can't I see the structure?
> >>>
> >>> I was reviewing a page or two of Prolog code for someone the
> >>> other day.  By the end of three hours, I'd made some progress,
> >>> but I was troubled.  The code was clean, but it wasn't OBVIOUS.
> >>> What finally dawned on me would have been instantly obvious to
> >>> a real functional programmer:  the code was an interweaving of
> >>> a "compute argmax of a partial function over a finite domain"
> >>> and "here is this partial function".  Actually introducing the
> >>> higher order function in question let me explore several ways
> >>> of implementing that *without* any effect on the rest of the
> >>> code.  Breaking the specific partial function out and naming
> >>> it let me see that memoising *that* function -- which hadn't
> >>> previously existed -- stood an excellent chance of reducing
> >>> the overall cost of the algorithm down *hugely*.
> >>>
> >>> So I say, if you find yourself _wanting_ a method name to
> >>> appear 40 times in a day's work, you are doing something
> >>> badly wrong.
> >>>
> >>> For another data point, as part of building up my Smalltalk
> >>> skills, I used to pick up Java code and rewrite it in Smalltalk.
> >>> There were two invariable results:  first, the code would
> >>> shrink by about a factor of six, and second, it would become
> >>> painfully obvious that the original code was really really
> >>> bad design, and that in a *good* OO design, most of the
> >>> classes wouldn't just shrink, they'd disappear.  A good part
> >>> of this is down to Smalltalk's support for and extensive use
> >>> of higher order functions from day 1.
> >>>
> >>> >
> >>> > 3) Syntax coloring. (VIM color codes a file so that is there, emacs I
> >>> > don't know AT ALL.)
> >>> To which Steve Strong replied
> >>> > I don't know of any editor that doesn't do this -
> >>> > even github displays syntax colouring on erlang files.
> >>>
> >>> My own text editor doesn't do syntax colouring.
> >>> Frankly, I hate syntax colouring.  I could give you
> >>> a long rant about why.  One big issue is that the
> >>> name is a lie.  It's *lexical* colouring; the colour
> >>> depends on what kind of token something is.  But I
> >>> can *see* that.  If you offered me an editor where
> >>> calls to functions whose definitions had been edited
> >>> recently were brightly coloured, or where the functions
> >>> imported from a particular module were brightly coloured,
> >>> or where slicing was used to colour the places where a
> >>> particular variable could be *changed* and *used*, I'd
> >>> find that really really helpful.  Why waste colour
> >>> telling me something that is already obvious at a glance?
> >>> I once came across a compiler (written in Finland) where
> >>> several passes had had to be woven together because of
> >>> the language it was written in, so they had coloured
> >>> each declaration and statement according to which pass
> >>> it was logically part of.  Now _that's_ good use of colour!
> >>>
> >>> >
> >>
> >>
> >
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140131/008730a6/attachment.html>

123