96 karma · joined January 31, 2011
You might argue that we should have settled on one of our iterations that was close rather than continuing the search for something better. I can't really disagree with that except to say that each of the latest prototypes was such a large improvement over the last that it felt irresponsible to stop short.
Unfortunately, we've had to find work that would keep a roof over our heads, but that doesn't mean we've buried the work we've done. We've open sourced Light Table and every iteration of Eve that was remotely useful, and we've worked hard to share the most important things we learned on the journey with those who might continue it through essays, speaking, and thorough commenting in the most interesting sections of our code. Nothing would make me happier than having someone take inspiration from our attempt and build the future of programming before I have the financial freedom to return to working on it.
Like everyone at Kodowa, I just want to live in the world where those tools exist. I am sad that we weren't able to complete them in the short time that we had, but I am not sad that we tried.
Literature is accessible and as a society we value the importance of ensuring that everybody has access to the power it provides. You can either believe that programming is for the elite /or/ that it is like literature.
[1] https://gamedev.stackexchange.com/a/23639 [2] https://news.ycombinator.com/item?id=2419347
https://www.youtube.com/watch?v=BT8shMtBZsY
EDIT: Fixed the link
Several version focused on just the keyboard, but we found that most of the things we built using Eve were inherently visual, and as such needed to be tested and interacted with using the mouse. Since we can't eliminate that context shift, we tried doubling down on it.
As a die hard Emacs user, I was shocked by just how competitive the mouse could be in the smalltalk-esque environment we built.
1. We could be more clear about this, but expanding to suit the needs of non-programmers is still very much in the cards. It falls under the umbrella of milestone 3 [1].
2. We're very interested in improving the process of generating UI. To start with, that will mean expanding our library of views (essentially Eve's version of web components) to cover a wider range of common use cases. Beyond that though, HTML is pretty crufty with layers upon layers of of additions and legacy support, it would be very interesting to explore alternative markup models.
3. It certainly is very important. Our model for interacting with the external world is pretty simple. For the most part You can use our first party modules (like `@http` for web requests) to pull the requisite data into Eve where you can transform it into whatever shape is appropriate. For cases where you need entirely new transport systems (like connecting Eve to USB devices), you can create a new module just like the first party ones and side load it in. Since the runtime is currently written in Typescript, that's the language of choice for these extensions. We may support others in the future.
4. For users unfamiliar with HTML and CSS, the best we can do is insulate them from it, as in #2. If it's a subject that personally interests you, I'd love to strike up a conversation on the mailing list about how we can improve the markup process [2].
[1] http://programming.witheve.com/#justataste [2] https://groups.google.com/forum/#!forum/eve-talk
Since we are targeting programmers first right now, it seemed better to focus on other aspects of the editing experience than to try and re-invent document markup to start with. That said, we're not opposed to exploring that possibility down the road. If you have any thoughts on the subject I'd love to strike up a conversation on the mailing list [1].
- Asynchrony is pain-free (no imposed cost, no alternative syntaxes, no callback hell).
- Programs are live by default -- there’s no need manually listen for changes all over the place, and no falling out of sync.
- Programs are easily extensible -- because of the above, anything that conforms to the pattern for a block will get picked up by that block.
- Mocks, shims, and other injection patterns are free -- making testing and experimenting very easy.
- Refactoring is trivial -- If a block changes, I only ever need to change its immediate downstream users to get back to a working state. Eve can find those for me.
- Everything is data, so state sharing is trivial. When a coworker finds a bug in my code they can save their exact state and send it to me with a single command.
- The number of classes of bug are drastically reduced. This doesn’t mean they aren’t occasionally perplexing, but because there are so few ways for a program to fail, I can literally run through a checklist of possibilities while debugging. This is the premise that powers the inspector.
This certainly isn’t a complete list, but it’s a few of my favorite quality of life improvements that I think sets this project apart. If you do get the chance to use it, I’d love to hear your thoughts on what works and what doesn’t for you.
The first is whether a bloom-like language such as Eve is semantically well-suited for game design [1]. Unfortunately, there's not a lot of precedent here yet (it feels like there hasn't been a lot of overlap in interest in game design, datalog, and free time yet). Having used various datalog implementations over the past year though, and I'm convinced that it lends itself very naturally to building a Component Entity System style game engine. datalog's twin benefits of provenance-based debuggability [2] and strong decoupling [3] really help in building and maintaining advanced logic systems. I'm concerned it will have a bit of a learning curve, since we are as a rule not very used to thinking about systems programming this way, but it's certainly felt more intuitive than any other technique I've used in the past once I picked up the mindset for it.
The second is whether a language that lives in a persistent (potentially remote) relational DB is fast enough to run a game in. This is the bigger question for me. We've been doing a lot of research in this field and I'm convinced that for Eve's specific needs we can architect a much faster DB than the general purpose alternatives [4]. That said, even with all of the clever tricks in the book, there's still going to be some amount of overhead compared to working in purpose-built data structures with raw assembly. In cases where we're just not fast enough (either because the optimizations and query planning aren't all there yet or because we've come up against a fundamental design bottleneck) we do have an escape hatch. Through a system called watchers (which enable Eve to I/O with the outside world), it's possible to wire in compute programs written in other languages to do the heavy lifting with a very low latency. The watcher system is probably best conceptualized as a very simple FFI. I think we can get Eve to the point where it handles typical 2D games with aplomb, and for the rest I plan to put a lot of love into the watcher interface with the hopes that it will be fast enough to keep the game logic in Eve and just delegate physics and potentially rendering work to external components.
Anyway, this is still a fair ways off, we're beginning with an MVP and iterating from there. Game development is certainly on my radar though, and I look forward to publishing news about it when Eve is ready to do so. :)
[1] In the current experimental version of Eve, the only exposed query language is our high level search language, which makes very expressive searches like `dishes with eggs and sugar that are savory` trivial, but someone limits the power and scope of a single query. This is built on (and indeed compiles to) a Turing complete sub-language that will look much more familiar to datalog users. We tentatively intend to expose this in the near future.
[2] Given that the underlying graph structure of the program is stored relationally as data (exactly like user data) in Eve, it's very simple to see which sources a view depends on or feeds into, and even to ask complex questions like "when did this value become 10?".
[3] One of my favorite benefits of Eve is that it strongly encourages data composition over functional composition. In effect, If I have a view `active users` over the list of all users `users` and a set of other views dependent on that, they depend only on the data `active users` produces, and not it's implementation whatsoever. `active users` could be replaced in any way that still provides data isomorphically without any of its dependents being aware of the change. Further, even if the data changes non-isomorphically, only it's direct dependents will need to change, rather than having to propagate these changes all the way to the leaves of the system.
[4] To be clear, I don't claim that ours would hold a candle against the 20+ years of experience that GP DBs bring to the table across their whole domain of use cases, just over the small handful that we require.
One of our past examples worked on a similar principle to the SC trigger system [1] but we unfortunately found that it didn't scale as well to larger systems. While it was very easy to write in, it was hard for a stranger to read and intuit the implied data flow. We've had a lot of fun experimenting with different query editors, and I hope to find the time soon to do a more in depth write up on our research.
[1] https://camo.githubusercontent.com/f24714bf6429fa21ca91e4987...
1. A SASS-based theme framework for LT that modularizes all of the widgets and plugins into partials. It's pretty difficult to just dive into the existing CSS and figure out what to change to achieve a particular effect. You're basically required to poke around in the dev inspector.
2. A proper C++ language mode via clang.
Once those are up in several weeks if nobody else has tackled an org-mode implementation I'll probably investigate it. If you have any free time and a desire to learn or use clojure I'd definitely recommend giving it a shot though. The community would definitely appreciate it.
Perhaps more importantly, not trying to restrict plugins to using a particular API has opened LT to integration with the tons of projects already built for the web -- from terminal emulators to emmet.io, integration is very nearly as simple as including the project's source and embedding it's root element into a tab. There's a lot of low hanging fruit at this stage in the game, so I look forward to seeing rapid plugin development in the coming weeks.
[1] Claire - Fuzzy File Finder inspired by ido-mode in emacs (https://github.com/joshuafcole/claire).
[2] Recall - Workspace Persistence Plugin to keep your tabs and tabsets loaded between sessions (https://github.com/joshuafcole/recall).
(Disclaimer: I'm the author of claire)
1. It is _not_ windows only, but the setup.py _is_. Ensure you have the requirements listed along with pyscintilla2 and then execute Stellar.pyw directly (python Stellar.pyw).
2. Very little is currently functional. This appears to mostly be a QT GUI inspired by Gamemaker. Certain aspects of the UI are also currently nonfunctional (e.g. right click menus on folders).
2a. There appear to be some small issues with windowing (e.g. opening a sub-window fullscreen (in this case a sprite) and then opening a new window (in this case an object) leads to the new subwindow being minimized by default.
So, I didn't spend a lot of time reading the code (just enough to get it running actually), but this is definitely more of a call for assistance than a call for beta testers. When finals have wound down I'd like to spend more time with the code and see if this would be a good project for my Christmas pull requests.
As some of the other commenters have mentioned, Game Maker was a great product, but it certainly showing its age. I'd love to see something that improves on what we've learned from Game Maker to help train the next generation.
I desperately want to see this sort of pricing for cluster computing available in the future, when I have the scratch and knowledge necessary to make these ideas into products.
I think that future is worth skipping the occasional movie or meal to pay into, and I'm looking forward to my somewhat unexpected end of year gift.
Have others tried programming a project in one language and transcribing it to another? I work with a fair number of languages, and I find myself falling into a distinctive mindset with each one. Several of the nice idioms I use in one language don't seem like they'd translate well to another. Beyond being an interesting exercise in the mindset behind both languages, are there any benefits to this? It seems like you'd have to cut features you might normally use in the source language until you've reached a union with features from the destination language. It seems like that'd be a pretty tough transition going from a typed and functional language like Haskell to JS.
I usually use three color variables ($background, $foreground, $highlight) every time I start a website and expand sparingly from there. If I wanted my headers to have an indented appearance, I can use a text shadow 1px above the text with `darken($background, 10%)` to choose an appropriate color for the imprint without having to manually keep them in sync. Similarly, if I'm ever working with gradients, say on an alert bar that spans the top of the screen, I can simply use `linear-gradient(top, lighten($highlight, 5%), darken($highlight, 5%))`.
If you'd like an example of a website built this way, we completed enyojs.com in about two weeks thanks entirely to SASS and in part to color variables and functions.
As ever, your mileage may vary and what works wonders for me may not fit your style of design.
http://enyojs.com/ - Check out index.css, line 671. I apologize for the lengthy CSS, we used SASS (which I strongly recommend) and the original plan was to minify the CSS and keep the sass files available publicly, but it seems this has changed since my internship ended.