[Автор оригинального текста — Paul Chiusano, программист, работает в Capital IQ, пишет преимущественно на Scala. Один из разработчиков библиотеки scalaz — прим. пер.]
Как будет выглядеть программирование через 10-20 лет? В канун нового года самое время пофилософствовать о будущем нашей индустрии. Мы находимся на пороге значительных изменений в деле написания программ, по сравнению с которыми нынешние, 2011 года, техники и идеи будут выглядеть примитивными. Изменения будут происходить в нескольких важных областях: инструментария и инфраструктуры, языков и систем типов, систем времени исполнения.
...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Да что там обсуждать, кто ж его знает как оно будет на самом деле. Мир слишком многогранен, что бы зоопарк ушел в лес.
По сравнению с меинстримными языками, такими как Java, C# или Python язык Javascript не так и плох; в некоторых отношениях он даже лучше. Но Javascript не выдерживает сравнения с языками, имеющими хорошую систему типов и настоящую поддержку ФП, вроде Haskell, Scala и тех языков будущего, которые придут им на смену.
Яваскрипт перед всеми остальными имеет ровно одно преимущество — он действительно исполняется в реальных браузерах.
По всем остальным пунктам он сольёт. Тем не менее я лично считаю, что JS — язык действительно интересный, хороший язык — но — на нём дороговато разрабатывать. Лучшие средства разработки с трудом справляются с ним даже с обильно усеянными хинтами. Эффективность исполнения? Тоже сольёт и Java и C# и Python.
А про ФП — так это вообще судя по всему словечки ради дани моде.
Нет, конечно, если на каждый чих генерить страницы с сервера — то зачем и JS то нужен?! А для более-менее современной обвязки нужно как минимум около 300Kb JS кода, — фреймворка. Посмотреть на фреймворки поболее — так там счет на мегабайты. Может не в языке дело?
Предвижу будущее, в котором Javascript постепенно отходит на второй план, как уходят и специализированные плагины для браузеров вроде Flash, уступая место коду, написанному на произвольных, компилируемых языках, использующих для работы что-нибудь вроде NaCl.
NaCl как и Chromium платформа просто умрёт под собственным грузом. Да ну как и остальные html движки — кода много — ресурсов хавает дай бог каждому, а толку то реально мало. Продвигать насквозь однопоточные layouting engine с кучей ограничений лишь под флагом секурности и скорости и изоляции — это просто бред, при этом решая просто насущные проблемы однопоточного дизайна, и (опционально для разных движков) невозможность достоверно уничтожить js context без перезапуска процесса. Самое смешное, что исключительно все выходцы былых времен и страдают одними и теми же проблемами — а новых выходцев — нет, потому что потянуть всю эту ахинею осилит далеко не каждый, труд слишком велик. Тем не менее вся это богодельня мне кажется очень даже будет жить.
Да уже лет 30 ничего в программировании толком ничего не меняется. Что будет еще через 10? Да ничего! То же самое подадут еще раз под несколькими соусами. Ну может и возникнет какая-нибудь мода, и станет популярным какой-нибудь PJMLScript&& для новой разработки, но суть останется той же да и большинство продолжит поддерживать кучу написанного кода и верно напоминать, что PJMLScript&& оно конечно да, но ни разу не панацея и мозг включать по любому придется.
Здравствуйте, LaptevVV, Вы писали:
LVV>[Автор оригинального текста — Paul Chiusano, программист, работает в Capital IQ, пишет преимущественно на Scala. Один из разработчиков библиотеки scalaz — прим. пер.]
Первым существенным изменением будет уход от представления программ в виде текста, разделенного на файлы.
Первый посыл и сразу весьма сомнительный. Сомнительный практически до нереального. Короче, фантазёрство. Советские фантасты так представляли планету через 50 лет (как раз наше время). Везьде коммунизм, в небе кругом летательные аппараты, космические карабли бороздят просторы, а мониторы у компьютеров всё такие же зелёные и информация хранится в сейфе предварительно сброшенная на перфоленту. А на деле получилось интернет, карманные телефоны со встроенными видео камерами, навигаторами и музыкальными центрами, трёхмерное телевидение и терабайты семейных картинок и видео. Правда вот с коммунизмом и космосом как-то не всё получилось.
Если нам не помогут, то мы тоже никого не пощадим.
LVV>[Автор оригинального текста — Paul Chiusano, программист, работает в Capital IQ, пишет преимущественно на Scala. Один из разработчиков библиотеки scalaz — прим. пер.]
LVV>Как будет выглядеть программирование через 10-20 лет?
LVV>...
Изменения в программировании происходят,когда назревает необходимость. Так было с С++ и Java. На данный момент, контроль над мейнстримными языками осуществляют те же компании, что и создают веяния в мире софта и железа. Так получается замкнутный круг — девайс->технология<->язык.
Лично я За — изменения самого образа программирования в сторону визуальности. Автор прав в том, что потеря продуктивности из-за кода в тексте, остается за пределами радаров программиста.
1. автор -- человек с завышенным чсв, рассказывает про то, что
> Эта проблема пользуется популярностью среди людей, которые предпочитают находить своему нежеланию учить Haskell и ФП рациональные объяснения
*людям* и права нет смысла учить хаскель, его имеет смысл учить *только* для того, чтобы понимать о чем там говорят ученые и псевдо-ученые
> А тем, кто предпочитает критиковать ФП, я считаю, не помешает заиметь немного скромности.
помешает
очень даже помешает критическому восприятию их понтов -- как ввели *недавно* в хаскеле (или его расширении) семейства типов (практически аналог плюсовых шаблонных типов, существующих х.з. сколько времени), уж столько помпы в вики -- это же почти зависимые типы!!1111
3.
> Так, будут почти универсальные стандарты (вроде getAllLinks)
так мы и поверили -- гуглу будет выдаваться одно, а человеку показываться другое, спамеры однако
я думаю тут решение будет простое -- настоящим аппликухам нет смысла держать у себя шибко интересные гуглу урл-ки, урл-ки это атрибут документации (т.е. именно страницы с (гипер)текстом), а не аттрибут аппликухи
это язык для создания запросов к исходному коду и для трансформации исходного кода
что касается нетекстового и нефайлового хранения -- идея 50% на 50%; хотя мне честно говоря не хватает текстового представления языка, нетекстовое потребует затрат по адаптации к нему vcs
Здравствуйте, licedey, Вы писали:
L>Лично я За — изменения самого образа программирования в сторону визуальности. Автор прав в том, что потеря продуктивности из-за кода в тексте, остается за пределами радаров программиста.
Попыток уйти от этого было дохрена и больше. И обсуждений причин гиблости затеи здесь тоже было дохрена и больше. Вот из последнего, где я участвовал.
LVV>[Автор оригинального текста — Paul Chiusano, программист, работает в Capital IQ, пишет преимущественно на Scala. Один из разработчиков библиотеки scalaz — прим. пер.]
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, LaptevVV, Вы писали: IT>
IT>Первым существенным изменением будет уход от представления программ в виде текста, разделенного на файлы.
IT>Первый посыл и сразу весьма сомнительный. Сомнительный практически до нереального. Короче, фантазёрство. Советские фантасты так представляли планету через 50 лет (как раз наше время). Везьде коммунизм, в небе кругом летательные аппараты, космические карабли бороздят просторы, а мониторы у компьютеров всё такие же зелёные и информация хранится в сейфе предварительно сброшенная на перфоленту. А на деле получилось интернет, карманные телефоны со встроенными видео камерами, навигаторами и музыкальными центрами, трёхмерное телевидение и терабайты семейных картинок и видео. Правда вот с коммунизмом и космосом как-то не всё получилось.
1. А вы читали вот эту книгу: http://www.ozon.ru/context/detail/id/2896278/
Там есть очень интересная глава про исследовательские работы в Микрософте.
2. Отец БлэкБокса Клеменс Шиперски работает в Microsoft Research: http://research.microsoft.com/en-us/um/people/cszypers/
А представление модулей в БлэкБоксе — не текстовое. Это было еще в 95-м году.
3. Программа — это мультиграф, вершинами которого являются модули.
В системе этот мультиграф может хранится в каком угодно виде.
И только для человека его нужно представить в текстовом виде. Но это не значит, что в текстовом же виде программу надо и обрабатывать.
И даже вводить можно не в текстовом виде.
Мы у себя делаем семантический редактор, который с текстами не работает.
Первая часть компилятора физически отсутствует — фактически требуют анализа только выражения.
Но на экране — текст, который читает человек.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, licedey, Вы писали:
L>Изменения в программировании происходят,когда назревает необходимость. Так было с С++ и Java. На данный момент, контроль над мейнстримными языками осуществляют те же компании, что и создают веяния в мире софта и железа. Так получается замкнутный круг — девайс->технология<->язык.
Вот у нас (лично у нас в Астрахани) и назрела необходимость. L>Лично я За — изменения самого образа программирования в сторону визуальности. Автор прав в том, что потеря продуктивности из-за кода в тексте, остается за пределами радаров программиста.
Нет. Мы — программисты. И должны сами сделать такой инструмент, который НАМ удобен.
Как в свое время сделали юникс — систему, которая удобна именно программистам.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>3. Программа — это мультиграф, вершинами которого являются модули. LVV>В системе этот мультиграф может хранится в каком угодно виде. LVV>И только для человека его нужно представить в текстовом виде. Но это не значит, что в текстовом же виде программу надо и обрабатывать.
Ну как бы что у Влада интеграция немерла для VS, что у Одерски интеграция скалы для Eclipse тоже всё перекомилирует на каждый чих программиста. Причём как минимум у одного из них — не полностью, а только необходимое поддерево. Небось, как раз и держит в памяти AST — тот самый нетекстовый вид. А вот фраза "для человека его нужно представить в текстовом виде" содержит ошибочку: надо не только "представить" (r/o), но и обеспечить возможность редактирования человеком в текстовом виде (r/w).
LVV>Мы у себя делаем семантический редактор, который с текстами не работает. LVV>Первая часть компилятора физически отсутствует — фактически требуют анализа только выражения. LVV>Но на экране — текст, который читает человек.
читает, но не редактирует? а редактирует уже дерево/граф?
а парсить текстовые файлы ваша система умеет? или для переноса в нее кода требуется забивать его руками?
если так уж прям хочется окунуться в такую систему, рекомендую JetBrains MPS
а вот еще че забыл спросить -- грамматика для перевода дерева/графа в текстовое представление проверяется на однозначность? т.е. может возникнуть такая ситуация, что два *разных* графа выливаются в один и тот же текст?
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, LaptevVV, Вы писали:
LVV>>3. Программа — это мультиграф, вершинами которого являются модули. LVV>>В системе этот мультиграф может хранится в каком угодно виде. LVV>>И только для человека его нужно представить в текстовом виде. Но это не значит, что в текстовом же виде программу надо и обрабатывать.
D>Ну как бы что у Влада интеграция немерла для VS, что у Одерски интеграция скалы для Eclipse тоже всё перекомилирует на каждый чих программиста. Причём как минимум у одного из них — не полностью, а только необходимое поддерево. Небось, как раз и держит в памяти AST — тот самый нетекстовый вид. А вот фраза "для человека его нужно представить в текстовом виде" содержит ошибочку: надо не только "представить" (r/o), но и обеспечить возможность редактирования человеком в текстовом виде (r/w).
Редактировать надо не весь текст. Например, ключевые слова нафиг не надо редактировать.
Фактически создание модуля состоит из операций вставки-удаления конструкций + текстовое редактирование отдельных лексем — идентификаторов, констант и т.п.
Плюс операции рефакторинга вроде — преобразовать выделенную последовательность операторов в функцию. И наоборот — "раздеть" функцию.
Операции рефакторинга требуют исследования. Это вам не вставить — удалить символ.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, m e, Вы писали:
LVV>>Мы у себя делаем семантический редактор, который с текстами не работает. LVV>>Первая часть компилятора физически отсутствует — фактически требуют анализа только выражения. LVV>>Но на экране — текст, который читает человек. ME>читает, но не редактирует? а редактирует уже дерево/граф?
Редактирует. Но не весь. Ключевые слова нафиг редактировать.
Имена, константы, выражения — это требует редактирования ручного. А сама структура конструкции оператора редактирования не требует.
Он добавляется в модель одной клавишей. Одной же и удаляется. ME>а парсить текстовые файлы ваша система умеет? или для переноса в нее кода требуется забивать его руками? ME>если так уж прям хочется окунуться в такую систему, рекомендую JetBrains MPS ME>она уже сделана
В смысле IntelliJ ?
Импорт — это естественно будет. Но задача не первоочередная.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Фактически создание модуля состоит из операций вставки-удаления конструкций + текстовое редактирование отдельных лексем — идентификаторов, констант и т.п.
Для меня создание модуля в доброй половине случаев начинается с копипаста другого.
Здравствуйте, LaptevVV, Вы писали:
LVV>А сама структура конструкции оператора редактирования не требует. LVV>Он добавляется в модель одной клавишей.
Дык это и щас есть. Code snippets называется, что ли... Один хрен не пользуюсь — лениво запоминать горячую клавишу и настраивать удобные мне шаблоны с удобным мне форматированием.
LVV>Одной же и удаляется.
Гы. Я так понимаю, не дай бог нажать delete под словом "class".
Мне так кажется, что надо не обсуждать что сделают другие, а что мы сделаем в том момент когда все зашло в тупик, самый момент предложить что-то новое.
Но для начала надо понять что плохо.
А плохо то что так и не создан язык, подобный математическому языку. Языку без ифов, языку без двоичной логики. Ну если хотите, для затравки/обьяснения — языку у которого иф как бы срабатывает на 0.5 То есть если уловие уже близко к истине он уже начинает выполняться.
Если нам не помогут, то мы тоже никого не пощадим.
Автор(ы): К. Чарнецки, У. Айзенекер
