search

ChrisKnott / Algojammer

An experimental code editor for writing algorithms
Apache License 2.0
2.92k stars 107 forks source link

Discussion issue wrt Lamdu #6

Open yairchu opened 5 years ago

yairchu commented 5 years ago

Hi! Algojammer looks very cool!

I've did something similar - using the IDE (+language) I'm developing, Lamdu, in Google Code Jam! Unfortunately GCJ switched to a limited set of languages and my new language isn't one of them so I didn't participate lately..

I'm opening this issue because you wrote "Please use the Issues for starting discussions on ideas you might have for either design, or engineering", and I happen to have a lot of similar ideas - see video: https://youtu.be/skhP6LcbRTs

The video presents a similar approach, but with some differences, like for example Lamdu displays the expression's results inlined the code (under all subexpressions)

ChrisKnott commented 5 years ago

@yairchu thanks for sharing this, I will watch it this evening when I can do it properly.

I was gutted when GCJ changed the platform because it meant I couldn't use Pypy!

ChrisKnott commented 5 years ago

@yairchu I watched it - great work. I am not familiar at all with functional languages but I could follow the structure of the fibonacci example very easily. I will download and try and when I get some time.

I think showing real values right alongside the code is very important. I am thinking you should definitely be able (in algojammer) to ctrl+mouse over variables in the main editor and see the values underneath. This is a good solution to the "bandwidth" problem as you put it.

yairchu commented 5 years ago

I am thinking you should definitely be able (in algojammer) to ctrl+mouse over variables in the main editor and see the values underneath. This is a good solution to the "bandwidth" problem as you put it.

I prefer the annotations everywhere approach - as glancing is much easier and quicker than moving the mouse.

Bret Victor also touches on this topic in his Magic Ink essay::

... physical disadvantages of interaction. The hand is much slower than the eye. ... given the mismatch between mousing and reading speeds, most of her time may be spent navigating, not learning. Further, the user might prefer to learn information while using her hands for other purposes, such as writing or eating or stroking a cat. Each time software demands the user’s hands, this activity must be interrupted. ...

Unless it is enjoyable or educational in and of itself, interaction is an essentially negative aspect of information software. There is a net positive benefit if it significantly expands the range of questions the user can ask, or improves the ease of locating answers, but there may be other roads to that benefit. As suggested by the above redesigns of the train timetable, bookstore, and movie listings, many questions can be answered simply through clever, information-rich graphic design. Interaction should be used judiciously and sparingly, only when the environment and history provide insufficient context to construct an acceptable graphic.

Also see this post by @glench which discusses both options

yairchu commented 5 years ago

And regarding functional programming, specifically pure - Before developing Lamdu, when me and @Peaker were still discussing our vision, I learned Haskell at his encouragement because he thought that it is a perfect match for a live programming system. In the video we mention it as the solution to the live-reloading safety problem. But also, when you display the values of things and the values are immutable, then the model you need to present to the user is much simpler. Of course, learning Haskell wasn't easy (coming from a C++ and Python background) but ultimately it did prove jammable :) and I've identified that most challenges which it presents, like complex type errors, could theoretically be addressed by a good IDE.

ChrisKnott commented 5 years ago

You've convinced me to learn Haskell which is something I've been putting off for a while