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

Fun vs. Computer Science (2016)

prog21.dadgum.com

Post reply on HN
Print view View original

161–170 of 184 posts

Re: Fun vs. Computer Science (2016)

#161

Post by didibus »

msangi wrote: post #144
didibus wrote: post #116

Earlier quoted context omitted.

It's true, but it's more a treatment then addressing the root cause. Rich Hickey, creator of Clojure has a fun quote that goes something like: "You thought you wanted TDD, but really you wanted an interactive REPL." My gripe with TDD, is that it gets tedious in its own way. Always needing to eventually mock some aspects of the code, and always working in the small, you start feeling distant from the medium and large…

A REPL is better when prototyping but tests have a lot of value afterwards. They're repeatable and they can be used to spot regressions. I think that the a good workflow is to do initial experiments on a REPL followed, once I get an idea of the code will look, by writing tests and the actual code that will run in production.

Yea, you still want regression tests no doubt, but those are very different from TDD. You only need write them after you're code complete on a feature.

Re: Fun vs. Computer Science (2016)

#162

Post by didibus »

btilly wrote: post #160
didibus wrote: post #113

Earlier quoted context omitted.

Ya, I think that's just the familiarity hump. Most people don't get over it, and the few that did geek out too much about the possibility of infinite macros, and how you could extend Lisp, while eventually realising how few made it past the familiarity hump and starting to feel isolated they eventually move to something else. It's hard to break this habit of familiarity, it's self replicating, because the less famili…

Speaking personally, I don't want to work with an image based language. That's an argument against both Lisp and Smalltalk. The problem with image based languages is that you've thrown away your file-based tool system. You're so used to your favorite text editor, source control system, etc? So sorry, we're building better tools! And when your code is ready, you just deploy the image! It sounds great in theory, once t…

Fair enough, but not all Lisps are image based. Clojure is file based. That's the one I use.

Re: Fun vs. Computer Science (2016)

#163

Post by kybernetikos »

tormeh wrote: post #158
kybernetikos wrote: post #157

Earlier quoted context omitted.

> It might even be more important than a static type system, at least for some apps. But you can have both. The important thing is not at which stage in the compilation pipeline the bug became obvious, it's at how many seconds elapsed it became obvious. I generally found that working in untyped js with a workflow prioritising fast iteration was much better for finding bugs quickly than working in Scala with its advan…

Scala has incremental compilation now through SBT, I believe. How long ago was this?

A few years.

Re: Fun vs. Computer Science (2016)

#164

Post by didibus »

Scarbutt wrote: post #145
didibus wrote: post #137

Earlier quoted context omitted.

Not really, I often don't need them. They're mostly for being able to reset the full app state back to how it is at startup. You can also just restart the REPL, though some people find waiting 5 second for that too annoying. I wish the restart times were much faster, but its not as big a problem as most people make it sound like. Often time, you can just learn to mold your program in smarter ways, so that you don't g…

You can also just restart the REPL, though some people find waiting 5 second for that too annoying. That's true only if clojure is your only dependency, in real project with libraries is more like 15 seconds with lein repl, cider is much worse. Do you have other recommendations for a language that meets these criterias? Some would say Common Lisp.

Another Lisp, I see. I've heard good things. It seems just a different set of trade offs. Clojure tradeoffs align better with me. The extra emphasis on immutability, concurrency, and functional programming, and embracing the JVM and JavaScript ecosystems. As well as the extension on the syntax for better data notation.

But I'll eventually give Common Lisp and Scheme a try.

Re: Fun vs. Computer Science (2016)

#165

Post by [deleted] »

btilly wrote: post #160
didibus wrote: post #113

Earlier quoted context omitted.

Ya, I think that's just the familiarity hump. Most people don't get over it, and the few that did geek out too much about the possibility of infinite macros, and how you could extend Lisp, while eventually realising how few made it past the familiarity hump and starting to feel isolated they eventually move to something else. It's hard to break this habit of familiarity, it's self replicating, because the less famili…

Speaking personally, I don't want to work with an image based language. That's an argument against both Lisp and Smalltalk. The problem with image based languages is that you've thrown away your file-based tool system. You're so used to your favorite text editor, source control system, etc? So sorry, we're building better tools! And when your code is ready, you just deploy the image! It sounds great in theory, once t…

[deleted]

Re: Fun vs. Computer Science (2016)

#166

Post by fredsir »

falcolas wrote: post #124
fredsir wrote: post #88

Earlier quoted context omitted.

What you are saying is like the people that would "rather write new functionality than tests"... Like, yeah, that would be nice, if you were able to write 100% bug free code, but you aren't so your tests are actually important in the goal towards a working product.

Well, I'd actually rather write unit tests than shake out type trees too, so no, the two statements aren't equivalent. Why? Unit tests also check a lot more than the types being passed around, so they are a lot more useful in the long run. There are some type systems where this is perhaps not the case, but they certainly aren't the majority. The majority is "so do I go with a float or a double" or "I have to cast thi…

A language that is exceedingly popular and has a great type system and has great tooling for tests is Rust. When using Rust, it’s quite evident why you have to use both and not one or the other.

And when it comes down to it, in theory, proofs are better than tests, and Id say no one would disagree, and in practice, types are proof. Unfortunately, you can’t use types for proving everything, so that is where tests comes in.

Imagine a platform where you could indeed prove everything. I believe, but am not sure, that there is some languages that do this, like Idris.

Re: Fun vs. Computer Science (2016)

#167

Post by open_bear »

btilly wrote: post #160
didibus wrote: post #113

Earlier quoted context omitted.

Ya, I think that's just the familiarity hump. Most people don't get over it, and the few that did geek out too much about the possibility of infinite macros, and how you could extend Lisp, while eventually realising how few made it past the familiarity hump and starting to feel isolated they eventually move to something else. It's hard to break this habit of familiarity, it's self replicating, because the less famili…

Speaking personally, I don't want to work with an image based language. That's an argument against both Lisp and Smalltalk. The problem with image based languages is that you've thrown away your file-based tool system. You're so used to your favorite text editor, source control system, etc? So sorry, we're building better tools! And when your code is ready, you just deploy the image! It sounds great in theory, once t…

> No matter how good your environment, you do not beat the collective effort and productivity of file-system based tools.

I bet people said the same about trains and ships. There was a lot of work put into horse-powered infrastructure and first cars and trains were very slow and bad. Same with boats: at the time steam-powered ships were created wind-powered clippers were 5 times faster and much more reliable.

Re: Fun vs. Computer Science (2016)

#168

Post by coldtea »

btilly wrote: post #160
didibus wrote: post #113

Earlier quoted context omitted.

Ya, I think that's just the familiarity hump. Most people don't get over it, and the few that did geek out too much about the possibility of infinite macros, and how you could extend Lisp, while eventually realising how few made it past the familiarity hump and starting to feel isolated they eventually move to something else. It's hard to break this habit of familiarity, it's self replicating, because the less famili…

Speaking personally, I don't want to work with an image based language. That's an argument against both Lisp and Smalltalk. The problem with image based languages is that you've thrown away your file-based tool system. You're so used to your favorite text editor, source control system, etc? So sorry, we're building better tools! And when your code is ready, you just deploy the image! It sounds great in theory, once t…

>The problem with image based languages is that you've thrown away your file-based tool system. You're so used to your favorite text editor, source control system, etc? So sorry, we're building better tools! And when your code is ready, you just deploy the image!

First, what's bad about that? Our text editors and source control systems are indeed crap compared to what we could get with image based systems with inherent (not text-level) knowledge of code. The only real argument is that we still need to work with legacy crap text-based languages also, which can't share those tools. But that's not really an argument against those tools being good in themselves.

Second, there's nothing about an "image based language" that says you can't also have a textual representation, and thus work with your editor (or the image based editor) and "regular" SCM tools.

Third, LISPs are generally not image based.

Re: Fun vs. Computer Science (2016)

#169

Post by DonbunEf7 »

didibus wrote: post #147
DonbunEf7 wrote: post #30

Earlier quoted context omitted.

Well, actually, let's explore the metaphor. Here's how I compose music. First, I use a highly-flexible prototyping instrument to quickly iterate on melodic ideas. Normally this is either humming or whistling. "Our first instrument," as an instructor used to call it. I do this until the melody is catchy enough to start sticking in my mind. Then I'll look at alternate parts, like countermelodies, B/C sections, harmonie…

Honestly, that describes exactly my programming workflow when working in Clojure. The whole process happens in Clojure. This language is small enough to write on a single piece of paper Check, Clojure is one of the most concise language out there. I use it for hand writing code or when coding on my phone, because its so short. fully contains all of its abstractions Yup. In fact, you need to change your mindset, you d…

Um. Here's the first part of Clojure's docs [0]. Compare and contrast: "A pitch is a frequency. 440Hz is an A pitch. There are twelve pitches. Each pitch differs from the previous pitch by the multiplicative constant twelfth-root-of-two. Twelve pitches in a row doubles the frequency, creating an octave." It only takes four or five paragraphs to mathematically describe the basis for chromatic notation.

If Clojure fully contained all its abstractions, then it would not have the option of calling into the JVM.

Clojure does not have the property that cutting any fragment of a valid program yields a valid program. There are languages in the concatenative style which have this property, but even there, the ability to compose does not guarantee the ability to split.

If you think that types produce reliability, then you do not understand types.

You seem dedicated to Clojure, which is great, but music is thousands of years older and has figured out a lot of stuff. I think that you also missed my bigger point, which is that programming is roughly at the same point in its art that cave painting was at hundreds of thousands of years ago. If you think that Lisps are beautiful and Clojure is the pinnacle, then I think that you don't know beauty. But it's not your fault; you've never seen anything beautiful. None of us have. And none of us ever will, at the current rate of progress.

Here, have a video to provoke some thoughts: [1]

[0] https://clojure.org/reference/reader [1] https://vimeo.com/74354480

Re: Fun vs. Computer Science (2016)

#170

Post by didibus »

DonbunEf7 wrote: post #169
didibus wrote: post #147

Earlier quoted context omitted.

Honestly, that describes exactly my programming workflow when working in Clojure. The whole process happens in Clojure. This language is small enough to write on a single piece of paper Check, Clojure is one of the most concise language out there. I use it for hand writing code or when coding on my phone, because its so short. fully contains all of its abstractions Yup. In fact, you need to change your mindset, you d…

Um. Here's the first part of Clojure's docs [0]. Compare and contrast: "A pitch is a frequency. 440Hz is an A pitch. There are twelve pitches. Each pitch differs from the previous pitch by the multiplicative constant twelfth-root-of-two. Twelve pitches in a row doubles the frequency, creating an octave ." It only takes four or five paragraphs to mathematically describe the basis for chromatic notation. If Clojure ful…

I think that you also missed my bigger point

Indeed I did. I'm not claiming Lisps and Clojure to be the be all end all of programming languages, I hope not. That said, I think you're being a little dramatic. Beauty really doesn't exist, its an illusion fabricated by a mix of our culture and our genetic predispositions. It's mostly characterized by the emotions it evokes in you.

Clojure and Lisps, currently of all languages I've tried, evoke the strongest set of positive emotions in me, the strongest one being joy. And I think some of it is not without merit.

Still, beauty is not what I'm talking about. I like quantifiable measures. You have productivity, explorativity, understandability, performance and correctness. Clojure finds a good balance between these, it tries to maximise the average of them all. Which is why I find it's great for your average programming project. I don't yet know of a language which does a better job at this maximization, but I'm always on the outlook for one.

It only takes four or five paragraphs to mathematically describe the basis for chromatic notation.

Its just as short to describe the basis of Lisps, that is the lambda calculus. Also, chromatic notation is less powerful then lambda calculus notation, much less, yet lambda calculus notation isn't much longer to describe. I'm also not sure shortness is necessarily better or more beautiful, again, that's an esthetic preference like minimalism in art. With nine constructs you can have a full Lisp impmementation that can do all turing equivalent computations and also I/O. But in practice, having even more turns out to be useful and makes things easier. I think it's the same for Forth too.

If Clojure fully contained all its abstractions, then it would not have the option of calling into the JVM.

I'm not sure this has any practical merits, but there's nothing in Clojure preventing this. It could, in fact self-hosted ClojureScript does. It's not very useful, which is why Clojure doesn't bother, and calling into the JVM is actually quite useful, to leverage lots of existing code.

Clojure does not have the property that cutting any fragment of a valid program yields a valid program.

You can cut anywhere an sexpr starts or ends and get a valid program. Maybe that's not granular enough for you, but what is? In forth you can cut at any whitespace and get a valid program, but I could claim it's not granular enough, I want to cut at any character. To me, the property is that the notation is recursive, it builds on itself. Sure the unit being an sexpr is not as small a unit as a single musical note, but that unit is independent, composable and nestable.

If you think that types produce reliability, then you do not understand types.

I don't, I didn't use that word at all. In fact I believe Clojure programs to be very reliable, even though they don't have static types.

Here, have a video to provoke some thoughts

Thanks, always looking for thought provoking thoughts, I have not watched it yet, but will.

Post reply on HN