Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure at Netflix (2013) [slides]

speakerdeck.com

Post reply on HN
Print view View original

291–300 of 307 posts

Re: Clojure at Netflix (2013) [slides]

#291

Post by vram22 »

Barrin92 wrote: post #187
vram22 wrote: post #183

Earlier quoted context omitted.

>Clojure code bases tend to be much smaller than Java. What are the reasons for this? FP language vs. OOP? Less boilerplate (again maybe due to FP)? Higher-level abstractions in the language or libraries? I have seen that F# code (another FP language, although I've read F# is more from the ML family via OCaml, vs. Clojure being from the Lisp family) can be significantly shorter than equivalent C# code, for example, a…

one thing for sure is the higher level abstractions you tend to use in functional languages, but a big thing about clojure is that it's very flat and generic in terms of datastructures. You basically have maps, lists, vectors, functions and not much in terms of hierarchy. A lot of code in Object Oriented languages simply exists to manage the hierarchies and structures you build and that's something that clojure large…

Thanks.

>You basically have maps, lists, vectors, functions and not much in terms of hierarchy. A lot of code in Object Oriented languages simply exists to manage the hierarchies and structures you build and that's something that clojure largely avoids.

It's similar for Python's built-in data structures: tuples, lists, dicts, sets, frozensets, with their built-in features and methods, including slicing for lists and strings (even without using, say, the collections module of the stdlib). (And of course including building up nested structures from the same.) Had read early on in my use of Python and later experienced for myself, a good amount, when doing work with it, that those structures are fairly powerful and for many apps, you do not even need OOP structures and hierarchies.

List, dict and set comprehensions are great for that, too.

Although Clojure may have some additional ones that Python does not, not sure, since I haven't used it.

Re: Clojure at Netflix (2013) [slides]

#292

Post by vram22 »

wild_preference wrote: post #203
vram22 wrote: post #183

Earlier quoted context omitted.

>Clojure code bases tend to be much smaller than Java. What are the reasons for this? FP language vs. OOP? Less boilerplate (again maybe due to FP)? Higher-level abstractions in the language or libraries? I have seen that F# code (another FP language, although I've read F# is more from the ML family via OCaml, vs. Clojure being from the Lisp family) can be significantly shorter than equivalent C# code, for example, a…

I worked at a shop that used Clojure and Java. One big difference is that Java APIs tend to require the collaboration of various class instances to get something done, things that you would implement as a single function + options object on your own. Bouncy Castle is a good example. You may need a Hasher, HasherStrategy, ASNEncoder, DERParameters, and ASNSerializerStrategy instances to execute what you would've imple…

Interesting, thanks.

I agree with your last point.

Re: Clojure at Netflix (2013) [slides]

#293

Post by tome »

CMCDragonkai wrote: post #273
matt-noonan wrote: post #229

Earlier quoted context omitted.

That blog post was a nice read, thanks! I realize this is just one example, but you might be interested to know that I've done some work making this kind of invariant enforceable via static types (though in practice, you need a combination of features that aren't found in many mainstream language besides Haskell afaik). See the README here for motivation and some examples (in Haskell, but hopefully the idea is still…

I found your explanation of the relationship between an existentially quantified type and rank 2 polymorphism to be quite illuminating. Do you have any ideas why Haskell didnt have the direct way to express existential quantification in the type signature? Is it a technical limitation or something else?

I don't have a good answer but I did write something about this once http://h2.jaguarpaw.co.uk/posts/exists/

Re: Clojure at Netflix (2013) [slides]

#294

Post by fiddlerwoaroof »

unlogic wrote: post #289
fiddlerwoaroof wrote: post #180

Earlier quoted context omitted.

(Although, if you anticipate this, you can call the ref (e.g. `(#’foo arg)`) rather than the function `(foo arg)`. But this means that you have to plan the dynamically modifiable parts out ahead of time.

That's not true. You only have to prepend #' if you pass the function by value (as in your web server handler example). If you call the function by name yourself, like (foo arg), and you recompile foo, any code that called foo will see the new version.

Hmm, I’ll try it again, but I remember issues with the function call syntax too. Iirc, it had to do with the fact that redefinitions don’t count if the use site is running in another thread. But I’ll double-check this when I get a chance.

Re: Clojure at Netflix (2013) [slides]

#295

Post by cmoscoso »

tome wrote: post #78
kamaal wrote: post #74

Earlier quoted context omitted.

One wonders what kind of challenging tasks a programmer who can't even indent code, can solve. By the way indenting code happens to be the most basic of code review checks.

Why waste human time on what can be done by a machine?

In my experience, a compiler would be wasting my time interrupting me with errors that are easily catch later, playing with the clojure REPL.

Re: Clojure at Netflix (2013) [slides]

#296

Post by truculent »

yogthos wrote: post #252
truculent wrote: post #250

I always see loads of Static vs Dynamic and Functional vs OO opinions breaking out in the comments. While the discussion is often interesting and insightful, it would be nice to see some empirical analysis of the trade-offs here. Stuff like development time, error rates, maintainability (no idea how you'd measure this one...). Anyone know if such studies exist? Feels like they should be out there given the amount of…

There is some research available on the topic. There's a good summary of it here https://danluu.com/empirical-pl/

Lovely, thank you!

Re: Clojure at Netflix (2013) [slides]

#297

Post by jose_zap »

preordained wrote: post #128
bunderbunder wrote: post #120

Earlier quoted context omitted.

You can't necessarily do it in Haskell, either, on account of the whole partial functions thing.

Or lack of great IDE...the best type system seems a waste without a right-click refactor option to show for it. I'm not going to chase compilation errors file by file...

It has a language server which works with many good editors like vscode, that’s something at least!

Re: Clojure at Netflix (2013) [slides]

#298

Post by tanin »

yogthos wrote: post #256
tanin wrote: post #168

Earlier quoted context omitted.

> It does depend on how you write your code but favoring pure functions, pushing immutability to the edges of your programs allows you to refactor without fear. Dynamic typing is punitive if we make mistake (e.g. using the wrong architecture, now we have to refactor), and we'll make mistakes. Writing perfect code with perfect architecture and perfect test has been the argument "for" dynamic typing, but I don't think…

My experience is that static typing tends to lead to higher coupling and monolithic design, while you tend to break things up more aggressively in a dynamic language like Clojure.

I understand what you mean, and it's definitely a trade off.

Static typing requires all types to make sense together no matter how small the addition is.

In dynamic typing, we can just add a class/object/field here and there because it'll only be used narrowly anyway. So, it's often fine.

This would be great if we can think of a small example to illustrate this trade off.

Re: Clojure at Netflix (2013) [slides]

#299

Post by yogthos »

tanin wrote: post #298
yogthos wrote: post #256

Earlier quoted context omitted.

My experience is that static typing tends to lead to higher coupling and monolithic design, while you tend to break things up more aggressively in a dynamic language like Clojure.

I understand what you mean, and it's definitely a trade off. Static typing requires all types to make sense together no matter how small the addition is. In dynamic typing, we can just add a class/object/field here and there because it'll only be used narrowly anyway. So, it's often fine. This would be great if we can think of a small example to illustrate this trade off.

One example I can think of is how Ring middleware works. The request map is passed through a series of functions, and each one can modify it in its own way. For example, you could have an authentication library that adds an :identity key, and another that adds a :session key. These libraries can work together without having to know anything about each other.

Re: Clojure at Netflix (2013) [slides]

#300

Post by matt-noonan »

CMCDragonkai wrote: post #273
matt-noonan wrote: post #229

Earlier quoted context omitted.

That blog post was a nice read, thanks! I realize this is just one example, but you might be interested to know that I've done some work making this kind of invariant enforceable via static types (though in practice, you need a combination of features that aren't found in many mainstream language besides Haskell afaik). See the README here for motivation and some examples (in Haskell, but hopefully the idea is still…

I found your explanation of the relationship between an existentially quantified type and rank 2 polymorphism to be quite illuminating. Do you have any ideas why Haskell didnt have the direct way to express existential quantification in the type signature? Is it a technical limitation or something else?

I'm not sure about the history. It looks like UHC supported existential types at some point, but I'm not sure how that would interact with what I am presuming is a more sophisticated system in GHC Haskell.

This post had some interesting tidbits about technical challenges, but I didn't fully grasp everything on first read: http://blog.ezyang.com/2016/04/hindley-milner-with-top-level...

I really like tome's observation in the other comment: universally-quantified types have a direct encoding in System F as type abstractions, but there is no such direct encoding for existentially-quantified types.

Post reply on HN