dm3

This actually looks pretty handy. Not sure why you'd think it's so terrible - how else would you capture a request in a variable to play with it in the REPL?

I think a lot of the constraints can be relaxed during the development phase.

I'm not a big fan - once you start encoding type information in names, you have to be extremely attentive when refactoring. It doesn't scale too well in a larger team.

I prefer clojure.spec to guard significant (ns, api) boundaries.

* Don’t use “use” - agree completely.

* Use consistent, unique namespace aliases - agree. This helps tremendously when consistent across projects given the varying tooling capabilities. We even have a dictionary of namespace -> alias mappings that is expanded as new commonly used namespaces appear.

* Use long namespace aliases - agree partially. I have a few favourite namespaces present in pretty much every project that get a single letter alias.

* Choose readability over compactness - agree partially. Another part of the solution is keeping the functions small and all the types explicit. However, there's a fine line between that and having to use something like a hungarian notation for the local variables.

* Don’t rely on implicit nil-to-false coercion - agree. However, I never find myself in this situation. Mostly because I just don't use plain booleans. Pretty much always you can use an enum (keyword) instead to better express the intent. When used locally - in the scope of a single function - I find that boolean-nil problem doesn't cause any issues.

* Avoid higher-order functions - agree completely. `comp` and `partial` in Clojure are awkward. If you find yourself using them, you're probably nesting too many lambdas with hash (#) notation - move some of them out into a `let`.

* Don’t spare names - agree partially. The suggestion is definitely more readable. I just love writing threading expressions.

* Don’t use first/second/nth to unpack tuples - agree completely.

* Don’t fall for expanded opts - agree completely.

* Use * as prefix for references - agree. This needs some sort of a blessed reference in the Clojure documentation. Something to syntactically mark constants, e.g. `+constant+`, something to mark refs, e.g. `+ref`.

* Align let bindings in two columns - this is purely a matter of preference. I don't care either way.

* Use two empty lines between top-level forms - also a matter of preference. I prefer a single line.

Interesting. As a datapoint - I've never programmed in Python (mostly Java/Clojure) but had no trouble answering the questions.

You don't have to use maven directly. Something like https://github.com/bodar/jcompilo would be much simpler and faster for a small project.

Do you have any particular reasons to prefer Node (assuming Javascript) to Clojure/Groovy?

Asking, because I do most of my development in Clojure and find it much nicer than Node both for POC and production. There's also self-hosted Clojurescript now that runs without a dependency on JVM.

It's possible, but you have to be disciplined. I try to get up an hour or two early every day at least for a week per month to put some quality time into the studies/projects. Other times it's 10 minute chunks that you squeeze in throughout the day which aren't productive.

Actually, the new G1 collector deals very well with latency-sensitive workflows. I'd say it's comparable to Go if you adjust your heap size to the working set. You can try running the benchmarks here - https://gitlab.com/gasche/gc-latency-experiment.

Having built a few RDBMS-based event stores - it's pretty easy to do. There are two parts that I can think of that are not completely trivial - appending events to the stream while respecting "expected version" modifiers with optimal concurrency and allowing for fast and light subscriptions to new events (e.g. LISTEN/NOTIFY in Postgres, ringbuffer on the client).

The good thing is that you can adapt the event store to your performance requirements and do the simplest thing possible in a huge amount of cases.

You don't need that `cemerick.pomegranate` import. Boot can already do that - the `deps` functions should look like this:

    (defn deps [the-deps]
      (merge-env! :dependencies the-deps))

For those interested - there's a Clojure RETE implementation:

https://github.com/rururu/rete4frames

Very nice. This looks like a great complement to `jt` (https://github.com/micha/json-table) - a tool to turn JSON into plain text tables. Both seem to be super simple tools written in C with no heavy dependencies.

We're using pallet. Even though it's not trivial to get started with and the docs are quite sparse, it provides a solid foundation for scripting the configuration management tasks. I much prefer it to Ansible/Chef/Puppet. However, as you're exposed to the full programming language, there are much less constraints to what you can do. You'll need a layer of rules (a framework) of your own if you don't want to end up in a mess.

Activity of the core project seems to be low, but that's true for many other mature Clojure projects. You can still use them successfully.

If you're ready to check out Clojurescript, I strongly recommend trying out Hoplon:

https://github.com/hoplon/hoplon

It requires a certain shift in thinking when coming from pretty much any other framework. However, it avoids all of the unnecessary complexities of React by exposing the DOM elements directly as functions. The mindshare behind it might be low compared to Om or Reagent, but the people that are using it are pretty active at Clojurians slack channel #hoplon and on IRC (freenode, #hoplon). It's also FRP-based and pretty efficient. Highly recommend!

You have to start with the problem. If your problem is solved by highly available and stateful services, then the Erlang VM on the host seems like a good idea. If the availability doesn't matter that much or the services can be made stateless without much pain - go for the containers.

As a counterpoint - I went back to VIM after a month of spacemacs. I've actually put in the effort to learn the keybindings for all the relevant tasks I needed and the way Emacs works internally, as much as it's possible in a month. I was doing Clojure and the main problem for me was the less fluent editing - most commands in vim are at least one keystroke shorter. The other big problem are non-evilified plugins that completely mess up the workflow - you constantly keep switching between "I'm in VIM" and "I'm in Emacs" mindset. Also, emacs feels a bit more sluggish, although that may be just CIDER.

The things I loved:

  * helm mode - autocompletions for the commands
  * consistency - SPC + ... everywhere
  * REPL in a buffer

I understand that a month with Emacs isn't remotely enough to make up for years of VIM, but I didn't find enough benefits to stick with it.

What are the perceived advantages over the standard VIM? I understand that the core is simpler, the plugin API is better, but what would make one switch as a user?

Specter also works with Clojurescript :)

The other benefit of the JVM is the multiple languages that run on it - did you try Clojure or JRuby already? Or do you mean Java as in JVM and you don't want that in your stack for some reason?

Could someone explain in simple terms how is the target set to the robot so that it can learn to accomplish the task? For example, what inputs are provided in order for it to understand that it needs to put the cap on the bottle?

There's an argument for spoofing from earlier this year [1] which I would tend to agree with if the proportion of spoofers and HFT front-runners actually balanced out. Not sure how it really is in reality though.

[1] http://www.bloombergview.com/articles/2015-01-23/high-freque...

There's a publication comparing plea bargaining system of US with the tortures commonly applied in medieval courts to get convictions: http://www.ibccrim.org.br/DPE2014/docs/flavio/torture.pdf

In short, the way the plea bargaining system developed was due to the jury system being too ineffective and time consuming in producing convictions. Thus the workaround which forces innocent people into accepting charges.

There's a good comment on this topic in the /r/science subreddit: http://www.reddit.com/r/science/comments/3012yj/global_warmi...

Minor remark: one major selling point of (some) hedge funds is low correlation with other investments, not huge returns.

It's neither obsolete, nor antiquated. People in this thread seem to conflate DDD and OOP which is understandable given that 90% of DDD resources target the typical enterprise Java/C# setting.

The truth is, DDD consists of two parts: tactical patterns, such as Entity, Value Object or Aggregate Root and strategic design patterns such as Ubiquituos Language, Bounded Context or Context Maps. Tactical patterns are much easier to understand and apply, but most of the benefits claimed by DDD are provided by the application of strategic design.

Sadly, most people starting with DDD focus on the tactical patterns and technology, then get demotivated when the benefits do not appear.

One of the best known proponents of a Microservice architecture is Netflix. Adrian Cockcroft has been talking about it at conferences for quite some time now (e.g. http://www.youtube.com/watch?v=wyWI3gLpB8o).

Netflix is known for opensourcing a whole suite of infrastructure components which allow to run a microservices architecture on AWS (https://github.com/Netflix). These include various configuration management tools, event buses, monitoring solutions and much more.

To my mind, the most important benefits of a microservice architecture are a clear separation between teams working on different services and the ability to upgrade said services autonomously without stopping/breaking the consumers which allows for fast iteration. The important point is you don't just replace services, but introduce new versions and automatically retire old versions when all of the consumers upgrade to the new ones.

Time and time again I've found the following classification useful for thinking about REST and web-APIs in general: http://www.nordsc.com/ext/classification_of_http_based_apis....

Most of the stuff people are describing here as REST would be classified as HTTP-based Type I/II according to the above resource.

> like some of those American Indian tribes that tried and failed to build corn-based civilisations in pre-Columbian times

Do you imply that corn had negative effect on Indians? From what I've read [1] it actually allowed Indians to maintain their population levels without having irrigation technology comparable to one developed in middle East and Europe.

[1] http://mitpress.mit.edu/books/technology-world-civilization

Core.typed appears to have some higher kind and variance support (as seen in the user guide - https://github.com/clojure/core.typed/wiki/User-Guide).

Type classes can be mimicked via multimethods or protocols.

They actually are easier once you learn the (simple) novelties. Simplicity makes the learning process shorter.