16 ms·
Clojure/Conj 2017 – Opening Keynote by Rich Hickey [video]
- amrrs 9y agoI have been to a local Clojure conference once. Most of the guys who started practising Clojure was inspired by Rich Hickey's functional programming talks. I'm wondering how many such BDFL inspire users to adopt something new just with talks!
- iLemming 9y agoI didn't even know about Rich Hickey talks and "Simple made easy" when I decided to start learning Clojure. I came to conclusion that I needed to learn a Lisp after learning Emacs and dubbing in writing small elisp functions. I had no idea and was really surprised when I found out how awesome Lisp can be, so I looked at the current state of Lisp at the time. And then after learning a bit of Clojure and Clojurescript and seeing things people were building with it, I quit my job. I really wanted to use Clojure full-time. Never in my life I ever before have had this urge to learn a language and build things with it.
- kimi 9y agoAny transcripts yet?
- grabcocque 9y agoI always enjoy Rich's and Cognitect's increasingly futile attempts to bait and switch the Clojure community into using his expensive proprietary database, Datomic. I love Clojure, it's a beautiful language, but its march has stalled, perhaps even reversed, and I lay the blame of that squarely at the anti-community practices of Cognitect, especially surrounding Datomic.
- keymone 9y agois anybody forcing you to use datomic? no. is cognitect doing something to clojure that is beneficial exclusively for datomic? no. has cognitect banned you from making pull requests that improve clojure? no. has cognitect banned you from forking clojure and fixing whatever you think they've done with some evil intent? no. so wtf are you on about?
- whalesalad 9y agoAFAIK clojure doesn’t accept pull requests.
- keymone 9y ago"send a patch" sounds so 90s, but you're right.
- geofft 9y ago> has cognitect banned you from forking clojure and fixing whatever you think they've done with some evil intent? no. I don't understand this objection. The value in a free software project, and especially of a programming language, is primarily in its community and the expectation of a future around the project, not in the existence of some code somewhere. It's extraordinarily hard to build a community around a fork, and if you need to fork to do reasonable things, that's a legitimate criticism of the people running the original community. (That said, if you only need to fork to do unreasonable things, that's good community management. I don't pay nearly enough attention to Clojure to know what's actually happening - but I have seen both of these cases in other free software communities.)
- keymone 9y ago> It's extraordinarily hard to build a community around a fork it follows quite naturally, that reasoning to fork doesn't have enough community support, which only means one thing - you're wrong about clojure community's opinion on state of things around clojure.
- Sinidir 9y agoYou mean that they want to make some money?
- vog 9y agoDo you imply that in general, the (perfectly valid) desire to make money would have justified bad behaviour towards a community? In general, if you have a community around your comany, you can do it properly, or you can do it Oracle style. (pushing MySQL, OpenOffice, OpenSolaris, etc. into forks or death). So the question is only whether Cognitect is good or bad for the community, not whether they make money or not. Making money is not a good excuse of bad behaviour. And while we are at it, doing voluntary work isn't a good excuse for bad behaviour, either, but that's another topic. Having said that, I don't see where Cognitect is bad for the community. Rather, they seem to interact very well with the community.
- deleted 9y ago[deleted]
- sooheon 9y ago> Do you imply that in general, the (perfectly valid) desire to make money would have justified bad behaviour towards a community? But the OP made insinuations that the act of selling software was de facto negative to the community. It is only necessary to point out that making money is not automatically harmful to the community.
- pjmlp 9y agoPeople that give you programming languages for free need to pay their bills in some way.
- cutler 9y agoIt could be argued they'd make more money from consulting with a much wider adoption of free Datomic. The problem in the Clojure community is much wider - it's not interested in wider adoption, competing for mindshare and rallying round a web framework to attract new users. I think it's partly a Lisp thing.
- iLemming 9y ago> its march has stalled Clojure being a Lisp probably exceeded and overachieved its goals when it comes to popularity. Sadly, not a single Lisp probably will ever become a mainstream. And for the same reasons why Vim and Emacs would never become more popular than IntelliJ and Sublime. People tend to choose something easy to start with, out of the box thing, not something that has a small, simple core yet extremely extensible and rich ecosystem. Most of the innovation in Clojure-space happening outside of Cognitect, driven mostly by individuals. Look at Clojurescript. It hasn't stalled, au contraire - with every release it's getting better. Pick any large Clojurescript project - PrecursorApp or Circle CI, look under the hood. Compare Re-frame and Fulcro projects with other popular Javascript frameworks. Check out Re-Natal, Lumo and Planck. Right now Clojurescript probably the most pragmatic choice if you want to build web-apps using a functional language. GHCJS and Purescript (that appeared few years before Clojurescript) - still hasn't quite reached popularity. Elm - which is 5 years old (same as Clojurescript) - still feels a bit experimental. ScalaJS - I don't even want to talk about Scala. Fable/FunScript/WebSharper? Microsoft has failed to convince even its own herd to start using F#. Largely - C# still in use. And those guys prefer Typescript - not really functional. Only ReasonML someday soon may become true competitor to Clojurescript simply because: a) Facebook behind it; b) ain't a Lisp.
- kasbah 9y agoI submitted this link before I had watched the whole thing. As someone who has only dabbled in Clojure I think there are a lot of interesting ideas in there but found the type-system bashing pretty off-putting. I am now watching his "Simple Made Easy" talk [1] after I have heard it recommended on a few functional programming related podcasts. Again really interesting stuff but I encountered another cheap shot at typed functional programming ("You can't use monads for that! Hurr hurr hurr"). Given how well received these talks seem to be by people that enjoy programming with advanced type systems I would have have really expected a more balanced discussion and some acknowledgement of the trade-offs between dynamic and statically typed functional programming. [1]: https://www.infoq.com/presentations/Simple-Made-Easy https://www.infoq.com/presentations/Simple-Made-Easy
- hellofunk 9y agoThe new Conj talk is certainly an interesting look at one man's (or one community's) look at static typing. However, as much as I admire Rich, some of the points he made don't resonate with me, particularly the one about how compile-time checks to catch minor bugs in syntax are not a particularly useful feature of static typing. I certainly disagree. As someone who writes Clojure all day long right now for a living, I am constantly dealing with runtime errors that are due to minor typos in my code that I have to track down, and this time would be greatly saved by having a compiler tell me "on line 23 you looked for :foo keyword in a map but you meant to type :foobar, so that's why that was nil" and many other similar woes. I love Clojure but I really miss static type checks. The other item in his talk I do not agree with, he says (slightly paraphrasing) "in static typing, you can pattern match on something 500 times but if you add a case, you have to update those 500 matches to handle the new case, when really they don't care about this new case, only the new logic needs to consume this special case, it's better for the producer to speak directly to the consumer". Well, in languages like OCaml, Swift, Haskell, it is a feature that pattern matches much be exhaustive. This prevents bugs. In most cases, I'd expect that if I add a case to an enum, the chances are good my existing logic in pattern matches should know about that. Maybe not all, but a lot of them will. It's nice to have the compiler guide you to those places. I certainly like how fast I can write programs in Clojure, and I like the minimal amount of code that makes refactoring and rewriting fairly straightforward since there is not a lot of time investment in the existing number of lines, and I like the incredible elegance of Clojure's approach to functional programming. But I do miss having much greater compiler assitance with typos, mis-typed argument order to functions, mis-typed keyword names, etc. Would really save a lot of time.
- hellofunk 9y agoNo one in this thread is yet talking about the content of this talk, which I think is interesting. Rich is doubling down on dynamic typing. As the world is gradually moving to more statically-typed languages (Rust, Swift, Go, Elm, Purescript, Typescript are all popular tools that come to mind), Clojure remains in the embrace of dynamic typing, and this talk is an interesting look at the perspective of why that is, and adds perhaps a little bit to the debate between static and dynamic typing. I admire Rich a lot, but I also admire John Carmack, and it is apropos that yesterday another comment was shared on another post here [0] about his opinions on static typing, and how in just a few years (his talk was in 2013), the industry as a whole has made considerable changes in its opinions of static typing; according to his talk, in 2013 most of the industry was still not convinced of the benefits of static typing. [0] https://news.ycombinator.com/item?id=15460604 https://news.ycombinator.com/item?id=15460604
- amelius 9y agoOkay, but at least with static typing one can have dynamic typing simply by using an all-encompassing type. With only dynamic typing, one cannot have static typing.
- hellofunk 9y agoI invite you to watch this talk. Dynamic typing is about a lot more than having an "Any" type. It's about widespread lack of extra code and cognitive overhead associated with the imposed structure of adding static types to a project, as well as the verbosity that static typing typically adds (including in type-inferred languages). You can't just turn off the static typing in a static-typed language; you can turn off the static type for a specific type, yes, but that doesn't give you the experience that dynamic languages offer.
- amelius 9y agoYes. So how about a workflow where you write dynamically typed code, and then use a tool to convert that code (with user input) to statically typed code. You could do this incrementally. So once you have "frozen" your code into statically typed form, you could add dynamically typed code to it, and then "freeze" that. Or you could "thaw" the whole codebase, and add dynamically typed code, etc. > You can't just turn off the static typing in a static-typed language I suppose one could design a language where that is possible (although you wouldn't use the full power of static typing in that case).
- keymone 9y agoare people without a degree in type systems even allowed to express their opinion on dynamic vs static? because if their opinion is automatically viewed as inferior whenever a person with a degree chimes into a discussion, isn't dynamic typing stuck in the limbo of not having competent defenders and the only path for a defender to become competent is to spend years of their lives learning the opposite thing? i think (as a person without a degree in type systems) that relative success of Erlang and Clojure are a testament that pragmatic approach works, and that is not in any way evidence that static typing is inherently bad or can't work.
- dgllghr 9y agoErlang & Elixir have a very interesting approach to typing. The support for pattern matching in function definitions provides a kind of structural typing for functions. And they both embrace typespecs for type analysis through a separate program analyzer. So a lot of the benefits of static typing are there without the static types.
- keymone 9y agoclojure has destructuring, which isn't quite pattern matching but it does help to detect wrongly shaped inputs. also dialyzer is amazing and i wonder if clojure.spec can be used like that.
- DigitalJack 9y agoclojure has pattern matching too. As a library. Much of the interesting functionality of clojure comes from libraries. (core.async, core.spec, core.match, etc..) The matching library is good. I wouldn't use it in a tight performance loop, but as a productivity booster it's very nice.
- cutler 9y agoRelative success? In what sense? As far as the jobs market is concerned Erlang/Elixir and Clojure have failed to make an impression. Ok, Wallmart, Bleacher Report etc. but search Indeed.com by job title and you'll get what I mean.
- whalesalad 9y agoRich is always a great speaker. Sometimes he gets a little esoteric and you hear all the monad loving neck beards giggle in the audience. Then again, he invented a lisp that runs on the JVM. Usually though he is very pragmatic and real-world. I love how often he says things like “the type checker in my compiler doesn’t matter to the users of my program” or, “the perfect, most beautiful search algorithm doesn’t matter if it can’t fit into a web page and work when your user hits enter” So... even if you don’t care about Clojure or functional programming I’d certainly suggest listening to some of Rich’s talks. He’s a very sharp guy but his format is very friendly.
- crispyambulance 9y agoCan we please get this man a Wikipedia page now? https://news.ycombinator.com/item?id=5619680 https://news.ycombinator.com/item?id=5619680
- sooheon 9y agoWow that man Artem Karibov quoted in the link has some problems.
- fergyfresh 9y agoNot to be rude, but this guy could have had a rough time growing up DICK HICKEY!!!!
- platz 9y ago> "SPJ in an excellent series of talks lists these advantages of types... the biggest thing left out of clojure..." > "The biggest merit he says is in software maintenence, and i really disagree with just a lot of this. it's not been my experience; the biggest errors are not caught by these type systems; you need extensive testing to do real-world effectiveness checking." I think Rich is dead wrong on types not providing good tools for software _maintenance_. He is attempting to discredit types because they do not catch all errors, or the toughest errors; that's fine, I don't agree with people that would say types do that for you. I think dynamism is great for speed of development and flexibility; but my impression about trying to debug and maintain clojure code is that one has to spend time tracing back the source of errors and shape of maps (pre-spec). Those issues are somewhat mitigated by having a good type system, and what you loose on the flexibility going with types, is a trade that I think returns much more that what you give up.
- flavio81 9y ago>"The biggest merit he says is in software maintenence, and i really disagree with just a lot of this. it's not been my experience; the biggest errors are not caught by these type systems; you need extensive testing to do real-world effectiveness checking." I think I fully agree with Rick Hickey on this, and I have mentioned the same before here in HN. The biggest and most serious errors are not caught by the (statically checked) type systems. I agree that simple type errors that, on a dynamic system without compile-time checks are not caught, will be then caught at runtime and you will say "oh, i need to get back and correct this, damn it". But this is a minor annoyance, that takes small time compared to the bugs i'm mentioning in the previous paragraph; bugs that can take days to be resolved.
- lliamander 9y agoI would say the main point of types is to prevent uninteresting bugs. For me that's a selling point because I don't want to be distracted by those kinds of bugs.
- runT1ME 9y agoWhat kind of errrors do you think are not caught with static typing? Usually people who say this aren't familiar with languages that have type classes...
- agumonkey 9y agoOh noes, the ML fad got to Rich !
- yawaramin 9y agoI understand that Rich Hickey is a fantastic developer, a productivity multiplier, and an industry leader, but I have a few issues with his portrayal of types. In this talk he has repeatedly cherry-picked the most negative examples from every type system, while ignoring the more positive, simple, and elegant type system features. E.g., he talks about languages which represent product types as `int * int * string * string * ...`, i.e. as nameless clumps of data, while ignoring that those same languages usually support much richer record types which are of course product types with field labels. Then he talks about Java types being non-composable while ignoring generics and row polymorphism in other languages. He talks about Clojure maps being powerful while ignoring the same maps with the same power in static languages. He talks about type system complexity while ignoring the mental burden of keeping the types in your head in a totally dynamic system like Clojure. Ironically, he even talks about how you can handle five to seven arguments mentally before getting lost, while ignoring that in a dynamically-typed system you're left to your own devices handling much higher cognitive loads. Another beef I have here is he repeatedly talks about pattern-matching in 500 different places, and having to go and update them, while ignoring the fact that _no one does that,_ we actually do write modular code with data structures as abstract as possible and try to provide powerful, general-purpose functions which manipulate them instead of exposing all the variant cases for raw pattern-matching. PM is great, but it's still important to limit its use for scalability reasons. I don't know to what extent he has explored the type systems of ML-family languages. But he certainly does not present them accurately here. I would love to see him just do a debate-style talk with someone really well-versed in type theory as well as practical systems, say, Yaron Minsky of Jane Street.