In France they did ask.
In 1992 there was a referendum about Maastricht, where the 'yes' had a tiny lead over the 'no'. In 2005 the French people voted a resounding 'no' to the European consitution , so did the Dutch if I remember well.
EU then modified minor things and renamed it the Lisbon treaty, which has been ratified by parliamentary procedure.
So even when people opinion is being asked, it's completely circumvented.
It is very clear that EU has never been about building a democracy, those that believe that are very naive.
If you only care about marketability on the backend side, then scala is certainly a fair choice. The difficulty with scala is the complexity of the language itself.
If you want to improve your own thought process rather than your skill in just one programming language, then clojure(script) would be a better choice. Once you've been through the learning and practice curve, the benefits of having decomplected your mind will spill to other languages.
Maybe Microsoft has left Github doing its own thing, but they're still using their operating systems to massively spy on users.
I cannot help but think Github is not longer neutral: its business used to be about code repository and only that, but now it's also about all the things Microsoft does and wants to protect. Actual and potential competitors legitimately can wonder how private their code is.
The point of this feature seems to be that Facebook knows the signatories are real people, which makes the petition more valid. Allowing votes from outside the FB user graph would defeat that.
The problem is that FB is a business, not a public service providing proof of identity. It is wrong to force people to get into a commercial agreement with a private company to carry out civic duties. Same issue as authorities publishing only word documents that can only be read with MS Word.
Yes, he's rather explicit in saying Maybe is a poor tool.
I'll have to watch the talk a second time to be sure, but I'm not sure he proposes any solution at the level of type systems. Not using Maybe or using Union is not what he is advocating.
For him (and me too) types are the wrong thing to put data in because, among other things, it forces you back into PLOP. His point is to remove entirely the need to fill slots with nothing.
Obviously the talk is more about specs than types. While tactfully avoiding the debate around types, he's still starting the talk with types to help those that are only there to decomplect their thinking.
Yes I was going to mention that video in which Rich makes an important point in my opinion: database tables, or objects, or structs, still live within the Place Oriented Programming (PLOP) mindset. That mindset was born in a time where disk and RAM were the expensive resource therefore update-in-place was the default. I insist on the "in-place": you need to know where something is so you can update it. The downside of PLOP is that if you have no value for one of the slot in your generic form (be it a table, object or struct) then what can you put there?
The alternative is to use data shapes that do not require something to be in a certain place. Hence the use of maps as the most basic data shape: you either have an entry in it, or you don't, no need to have a null entry. Expanding that thinking to databases, and you realise tables is not the right aggregate, instead you need to go one level down to something that datomic calls datom, or RDF calls a fact.
To summarise, PLOP forms that package together a set of slots to be filled magnify the issue of NULL/null/nil. Instead make the slot your primary unit of composition and make sure you use aggregation of slots that does not force you to have slots filled with a null value when there is no value in the first place.
Funny this is being posted as I just started to use specter for extracting entities from XML documents we receive. I never used it before but now I see the value of:
- paths as data
- navigators as transducers
First I started using plain clojure code, then played with using xml-in [1], then created my own transducers and channels to build a dataflow-like pipeline manually, and finally started using specter because I wanted paths to be a data structure I can use to build the pipeline programmatically instead of manually. For that I needed a way for paths to become tranducers (which specter traverse-all does [2]), and I also needed paths to be a sequence of literals or "interned" elements [3] such as keywords or symbols, but not functions created on the fly. That way I can create a tree from a sequence of paths, using something similar to this SO answer [4], and build the pipeline.
I'm almost there, I should end up in a situation where I can specify a list of paths to extract from an XML document, and the dataflow pipeline needed will be built automatically, with an input channel for the parsed XML, and output channels for each given path. If you use clojure.data.xml instead of clojure.xml, my hope is to have a one pass XML parsing of larger-than-RAM XML docs.
> The thing about Lisp's power is it allows the production of complex program quickly but doesn't particularly have a standard way of gluing these programs together.
I'd argue Clojure is setting some new standard here with its powerful literal notation for basic data structures (list, vector, set, and maps) and its practice of integrating/composing first on data. Most of the time that's enough to get some libraries work together. If not enough, integrating/composing on functions is the next stage. Only after having covered data and functions should you consider macros, which should be easier to write if you have done a good job at the data and function levels.
If such powerful and ubiquitous data structures work so well for programs written in clojure(script), why would that not be true in the larger picture for integrating systems? JSON worked much better than XML because it actually represents simple data structures, not objects talking to each other. Redis, Avro, and similar tech are continuing that story while Kafka adds a fantastic transport and storage mechanism. Sounds like we're closer to having better foundations for integration in the small and in the large.
I have used Clojure on several customer projects and my own Cookingspace.com hobby project. I like Clojure except for the way recursion is handled. I have been using various Lisps since 1982 and Clojure’s support for recursion bugs me.
Yeah, because the JVM can't do TCO you can't have nice recursion. The options in the language provides are good enough but definitely not the most ergonomic.
I can't remember the last time I wrote a recursive call in Clojure, other than for multi-arity. In general, if I were in a code review and saw the "recur" keyword, I think I would regard it as a code smell and see if I can re-implement it using higher order functions.
I have to agree, the key question here is where would the power go if nation states give it away.
I can relate to the candidness in the article, but there is an equal amount of naivety.
It's not because nation states exist that nations tend to fight for power, it's because we individually and collectively think about power in a certain way. As long as our main struggle is for power, whether by money or force, and as long as we see democracy as a process of giving our powers away to concentrate it, then nation states will reflect that reality of human thinking. In that respect nations are still useful to localise the blast impact of our collective stupidity.
Globalisation today has nothing to do with economic wisdom and everything to do with power concentration.
To me the most important contribution of Clojure is to not focus on OO or FP at all, but instead on data.
Data is a first class citizen of the language: data literal is part of its syntax, and it uses powerful persistent data structures behind that.
Programming with Clojure is what has made me realise that data is really what matters after all. None of that FP or OO discourse should deviate us from that reality check that computing is all about data-in/data-out. Pull the plug and/or battery of your computer and see what remains next time you power it up.
So yes, Clojure may not be revolutionary in itself, it does rely on the shoulders of giants. It is however setting a new standard in terms of being successful in bringing together a very well thought out set of features and philosophy to bring the focus of programming back towards the real complexity, instead of the accidental one created by how we think.
I wrote Clojure full-time for a few years. I was lucky to do so and get paid to learn such an interesting language and paradigm of software development.
Aside from the points you mention, of which I agree, there is one other point I took away from the experience that many would disagree with: I really, really missed static typing.
So that's the main reason I don't use Clojure as much any more and went back to other languages with a different model of typing. But I learned so much and it changed the way I work in other languages.
