My argument in that case is that grep is insufficiently expressive for the modern world.
The UNIX "everything is a file, and those files are all ^J delimited records" is a hack for a world when record based file systems were seen as overcomplicated (because, well, MULTICS style files were overcomplicated). It's time to move up.
It might seem antiquated and weird to us nowadays, but emacs-lisp is actually fairly typical of the dialects of its day. It's day was just the late-70s/early-80s. Scheme and Common Lisp did a lot to modernize Lisp, and they just happened to be the first popular dialects on commodity machines so it's easy to forget that Lisp predates all computing paradigms and has given them all a shot at one point or another.
I ignored it (see my user name, I don't have a fancy slashdot badge so I fly under the radar... or remain unknown or something clever) -- The Register claimed to have confirmed it with Stanford... through twitter. I personally prefer having things other than 100 character messages for sources.
Stories posted after around 7 or 8 eastern time tend to not see many comments, and I felt it was a better decision to run it in the morning where everyone would see it at the start of their day instead of hiding out under the overnight stories (and gone from the main page shortly thereafter).
It looks like I maybe should have posted it earlier and not made an obscure Lisp reference (discoverer vs inventor) in the title. Oh well. You can't make everyone happy...
Techcruch posted a story based on a single tweet that was linked from Hacker News. It was closer to eight p.m. EDT before there was solid evidence that it was, indeed, quite true. At that point... it seemed more respectful to hold off until the morning rather than posting immediately.
Ok, we were actually having an argument about different things;)
ELF is a separate concern — I do agree that it would be nice if binaries from other languages were encapsulated in ELF more (Guile Scheme has made motions toward this). You can already do things like dump Common Lisp binaries that include a minimal C bootstrap runtime. Getting more than a main entry point so that they can be run as programs, however, is one of those really difficult things — the C language ABI is basically mandated.
When I watched the talk I noticed the multi-language goals of Chibi Scheme seem to overlap with those of Guile — is there any reason there isn't collaboration? Guile did recently get a fancy new VM (with a direct compiler, wingo has made grumblings about rectifying that...), and good progress has been made toward getting Emacs-Lisp running on it (it can load subr.el and run dunnet at least, I've seen it with my own eyes). It seems like getting multiple languages to interoperate other is going to be a huge challenge (you know, with that whole type system mismatch thing...); #nil being "beautiful in an ugly way" is one such example ('tho BT, the one working on the elisp compiler right now, isn't particularly fond of it). I'm not sure what the intentions for Chibi Scheme are wrt interoperability — I noticed you mentioned that the bash compiler probably won't be able to call Scheme?
And, thanks for stopping by and commenting! I hope my summary didn't misrepresent your presentation any; if it did let me know and I'll make the appropriate edits for accuracy. (I noticed that I managed to skip over the numeric tower stuff so at least one slight revision is already needed).
The common ABI of all platforms in wide use today were designed only with C in mind (extended slightly, in an incompatible manner, to support C++). If even C++ cannot link directly with C, why would Ocaml et al have to? These things have their own internal binary interfaces and so I don't see what the problem is. The lack of a shared library format?
The ABI defines how data is represented at the machine level, how functions are called, etc. The C ABI is insufficient for representing languages like Common Lisp, OCaml, Haskell,... for a number of reasons. One is that the calling convention is not powerful enough for them, another is that it is difficult to express types from these languages in terms of the C ABI. It could probably be done, but then you'd need a lot of run time support and it would be really difficult for a human to actually call things from C. Then you have things like the stack -- SML/NJ at least doesn't even use the C control stack (opting instead to keep a list of activation frames on the heap -- this makes call/cc O(1) instead of O(N) proportional to the length of the activation chain).
As long as they provide a main entry point does it really matter?
Adhering to the platform ABI makes little sense -- the "platform" ABI on e.g. UNIX is meant for C programs and is not expressive enough for other languages (keep in mind the only types in C are bytes, half-words, words, double words,...).
Well then, I feel dumb. FWIW everyone else missed the typo too... if you tag a story typo it makes a jabber bot yell at me so I look harder at the text to find things like that.
Not to nit too much, but I am fairly certain (I may have secret inside information OR: planet lisp) that ITA moved to a mixture of SBCL and Clozure CL, with the main scheduling engine running on SBCL.
Of course, Google will probably just fire everyone, rewrite it in Java, and cause the entire airline industry scheduling infrastructure to collapse...
And then the performance of the code I'd written (pretty straightforwardly) was abysmal.
Well, it's true that Guile has horrible performance, even compared to other Scheme implementations'; but then, JavaScript had pretty horrible performance until Google and Mozilla started putting serious effort into speeding it up.
That is using Guile 1.8.x; Guile 2.0 features a brand new VM that performs much better (IIRC, beating Chicken in some cases).
Here is an idea instead of adding Lua support, I don't know, USE LUA... Wow what a concept!
Julien Danjou (of awesome fame, a high profile Lua using application), explains it fairly well. Basically, the Lua API is a huge pain to use and contorts the program around it making anything but the most trivial uses nearly impossible.
Lua and a language and basic extension library, however, is eminently usable by non-programmers. This makes it a fairly small task to implement the user facing parts of Lua. This was actually mostly done during GSoC 2010, but like most GSoC projects the student kind of trailed off once he passed the final evaluation and hasn't made too much effort at merging it into master. There was, however, chatter on the Guile IRC channel today about finally getting around to doing that (there is finite maintainer time and everyone has a day job and whatnot).
Thanks for the heads up -- this was a "breaking news run it quickly!" situation and I managed to write down the post time instead of the quake time without noticing.
New hardware has bought us the ability to use managed code for most (not all) software. Isn't this much better than expecting every programmer to perfectly manage his memory every time? Just wait a couple more years and we won't be feeling the hardware pinch even on phones.
Personally I hope new machines start learning from the past and implementing processor instructions to make GC easier and support things like runtime type checking. ARM has ThumbEE which is definitely a step in the right direction. Basically, I see the proliferation of "Managed" run time environments as a consequence of computer architectures remaining dangerous to write code for — we can pack a lot of transistors onto a die nowadays so why not use some of that space for features people have been implementing in software for decades?
Moby is a limited educational environment that does not expose the full Scheme language and integrates poorly with the rest of the environment (you can't e.g. call Java protocols directly from Scheme... which could be problematic). Kawa, OTOH, compiles to Java bytecode that can be transformed into DEX just like any normal Java. Since it compiles to Java you can directly call of the Android protocols making it actually useful. The only problem is that getting it into the build chain is a bit mystifying at least for this Schemer (ant is not really what I would consider intuitive). Java protocols also tend to not fit very cleanly into traditional Scheme program structure.
My hope is that the App Inventor source will have good examples of using the Android protocols in a Schemey style and especially how to sanely build programs with the Kawa library.
None are officially supported, but there has been work done to support at least Android and iOS. I think the lack of a WP7 port is more Elop running the company into a ground crap (I mean, if you could write a Qt app for Symbian or Meego and port it to the new Microsoft-Nokia devices...) so that may be rectified. Personally I think WP7 is doomed within a few years, and iOS not too long after that (be warned, I am also a Free Software nut so...).
There are other ways than rewriting the same thing several times. You don't even have to use C or C++. You already need at least different layouts for desktops, tablets (really just desktops without the input devices), and phones (or: tiny screen devices) for an application to be usable. So what is the advantage of using an overgrown design-by-committee hack that has repeatedly rejected all innovation in the name of compatibility? It doesn't help that HTML5 is probably more difficult to implement than the entire rest of an operating system.
Ah, I hadn't checked the situation in a while and that was a pleasant surprise. It still looks like the interface is limited to more or less embedding snippets of HTML5 into the interface. Which is pretty powerful, but Firefox still has the advantage here (e.g. the entire XUL toolkit is available). There's also the theoretical advantage of Firefox extensions being applicable to most any xulrunner app (e.g. a lot of extensions work work with Conkeror), but in practice it doesn't always work out so well. Personally I'm not a huge fan of HTML5 (it looks impossible to implement from scratch...) and so having access to a (ever so slightly) saner toolkit for UI programming is handy. But I still write elisp regularly and that language certainly isn't going to win any prizes for consistency and sanity any time soon (sometimes popularity wins, eh).
It's still nice to see more browsers taking advantage of that little javascript environment they have to permit interface extensions nowadays.
Part of it is that you can write Firefox extensions in Javascript whereas Chromium extensions require you to dive into C++ which is a pretty horrid language (I know, I spent years using it).
Slashdot Mirror
My argument in that case is that grep is insufficiently expressive for the modern world.
The UNIX "everything is a file, and those files are all ^J delimited records" is a hack for a world when record based file systems were seen as overcomplicated (because, well, MULTICS style files were overcomplicated). It's time to move up.
Jack Wagner told me we fell back two times...
(or: thanks for catching my arithmetic error ...)
It might seem antiquated and weird to us nowadays, but emacs-lisp is actually fairly typical of the dialects of its day. It's day was just the late-70s/early-80s. Scheme and Common Lisp did a lot to modernize Lisp, and they just happened to be the first popular dialects on commodity machines so it's easy to forget that Lisp predates all computing paradigms and has given them all a shot at one point or another.
I ignored it (see my user name, I don't have a fancy slashdot badge so I fly under the radar... or remain unknown or something clever) -- The Register claimed to have confirmed it with Stanford... through twitter. I personally prefer having things other than 100 character messages for sources.
Stories posted after around 7 or 8 eastern time tend to not see many comments, and I felt it was a better decision to run it in the morning where everyone would see it at the start of their day instead of hiding out under the overnight stories (and gone from the main page shortly thereafter).
It looks like I maybe should have posted it earlier and not made an obscure Lisp reference (discoverer vs inventor) in the title. Oh well. You can't make everyone happy...
Techcruch posted a story based on a single tweet that was linked from Hacker News. It was closer to eight p.m. EDT before there was solid evidence that it was, indeed, quite true. At that point... it seemed more respectful to hold off until the morning rather than posting immediately.
Ok, we were actually having an argument about different things ;)
ELF is a separate concern — I do agree that it would be nice if binaries from other languages were encapsulated in ELF more (Guile Scheme has made motions toward this). You can already do things like dump Common Lisp binaries that include a minimal C bootstrap runtime. Getting more than a main entry point so that they can be run as programs, however, is one of those really difficult things — the C language ABI is basically mandated.
When I watched the talk I noticed the multi-language goals of Chibi Scheme seem to overlap with those of Guile — is there any reason there isn't collaboration? Guile did recently get a fancy new VM (with a direct compiler, wingo has made grumblings about rectifying that...), and good progress has been made toward getting Emacs-Lisp running on it (it can load subr.el and run dunnet at least, I've seen it with my own eyes). It seems like getting multiple languages to interoperate other is going to be a huge challenge (you know, with that whole type system mismatch thing...); #nil being "beautiful in an ugly way" is one such example ('tho BT, the one working on the elisp compiler right now, isn't particularly fond of it). I'm not sure what the intentions for Chibi Scheme are wrt interoperability — I noticed you mentioned that the bash compiler probably won't be able to call Scheme?
And, thanks for stopping by and commenting! I hope my summary didn't misrepresent your presentation any; if it did let me know and I'll make the appropriate edits for accuracy. (I noticed that I managed to skip over the numeric tower stuff so at least one slight revision is already needed).
The common ABI of all platforms in wide use today were designed only with C in mind (extended slightly, in an incompatible manner, to support C++). If even C++ cannot link directly with C, why would Ocaml et al have to? These things have their own internal binary interfaces and so I don't see what the problem is. The lack of a shared library format?
The ABI defines how data is represented at the machine level, how functions are called, etc. The C ABI is insufficient for representing languages like Common Lisp, OCaml, Haskell, ... for a number of reasons. One is that the calling convention is not powerful enough for them, another is that it is difficult to express types from these languages in terms of the C ABI. It could probably be done, but then you'd need a lot of run time support and it would be really difficult for a human to actually call things from C. Then you have things like the stack -- SML/NJ at least doesn't even use the C control stack (opting instead to keep a list of activation frames on the heap -- this makes call/cc O(1) instead of O(N) proportional to the length of the activation chain).
As long as they provide a main entry point does it really matter?
Request granted (at least for calling C). SML has an even nicer FFI and most certainly builds native executables.
Adhering to the platform ABI makes little sense -- the "platform" ABI on e.g. UNIX is meant for C programs and is not expressive enough for other languages (keep in mind the only types in C are bytes, half-words, words, double words, ...).
Thanks for noticing, I've fixed the link.
Well then, I feel dumb. FWIW everyone else missed the typo too... if you tag a story typo it makes a jabber bot yell at me so I look harder at the text to find things like that.
Thanks for catching the typo!
Not to nit too much, but I am fairly certain (I may have secret inside information OR: planet lisp) that ITA moved to a mixture of SBCL and Clozure CL, with the main scheduling engine running on SBCL.
Of course, Google will probably just fire everyone, rewrite it in Java, and cause the entire airline industry scheduling infrastructure to collapse...
And then the performance of the code I'd written (pretty straightforwardly) was abysmal.
Well, it's true that Guile has horrible performance, even compared to other Scheme implementations'; but then, JavaScript had pretty horrible performance until Google and Mozilla started putting serious effort into speeding it up.
That is using Guile 1.8.x; Guile 2.0 features a brand new VM that performs much better (IIRC, beating Chicken in some cases).
Here is an idea instead of adding Lua support, I don't know, USE LUA... Wow what a concept!
Julien Danjou (of awesome fame, a high profile Lua using application), explains it fairly well. Basically, the Lua API is a huge pain to use and contorts the program around it making anything but the most trivial uses nearly impossible.
Lua and a language and basic extension library, however, is eminently usable by non-programmers. This makes it a fairly small task to implement the user facing parts of Lua. This was actually mostly done during GSoC 2010, but like most GSoC projects the student kind of trailed off once he passed the final evaluation and hasn't made too much effort at merging it into master. There was, however, chatter on the Guile IRC channel today about finally getting around to doing that (there is finite maintainer time and everyone has a day job and whatnot).
Thanks for the heads up -- this was a "breaking news run it quickly!" situation and I managed to write down the post time instead of the quake time without noticing.
That was me being a dolt (does anyone want some habañero dip while we're at it?). Move along, nothing to see here.
New hardware has bought us the ability to use managed code for most (not all) software. Isn't this much better than expecting every programmer to perfectly manage his memory every time? Just wait a couple more years and we won't be feeling the hardware pinch even on phones.
Personally I hope new machines start learning from the past and implementing processor instructions to make GC easier and support things like runtime type checking. ARM has ThumbEE which is definitely a step in the right direction. Basically, I see the proliferation of "Managed" run time environments as a consequence of computer architectures remaining dangerous to write code for — we can pack a lot of transistors onto a die nowadays so why not use some of that space for features people have been implementing in software for decades?
Moby is a limited educational environment that does not expose the full Scheme language and integrates poorly with the rest of the environment (you can't e.g. call Java protocols directly from Scheme... which could be problematic). Kawa, OTOH, compiles to Java bytecode that can be transformed into DEX just like any normal Java. Since it compiles to Java you can directly call of the Android protocols making it actually useful. The only problem is that getting it into the build chain is a bit mystifying at least for this Schemer (ant is not really what I would consider intuitive). Java protocols also tend to not fit very cleanly into traditional Scheme program structure.
My hope is that the App Inventor source will have good examples of using the Android protocols in a Schemey style and especially how to sanely build programs with the Kawa library.
None are officially supported, but there has been work done to support at least Android and iOS. I think the lack of a WP7 port is more Elop running the company into a ground crap (I mean, if you could write a Qt app for Symbian or Meego and port it to the new Microsoft-Nokia devices...) so that may be rectified. Personally I think WP7 is doomed within a few years, and iOS not too long after that (be warned, I am also a Free Software nut so ...).
There are other ways than rewriting the same thing several times. You don't even have to use C or C++. You already need at least different layouts for desktops, tablets (really just desktops without the input devices), and phones (or: tiny screen devices) for an application to be usable. So what is the advantage of using an overgrown design-by-committee hack that has repeatedly rejected all innovation in the name of compatibility? It doesn't help that HTML5 is probably more difficult to implement than the entire rest of an operating system.
Ah, I hadn't checked the situation in a while and that was a pleasant surprise. It still looks like the interface is limited to more or less embedding snippets of HTML5 into the interface. Which is pretty powerful, but Firefox still has the advantage here (e.g. the entire XUL toolkit is available). There's also the theoretical advantage of Firefox extensions being applicable to most any xulrunner app (e.g. a lot of extensions work work with Conkeror), but in practice it doesn't always work out so well. Personally I'm not a huge fan of HTML5 (it looks impossible to implement from scratch...) and so having access to a (ever so slightly) saner toolkit for UI programming is handy. But I still write elisp regularly and that language certainly isn't going to win any prizes for consistency and sanity any time soon (sometimes popularity wins, eh).
It's still nice to see more browsers taking advantage of that little javascript environment they have to permit interface extensions nowadays.
I guess I should have written Emacs/vim-like instead ;)
Also: the horror, oh the horror.
Part of it is that you can write Firefox extensions in Javascript whereas Chromium extensions require you to dive into C++ which is a pretty horrid language (I know, I spent years using it).