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

261–270 of 307 posts

Re: Clojure at Netflix (2013) [slides]

#261

Post by draw_down »

projectileboy wrote: post #53

This is a bit tangential to the post, but I've seen a couple comments in this thread that amount to "Clojure is hard to read", but I think that's a really unfair comparison, because people are unwittingly comparing apples and oranges. It seems to me the reason people think Clojure is hard to read is that the language is so powerful and expressive, that when you're reading Clojure code, you're typically trying to unde…

I think it's a valid reaction to Clojure (and other Lisps). In a lot of ways it isn't necessarily important how exactly it came to be that a given person finds a language hard to read. You could make the same argument for a language of dots and dashes, or something like BF; since it's not common to use such languages, many will find them hard to read. But that isn't really an argument in favor of their readability.

Re: Clojure at Netflix (2013) [slides]

#262

Post by xapata »

blandflakes wrote: post #258
xapata wrote: post #257

Earlier quoted context omitted.

Of course that's possible, but the evidence suggests that most people become more productive when using the REPL to experiment while developing large projects. One issue with trying to adopt the habit midway through a project is having a design that makes it easy to load small portions of the project with test data into the REPL. It's not quite the same as having code that's easy to test. Do you use an interactive de…

I appreciate your earnest approach, but I also feel somewhat patronized. I've been doing this for a while. I used Clojure extensively for years, was productive and found much to like. The REPL wasn't part of it, and I don't miss it. I still use Clojure on occasion. This response is pretty common: "You probably weren't doing it right. Trust me, this is the way!" While I agree that suspending beliefs/old practices and…

No condescension meant. It's hard to estimate how experienced someone is from a few sentences in the forum. I'm generally careful to make assertions about most and in general rather than all or universally.

Re: Clojure at Netflix (2013) [slides]

#263

Post by blandflakes »

xapata wrote: post #262
blandflakes wrote: post #258

Earlier quoted context omitted.

I appreciate your earnest approach, but I also feel somewhat patronized. I've been doing this for a while. I used Clojure extensively for years, was productive and found much to like. The REPL wasn't part of it, and I don't miss it. I still use Clojure on occasion. This response is pretty common: "You probably weren't doing it right. Trust me, this is the way!" While I agree that suspending beliefs/old practices and…

No condescension meant. It's hard to estimate how experienced someone is from a few sentences in the forum. I'm generally careful to make assertions about most and in general rather than all or universally .

None taken personally - I just find it valuable when I read comments against the grain, and had an experience that I know many Clojurists find atypical and wanted to share that my style of work just doesn't lend itself to Clojure as supported today.

Re: Clojure at Netflix (2013) [slides]

#264

Post by cutler »

yogthos wrote: post #253
m12k wrote: post #55

I'd like to learn a modern production-ready functional language (I have some academic experience with SML), since they seem like a good way to grow as a programmer. Main contenders so far are Haskell, Scala and Clojure (Reason might go on the list soon too) - but the fact that Clojure is dynamically typed is a bit of a turn off for me. My experience with dynamic vs static typing is that as a system grows in size and…

Worked with static typing for about a decade primarily with Java in the enterprise. However, I've also used Haskell and Scala which have advanced type systems. I moved to work with Clojure about 8 years ago, and I don't miss types. If I did, I would've gone back to a typed language a long time ago. My experience is that dynamic typing is problematic in imperative/OO languages. One problem is that the data is mutable,…

This nails it for me. Clojure has unique advantages over other, less composable languages and the design of clojure.spec is where you see it most clearly. Rich Hickey's presentation on clojure.spec demonstrates how you can define contracts for your functions which go well beyond what type systems have to offer.

Re: Clojure at Netflix (2013) [slides]

#265

Post by cutler »

yogthos wrote: post #247
cutler wrote: post #169

Earlier quoted context omitted.

These stats look highly suspect with Clojure:Scala = 1.6. Here in London the jobs boards Angel.co and Indeed.com have Scala:Clojure at 3.6 and 19.6 respectively.

It's one of the most comprehensive surveys to date. Meanwhile, the job numbers can relate to many factors. For example, there could be more turn around for Scala jobs.

The survey opens with:

"Welcome to the largest survey ever of Java developers ... The survey was conducted by publishing its availability to the Java community at large (via social media primarily), to Java User Groups around the world, including the Virtual JUG, and to subscribers of Java Magazine, the Java bimonthly publication from Oracle Corp."

So the sample is heavily biased and doesn't include the population of JVM users who have never touched Java.

Re: Clojure at Netflix (2013) [slides]

#266

Post by kamaal »

flavio81 wrote: post #172
kbp wrote: post #126

Earlier quoted context omitted.

> but as a LISP most people aren't going to be excited about using it. I agree that Clojure has a lot of strong points and that s-expressions probably put a lot of people off, but as a Lisp programmer, I was very disappointed in Clojure's debugging/interactive development story (and I've heard that from a lot of others). It feels more like using a typical scripting language compared to the traditional Lisp/Smalltalk…

> I was very disappointed in Clojure's debugging/interactive development story (and I've heard that from a lot of others). It feels more like using a typical scripting language compared to the traditional Lisp/Smalltalk experience Common Lisp user here. I was also disappointed in the same way when trying Clojure. Other minor things i didn't like was the noisy [] on the syntax, and the fact that for practical purposes…

>>for practical purposes you're fully tied to the JVM and the java runtime libs.

That's more like a positive thing about Clojure. Java inter-op and targeting the JVM gives Clojure a great chance of adoption at large enterprises.

These days no one really has a issue installing jars on a production machine.

Re: Clojure at Netflix (2013) [slides]

#267

Post by yogthos »

cutler wrote: post #260
yogthos wrote: post #251

Earlier quoted context omitted.

You can use ClojureScript on top of Node. My team started using Node for some services, and I published Macchiato based on that https://macchiato-framework.github.io/

I like the idea behind Macchiato but unlike it's Clojure cousin, Luminus, there doesn't seem to be any documentation on database access. I especially like HugSQL in Luminus. Is it possible to use it with Macchiato?

There is macchiato-sql [1] which is modeled on HugSQL. I've used it for a couple of projects, but YMMV. I tend to use sequelizejs since it works with most databases and it's well documented.

[1] https://github.com/macchiato-framework/macchiato-sql

Re: Clojure at Netflix (2013) [slides]

#268

Post by jwhitlark »

matt-noonan wrote: post #259
jwhitlark wrote: post #245

Earlier quoted context omitted.

Well, there are certainly classes of problems that I'd use static typing for, but in my experience, static typing != software that gets the job done. That doesn't mean that it holds things back, though. Many static typing arguments remind me of the Air Force's old "We'll bomb them so hard we won't have to send in ground troops." I just haven't seen it in practice, and the few studies that have looked at it empiricall…

> I just haven't seen it in practice, and the few studies that have looked at it empirically haven't seen a clear advantage either. If you know of such a study, please point it out! This is basically right; there are not a ton of studies, and the ones that exist mostly have pretty bad methodologies. Dan Luu summarized a bunch of them, circa about 2014. [1] Since then, there has been one study in this area that I thin…

My gut feeling is the problem matters more than the language. I'm hopeful with the push to microservices we'll be able to mix and match these things where we think they'll work best.

Re: Clojure at Netflix (2013) [slides]

#269

Post by yogthos »

cutler wrote: post #265
yogthos wrote: post #247

Earlier quoted context omitted.

It's one of the most comprehensive surveys to date. Meanwhile, the job numbers can relate to many factors. For example, there could be more turn around for Scala jobs.

The survey opens with: "Welcome to the largest survey ever of Java developers ... The survey was conducted by publishing its availability to the Java community at large (via social media primarily), to Java User Groups around the world, including the Virtual JUG, and to subscribers of Java Magazine, the Java bimonthly publication from Oracle Corp." So the sample is heavily biased and doesn't include the population of…

That's very likely the case, but presumably you'd get an even sampling from the users of other languages. It would be interesting to see some more surveys focusing on the larger JVM ecosystem though.

Re: Clojure at Netflix (2013) [slides]

#270

Post by cutler »

yogthos wrote: post #267
cutler wrote: post #260

Earlier quoted context omitted.

I like the idea behind Macchiato but unlike it's Clojure cousin, Luminus, there doesn't seem to be any documentation on database access. I especially like HugSQL in Luminus. Is it possible to use it with Macchiato?

There is macchiato-sql [1] which is modeled on HugSQL. I've used it for a couple of projects, but YMMV. I tend to use sequelizejs since it works with most databases and it's well documented. [1] https://github.com/macchiato-framework/macchiato-sql

Bejesus, Sequelize.js is a LOT more work than HugSQL. I keep looking at Macchiato but without a Clojurescript database layer I can't see it being useful.
Post reply on HN