I feel that the best way to run an open-source project is to do it only for yourself. You don't have to take responsibility for anything, all you do is let others use your results for their stuff if they'd like. This makes all of those marketing roles redundant -- you don't care about who uses your product, if anyone -- and also generally relaxes your schedule quite a lot -- there are no expectations you have to meet except your own. This way it obviously won't be a source of income, but there are easier and more reliable ways to earn money anyways. To be honest, as a user, I'm glad not all developers see it this way, but as a developer I can't see myself willingly taking responsibility for something troublesome just for the sake of others. Passive open source works for the same reason piracy does: it doesn't cost me anything to let you copy data. Active open source is a mystery to me, but also something I really respect, I guess.

Why not just make a mechanism that let's you do unsafe things in a safe way. The point of functional is not to never do mutations, it is to not screw other parts of the code with your mutations. * You can analyze that the mutations cannot be seen outside a function, which would usually mean it's in the current stack frame, unless you have more advanced rust type lifetime analysis. * There can be a mechanism to mark a function as unsafe, meaning it is allowed to take a mutable value as parameter, so it's possible to have helper functions inside a unsafe algorithm. These would only be callable on stack local data as parameters. * Simply make it so that those things that are only locally visible or passed to unsafe helper methods can have unsafe operations done to them. * Copying parameters into an array before running an algorithm, should in most cases be much cheaper than the algorithm itself. If that is no so, then it's not that expensive of an operation to begin with. * In addition copying could make the algorithm itself run a lot faster if the data is then copied into the actual array, instead of being on the heap (or boxed, or what you want to call it). This is a common technique even in imperative languages that use the heap to speed up certain algorithms, so that data will be ordered and not cause cache misses all the time while it's running. * All collections could have a "copy_for_mutation" ability, which in most cases would be all you need to do to start a mutating algorithm. But the result must be wrapped in a non mutable interface, and never referenced again once it escapes. Alternatively it can be converted to it's immutable counterpart first.

19:44 , Can we say that this anomaly is due to the database, having no clue of what the application is trying to do? If we store the count of on call doctors in the database, with mvcc snapshot isolation level, the writes to this counter will serialize and abort the other doctor's transaction.

Thanks you, for this insightful talk

I’ve realized the reason I made inefficient programs was because I lacked mathematical knowledge like this (abstract algebra in this case). I believe too many developers turn their nose up to the theoretical / functional world in an effort to keep things practical. But it’s a decision that leads to tech debt in the long run.

Great talk, thank you

Very useful details shared, thank you 👌🏽

at 10:20 he says that it's pretty clear that trivial non-breaking renames are better than what we have now, without addressing the implied and very clear downside that any semantic change (e.g. a bugfix in a dependency) must propagate code changes all the way through the codebase. this seems great if you're always right the first time, but i can't imagine working in software 20 years and somehow thinking people are generally right the first time. i hope theres some system to enable this to be painless, but to not mention it at all...?

The Python example from around 4:00 on feels a little contrived to me. I’ve done some professional work in Python, and I think I’d write it more as something like this: from math import sqrt def nd_pythagoras(*args): return sqrt(sum(x*x for x in args)) Or if you don’t want to do the fancy n-dimensional generalization: def pythagoras(a, b): return sqrt(a*a + b*b) Which doesn’t require much more name-binding than the likes of “: pythagoras dup * swap dup * + sqrt ;”. I’ll keep watching. Stack-based languages interest me, and while I doubt even Chuck Moore could implement Tears of the Kingdom in Forth, the way something like PlanckForth can be bootstrapped from a tiny core is fascinating. I’ve dabbled in designing a postfix-based language of my own (under the premise of “What would the C equivalent look like in a world where programming languages were mostly developed by speakers of an SOV language?”), but it did seem like there was a lot that could be expressed more clearly and succinctly with explicit value names.

year 2024. Still actual. Thanks!

Which one best python or nodejs for robotics

I don't see the problem, I bust out a program in c and because I know how the machine will run ahead of time, I get 80% there then spend maybe 10% of my time debugging and getting a cleaner output. The only problem I face is poor docs that prevent me to knowing how the lib uses the hardware therefore it flips, i use 90% of my work figuring out the damn thing as i bang my head against the wall. I guess in the situation a JIT or runtime language would be better to see changes quicker. Also I don't see how you could do computing with non linear program progression by the design of the processor itself. I guess you can argue abstracting the hardware away to a point where you don't know its there and have the runtime worry about adapting a program to be linear. I don't see linearity as a bad thing in fact it helps me solve the problem in systematic stages. If I am missing something PLEASE let me know.

It does not entirely check for "thread safety" - but testing for unexpectedly out of order events are certainly a starter for ten. In the olden days working on radio comms s/w of state/event matrices forced devs to think about all eventualities - but those were simpler systems. When you have multiple processes speaking to each other, each with their own state machine, the number of states of the system as a whole becomes exponentially more complex as you add processes, and bad things can happen. Part of the argument for distributed systems is that each small part can be easily understood and tested fully. However, often by splitting a complex system you actually create a system with far far more states many of which are never considered, or used or tested. Deterministic Simulation will test some of these situations by not all of them. It will be helpful for debugging but best not have a bug in the first place. And all this is before people start inaccurately and incompatibly reflecting the same state in multiple processes. For this reason my advice has always been "do not create another process or another thread unless absolutely necessary - it may be complicated , but splitting it up unnecessarily will only make that worse, it just won't be obvious until it is too late".

It’s 2024 and the situation has gotten worse.

20:02 just use subtraction to define it. Or loosely define every operators, solved.

I've started to have the feeling that many problems we think of as open (aka challenging and unsolved) at the business level have actually be solved many years ago in academia. But the reason we're still dealing with the same things is we haven't found an effective way to apply the concepts from these papers, or often just don't even know that they exist and relate to our domain. I've been in business meetings a few times we're people are discussing a decision to make or process to implement, and many non-technical people suggested things because they seemed nice but didn't have a precise rationale. I realized a lot of their problems were just solved math problems with new names. The downside is that many times the business execs thought my suggestion was too nerdy and wanted to just do what they thought was good in their opinion. Words like "monad" and "constraint satisfaction" and "algebraic data types" and all this stuff can make many people dismissive because it can sound condescending (at least for ones who are egotistically not confident in their own intelligence) and thus people assume those solutions are unnecessary complications when they're often actually *simplifications* compared to the alternative stuff we come up ad hoc. I believe that making it a habit to encourage better habits for organizations (governments, corporations, sports teams, families, etc) according to established research should be the goal for the next few years for people in the STEM fields rather than doing their own obscure research. Because what's the point of all these papers if few people are applying them and there are so many groups constantly reinventing the wheel (*cough* *cough* JS frameworks...) in ways that make standardization intractable.

interesting concept. any updates so far?

wonderfully nerdy, 谢谢！

TLDR: Values, types, and functional transformations are all non-sequential in reality but we're forced to choose some serialization in order to conform to source code's medium of choice--text. I believe if we could switch between a graphical perspective of the code which shows nodes and edges as well as the traditional sequence of source code characters in a file perspective, then we could have the efficient terseness of the combinatory approach as well as the more realistic clarity of a diagram. Rational: I think the reason that people often shy away from this style of programming is because code as text is serialized/sequential: it's ultimately stored as an ordered multiset of characters and we rely on the underlying programming language parser to understand it as a tree structure. But I believe that the tree structure is so much more intuitive to reason about. For example, we often think of data values as a (possibly recursive) tree-like structure with various fields / tuple indices to hold simultaneous smaller pieces of data. Types are a composition of data values that are mutually exclusive in time: you will have exactly on of the terms of the type at any time in a variable. And then transformations are a composition of functions that is probably not linear (as the examples in this talk showed) but are like a directed graph with initial nodes and terminal nodes.

I've become obsessed with the idea of structure in programs (and real life). I believe there is structure in values (both concretely and hypothetically as product types and sum types, respectively) like structs, enums. And then there is structure in changes which would correspond to functions and combinators of those functions. You can think of an analogy with natural language where values and their types are nouns (with values being the referent [which thing] associated to a lexeme [what thing] like `42 + 3.14i` being a value of type Complex) but functions are verbs which relate an input noun (sentence object) to output noun (sentence subject) which can be combined syntactically just like combinators can combine functions. Then it becomes a matter of specifying the desired output type (like a noun subject) according to the possible input type (noun object) and then the appropriate combinator of functions (verbs) will map the correct input referents to output referents within the respective types.

25:06 It seems like the second De Morgan law here is incorrectly shown since the OR inside the right parens should flip to an AND symbol when the negation distributes over `b OR c` to become `not b and not c`.

a presentation worth every minute with insights that became relevant more than ever in the past 10 years

great talk

I lost him at the point where HashTable is not good enough for in-memory caching 😅

One more ? Why not just improve haskell or racket ?

The reason C++ has become a garbage heap is the same reason Swift has also. It's become a slop of mutually exclusive ideas with tools that attempt to bring it together, however the language constantly expands with the ever need for more features. It's not great to add new features when they are not needed and add complexity to the entire system.

One of the best talks that I ever watched. It's like 4 talks in one where with so much content that Mae could go deeper in any direction at any time but also everything so well explained that all makes sense!!

Using the compression to find similar files, is a rudimentary way. But you can to find the similarities a more abstract way comparing programs description and reduce the complexity merging or substitute similar pieces of code looking for similar ASTs rather than similar files.

This talk was brilliant. Every part of it

If anyone else want the clear terminal string here it is for copy paste: \x1B[2J\x1B[1;1H

don't forget about steam controller input and gyro controls for the mousecombined this with talent voicean auto hot key in pythonyou can work twice as fast

Great talk! So, I wanted to use it in a simple elm program. However, there must be something I must install and/or import since putting "main = asText 42" in the elm playground just gives me the (expected) "I cannot find a `asText` variable" message.

He's written a paper on basic block versioning with Marc Feeley, the latter being the author of Gambit Scheme.

watching this again because it is so good

Dear lord... Did she just solve distributed systems and synchronization?!

perfect

If anyone wants to learn more about the Propagator model, 'Propagation Networks: A Flexible and Expressive Substrate for Computation' is a really good read from Sussman's PHD student Alexey Radul.

What about Idris2

Take a look at Pure Data

I watch this every year or two. ❤

Still the best talk on color spaces!

this is insane

He speaks English so well😂. Really like his way of introducing the history of all those punch cards and TTYs. Plus, the idea of interactive programming is quite useful in my opinion.

Love this video

This is a little hard to take in, but i can see there us future here. Amazing possibilities for such low power. Thank you Chuck.

❤❤

Too bad the stabilizer project seems to be dead. Anyone knows an updated version for llvm18+?

Such a great composition, delivered step by step. Very useful. Thanks for sharing.

Interesting idea about smaller language layers preserving more symmetries

Ironic to be watching this, as I just so happen to be re-compiling my whole Nix store as ``content-addressed``. This man was and this talk is simply BRILLIANT. I wonder how many people know about Unison, which brings some of these content-addressable goodness to the world of programming.