I disagree. The presence of several typos on the main page is a big red flag for a technical book.
Having said that, I'm still interested, but the lack of proofreading on the author's release announcement for his book is definitely counterproductive.
I have experience teaching kids Lua, and with the right metaphors and a little bit of backtracking and foundation-building, even complicated ideas like emulating classes and single inheritance can be understood and even implemented by young students.
If I taught them lua reserved keywords, and a couple little math tricks here and there, they usually would all bunch up everything into a couple huge functions, and their game would (sort-of) work but be impossible to reason about, and very painful to extend.
Introducing objects as a way to represent things that they want the game to do (draw things, shoot things, eat things, etc), it becomes clear to them that there is merit in structuring programs with objects beyond "shrugger says to do it like this!"
OOP on its own doesn't make much sense. You can't teach someone to drive stick shift if they don't know what a car is. Maybe you could, but that's probably even worse.
You misunderstand how capitalism works. If you don't want these companies to succeed, don't give them money and don't give them data they can make money from.
I don't use Facebook products because I don't want to give Zuckerberg my money. I don't use Apple because I don't want to give money to a company whose original figurehead thought that wearing Mom-jeans to press conferences was in any way professional.
The point is that these companies, however monopolistic they might seem to you (and me), are driving innovation several orders of magnitude faster and more efficiently than organizations like Mozilla or GNU. A company exists to make money. That's an ethos that I personally find more consistent and more comfortable to think about than "we should make software that EVERYONE can use" and it's a safer bet as well, since these companies will go out of business if they don't make money whereas GNU/Mozilla/et al will vomit out software that sorta works for a million years.
Also, machine learning is not about predicting the future anyways, it's almost exactly the opposite. Understanding what people have done is much more actionable than trying to figure out what people are GOING to do, because we are very fickle, complex, imaginative creatures. Could you have predicted that I'd write this comment? No. Could a program that has read every previous comment that I've ever made predict this comment? No. Could it predict that I might write a comment of a similar nature? Sure. If we were playing poker and I thought that you were going to fold, that's much different from some algorithm that was CERTAIN you were going to fold.
I switched from Ruby to Scala, and I have had an absolute blast. Elixir is sort of chained to BEAM, which doesn't appear to have as bright a future as the JVM or LLVM does, so Scala seemed like a safer bet.
Reading about Elixir is cool sometimes, but then I look at Dotty, and I feel confident that I made the correct choice.
I've also been keeping an eye on Crystal (statically typed Ruby-esque language, LLVM), but they aren't making great PLT choices so far. Maybe they'll get it together later. Scala-Native will blow it out of the water most likely anyways.
Sort of the opposite of losing statically typed programming, but I've really enjoyed the journey and it's improved my work a lot more than I thought it would. I know Ruby pretty well and I used to feel really dumb all the time when things would break, and it took some time for me to realize that it was a language problem. Looking back and reading some of the Ruby that I ported, it was impossible to reason about, and very difficult to make guarantees for. Nothing was solid at all, and runtime errors could hypotehtically stop the show at any time. With Scala there's a much sharper baseline of what will definitely work or not work.
Types make a LOT of things so much easier, in exchange for making a few things SLIGHTLY more tedious. After doing it, I'd make that trade ten more times if I had to.
> Elixir is sort of chained to BEAM, which doesn't appear to have as bright a future as the JVM or LLVM does, so Scala seemed like a safer bet.
Where does this impression come from? The BEAM VM is maintained by Ericsson, we get new "major" releases every year. In the last years we got the maps data type, the new scalable timer API, better tracing facilities, dirty schedulers, and so on. Lately, at ElixirConf Berlin, we heard about the current efforts on scaling the Erlang Distribution to thousands of nodes out of the box (it is already possibly today, just not by default).
They are also plenty of research projects, mostly in Europe, about improving the VM, development experience and scalability in different ways, such as http://release-project.eu/, http://www.prowessproject.eu/ and http://paraphrase-ict.eu/. That's not including the usual suspects like Chalmers and Uppsala in Sweden, which have been exploring different aspects, specially in the testing area with property-based testing, concolic testing, systematic concurrent testing, etc.
Companies like Adapteva (behind Parallella), Basho, Erlang Solutions, Plataformatec, and many more are investing in the ecosystem too. If there is one thing I am not worried about is the VM and the runtime bright future.
In my opinion, the simple fact we have a runtime with preemptive light-weight processes from the ground-up (instead of tackled on top as a library/framework) with per process garbage collection and inter-node communication taken care of is enough to hold the VM for the next handful of years, even if all development ceased today.
I can't speak for shrugger, but when I see the manpower invested in improving Java, .Net, JavaScript, Go, LLVM runtimes/compilers, I'm personally wondering if BEAM will be able to follow. We are starting to see languages like Python fade away because of that, when fast execution starts to matter.
That's right, LLVM does support JIT compilation. But it's just one tool in the toolbox. I would hazard a guess that most projects which depend on LLVM don't use the JIT compiler.
But even with a JIT compiler, LLVM doesn't provide the kind of runtime services (e.g., memory and resource management) that we would typically associate with a VM runtime like the JVM's. Like their Web site says, "Despite its name, LLVM has little to do with traditional virtual machines, though it does provide helpful libraries that can be used to build them."
I don't think you've communicated what you were trying to accomplish very well with your LLVM comparison. Many people will see it and think you're confused at what you're talking about.
I saw about 5-6 products which use Scala.js and I haven't heard of any of them before. Who else uses that? Seems rather obscure.
Is Scala Native used widely? They just finished implementing java.lang.String 20 days ago or so. At least Erlang on Xen has been serving web pages for a few years now: http://erlangonxen.org
But most usage of Scala is on JVM still, wouldn't you agree? We are not talking CPython/Jython/PyPy/Numba... I don't know, the claim that Scala is widely implemented on other platforms while Elixir is tied to BEAM doesn't quite go far for me.
I understand, but your opinion doesn't change the facts. Scala.js is more than mature, with some huge projects already built in it. I'd not heard of erlangonxen, but it would take a lot of convincing to re-write something in Erlang to begin with, when I could write it quicker in Scala, and run on 2, eventually 3 different platforms.
Scala Native is not very far along compared to Scala.js, but it is actively being improved, and is considered an official extension. Additionally, Dotty will bring huge improvements for JVM scala.
I am not super happy with JVM most days, but I'd far and away prefer to be chained to JVM than BEAM. I mean, it's not even a question at this point, considering the billions of dollars spent developing JVM and the work of the brightest minds of several generations. Joe is a cool guy and all, but Erlang is objectively a niche platform compared to JVM.
missed a couple Govt classes? The existence of central banks are opposed by people who want to restrict third-party control of their money, not let any loser who walks by have a say (like DAO)
Ethereum is a bad idea and people are too embarrassed to admit it. I get it. However, turning around and shoehorning that sentiment into "They don't understand central banking" is just foolish and highlights the sort of headstrong obliviousness that has essentially springboarded DAO into the spotlight to begin with.
Smart contracts aren't good for stupid users. Someone outsmarted a big group, now they're having a fit because all of their money is going to leave, and rather than walk away from the poker table with their head hung low, they've decided to just rob the dealer and try for heisting the vault while they're at it.
And then they have the gall to say "Oh, you just dont understand the purpose of central banking" as they oppose a system that they put in place to benefit themselves, by themselves.
What (I think) OP is saying is that at the end power is what matters and the power is not evenly distributed like the blockchain. Looking at the long block size discussion you can see which stakeholders has power while others just watch.
I am long on cryptocurrencies but the community at large needs a reality check to see where they currently fit.
And you say you don't like Ayn Rand! Terse is just another word for unimaginative, when it comes to prose.
I think you might be blurring the lines between writing something in a socratic dialogue versus writing technical documentation. Dijkstra, obviously often is writing in the former style and so there's plenty of room for his personality in the text and it doesn't take away from the overall quality and cohesiveness of the text.
I don't think I'm blurring; if anything, I'm sharpening! Not all text is the same, and it's important to know what you're trying to accomplish when you set out to write something.
Reasonability. In an age where billion dollar companies are gutted by 16yo hackers on a monthly basis, it's worth the effort to build strong, secure systems that can be formally reasoned about.
Its disengenious to imply that functional cant be as insane as procedural. Also, everything is strong and securw until vulnerabilities are found (heartbleed as an example). Its in the hackers best interest to never let these vulnerabilities known. Also since there are many less eyes on less popular languages, vulnerabilities will take more time to be discovered.
The combination of stronger type systems (especially dependent typing), less error-prone design (no manual memory management, no mutation, no global state, no loops/off-by-one errors), separated side effects (crashing during computation won't break things, less places for outside interference/external failure, etc.), and better error handling (no null, usually no exceptions meaning you have to encode failure into the return value itself without losing type information) solves many common bugs in imperative code.
Type systems - already available in the most popular languages
no memory management - c++, go, java come to mind
No mutation - has a side effect which you probably will never mention. But it will become important as the internet of things gets smaller
No global state - in what environments would that ever be an encouraged paradigm? Javascript?
No loops/off by one - you still need loops, they are just recursive. The difference is you need to jump around to figure out what the hell is going on instead of reading it top to bottom
Better error handling - nothing you just said seems better to me
Sure, there are many thing I like about functional languages. I like how you can create a tree to reason about you code to the point it looks like a flowchart. It has forced me to question my own coding style and how I compartmentalize and where I can run things in parralel. How infinite lists, streams and arrays can all be considered the same interface. But I think there is room for growth.
- forces me to the bottom of a document to find out where it starts
- uses obscure language in order to avoid oop
- Cannot use symbols represent the start and end of a typed object constructor with a single string argument (regex, jsx, queries, etc)
I don't believe GP meant 'type systems' the way you mean them. He's talking about the more powerful concepts such as dependent typing, not just the existence of types.
There are very few popular languages which would fit this category IMO, depending on how one defines powerful type system and popular. Scala is the only candidate that I can think of for my own definitions of those two concepts.
>Type systems - already available in the most popular languages
This implies you haven't actually spent time with a strongly typed functional language like Haskell. Once you have, it's hard to continue thinking of Java or C++ as having "type systems".
If a guy writes an entire book and you don't want to read it because he made a spelling mistake, then don't.