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

Logic for Programmers

logicforprogrammers.com

Post reply on HN
Print view View original

11–20 of 53 posts

Re: Logic for Programmers

#11

Post by dwattttt »

jpollock wrote: post #9
Merkur wrote: post #5

I read the free part. Looks interesting, but the math heritage is dominant as promised. It seems to favor the compact and efficient kind of code that is brittle in the hand of a mildly competent junior dev, or a heavy multitasking senior. I like smart code, in fun projects, but on the job I prefer fast to read and to reason code. Don’t try to be fancy. So I guess that’s a book to challenge my assumptions. I like that…

I know that as Kernighan's Law. Seems to be something that seniors learn over time. https://github.com/dwmkerr/hacker-laws#kernighans-law "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

I took some time to think about why this saying bugs me, and I think I've settled on "it suggests you can't understand your limits".

I know it's explaining the joke, but you've blown past "clever" if you've reached the point where you can't debug it.

Re: Logic for Programmers

#12

Post by fmajid »

kriro wrote: post #8

Looking at the table of contents, I see no mention of Gödel/incompleteness theorems or limitations which is not a great sign. It does look well structured though but I'd probably recommend just going with "Introduction to Logic" by Tarski and "Metalogic. An introduction to the metatheory of standard first order logic." by Hunter. Those served me well and are fairly understandable for a non-mathematician (imo). Altern…

How are Gödel's incompleteness theorem relevant to the working programmer?

Re: Logic for Programmers

#13

Post by harperlee »

theusus wrote: post #7

The problem I see with the book is copy editing. It is self published on lean pub, which I have seen has poor copy editing.

FWIW, I'm on the email list of Hillel, and when discussing that the book is done, he said the following, which makes me thing otherwise:

    This marks the completion of a project that took five years of work, six bookwriting professionals, fourteen domain experts, and fifteen public alphas.

    This has been, without a doubt, the biggest and most exhausting project I've ever done. The examples in the discarded drafts alone could make a second book. The cursed knowledge I've gained on LaTeX and typography could fill a third (or at least a couple of entertaining blog posts). Self-publishing was simultaneously the worst and best decision I made.

    Now excuse me I am going to sleep for a month.

Re: Logic for Programmers

#14

Post by gitowiec »

I would buy this book, but reading examples of simplify the condition is hard. I don't know the rules that apply to this. Do you know any other book that describes these rules?

Re: Logic for Programmers

#15

Post by jpollock »

dwattttt wrote: post #11
jpollock wrote: post #9

Earlier quoted context omitted.

I know that as Kernighan's Law. Seems to be something that seniors learn over time. https://github.com/dwmkerr/hacker-laws#kernighans-law "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

I took some time to think about why this saying bugs me, and I think I've settled on "it suggests you can't understand your limits". I know it's explaining the joke, but you've blown past "clever" if you've reached the point where you can't debug it.

When you get into team development, doesn't it become the average? So, it's not just about your limits, it's about the team's average.

Otherwise, you're the only one who can fix your code, and becomes a whole bus factor thing.

Re: Logic for Programmers

#16

Post by js8 »

Looks like a nice book, but.. I feel like no serious work with this ambition today should omit (maybe it is present, not sure from the ToC) the Curry-Howard isomorphism, propositions-as-types, and from it following the analogy between logics and lambda calculi.

I really like this: https://disi.unitn.it/~bernardi/RSISE11/Papers/curry-howard....

I think every programmer should understand the consequences of CHI to the discipline, which are profound. It means that there is no need for classical logic as a separate metalanguage, the properties of programs could also be expressed in the programming language of your choice. Furthermore, it shows that "running the program" and "reasoning about the program" are ultimately the same processes, which raises some good philosophical questions about testing for example. But also about how can we approach the program design, maybe we can just "calculate it" from the constraints. It also opens us to things such as supercompilation.

I think the discipline needs to move towards formal understanding how different programming languages and logics express similar ideas, because it's a really powerful tool of mutual understanding.

(Also, I personally find the typed LC notation, especially with type checking and inference, easier than the classical logic notation. It might be the reason why logic is considered too complicated.)

Re: Logic for Programmers

#17

Post by cubefox »

kriro wrote: post #8

Looking at the table of contents, I see no mention of Gödel/incompleteness theorems or limitations which is not a great sign. It does look well structured though but I'd probably recommend just going with "Introduction to Logic" by Tarski and "Metalogic. An introduction to the metatheory of standard first order logic." by Hunter. Those served me well and are fairly understandable for a non-mathematician (imo). Altern…

> I'd probably recommend just going with "Introduction to Logic" by Tarski and "Metalogic.

Those are not aimed at programmers, so very different and not a replacement. Just look at the free sample on the website. Besides, incompleteness theorems are probably irrelevant for programmers.

Re: Logic for Programmers

#18

Post by cubefox »

This looks great. Most logic books are written by and aimed at mathematicians or philosophers, with basically zero involvement of practical programming applications, while the author here has a software engineering background and it shows.

Re: Logic for Programmers

#19

Post by cubefox »

js8 wrote: post #16

Looks like a nice book, but.. I feel like no serious work with this ambition today should omit (maybe it is present, not sure from the ToC) the Curry-Howard isomorphism, propositions-as-types, and from it following the analogy between logics and lambda calculi. I really like this: https://disi.unitn.it/~bernardi/RSISE11/Papers/curry-howard.... I think every programmer should understand the consequences of CHI to the…

The book you mention is the opposite of "Logic for Programmers": it's abstract academic mathematics with zero code. (Except in the sense that constructive proofs are allegedly code. They are not, unless they are written in an actual programming language like Lean.)

Re: Logic for Programmers

#20

Post by Jach »

jpollock wrote: post #15
dwattttt wrote: post #11

Earlier quoted context omitted.

I took some time to think about why this saying bugs me, and I think I've settled on "it suggests you can't understand your limits". I know it's explaining the joke, but you've blown past "clever" if you've reached the point where you can't debug it.

When you get into team development, doesn't it become the average? So, it's not just about your limits, it's about the team's average. Otherwise, you're the only one who can fix your code, and becomes a whole bus factor thing.

The limits of the team, even insisting on >1 person being able to fix any code written by the team, are probably much higher than the average of the team. Furthermore, the average isn't going to improve much if code is never written above it. This isn't to say go all out with the most clever code possible, or make things difficult for the sake of difficulty, but consider that it's possible to help upskill your team by showing them better ways (even if sometimes technically "cleverer ways") to write code. It's ok if something isn't as familiar to everyone initially -- exposure helps that. Do better code reviews, code walkthroughs, lunch & learns, book clubs, consultants to come in and teach something, there's lots of ways to improve as a team.
Post reply on HN