Слушайте доклад Мартина на scaladays.org 8 июня.
Мое мнение — скоро оба компилятора будут сосуществовать. Основные отличия для меня(это мое мнение и не факт что все выйдет так как я думаю):
появится другая екосистема, дружественная к оптимизаторам(моя область) и метапрограммированию(Женя Бурмако), если коротко — теперь scala будет компилироваться в некое промежуточное представление, а оно уже будет компилироваться в JVM bytecode\javascript\LLVM. LLVM — под вопросом. Но один активист делает титанические усилия в эту сторону.
Выдадим пользователю типа объединения(union) и типы пересечения(intersection). Для меня это заменяет enum-ы на чтото что разумно.
Изменится схема компиляции lazy val-ов. Теперь lazy val без `@volatile` не thread-safe, и доступ к таким быстрее раз в 10. `@volatile` lazy val будет быстрее на 10-20%, позволит инициализовывать несколько lazy полей одновременно в одном объекте(он почти не синхронизуется на this), и вообще в большинстве случаев будет lock-free и значит без дедлоков.
метапрограммирование — scalameta.org обычные макросы не поддерживаются.
частью экосистемы станет dotty linker: штукенция которая делает глобальный анализ программы, смотрит как вы используете библиотеки, тюнит их для вас и встраивает в ваше приложение. Это реинкарнация scala-blitz.github.io. Позволяет писать высокоуровневый код, зная что компилятор сможет заменить его на эффективный. Из спорных вещей — это аналог статической линковки, те при изменении зависимостей нужна перекомпиляция. Это не часть Dotty, тк в некоторых ситуациях люди привыкли менять один jar чтобы пофиксить баги в зависимостях. Это только для тех кому нужна максимальная производительность, или минимальный размер(Android например). Он же будет делать specialization только для тех классов которые используются. В теории это может позволить нам сделать reified generics но мы не решили хорошо ли это.
более быстрый компилятор — мы еще не тюнили его, но даже сейчас он примерно такойже по скорости компиляции как scalac
arrays of value classes
value classes over value classes
под вопросом — multifield value classes.
Как видите, мы хотим улучшить многое. А любое улучшение приходит с багами. Потому и будут два компилятора.
В последнее время, с момента появления Typesafe, scala стала намного более консервативной, и это понятно и разумно.
Нужно понимать что в dotty мы(лаборатория Мартина) хотим проводить исследования того, каким язык должен быть.
Нужна стабильность — scalac. Нужны новые фичи — Dotty.
Сколько продлится сосуществование — мне самому любопытно. Это уже вопрос граничащий с коммерческими вопросами для Typesafe, тк они продают многолетние контракты поддержки.
Пока я жил в Москве, тоже не знал о таких вещах.
Как оказалось это вопрос «удаления» от тех людей, которые вершат изменения. Я не припоминаю чтобы кто-либо из моих знакомых в Москве ездил на конференции по другим странам, а тем более был докладчиком.
Сейчас, находясь в Швейцарии, работая над Scala я обычно узнаю все Scala-новости в течении недели.
Disruptor это очень быстрая реализация фиксированного по размеру кольцевого буфера. Быстрая она не из за фундаментальных нововведений, а из за того что люди полезли в железо и учли мелкие детали, например порядок полей, выравнивание, конфликт строк памяти при запуске Cache Coherence Protocol, итд.
Зависит от того насколько глубокий курс. Если вы рассказываете теорию множеств то можно пояснить почему default arguments не дружат с overload resolution.
Кстати, если курс предназначен для разработчиков, то из стандартного инструментария — macros, pickling(самый быстрый сериализатор, тк 90% работы делает во время компиляции и по возможности избегает reflection), spores(убеждается что лябмды не захватили чтото случайно в окружении, помогает с memory leak-ами бороться).
Из вещей которые стоит не рассказывать(точнее расказать что не стоит использовать) — xml как часть языка. Уже давно есть сильное намерение вынести его в string interpolation. В Dotty эта часть языка не поддерживается как таковая.
Streams тоже to-be deprecated, потому что они дают ложное впечатление контроля.
Они не deprecated потому что мы замену еще не сделали — она будет основана на инфраструктуре Dotty и будет иметь много общего со Stream Fusion из Haskell.
Через пол-годика-годик будет в этой области улучшение: github.com/lampepfl/dotty/pull/411
Скорее всего будут — массивы value-classов, value-class-ы поверх value-class-ов, отсуствие боксинга в аннонимных функциях.
Маловероятно, но возможно — специализация для value-class-ов.
и, ИМХО, любой толковый курс по Scala сейчас должен включать String Interpolation,
А также лучше б ему включать хотябы минимум про blackbox macros.
Иначе вы упомянули shapeless, но не то на чем он построен.
Как один из разработчиков компилятора говорю — не нужно бездумно совать всюду `@inline`. Тут — это не помогает компилятору никак, но замусоривает ваш код. Каждая такая аннотация должна быть хорошо продумана.
Я бы еще добавил что в bytecode не множественных catch, а блок finally отсутствует вообще и дублируется между телом try и catch-блоками. В итоге правильно составленный исходник будет расти экспоненциально при компиляции в байткод.
Не distance. А в EPFL. В офисе. В аспирантуре.
Жить — спокойно. По желанию — учишь язык. Я учу практикуясь, но потребности знать его заранее нет. phd.epfl.ch/edic/application —
Хотя проблемы с недобором у нас отрадясь не было, но:
меня можно считать представителем «организации» Scala на хабре. И возможным ментором проектов связанных с github.com/lampepfl/dotty — экспериментальным компилятором для Scala, если будут желающие.
Убедить все разношерастные браузеры на приличном уровне поддерживать несколько языков маловероятно.
Другим подходом можно создавать компиляторы из других языков в JS, и воспринимать JS как assembler для Web, и делать компиляторы в него из других языков.
2 года назад я бы предложил Pascal.
Но сейчас, я предложу Scala. Не удивляйтесь, сейчас поясню.
Да, у Scala есть «сложные» куски — dependent types один из них, однако на самом деле, Мартин Одерски, будучи учеником Вирта(создателя Pascal) идет темже путем — язык очень прост в изучении, если его давать правильными частями.
Если подготовка группы говорит что они лучше поймут функциональное программирование(математики-теретики например), то на время не рассказывайте про мутабельность — покажите им моноиды, iteratee, и они будут впечатлены.
Если подготовка группы говорит что они поймут императивную модель — используйте императивное проявление скалы. Делаете все тоже что делали в Pascal.
Потом можно рассказать про actor-based модель, и передать привет Erlang-у, все в одном языке.
Нужен браузер — scala.js. Нужен Android — тоже не такие уж и трудности. Есть нормальные среды разработки(eclipse, idea), есть отладка.
Потом ИМХО я бы рассказал про DSL-и, которые легко встраивать в язык, это покажет всю силу Scala и пояснит что такое адаптация синтаксиса под область.
Далее, по мере подобных вопросов «а как сделать ****» можно открывать более сложные части языка, поясняя зачем они вообще есть.
С моей точки зрения Трансдьюсеры очень близки к попытке сделать Stream Fusion\deforestation руками. С одной стороны выходит больше контроля чем если это было сделано автоматически компилятором, с другой стороны нужно больше телодвижений и больше шансов для ошибки.
Причем, насколько мне известно, эта попытка не учитывай почти 30-летний опыт в этой области.
— (Уменьшенные в объеме специально для ИТшников) Матанализ, Линейная алгебра, Теорвер и т д
Соглашусь. Причем не то что уменьшенные а совсем урезанные местами. Предполагается что если на курсе, скажем, вероятностных алгоритмов вам понадобится теорвер, то вы сами в нужных объемах его найдете.
— (Расширенные по сравнению с МФТИ и Мехматом) Дискретная математика, Методы оптимизации, Численные методы, Теория алгоритмов и т д
Я вот сказал бы что Методы Оптимизации+Численные методы+Дискретка на физтехе были сильнее чем в EPFL. Во всяком случае у меня знаний осталось больше чем у студентов бравших курсы тут. Про алгоритмы соглашусь, но еще больше и лучше изложение в Школе Анализа Данных Яндекса.
— Языки программирования, Операционные системы, Базы данных, Сети
Я бы не сказал что в бакалаврский курс EPFL входят нормальные курсы этого. Они уже на мастере.
Я бы утверждал о другом. В EPFL курсы дают с привязкой к практике с первого курса. Пример:
На первом курсе можно взять курс по ООП на примере Java. Уже на втором месяце вам в руки выдадут написанный тут для этого курса фреймворк для работы с ГИС на котором нужно будет решать задачи типа «найти куда можно добраться из EPFL за 20 минут от 'сейчас' с учетом расписания транспорта».
А на курсе по компиляторам будут писать свой парсер, свой простейший интерпретатор и свой сборщик муссора. Которые будут тестироваться автоматической системой.
Мое мнение — скоро оба компилятора будут сосуществовать. Основные отличия для меня(это мое мнение и не факт что все выйдет так как я думаю):
Как видите, мы хотим улучшить многое. А любое улучшение приходит с багами. Потому и будут два компилятора.
В последнее время, с момента появления Typesafe, scala стала намного более консервативной, и это понятно и разумно.
Нужно понимать что в dotty мы(лаборатория Мартина) хотим проводить исследования того, каким язык должен быть.
Нужна стабильность — scalac. Нужны новые фичи — Dotty.
Сколько продлится сосуществование — мне самому любопытно. Это уже вопрос граничащий с коммерческими вопросами для Typesafe, тк они продают многолетние контракты поддержки.
Как оказалось это вопрос «удаления» от тех людей, которые вершат изменения. Я не припоминаю чтобы кто-либо из моих знакомых в Москве ездил на конференции по другим странам, а тем более был докладчиком.
Сейчас, находясь в Швейцарии, работая над Scala я обычно узнаю все Scala-новости в течении недели.
Disruptor это очень быстрая реализация фиксированного по размеру кольцевого буфера. Быстрая она не из за фундаментальных нововведений, а из за того что люди полезли в железо и учли мелкие детали, например порядок полей, выравнивание, конфликт строк памяти при запуске Cache Coherence Protocol, итд.
Кстати, если курс предназначен для разработчиков, то из стандартного инструментария — macros, pickling(самый быстрый сериализатор, тк 90% работы делает во время компиляции и по возможности избегает reflection), spores(убеждается что лябмды не захватили чтото случайно в окружении, помогает с memory leak-ами бороться).
Из вещей которые стоит не рассказывать(точнее расказать что не стоит использовать) — xml как часть языка. Уже давно есть сильное намерение вынести его в string interpolation. В Dotty эта часть языка не поддерживается как таковая.
Они не deprecated потому что мы замену еще не сделали — она будет основана на инфраструктуре Dotty и будет иметь много общего со Stream Fusion из Haskell.
github.com/lampepfl/dotty/pull/411
Скорее всего будут — массивы value-classов, value-class-ы поверх value-class-ов, отсуствие боксинга в аннонимных функциях.
Маловероятно, но возможно — специализация для value-class-ов.
А также лучше б ему включать хотябы минимум про blackbox macros.
Иначе вы упомянули shapeless, но не то на чем он построен.
а в Pattern matching добавить name-based pattern matching.
Жить — спокойно. По желанию — учишь язык. Я учу практикуясь, но потребности знать его заранее нет.
phd.epfl.ch/edic/application —
Ни слова о французском.
меня можно считать представителем «организации» Scala на хабре. И возможным ментором проектов связанных с github.com/lampepfl/dotty — экспериментальным компилятором для Scala, если будут желающие.
PS: не имею отношения к Typesafe.
Другим подходом можно создавать компиляторы из других языков в JS, и воспринимать JS как assembler для Web, и делать компиляторы в него из других языков.
Но сейчас, я предложу Scala. Не удивляйтесь, сейчас поясню.
Да, у Scala есть «сложные» куски — dependent types один из них, однако на самом деле, Мартин Одерски, будучи учеником Вирта(создателя Pascal) идет темже путем — язык очень прост в изучении, если его давать правильными частями.
Если подготовка группы говорит что они лучше поймут функциональное программирование(математики-теретики например), то на время не рассказывайте про мутабельность — покажите им моноиды, iteratee, и они будут впечатлены.
Если подготовка группы говорит что они поймут императивную модель — используйте императивное проявление скалы. Делаете все тоже что делали в Pascal.
Потом можно рассказать про actor-based модель, и передать привет Erlang-у, все в одном языке.
Нужен браузер — scala.js. Нужен Android — тоже не такие уж и трудности. Есть нормальные среды разработки(eclipse, idea), есть отладка.
Потом ИМХО я бы рассказал про DSL-и, которые легко встраивать в язык, это покажет всю силу Scala и пояснит что такое адаптация синтаксиса под область.
Далее, по мере подобных вопросов «а как сделать ****» можно открывать более сложные части языка, поясняя зачем они вообще есть.
Причем, насколько мне известно, эта попытка не учитывай почти 30-летний опыт в этой области.
Обратите внимание на DarkTable.
Соглашусь. Причем не то что уменьшенные а совсем урезанные местами. Предполагается что если на курсе, скажем, вероятностных алгоритмов вам понадобится теорвер, то вы сами в нужных объемах его найдете.
Я вот сказал бы что Методы Оптимизации+Численные методы+Дискретка на физтехе были сильнее чем в EPFL. Во всяком случае у меня знаний осталось больше чем у студентов бравших курсы тут. Про алгоритмы соглашусь, но еще больше и лучше изложение в Школе Анализа Данных Яндекса.
Я бы не сказал что в бакалаврский курс EPFL входят нормальные курсы этого. Они уже на мастере.
Я бы утверждал о другом. В EPFL курсы дают с привязкой к практике с первого курса. Пример:
На первом курсе можно взять курс по ООП на примере Java. Уже на втором месяце вам в руки выдадут написанный тут для этого курса фреймворк для работы с ГИС на котором нужно будет решать задачи типа «найти куда можно добраться из EPFL за 20 минут от 'сейчас' с учетом расписания транспорта».
А на курсе по компиляторам будут писать свой парсер, свой простейший интерпретатор и свой сборщик муссора. Которые будут тестироваться автоматической системой.