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

(next Rich)

clojure.org

Post reply on HN
Print view View original

131–140 of 158 posts

Re: (next Rich)

#131

Post by Raticus79 »

magicinky wrote: post #100
brundolf wrote: post #30

Earlier quoted context omitted.

Hah, very fitting way to put it :)

Agree. For those not familiar with Rich's famous use of etymology, see his 2011 presentation "Simple made Easy" as a good example: https://www.infoq.com/presentations/Simple-Made-Easy/ Side question: Rich seems to use etymology as a tool for original thinking and clear explanations. Are there other people who do this as well as he does?

I use etymonline for this kind of thing often. Our complex words are compositions of lots of forgotten meaning... I find it helps to retrace those steps.

e.g. https://www.etymonline.com/word/system - see how it's about composition, not so much about ways of doing things.

Re: (next Rich)

#132

Post by red_hare »

I got to work in clojure for two years and it was one of the most useful experiences of my career. I still "think in clojure" even now writing Python, Java, and Go. I can't wait to use it professionally again someday.

Re: (next Rich)

#133

Post by zbobet2012 »

draw_down wrote: post #2

I wonder if he’ll still give talks. I don’t blame him if not, but he’s really good at it. “Simple made easy” was a classic even if everyone proceeded to ignore the practical advice contained therein. And “Maybe not” is my personal favorite, a great discussion of requirements/provisions and the downsides of option types.

Maybe Not is an excellent video in some ways, but I just watched it a few years later and it reminded me that as much as I love almost every Rich video, I do wish he'd spend some time reading a little deeper on type systems and theory.

For example his note about "Categorical descriptions" and then the explanation about maps/and spec at 25:00[1] seems to indicate he's unfamiliar with the difference between extensional and intensional type theory.

The core difference between the two is extensional type systems decide equality on the observable behavior of the output. For example if two functions take the same input, and produce the same output extensional type systems/theories say they are the same. The problem with this is type equality is then undecidable.

Extensional type systems also struggle because there are more than one way things might be equal! For example two string might be equal if you ignore case, but unequal if you don't. So if we want our type system to check if two functions are equal under case insensitivity an extensional type system will struggle with this.[2][3]

Now in fairness to Rich, these concepts come more from the math community, especially the notion of types being equal under different paths, and in the case of Homotopy type theory are burred in unapproachable language and concepts... even by mathematicians standards.

He also talks about select from spec, and it not preventing you from passing types broader types, and the necessity of specifying deeper type.[4] But, that's just an eliminator defined on the type[5].

Now most strongly typed programming languages suffer from the issue he identifies when talking about not making brittle systems [6] and the issues you get with coupling around taking a map/struct/product type C = A X B (e.g a map C = {A: something, B: something}), and you require A so you're function should be good but you fail to compile because the function says A, and now you're passing C.

It's frankly pretty annoying in places like Java that if you have a Point = Int x Int y you can't use it in functions which take a Tuple = Int x Int y. I'd actually say that's the common observation that both Rich, the Go Inventors, and the TypeScript folks have all made. You need to care about the extensional type of your input (and output) fairly often. And carring around the intensional type causes both dependency issues and just some general PITA's.

[1] https://www.youtube.com/watch?v=YR5WdGrpoug&t=1504s [2] https://math.stackexchange.com/questions/4486995/what-is-an-... [3] https://en.wikipedia.org/wiki/Intuitionistic_type_theory#Ext... [4] https://youtu.be/YR5WdGrpoug?t=2668 [5] https://www.quora.com/In-type-theory-what-is-an-eliminator-a... [6] https://youtu.be/YR5WdGrpoug?t=2823

Re: (next Rich)

#134

Post by tumdum_ »

kaba0 wrote: post #94
brundolf wrote: post #82

Rich has to be my favorite thinker in this space, absolutely love his talks and the way he articulates things, and I often draw from his philosophies in my work But, I've always been turned off to Clojure by the lack of static typing (I know spec exists, but it's not really the same thing). I did a little project once to try it out, and even there I found myself spending time debugging basic issues like passing the w…

I am myself not 100% sold on it, except immediately after any Rich talk (honestly, that man could sell me anything :D), but it was eye opening to me that static typing is not an end goal in itself -- it might be a local optimum, but there are many more things it can't express than it can. Also, in case of Clojure you usually handle FP code with no side effects, written in a REPL-driven, interactive style. This combin…

I have the same reactions to his talks. Yet, long term, I've never been able to convince myself that clojure, common lisp or more popular ruby/python, are good choices for me in case of long running projects.

I'm not sure how being liberal in what you accept is at odds with static typing. Static typing is about encoding the rules and shapes of the data that your program *knows* how to work on. It's not preventing some other data that you don't care from existing alongside.

Even if I'm missing something, that doesn't change the fact that in most static typed languages you can fallback to some sort of "any" types. Seems to me it's better to have option to use static or dynamic types in the same program, instead of being forced to do *everything* in dynamically typed way.

Re: (next Rich)

#135

Post by stefcoetzee »

devgoth wrote: post #106
jwr wrote: post #101

Rich, thank you for creating and maintaining a tool that has helped me build a successful SaaS business. I could not have done this without your work and your insights. I also learned a lot from your talks, and I do hope to meet you again at one of the Clojure conferences.

Curious, what SaaS space are you in where you found Clojure was a good fit? Would love to add this info to my brain-base for future ideas :)

PartsBox https://partsbox.com/ — an app that lets you take control of electronic parts inventory and electronics production.

Re: (next Rich)

#136

Post by whitepoplar »

red_hare wrote: post #132

I got to work in clojure for two years and it was one of the most useful experiences of my career. I still "think in clojure" even now writing Python, Java, and Go. I can't wait to use it professionally again someday.

i'ved only dabbled in clojure/lisp, but i've heard many lisp programmers talk about "thinking in lisp". can you share some of the particulars of what that means and why thinking in lisp/clojure is beneficial?

Re: (next Rich)

#137

Post by kaba0 »

tumdum_ wrote: post #134
kaba0 wrote: post #94

Earlier quoted context omitted.

I am myself not 100% sold on it, except immediately after any Rich talk (honestly, that man could sell me anything :D), but it was eye opening to me that static typing is not an end goal in itself -- it might be a local optimum, but there are many more things it can't express than it can. Also, in case of Clojure you usually handle FP code with no side effects, written in a REPL-driven, interactive style. This combin…

I have the same reactions to his talks. Yet, long term, I've never been able to convince myself that clojure, common lisp or more popular ruby/python, are good choices for me in case of long running projects. I'm not sure how being liberal in what you accept is at odds with static typing. Static typing is about encoding the rules and shapes of the data that your program *knows* how to work on. It's not preventing som…

Well, spec is there, so it is not only typed vs untyped but static types vs contracts. With the added ability to generate test data, I think the field is much more equal, but as I said, I also tend to fallback to statically typed languages, but that’s mostly just out of conform.

Re: (next Rich)

#139

Post by seer »

zbobet2012 wrote: post #127

Rich's simple made easy is the best programming video I've ever seen, and is ultimately I think what so many engineers need to "grok" to unlock better coding. I'm the "most senior" engineer (chief architect) in a company of more than a thousand engineers, and I recommend it to every junior who asks how to get better. I will also say I used clojure + aleph to write the only significant application I ever released whic…

The other essential talk I usually recommend is “beyond PEP8” by Raymond Hettinger.

Its was one of those things that was always on my mind, but couldn’t express it well to my peers, before encountering this talk. Plus its about both python and java, so increases the chances to be heeded by non-fp people.

A lot of programmers I’ve worked with either don’t want to learn well the environment they are working in, thus repeating stuff that doesn’t fit well, or over-engineer abstractions to force their environment to behave the way they like, and both approaches can leave the codebase in shambles.

Re: (next Rich)

#140

Post by nlitened »

whitepoplar wrote: post #136
red_hare wrote: post #132

I got to work in clojure for two years and it was one of the most useful experiences of my career. I still "think in clojure" even now writing Python, Java, and Go. I can't wait to use it professionally again someday.

i'ved only dabbled in clojure/lisp, but i've heard many lisp programmers talk about "thinking in lisp". can you share some of the particulars of what that means and why thinking in lisp/clojure is beneficial?

From my experience with Clojure, and how it changed my thinking:

1. I stopped thinking about OOP, classes, “patterns”, frameworks, and mostly think about what data flows through the program, how it’s (they’re?) transformed and stored. It’s a much clearer view of a system, I think.

2. I started being very conservative about mutable state. I keep mutable parts few and mostly on the top level, and compose program logic from practically pure functions. It helps with debugging issues immensely, and fewer issues arise because pieces can’t interact unpredictably.

3. I stopped caring about types/shape of data inside modules, and spec the hell out of it on module boundaries. IMO static typing is too strict for the former use case, and too loose for the latter. It allows more flexibility in implementation without actual breaking changes.

4. I now enjoy developing in REPL, updating a running program, adding features in real time. It feels so natural.

Post reply on HN