Live data from Hacker News

Show HN: DeepUI Programming Studio – A different approach to programming

deepui.io

61–70 of 136 posts

Re: Show HN: DeepUI Programming Studio – A different approach to programming

#61
post #29

Earlier quoted context omitted.

Just recently we had the author of Octave, thinking about giving up development, because of exactly this problem, so excuse me if you don't think my remark was mature enough. https://news.ycombinator.com/item?id=13603575 Do you at least pay for the distribution you use? I do.

Your comment attacked an entire user base, their collective crime being that they don't share your particular (weak) moral values about the distribution of software intended for use on the Linux desktop. Worst of all, you now insinuate that a problem suffered by one author of one application that is used on the GNU/Linux desktop is a problem for all. Not everybody can "pay for" (support monetarily) free software. I p…

I wish this wasn't a deeply nested comment attached to a somewhat unrelated article because I think this is a really interesting discussion that deserves its own thread. There are some genuinely interesting ethical questions here.

FWIW, I feel that people who have the money to do so should support the artists, engineers, and other folks who create the things they use and enjoy. I buy books rather than borrow them from the library for this reason: I want to give the authors more money, so that hopefully they'll keep writing the books I love to read.

I know not everyone shares my perspective, though.

Re: Show HN: DeepUI Programming Studio – A different approach to programming

#63

Some feedback on the website: IMO, it's obnoxious and disrespectful to play full screen video like you're doing. That just made me close it immediately and leave after reading through the text. Considering the complexity involved in developing a an advanced IDE or similar, have you considered publishing an open source community version? Similar to JetBrain with IntelliJ. They seem to be doing great. Since we're on th…

I actually disagree about the fullscreen video. Why would I ever want to watch video not fullscreen? Vimeo also behaves like this on mobile and it's far superior to Youtube, which often totally hides the fullscreen button.

>Why would I ever want to watch video not fullscreen?

Because you're doing other stuff while listening to the audio.

>Youtube, which often totally hides the fullscreen button.

It's in the bottom right.

Re: Show HN: DeepUI Programming Studio – A different approach to programming

#65

I worked on Accelsor which is a tactile-spatial programming language, and I think the ideas here are actually really good (so don't let HN haters get you down). Ultimately work like this though leads to needing to reinvent all of programming (unfortunately) for instance, I'm now having to build a graph database to handle Turing Complete systems that are being collaborated on in realtime (see http://gun.js.org ). So p…

I still have to eat though :)

Re: Show HN: DeepUI Programming Studio – A different approach to programming

#66
post #56

Earlier quoted context omitted.

Back in the late 80s/early 90s after I learned C, I remember wondering in awe how in the world compiler optimizations worked. But they do the same thing, they build (often intricate) dependency graphs. In the end, if a human can translate between imperative and functional programming, then there's no reason a machine can't. I think the move towards functional programming, and putting the onus on developers to do the…

I enjoy functional programming because it's easier to reason about the code. Often it's easier to write it, but it's true that sometimes it's harder. I find that when I need to read and understand that code later, though, functional programming is usually a win. The same factors that make it sometimes harder to write - state must be passed around explicitly, idiomatic control flow constructs are less general, mutabil…

Ya I'm not knocking functional programming (I prefer it as well) but I find it frustrating that so much of it breaks from the conventions we are accustomed to in C-style languages. Others around me can’t easily grok what I’ve written. Functional logic is the solution to the problem being tackled, but currently it has to be generated by hand, often in a write-only style. We are effectively writing functional assembly.

Take Swift for example (neat handle by the way!), it's probably the most pedantic language I have ever used. Personally I don't believe that it can be written without compiler assistance, especially when dealing with real-world data like JSON where pretty much anything can be optional. It's a language that makes me feel like anything I try will be rejected outright. It gets us halfway to functional programming with "let" and passing variables as immutable to callbacks by default, but then breaks too far from the contextual assumptions that we've built up in languages like C and javascript to "just work" when we try things. I feel misgivings about Rust for precisely these same reasons.

At this point the only functional language I've found that's somewhat approachable from an imperative background is probably ClojureScript, which is basically just Scheme running in one-shot mode, switching to Javascript to get the next piece of data instead of forcing the developer to use monads. It’s not even close to how I would design a functional language, but it’s substantially more approachable than say, Haskell.

I’m to the point where I am thinking about rejecting all of this and programming in synchronous shell-scripting style in something like Go, to get most of the advantages of Erlang without the learning curve. If languages aren’t purely functional, then I don’t believe they offer strong enough guarantees for the pain of using them. And purely functional languages can’t offer the leverage that scripting can, because they currently can’t be transpiled from imperative ones. It’s trivial to convert from functional to imperative, but basically impossible to go the other direction. They do nothing for you regarding the difficult step (some may argue the only step) of translating human ideas to logic. I think that’s the real reason that they haven’t achieved mainstream adoption.

Re: Show HN: DeepUI Programming Studio – A different approach to programming

#69

Earlier quoted context omitted.

> is there a well-defined ordering? > a = 0; b = 1; c = a + b; In pure functional languages, these expressions form a dependency graph and the interpreter or compiler may choose an ordering and may cache intermediate results We may even represent the program itself as a graph, just like you suggest with ML programs, but this is a general purpose program Obviously we can't do this in imperative languages. I think pure…

Back in the late 80s/early 90s after I learned C, I remember wondering in awe how in the world compiler optimizations worked. But they do the same thing, they build (often intricate) dependency graphs. In the end, if a human can translate between imperative and functional programming, then there's no reason a machine can't. I think the move towards functional programming, and putting the onus on developers to do the…

> I think the move towards functional programming, and putting the onus on developers to do the mental elbow grease of converting what are largely macro-style tasks (do this, do that) into functional code (feed this transform into this one) has done a great disservice to software engineering, especially with respect to productivity.

I think you've got this exactly backwards. Functional programming lets you think at a higher level of abstraction (data flow) than imperative programming (control flow). The compiler then applies elbow grease to translate your high-level data flow transformations into low-level control flow constructs.

Let's translate your statement back a generation and see how it sounds: "I think the move towards structured programming, and putting the onus on developers to do the mental elbow grease of converting what are largely assembly-level tasks (branch, copy, add a value to a register) into structured code (if, while, for) has done a great disservice to software engineering, especially with respect to productivity."

Hopefully you can understand how silly that seems to a modern programmer.

Re: Show HN: DeepUI Programming Studio – A different approach to programming

#70

There is a deeper question undercutting this project (and Bret Victor's Drawing Dead Fish talk and related approaches). That question is: how can we represent computation in an intuitive and scalable way? Conventional programming languages is one answer. They associate programs with text. Some believe there is another way, by associating programs with diagrams. A more abstract example: machine learning associates pro…

> We don't, however, try to understand what "thought" is, and work backwards to form a representation of it. Yes, we do. ML/AI is a moving target that literally represents the current SOTA in doing just that, and even symbolic logic itself is the outcome of an older, a priori , way of doing that. Actually, analytic diagrams are also an outcome of one approach to that. So, all programming methods you mention come from…

Perhaps I spoke too broadly. You're right, many disciplines try to understand thought. From CS to philosophy to neuroscience to psychology etc.

My real point is that thought is not visual or textual. Those things are simply ways of transmitting thoughts. When I have a thought, and I write it down, and you read it, I am simply hoping you are now having a thought related to the one I had. Some interaction in your brain is similar to the one in mine, when I had the thought. Civilization has spent a lot of time in mechanisms that correlate thoughts between people. Hence, language. Hence literacy. Etc.

Now we are trying to create a shared language between humans and computers, where we both understand each other with minimal effort.

Post reply on HN