Think in Math, Write in Code • Hacker News Board

Re: Think in Math, Write in Code

#111

Post by Jtsummers » Thu, Jul 18, 2019, 2:41 PM UTC

ryandrake wrote: post #108

rowanG077 wrote: post #78

Earlier quoted context omitted.

Building software is not even remotely the same thing as building a bridge. It would be more akin to the architect creating the drawings twice for the bridge. Once as an exploratory version and the second one the production version. Oh wait that is actually how architects work. In fact at my work we have multiple CAD designers(not architects though) and it's not uncommon for them to completely throw away a design and…

Maybe if we treated the practice of software development more like bridge building, we would have better reliability, fewer outages, fewer zero-day exploits, fewer patches and bugfixes--software that actually works the first time, and every time for years.

I work in aviation/defense. They try to treat it just like building bridges, and it's a disaster. Please don't.

Software is a design practice/process. Not a building process. Any analogy should be to the design phase of other engineering disciplines.

Re: Think in Math, Write in Code

#112

Post by geomark » Thu, Jul 18, 2019, 2:45 PM UTC

Junk_Collector wrote: post #82

geomark wrote: post #71

Earlier quoted context omitted.

I've been thinking about this quite a bit, but coming from a different angle. I've been helping at my kid's school with coding clubs for primary students. When teachers are recruiting for the coding club they always mention the students who are good at math as good candidates. But what I have noticed is that the students who do the best in coding are more often musically inclined or linguistically talented. It seems…

It's also worth thinking about that you don't really learn math in primary school so much as you learn numbers and computation, so when a teacher says a child is good at math they usually mean good at numbers. Very few teachers understand math well enough to identify who would be good at it and a lot of unfortunate students find this out when they get to college.

Sure, I can see that. But isn't it similar with language and other subjects? You just learn the basics, nothing deep, no turns of phrases, little expressiveness.

Perhaps there is little correlation between those who excel at coding at a young age and those who go on to be good programmers when they get older. I just find it interesting that at this young age I see a correlation between coding skills and language skills more than math (really just arithmetic) skills.

Another observation was that we did the Hour of Code activity in December last year with Year 2 to Year 6 students (equivalent to Grade 1 to Grade 5 in the US). And in each group there was one or two student who really stood out. And every one of them was a girl. Small sample size of only about 100 students so maybe I shouldn't be wondering what is going on here.

Re: Think in Math, Write in Code

#113

Post by TrackerFF » Thu, Jul 18, 2019, 2:46 PM UTC

UK-AL wrote: post #81

I honestly believe the majority of the problems in the industry comes from the refusal to treat programming as mathematics. Everything has to be "easy", so anyone can understand from a basic level. It's one of the reasons we don't like verifying software using TLA, coq(proofs for programs), refinement types or using functional programming techniques. "It's too difficult for the average programmer". The first excuse i…

Well, from a practical standpoint, it's more desirable to put out a partially-working system fast, which can be improved upon as it is live - than spend too much time planning and implementing a fully working system. Note: By partially and fully, I simply mean systems with more and less bugs.

Rarely do companies and startups have the luxury to just lean back and take their time. It's a race against competitors, and everyone wants the advantage of being first.

I don't blame the devs, as much as I blame the market. People start taking shortcuts when they're judged by how fast they can crank out codes, and whether they can finish their sprints on time. You develop a culture of constantly putting out fires.

Hell, for some consulting firms this is a profitable business model: Deliver a partially working product, then spend 10-15 years on patching it up, on your clients bill.

Re: Think in Math, Write in Code

#114

Post by blain_the_train » Thu, Jul 18, 2019, 2:47 PM UTC

wa1987 wrote: post #61

This article reminds me of something I'm wondering about for too long now. What is the meaning of the below terms (possibly in various contexts). - abstraction - indirection - encapsulation - information hiding How do these relate to and differ from each other? I feel these get conflated a lot. Would be nice to tell them apart.

the book "Elements of Clojure" covers this.

Re: Think in Math, Write in Code

#115

Post by chongli » Thu, Jul 18, 2019, 2:48 PM UTC

deadgrey19 wrote: post #102

Thinking in math first has been the catch cry of functional programmers (and their formal logic/verification friends) for decades. And there's nothing wrong with it, unless the problem you are trying to solve actually requires performance. Then, you have to think in "system" first. For example: Write a program that captures network packets and stores them to disk as fast as possible . There's no maths to think of her…

What you're describing is a very limited view of math, resembling the general public view of math as being algebra, trigonometry, geometry, and calculus; that is, all the math people are exposed to in secondary school. Look further and you'll see disciplines such as mathematical logic, combinatorics, and graph theory, without which you wouldn't have networking or binary or computers at all, really.

I don't know what you mean by "fancy algorithms", but all algorithms that run on your computer have a basis in math.

As for making things go as fast as possible, well that's a special case of the field of optimization, another mathematical discipline.

Re: Think in Math, Write in Code

#116

Post by breck » Thu, Jul 18, 2019, 2:50 PM UTC

enriquto wrote: post #2

I do that. Then people hate me because all my variable names are single letters... At least, for functions use self-documenting names instead of "f", "g", as in math.

Mathematical notation is a primitive notation, and will go the way of Roman Numerals. I would recommend the book "Clean Code", which might convince you to lengthen your identifier names :)

Re: Think in Math, Write in Code

#117

Post by anaphor » Thu, Jul 18, 2019, 2:50 PM UTC

pron wrote: post #35

As the author notes, Leslie Lamport makes much of the same point, but more rigorously. You can find it in many of his writings, e.g. http://lamport.azurewebsites.net/pubs/state-machine.pdf Lamport's TLA+ makes this formal. It is a language based on simple mathematics + some temporal logic for reasoning about discrete systems (software, hardware) as well as hybrid discrete-continuous systems, and is increasingly used…

For most programs, you can just use PlusCal instead of straight TLA+ and get most of the benefits. Unless you're writing something that is heavily concurrent or distributed.

Re: Think in Math, Write in Code

#118

Post by wa1987 » Thu, Jul 18, 2019, 3:07 PM UTC

m3at wrote: post #41

1. Identify a problem 2. Design algorithms and data structures to solve it 3. Implement and test them ... In practice, work is not so well organized as there is interplay between steps. You may write code to inform the design. As the author acknowledged, real life rarely allow such clean division. One tool that I find very useful to interleave the three - or at least to allow shorter loops - is jupyter notebooks. The…

On a similar note, this looks interesting as well (not affiliated): https://observablehq.com/

Re: Think in Math, Write in Code

#119

Post by rowanG077 » Thu, Jul 18, 2019, 3:10 PM UTC

gaze wrote: post #99

rowanG077 wrote: post #11

Earlier quoted context omitted.

Really? I think the best way to solve a problem is to code it. I can never see all the corner cases and logical inconsistencies before I start typing. I have tried to formally model software before I start writing it and in the end it was largely a waste of time because real understanding of the problem comes with coding the solution. Of course when doing it like this you write a lot of code which later is unused or…

I have found that the gap in understanding between thinking you understand something and implementing something as a program is often much smaller than the gap between having programmed something and having proven it.

What do you mean having proven it? As in you tested it and it works or do you mean you have formally using math that your solutions always gives the correct result?

If it's the former then this is part of building it. An implementation without proper testing is incomplete. If it's the later I actually agree. Only the most sensitive of applications require that level of sophistication though.

Re: Think in Math, Write in Code

#120

Post by FiberBundle » Thu, Jul 18, 2019, 3:16 PM UTC

pgcj_poster wrote: post #67

I was surprised to learn that I really enjoy coding, whereas I rather dislike math. I feel like this article might resonate with some people, but not with me. > Programming languages are implementation tools, not thinking tools. They are strict formal languages invented to instruct machines in a human-friendly way. In contrast, thoughts are best expressed through a medium which is free and flexible. I don't find math…

> When I write code, the computer forces me to be 100% precise and will spit errors at me as soon as I do something wrong.

This is similar to math though, with the exception that you don't have something or someone telling you that you made a mistake, but you have to seriously question every step in your proof by applying the rules of logic and your knowledge. At a certain point you develop sufficient intuition to spot steps that might be wrong. Most mathematicians ignore steps, which they are not completely confident of being true for the time being, assume the step is true and continue to see whether their derivation leads to what was to be proved, only later checking the steps which they had doubts about. It's more similar to programming than you think. If you like the logical part and algorithmic thinking involved in programming, I'm sure you would also enjoy math if you'd give it a real chance.