4 ms·
Something feels kind of "right" about this in the same sense that machine learning techniques seem to be able to produce correct results. In my "things that exi
by bane 7y ago
Something feels kind of "right" about this in the same sense that machine learning techniques seem to be able to produce correct results. In my "things that exist in Star Trek:TNG that we should be making more progress on" list, I think that how we program is wrong for a great many of use-cases.
In the Star Trek fictional universe, you often see characters programming impossibly complex things very quickly. There's several episodes where a character will create a holodeck simulation simply by describing what they want and providing detail for the parts the computer got wrong until the simulation is more or less what they want.
I feel like in some cases we're starting to figure this out like with GauGAN: https://www.youtube.com/watch?v=p5U4NgVGAwg https://www.youtube.com/watch?v=p5U4NgVGAwg
But what about other cases? Can we just sort of describe the output we want, feed in data and have the computer more or less figure out the set of functions that produces what we're looking for? Such a paradigm would basically allow anybody to make a huge array of one-off, ultra-custom, long-tail, "programs" that solve extremely niche needs without needing to learn all the rigor of actually programming.
- oscargrouch 7y agoI think one programming paradigm that is very underserved is something in the sorts of filters. GPU shaders, Signal Processing or a Nginx filter are all on this line of thinking. We should be more inclined into program things as filters where we manipulate and maybe mutate/transform the data that is passing through that filter, so this could be easily paralelized, cut a lot of expensive CPU branches and where humans and machines could work together making those filters. (It would be much easiar for an AI to infer/learn about how to program like this) In this perspective how we layout and shape the data is much more important.. so if we could create new standards where we can represent anything as a matrix for instance, we could have state-of-the-art engines who would care about scheduling, compilation and paralelization so we could only focus on manipulate and transform data according to the goals of what we are trying to achieve.
- hderms 7y agoI'm inclined to agree but if an nginx filter is like (HttpRequest, HttpResponse) => (HttpRequest, HttpResponse) then aren't we basically saying we like purely problems that can be expressed as compositions of pure functions? Signal programming I have less feelings on
- oscargrouch 7y agoin Nginx HttpRequest/HttpResponse are larger abstractions but the "real fun" will happen at the buffers, where you will end up mostly manipulating bytes on the buffers. The fact that we are creating arbitrary abstractions to represent data and imposing to others is actually the core issue here. Supose we could set up the representation for the most things as a matrix. colors, words, sound, etc.. Than you can filter and process applying linear algebra, ML, etc.. I fell that the way we pack bytes, in arbitrary fashion, by mixing types is a core impediment for us to have a better experience with the program/data duality. But i guess that all of this data centered, AI focused world will make us understand a better way to deal with both programs and data. The need to make our ML agents understand our world will probably change the way we deal with code and data.
- viraptor 7y agoIs the jump to pure functions needed? I mean, nginx will happily include a cache lookup, or a random content in that transformation - that's very much not pure, but often desired.
- oscargrouch 7y agoJust to add to this, more to the spot of your question, i think a no side-effect is often desirable, but i dont think it should be an impediment. As you might need to call another function inside of our procedure that mutates some data. But i think there are some sort of problems we are imposing to ourselves just because we need to deal with the millions possible ways a data could be laid out or modeled based in our type-system centric world. In my perfect world, we should model functions in a DNA fashion, so function is also data, and if is mutable, could even be changed by the data depending of the what is in it. First, we would never have to re-create a function again, and if we do, the data signature would be exactly the same as the other one created before, so we can match in a index for instance. Im more inspired by the way things are done in the natural world, than the way we ended up shaping math (where the concepts of FP are more based on).
- Izkata 7y agoSemi-amusingly, to tie that to GP's comment, the few times they show "real" programming on Star Trek, that's exactly what it looks like - visually chaining transformations together in a directed graph.
- vanderZwan 7y agoNoodle interfaces are really old in terms of GUIs, and have the advantage of being very visual (important for a TV series) so that's not too surprising
- vanderZwan 7y agoYou might be interested in Halide: https://halide-lang.org/ https://halide-lang.org/
- oscargrouch 7y agoYes, this is much more into the spot. But i think will be a long way til we reach tools that are more like that. We are very dependent of the current data formats, software and tools, and going into this direction, would mean to leave a lot of working good stuff behind.
- thristian 7y agoApparently these days Excel has a bunch of features like that for data cleanup. https://www.youtube.com/watch?v=uqV9BlxEG5s https://www.youtube.com/watch?v=uqV9BlxEG5s Horribly patent-encumbered, of course, so you can't use it outside Excel, but still.
- j-pb 7y agoThe reason for why thats possible in StarTrek is pretty simple... P = NP. Heres the evidence: There are no unbreakable cyphers in Startrek, it's merely a matter of time or Datas smarts until whatever species of the weeks encrypted message is broken. Thus, most optimisation and search problems are easily solvable in their universe including automatic program synthesis.