digitalmars.D - Re: Looking for champion - std.lang.d.lex
- bearophile <bearophileHUGS lycos.com> Oct 23 2010
- bearophile <bearophileHUGS lycos.com> Oct 23 2010
- "Nick Sabalausky" <a a.a> Oct 23 2010
- Bruno Medeiros <brunodomedeiros+spam com.gmail> Nov 24 2010
- Bruno Medeiros <brunodomedeiros+spam com.gmail> Nov 25 2010
- Andrew Wiley <debio264 gmail.com> Nov 24 2010
Walter:As we all know, tool support is important for D's success. Making tools easier to build will help with that. To that end, I think we need a lexer for the standard library - std.lang.d.lex. It would be helpful in writing color syntax highlighting filters, pretty printers, repl, doc generators, static analyzers, and even D compilers.
This is a quite long talk by Steve Yegge that I've just seen (linked from Reddit): http://vimeo.com/16069687 I don't suggest you to see it all unless you are very interested in that topic. But the most important thing it says is that, given that big software companies use several languages, and programmers often don't want to change their preferred IDE, there is a problem: given N languages and M editors/IDEs, total toolchain effort is N * M. That means N syntax highlighters, N indenters, N refactoring suites, etc. Result: most languages have bad toolchains and most IDEs manage very well only one or very few languages. So he has suggested the Grok project, that allows to reduce the toolchain effort to N + M. Each language needs to have one of each service: indenter, highlighter, name resolver, refactory, etc. So each IDE may link (using a standard interface provided by Grok) to those services and use them. Today Grok is not available yet, and its development is at the first stages, but after this talk I think that it may be positive to add to Phobos not just the D lexer, but also other things, even a bit higher level as an indenter, highlighter, name resolver, refactory, etc. Even if they don't use the standard universal interface used by Grok I think they may speed up the development of the D toolchain. Bye, bearophile
Oct 23 2010
bearophile <bearophileHUGS lycos.com> This is a quite long talk by Steve Yegge that I've just seen (linked from Reddit): http://vimeo.com/16069687
Sorry, the Reddit thread: http://www.reddit.com/r/programming/comments/dvd9x/steve_yegge_on_scalable_programming_language/
Oct 23 2010
"bearophile" <bearophileHUGS lycos.com> wrote in message news:i9vs3v$142e$1 digitalmars.com...Walter:As we all know, tool support is important for D's success. Making tools easier to build will help with that. To that end, I think we need a lexer for the standard library - std.lang.d.lex. It would be helpful in writing color syntax highlighting filters, pretty printers, repl, doc generators, static analyzers, and even D compilers.
This is a quite long talk by Steve Yegge that I've just seen (linked from Reddit): http://vimeo.com/16069687 I don't suggest you to see it all unless you are very interested in that topic. But the most important thing it says is that, given that big software companies use several languages, and programmers often don't want to change their preferred IDE, there is a problem: given N languages and M editors/IDEs, total toolchain effort is N * M. That means N syntax highlighters, N indenters, N refactoring suites, etc. Result: most languages have bad toolchains and most IDEs manage very well only one or very few languages. So he has suggested the Grok project, that allows to reduce the toolchain effort to N + M. Each language needs to have one of each service: indenter, highlighter, name resolver, refactory, etc. So each IDE may link (using a standard interface provided by Grok) to those services and use them. Today Grok is not available yet, and its development is at the first stages, but after this talk I think that it may be positive to add to Phobos not just the D lexer, but also other things, even a bit higher level as an indenter, highlighter, name resolver, refactory, etc. Even if they don't use the standard universal interface used by Grok I think they may speed up the development of the D toolchain.
I haven't looked at the video, but that sounds like the direction I've had in mind for Goldie.
Oct 23 2010
On 24/10/2010 00:46, bearophile wrote:Walter:As we all know, tool support is important for D's success. Making tools easier to build will help with that. To that end, I think we need a lexer for the standard library - std.lang.d.lex. It would be helpful in writing color syntax highlighting filters, pretty printers, repl, doc generators, static analyzers, and even D compilers.
This is a quite long talk by Steve Yegge that I've just seen (linked from Reddit): http://vimeo.com/16069687 I don't suggest you to see it all unless you are very interested in that topic. But the most important thing it says is that, given that big software companies use several languages, and programmers often don't want to change their preferred IDE, there is a problem: given N languages and M editors/IDEs, total toolchain effort is N * M. That means N syntax highlighters, N indenters, N refactoring suites, etc. Result: most languages have bad toolchains and most IDEs manage very well only one or very few languages. So he has suggested the Grok project, that allows to reduce the toolchain effort to N + M. Each language needs to have one of each service: indenter, highlighter, name resolver, refactory, etc. So each IDE may link (using a standard interface provided by Grok) to those services and use them. Today Grok is not available yet, and its development is at the first stages, but after this talk I think that it may be positive to add to Phobos not just the D lexer, but also other things, even a bit higher level as an indenter, highlighter, name resolver, refactory, etc. Even if they don't use the standard universal interface used by Grok I think they may speed up the development of the D toolchain. Bye, bearophile
Hum, very interesting topic! A few disjoint comments: (*) I'm glad to see another person, especially one who is "prominent" in the development community (like Andrei), discuss the importance of the toolchain, specificaly IDEs, for emerging languages. Or for any language for that matter. At the beggining of the talk I was like "man, this is spot-on, that's what I've said before, I wish Walter would *hear* this"! LOL, imagine my surprise when I found that Walter was in fact *there*! (When I saw the talk I didn't even know this was at NWCPP, otherwise I might have suspected) (*) I actually thought about some similar ideas before, for example, I thought about the idea of exposing some (if not all) of the functionality of DDT through the command-line (note that Eclipse can run headless, without any UI). And this would not be just semantic/indexer functionality, so for example: * DDoc generation, like Descent had at some point (http://www.mail-archive.com/digitalmars-d-announce puremagic.com/msg02734.html) * build functionality - only really interesting if the DDT builder becomes smarter, ie, does more useful stuff than what it does now. * semantic functionality: find-ref, code completion. (*) I wished I was at that talk, I would have liked to ask and discuss some things with Steve Yegge, particularly his comments about Eclipse's indexer. I become curious for details about what he thinks is wrong about Eclipse's indexer. Also, I wonder if he's not conflating "CDT's indexer" with "Eclipse indexer", because actually there is no such thing as a "Eclipse indexer". I'm gonna take a better look at the comments for this one. (*) As for Grok itself, it looks potentially interesting, but I still have only a very vague impression of what it does (let alone *how*). -- Bruno Medeiros - Software Engineer
Nov 24 2010
On 24/11/2010 18:48, Andrew Wiley wrote:On 24/10/2010 00:46, bearophile wrote: Walter: As we all know, tool support is important for D's success. Making tools easier to build will help with that. To that end, I think we need a lexer for the standard library - std.lang.d.lex. It would be helpful in writing color syntax highlighting filters, pretty printers, repl, doc generators, static analyzers, and even D compilers. This is a quite long talk by Steve Yegge that I've just seen (linked from Reddit): http://vimeo.com/16069687 I don't suggest you to see it all unless you are very interested in that topic. But the most important thing it says is that, given that big software companies use several languages, and programmers often don't want to change their preferred IDE, there is a problem: given N languages and M editors/IDEs, total toolchain effort is N * M. That means N syntax highlighters, N indenters, N refactoring suites, etc. Result: most languages have bad toolchains and most IDEs manage very well only one or very few languages. So he has suggested the Grok project, that allows to reduce the toolchain effort to N + M. Each language needs to have one of each service: indenter, highlighter, name resolver, refactory, etc. So each IDE may link (using a standard interface provided by Grok) to those services and use them. Today Grok is not available yet, and its development is at the first stages, but after this talk I think that it may be positive to add to Phobos not just the D lexer, but also other things, even a bit higher level as an indenter, highlighter, name resolver, refactory, etc. Even if they don't use the standard universal interface used by Grok I think they may speed up the development of the D toolchain. Bye, bearophile From watching this, I'm reminded that in the Scala world, the compiler can be used in this way. The Eclipse plugin for Scala (and I assume the Netbeans and IDEA plugins work similarly) is really just a wrapper around the compiler because the compiler can be used as a library, allowing a rich IDE with minimal effort because rather than implementing parsing and semantic analysis, the IDE team can just query the compiler's data structures.
Interesting, very wise of them to do that. But not very surprising, Scala is close to the Java world, so they (the Scala people) must have known how important it would be to have the best toolchain possible, in order to compete (with Java, JDT, also Visual Studio, etc.). -- Bruno Medeiros - Software Engineer
Nov 25 2010
--001636c5b83f33f5290495d0ee9d Content-Type: text/plain; charset=ISO-8859-1On 24/10/2010 00:46, bearophile wrote:Walter: As we all know, tool support is important for D's success. Making toolseasier to build will help with that. To that end, I think we need a lexer for the standard library - std.lang.d.lex. It would be helpful in writing color syntax highlighting filters, pretty printers, repl, doc generators, static analyzers, and even D compilers.
This is a quite long talk by Steve Yegge that I've just seen (linked from Reddit): http://vimeo.com/16069687 I don't suggest you to see it all unless you are very interested in that topic. But the most important thing it says is that, given that big software companies use several languages, and programmers often don't want to change their preferred IDE, there is a problem: given N languages and M editors/IDEs, total toolchain effort is N * M. That means N syntax highlighters, N indenters, N refactoring suites, etc. Result: most languages have bad toolchains and most IDEs manage very well only one or very few languages. So he has suggested the Grok project, that allows to reduce the toolchain effort to N + M. Each language needs to have one of each service: indenter, highlighter, name resolver, refactory, etc. So each IDE may link (using a standard interface provided by Grok) to those services and use them. Today Grok is not available yet, and its development is at the first stages, but after this talk I think that it may be positive to add to Phobos not just the D lexer, but also other things, even a bit higher level as an indenter, highlighter, name resolver, refactory, etc. Even if they don't use the standard universal interface used by Grok I think they may speed up the development of the D toolchain. Bye, bearophile
From watching this, I'm reminded that in the Scala world, the compiler can
and IDEA plugins work similarly) is really just a wrapper around the compiler because the compiler can be used as a library, allowing a rich IDE with minimal effort because rather than implementing parsing and semantic analysis, the IDE team can just query the compiler's data structures. --001636c5b83f33f5290495d0ee9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">On 24/10/2010 00= :46, bearophile wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Walter:<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> As we all know, tool support is important for D's success. Making tools= easier<br> to build will help with that.<br> <br> To that end, I think we need a lexer for the standard library - std.lang.d.= lex.<br> It would be helpful in writing color syntax highlighting filters, pretty<br=
</blockquote> <br></div> This is a quite long talk by Steve Yegge that I've just seen (linked fr= om Reddit):<br> <a href=3D"http://vimeo.com/16069687" target=3D"_blank">http://vimeo.com/16= 069687</a><br> <br> I don't suggest you to see it all unless you are very interested in tha= t topic. But the most important thing it says is that, given that big softw= are companies use several languages, and programmers often don't want t= o change their preferred IDE, there is a problem: given N languages and M e= ditors/IDEs, total toolchain effort is N * M. That means N syntax highlight= ers, N indenters, N refactoring suites, etc. Result: most languages have ba= d toolchains and most IDEs manage very well only one or very few languages.= <br> <br> So he has suggested the Grok project, that allows to reduce the toolchain e= ffort to N + M. Each language needs to have one of each service: indenter, = highlighter, name resolver, refactory, etc. So each IDE may link (using a s= tandard interface provided by Grok) to those services and use them.<br> <br> Today Grok is not available yet, and its development is at the first stages= , but after this talk I think that it may be positive to add to Phobos not = just the D lexer, but also other things, even a bit higher level as an inde= nter, highlighter, name resolver, refactory, etc. Even if they don't us= e the standard universal interface used by Grok I think they may speed up t= he development of the D toolchain.<br> <br> Bye,<br> bearophile<br> </blockquote> </blockquote></div><br><div>From watching this, I'm reminded that in th= e Scala world, the compiler can be used in this way. The Eclipse plugin for= Scala (and I assume the Netbeans and IDEA plugins work similarly) is reall= y just a wrapper around the compiler because the compiler can be used as a = library, allowing a rich IDE with minimal effort because rather than implem= enting parsing and semantic analysis, the IDE team can just query the compi= ler's data structures.</div> --001636c5b83f33f5290495d0ee9d--
Nov 24 2010