Zompist Bboard Again

rotting bones wrote: ↑Mon Feb 20, 2023 10:15 pm 1. If the first lesson in programming is Lambda Calculus and basic I/O is the fifteenth, that seems unreasonably elitist to me. https://youtu.be/ADqLBc1vFwI

2. Excessive rigidity negatively affects usability and modular development: https://youtube.com/playlist?list=PLLce ... Yl7wnth-bT

3. Code optimization is a mystery even to veterans: https://youtu.be/yRVjR9XcuPU

4. If your theory of computation is drawn from first principles rather than being based on physical models, then you won't be able to update it with, eg, the development of Quantum Mechanics.

bradrn wrote: ↑Mon Feb 20, 2023 11:41 pm I’ve had this discussion many times on the FP Discord server. The consensus we’ve come to is that this is indeed a bad way of teaching, and introducing IO early would be better.

bradrn wrote: ↑Mon Feb 20, 2023 11:41 pm Good Haskell code shouldn’t be rigid. I find that the design of the type system gives my Haskell code significantly more flexibility than, say, Java.

bradrn wrote: ↑Mon Feb 20, 2023 11:41 pm I have no idea how to even respond to this. How is QM at all relevant? How is Haskell different to any other current programming language in this regard?

rotting bones wrote: ↑Tue Feb 21, 2023 12:03 am

bradrn wrote: ↑Mon Feb 20, 2023 11:41 pm I’ve had this discussion many times on the FP Discord server. The consensus we’ve come to is that this is indeed a bad way of teaching, and introducing IO early would be better.

So you'd just not tell them what monads are until later?

bradrn wrote: ↑Mon Feb 20, 2023 11:41 pm Good Haskell code shouldn’t be rigid. I find that the design of the type system gives my Haskell code significantly more flexibility than, say, Java.

Well, I'm entirely self-taught in Haskell. Where can I learn non-fussy Haskell coding?

bradrn wrote: ↑Mon Feb 20, 2023 11:41 pm I have no idea how to even respond to this. How is QM at all relevant? How is Haskell different to any other current programming language in this regard?

Quantum computing? What's the Lambda Calculus equivalent of the Quantum Turing Machine?

- Depending on how it's written, Haskell's syntax can be elegant, maybe?

- I've heard people say that Haskell programs are short. However, I'm not sure what Haskell can accomplish that can't be reproduced in modern C++ with consts, enums, lambdas and tail recursion.

alice wrote: ↑Tue Feb 21, 2023 2:50 am You may be interested to know that at my work I successfully introduced functional programming techniques, including a simple implementation of monads, into the Python project I'm working on, only to see the whole thing derailed by rogue I/O exceptions which no amount of correctness proofs could have explained away.

bradrn wrote: ↑Tue Feb 21, 2023 12:22 am Yes, pretty much. At least for teaching purposes, do-notation is entirely usable without requiring knowledge of monads.

bradrn wrote: ↑Tue Feb 21, 2023 12:22 am Er… not sure; it all depends on how much you know so far. But I like What I Wish I Knew When Learning Haskell as an overall guide to what’s possible in the ecosystem.

bradrn wrote: ↑Tue Feb 21, 2023 12:22 am True, quantum computing would require entirely different paradigms. But that being said, I have some knowledge here, and am fairly confident in saying that quantum computing is not in any way a replacement for classical computing. I like to compare it to GPUs in how it might eventually be applied — and note that GPUs don’t necessarily use ‘standard’ paradigms either.

rotting bones wrote: ↑Sun Feb 26, 2023 8:33 am In cybersecurity, you want your program to fail if it doesn't meet predefined security parameters no matter how convoluted it needs to be as a result.

alice wrote: ↑Sun Feb 26, 2023 2:09 pm A bit off-topic, but I decided to learn Rust by reimplementing my SCA in it, and found the whole experience so frustrating that I've given up on it for the time being.

rotting bones wrote: ↑Sun Feb 26, 2023 8:33 am

alice wrote: ↑Tue Feb 21, 2023 2:50 am You may be interested to know that at my work I successfully introduced functional programming techniques, including a simple implementation of monads, into the Python project I'm working on, only to see the whole thing derailed by rogue I/O exceptions which no amount of correctness proofs could have explained away.

Right? Meanwhile, the famous "pure" object-oriented language, Smalltalk, is so eminently usable, it was used to teach coding to babies.

By contrast, in strict functional programming, your code doesn't run until the type theoretic proof goes through.

rotting bones wrote: ↑Sun Feb 26, 2023 8:55 am

bradrn wrote: ↑Tue Feb 21, 2023 12:22 am Yes, pretty much. At least for teaching purposes, do-notation is entirely usable without requiring knowledge of monads.

If you need to introduce programming with an underexplained do notation, doesn't that prove imperative programming is more intuitive than functional programming? There's a reason recursion is taught after loops.

I don't remember the details of how I learned Haskell. I know it involved Haskell Programming from First Principles and loads of online advice.

If Lambda Calculus is your only theory of computation, how will you reason about the speedups from Quantum Computing? I consider the fact that we can't explicitly represent certain algorithms in it to be a strike against Lambda Calculus.

bradrn wrote: ↑Sun Feb 26, 2023 5:19 pm Smalltalk is a very nice language indeed! (Mostly because it implements proper OOP, not the half-baked version popularised by C++ and Java.)

bradrn wrote: ↑Sun Feb 26, 2023 5:19 pm But I strongly suspect that the ‘teaching to babies’ aspect of things has more to do with its very nice live environment than anything else. Compare some other programming languages widely used as a first language: BASIC, Scratch and Logo have very little in common, except that they run in a live environment.

bradrn wrote: ↑Sun Feb 26, 2023 5:19 pm Yeah, if by ‘type theoretic’ you include stuff like ‘you can’t add a number to a string’!

bradrn wrote: ↑Sun Feb 26, 2023 5:19 pm I’m not a fan of HPFPP. Starting with lambda calculus was entirely the wrong approach.

bradrn wrote: ↑Sun Feb 26, 2023 5:19 pm But secondly: you’re confusing the mathematical formalism of algorithms with the physical substrate used to implement them. Every quantum algorithm can be implemented on a classical computer just as easily, and every classical algorithm can be run on a quantum computer too.

...

Thus, if you want to reason about speedups, then you do need to develop a machine-specific representation, no matter how much that feels like a ‘strike against’ that representation. For classical computers, that involves thinking about assembly language, memory access times, pipelining, branch prediction, etc. For quantum computers, that involves writing algorithms with matrix algebra and thinking about error-correction codes. For the abstract algorithm, it involves interaction combinators. And so on.

bradrn wrote: ↑Sun Feb 26, 2023 5:19 pm Sure, some algorithms provide an asymptotic speedup on a quantum computer, but there’s nothing particularly special about that — the abstract algorithm gives an asymptotic speedup on some algorithms too, and that’s just classical lambda calculus! Meanwhile, a lot of algorithms are much easier to implement on a classical computer than on a quantum computer.

rotting bones wrote: ↑Sun Mar 05, 2023 10:17 pm - For neural networks, we want to check, modify and drop intermediate nodes. People [weasel words] have said this is made unnecessarily difficult when mutation is disabled.

- While Haskell's syntax is minimalistic, it's so determined to distinguish operations that are even slightly different that it creates an explosion in the number of operators. For example, IIRC Haskell strongly distinguishes between multiplying by a scalar and a dot product. The maker of an AI library said this kind of thing introduces unnecessary complexity.

class HeteroMult a b c | a b -> c  where
    (.*) :: a -> b -> c
instance HeteroMult Int Int Int where
    n .* m = n * m
instance HeteroMult Int [Int] [Int] where
    n .* ms = fmap (n*) ms
instance HeteroMult [Int] [Int] Int where
    ns .* ms = sum (zipWith (*) ns ms)

bradrn wrote: ↑Sun Feb 26, 2023 5:19 pm But I strongly suspect that the ‘teaching to babies’ aspect of things has more to do with its very nice live environment than anything else. Compare some other programming languages widely used as a first language: BASIC, Scratch and Logo have very little in common, except that they run in a live environment.

True, but I don't think it's just the environment. A lot of languages have BASIC-like REPLs. The concept of telling entities to do things lends itself to anthropomorphism, something humans are naturally good at. Logo leverages the same concept with the turtle.

bradrn wrote: ↑Sun Feb 26, 2023 5:19 pm Yeah, if by ‘type theoretic’ you include stuff like ‘you can’t add a number to a string’!

Why not? A type is a set with an identity function defined over its elements. You're mistaken if you're implying that Haskell's type system is limited to practical programming types. It was explicitly designed to be compatible with advanced mathematical properties in category theory.

You can write Haskell in a top-down style where you fill in low level details involving mundane types afterwards. It's a bit like interfaces in Java. If you're willing to put in the effort, Haskell allows you to structure your code like a proof of correctness.

bradrn wrote: ↑Sun Feb 26, 2023 5:19 pm I’m not a fan of HPFPP. Starting with lambda calculus was entirely the wrong approach.

I enjoyed working through it TBH. I learned Lambda Calculus by reading Wikipedia. The untyped Lambda Calculus is very simple:

bradrn wrote: ↑Sun Feb 26, 2023 5:19 pm But secondly: you’re confusing the mathematical formalism of algorithms with the physical substrate used to implement them. Every quantum algorithm can be implemented on a classical computer just as easily, and every classical algorithm can be run on a quantum computer too.

...

Thus, if you want to reason about speedups, then you do need to develop a machine-specific representation, no matter how much that feels like a ‘strike against’ that representation. For classical computers, that involves thinking about assembly language, memory access times, pipelining, branch prediction, etc. For quantum computers, that involves writing algorithms with matrix algebra and thinking about error-correction codes. For the abstract algorithm, it involves interaction combinators. And so on.

As a holder of a Masters degree and a PhD candidate in Computer Science, I feel compelled to point out that this is a misunderstanding of asymptotic complexity theory. All considerations about space and time have been collapsed into a single complexity tree hierarchy. For example, we know that logspace is a subset of polynomial time: https://en.wikipedia.org/wiki/L_(complexity) Using a quantum processor introduces novel structure into this tree that, to the best of our knowledge, cannot be obtained in any other way: https://en.wikipedia.org/wiki/BQP https://en.wikipedia.org/wiki/Quantum_complexity_theory

bradrn wrote: ↑Sun Feb 26, 2023 5:19 pm Sure, some algorithms provide an asymptotic speedup on a quantum computer, but there’s nothing particularly special about that — the abstract algorithm gives an asymptotic speedup on some algorithms too, and that’s just classical lambda calculus! Meanwhile, a lot of algorithms are much easier to implement on a classical computer than on a quantum computer.

But a sequence of operations is what the substrate does. No chip works on Lambda Calculus. Since physics is dynamic, it's unclear how to build a chip which evaluates such operations on a fundamental level.

Why make it difficult to reason about the underlying architecture by encasing it in unnecessary layers of abstraction? There are good answers to this question, and those answers indicate the use cases that Haskell is good at.

Don't get me wrong, I think "safety" concerns (AKA proving theorems) is often important in fields like cybersecurity.

Besides, I love Haskell since Curtis Yarvin hates it.

If anything, I don't think Haskell goes far enough.

jcb wrote: ↑Mon Mar 20, 2023 3:11 pm Imo, the OOP craze (Java, C++, etc) has stunted programming language evolution for a whole generation.

Such as ? I find most of Haskell's deeper features useless and needlessly complex (elm wisely never implemented them for this reason), but then again, I'm not an academic doing academic things with Haskell, which is why most of those features exist in the first place.

1. Languages with poor type systems (e.g. Java) have trouble when they need to represent data with a flexible structure. One way around this is to get rid of static type checking in the first place, which is what dynamically typed languages do, but that removes all the guarantees static typing gives you. The other alternative is to enhance the type system so you can represent what you want. This is what Haskell does.
2. A type system is only as helpful as the guarantees it can give you. Most type systems can’t give you guarantees much more complex than ‘this number is integral’. Haskell’s can enforce much more interesting properties, which is helpful for preventing mistakes in real-world programs.

bradrn wrote: ↑Mon Mar 20, 2023 8:14 pm

jcb wrote: ↑Mon Mar 20, 2023 3:11 pm Imo, the OOP craze (Java, C++, etc) has stunted programming language evolution for a whole generation.

Not necessarily. Java and C++ have a rather terrible and distorted implementation of OOP, but the original idea of OOP (implemented in languages such as Smalltalk and Ruby) was rather good. It also introduced several ideas, such as encapsulation and late-binding, which continue to be extremely useful to this day.

Such as ? I find most of Haskell's deeper features useless and needlessly complex (elm wisely never implemented them for this reason), but then again, I'm not an academic doing academic things with Haskell, which is why most of those features exist in the first place.

As someone who uses Haskell for non-academic stuff (and is somewhat uninterested in the academic stuff anyway): my perspective on this is that those are actually surprisingly useful! You don’t need them all the time, but when you do they’re invaluable. Fundamentally, those features are there for two related reasons:

1. Languages with poor type systems (e.g. Java) have trouble when they need to represent data with a flexible structure. One way around this is to get rid of static type checking in the first place, which is what dynamically typed languages do, but that removes all the guarantees static typing gives you. The other alternative is to enhance the type system so you can represent what you want. This is what Haskell does.
2. A type system is only as helpful as the guarantees it can give you. Most type systems can’t give you guarantees much more complex than ‘this number is integral’. Haskell’s can enforce much more interesting properties, which is helpful for preventing mistakes in real-world programs.

Not necessarily. Java and C++ have a rather terrible and distorted implementation of OOP, but the original idea of OOP (implemented in languages such as Smalltalk and Ruby) was rather good. It also introduced several ideas, such as encapsulation and late-binding, which continue to be extremely useful to this day.

Languages with poor type systems (e.g. Java) have trouble when they need to represent data with a flexible structure. One way around this is to get rid of static type checking in the first place, which is what dynamically typed languages do, but that removes all the guarantees static typing gives you. The other alternative is to enhance the type system so you can represent what you want. This is what Haskell does.
A type system is only as helpful as the guarantees it can give you. Most type systems can’t give you guarantees much more complex than ‘this number is integral’. Haskell’s can enforce much more interesting properties, which is helpful for preventing mistakes in real-world programs.

3 feet + 5 meters

jcb wrote: ↑Tue Mar 21, 2023 12:12 am What I would like to see is a system that lets one add units/measurements to types. So,

Code: Select all

3 feet + 5 meters

gives a compiler error (or auto converts units appropriately), but still lets me use any ft and m type with any function with an integer parameter, thus relieving me of having to duplicate function definitions for different types. ( (+) for both ft and m). Of course, the types would combine appropriately when multiplied and divided. Thus, a function for velocity would have a return type of m/s, and acceleration m/s^2, and would raise a compiler error if the value returned didn't match the signature.

I’m working on this! There’s a couple of languages with some support for units (Frink, F#), but nothing which is both good and statically typed. I haven’t quite figured it out yet, but there’s enough literature on how such a language would work that I’m sure I’ll manage it eventually.