8:16 "As we move forward we have to take what we already have and make that elephant do more, make it do things differently, make it do things better, and as we try to take on manipulating software we are going to be challenged to understand it in order to make that happen. And I'll contend that you will completely be dominated by complexity. I don't care what processes you are using, I don't care how well you test or anything else. Complexity will dominate what you do." SO true.
I am a huge fan of Rich Hickey. The summary I get from this talk is "We all care about agile methodologies agile teams but how many of us actually care about agile architecture?". This is one of the best talks ever....so simple...so lucid...or just simple made easy.
Great talk. Liked it a lot. A note on "22:16 Simplicity -- the art of maximizing the work not done -- is essential." I want to add some nuance here. Imho "Simplicity -- the art of maximizing the work not done -- is essential" is a way to say "Don't try to build a rocket when a bycicle is what the customer wants and needs". This definition of Simplicity is more like a definition of Simplicity in Agile, whereas the Simplicity Rich Hickey is talking about is Simplicity in Code.
Classes mostly complect state and behavior, without giving much in return. foo.bar(arg) invocation is just a syntactic sugar for bar(foo, arg), as it is done in Python, for example. Tacit knowledge recreation can be done via good namespaces and transparent naming conventions.
No. Please watch "Simple made Easy" - the first one from Strange Loop 2011 - it's on infoq. The so-called hostility is actually humor. If you have no sense of humor, I guess you'll see all of Rich's comments on the mainstream as "hostile".
25:54 I agree with Rich that tuples are a product type, but in the context of the example he gives, I think he does the rationale behind product types a disservice. Clojure is full of product types. The "syntax" for function definitions in Clojure is a product type: if you write ([x] (* 2 x) double-it defn) you're not going to have a good time! Product types are fundamentally unavoidable. I do agree that when order does not matter, product types are inappropriate. I think that's the main point.
What structural programming do you mean? If you take not even Pascal but Go you will find it painful to use for many tasks. Lack of polymorphism and strong typing. If you write in Python in "structural" style you actually have all the power of a dynamic language where everything is an object actually but you just don't write your own classes. And it's a huuuge difference.
And then you try to convince that "This is an empty class that only has properties, no functionality that needs to be maintained and commented" and you get "we keep it because it the IDE auto-completes the object properties". :(
There were lots of great things here, but some things like using hashes over objects make little sense to me. Classes act like a validation schema, whereas hashes can take whatever arbitrary fields you set on them. There's a reason why refactoring large code bases in languages like java or c# is so much easier than ruby, and this sort of approach only pushes ruby in the opposite direction.
Thanks for this comment Daniel, I loved the until he went against classes. With the validation and refactoring benefits also could be mentioned the gain in scalability and communication. I guess for the main system components classes might be the best choice.
Don't watch "Simple made easy" on InfoQ. This talk is a much improved version of that talk, because he cut down on hostility and promotion of functional programming. Which is meta great, because it's an application of his principle. "Simple made easy" on InfoQ complects the above discussion with hostility towards object-orientation, and with promotion of FP. Now his talk almost only promotes the "simplicity/complexity" discussion and thus is simple.
simple vs easy .. a good example might be the considering alternative math systems: {complex number and infinity} math system is simple .. vs "real" number math system is easy (but cumbersome) ie. (complex number, infinity) -> function eg sin, cos, tan sqrt -> (complex number, infinity) .. all of the domain is valid for all math operations and maps back into the domain. (real number) -> function eg sin, cos, tan sqrt -> (real number or error .. it depends) .. valid domain needs to be considered for each function .. the less rules about the domain, the simpler and more useful to use. .. but maybe not easy to set up. The problem with the math system is that "real" numbers are what we're used to (thus easy) and "complex" numbers are typically presented to the newcomer as strange and unnatural, and infinity presented as an outright insult to reality. (really, though .. they're all simply symbols for processing) For some reason *all* the programming languages (except one) do the math thing backwards where they provide the cumbersome (but easy to implement) "real" system and make us work hard to get the simple complex number + infinity system. (the exception being the J Programming Langauage .. eg. right from the very getgo .. sqrt _7j24 -> 3j4, log _1 -> 0j3.14159)
Great stuff overall, with one exception -- the advice at 29:03 to use hashes/maps instead of objects.. I've seen medium-to-large applications based on generic data structures - and they all have been terrible to understand and change! That's exactly the opposite of "simplicity", because these hash/maps become "complected" by the various contexts they are used in - you never know which "fields" are always present, which are sometimes/never present. It appears easy when you have trivial data models, but that's rare. Most applications manipulate objects with dozens of fields, some of which are dependent on other fields, and may be even object. So, I respect Rich Hickley, and his advise is mostly good, but he erred on this point very deeply. Object/data encapsulation is goodness. IntelliSense is goodness. Hash/maps are useful only within a very defined context - like, when performing algorithmic transformations or data interchange.
Don't replace documentation with an object system....the worst thing you could do! Hickey is right and you are wrong I'm afraid. Data can represent itself just fine!
I actually think the opposite of that. Having it being generic data structures is very easy to reuse functions, I think in the problem you described you can get it to make sense by doing some assertions on the functions input (to verify if the map has the data you need) so you can find the problem points, in the long run a good test suite should reduce those problems to minimum, I think that's someone about simplicity, is getting the proper time to design your inputs/outputs so you can reduce the complexity at most, and nothing is simpler than having all inputs and outputs as simple data.
Jack Pamm I had similar thoughts, at first. But this is my counter-point: Using a generic data structure makes it easier to write custom code to do validation as well as various other mundane operations. Yes, you will miss compile-time / IDE validation, but the added flexibility...might make up for it. Of course ideally you'd want something that gives you the ease of use as a generic data structure *and* compile-time validation.
I think that the comparison to RESTful APIs is apt. Yes, they usually use something like JSON which is as generic as they get. All the actual typing and defining of things takes place in API documentation and standardization. Using a class inside an application is also a way of defining an API. I think it's a much easier and straightforward way to define an API. But what you don't want is APIs that are poorly or not at all defined. If you're writing a simple blog app you can get away with using an array with 'id', 'title' and 'body'. I'm not sure what awesome universal way of transforming that generic data structure this enables, unless you want to like map($data, 'uppercase') or something. But when you get to the level of complexity of most mature apps you need your APIs defined and adhered to. Another advantage of using typed structures is the discoverability. If someone passes you an array/hash called $blogPost you don't really know what it contains unless you look up the source of that array/hash which can be troublesome. It could, for example, be based on a number of entities in a database collated etc. An object has getters which you can easily look up.
well, Clojure 1.9 is going to solve the this issue of "not knowing what's coming" with the clojure.spec, clojure.org/guides/spec, using specs is even better than just types, because specs can specificy much more (for instance, a number in a range, regexp expressions for sequences, key-map relationships and much more).
Looking at millions and billions and trillions of very popular shit libraries for the most used languages, i conclude that there are not enough of these programmers.
Isn't it a paradox to say consistency is simpler than inconsistency? I assume consistency is basically being aware of the state around you, i.e. why you need transactions which handle state operations at a specific point in time: "Is anyone else appending to this file right now? ...no? okay, I get to append to it now..." Also, I don't think this means that inconsistency is simple, or simpler, either. There is basically always going to be complexity with state management, and the one that is simpler I think depends on context.
The typical difference to me for a more imperative style is that the context is no longer obvious and anything that is done in the wrong order, or at the wrong time, results in malfunction. Consider an example like: obj.do_a(...); ... obj.do_b(...); ... obj.do_c(...); ... where the order of operations here must precisely be 'a' before 'b', and 'b' before 'c', to produce correct behavior and avoid some potentially very obscure bugs like data races. That is highly prone to misuse, especially with parallel execution in the mix. It's not just requiring a full-blown awareness of the entire context, but allowing human errors related to misunderstanding of the context to easily slip through the cracks. For a crude analogy, it's like having a computer where clicking the mouse button before you finish booting into the operating system causes the motherboard to catch on fire. Then contrast it to functional: a = do_a(...); ... b = do_b(a); ... c = do_c(b); That still requires awareness of context but it makes it impossible to make such deadly mistakes since we cannot call 'b' until we get the results of 'a' in this case, which 'b' requires passing in. That is like a system where the mouse doesn't even get power and become enabled and light up until the operating system finishes booting if it's prone to cause a problem to try to use it before that. This also allows efficient and safe multithreading, since many threads could be simultaneously and safely calling 'do_a', and all get back results that they can pass to 'do_b', and pass those results to 'do_c'. We're free to parallelize to our hearts' content without locking since these are pure functions that have no side effects.
I was very excited when I watched this, but afterwards I'm having a few worries. Without any structure, how we can have any integrity in our apps? If all the data structures are like hashes/dicts/maps, then sure, it is easy to change things, but how can you ever feel safe your code is working? There's going to be a lot of errors at runtime?
@@nxtktube Using hashes, it is very easy to screw up structure inside the system boundaries and affect other parts of it that expect structure to be valid.
Usually, you need structure at the boundaries of your API/programs. You want to define a contract at these points and you can using validation, specifications to enforce them. But inside your program, you should try to code with values (ints, floats, strings, dates, keywords, associative structure and sequential ones).
@@advance512 because it also has an essential cost and you should be free to decide if the benefits are worth it. A contract basically bind you and probably restrict you in the genericity as well. We are all adults in the end, so we are free to decide if a tool (type logic, or predicative logic) is suited or not.
@@Neo2551 Sure, you're free to decide it for yourself. Typing, or to a lesser extent type hinting, has an essential cost but the benefits are huge. It is a good example of a contract inside the program's boundaries that is incredible helpful. Total freedom is not always more productive than a clear opinionated framework to work within.
I think that the OO approach confers some simplicity in large systems in that you know where everything is. Until he came up with the RESTful analogy, I wasn't buying his argument. We do OO for a reason, it reduces the cognitive load of having to think of where things are. When you have a program with 150+ code files, this becomes an issue. It seems like one could get the best of both worlds by replacing objects with some kind of construct that lumps functions together, where each of the functions contained takes a map as argument. Pretty cool ideas. Of course, if you start coding this way you will make things a lot less simple for whoever will work with you, since you will increase their cognitive load (at least during the time period where he gets used to the simpler style).
but he talks about simplicity, not about coding faster. For example, read the gang of four, they and many people say that you must replace most parts of inheritance with composition
A function stands alone having inputs and outputs. Methods come with associated state which can complicate understanding the method. Functions have inputs and outputs, methods have inputs, outputs and associated state. That I think is the sense in which they are more complex.
If you need state you're still going to need state. It's just that your state will be kept outside of that particular function and will not be directly accessible from it. That may or may not make the function simpler, but the overall complexity is unlikely to have been reduced.
I have to disagree. If your state and your function are inextricably linked (which is definitely the case with functions that are methods) then that makes things more complicated, as opposed to using functions that are "agnostic" with regard to state and can be transplanted anywhere else. I think Rich Hickey makes a more apt variant of this point in this talk.
21:27 Don't necessarily agree with him on ORM's. I have no doubts that *maintaining* the complexity of an ORM package is extremely complex, but for actual application development ORM's are far easier to use quickly than writing SQL.
+Spuds7er Really, "far easier"? He says that this "complexity" is "easy" to get and programmers get way too easily excited only about the benefits of something and ignore what else they get with that. That is sooooo true, it's not even funny. Don't forget how much time we all spend with ORMs over our lifetime. We probably should have written SQL all along. A simple wrapper to simplify the SQL execution should be sufficient. We would always exactly see which statements are executed, we could tweak and modify it precisely, debug it and beyond that we have to know SQL anyways for debugging. Also, for more advanced cases we have to write SQL anyways. So it's also a leaky abstraction. So many questionable things about ORMs.
AktionJackson I actually know a Rails project that completely eschewed ActiveRecord for manual SQL. It's a nightmare and the project is having a hard time finding people who want to work on it. ActiveRecord ORM gives you a lot of powerful functionality for way less mental overheard than would be needed if writing SQL manually. In many cases it's all you need unless you're trying to do something very complex or high traffic. Things like chaining scopes are great abstractions that make it easy for core behaviour to be abstracted. E.g. User.where(active: false).all is a great abstraction over normal SQL.
+Spuds7er That tells more about the project than the discussed issue though, I don't see an inherent relation. Your given example is especially great because every single tiny thing gets a class, but the ugly side of an ORM especially shows quickly when things get complicated (i.e. something trivial like pivot tables). Writing a generic comparison wrapper for you example is just a few lines of code which you can perfectly tweak, modify and debug and is blazing fast.
You would be quickly overrun by complexity with this approach. Thats why ORMs actually came to be. To solve those stupid direct SQL queries. It is not like we use ORMs where what you want is a simple single SQL query anyway. Actually, ORMs simplify things for us. They allow us to directly map the data without caring about SQL, caches, wrong selections, typos and other stuff. Map it and use it as you would use any other object in program. I don't see any problems with this approach.
kenektik, and what usually happens with all these rails projects that use ActiveRecord after several years? but yes, it doesn't mean we should put SQL statements everywhere instead of using AR
Lisp adoption? Not writing classes because Hickey says not to? Concurrency? Sounds like you're complecting this simple video with some personal baggage.
The main problem with this and the idea of Clojure is there is no business requirement and there is no benefit out weighing adoption cost. I think Rich needs to seriously look at the model is he wants a broad adoption. 1. No one will code in Lisp. Odersky knows this much. 2. The ideas of 'hard concurrent problems' are unfounded. we have been doing these from day one. Yes pure immutability leads to easier programs. but do you really say 'I cant model an object because Rich says data rules'
His concrete examples begins around 23:57 with his comment about how order or "chaining" methods is much more complex than unordered data structures like hashes, or using queues. That's a concrete example.
I find it very amusing the my comment was flagged based on its objectivity to the subject, I wish Clojure the best of luck, It does very much need it. My comments are still fact, Clojure is going no where because its based on an ideal that has never seen the light of day in 50 years, Bit like Haskell. Ideas with no pragmatism or realism I will code Java for the next 20 years and I expect you and many others will
Rich Hickey totally does not understand what simplicity is. He would do well to watch some Alan Kay talks on simplicity because the IT industry is still using 50 year old technology- the unix family of operating systems for everything other than windows and the C programming language is the defacto low level standard. So Rich thinks he is attacking complexity because he revived/modernized a 60 year old programming language. Im not going to say that Rich is not innovating because Datomic does bring novel ideas to the table. But overall innovation and research in the IT is stagnant and he is not really looking at the big picture but rather treating the 'worse is better' problem with small bandaids.
