Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Whereas I'm fully aware of Scala and Akka actors, and other, non-stdlib concurrency packages for Scala, having gotten used to Gevent (it's a green threading + non-blocking IO framework/library for Python, that has not been getting the attention I think it deserves compared to stuff like NodeJS and all sorts of Actor frameworks) and how easy it is to write concurrent code with it—just write code as if with "real" threads but no actual OS threads are used, so you can have thousands of them, like Erlang processes, and all existing code Just Works—I have to say I'm not currently too much in love with the rather limited (and somewhat hard to compose with "normal code") way in which concurrent code needs to be written when Akka-style actors are used.
Now, there is Kilim, which appears to be doing what Gevent is doing (except it's using a CPS transform not runtime stack manipulation); also, Scala is known to be able to fully interoperate with Java. However, does this interoperability fully extend to the level at which Kilim operates? If yes, what are the key things to keep in mind when a combination of Scala and Kilim is implemented? I've found some resources (e.g. https://github.com/lllazu/kilim-scala) on this by googling but nothing clear or substantial.
Note: I'd also be interested in aspects such as:
why this is a typically discouraged approach to start with (i.e. I should be using Akka);
that I'm wrong and Akka-style actor code isn't limiting, or is not limiting enough to have any considerable effect on the (high level) style of code;
Feel free to have a comment on anything related
In C/C++ the most generic and least invasive approach to asynchronous execution seems to be the callbacks and I prefer to stay with the callbacks in order to be able to reuse the most libraries out there. With a bit of coroutine magick any callback-oriented library can be used imperatively, that is, for any method foo (callback (bar)) I can make a wrapper bar = foo (cbcoro) which can be used withing a normal imperative control flow (while doing context switching behind the scene).
I'm starting another project in Scala now and going to try to use the delimeted continuations in a similar way.
P.S. Bytecode instrumentation which works fine with the Java bytecode code can still fail with the Scala bytecode, I've seen this happen with db4o and DataNucleus, therefore you need a good support (or a very good knowledge of the tools in question) if you're going that way.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Recently My Project Manger has asked me to work on InterSystems Cache ObjectScript. Earlier i used to work as Java Developer (J2EE). So my question is how different is Cache from java. Comparison would be great to have.
Caché ObjectScript is very different from Java and has very little in common. It is more like dynamically typed compiled scripting language with meta language built in (class definitions) and with a large number of features you need to know to write the good code. All the code is compiled to a low-level (but pretty readable) so-called routine code and is processed by DBMS Caché and its application engine.
Take for example this reference. As you may notice, there are many weird symbols and structures like $, $$, $$$, ##class, &sql(...), &javascript<...>, #dim, $System, .#, $get, $zu(...), %, ^%, { ... }, ... (this list is big). Some of the language features are very unpredictable from the first glance. For example, function $get(...) looks like a fundtion but silently acts like a try/catch statement, as well as $data and some other system functions.
So prepare to work with InterSystems documentation! Also, recently developed InterSystems community is a great resource. And while Googling, you may find quite a few answers out of the internet, but just keep in mind to search with “intersystems” or “objectscript” keywords. But many things you won’t find there, and in this case you should use InterSystems docs or community to ask the questions. Once you will get used to the language (which for me took over 6 months), you will feel more confident in it.
Also it is worth mention that Caché ObjectScript is literally “dinosaur” language, which involves and upgrades over time. That’s why there are so many different features. Some of them you shouldn’t use anymore: for example, instead of writing code in routine, like people did before OOP concepths were introduced, you should use classes. ObjectScript’s JSON capabilities (ability to write JSON inside ObjectScript) was intoduced just approximately 1 year ago. And you may find a plenty of “prehistoric” code in Caché and should take it normally: it is a really huge ecosystem.
Hope this helps, happy hacking!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Almost all conventional languages today represent programmers intention as text source, which is then (lets say for sake of simplicity) translated to some bytecode/machine code and interpreted/executed by a VM/CPU.
There was another technique, which, for some reason, isn't that popular theese days: "freeze" the run-time of your VM and dump/serialize the environment (symbol bindings, state, code (whatever that is)) into an image, which you can then transfer, load and execute.
Consequentially, you do not "write" your code in a usual way, but you modify the environment with new symbols, while in "run-time".
I see great advantages to this technique:
Power-boosted REPL: you can introspect your code as you write it, partially evaluate it, test it directly and see the effects of your changes. Then roll back if you've messed up and do it again, or commit it to the environment finally. No need for long compile-run-debug cycle;
Some of the usual problems about dynamic languages (that they cannot be compiled, as compiler cannot reason about environments statically) are obliviated: the interpreter knows where what is located and can subsitute symbol references with static offsets and do other optimizations;
It's easier on programmer's brain: you "offload" different contextual information about the code from your head, i.e. you don't need to keep track about what your code has already done to some variable/data structure or which variable holds what: you see it directly in front of your eyes! In the usual way (writing source), programmers add new abstractions or comments to the code to clarify intents, but this can (and will) get messy.
The question is: what are disadvantages of this approach? Is there any serious critical disadvantage that I am not seeing? I know, there are some problems with it, i.e.:
try building a module system with it, that will not result in dependancy hell or serious linkage problems
security issues
try to version-control such images and enable concurrent development
But these are, IMHO, solvable with a good design.
EDIT1: concerning status "closed,primarily opinion-based". I've described two existent approaches and it is clear and obvious that one is preferred over another. Whether the reasons for that are purely "opinion-based" or there is a reasearch to back this up, is unknown to me, but even if they are opinion-based, if someone would list these reasons for such an opinion to develop, it should, actually, answer my question.
As a daily user of smalltalk, I've to say I haven't found any fundamental disadvantages and have to agree that there are lots of advantages.
It makes metaprogramming, reasoning about your program easy, and much better supports refactoring and code rewriting.
It requires/develops a different way of looking at your code, though. Smalltalk has little to offer to developers who are not interested in abstraction
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
When I am making Rails applications, I often use RuboCop to help ensure my code is clean and up to par as well as readable.
I'm learning Scalatra right now and I'm wondering if there's a plugin similar to RuboCop that checks the style of your code and gives you a warning when you may be writing "dirty code". This probably isn't needed for a seasoned Scala developer, but for a beginner, this is a god send.
Turn on -Xlint in your compiler options. If you've got some spare time, also turn on -Xfatal-warnings. In either case, you'll learn a lot about how to write safer Scala code.
Once you've completed that exercise, set up WartRemover, which is a much more opinionated linting tool. You may not agree with all the rules that ship with WartRemover—I'm not sure I do—but you'll also learn a lot by trying to follow them (and by arguing with Brian and co. when you don't think the target of a rule is actually a wart).
There are also some syntax- and style-oriented tools like Scalastyle (mentioned in the comments above) that can make sure you're not mixing tabs and spaces or whatever (to be fair, Scalastyle is a little less superficial than that). These things can be useful, but I don't personally find them very interesting.
Lastly note that the best static analysis tool for Scala is scalac itself (even without -Xlint turned on). A tool like RuboCop has two main goals: to encourage you to write more idiomatic, readable code, and to try to catch problems that could happen at runtime before runtime happens. In a compiled language (especially a compiled language with a rich type system like Scala's), the compiler itself can do a lot of the work of catching problems in your code before they crash your program at runtime.
Others already mentioned -Xlint, ScalaStyle, WartRemover, etc., so let me just make a bit of a general point about purism vs. non-purism.
I think what is considered "good" isn't universal, it depends on the use case. Sure it's awesome to only use vals and no vars, to write everything using beautiful tail recursions, to use monads - but tail recursions aren't always possible and you can blow a stack when the recursions can't get optimized, and even Scala's for comprehension translates to map/flatMap/foreach, which is slow compared to a while loop. For RESTful WS and other Scalatra stuff, you probably don't care about this, because I doubt you'll have deeply recursive code of your own, and Scala is so much faster than Ruby that who cares about a for comprehension vs. a while loop performance. So, I assume you can remain a purist in this context, and that's why it would be a good time to learn best practices with the above-mentioned tools.
However, when one is trying to squeeze out the last bit of performance out of the application, one is rarely a purist. When you learn more about Scala, compare the purist code to, say, the internals of Apache Spark - they use while loops instead of for comprehensions (or map/flatMap etc.) in many places for performance reasons. The code may look awful at times and a purist would probably get a heart attack, but there's a specific reason for it - the designers knew Scala well enough to themselves be purists, but chose to do otherwise for specific reasons that took priority. I think we need "liberal religions" - it's good to be a purist 99% of the time, but when the cost is way too high and you really know why you're transgressing a rule and what the consequences are, try to consider alternatives. That said, like Travis mentioned, for beginners purism is good because they need to learn what good practices are that work in the majority of cases, and you can then decide to write non-purist code only when there are extenuating circumstances :)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
Question
Can anyone recommend a library for Ocaml that offers an actor-based concurrency model for distributed computing?
Note here the "actor-based" and "distributed" - I'd like the actor-based model, but also I want seamless handling of distributed actors - I don't want to write the protocol to talk to them. The library should ideally also offer standard patterns such a supervisor trees and so on.
Motivation
I love Erlang concurrency model and ability to transparently deal with distributed processes and local processes together. However, I find Erlang's syntax to be rather limiting and would like a much more expressive language. I'm considering moving from Erlang to either Scala or Ocaml.
I know Scala has the Akka library which seems to offer a nice Scala version of Erlang's concurrency model. I'd like to see what is available on the Ocaml side.
Aside
I'd also be happy to hear about actor-based concurrency libraries for other languages (particularly C++, Haskell, Python and Ruby).
While it may not be the exact same model that Erlang uses, you might want to take a look at JoCaml, which is based on the join calculus.
You can take a look at parvel -- message passing library/framework for ocaml. It's not yet complete, but already includes some primitives for programming with actors.
"I'm considering moving from Erlang to either Scala or Ocaml."
You should consider scalang, which allows you to program in Scala, but use Erlang's actors.
I recently saw a talk on the language by #moonpolysoft (Cliff Moon) at the Strange Loop conference. Cliff Moon developed it for https://boundary.com/ and open-sourced it earlier this year.
You'll probably spend a lot of time reading about:
Scala and F# have akka and MailboxProcessor which are being used in production apps (note: Scala actors and, I think, akka, are very tied to Hotspot; I'm not sure if MailboxProcessor can be used under MONO)
Haskell has userspace threads and at least 1 actor implementation which i don't know a lot about
For ML and ocaml, some libs which are probably not widely used: poly/ML and oc4mc
and netmulticore
Although, it is a very old question things have changed since it was asked. C++ has an actor model implementation which is quite robust. It also provides distributed computing features as asked by OP. The homepage is at http://actor-framework.org/
Further, it can also make us of OpenCL for HPC the module for which is located at github in one of the repositories.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
since concurrent programming becomes constantly more important, I was wondering
what you think about Erlang vs. Scala in that respect. It seems to me that Scala
has a larger user base and potentially a brighter future than Erlang. Furthermore,
Scala is kind of java.
I know these questions are alway a bit subjective, but what would be the better
future investment: Erlang or Scala. Or even another language?
Erlang has been designed for concurrent, fault-tolerant communication systems. You can easily write servers that handle large number of network connections and (thanks to one garbage collector per Erlang process) the servers can retain soft real-time characteristics (i.e., the whole server is not paused until GC finishes). You can also hot-swap Erlang code, distribute it across several nodes, etc. That's why (arguably) the most-scalable XMPP server (ejabberd) is written in Erlang. Yaws (a web server) is another example where Erlang excels, see: http://www.sics.se/~joe/apachevsyaws.html. Riak/Couch are examples of NoSQL DB build with Erlang. These are the problems where Erlang is a great choice.
But Erlang VM is not as fast as JVM in terms of raw computations, so as soon as you need to do something computationally intensive (e.g. financial modeling) JVM will be your preferred platform. Moreover, Erlang's concurrency model (actors) is baked in the language. If that doesn't fit the problem you're trying to solve, then you won't be happy with Erlang.
Scala is more 'general' language in a sense that concurrency, horizontal scalability, or fault-tolerance is not part of the language. It is solved at the level of libraries (that's why there are at least 3 implementations of actors in Scala). The good thing is that you can pick concurrency model that fits your domain. For example if you need software transactional memory (STM), just pick Akka and you're good to go (http://akka.io/).
Plus there is the whole argument that with Scala you can leverage your "JVM investments" and multitude of JVM libs.
You didn't give any info on what kind of software you want to write with either of those languages so it's hard to give you a definitive answer. Having said that, given all the above, Scala may be "safer" investment than Erlang (not bashing Erlang/OTP at all, it's a fine language/platform).
BTW. If a single-machine concurrency is important to you Clojure (http://clojure.org/) should not be overlooked (also JVM language).
UPDATE1: If you like what Erlang offers but not its syntax, take a look at elixir-lang.org
UPDATE2: STM has been removed from Akka - now you have a choice (mix/match) between actors (untyped or typed) and streams.
It doesn't matter Just pick one and stick with it for a while. Learn some stuff, make some cool things and either keep going with that language or move on to another one.
With respect to learning concurrent programming, either will be fine. The key here is that you will be learning something new and unless there's a job opening that you are trying to get hired for that uses Erlang specifically, it really doesn't matter. Plus, even if that opening did require Erlang, you would still likely have a good chance if you knew Scala really well.
Just think, all of the time you have spent trying to pick a new language could have been better spent if you just picked one and already started learning it by now.
Both languages, at the core, are not that hard to learn, and also to learn the concurrency features they provide. In fact, Scala actors are influenced by Erlang actors. I would go to both of them, take your time looking at their construct, do some tests in concurrency problems, etc.
If you know Java, Scala will be more natural, as Erlang is more like prolog. If, on the contrary, you're more oriented towards mathematical or logical type of languages, start with Erlang.