Live data from Hacker News

The Two Cultures of Mathematics (2000) [pdf]

dpmms.cam.ac.uk

41–50 of 72 posts

Re: The Two Cultures of Mathematics (2000) [pdf]

#41
post #11

I wrote a blog post a few years ago[1] making a similar claim about computer science. I said there’s 3 main camps of programmers: - People who enjoy programming because it’s mathematically beautiful (eg Haskell programmers) - People who enjoy programming because they like reasoning about machines, and like mechanical sympathy (eg C programmers) - And people who like programming because it can solve real problems for…

> wrote a blog post a few years ago[1]

I thoroughly enjoyed your post at the time!

One thing that I disliked, though, was the inaccurate caricaturing of people on camp 2. For example:

> Low level languages are often better than high level languages because you can be more explicit about what the computer will do when it executes your code. (Thus you have more room to optimize).

My concern is the last parenthesis. I am squarely on camp 2, but I'm almost never concerned for optimization. I want my code to be very explicit because I want to understand clearly what it does (thus I hate C++ and other untoward abstractions). Thus clarity is the main motivation, not efficiency as you put it.

Re: The Two Cultures of Mathematics (2000) [pdf]

#42
post #11

I wrote a blog post a few years ago[1] making a similar claim about computer science. I said there’s 3 main camps of programmers: - People who enjoy programming because it’s mathematically beautiful (eg Haskell programmers) - People who enjoy programming because they like reasoning about machines, and like mechanical sympathy (eg C programmers) - And people who like programming because it can solve real problems for…

> wrote a blog post a few years ago[1] I thoroughly enjoyed your post at the time! One thing that I disliked, though, was the inaccurate caricaturing of people on camp 2. For example: > Low level languages are often better than high level languages because you can be more explicit about what the computer will do when it executes your code. (Thus you have more room to optimize). My concern is the last parenthesis. I a…

Perhaps you are a detail-oriented person? I've met quite a lot of people who - like you it seems (although perhaps you disagree) - find things that are low-level and procedural to be clearest. Such people often like languages like C and Go where this style is encouraged.

On the other hand, I tend to think in terms of abstractions. And thus find things much clearer when they are based on high level abstractions (things like map and filter, RAII, pattern matching, etc). And I like languages like Rust and TypeScript where I can express those. If I read a for-loop, I have to translate it into a more abstract higher-level function in my head to understand what it's doing anyway.

Re: The Two Cultures of Mathematics (2000) [pdf]

#43
post #11

I wrote a blog post a few years ago[1] making a similar claim about computer science. I said there’s 3 main camps of programmers: - People who enjoy programming because it’s mathematically beautiful (eg Haskell programmers) - People who enjoy programming because they like reasoning about machines, and like mechanical sympathy (eg C programmers) - And people who like programming because it can solve real problems for…

You bluntly imply that j.blow wouldn't perish from using unity, but offloading to monopolies is really just a race to the bottom.

Re: The Two Cultures of Mathematics (2000) [pdf]

#44

Earlier quoted context omitted.

> wrote a blog post a few years ago[1] I thoroughly enjoyed your post at the time! One thing that I disliked, though, was the inaccurate caricaturing of people on camp 2. For example: > Low level languages are often better than high level languages because you can be more explicit about what the computer will do when it executes your code. (Thus you have more room to optimize). My concern is the last parenthesis. I a…

Perhaps you are a detail-oriented person? I've met quite a lot of people who - like you it seems (although perhaps you disagree) - find things that are low-level and procedural to be clearest. Such people often like languages like C and Go where this style is encouraged. On the other hand, I tend to think in terms of abstractions. And thus find things much clearer when they are based on high level abstractions (thing…

i think it may be that. When I see some code like this in C++:

    y = f(x);
I'm extremely terrified to what is going on. It is like looking into an abyss. Is this code calling a function named "f" with argument "x"? If so, there may be several different functions "f" depending on the type of "x". Maybe none of them has the same type as "x", but there are some conversions that may happen and lead to that. Or maybe "f" is not even a function, but it is an object that has overloaded the parenthesis operator? And then, what happens to the result, whatever type it has. Is it calling a copy constructor (over some inheritance chain)? Is the assignment operator overloaded? If running this line results in an execution error, I'm totally lost as to where to find the problem.

On the contrary, in C, the same line says explicitly what code is executed, without need for further context. If the code compiles, there is a single visible definition of a function named "f" and this is the code that is called.

I read much more code than I write. But code with lots of abstractions, like C++ with objects or templates, however elegant was to write, is a disgusting chore to analyze, understand and eventually fix (because the abstractions always fail). On the other hand, analyzing C code is pretty straightforward, even if it was a bit more verbose to write.

Re: The Two Cultures of Mathematics (2000) [pdf]

#45
post #11

I wrote a blog post a few years ago[1] making a similar claim about computer science. I said there’s 3 main camps of programmers: - People who enjoy programming because it’s mathematically beautiful (eg Haskell programmers) - People who enjoy programming because they like reasoning about machines, and like mechanical sympathy (eg C programmers) - And people who like programming because it can solve real problems for…

I belong to the camp that enjoys programing in a beautiful way and has experiemented languages that are capable of achieving mechanical sympathy without having to deal with C.

Re: The Two Cultures of Mathematics (2000) [pdf]

#46
post #11

I wrote a blog post a few years ago[1] making a similar claim about computer science. I said there’s 3 main camps of programmers: - People who enjoy programming because it’s mathematically beautiful (eg Haskell programmers) - People who enjoy programming because they like reasoning about machines, and like mechanical sympathy (eg C programmers) - And people who like programming because it can solve real problems for…

Fantastic! Thanks for this. The FP vs non-FP split has always just felt like a less rigorous version of the "analysis vs algebra" or "problem-solving vs theoretical" discussion and I'm glad I'm not alone in thinking this. This is also what rubs me the wrong way about the simplistic level with which FP languages (like Haskell or Scala+monads) are either cargo culted or hated. The truth is, the two perspectives really…

In my opinion, the FP/IP split is fueled in no small part by a wildly divergent set of vocabularies. A dozen different transforms are inscrutable to anyone who has not spent much time studying Lambda calculus, and the concept of a monad is famously difficult to explain.

You wind up with two camps that cannot communicate. It's often made worse by the functional programmers - who are mostly also imperative programmers - doing a poor job of enabling translation.

Re: The Two Cultures of Mathematics (2000) [pdf]

#47
post #37
post #11

I wrote a blog post a few years ago[1] making a similar claim about computer science. I said there’s 3 main camps of programmers: - People who enjoy programming because it’s mathematically beautiful (eg Haskell programmers) - People who enjoy programming because they like reasoning about machines, and like mechanical sympathy (eg C programmers) - And people who like programming because it can solve real problems for…

The camp 3 is called "professional programmers". I mean: - sometimes a practical problem benefits greatly from a well-designed high-level abstraction, - sometimes a practical problem strictly requires low-level optimization. And yes, it is totally fine to have one's inclination in general, pursue them to any level in their free time, or in some (but not all) academic research. Yet, if a professional software engineer…

Anyone getting paid to program is professional.

We need to disabuse ourselves of the notion that "professional" implies any kind of quality, or that the people who program without being paid money are doing a bad job of it, for that matter.

Re: The Two Cultures of Mathematics (2000) [pdf]

#48

Earlier quoted context omitted.

>Unfortunately the people that get excited building things is outnumbered by the people that is just in this for the money. I don't think there's a reason to be sad about it. There are plenty of e.g. maintenance jobs in the industry, and people who are passionate about programming may not be the best fit for this niche - it's boring, and sometimes you feel the urge to re-invent a few wheels even in detriment to actua…

There's no real difference, if your sole interest is a paycheck, any programming is boring.

Yep. Does it contradict to what I wrote though?

Re: The Two Cultures of Mathematics (2000) [pdf]

#49
post #11

I wrote a blog post a few years ago[1] making a similar claim about computer science. I said there’s 3 main camps of programmers: - People who enjoy programming because it’s mathematically beautiful (eg Haskell programmers) - People who enjoy programming because they like reasoning about machines, and like mechanical sympathy (eg C programmers) - And people who like programming because it can solve real problems for…

The trivial way to unify all camps is to view it from the lens of expressionism/self-expression.

Mathematicians want to express equational reasoning/identities.

Computer scientists want to express computations.

Translation/bridging the gap will be a whole lot easier when both camps answered the trivial 'Why?' question which contextualises the reason for doing whatever it is that you are doing.

People without shared goals have the tendency to speak right past each other.

Re: The Two Cultures of Mathematics (2000) [pdf]

#50
post #11

I wrote a blog post a few years ago[1] making a similar claim about computer science. I said there’s 3 main camps of programmers: - People who enjoy programming because it’s mathematically beautiful (eg Haskell programmers) - People who enjoy programming because they like reasoning about machines, and like mechanical sympathy (eg C programmers) - And people who like programming because it can solve real problems for…

Fantastic! Thanks for this. The FP vs non-FP split has always just felt like a less rigorous version of the "analysis vs algebra" or "problem-solving vs theoretical" discussion and I'm glad I'm not alone in thinking this. This is also what rubs me the wrong way about the simplistic level with which FP languages (like Haskell or Scala+monads) are either cargo culted or hated. The truth is, the two perspectives really…

All notations (programming or Mathematical) are just different ways of expressing computations.

All notations have trade-offs at the level of semantics making certain operations more difficult to express (what programmers refer to as 'the expression problem')

That's the entire shpiel of reification/first-class citizenships/semantics of programming languages.

Instead of getting into fanboi-ism of 'my language is better than your language' perhaps approach the problem from first principles (design): what is "IT" that you want to talk about, reason, express and manipulate in your program?

That dictates the sort of language you need to solve the problem that you are trying to solve.

https://en.wikipedia.org/wiki/First-class_citizen https://en.wikipedia.org/wiki/Reification_(computer_science)

Post reply on HN