Zalastax (u/Zalastax)

Zalastax commented on Fast self-hostable open-source workflow engine windmill.dev/blog/launch-... · Posted by u/rubenfiszel

sisve · 2 years ago

Searching for "Vfx pipeline" just gave me visual effects stuff. Quite sure that was not what you talked about. Could you explain a bit more what ypu mean by it and point to a resource. Keen to learn more.

I think windmill could have helped with several of the task and automated some. Its very easy to create dashboard and table with statuses. But its def not a process tool, if that was what he was after.

Zalastax · 2 years ago

I would also like to understand better. But it seems like it is visual effects that is meant. These tools were mentioned by name: https://www.kabaretstudio.com/https://prism-pipeline.com/

Zalastax commented on How many medical studies are faked or flawed? web.archive.org/web/20230... · Posted by u/PaulHoule

somenameforme · 2 years ago

"For more than 150 trials, Carlisle got access to anonymized individual participant data (IPD). By studying the IPD spreadsheets, he judged that 44% of these trials contained at least some flawed data: impossible statistics, incorrect calculations or duplicated numbers or figures, for instance. And in 26% of the papers had problems that were so widespread that the trial was impossible to trust, he judged — either because the authors were incompetent, or because they had faked the data."

So, 70% fake/flawed. The finding falls in line with other large scale replication studies in medicine, which have had replication success rates ranging from 11 to 44%. [1] It's quite difficult to imagine why studies where a positive outcome is a gateway to billions of dollars in profits, while a negative outcome would result in substantial losses, might end up being somehow less than accurate.

[1] - https://en.wikipedia.org/wiki/Replication_crisis#In_medicine

Zalastax · 2 years ago

Is there not full or at least partial overlap between the 44 % and the 26 %? Which would mean not 70 % but some smaller number?

Zalastax commented on Euclidean rhythms observablehq.com/@toja/eu... · Posted by u/hippich

Zalastax · 3 years ago

Euclidean rythms are well supported in the Tidal Cycles family of live programming environments. Here's a demo that you can play with online: https://strudel.tidalcycles.org?fTGy0eTiAUox

Which I took from its examples in the tutorial: https://strudel.tidalcycles.org/tutorial/

Tidal Cycles can be used to generate sound on your computer but it can also sequence MIDI hardware.

Zalastax commented on Gaming CS Interviews transitivebullsh.it/gamin... · Posted by u/EntICOnc

parimal7 · 3 years ago

Recently gave an interview where they asked me to open my Leetcode profile, and checked if there are any prior submissions to the asked questions. ¯\(ツ)/¯

Zalastax · 3 years ago

Interesting! I suppose one could prepare for that by having a second profile with just a few questions solved?

Zalastax commented on Go 1.18 go.dev/blog/go1.18... · Posted by u/mjlee

_0w8t · 3 years ago

For me the most puzzling aspect of Go is channels. Ada tried CSP (Concurrent Sequential Processes that Go channels are based on) in eighties and people quickly realized that it lead to bad performance and was unsuitable for a lot of useful cases. So Ada got standard mutexes and signals.

So why CSP which does not allow to implement priority delivery or multicasting and makes cancelling much harder compared with normal polymorphic message queue per thread? Moreover, Go crippled CSP even further as one cannot select on channel and file descriptor.

Fortunately Go does provide mutexes and signals so one can ignore channels unless required by Go API. Still without proper sum types polymorphic and type-safe message queues are not possible.

Zalastax · 3 years ago

You may find my MsC thesis, link in profile, interesting! If I remember my writing correctly, I have similar reflections on CSP.

Zalastax commented on Be curious, not judgmental shubhro.com/2021/12/20/be... · Posted by u/shbhrsaha

mwattsun · 4 years ago

Right, I understand where I wasn't clear. You're right, that idea has won and gone mainstream so I didn't think it was worth mentioning. I was emphasizing that I thought immutable data structures were inefficient and that it was the luxury of academics to abstract away stateful changes in the name of purity.

I've got a couple of other ideas that I need to do more research on (I'm watching Erik Meijer videos today)

1) Class objects with methods and data are like small programs, so I don't get why people go on and on about having data structures with functions as being superior to class objects, which are essentially data structures with associated functions.

2) Similarly, Joe Armstrong seems to hate object oriented programming but Erlang instances are essentially class objects, albeit running in their own process so they have more isolation

3) From reading Erik Meijer's Confessions of a Used Programming Language Salesman, I'm assuming that Async/Await that he help put in C# and Dart are his attempt to bring Haskell continuation monads to the imperative world

4) I'm assuming Clojure Atoms and Actors are like Haskell monads but don't know that. I watched Brian Beckman: Don't fear the Monad (https://www.youtube.com/watch?v=ZhuHCtR3xq8) but couldn't make heads or tails of it. Something about functions calling first order functions and pure first order effects with stateful second order effects, or something... That was a few years ago so I will give it another chance.

I'm probably wrong about these ideas but they're fun to think about and give me something to learn

Zalastax · 4 years ago

My view on 2 is that you get into a quite different mindset when you program actors, compared to objects. For starters, since each actor is scheduled separately, it becomes routine to not assume too much about the internal state of the actor. So you won't see many getters + setters in Erlang, for example. You also need to structure your program to not communicate unnecessarily, since communication may fail and requires you to wait for the other actor to reply. This makes you to think about what state should belong to which actor. It is quite subtle and is best seen by experiencing it, but I think the programs turn out quite different, and in my view better. Actors are not perfect for everything but to me they are what object oriented programming should have been.

Zalastax commented on “Alexander the Grate” on living in the “interstices of the infrastructure” smithsonianmag.com/smiths... · Posted by u/whocansay

graham_paul · 5 years ago

> or natural body

What do you mean by natural body?

Zalastax · 5 years ago

Natural body of water!

Zalastax commented on The Hamler Programming Language hamler-lang.org/... · Posted by u/rossng

YorickPeterse · 5 years ago

It indeed is difficult to combine static typing, and actors that can receive messages from any other actor. "Session typing" is a way of handling this, but I've yet to see an implementation that isn't overly complex.

Type-checking messages on the sending side is straightforward: just use a generic PID/actor type of some sort. So for example (using Inko [1] syntax here):

    let child: Process!(String) = process.spawn {
      ...
    }

    child.send('hello')

Handling this on the receiving end is more tricky, as a receive could happen anywhere at any time. Imagine somewhere deep down you have a method like this:

    def foo {
      process.receive
    }

How would the compiler know what type `process.receive` is supposed to return? What if you want not just a string, but a specific list of strings?

I'd say that for most languages the best approach is to use some kind of "Any" type for messages, and rely on some form of pattern matching to figure out what you're dealing with. This has the downside of not providing compile-time safety, but it might be good enough. For example, in Inko (this is a new addition not yet released) you would do something like this:

    match(process.receive) {
      'start' -> { start_the_thing }
      'stop' -> { stop_the_thing }
      else -> { oops }
    }

[1]: https://inko-lang.org/

Zalastax · 5 years ago

Yes, it's super difficult to limit the receiving end. If you use a mailbox type, it quickly needs to handle basically all shapes of data. Session types or similar are needed to get all guarantees we want but are super complicated. I looked at this in my MSc thesis "Singly typed actors in Agda": http://studentarbeten.chalmers.se/publication/256251-singly-...

Zalastax commented on Phoenix LiveDashboard github.com/phoenixframewo... · Posted by u/feross

cercatrova · 5 years ago

I like Elixir and all of its infrastructure and libraries, like BEAM and Phoenix, but I could never get used to not having static types. What's the best way to have static types in Elixir?

I have seen in Elixir an implementation of functional programming concepts that might prove useful: https://github.com/witchcrafters/witchcraft. It hasn't been updated since last year so I'm not sure if it still works.

These days I've just started using Rust and actix-web instead, seems a lot faster due to no VM, with static typing, and moreover, algebraic data types. I wonder if I could use another language without ADTs anymore.

Zalastax · 5 years ago

We're working on a gradual type system for Erlang which also works quite okay for Elixir: https://github.com/josefs/Gradualizer/.

Zalastax commented on Landmark computer science proof cascades through physics and math quantamagazine.org/landma... · Posted by u/digital55

umvi · 6 years ago

Slight tangent, but it seems to me that humans are not bounded by the halting problem like computers are. In other words, given a general algorithm to determine whether a program halts, I can always write a program that fools the algorithm. But I can't write a program that fools my brain. Ergo, human brains are not simply biological Turing machines like everyone seems to think?

Zalastax · 6 years ago

A pretty simple program that fools your brain is one testing the Collatz conjecture: https://cs.stackexchange.com/a/44875

Or did you mean something else?