ane

I do understand your point, there is a lot of ego-stroking going on in the community, and I loathe it as well... but this page? This is just a demonstration of Either, one of the simpler types! I honestly think you just saw the word "algebra" and that was enough to alarm you, which I kind of understand as well, but still. This isn't λ-bro stuff. This is one of the good ones.

That's... actually simple stuff. Have you had a look at Scalaz? Or Shapeless? The whole point of Cats is to solve the overkill of Scalaz, where you sometimes do need algebra, by making abstractions simpler and safer to use. Remember, nobody is forcing you to use this wizardry in Scala. You can write it in a simple, matter-of-fact better Java style; or you can leverage the power of abstractions to create something advanced. You don't have to indulge in applicative functors and coproducts just because. Use them wisely, if at all!

Scala is a highly versatile hybrid language that can be used in a way that doesn't promote needless complexity. Just like you need not use the most advanced OOP features, you need not use advanced FP features, nor do you have to use macros. If you don't want to.

This choice is what makes it an interesting and pleasant language to work with. I've often dealt with Scala code that is much simpler to understand than comparable Java code, but still more often than not, Scala code is made needlessly complicated.

That choice implies a certain kind of respect for the programmer: here's a very, very powerful tool, and use it wisely.

Go is the antithesis of this, and I get its point, it's the opposite philosophical direction. I think it's a direction that will not move the industry forward, it's a direction that will undoubtedly help us produce value---software, reliably---instead of doing something amazing.

+1

HashiCorp is working on something like this: https://github.com/hashicorp/go-plugin

The actual northernmost French (the Republic) community is in Saint-Pierre-et-Miquelon, which is funnily enough just next to Quebec! it's an overseas territory and they use the Euro as their currency.

https://en.wikipedia.org/wiki/Saint_Pierre_and_Miquelon

Soros has insightful opinions regarding Orbán and the internal political struggle arising within the EU, but caveat lector: Soros has a large, literally vested interest in seeing the Euro collapse. That is to say, he has bet a huge amount of money on it collapsing. So he paints a bleak picture about the future of the Euro, because it is the future he desires.

It does indeed. The interactive shell is called IEx: http://elixir-lang.org/docs/master/iex/IEx.html

Is the ad hoc distinction between compilation and "transpilation" really worth it? Can't we just call them compilers? I get that the difference between compilation and transpilation is that the target language of the latter is not a lower lever language, which would be in the case of C and Assembler, but that it targets a language that's more or less of a similar level. Is this really worthy of another term? I'm not sure.

I think he means that employee is telling the manager that the employee is tracking his own time, thus, when the manager requests work to be done, the manager will take a resource-oriented approach to the employee's time and focus. It might make the manager more conscious about this often subtle detail (time is money) and they will likely feel more restricted when it comes to managing the employee, instead of being empowered. This is good for curbing micromanagement.

The MVC pattern is honestly so simple it or something like it usually emerges from most UI architectures. I would argue that even the increasingly common backend vs. frontend separation is a form of MVC. Of course, MVC isn't synonymous with MVC frameworks.

When it comes to pure old MVC, I feel that it is a bit like Greenspun's tenth rule:

> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

So any UI environment will eventually contain an architecture that more or less embodies the spirit of MVC.

And I think MVC is fine within a single environment. That means, the information travelling from the models to the controllers to the views does not contain intermediary where mediums are crossed. A traditional Rails application crosses from databases to a Ruby program to a web browser, and each bit of logic is dependent of the others.

What makes the backend/frontend separation such a good model is that a front running on a REST API is not inherently dependent on a protocol or a server implementation, and the same applies to the backend. This will work in the post-HTTP world, whenever that comes.

Traditional Rails apps assume they are talking to a web browser. This is assumption is no longer tenable.

What made you switch? I mean, if you are already familiar with Emacs, I don't see any reason to switch. CIDER and clj-refactor offer a lot more functionality, and the debugger is fantastic.

Your Python example is functional programming! You're doing exactly the same thing as in Clojure, just not in a Lisp syntax.

Therefore, in your question, you could substitute Clojure with functional programming, and the examples in which FP allows you to express thoughts you wouldn't know how to express in for, while and so on -- are plentiful.

I may not be answering your question, but there's a reason for that: the functional programming aspect isn't Clojure's main selling point. It's the other ideas. Software transactional memory, immutability, its emphasis on state and identity, the protocol system, transients, concurrency, transducers, the list goes on.

Elixir isn't that old and it'll be interesting to see if it caches on. It's basically Erlang with a nicer syntax and some new ideas.

Lisp isn't just a concept, it's also a family of implementations. The two significant branches are Scheme and Common Lisp. The only thing they have in common is using parentheses - they're about as different from each other as JavaScript and C.

Scheme is more functional programming oriented, Common Lisp is less so. Scheme is very minimalist, it's most recent standard contains only about 20 syntax definitions! Unfortunately this transformed Scheme into a concept from an implementation. Compare this to CL, which has just about everything and the kitchen sink, and is more of a "concrete" language.

To choose a Lisp is to choose an implementation. I'd recommend playing with all of them. Common Lisp, a Scheme (CHICKEN or Guile), or the "recent" ones like Clojure and Racket. Racket is very much a Scheme - it used to be called PLT Scheme - and has a bunch of PLT superstars building really cool stuff with it.

Clojure, the JVM-based Lisp, has more in common with Common Lisp than any other, but embodies a strong philosophy about identity and value. It has a lot of common with Haskell in that regard, supporting immutable data structures and STM right out of the box. It also has really cool ideas like transients [1], transducers [2] and protocols [3], features which have since crept into other languages.

Clojure is probably the most popular right now, and its ecosystem is growing every day, and can be used for building serious stuff. This doesn't mean you can't build cool stuff with other Lisps! CHICKEN Scheme has a great package ecosystem, so does Racket, Guile lags behind, and for Common Lisp there's a recent "State of the Ecosystem" article[4] that summarizes its ecosystem.

"Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot."

-- Eric S. Raymond

[1] http://clojure.org/transients

[2] http://clojure.org/transducers

[3] http://clojure.org/protocols

[4] http://eudoxia.me/article/common-lisp-sotu-2015/

None exist. So far the best solution is to use Emacs with [2]

* merlin-mode, for autocompletion

* ocp-indent, for external code formating... think running gofmt on every enter press (surprisingly, it's fast enough unless your file is 2k lines long)

* tuareg-mode (everything else, REPL etc.)

* flycheck-ocaml for syntax checking

The "real" IDE plugins aren't even close and that's saying a lot since the hodge-podge of addons I just listed isn't

The default Emacs user experience is awful so if you're a Vim user, just install the "evil" package and enable it inside Emacs by doing M-x evil-mode, then you have Vim inside Emacs. Or use Vim, but the experience isn't as complete w.r.t. tooling[3]. There's always Spacemacs as well[1].

[1] https://github.com/syl20bnr/spacemacs

[2] https://github.com/the-lambda-church/merlin/wiki/emacs-from-...

[3] https://github.com/the-lambda-church/merlin/wiki/vim-from-sc...

With the addition of virtual desktops to Windows 10 you can keep the full-screen Virtualbox in another desktop. Switching between OSs just by pressing Ctrl+Super-Right/Left is fun.

Even if it's not official the IntelliJ Go plugin is quite good. It recently added support for a debugger, and it has a lot of static analysis capabilities and refactoring. I would say it is on par with other environments for most serious languages. The Emacs go-mode and vim-go are good enough but not as great.

There is a general attitude in the Go community eschewing all sorts of complexity be it in the language itself or tooling and this attitude is toxic and stupid. It will prevent Go from becoming a serious language unless this nonsense about "simplicity" is left to perpetuate. There is nothing wrong with keeping a language elegant--cue a brouhaha about generics in 1... 2... 3...---but forcing this attitude to tooling is not a wise thing to do. A significant majority of professional devs do not write their code in vim without syntax highlighting, which is what some eminent members of the Go community seem to be in favour of. They need auto-completion, refactoring (which search and replace isn't), automated deployment and testing, debugging and project support.

It's just going to keep getting more features from ES6 and ES7. Some of the features in ES6/7 were taken from TypeScript, I reckon.

https://github.com/Microsoft/TypeScript/wiki/Roadmap

The benefit of CIDER (the Clojure Emacs development environment) is that it now has a s-expr based debugger, whereas Cursive's debugger is still call stack based. So you can traverse the AST like in any other Lisp debugger and evaluate and manipulate s-exprs as you go.

OCaml!

The food is rather nice.

You will regret not going later. If you have the interest, computer science can offer staggering amounts of enlightenment.

Same here. I drink it for just the taste and smell. I can go off it for days and I don't get any adverse effects, nor do I feel any different lest I consume it excessively (about a litre).

The JVM type system uses type erasure (which means that any generic type Blah<T> becomes Blah at runtime), so you can't instantiate types based on generics at runtime. In C# it is valid to do "T foo = new T();" and because of reified generics, this works. You can't overload functions based on their generic type ("Foo(List<int> ...) and Foo(List<string> ...)" on the JVM (the <...> bit gets erased!). This was done to preserve binary backward compatibility when generics were introduced in Java.

The CLR supports user-defined value types whereas the JVM doesn't, it relies on a classical uniform data representation. Because value types are stack allocated, in C#, you will have less stress on the GC (because you can define stack-allocated value types), on the other hand, the JVM GC will be doing a lot more work. This is why you see "the JVM is heavily optimized" statements.

Another downside of the JVM is that it has no native support for tail call optimization, this is not that major, but it is a bit silly for functional languages running on the JVM (Clojure). The Scala compiler is intelligent enough to do this by itself, but there's no native support on the VM itself, unlike on the CLR.

Another point is that the CLR was designed as a true language-agnostic virtual machine, so developing new languages on it is easy. It is not hard to do that on the JVM, but more so than on the CLR.

Well, if somebody breaks the kernel so that printing doesn't work, it will most likely return something strange, in the case of Clojure, an exception.

A pure function always returns the same result because it only depends on its input parameters. An impure IO function does not.

There's also evil-lisp-state (which is essentially a modal interface to smartparens), https://github.com/syl20bnr/evil-lisp-state, and evil-smartparens (https://github.com/expez/evil-smartparens) which makes the default motion operators work better with sexps.

I think in Estonia any invested money is exempt from taxation, that is to say, if you invest your profits, you will not be taxed.

Java generics aren't the best example of how to implement generics. C# or Rust are better in this regard, which both have reified generics. Generics do solve a practical problem identified decades ago, ad-hoc code generation or void* aren't the solution. I don't think the omission of generics has any bearing on how easy writing tooling is.

You can always omit them, if you're prepared to deal with code duplication, but I think you're downplaying its significance: it is not just "maybe some" code duplication, nor is it a "a few casts". It's sometimes a deep, murky swamp you're forced to trudge in, and it's not pleasant.

The lighting is indirect and not as strong as in a backlit display. That could affect the amount of melanin suppression going on. That is to say, it could very well be considerably weaker than in backlit displays.