Btw, I sent you an email on a somewhat related topic recently.
3,597 karma · joined December 11, 2011
But sometimes, the logical output format for the response from a command is going to be an image. And sometimes, you'd like to view that inline with your commands in the terminal.
That isn't that radical a suggestion. And it doesn't turn anything into a big old GUI suddenly. :)
xterm actually support Sixel graphics now (although with 16 colors and a configure flag being set). Other terminals also support Sixel graphics, but not all terminal emulators and not the primary ones (Terminal.app, PuTTY, iTerm2, GNOME Terminal, etc).
Sixel and Regis graphics used to be available in actual terminals. I didn't mention Regis graphics in my post, nor did I mention Tektronix graphics, also available in vintage terminals. Both Sixel and Regis graphics were designed by DEC (Digital Equipment Corporation). Sixel was raster-based while Regis was vector-based.
Should we bother with Sixel today? Who knows? But there used to be standards for this sort of thing, but in the actual physical terminals, before we all switched to terminal emulators, most of which stuff with VT100 / VT220 emulation rather than anything too advanced. (Regis was available in the VT240, while Sixel came with the VT340, I think.)
Once the iTerm inline image support is out in an actual release, I have some tools that I'll update to support soon after.
But I have some follow up posts where I'll talk about some of this in-depth. This wasn't a random one-off post that I wrote. :)
That said, that's a great topic to cover! I think GCLI does a pretty good job of command completion. The Lisp Machine did as well. I have friends who love some of the router CLIs, but not sure which one(s).
The next thing I want to write though is about building something that has a command shell UI today and thinking about how to do so in a flexible way that works with multiple output devices.
I also have need of being able to run a program under a harness that, should it crash, lets me get the stack and other details. Bonus points if I get to set up my own code to help decode and pretty print my own data types. But for my purposes, that needs to be something under a more open license which is why I've been working with LLDB to date.
Maybe unikernels like OpenMirage will help make things interesting.
And thanks! The work on Dylan is a lot of fun and keeps me semi-sane by keeping me busy.
The good news is that you can integrate your language-specific tools with Nix as well, such as has been done for Haskell, node.js and other things. (I'm looking at it so that we can integrate our Dylan stuff with it.)
Dylan was one of the original languages to have an infix-syntax with a Lisp / Scheme style macro system. (It is fairly similar to Scheme's syntax rules, but there's an implementation of something more powerful that is used within the compiler but isn't currently available to users.)
The examples that he is demonstrating in the other languages would like this in Dylan:
define macro swap!
{ swap! (?place1:expression, ?place2:expression) }
=>
{ let value = ?place1;
?place1 := ?place2;
?place2 := value; }
end;
define macro each-it
{ each-it (?collection:expression)
?:body
end }
=>
{ for (?=it in ?collection)
?body
end };
end;
My full post as linked above contains links to documentation and other minor details.
My productivity in any of them is usually pretty decent, but it depends more on what I'm doing. In Dylan, I'm often hacking on the compiler or the runtime, so that's harder and slower going than doing some web services in Python, or Javascript for some visualization / UI. C++ varies from fairly easy work to modifying the standard C++ library to add instrumentation hooks, so again, the productivity varies.
> I've previous written about techniques for implementing fast multiple > dispatch using Dylan's type system: > http://www.cs.dartmouth.edu/reports/abstracts/TR2001-404/
We may be coming back to you about this. The dispatch mechanism implemented in Open Dylan is great for 1990s hardware, but less so on today's architectures.
> Limited integer types were ....
One of my next posts (already a good deal written, but a lot to go) is about the "limits of limited types" and looks at how they might be generalized into some more interesting and broadly useful types, namely parametric polymorphism and refinement types. There's some interesting research required to pull that off though.
> - Both type unions and subclass types worked quite well in practice.
Funny ... I forgot to mention subclass types (since they're technically an extension to the language and not part of the core specification).
> Dylan was an exceptionally good language for its time, and I had a ton of fun using it.
I hope that you're on the hackers mailing list still, then. We're going to start some discussions this coming week about the future of Dylan and making some fairly drastic changes to things.
One thing is that we'd like to make it much easier to hack on. The compiler is, as you indicate, fairly complex and it would be great to reduce the build time, add more tests, and in general, make it simpler.
Another is that some parts of Dylan could use an update in keeping with modern research and theory. The type system is an interesting example of this, and that's why I wrote an overview of what we have now. We'd like to increase the knowledge available to the compiler and increase the amount of static checking that can be done. I've already written about adding function types, we want to add parametric polymorphism in a general sense, and there are other things that can still be improved.
There are also just some missing features in the language & implementation like vector math, a solid Unicode definition and implementation. It would be interesting to revisit mutability of some things.
We'll see!
Other than that, they seem to work out fine.
I'm thinking of writing a blog post along the lines of "So, you thought that was a function call, eh?" as Dylan treats everything as a function call at the syntax level, but can go and optimize it into something better. That'll be a pretty complicated post though with a lot of Dylan + generated code examples and I know that I lost some people today by showing C in the type system overview post.
And many of the people involved with that were also involved with the Common Lisp standardization (like David Moon, Scott Fahlman, etc).
Common Lisp is a pretty interesting example, but due to the politics of the various companies involved, the vast amounts of code in each of the various Lisps, and so on, I don't think it is a fair reflection on "designed by committee". It is just what that committee was able to design given the constraints imposed upon them.
In many ways, Dylan was a stripped down and much more minimal Common Lisp, but with aspects of Scheme as well. But Dylan was designed from a green field, while Common Lisp was designed with a number of existing Lisps in mind that each had a stake.
I don't usually bother to post them on HN as I don't have the time to try to get something on the front page (otherwise, no attention). I do post them on r/lisp though or lobste.rs usually.
I've got a couple of posts in draft stage now that I hope to publish this week or next.
For better or worse, I've been pushing Dylan forward heavily over the last few years and am effectively the primary maintainer.
Over the last couple of years, we've made a lot of progress. We've completely revived the documentation from 1990s era FrameMaker files and have it published via a pretty modern system. We've converted from SVN to Git and moved to GitHub. We've done 4 actual releases. We've improved our platform portability. We've provided some basic debugging integration with LLDB. We've fixed some long standing issues in the compiler and tool chain. We've improved the GC integration on all platforms.
But there's a lot to do. We need to fix our Unicode support. We need to improve the type system in at least minor ways if not major ways. We need to improve how parse failures are handled as the errors are not always friendly. We need more libraries. Some of this is really easy, some isn't. But for pretty much everything, there are bite-sized pieces of work that could be done in a couple of hours/week that would lead to significant gains.
I've wanted to just flat out use Dylan for something and have built some small prototypes with it and while they've worked out well enough, the actual projects themselves didn't go anywhere (unrelated to the use of Dylan).
I think this blog post was triggered by a comment that I'd made publicly yesterday that I'm feeling rather discouraged at this point. There was also a private email that I sent to 19 people who have been involved with Dylan recently, but the author of this post didn't get that email.
I view Dylan, not as a language from the past, but as a stepping ladder towards building a better language for the future. We don't have to get bogged down in a lot of the minutiae involved in creating a new language as a lot of the work has been done. We get to focus on things at a different level and those things are just as important. People bring up Goo often when Dylan comes up. Goo is interesting, but the implementation is nothing close to being industrial enough to survive an encounter with the real world.
I came to Dylan because I saw the mess that Scala and other languages were. I didn't like where they were going and following some people on Twitter like https://twitter.com/milessabin and others seems to show that I'm not alone.
And that's why I'll probably keep at it with Dylan. I want a better future and I'm going to keep trying to build it.
It is impossible to know what might have happened if Dylan had kept the s-expression syntax and how that syntax might have evolved. When the switch was made, the language didn't have all of the features that it soon had in the infix syntax. The macro system is just a single example of this. (And Dylan was one of, if not, the first infix language to have a macro system like it does. See http://people.csail.mit.edu/jrb/Projects/dexprs.pdf for a discussion of it and some extensions.)
In the s-expression syntax, you defined a new method by:
(define-method odd? ...)
define method odd? ...
...
end;
define sealed inline method odd? ...
...
end;
Given the history of the last 20+ years since Dylan was created, there are a lot of other things that could've been done differently in the syntax as well:
* Something more terse and compact.
* Not requiring semicolons.
* Using braces or whitespace instead of 'end' statements.
* Stuck with s-expressions since Lisp is more acceptable today (ala Clojure).
* <Your bikeshed here.>
One of the Dylan designers, David Moon, went on design (but not implement) a new language with some differing takes on the syntax: http://users.rcn.com/david-moon/PLOT3/ ... it is interesting, but without an implementation.
There's also the question of whether Dylan failed due to the syntax. There were a lot of factors that led to Dylan not seeing the adoption that was desired:
* Java was a big factor.
* The financial troubles at Apple.
* The collapse of Harlequin. Harlequin had an implementation of Dylan that lives on today as Open Dylan, but had a very advanced IDE on Windows and a pretty solid foundation.
* The business model of Harlequin. Harlequin sold expensive commercial development tools. Lispworks lives on with that business model, but it can't be said to be a massive success.
* The team at CMU switched to Java and away from their Gwydion Dylan implementation. (This was partly due to research dollars.)
And the failings of the Apple Dylan product itself didn't help. It was late to market, buggy, slow, and lacked PowerPC support in the initial release.
Much of the above wasn't due to or related to the syntax.
Yet despite all of that, Dylan still has a special place in my heart and that of many others. We've put out new releases, fixed a lot of bugs, improved platform portability and more in the last few years. Now we're looking towards the future and considering potentially larger changes.
At the time, there was much frustration that Apple
Cambridge spent so much time on their new development
environment, and not as much as we wanted on making
improvements to the Dylan runtime (for example, we hired
Ken because we concluded that Cambridge would not get
around to threads in time to matter to us). That said,
I have nothing but respect for what Apple Cambridge
accomplished.
Given that, it is pretty likely that they lacked a tree-shaker to reduce executable sizes (https://groups.google.com/forum/#!topic/comp.lang.lisp/pspFr...). It is also pretty unlikely that they'd spent enough time on reducing the memory usage and so on. (It is worth noting that even today, Open Dylan hasn't got a tree shaker.)
Bringing up a whole new ecosystem from scratch is hard work!
After his time on Dylan and the Lisp-based Newton at Apple, he went on to work on SK8 (http://en.wikipedia.org/wiki/SK8). If you dig around online, you can find the SK8 sources which were openly published at some point. They aren't that useful now given that they're written for Macintosh Common Lisp on the original Mac OS, but they're definitely interesting to read through.
These days, Mikel is still doing Common Lisp work, but he's also worked on his own language, Bard: https://github.com/mikelevins/bard and he's slowly been working with us in the Open Dylan community to add support back for the old s-expression syntax.
It works for me now at the moment though.
Dylan (http://opendylan.org/) has them, but that's because some of the same people who standardized Common Lisp went on to design Dylan.
We have, in the past had multiple implementations, but due to community size, desire to evolve things, etc, we narrowed it down to Open Dylan being supported and maintained.