5 ms·

Why do you think that those doing research inside Typesafe are steering the language in a direction that is user hostile? From what I have seen the effort appe

Why do you think that those doing research inside Typesafe are steering the language in a direction that is user hostile? From what I have seen the effort appears to be more focused on simplifying the language in order to make it easier to use: http://www.infoq.com/presentations/data-types-issues http://www.infoq.com/presentations/data-types-issues

laureny 13y ago
> Why do you think that those doing research inside Typesafe are steering the language in a direction that is user hostile? Macros come to mind. It's a feature that completely circumvented the SIP (and was later retrofitted into it), which is still heavily controversial inside scala-internals to the point that we're still not sure whether they will ever be officially part of scalac and which will probably never be used by more than a very tiny minority of Scala users. They took months of work (which could have been put to better use, e.g. IDE support), mostly done with little transparency and which started generating papers for conferences before the project was remotely close to a prototype. This kind of project would never have seen the light of day if the language was led by a company focused primarily on users and sound engineering.
- necubi 13y ago
  I can personally vouch for the value of Scala macros, which I feel really transform the language. With macros (at least with macro-paradise) I can metaprogram Scala more powerfully than Ruby, while retaining typesafety. Scala + macros is a pretty remarkable language, being very dynamic while also being very safe. The macros support included in 2.10 is pretty basic and difficult to use, but with annotation macros and quasiquotation in macro-paradise those issues are eliminated. And who are you to determine what gets priority amongst open-source devs? Does macro support make scala a worse language? Are you upset that an unpaid researcher (not an employee of typesafe) decided to spend time implementing the macro system instead of working on the IDE?
- modersky 13y ago
  Macros were not done at Typesafe, but by Eugene Burmako, who's a grad student at EPFL. Grad students do new stuff, and they publish about it, IDE improvements are typically not their piece of cake (Typesafe does have a very capable team working on IDEs). As you imply, macros are labelled experimental, which means that you have to enable them explicitly. Having experimental features is Scala's way of reconciling a vibrant open source community with the stability needed for enterprise use. Needless to say, we do not recommend use of experimental features in enterprises. They are good for playing around with interesting new concepts and sometimes they do lead to something which is a win, such as the beautiful async/await library that will ship in 2.11.
- adriaanm 13y ago
  Macros were not developed by Typesafe, though we do try to help out. Also, macros are clearly marked experimental -- a compromise for a language co-developed by researchers (EPFL has invested over a decade in Scala) and industry. We (Typesafe) are using macros in our own projects, so the small investment in helping out with their development has largely been paid off because they essentially give us a lightweight compiler plugin mechanism. Users need not be aware macros underly, say scala-async.
- deleted 13y ago
  [deleted]
- eugene_burmako 13y ago
  Hi, that's me who's doing macros for Scala. Martin & Adriaan have already commented on my choice of the project and its status within Scala, but I'd like to additionally elaborate on your other points. Speaking of target audience and usefulness. Even before being officially released, macros have attracted attention of popular community libraries and tools (e.g. SBT, Akka, Play, Slick), and later on we got even more people on board [1]. Therefore, even though not many people are writing macros, a lot of Scala developers are, sometimes even unknowingly, using them. That's I think is the best thing about macros in Scala - natural integration with other language features, to the extent that people aren't even aware that they are using macros and not regular functions or implicits or whatnot. Surprisingly many features can be empowered this way, giving rise to new and effective ways of solving development challenges [2]. Speaking of the future status of macros. Half a year ago, we had a joint EPFL and TypeSafe meeting where we decided to stabilize a subset of macros (so called blackbox macros [3]) and include it as an official, non-experimental language feature by 2.12. Indeed, at times we have fierce debates on our mailing lists about this or that esoteric macro flavor, but that concerns only my research activities [4], not blackbox macros, which have reach unequivocal approval at scala-internals a long time ago. This brings me to the next point - transparency of development. For the entire duration of my doctoral studies at EPFL that begun in Sep 2011, we were always open with our plans, welcoming feedback and actively answering questions on the mailing lists and stack overflow. Some of the most successful reflection and macro features are there only because of our close collaboration with the community, and I'm very grateful to everyone who has participated and is participating. Finally, the thing about generating papers is just untrue. Sure there are people who do their research using macros, but if you take a look at the list of my publications, you'll see that over the two years that I've been a PhD student I have authored zero conference papers. This is the cost of seeing through an implementation of a feature in an official language release, addressing the feedback of early adopters, and then maintaining it as it's being used in production. But anyhow I don't mind how it turned out, because I'm very glad that more and more people are picking up macros and finding them useful. [1] http://scalamacros.org/paperstalks/2013-06-12-HalfYearInMacroParadise.pdf http://scalamacros.org/paperstalks/2013-06-12-HalfYearInMacr... [2] http://docs.scala-lang.org/overviews/macros/usecases.html http://docs.scala-lang.org/overviews/macros/usecases.html [3] http://docs.scala-lang.org/overviews/macros/blackbox-whitebox.html http://docs.scala-lang.org/overviews/macros/blackbox-whitebo... [4] http://docs.scala-lang.org/overviews/macros/paradise.html http://docs.scala-lang.org/overviews/macros/paradise.html

laureny 13y ago

> Why do you think that those doing research inside Typesafe are steering the language in a direction that is user hostile? Macros come to mind. It's a feature that completely circumvented the SIP (and was later retrofitted into it), which is still heavily controversial inside scala-internals to the point that we're still not sure whether they will ever be officially part of scalac and which will probably never be used by more than a very tiny minority of Scala users. They took months of work (which could have been put to better use, e.g. IDE support), mostly done with little transparency and which started generating papers for conferences before the project was remotely close to a prototype. This kind of project would never have seen the light of day if the language was led by a company focused primarily on users and sound engineering.

necubi 13y ago
I can personally vouch for the value of Scala macros, which I feel really transform the language. With macros (at least with macro-paradise) I can metaprogram Scala more powerfully than Ruby, while retaining typesafety. Scala + macros is a pretty remarkable language, being very dynamic while also being very safe. The macros support included in 2.10 is pretty basic and difficult to use, but with annotation macros and quasiquotation in macro-paradise those issues are eliminated. And who are you to determine what gets priority amongst open-source devs? Does macro support make scala a worse language? Are you upset that an unpaid researcher (not an employee of typesafe) decided to spend time implementing the macro system instead of working on the IDE?
modersky 13y ago
Macros were not done at Typesafe, but by Eugene Burmako, who's a grad student at EPFL. Grad students do new stuff, and they publish about it, IDE improvements are typically not their piece of cake (Typesafe does have a very capable team working on IDEs). As you imply, macros are labelled experimental, which means that you have to enable them explicitly. Having experimental features is Scala's way of reconciling a vibrant open source community with the stability needed for enterprise use. Needless to say, we do not recommend use of experimental features in enterprises. They are good for playing around with interesting new concepts and sometimes they do lead to something which is a win, such as the beautiful async/await library that will ship in 2.11.
adriaanm 13y ago
Macros were not developed by Typesafe, though we do try to help out. Also, macros are clearly marked experimental -- a compromise for a language co-developed by researchers (EPFL has invested over a decade in Scala) and industry. We (Typesafe) are using macros in our own projects, so the small investment in helping out with their development has largely been paid off because they essentially give us a lightweight compiler plugin mechanism. Users need not be aware macros underly, say scala-async.
deleted 13y ago
[deleted]
eugene_burmako 13y ago
Hi, that's me who's doing macros for Scala. Martin & Adriaan have already commented on my choice of the project and its status within Scala, but I'd like to additionally elaborate on your other points. Speaking of target audience and usefulness. Even before being officially released, macros have attracted attention of popular community libraries and tools (e.g. SBT, Akka, Play, Slick), and later on we got even more people on board [1]. Therefore, even though not many people are writing macros, a lot of Scala developers are, sometimes even unknowingly, using them. That's I think is the best thing about macros in Scala - natural integration with other language features, to the extent that people aren't even aware that they are using macros and not regular functions or implicits or whatnot. Surprisingly many features can be empowered this way, giving rise to new and effective ways of solving development challenges [2]. Speaking of the future status of macros. Half a year ago, we had a joint EPFL and TypeSafe meeting where we decided to stabilize a subset of macros (so called blackbox macros [3]) and include it as an official, non-experimental language feature by 2.12. Indeed, at times we have fierce debates on our mailing lists about this or that esoteric macro flavor, but that concerns only my research activities [4], not blackbox macros, which have reach unequivocal approval at scala-internals a long time ago. This brings me to the next point - transparency of development. For the entire duration of my doctoral studies at EPFL that begun in Sep 2011, we were always open with our plans, welcoming feedback and actively answering questions on the mailing lists and stack overflow. Some of the most successful reflection and macro features are there only because of our close collaboration with the community, and I'm very grateful to everyone who has participated and is participating. Finally, the thing about generating papers is just untrue. Sure there are people who do their research using macros, but if you take a look at the list of my publications, you'll see that over the two years that I've been a PhD student I have authored zero conference papers. This is the cost of seeing through an implementation of a feature in an official language release, addressing the feedback of early adopters, and then maintaining it as it's being used in production. But anyhow I don't mind how it turned out, because I'm very glad that more and more people are picking up macros and finding them useful. [1] http://scalamacros.org/paperstalks/2013-06-12-HalfYearInMacroParadise.pdf http://scalamacros.org/paperstalks/2013-06-12-HalfYearInMacr... [2] http://docs.scala-lang.org/overviews/macros/usecases.html http://docs.scala-lang.org/overviews/macros/usecases.html [3] http://docs.scala-lang.org/overviews/macros/blackbox-whitebox.html http://docs.scala-lang.org/overviews/macros/blackbox-whitebo... [4] http://docs.scala-lang.org/overviews/macros/paradise.html http://docs.scala-lang.org/overviews/macros/paradise.html