Futurama
Следующего большого языка программирования не предвидится. По крайней мере, на то нет причин с точки зрения теории эволюции.
Эволюция работает не только в животном мире, но и в любой подходящей среде. Впервые эта идея получила широкое распространение с выходом книги Ричарда Докинза «Эгоистичный ген» в 1976 году. В ней был введен знакомый каждому термин «мем», как пример эволюции в социальной и культурной среде. Языки программирования тоже эволюционируют. А значит их развитие подчиняется принципам эволюции, на основании которых можно сделать предположение о будущем их развитии.
Для работы эволюционных принципов необходимы следующие механизмы: изменчивость, наследование признаков и естественный отбор. Кажется, что выполнение этих требований для языков программирования достаточно очевидно. Простой пример — диаграмма развития языков программирования, которая, может быть, даже красуется на постере у вас за спиной.
Можно было бы возразить, что создание нового языка программирования — это исключительно заслуга творца. Джеймс Гослинг создал Java, Гвидо Ван Россум — Python, а Керниган и Ричи — C. Однако, на практике они лишь реализуют механизм изменчивости собирая из “генов” языков программирования что-то новое. Никто не в состоянии сам заставить весь мир разрабатывать, например, на ABAP, что, впрочем, не умаляет заслуг авторов.
Для понимания того, когда появится следующий большой язык программирования, стоит ознакомиться с принципом острова. Но прежде давайте рассмотрим применение других принципов эволюции к языкам программирования, хотя бы ради любопытства.
Вымирание и гены
Используя аналогию с устной речью, вымершими будем считать те языки, на которых никто не разрабатывает в настоящий момент. Даже если компиляторы этих языков существуют, программы на них написанные можно запустить, а некоторые “историки программирования” все еще могут написать на них новый код.
Все знают, что предками языков C (1972) и Pascal (1970) были B (1969) и Algol (1958-68), которые смело можно считать вымершими. Утверждать что язык B забыли, потому что он “старый” — неправильно. Lisp (1958) старше, а его диалекты в ходу до сих пор, как и само название языка. Да и C, несмотря на то что уже не молод, будет с упорством отстаиваться как лучший язык программирования миллионами разработчиков по всему миру.
Посмотрим на пример кода на B из оригинального руководства по языку. Согласитесь, он не так уж и далек от современного C:
main() {
extrn putchar, n, v;
auto i, c, col, a;
i = col = 0;
while(i<n)
v[i++] = 1;
while(col<2*n) {
a = n+1 ;
c = i = 0;
while (i<n) {
c =+ v[i] *10;
v[i++] = c%a;
c =/ a--;
}
putchar(c+'0');
if(!(++col%5))
putchar(col%50?' ': '*n');
}
putchar('*n*n');
}
v[2000];
n 2000;Есть причина, по которой B и подобные ему языки забыты, — это “ген” структур данных. Единственное что отличает C и Pascal от своих предшественников — наличие конструкций “struct” и “record”. Почему это, казалось бы, небольшое изменение обеспечило живучесть C и Pascal на десятилетия, а их предшественники лишь вскользь упоминаются в университетских курсах? Просто изменилась среда.
Проект «Манхэттен» показал, что возможностей электромеханических табуляторов недостаточно для проведения физических расчетов: необходимых для разработки атомного оружия. О том, как проводились такие вычисления рассказывается в одной из глав книги «Вы, конечно, шутите, мистер Фейнман!». Конечно, именно Пентагон стал заказчиком нового инструмента для проведения вычислений — компьютера, первый из которых увидел свет в 1946 году (ENIAC).
Что нужно для проведения физических расчетов — скаляры, векторы, матрицы и нехитрая программа. Долгое время такого инструментария было достаточно для решения всех насущных задач. Именно это и было реализовано в языке Fortran (1957), и даже в редакции 1977 структуры данных в нем не появились. По тем же принципам строились и другие языки того времени.
Появлению C мы обязаны возникновением нового класса задач — системного программирования. Необходимость создавать операционные системы, в разработке которых требуются “не математические” структуры данных, привела к тому, что язык закрепился и здравствует. Оказалось, что иметь возможность оперировать произвольными структурами — это очень удобно и позволяет решать любые классы задач, в то время, как языки B или Algol показали свою ограниченность и были забыты. Пожалуй только Fortran сохранил свою актуальность по сей день, и то в 1990 году структуры данных в него все таки добавили.
Конвергентная эволюция
Живые существа в сходных условиях вырабатывают аналогичные свойства адаптации к ним независимо друг от друга. Например, и птицы и летучие мыши имеют крылья. При этом птицы это птицы, а летучие мыши — млекопитающие. Инструмент для полета был реализован ими независимо, но одинаково, поскольку решал одну и ту же задачу.
Европейская и американская школы программирования не склонны заимствовать наработки друг друга, и предпочитают изобретать свои решения самостоятельно. Именно поэтому C и Pascal возникли практически в одно время и реализовали одну и ту же особенность — концепцию структур данных, пусть и немного по-разному.
Аналогичную ситуацию можно проследить между Windows 1.0 (1985) и node.js (2009). В случае Windows 1.0 решалась задача обеспечения одновременной асинхронной работы одного пользователя со многими приложениями, в node.js — многих пользователей с одним приложением использующим асинхронные операции ввода-вывода. Поскольку обе системы основываются на однопоточной модели исполнения, в них были придуманы одинаковые решения — цикл обработки очереди сообщений. Не удивительно что и та, и другая реализации склонны “зависать” и требовать “ребута”. В node.js концепция watchdog вообще считается нормой и самой собой разумеющейся.
При этом решение той же проблемы на основе вытесняющей многозадачности, лишенное детских проблем “зависаний” всей системы, было реализовано как в операционных системах UNIX (1969) так и в программировании — Erlang (1986). Причины, по которым авторы node.js решили изобрести свой велосипед, возможно были теми же, по которым C появился после Pascal — несовместимость американской и европейской школ программирования.
К слову, в том же 2009 году появился язык программирования Go, которые решает проблему массовой многозадачности гораздо более надежным способом — ”go routines”. Фактически, в нем реализован тот же принцип легковесной многозадачности, что и в Erlang.
Слепая эволюция
Эволюция слепа, и процесс эволюционного развития не предполагает построения “идеальной архитектуры” или проведения “полного рефакторинга”. Человеческий глаз имеет слепое пятно, из-за чего мозг вынужден достраивать недостающие части картинки, и это не обусловлено каким-то разумными ограничениями. Все можно было сделать гораздо лучше, если бы эволюция “пересмотрела” архитектуру глаза. Однако, эволюция так не работает — она никогда не перерабатывает имеющиеся решения с нуля, но лишь улучшает то, что есть. Подробнее о процессе эволюции зрения рассказано, например, в книге «Что, как и почему мы видим на самом деле».
Так же и язык C. С момента своего появления он изменяется и расширяется, но никогда не перерабатывается полностью. Сейчас мы имеем дело с монстром C/C++. Он содержит все врожденные проблемы управления памятью, неприлично обширный синтаксис, огромное количество библиотек и процесс компиляции, требующий отдельной вычислительной фермы. При этом он полон сил, активно развивается и вообще пышет здоровьем.
Другой пример — Java. Начиная с первой версии, в язык были включены примитивы многопоточного программирования. Конструкция “synchronized”, поддержка блокировок на уровне любого объекта и, простите, “Hashtable”. И вот это представили как решение проблем многопоточного программирования, объявили что Java — “concurrent” и выпустили в свет. Сейчас очевидно, что разработку многопоточного кода нужно основывать на принципах “stateless” и “immutability”, что для “concurrency” нужные специализированные структуры данных — “ConcurrentHashMap”, а блокировки стоит использовать только в крайних или специфичных ситуациях. Увы, фарш невозможно провернуть назад. “Hashtable” останется в Java навсегда, а необходимость рассказывать каждому новому разработчику, почему нужно использовать “StringBuilder”, а не “StringBuffer” — это крест, который несет все Java-сообщество.
В примере с Java важно, что такие “атавизмы” на самом деле никак не влияют на “живучесть” языка программирования. Все перечисленные проблемы были устранены в .Net изначально, и кому какое до этого дело.
Принцип острова
Новые виды наиболее активно появляются в новой изолированной среде. Такой средой может быть как остров в буквальном смысле, — Ява и ее малый оленёк или Мадагаскар с лемурами, так и озеро — например, Байкал и его прозрачная голомянка. Континент Австралия с населяющими его сумчатыми также является островом в эволюционном смысле.
Попав в независимую среду, виды начинают быстро эволюционировать и образовывать новые виды. Именно принцип острова определяет возникновение мейнстримных языков программирования.
Рассмотрим островное происхождение языка Java. То, что Java стал мейнстримным языком программирования, — по большому счету, случайность. Для этого не было никаких разумных предпосылок. Разработка Java началась в 1991 году (тогда язык назывался Oak). По легенде, основной платформой для исполнения Java-приложений должны были стать кофемолки. В целом это неудивительно, поскольку Java разрабатывалась в недрах Sun Microsystems — “железной” компании, так что разработка языка для встраиваемых систем там была вполне логичной. Но в 1993 году появился первый браузер Mosaic, и это все изменило.
Появилась совершенно новая, никем не занятая и не освоенная среда, полностью свободная от багажа предыдущего опыта и технологий. Никто не знал что и как в ней делать. И вот в 1995 году технологию Java представили миру. Правда, по нынешним стандартам, технология была так себе. Ирония состоит в том, что Java изначально позиционировалась как клиентский язык программирования, отсюда Applet — технология встраивания в браузеры, окончательно уничтоженный только в 2015, и обреченный с рождения браузер HotJava. Java стал одним из основных языков серверного программирования скорее вопреки задумке авторов. Справедливости ради, на то были разумные основания. В 1990-х, выбирая, на чем разрабатывать серверную логику — на C++ или Perl, любая альтернатива этим двум казалась бы лучшим выбором. А как серверная технология Java оказалась настолько хороша, что уже в 2002 году ее скопировал Microsoft.
Тем временем, в том же 1995 году появился JavaScript. Пользуясь полнейшим провалом Java на стороне клиента, он стал доминирующей технологией разработки клиентских приложения для веба.
Справедливости ради следует добавить что тогда же, в 1995 году появился PHP и занял экологическую нишу быстрой разработки. Вообще, эра веба крайне благоприятно сказалась на развитии языков на букву “P”.
Острова не только для языков программирования
Конечно веб не остался единственным островом. Среда меняется и новые доминирующие виды на них появляются регулярно. Просто это не языки программирования, а что-то другое.
Хорошим шансом для появления нового массового языка программирования стало появление смартфонов. Но не случилось. Apple по инерции использовала в iPhone (2007) Objective-C (1984), а Google — Java в Android (2008). Становление нового рынка было слишком горячим фронтом противостояния, чтобы отвлекаться на эксперименты (см. «Как поссорились Apple и Google»). Да, конечно есть Swift, но о нем вспомним чуть позже.
Другой островок появился где-то в районе 2009 года, когда все начали добавлять в веб-приложения поддержку WebSocket для обновления данных на странице в реальном времени. Так появились Node.js и Go, и вновь показался на радарах Erlang. Но несмотря на технологическое превосходство Go над Node.js и привычную семантику по сравнению с вычурным Erlang, Go не стал лидером, как, впрочем, и никто из его “коллег”. Островок оказался слишком маленьким и на базу для дальнейшей экспансии не потянул. А совсем недавно там добавился еще один обитатель-конкурент — Elixir (2012), адекватный синтаксис и исполнение в среде Erlang.
Остров интернета вещей — компьютер размером с пуговицу работающий от солнечной энергии на котором можно запустить Doom, это да. Сейчас в тренде смарт-часы, и это дает шанс добиться популярности новым операционным системам, например Tizen.
Остров машинного обучения в основном населяют C++ и Python, немного Java, иногда Lua (1993) и конечно R (1993). В целом машинное обучение — больше про алгоритмы и специфичные способы обработки данных.
Генная инженерия языков программирования
За время своего развития мейнстримные языки программирования накопили багаж негативных аспектов, которые хочется исправить. Периодически происходят попытки искусственно переломить ситуацию и создать “в пробирке” замену языкам “выросшим на воле”. Однако, нарушения законов эволюции пока не наблюдается. Новые языки программирования конечно добиваются определенных успехов, но только в узких областях, и о полной победе речи не идет. Вот только некоторые примеры.
Apple выпустила Swift на замену Objective-C в 2014. Похоже что дела в этом направлении идут неплохо, но нет причин ждать чего то большего.
В JetBrains устроили локальную революцию с Kotlin в 2011, решив переписать на него IDEA а заодно избавить весь мир от NullPointerException. Пока не помогло.
Google громко анонсировал Dart как “убийцу JavaScript” в том же 2011. Криминала, впрочем, не случилось, как и нативной поддержки Dart в браузерах. В целом Dart и TypeScript (2012) неплохо живут и компилируются в JavaScript, но свергнуть короля веба они оказались не в состоянии, хотя и существенно потеснили его в рамках разработки крупных проектов.
Mozilla решила переписать Firefox на Rust (2010). Распространение системы типов на многопоточность — это интересно, да и все остальное в Rust выглядит основательно. Есть одна загвоздка — на Go худо-бедно уже можно найти живые приложения, а вот от Rust выхлопа пока нет.
Мажорное обновление Python 3, ломающее обратную совместимость, сформировалось в 2006 и называется Python 3000. Первый релиз вышел в 2008. Судя по тому что Python 2 бодр, весел, и все еще с нами, изначальные оценки по внедрению третьей версии к 3000 году были недалеки от истины.
Если с Python дела обстоят более-менее серьезно, то инициативу Perl 6 уже можно рассматривать как анекдот. Начав разработки в 2000, с целью заменить Perl 5 (1994), Perl 6, похоже, все-таки зарелизили в 2015.
Следующего большого языка программирования не предвидится
Похоже, что дело обстоит именно так. Новых естественных островов, на которых мог бы закрепиться свежий лидер, похоже не планируется, а эксперименты по созданию новых языков не могут побороть инертность индустрии разработки. Пожалуй, это не так уж и плохо.
Отсутствие новостей — хорошие новости. Если вы планируете начать изучать JavaScript, Java, C#, Python или PHP, это стоит сделать. Мейнстримные языки с нами всерьез и надолго, и их знание всегда пригодится. При этом, новые языки вроде Rust или Go тоже имеют перспективу, возможно, не как замена всего и вся, но как инструмент для решения интересных задач.
Дмитрий Мамонов
Департамент разработки,
Подразделение мержа в мастер,
Отдел работы с гит,
Оператор баш консоли с “пробегом”
Комментарии (219)
potan
13.03.2017 14:29+3Есть ниша логических языков — прогресс в них медленный, но с ростом мощности компьютеров и объема оперативной памяти можно ожидать его ускорения.
К тому же нельзя исключать катастроф, вроде появления на порядок превосходящего традиционные компьютера с троичной системой счисления или появление доступных квантовых вычислений.
Karpion
16.03.2017 21:48+1С чего бы это троичный компьютер будет «на порядок превосходящий»?
А в квантовые вычисления я как-то не верю. Квантовый компьютер может одновременно решать много задач — но вот на выходе будет суперпозиция из всех этих решений. А разделение результата будет занимать много времени.dimm_ddr
17.03.2017 10:03+1В квантовый компьютер не нужно верить. Уже есть задачи, которые он решает лучше обычного, известны требования к таким задачам. Он не заменит стандартного, но дополнит его, как дополняют видеокарты например. Сейчас уже не стоит вопрос что можно с ним делать, сейчас стоит вопрос только как сделать достаточно дешевый и стабильный квантовый компьютер.
potan
17.03.2017 20:45+1С чего бы и нет? Откроют новый физический принцип, позволяющий сделать очень эффективную тристабильную ячейку, а бистабильную только игнорированием одного из состояний. Или ты знаешь почему это принципиально невозможно?
Ну все, надо сообщить в IBM и Google, что бы работы сворачивали.Karpion
19.03.2017 00:03Ну хорошо, тристабильная ячейка — ничего принципиально сложного я не вижу, чисто инженерная задача. Но как это может повысить скорость вычислений и/или ёмкость памяти сильнее, чем в полтора раза?
Что-то мне кажется, в IBM и Google кто-то пилит бюджет по грантам…
zolern
13.03.2017 14:40А я ставлю на то, что Nim (nim-lang.org) все же выстрелить, возможно еще в этом году. Гибкая система типов, мултипарадигма, приятный а-ля Python синтаксис и скорость выполнения как в C — это совсем как появление млекопитающих в мире динозавров: стильно, интересно и молодежно :)
Но почему ни слова о Haskell?
Yeah
13.03.2017 16:01+6Но почему ни слова о Haskell?
На данный момент в мире есть примерно 7 (семь!!!) коммерческих вакансий на Хаскеле: https://wiki.haskell.org/Jobs
Sirikid
13.03.2017 18:11+7На самом деле больше, не все вакансии публикуются на Haskell Wiki, большая часть закрывается через twitter, reddit, тематические сайты и чаты.
samsergey
14.03.2017 02:19+5Поищите вакансии математиков-теоретиков, их в сети будет не больше :) Но это не значит, что они не нужны и неконкурентноспособны.
develop7
14.03.2017 09:29Предположим на секунду, что это так. И что?
dimm_ddr
14.03.2017 09:56-1Тогда, по определению из статьи:
вымершими будем считать те языки, на которых никто не разрабатывает в настоящий момент
его нельзя назвать живым. Впрочем это верно, только если верно предположение, что если нет большого количества открытых вакансий, то никто ничего и не разрабатывает.
unclechu
14.03.2017 23:34его нельзя назвать живым.
Глупости. Я практически каждый день пишу на Haskell, можно пойти пособирать статистику коммитов по github-у какому-нибудь, из чего будет явно очевидно что на нём таки ежедневно пишет куча людей. Или сходите для разнообразия на #haskell на freenode, который обычно не замолкает более чем на несколько минут (ну ещё на ряд haskell-ориентированных более узко специализированных каналов вроде #haskell-lens, #haskell-beginners, #haskell-game, #haskell-infrastructure, etc). Один приятель ведёт стримы, где пишет на Haskell: и т.д. и т.п. Мне известна компания в городе, где я раньше жил, которая использует Haskell для критически важных частей своей системы. В настоящий момент на нём-таки разрабатывают, и не полтора анонимуса.dimm_ddr
15.03.2017 10:39Я и не утверждаю что это именно так. Но «я каждый день пишу» не попадает под данное определение живого языка. Компания с критической частью написанной на хаскеле — уже да, попадает. Вопрос в том, сколько всего таких компаний и как это оценить. Самый простой способ оценки, хоть и естественно крайне ненадежный — по количеству открытых вакансий, этот способ используется часто. Честно говоря навскидку сказать как еще можно объективно оценить количество разработчиков на хаскеле я не знаю. Опрос мог бы сработать, но это надо очень заморочиться. Можно оценивать по коммитам в гитхабе, но, во-первых, здесь есть свои недостатки — так можно оценить только опенсурс, а, во-вторых, таким образом мы не оценим большую часть разработки для продакшена — там до сих пор далеко не все пишут код в открытую. А именно код для реальных продуктов и является критерием живости языка по определению автора статьи.
Поэтому, хотя ваш опыт безусловно имеет некоторую ценность, нельзя сказать что это объективный показатель. Собственно как и мой, как и чей либо еще. Это только слабое свидетельство в пользу, но никак не доказательство.
Каналы на фриноде тоже не могут таким доказательством считаться — они точно также никак не отображают количества людей разрабатывающих на хаскеле профессионально.
Тут ключевое — это то, как автор определил живость языка. У вас, как мне кажется, несколько другое понимание этого термина и в таком понимании хаскель безусловно жив.unclechu
15.03.2017 11:07Я и не утверждаю что это именно так. Но «я каждый день пишу» не попадает под данное определение живого языка. Компания с критической частью написанной на хаскеле — уже да, попадает.
Вы же сами сослались на определение, под которое-таки попадает:
вымершими будем считать те языки, на которых никто не разрабатывает в настоящий момент
Это уже боюсь ваши личные какие-то критерии и оценки, я обратил внимание именно на озвученный критерий, по которому вы и возразили, что якобы ему не соответствует, но ведь это не так от слова «совсем».
А личные критерии «о живости/мёртвости» языка программирования, — это такая разношёрстная и отнюдь не единогласная солянка, что я бы не стал придавать отдельным частностям какое-либо значение, если только критерии чётко и стройно не сформулированы. Я вот например вообще не связываю понятие «живости» языка с деятельностью коммерческих компаний, что видимо входит в прямое противоречие с вашим видением, но это моё личное и сюда я не вплетал.
Тут ключевое — это то, как автор определил живость языка. У вас, как мне кажется, несколько другое понимание этого термина и в таком понимании хаскель безусловно жив.
В том всё и дело, что я зацепился за авторское определение:
Используя аналогию с устной речью, вымершими будем считать те языки, на которых никто не разрабатывает в настоящий момент. Даже если компиляторы этих языков существуют, программы на них написанные можно запустить, а некоторые “историки программирования” все еще могут написать на них новый код.
Понимая его буквально, без каких-то особых личных «додумок» за кулисами, не добавляя ничего своего. В рамках этого определения Haskell бесспорно — жив.dimm_ddr
15.03.2017 13:59+1Да, вы правы, это я неправильно прочитал авторское определение. Претензий нет, в данном варианте все мои размышления не имеют смысла.
Source
15.03.2017 12:54Честно говоря навскидку сказать как еще можно объективно оценить количество разработчиков на хаскеле я не знаю.
Есть же рейтинги популярности ЯП. Например, по данным Redmonk он занимает 16-е место (между Go и Swift). Да, он только по данным Github и StackOverflow, но это даёт представление о размере сообщества.
Самый простой способ оценки, хоть и естественно крайне ненадежный — по количеству открытых вакансий
Я всегда считал, что кол-во открытых вакансий показывает показывает насколько рабочих мест больше, чем подходящих специалистов. Если их примерно поровну, то кол-во открытых вакансий будет стремиться к нулю, даже если есть миллион трудоустроенных специалистов. Разве не так?
dimm_ddr
15.03.2017 14:04В целом я неправильно понял авторское определение, так что вы правы конечно. Но если считать живыми языки на которых разрабатывают коммерческие продукты, то гитхаб уже не может являться адекватной метрикой. СО впрочем будет относительно актуален и в этом случае, да.
Насчет открытых вакансий. В общем случае вы тут тоже правы, но можно учесть большую текучку кадров и частую смену работы программистами — сейчас это очень распространенное явление. А раз это явление распространено, то, при миллионе работающих программистов вакансий будет тоже много просто из-за текучки. С другой стороны я не могу утверждать, что это верно для любого языка. В среде людей пишущих на коболе или фортране, например, текучка может быть (и скорее всего есть) гораздо меньше.
yarric
13.03.2017 21:52+2Скорость выполнения — как в C, и при этом — со сборщиком мусора? Любопытно...
unclechu
15.03.2017 20:07Я даже так скажу, можно писать на C, при этом писать на Haskell.
А вообще нужно иметь в виду что раскладывать и оптимизировать чисто-функциональный код на порядок проще, чем завязаный на последовательность действий и постоянные мутации состояния, эдакое педалирование регистров ручным приводом, не говоря уже о том, что чисто-функциональный код пустить в плеяду тредов ничего не стоит, чего отнюдь нельзя сказать об C например. Haskell помимо всего прочего по-настоящему «ленив», он не станет маппать весь список из 9000 элементов, если в итоге из него понадобилось только 3, замаппится только 3 элемента из 9000. Суммируя все особенности, можно зачастую получать больший перформанс, чем эквивалентная по смыслу реализация на С, но есть различные нюансы, которые нужно понимать и иметь в виду. Но основная соль-то даже не в этом, вот взять систему типов, тайпклассы, настоящий лаконичный полиморфизм, не перегруженный необходимостью писать полотна мета-манускриптов, чтобы сделать код действительно абстрактным, как это происходит с случае с C++ каким-нибудь, C даже рядом поставить не получится.
qadabr
14.03.2017 00:24+3Честно говоря, не сказал бы, что у Python такой уж и приятный синтаксис.
Source
14.03.2017 13:08Тогда есть Crystal с приятным синтаксисом в стиле Ruby. Он и постабильнее, чем Nim, будет… сравните кол-во открытых issues на Github. По быстродействию в среднем где-то между C и Go.
develop7
14.03.2017 18:21+3Не сказал бы, что и у Ruby приятный синтаксис (4 года работы с).
UPD: у Elixir приятный синтаксис, да и DSL легче отлаживать (за счёт гигиеничных макросов).
am-amotion-city
14.03.2017 19:47DSL легче отлаживать (за счёт гигиеничных макросов)
Вы отлаживаете чей-то чужой DSL, или не можете себя заставить писать DSL без протечек сущностей? Дык гигиену тоже можно обойти:
Kernel.var!/2иKernel.alias!/1:)
janatem
13.03.2017 14:41+6Есть старая, но почему-то плохо заполненная ниша языка описания аппаратуры. Есть Verilog и VHDL, несущие дух своей эпохи 80-х. Новое пока зарождается только в виде экспериментальных языков, которым пока не удается пробиться в промышленность.
zolkko
13.03.2017 14:47Почему-то на картинке у o'reilly ISWIM и ML не имеют ничего общего, хотя читая статью (http://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf) у меня было ощущение, что таки ML прямое развитие.
И communicating sequential processes и actorы это фактически две разные модели.
potan
13.03.2017 14:56+4И еще об эволюции. Есть такое учение «трансгуманизм», которое утверждает, что эволюция человека продолжается, только уже не методом отбора, а разработкой кибернетических имплантантов, генной и тканевой инженерии и тп.
Так и в языках программирования пора уходить от естественного отбора в сторону «разумного дизайна».
Neftedollar
13.03.2017 17:37что и происходит исходя из статьи, только в статье говорится о том что в целом это не сильно работает. Но путь в тысячи ли начинается с шага. И конечно привет H+
WinPooh73
14.03.2017 10:45В условиях свободной конкуренции это вряд ли возможно. Как минимум, потребуется мощная организующая сила с ресурсами, суммарно превышающими возможности крупнейших корпораций. Думаю также, что каждый из создателей больших языков, от Бьярна до Гвидо, далее везде, готов привести массу доводов о том, что его-то дизайн как раз и есть самый разумный.
potan
14.03.2017 12:21Сам Хокинг предложил создать мировое провительство. Надеюсь, в его компетенцию войдет разработка языков программирования. :-)
dimm_ddr
14.03.2017 14:41+2Я надеюсь что не войдет. Страшно представить каким будет язык, разработанный в правительстве. Да еще и в условиях монополии правительства…
unclechu
15.03.2017 20:15Если понаблюдать за «правительством», то можно предположить, что это будет в лучшем случае PHP. Но сдаётся мне что с задачей вообще не справятся, тут ведь нужен какой-никакой интеллект, а не букетик условных рефлексов.
Tiendil
13.03.2017 15:02+6>Следующего большого языка программирования не предвидится. По крайней мере, на то нет причин с точки зрения теории эволюции.
Совершенно неверный вывод из верных посылок.
Эволюция идёт во многом балгодаря изменичивости окружающей среды, а в нашей отрасли она крайне изменчивая.
Есть увеличение сроков изменений, но оно обусловлено взрослением индустрии и ни в коем случае не свидетельствует о конце времён.RomanArzumanyan
13.03.2017 15:44+2+1. Например, языки программирования для квантовых компьютеров.
xPomaHx
14.03.2017 04:35+3Нет. Развитие квантового компьютера выльется в что то типа видеокарт, то есть доп. плата в комп вставляется, а ОСь уже решает для каких задач что использовать. Так что новых языков не будет, будет какая то небольшая надстройка над существующими типа cuda.
dimm_ddr
14.03.2017 10:00А почему не как FPGA например? Их тоже можно подключать к обычному компьютеру, но пишут для них на специфичных языках.
impwx
14.03.2017 11:17+3Для видеокарт есть языки шейдеров, которые несмотря на сходство с С все-таки имеют несколько самобытных особенностей. С квантовыми «приставками» будет аналогичная история — несколько языков для квантового программирования уже написано.
3draven
13.03.2017 15:03-2Следующий язык будет включать прямую работу с нейросетевыми структурами и многопоточность в смысле работы таких структур. Так же как С включал структуры как наборы «однопоточных» данных.
bm13kk
13.03.2017 15:32+1Хорошая статья, мне понравилось.
Но она построена на неверной предпосылке. Остров — это благоприятная среда для революций (быстрых скачков эволюций, происхождению новых видов.). Однако большинство новых видов появилось в обычных уловиях, уже занятых местах.
dm_wrike
14.03.2017 01:09+1Распространение кроликов (в австралии) стало самым быстрым распространением млекопитающего вида в известной истории.
Остров нужен чтобы «кролики» появились и окрепли, а когда они окажутся в «австралии» их уже будет не остановить.
Но подходящей изоляции, кажется, нет.
Однако большинство новых видов появилось в обычных условиях
Да, и сейчас мы наблюдаем расцвет языков программирования. Их много, много новых, и многие из новых хороши.
С разнообразием, как раз, все в порядке.
Просто никто из новичков не станет лидером.
vlanko
13.03.2017 15:34Значит новый язык возникнет тогда, когда нормально научатся писать в мозг или читать.
Crandel
13.03.2017 15:41+3Почему то все забыли про квантовые компьютеры, для которых необходим совершенно другой язык программирования
dimm_ddr
13.03.2017 16:51+3Мне кажется что в ближайшие лет 10-15 квантовые компьютеры будут все еще большой редкостью и языки для их программирования будут распространены на уровне нынешних эзотерических. В таком ключе посыл статьи вполне адекватен — в ближайшем будущем нового языка не предвидится. Это не значит что их не будет, это значит что они будут очень сырыми и на них почти никто не будет писать. Более того, весьма вероятно что, когда квантовые компьютеры таки войдут в повседневную жизнь, эти языки уже будут вполне себе мертвыми а жить будет нечто построенное на их костях.
dm_wrike
14.03.2017 01:02+5Хорошее замечание, но!
Даже если квантовые вычисления случатся — они будут крайне ограниченными.
Для них будут использовать специальные микропрограммы, как для шейдеров в графике,
которые будут встраивать в программы на обычных языках программирования.
Magic_B
13.03.2017 15:59+5Какое-то очень смелое заявление, как-будто все человеку известно наперед.Очень сомневаюсь, что вообще грамотно, делать подобные заявления…
По поводу нового языка программирования, как мне видится, можно рассматривать с точки зрения либо нового устройства компьютера либо самого процесса программирования. В любом случае, для компьютеров настоящего любой код — компилируется в машинный…
Я бы представил программирование завтрашнего дня в терминах распределенных вычислений…
realbtr
13.03.2017 16:50+1Не обязательны низкоуровневые нейросетевые структуры. Скорее речь может пойти о гетерархических онтологиях, когда над ними появятся внятные формальные операции вывода.
Но в целом, самое первое, что произойдет: будущий большой язык программирования свяжет ландшафты платформ воедино. Это будет замена фреймворков и платформенных «миксджетов», вероятно.
Просто сейчас все эти «гены-мемы» не очень-то просматриваются. Чтобы язык программирования стал большим он должен дать очередную волну массовости. То есть то, что сейчас делается большими усилиями глубоких специалистов должно стать массовым развлечением.
И в этом смысле, конечно же, есть предпосылки для множества новых языков. Огромного множества.
Просто пока об этом рассуждают люди не понимающие глубины «трендообразования», они не способны такие гены разглядеть.
Просто посмотрите сейчас на разнообразие средств программирования и множество узкоспециализированных систем, изучение и использование которых крайне дорого (трудозатратно) и Вы увидите лакуны для новых больших языков.
Можно просто взять тот же хабр по хабам и посмотреть на разнообразие сильно специализированных статей. Вот и перечисление будущих фич будущих языков.
Казалось бы, все идет по пути синтаксического сахара и новых онтологий, но если посмотреть на платформенный ландшафт, то очевидно, что идет только заполнение лакун. Так и работает естественный отбор. Как только некая фича оказывается достаточно значимой для организма или системы, она начинает трансформировать генотип или мемотип.
UA3MQJ
13.03.2017 16:58+4К слову, в том же 2009 году появился язык программирования Go, которые решает проблему массовой многозадачности гораздо более надежным способом — ”go routines”. Фактически, в нем реализован тот же принцип легковесной многозадачности, что и в Erlang.
Go уже научился прерывать работу зацикленной горутины, считать редукции?kolo2012
13.03.2017 19:04-4простите, но зачем ему это? Вы должны сами следить за этим.
UA3MQJ
13.03.2017 19:42+6Для вытесняющей многозадачности. В данном случае легковесной. Чтобы всем легковесным процессам гарантированно выделять процессорное время. Если процесс по какой-либо причине «зависнет», то Go приложение потеряет один из своих thread'ов выполнения? Приложение Go научилось как-то контролировать зависшие корутины и как-то решать этот вопрос?
Я именно спрашиваю, а не утверждаю. Потому что, очевидно, Golang развивается. И может быть там эти решения появляются. И я бы хотел об этом узнать, если так.
Моя критика тут в том, что утверждение в выделенной мной цитате, ИМХО не соответствует действительности. Ни первое, ни второе:
К слову, в том же 2009 году появился язык программирования Go, которые решает проблему массовой многозадачности гораздо более надежным способом — ”go routines”.
Более надежным способом, чем где? Чем в windows 1? Принцип тот же: процесс завис — система зависла. В Go приложении корутина зависла — приложение зависло. Спасает только то, что Go приложение берет gomaxprocs по умолчанию больше, чем 1. Если выставите 1, то приложение зависнет на горутине. Никаких средств переключения на другую корутину нет. Никаких средств прибить зависшую корутину нет. А проблема массовой многозадачности — ну да, решается. Только переключения между горутинами происходит в момент вызова функций внешних библиотек.
Фактически, в нем реализован тот же принцип легковесной многозадачности, что и в Erlang.
Даже рядом нет. Потому что у ерланга виртуальная машина интерпретирует код, поэтому может легко в любой момент переключаться между процессами. В го нет никакого интерпретатора или виртуальной машины.Stronix
13.03.2017 22:08-3В Go приложении корутина зависла — приложение зависло. Спасает только то, что Go приложение берет gomaxprocs по умолчанию больше, чем 1. Если выставите 1, то приложение зависнет на горутине.
In prior releases, a goroutine that was looping forever could starve out other goroutines on the same thread, a serious problem when GOMAXPROCS provided only one user thread. In Go 1.2, this is partially addressed: The scheduler is invoked occasionally upon entry to a function. This means that any loop that includes a (non-inlined) function call can be pre-empted, allowing other goroutines to run on the same thread.
Вполне себе завершаетсяpackage main import ( "fmt" "runtime" "time" ) func main() { runtime.GOMAXPROCS(1) go func() { for { fmt.Println("Endless loop...") } }() time.Sleep(300 * time.Millisecond) fmt.Println("Exiting main program..") }UA3MQJ
13.03.2017 22:28+3А если в цикле без вызова fmt? Например, какой-нибудь i=i+10, а Print уже за пределами цикла?
Ну то есть, как будто бы в цикле какой-то сложный расчет, который залип.
Внешний вызов — он да, как раз позволит прервать эту корутину. Я об этом и писал.
Может какой-то есть аналог yield или Application.ProcessMessages?Stronix
13.03.2017 22:37+1develop7
14.03.2017 09:36+2Правильно ли я понимаю, что в коде, который может выполняться существенное время, предлагается вызывать эту функцию вручную?
Stronix
14.03.2017 11:45Да.
Кстати, а когда может понадобиться ограничивать приложение одним потоком, ну разве кроме редких случаев жесткой оптимизации?
napa3um
13.03.2017 17:18+12Рождение нового вида в экосистеме — это событие класса «чёрный лебедь», событие фазового перехода в хаотической (квазистабильной открытой динамической) системе. Невозможность предсказать «лебедя» вы же сами и показали, рассказав о «случайном» становлении Джавы или Ноды. Так что от предвидения или непредвидения, похоже, появление новых массовых ЯП не зависит, и когда они появятся, мы так же сможем ретроспективно пытаться понять причины их появления, но следующий ЯП возникнет по совершенно другой причине.
dm_wrike
14.03.2017 00:58+1В действительности инновации не происходят внезапно, они тщательно готовятся.
На 1995 пришелся «массовый старт» интернета, при том Dial Up соединения были доступны и ранее.
Возможно я что то упускаю, но в списке «Острова не только для языков программирования»
нет чего то столь же масштабного, по крайней мере такого что еще не «выстрелило».
Возможно я скептик, но сомневаюсь что за углом нас ждет новый, не открытый, континент.napa3um
14.03.2017 01:07+1У вас просто ещё недостаточно опыта для футурологических прогнозов. Опыт придёт, когда на вашем веку из-за угла появится несколько неожиданных континентов (о которых вы потом почитаете, насколько они долго и тщательно готовились). Несколько континентов в комментариях уже попробовали примерить — это и языки для распределённых приложений поверх блокчейнов, и языки для выразительного описания нейросетей и их обучения, и языки для квантовых вычислений. На ваш век ещё хватит инноваций в сфере ИТ точно (если метеорит не упадёт или ядерным грибом не накроет раньше).
dimm_ddr
14.03.2017 10:05если метеорит не упадёт или ядерным грибом не накроет раньше
Если после такого в живых останется хоть сколько-то много людей, то инноваций в ИТ будет море — знания во многом есть, а рук для выполнения работ хватать не будет — автоматизация будет крайне необходимой и, скорее всего, сложно настраиваемой. Только полное уничтожение человечества может спасти ИТ от инноваций.napa3um
14.03.2017 10:12И это только вершина айсберга всех возможностей для появления нового ЯП. Столько случайности в человеческой жизни, ужас.
SergeyVolodko
13.03.2017 19:04+2А как же островок блокчейна с его Этириум смарт-контрактами и тому подобными? Среда похоже довольно изолированная, благодаря новой архитектуре, и благоприятная, так как деньги вливаются, Там вполне может вырости что-то джаваскрипт-подобное с заточкой под транзакции, безопасность, или какие-то ещё нужды финтеха.
khim
13.03.2017 20:10-1Существуют десятки и сотни островков где живут разные диковинные виды типа того же форта или Scheme. Однако чтобы стать новым «большим» языком ниша должна «захватить индустрию».
Android этого не сделал, следующая надежда — на IoT. Но там вначале должна произойти крупная катастрофа, возможно, с человеческими жертвами, для того чтобы люди отказались от подхода «тяп-ляп и в продакшн».
massimus
13.03.2017 21:42Про убийц Javascript: может, его сожрут не снаружи, а изнутри? Он сам стал Австралией, кишащей бурно размножающимися, мутирующими и дохнущими сумчатыми яйценесущими фреймворками. Вдруг один из них так удачно приспособится, что вырастет в самостоятельный язык и захватит веб?
napa3um
13.03.2017 22:02+3Фреймворки кишат, в основном, потому, что в стандартной веб-платформе многого «взрослого» из мира разработки не хватает. Но с WebComponents и WebAssembly «системные» фреймворки вымрут, мне кажется, а место их экосистемы займут каталоги готовых компонентов и библиотек компонентов. (Комментарий следует читать с придыханием, как о светлом коммунистическом будущем.)
impwx
14.03.2017 11:32Лет десять назад казалось, что таким фреймворком станет jQuery. Многие начинающие разработчики считали ее и сам язык javascript синонимами, поэтому вопросы вида «как сложить два числа на jquery» (sic!) встречались довольно часто. Однако сейчас она все чаще встречается как основа для более высокоуровневых фреймворков.
NickKolok
18.03.2017 01:02jQuery выстрелила и закрепилась потому, что она соединила две абстракции: DOM-элемент и CSS-селектор. Это на самом деле математика. Выживает та абстракция, которая обобщает существующие красиво, логично и востребованно.
zviryatko
16.03.2017 00:47Мм… Это как Zend Engine и php? Было бы неплохо за этим понаблюдать, может и язык лучше станет.
yarric
13.03.2017 22:00За последние 30 лет принципы работы компьютеров не изменились, как и не изменились основные концепции программирования. Я считаю, что нужно делать больший упор на создании и развитии фреймворков под конкретные задачи для существующих относительно низкоуровневых языков программирования, а не изобретать каждый раз велосипед.
Хорошие примеры расширения существующих языков фрейморками: JavaScript (Angular, Ember, React), PHP (Laravel), Java (Spring), C и C++ (Macintosh Toolbox, Qt, Gtk).
napa3um
13.03.2017 22:08> как и не изменились основные концепции программирования
Изменились задачи и способы (или, скорее, масштабы) их реализации. Фреймворки и ЯП ведь не только «математические» новые принципы и фичи несут, они так же упрощают в проекте взаимодействие людей с очень разными ролями. Написать что угодно можно и на ассемблере, а вот чтобы написать это быстро, с миниумом багов и задействовав сразу кучу программистов, а потом ещё чтобы это поддерживалось много лет, — вот это уже нужно покумекать, какой инструмент выбрать. Я считаю, что нужно делать больший упор на экономику ИТ-отрасли, а не на идеалистические представления о том, каким должен быть сферический ЯП в вакууме.
Gorthauer87
13.03.2017 22:14Статья забывает про массовые вымирания. Нечто может поменяться и целая ветка очень быстро отправится на мороз. Вот тут нишевые языки могут внезапно стать мейнстримом.
Плюс старые языки уже не могут быстро адаптироваться к изменениям. А новые могут наследовать их лучшие свойства, убирая слабые. Рано или поздно старый яп внезапно может умереть, например, вместе со своим островом.
А вообще, если понимать программирование на уровне "генов", то можно легко адаптироваться к тому, как все течет и меняетсяdm_wrike
14.03.2017 00:34-2Хорошим примером массового вымирания является LISP.
В 1980-х были очень популярна концепция экспертных систем построенных на LISP,
дело дошло до того что выпускали компьютеры исполняющие его непосредственно (lisp machines).
Но в какой то момент стало понятно что идея тупиковая, и и все довольно быстро прекратилось.samsergey
14.03.2017 02:30+3Боюсь, что опыт Closure и Emacs вы не учитываете. Попытки построить рефлексию в современных языках показывают, что Лисп нужен и нужен, похоже, будет всегда, как нужна математика.
Вот если бы Брендан Эйх выполнил требования спецификации к языку для Netscape и написал Scheme-подобный язык (да с макросами, и с оптимизацией хвостовой рекурсии...) то масса новичков-программистов не удивлялась бы скобочкам, а бодро изучала SCIP и это, правда, пошло бы им и всем нам на пользу.
Уверяю вас, о Лиспе в том или ином виде, вы будете слышать всегда. Он невероятно живуч. Это ли не победа в эволюционной борьбе?dimm_ddr
14.03.2017 10:09+6Лисп в этом смысле похож на крокодила — существует давно, уходить не собирается и в определенном месте сожрет кого угодно, но вот яблоки им собирать все-таки неудобно.
potan
14.03.2017 16:29Ясно не стало. Более того, Clojure сейчас достаточно популярный язык.
Просто обралось слишком большое комьюнити, очень чувствительных к тому, где писать знак операции — если он не между операндами у них начиналась паника.
Alexey2005
14.03.2017 18:01+5Скорее уж примером вымирания можно назвать Delphi. В России на нём было написано просто чудовищное количество софта, он был невероятно популярным. Его интеграция с БД, возможность быстрого прототипирования и компонентный подход (не знаешь как решить задачу — скачай компонент, который её решает) обеспечили ему громадное преимущество.
Но вымер. Вымер резко, внезапно и без каких-либо предпосылок к этому. Наверное, историки до сих пор гадают, как так получилось.
vedmedved
14.03.2017 00:24+2В начале статьи автором допущена серьёзная логическая ошибка — неоправданное расширение законов эволюции на другую область.
Эволюция работает не только в животном мире, но и в любой подходящей среде.
Это не аксиома, а утверждение, которое нужно сначала доказать, но автор почему-то принимает его за истину и строит на нём все дальнейшие рассуждения. А так как это утверждение ложно, то дальнейшие рассуждения не имеют смысла.
Думаю, что многим будет полезно ознакомиться с учебником логики, чтобы самим не делать подобных ошибок и сразу видеть их у других.napa3um
14.03.2017 00:37+2Думаю, вам будет полезно хотя бы Докинза почитать, на которого автор сослался. Эволюционные принципы уже очень давно вылезли за пределы биологии, и ни у кого нет сомнений в том, что эти принципы математические, а не следствие какой-то божественной природы живой материи. Эволюция проявляется в очень широком классе естественных и неестественных систем, состоящих из множества однородных элементов, во взаимодействии которых можно сформулировать репликацию, изменчивость и отбор. Так же как и термодинамические модели не обязательно применять к физическим задачам, они хорошо себя показывают и в социологии, например. Ограниченность кругозора не всегда возможно компенсировать логикой.
vedmedved
16.03.2017 01:30+2Ваш комментарий очень показателен, поэтому считаю нужным разобрать его подробно.
Думаю, вам будет полезно хотя бы Докинза почитать, на которого автор сослался.
Откуда вы знаете, что я его не читал? Например, совершенно очевидно, что вы не читали учебник логики, но то что я не читал Докинза ниоткуда не следует.
У Докинза та же самая проблема, что и у автора — неправомерное расширение законов на другую область. Но даже если мы на минуту допустим, что Докинз прав, то это вообще никак не доказывает правоту автора статьи, потому что это три совершенно разных области, поэтому любые выводы и законы одной области совершенно неправомерно применять к другой без доказательств.
Эволюционные принципы уже очень давно вылезли за пределы биологии
Что значит «вылезли за пределы»? Развитие (эволюция) происходит в совершенно разных областях, но из этого не следует, что всё и везде развивается по одним и тем же законам.
и ни у кого нет сомнений в том,
Это классическая манипуляция. У меня есть сомнения, поэтому ваше утверждение ложно. Более того, у меня есть не только сомнения, но и доказательства ложности этого утверждения.
эти принципы математические
Всё наоборот, не эти принципы были выведены из математики, а были построены математические конструкции, взяв за основу некоторые из этих принципов. Но почти всё что угодно можно описать математическим языком, так что это ничего не значит.
не следствие какой-то божественной природы живой материи
Причём здесь это? Не надо приписывать мне утверждений, которых я не делал.
Эволюция проявляется в очень широком классе естественных и неестественных систем, состоящих из множества однородных элементов, во взаимодействии которых можно сформулировать репликацию, изменчивость и отбор
Для лучшего понимания слово «эволюция» здесь лучше заменить на слово «развитие».
И развитие действительно происходит в очень широком классе систем, только в каждом классе оно происходит по своим законам. Дарвин вывел законы эволюции только для биологии, и никто ещё не доказал, что эти законы также действуют во всех остальных системах. Даже если есть какие-то общие законы с другой системой, то это совершенно не значит, что в другой системе будут действовать и другие законы.
Так же как и термодинамические модели не обязательно применять к физическим задачам, они хорошо себя показывают и в социологии, например
Где доказательства? Возможно, какие-то модели и действуют, и что с того? Если доказана применимость модели к другой области — то всё отлично, но если доказательства нет — то это всё что угодно, но не наука. Это может быть религия или обычное балабольство, но чаще всего этим пользуется лженаука.
Ограниченность кругозора не всегда возможно компенсировать логикой
А какой смысл в кругозоре, если он практически целиком состоит из заблуждений и логических противоречий? К сожалению, такое сейчас не редкость.napa3um
16.03.2017 01:36Это называется не логика, а демагогия. Разбирать по частям не считаю нужным, уж простите.
dm_wrike
14.03.2017 00:39Вы несправедливы.
Кажется, что выполнение этих требований для языков программирования достаточно очевидно.
Я игнорируют только доказательство утверждения непосредственно, но не необходимость доказательства.
Есть тонкая разница.
Было бы куда правильнее привести существенную аргументационную базу в подтверждение базового предположения,
но и безумно занудно, при том.
dimm_ddr
14.03.2017 10:16Вам в целом уже все сказали другие комментаторы, но я не удержусь и все-таки тоже немного позанудствую.
Ваше утверждение что утверждение автора ложно тоже не аксиома и требует доказательства. Пока же такого доказательства нет автор вполне вправе делать предположения и выводы из них. Если его начальное утверждение окажется верным — все его утверждения (если в них нет самостоятельных логических ошибок) будут верны. Если не верным, то, в общем случае, выводы не будут иметь смысла. Но в данном конкретном частном случае, возможно, может получиться скорректировать первоначальное утверждение и выводы из него так, чтобы рассуждения остались корректными.
В математике это достаточно распространенный случай, когда на недоказанных утверждения строятся новые конструкции и делаются выводы. Не имеет смысла работать только с уже доказанно ложными утверждениями.
ffibonacci
14.03.2017 00:24+1вилами по воде.
насколько язык должен распространиться, чтобы называться «большим» языком программирования?
P.S.
Если даже подвести статистику появления новых ЯП за последние 10 лет — статья уже кажется абсурдной.
Jef239
14.03.2017 03:17+1На самом деле «островов» хватает, а вот языков для них мало. Раз, два — и обчелся…
- FPGA. Verilog? VHDL?
- Сверхмалый embeded. FORTH?
- SIMD. APL?
- Транспьютеры и графические сопроцессоры. Occam?
- ПЛК. Ladder?
- DSP.???
Думаю, что на стыке verilog, matlab и apl появится язык для массового проектирования FPGAdimm_ddr
14.03.2017 10:19+1Ну попытки сделать язык заметно более высокого уровня чем Verilog или VHDL предпринимаются регулярно. Проблема в инертности отрасли и недостаточной массовости самих FPGA — это все еще слишком дорогое решение для многих задач. Часто дешевле арендовать часть времени обычного сервера и производить вычисления на нем.
samsergey
14.03.2017 03:34+7Полезно помнить, что отношение порядка определено не на всех множествах. Нельзя сказать, что одна точка в пространстве больше другой, нельзя сравнивать комплексные числа. Когда об этом забывают начинаются священные войны — все правы и никто не прав.
Сравнивая эволюционные ветви, можно обратить внимание на численность представителей вида, семейства или отряда. В этом смысле Земля — планета жуков, а не людей. Мы построили города, а поселились в них тараканы и голуби. В IT-сфере в этом смысле победят не С, не Haskell и не Ruby, а HTML, CSS и плохие программисты, их просто много и они постоянно откуда-то появляются, хватают самый простой для пищеварения язык, что непонятно выплёвывают и пишут, пишут… :) Новые успешные в этом смысле языки появляются вместе с новыми технологиями и новыми потребностями (например, веяниями моды).
Можно сравнить кто кого победит в схватке. Тут на Земле человеку с автоматом нет равных. В программировании во время соревнований сильнейший язык выбрать трудно. Я бы, если мне нужно было выбирать язык для себя, выбрал Haskell или Mathematica :) в первом можно быстро написать мощную и корректную программу, во втором — воспользоваться гигантской базой знаний и гибкостью, унаследованной от Лиспа. Python и R — тоже подходят, но мне они не практически нужны были в моей работе. Новый сильный язык родится тогда, например, когда параллельные вычисления станут формализованы до такой степени, чтобы об этом мог позаботиться компилятор. Мы наблюдали такое, когда родились сборщики мусора — классная история!
Можно сравнивать живучесть. Бактерии термофилы заняли нишу экстремальных температур и ни с кем не конкурируют. Их никто не съест — сварится, а они съедят кого угодно, варёного. Ледяные черви научились жить в снегу, а человек на вездеходе есть повсюду. В программировании такие экстремальные ниши будут появляться всегда. И всегда будут рождаться разновидности FORTH или того же Лиспа, просто в силу простоты реализации и интерпретации. И человек с С (или, возможно, с Rust) тоже будет повсюду.
Наконец, есть долгожители. Это тоже эволюционный успех! Хрящевые рыбы, гаттерии, гинкго и другие представители живой природы, хоть и немногочисленны, пережили массовые вымирания и населяют планету миллионы лет. Лямбда-исчисление, насление Дональда Кнута, а также Лисп, с нами надолго и, похоже, навсегда. И они не просто существуют, они развиваются! Mascyma, Wolfram Mathematica, Maple — это достижения Лиспа и филигранно отточенных алгоритмов! Haskell развивается медленно, и каждый свой шаг обмозговывает, обсуждает, но при этом рьяно ощупывает множество перспективных направлений. Может быть, он эволюционирует и изменится, но идеи, родившиеся благодаря ему, никуда уже не денутся. Именно на Haskell реализованы языки для формального доказательства теорем: Agda, Coq и Idris. Это тоже кусочек будущего.
Сила биосферы Земли в её разнообразии. Если человек, как самый сильный всех победит, ему же хуже будет. То что языков программирования много это очень хорошо, а вот сравнивать их и называть победителя неверно.
misha_shar53
14.03.2017 04:55-1Эволюционное развитие по определению не предполагает революционных изменений. Но это не доказывает, что их не может быть вовсе. Как раз наоборот. Вообще то раньше в высших заведениях изучали философию и даже заставляли по ней сдавать экзамены. Так вот там написано, что эволюционное развитие время от времени прерывается революционными изменениями. И этот закон философии назывался переход количественных изменений в качественные. Как только количественных изменений будет достаточно они перейдут в качественные и эволюционное развитие перейдет на другой уровень. Так что вопрос о появлении качественно нового языка следует не из теории эволюционного развития. Вопрос в том накопилось ли достаточно новых эволюционных идей для качественно нового языка. Я считаю что да. И в ближайшее время возможно появление качественно нового языка, который сотрет со сцены все предыдущие языки программирования.
dimm_ddr
14.03.2017 10:25+1Вообще то раньше в высших заведениях изучали философию и даже заставляли по ней сдавать экзамены.
И сейчас учат и заставляют, вопрос только в том, какой именно части философии учат. Нам например рассказывали исключительно о первых древнегреческих философах, половина из которых даже не удосуживалась доказывать свои утверждения. Интересно, но практического применения никакого. Разве что как база для дальнейшего изучения.
samsergey
14.03.2017 05:33+2А ещё странно, что ни автор, ни комментаторы не упоминают лекцию Роберта Мартина "The last programming language", в которой эта тема подробнейшим образом освещается. Очень рекомендую её всем интересующимся историей ЯП.
am-amotion-city
14.03.2017 09:48+2То, что Java стал мейнстримным языком программирования, — по большому счету, случайность.
А ничё, что Гослинг придумал «Write once run everywhere», и именно этот слоган купил энтерпрайз? То, что Java стал мейнстримным языков — абсолютная закономерность, потому что, например, именно из-за плохой переносимости кода вне виртуальной машины Apple упатентовывает свою железяку сорока двумя заборами, имиджевая хипсто-болтовня вокруг появилась, чтобы скрыть именно этот изъян. Android никогда бы не взлетел без Java: компилируемый в машинный код не может начать работать из коробки на дозиллионе слабо совместимых между собой железок.
Если бы Вирдинг и Армстронг с самого начала заморочились читаемостью кода для домохозяек и единой виртуальной машиной для VAX/VMS и Unix (хотя бы) — никакой Java бы не было.
Prolych
14.03.2017 10:44+11. ЯП создавали люди-создатели. Если ЯП свойственна эволюция как и животным, то животных создавали «создатели».
Эволюция — это непрерывный процесс проектирования и постройки создателями новых сущностей, от животных до языков программирования.
2. Новый язык обязательно появится, когда сделают процессоры, умеющие работать с двумерной+ памятью, а не с одномерной, в который мы все мучительно жаримся на сковородках многопоточности.
Грубо говоря, поток — это метрика времени, а память — это метрика пространства. На текущий момент мы пытаемся втиснуть большое количество метрик времени в одномерное пространство, и из-за этого мучаемся.
То есть правильная красивая программа, похожая на человека — это один поток исполнения в трёхмерной памяти. А то, что есть сейчас — многопоточные программы в одномерной памяти — это ад и чудовище.
vasiliysenin
14.03.2017 11:33Языки не рождаются сами по себе, как животные. Их создают люди. И ничто не мешает создать новый язык, если существующий не достаточно хорош.
Но на сегодняшний день, дешевле улучшать существующие языки. Но когда то наступит момент когда из-за принципа обратной совместимости уже будет невозможно улучшать существующий язык.
Если считать новую версию языка, новым языком. То можно сказать что новые языки появляются постоянно, просто под тем же названием.
guai
14.03.2017 12:02Некорректно сравнивать эволюцию языков программирования с эволюцией в живой природе. Там отбор естественный и слепой. У нас же вполне себе разумный.
Новые языки не так быстро распространяются по причине легаси и того, что сильно много фичей добавить уже сложно, почти всё из нужного уже было в их предшественниках.
И особенно никому не нужны новые языки, которые не пытаются пофиксить ВСЕ известные проблемы предшественников, а так, рюшечки добавляют. И не нужны те, которые привносят изменения туда, куда не надо, где и так всё было нормально и привычно.
И единственный язык, разрабы которого это понимают (и про который мне известно, конечно), — это Цейлон. Именно стремится дать максимум фичей, чтоб его имело смысл внедрять (в отличие, например, от котлина, который всё еще тащит багаж явы), и не портят привычные вещи (как скала со своими спейсшип-операторами и прочей наркоманией)
Ну еще D, хотя многие считают, что ему не стоило налегать на сборку мусора.
ppopoff
14.03.2017 12:31Скажу вот что. Следующему языку скорее быть (и причин на это достаточно). И мне очень хочется ответить на эту статью другой статьей, воторую возможно предстоит написать. Для нового языка есть ряд предпосылок.
- проблемы с платформами (такими как JVM)
- недостаток производительности (упираемся в кремний)
- высокая сложность текущих языков
- проблемы с эволюцией текущий языков (неудачная модель развития Python и неудачная модель развития Java).
- параллельность на уровне языка
- возможность составлять dsl, при максимальной простоте грамматики языка.
vedenin1980
14.03.2017 13:23+1проблемы с платформами (такими как JVM)
Например? Какая есть такая проблема в JVM, которую есть у любого провайдера JVM и которую нельзя обойти своей реализацией JVM?
неудачная модель развития Java
Например? С точки зрения бизнеса Java (и, скажем, PHP) вполне удачны, они относительно просты и стоимость разработчиков нижнего уровня (манкикодеров) относительно невысока при том что производительность таких разработчиков достаточно приемлемая. То что Java достаточно консервативна, большому бизнесу тоже на руку, он сам обычно весьма консервативен. В своей нише энтерпрайза Java вполне себе неплохо чувствует.
ppopoff
14.03.2017 18:04+1Начнем пожалуй с неудачной модели. Вы понимаете на что создатели обрекают язык, декларируя обратную совместимость? Java исчерпала свой бюджет сложности (для манкикодеров) когда вышла версия 5.0 Tiger. И это не я сказал, а Джошуа Блох. Java сложный язык. И те, кто считает Java простой не знают Java. Дальше будет тоже что и в случае с С++. И, поправочка, Java была консервативной, когда ей рулил Sun.
Т.е. по вашему мнению платформа идеальна?
Сторонние вендоры вам type-erasure починят? И unsigned типы добавят? и добавят большие массивы? И числовые типы заданной длины (как это сделано например в LLVM)? Там знаете можно сделать Int_256 или Int_128 (уже не помню как типы называются, знающие люди простят). И Java все-равно будет медленной.
Конечно же производительность Java адекватна решаемым ею задачам, однако сейчас мы упираемся в не только в тактовую частоту процессоров (которая не растет), но и в количество ядер, которое… тоже не очень то и растет.
И софт придется оптимизировать. И тут на сцену выйдут языки, с бекендом на LLVM. И, возможно, будут достаточно долго доминировать.Sirikid
14.03.2017 18:29-2В принципе беззнаковые числовые типы не особо нужны, ведь поведение знаковых при переполнении определено. Разве что как синтаксический сахар для
Integer#<op>UnsignedиLong#<op>Unsigned.ppopoff
14.03.2017 19:35+2Беззнаковые типы нужны языку для низкоуровневых задач, а ля разбор бинарных форматов и упакованных структур данных, без UInt-ов это может оказаться предельно неоптимально.
А ещё беззнаковые целые ведут себя куда предсказуемей при операциях сдвига — что как раз и важно при разборе бинарных данных, где важное значение имеют отдельные биты
khim
14.03.2017 19:53А ещё беззнаковые целые ведут себя куда предсказуемей при операциях сдвига — что как раз и важно при разборе бинарных данных, где важное значение имеют отдельные биты
А вот как раз с этим в Java всё в порядке: >>> и >>>= вполне достаточная замена беззнаковости при работе с битовыми полями.
Sirikid
14.03.2017 20:06У C определено битовое представление для беззнаковых чисел и не определено для знаковых, поэтому переполнение знаковых чисел — UB, а беззнаковых нет.
У JVM определено представление для знаковых чисел, и это представление (дополнительный код) позволяет использовать одни и те же инструкции для почти всех операций (кроме деления, деления по модулю и сравнения).
А ещё беззнаковые целые ведут себя куда предсказуемей при операциях сдвига — что как раз и важно при разборе бинарных данных, где важное значение имеют отдельные биты
Именно поэтому есть знаковый и беззнаковый сдвиги вправо.
vedenin1980
15.03.2017 12:40-1и добавят большие массивы?
Уже есть. Для этого достаточно библиотеки
И числовые типы заданной длины
Для произвольной длины ограниченной только памятью есть BigInteger и BigDecimal. Если вопрос экономии памяти и т.п., то это в большинстве случаев для Java это экономия на спичках. Точнее если вам это действительно критично — вы выбрали неверный язык для задачи.
И unsigned типы добавят
Зачем? Как выше говорилось есть в Java безнаковый сдвиг и т.п. Если для производительности, то вероятно для данной задачи вам нужно брать не Java, а С/Go/Rust и т.п. Ну на крайний случай написать код на C++ и подключить её к Java как библиотеку. Да, Java не способна конкурировать с С в числодробилках/играх/низкоуровневой работе с ОС
И Java все-равно будет медленной
Когда говорят Java медленная в 90% случаев оказывается что медленно из-за кривых рук программистов (или по старой памяти), в 10% — Java пытаются применить туда где ей не место. Ну не может даже очень хороший лимузин соревноваться с джипом по бездорожью. У каждого языка — свои ограничения.
Java сложный язык. И те, кто считает Java простой не знают Java
Первый год использования Java казалось мне простой, потом первый десять лет Java (и её фреймворки) сложными, сейчас после 10 лет Java кажется мне опять очень простой. Просто нужен грамотный учитель и тогда Java — очень простой и логичный язык.
И софт придется оптимизировать. И тут на сцену выйдут языки, с бекендом на LLVM. И, возможно, будут достаточно долго доминировать.
Большинство софта медленно просто потому что его написали криво, если использовать алгоритмы с O(N^N) — он будет медленным на любом языке. Оптимизация нужна, но в первую очередь алгоритмов и ошибок.
Т.е. по вашему мнению платформа идеальна?
Нет, конечно. Более того нет ни одной платформы или языка, который идеален. Нет и не будет. Любой язык это компромис, та же обратная совместимость с одной стороны великолепная фича. с другой большая боль. Любой язык это компромисс, пока JVM и Java в своей экологической нише чувствуют себя достаточно комфортно и это главное. Просто не стоит забивать молотки микроскопом и пытаться использовать JVM там где нужны числодробилки и сверхбыстрый код.
языки, с бекендом на LLVM
В энтерпрайзе? Сомнительно, там не так важна скорость работы сколько надежность и поддержка старого кода.Sirikid
15.03.2017 13:10Вот что имелось ввиду под типами произвольной разрядности.
vedenin1980
15.03.2017 13:40+1Это понятно, но есть ли в них иной смысл кроме производительности и снижения затрат памяти? На мой взгляд, если вам требуется настолько низкоуровневый тюнинг и настолько экономить на спичках, то вы выбрали неправильный язык для своей задачи. Java этого не может просто потому что для её задач это не нужно. В теории реализовать в Java что-то подобное можно с помощью сишных библиотек (или даже просто массива байтов и обычного Java кода), но зачем? Зачем лимузину добавлять фичи внедорожников, если нормальные владельцы все равно по бездорожью на нем гонять не будут? Просто чтобы были?
Sirikid
15.03.2017 14:45- Я не топик-стартер.
- Использование этих типов не дает никакой производительности и снижения затрат памяти (разве что на некоторых платформах), только семантику.
vedenin1980
15.03.2017 15:47+1Использование этих типов не дает никакой производительности и снижения затрат памяти (разве что на некоторых платформах), только семантику.
А в чем тут семантика? Всегда можно взять тип "с запасом", если нужно сделать валидацию на значения типов, то в Java (например в Spring) тоже самое можно сделать аннотациями (и куда более гибко, надежно и наглядно):
@Min(18) @Max(120) private Integer age; // возраст пользователя в нашем сайте для взрослых должен быть от 18 до 120 лет.
rg_software
14.03.2017 15:05+2А я вот соглашусь с автором. Особенно забавно, что в комментариях один пишет, что «предпосылки верные, вывод неверный», а другой — «предпосылки неверные» :)
Причём мне кажется, что дело не только в «островках», но и в том, что начиная примерно с 80-90-х эволюция чуть ли не каждого заметного языка программирования пошла экстенсивным путём. В мире языков программирования не только у млекопитающей летучей мыши есть крылья; у всех есть крылья (и ноги, и хвосты).
Если посмотреть старые учебники программирования, там обычно языки делят по сфере применения: у этого есть средства для работы с графикой, у этого с математикой, а у этого удобный файловый ввод-вывод. Сейчас, конечно, тоже можно рассуждать о подобных вещах, но наши проблемы даже близко нельзя поставить с теми, старыми. Если сейчас нужен, скажем, пакет линейной алгебры, вы всегда найдёте его для любого меинстримного языка, в то время как раньше его могло не быть вообще.
Мода началась, наверно, с Java. В своё время это был язык, как мне кажется, с самой развитой стандартной библиотекой. Сейчас аналогичным образом поступает и Python, и .Net. Таким образом, в девяностых годах стимулом к переходу могли быть более развитые средства для работы с чем-нибудь. Сейчас эта разница стремительно сократилась, и можно рассуждать разве что о большем или меньшем удобстве работы, но принципиальных проблем для использования старых языков в новых областях всё меньше и меньше.
taujavarob
14.03.2017 16:19+9Рассмотрим островное происхождение языка Java. То, что Java стал мейнстримным языком программирования, — по большому счету, случайность. Для этого не было никаких разумных предпосылок. Разработка Java начала в 1991 году (тогда язык назывался Oak). По легенде, основной платформой для исполнения Java-приложений должны были стать кофемолки.
Всё было не так. (С) Было всё веселее.
Жил был один инженер которому поручили разработать ПО для пульта телевизора. Писал код он на С.
Дело было новое и железо (микропроцессоры для пульта) ему приносила часто новое и разное.
И запарился он иметь зоопарк своих программ на С под разное железо для пульта. Запарился по полгода читать доки на каждый микропроцессор.
Решил он повеситься. Выбрал для этого серверную. Там хорошо, холодно. Висеть можно долго пока не найдут. Но не пустили его в серверную. И пошёл он к своему руководству с заявлением на увольнение.
Руководство его формально спросило — причина увольнения?
— Да, запарился я с вашим изменением железа, — сказал он. — Мне приходится по пол-программы каждый раз переписывать, — приврал он маленько.
В это время у руководство чего-то сидел Гослинг — который обычно ездил по универам на конференции и слушал о новинках в разработке ПО.
Гослинг сидел как все американцы — положив ноги на стол, перед директором. Директор слушал его в пол уха, ничего не понимая про некую «виртуальную машину», про которую Гослинг ему уже не раз пытался втолковать.
В то время не только все в универах то бредили ООП, но и интенсивно обсуждали виртуальные машины.
Гослинг волей не волей вынужден был присутствовать при увольнении этого программиста. Выслушав причину он немного подумал и сказал инженеру по пультам — Не увольняйся пока, я тут новую штуку придумал — пишешь один раз, выполняется во всех пультах для телевизора. …
Язык назвали «Oak» — что на жаргоне означало коньяк. (С)
Но когда дело дошло до маркетологов, те сказали, что негоже программистам пить алкоголь.
Стали выбирать: чай, молоко, пиво, вино, виски, сок, шампанское и сидр. Остановились на кофе — на жаргоне это «Java». (С)
( Кстати, когда Java уже взлетело, то программисту, разработавшему по заказу простой язык для обработки нажатий на странице в броузере, маркетологи сразу же сказали, что язык его будет называться JavaScript и надо также добавить оператор new.
Но зачем, спросил программист, — у меня же нет ООП.
Неважно, добавь, — сказали ему маркетологи. — За пару недель уложишься?
Так возник JavaScript, который к Java имеет такое же отношение, как «car» к «carnival». )
И наступил 1995 год и Java взлетел — шума было много. Почти как C, но реализация ООП проще чем у С++.
Про то, что Java был придуман как язык для написания ПО для встроенных систем типа пульта телевизора, сразу же забыли ибо наступили годы Интернета. — Что то надо было приспособить для рисования картинок в броузере. И для этого привлекли Java.
Если бы в 1995 году кто-то сказал, что Java станет (займёт место Кобола) языком для Энтерпрайз систем — его бы в дурку послали.
"Почти как С" — в то время престижно (модно было). Вот DBASE или FOXPRO — это не модно, а Clipper — это круто — это "почти как C" и даже на выходе .exe файл (неважно, что в каждом таком .exe был вшит интерпретатор).
P.S. Не существует модели («остров» и прочее) появления языков программирования. Они все возникают разными путями.
SQL — выбран из дюжины языков, написанных аспирантами в разных универах, по главному признаку — этот язык должен быть настолько простым чтобы им пользовались… операционисты в банке, бухгалтера, кладовщики, аптекари…
Вы знаете кто им (SQL) пользуется на самом деле сейчас? Вот, вот.
Это касается не только языков, но и сред:
Node.js — взлетел в яростной конкуренции ( а других, кто с ним конкурировал, то уже никто и не помнит вообще, а ведь их было не менее 5).
C# — майкрософтовская «улучшенная» копия Java. — Ну, любит Майкрософт «улучшать», операционки ли, броузера ли, языки ли (пример — C# (взяв Java) и TypeScript (взяв JavaScript)).
В начале 90-х Майкрософт собирался разработать свою, «улучшенную» версию интернета! (Но вовремя кто-то сказал им, что они сдурели с этим).
К чему клоню — Не существует модели («остров» и прочее) появления языков программирования. Они все возникают разными путями. Часто спонтанно — иначе бы мы тут, на хабре, очередной том от CODASYL (был такой "динозавр") разбирали.
Иначе говоря: Неисповедимы пути Господне. (С)Prolych
14.03.2017 21:13"… иначе бы мы тут, на хабре, очередной том от CODASYL (был такой «динозавр») разбирали."
скорее от Natural: о) Адабас был бы нашим всем.
mail-online
14.03.2017 23:03-2Спасибо автору. Действительно очень интересно.
Есть большая и не обжитая ниша, совсем не упоминаемая в статье. Можно их назвать «веб ориентированными 1С подобными языками». Поясню: 1С — это программа позволяющая себя произвольно редактировать изнутри. Не просто добавить поле, как в том же Wrike, или подредактировать интерфейс. А задать сложную логику работы по событиям, написать новый модуль, сделать сложный интерфейс.
Тот же подход применим к системе управления проектами по SaaS концепции. Это очень круто. За этим будущее. И этого практически нет. Вот ваш Wrike, по сути позволяет только добавлять новые поля и менять внешний вид интерфейса аккаунта (насколько я понял и справки). А чтобы клиент мог не выходя из аккаунта САМ разработать какой-то модуль, создать таблицу в базе данных, поставить какой-то триггер, написать хранимую процедуру, модернизировать любой элемент интерфейса, добавить новые поля ввода вывода?
Ведь в Wrike, да и во всех аналогичных системах: как сделано — так сделано. И бизнес должен подстраиваться под существующие структуры. Пользователь например не может дописать какие-то автоматические действия по событию изменения тех или иных данных. Или разработать необходимый компании модуль.
Будущее за SaaS системами, которые имеют встроенные языки программирования позволяющие это делать. Они обладают фантастически гибкими возможностями и на мой взгляд они буду вне конкуренции.
Вот пример пока единственной подобной системы: https://erp-platforma.com/. Здесь можно почитать как устроен сам язык: справка (Главы 3 и 4).
И эта ниша слабо развита ввиду очень большой сложности создания такого языка. Основная сложность — безопасность. Пуская в SaaS аккаунт — вы пускаете на свой сервер. И нельзя просто так давать программировать на вашем сервере. Это должна быть очень продуманная с точки зрения безопасности система, иначе вас просто сломают.
В ERP-Платформе например применены очень нестандартные схемы реализации языка, с внешним (пользовательским) и внутренним (системным) уровнями, общающиеся между собой через компилятор. А так же реализация пользовательской логики не в интерфейсе, а в базе данных. Интерфейс там служит только для вывода и редактирования данных, а вся логика обработки всего и вся задается в БД на аналоге PLSQL. Этим он как раз кардинально отличается от 1С, где логика реализуется в интерфейсе, а в БД только хранятся данные (насколько я в курсе, хотя не специалист по 1С).
Такого насколько я знаю нигде больше нет, и никто больше не делал. И это на мой взгляд единственный пусть для SaaS языка.
На практике благодаря взаимоинтеграции программирования интерфейса и базы, а так же встроенной CURD у меня получалось создать рабочий модуль раз в 5 быстрее, чем если это делать на PHP+SQL. Интерфейс вы можете разметить как в экселе, в ячейки накидать элементы форм управления, а к формам подцепить элементы базы данных. Очень удобно и быстро.
Но конечно это надо уметь. Как любой язык, его сначала надо изучить.khim
14.03.2017 23:16Это должна быть очень продуманная с точки зрения безопасности система, иначе вас просто сломают.
Да — но причём тут язык? Засунуть в «песочницу» можно любой язык и, более того, вся история показывает что попытки сделать полноценную «песочницу» на уровне языка — обречены на провал.
И это на мой взгляд единственный пусть для SaaS языка.
С чего вы взяли? Чем это отличается от требований того же AppEngine?
mail-online
14.03.2017 23:29С чего вы взяли? Чем это отличается от требований того же AppEngine?
Да всем отличается. Это принципиально разные продукты. AppEngine это по сути хостинг с возможностью разработки. Вы можете стем же успехом арендовать сервер и там разворачивать свои приложения.
SaaS система управления проектами — это готовый продукт с определенной функциональностью, и вот этот продукт дает возможность управлять собой при помощи встроенного языка. Вы можете подредактировать и автоматизировать нюансы работы вашей компании. Такой тип языков — своя отдельная ниша.khim
15.03.2017 00:47Вы можете стем же успехом арендовать сервер и там разворачивать свои приложения.
Не ставя при этом на свой сервер NoSQL, библиотеки манипуляции изображениями и прочим?
Такой тип языков — своя отдельная ниша.
Почему? Зачем? Что вам мешает взять подходящую песочницу и вкрутить туда Python, Lua или, прости господи, PHP? Чего такого должны уметь все эти языки такого, чем не умеет Ruby или тот же Perl?
Просто вы говорите:
И это на мой взгляд единственный пусть для SaaS языка.
Но не подкрепляете это громкое утверждение ровным счётом ничем.
Это должна быть очень продуманная с точки зрения безопасности система, иначе вас просто сломают язык, собственно, никак не ограничивает: как я уже сказал в песочницу можно засунуть любой язык.mail-online
15.03.2017 09:20-2Масштаб мешает.
Вы не можете «взять» песочницу, вам надо «сделать свою» песочницу. Вот вы возьмете тот же AppEngine. Максимум что вы там сделаете, это аля интернет магазин. Вот представим что вы там сделали свою платформу управления проектами, дает аккаунты пользователям, они заходят и пользуются теми алгоритмами что вы сделали. И вот вы этим пользователей пустите в свой аккаунт на котором у вас написана платформа чтобы они могли что-то редактировать? Они вам там такое наредактируют… Чтобы пользователю управляли аккаунтом на вашей платформе (которую вы создали в AppEngine) вам опять же надо сделать свою песочницу внутри той песочницы.
Если я не прав, приведите пример. Вот имея сервер, на нем имея сайт с платформой управления проектами, что я могу на этот сервер поставить, чтобы дать пользователю возможность произвольно менять алгоритмы работы именно его аккаунта, не затрагивая всех остальных пользователей?vedenin1980
15.03.2017 12:07+3Вот имея сервер, на нем имея сайт с платформой управления проектами, что я могу на этот сервер поставить, чтобы дать пользователю возможность произвольно менять алгоритмы работы именно его аккаунта, не затрагивая всех остальных пользователей?
Например, Docker и реализовать микросервисную архитектуру. Каждый пользователь будет иметь свои собственные инстансы микросервисов, полученные как образы доскера. Или использовать микросервисы и облака, у пользователей физически не будет доступа к чужому коду иначе чем через API с авторизацией.
В принципе, SAP подобные системы используют Java и при нормальных настройках безопасности достаточно сложно пользователю выйти за пределы своих прав (впрочем, идеальной защиты это не дает, всегда есть шанс что пользователь-хакер сможет найти дыру и повысить полномочия, но это проблема для любого доступа к серверу), но в принципе JVM достаточно хорошо умеет защищаться от таких пользователей, запрещая доступ куда не нужно при правильных настройках безопасности.
Но вопрос не в этом. Вопрос в том зачем нужен новый язык, когда тот же SAP и его аналоги прекрасно живут той же Java. Что есть такого в каком-нибудь 1С, чего не могут универсальные языки? И главное почему вы считаете что придуманная вами песочница будет безопаснее известных проверенных аналогов?
mail-online
15.03.2017 13:59-2Да, Docker это интересно. Спасибо за инфу.
Пока правда не уверен что это может иметь практическое применение к облаку. Надо тут подумать.
Каждый контейнер будет иметь веб сервер и свой IP, надо как-то авторизировать пользователя и пробрасывать его за НАТ в нужный контейнер. Мне кажется это еще та задачка, особенно с двухфактороной авторизацией. Плюс есть файловые сервера где хранятся БД (это не веб сервер, он не резиновый), т.е. из контейнера надо туда давать доступ, причем базы тогда должны быть тоже изолированы в контейнерах. Как то не давать доступ из контейнера с вебом к файлам чужих контейнеров по IP (что проблематично давая доступ к php коду в контейнере).
Плюс вся эта инфростуктура должна создаваться автоматически при регистрации аккаунта.
В общем на мой взгляд это довольно сложная логистическая задача. Но повторюсь, надо подумать, так сходу не могу сказать что не имеет права на жизнь.
Плюс встает вопрос защиты ПО, т.е. код вашей системы будет в конейнере, и вы даете доступ к этому коду и средства программирования. Ничего не помешает его получить. Обфускация не сильно помогает в этом случае. Нужен хотя бы ionCube. SaaS тем и хороша, что код защищен.
В общем решение с контейнерами и доступом к штатному языку программирования на мой взгляд имеют свои минусы. Хотя не скажу что не имеют права на жизнь. Надо переварить поглубже.
А вот свой внутренний язык с пользовательским уровнем абстракции и интерпритатором, решает все эти проблемы. Напрямую доступа нет, но при этом есть возможность произвольного редактирования своего аккаунта.
mail-online
15.03.2017 14:19К структуре базы тоже надо дать доступ, в том числе к служебной информации, что явно не хорошо. Молчу уж удобстве редактирования базы, о CURD, снапшетах процедур, автоматических логов, автоматической структуре прав доступа к элементам и т.п. что реализуемо в качестве функций встроенного языка.
В общем обобщая, свой язык в платформе решает проблему защиты кода смой платформы, проблему безопасности, проблему удобства доработки аккаунта, можно реализовывать свои нужные функции этого языка, которых нет в штатных. Понадобилось, сел, доделал и все пользователи радостно пользуются.vedenin1980
15.03.2017 15:58+1К структуре базы тоже надо дать доступ, в том числе к служебной информации, что явно не хорошо. Молчу уж удобстве редактирования базы, о CURD, снапшетах процедур, автоматических логов, автоматической структуре прав доступа к элементам и т.п. что реализуемо в качестве функций встроенного языка.
Есть микросервисы авторизации. Есть микросервисы работающие с базой данных. Они не доступны для редактирования, только для запросов (REST, SOUP, MQ query), они определяют какой пользователь имеет право на редактирования каких сущностей (например, запрещают админу одного проекта редактировать чужой проект). Ваши клиенты не должны иметь доступ к базе данных, только к сервисы, работающему с базой данных и под своей авторизацией и правами. Так же клиенты должны иметь возможность загружать свой код только в виде классов, реализующих определенные интерфейсы (явно заданными вами) и только для "своих" запросов.
что реализуемо в качестве функций встроенного языка
Ужасный костыль, к тому же глючный. Вместо того чтобы взять стандартные сервисы, стандартные библиотеки разграничения прав и безопасности (какой-нибудь Spring Security) и использовать их вы предлагаете КАЖДОЙ SAP системе придумывать свой язык? Проводить тестирования на безопасность (огромные деньги), обучение пользователей и программистов (ещё более дикие деньги), иметь проблемы с поиском специалистов (так как мало кто хочет изучать ваш ЯП, опыт в котором потом нельзя "продать" на рынке труда).
решает проблему защиты кода смой платформы, проблему безопасности
Серьезно? То есть язык сам раздает права на все объекты, сам определяет политики безопасности, сам по себе решает такие проблемы как SQL инжектион, кросс-браузерные запросы или кражу кук сессий? Или вы хотите создавать заново велосипед и писать заодно свой фреймворк, аля Spring Security?
mail-online
16.03.2017 10:32-2Почитал про Spring Security. Оно предназначено для аутентификации (я не прав?). Система разграничения доступа должна быть намного сложнее, с детализацией вплоть до каждого отдельного элемента страницы. Например одной роли надо дать доступ к кнопке на веб странице на изменение, другой на удаление, т.е. в зависимости от того что делает кнопка он должна или быть активна, или деактивироваться у того или иного пользователя. Кому то надо отображать информацию, а кому то пустой элемент. Права должны наследоваться, т.е. права областей старницы должны наследовать права роли на страницу если не задано иное, права элементов областей должны наследвать права области (если иное не задано). Должны задаваться прав по умолчанию, перекрывающиеся если иное принудительно указано в роли пользователя. Все намного сложнее. Вот если интересно, можете почитать как реализована система настройки прав в приведенном мной выше примере системы ссылка.
А как вы будите давать доступ к элементам страницы если не можете их построить как индивидуальные сущности? При помощи чего можно их строить? Такие возможности дает только встроенный в SAP язык программирования. Иначе никак. А система без удобной системы настройки прав (одним-двумя кликами) и возможности настройки прав вплоть до каждого элемента, она просто ущербна.
Потом посмотрите на систему с точки зрения разработчика. Вот вы сделали свою SAP систему и решили сделать встроенный язык программирования для того чтобы дать возможность гибкой настройки системы пользователям. Ваш подход с использованием стандартного языка априоре обречен на провал. Я поясню: например система написана на php. По вашему, чтобы дать возможность редактирования каждого элемента системы, вы должны сделать пользователю изолированный контейнер с системой, поставить туда php и дать доступ к коду, причем вы даже не сможете обфусцировать код, ибо как дать доступ к редактированию каждого элемента, если пользователь просто не сможет найти данный элемент. Т.е. вы всем в свободный доступ дате код многолетней разработки своей компании… Ваш бизнес просто долго не просуществует.
вы предлагаете КАЖДОЙ SAP системе придумывать свой язык?
К сожалению именно так. Почему я выше описал. Да, это сложно, да это дорого. Но если вы хотите заниматься этим бизнесом и дать пользователям сервис универсального редактирования, вам придется это сделать, придется для СВОЕЙ SAP разработать СВОЙ язык программирования. Иначе бизнеса не будет.
Именно поэтому 99% SAP систем своего языка программирования не имеют. Я знаю попытки встроить php код, но именно отдельным индивидуальным новым модулем, но не в коем случае не редактор существующего кода. Никакая компания в здравом уме пускать в свой исходный код не будет (если вы не open source конечно).
По поводу обучения и опыта который нельзя продать.
1С программисты не могут продать опыт свой? Да они очень неплохо зарабатывают, гораздо больше чем большинство программистов популярных языков. И все потому, что их не так много и они ценятся. Они нужны, ибо система распространена.
Обучение: да, проводите обучение. Включите в свои тарифы определенный объем ежемесячного бесплатного обслуживания своими программистами клиента (чтобы он мог не ведя большие расходы доработать свои мелкие нюансы). Если клиенту необходимо разработать крупный модуль и он не шарит в языке этом, да это будет за деньги, как и в случае любого другого языка.
В любом деле производя продукт вы будите нести какие-то издержки.vedenin1980
16.03.2017 17:35+4Почитал про Spring Security. Оно предназначено для аутентификации (я не прав?). Система разграничения доступа должна быть намного сложнее, с детализацией вплоть до каждого отдельного элемента страницы
Не правы, там можно настроить любые роли и права даже не до уровня элементов страниц даже до доступа к отдельным методов класса, то есть пользователь не имеющий нужных прав вообще никак не сможет вызвать этот метод.
@PreAuthorize("hasRole('ROLE_USER')") @PostFilter("hasPermission(filterObject, 'read') or hasPermission(filterObject, 'admin')") public List<Contact> getAll();
Такие возможности дает только встроенный в SAP язык программирования. Иначе никак. А система без удобной системы настройки прав (одним-двумя кликами) и возможности настройки прав вплоть до каждого элемента, она просто ущербна.
Ну да, ну да. Я работал в Netcracker вот там все это было (и даже более сложная логика с отдельными схемами и прочим), но своего ЯП не было. Для понимания там капитализация системы где-то на миллиард $, десятки тысяч программистов и клиентами половина крупнейших телеком компаний мира, включая большую тройку РФ. Нет никакой связи между удобной настройкой прав с веб.интерфейсом и своим ЯП. От слова совсем. Кстати, система Netcracker'а проходила тестирования безопасности на таком уровне, которым всякие ERP-Платформы вероятно и не снились.
Я поясню: например система написана на php. По вашему, чтобы дать возможность редактирования каждого элемента системы, вы должны сделать пользователю изолированный контейнер с системой, поставить туда php и дать доступ к коду, причем вы даже не сможете обфусцировать код, ибо как дать доступ к редактированию каждого элемента, если пользователь просто не сможет найти данный элемент.
Элементарно как делают всякие SAP'ы пользовательский код имеет доступ только к API (может быть даже к API сервисов лежащих на другом сервере и доступных только по Rest), пользователям могут давать вызвать свои классы или сервисы, но так же только по определенному интерфейсу. Например, мы хотим дать возможность нашим пользователям самим определять цен товаров при заказе клиентами, мы предлагаем им реализовать интерфейс:
public interface OrderedSystem { List<ItemsWithPrice> getItemsWithPrice(List<Items> itemsWithoutPrice); }
У пользователя код лежит в контейнере (возможно даже на локальном компе разработчика), которому по REST'у приходят данные о заказах без цен, а код возвращает так же по REST'у данные с ценами этого магазина. И все.
Как пользователь получит доступ к чужому коду? Чтобы он не сделал, он не сможет обойти данный ему API. Давать сам код нафиг не нужно и вообще бредово. И кто сказал что вы сумеете предусмотреть, что пользователь может использовать функцию чтения из файла и записи в лог файл в ВАШЕМ СОБСТВЕННОМ ЯЗЫКЕ, чтобы прочитать все php файлы и скопировать их содержимое?
Т.е. вы всем в свободный доступ дате код многолетней разработки своей компании… Ваш бизнес просто долго не просуществует.
Ну, кстати, я не верю что украв код огромной SAP системы конкуренты смогут его адаптировать и как-то использовать (к тому же избежав исков о чужом коде). Обычно в таких системах сами разработчики уже с трудом ориентируются и простейшая настройка тот ещё квест, а украсть код да переписать под себя — по моему это фантастика. Скорее я бы боялся, что конкуренты смогут скопировать интерфейсы, бизнес процессы и архитектуру. И намного хуже если они переманят ведущих разработчиков. Между прочим украсть код тоже намного проще через самих сотрудников, а не хакерскими методами. ИМХО.
Именно поэтому 99% SAP систем своего языка программирования не имеют.
Во-первых, SAP система существует только одна, собственно это система компании SAP. То что вы называете SAP системами называется ERP (Enterprise Resource Planning) BSS(Business Support Systems) или OSS (Operations Support Systems). Во-вторых, как-то вы лихо начали говорить о 99%. То же SAP (огромная часть рынка) позволяет писать код на Java и до сих пор не разорился. Опять-таки мы Netcracker тоже давали пользователям возможность писать на Java.
1С программисты не могут продать опыт свой? Да они очень неплохо зарабатывают, гораздо больше чем большинство программистов популярных языков. И все потому, что их не так много и они ценятся. Они нужны, ибо система распространена.
Во-первых, вы ошибаетесь, 1С-ники хорошо зарабатывают в начале карьеры, а потом планка старших разработчиков на многих языках выше планки 1С-ника и что ещё хуже разработчик может уехать почти в любую страну Запада и получат там в разы больше 1С-ника, который за границей никому особо не нужен. Либо работать удаленно на Западных клиентов в своем небольшом городе и так же получать в разы больший доход чем на местном рынке 1С-ники.
Во-вторых, они нужны только из-за уникальной ситуации когда продукт по воле случая стал монополистом. Если бы был у 1С сопоставимый по популярности конкурент с нормальным универсальным языком у него было бы весьма приличное преимущество за счет мобильности рынка труда.
1С программисты не могут продать опыт свой?
За границей не смогут и в другую область перейти тоже легко не могут. Это одна из причин почему очень многие IT'шники ни за какие коврижки не идут в 1С.
Обучение: да, проводите обучение. Включите в свои тарифы определенный объем ежемесячного бесплатного обслуживания своими программистами клиента (чтобы он мог не ведя большие расходы доработать свои мелкие нюансы). Если клиенту необходимо разработать крупный модуль и он не шарит в языке этом, да это будет за деньги, как и в случае любого другого языка.
На самом деле свой язык нужен тем разрабатывает ERP системы только затем чтобы подсадить клиентов на свой продукт, как делает 1С. Однако разумные клиенты не хотят "подсаживаться" на такие системы и при наличие конкурентом предпочитают аналоги где своего ЯП не будет или рассматривают систему как черный ящик, когда любые доработки делает сам производитель. Отсюда если у ERP системы нет монополии на рынке как у 1С, то свой язык бесполезен (кроме как для маркетинга), так как им никто вообще пользоваться не будет. Наличие нормального языка для настройки может быть определенным преимуществом.
mail-online
16.03.2017 19:12-2Интересный разговор получается. Постараюсь все таки отстоять свое мнение :)
Во-первых, SAP система существует только одна
Это всем понятно, я просто воспользовался вашей терминологией.
Элементарно как делают всякие SAP'ы пользовательский код имеет доступ только к API
Это не вариант. Вернее очень плохой вариант. Вы опять же ограничиваете пользователей рамками ваших API. Если брать опять же пример ERP-Платформы — там пользователь может создавать свой API, т.е. он может делать прямо в триггерах специальные элементы (называются позиции API) на любые таблицы, которые по любому выбранному событию по вашим правилам, передадут указанные вами данные на указанный вами внешний сервер. А на прием данных вы можете придумать свой формат и создать свою процедуру приема информации. Вы не ограничены придуманными кем-то API…
пользователь может использовать функцию чтения из файла и записи в лог файл в ВАШЕМ СОБСТВЕННОМ ЯЗЫКЕ, чтобы прочитать все php файлы и скопировать их содержимое?
Такие вещи должны решаться на уровне архитектуры языка. И кстати на стандартном языке их решить будет затруднительно. Извиняюсь, опять же приведу пример ERP-Платформы: там есть внешний (логический) и внутренний (физический) уровни, пользователь делает изменения только на внешнем (составляет конфигурацию), а на внутренний они попадают через компилятор. На физическом уровне он в принципе не сможет ничего сделать, а компилятор не даст сделать того что не разрешено, там жесткие уровни проверки корректности. Плюс логика делается не в вебе, а в базе данных. Базы данных естественно не на веб сервере, а в распределенной сети. Файлы естественно тоже никто на веб серверах не хранит…
Я конечно не утверждаю что возможна идеальная безопасность, наверное такого не бывает. Но ее можно приблизить к этому архитектурно.
Там кстати это уже 3-я версия языка, 2 предыдущих были забракованы и с высоты их опыта уже появилась третья с правильным архитектурным решением, которая выстрелила.
То же SAP (огромная часть рынка) позволяет писать код на Java и до сих пор не разорился
Он позволяет писать свой код? Или переписывать их в рамках вашего аккаунта? Это принципиально разные вещи.
По 1С-никам. Я имел дело с некоторыми, и такого насмотрелся, что если честно не очень их уважаю и сам принципиально в 1С лезть не хочу. А конторы реально только и мечтают избавиться бы от 1С, но особо нет альтернатив. И да, за рубежом они не продадут свой опыт. И вы правы что по сути они волею случая стали монополистами (а может что и стоит за этой волей случая...)
На самом деле свой язык нужен тем разрабатывает ERP системы только затем чтобы подсадить клиентов на свой продукт, как делает 1С
Вы тут не правы (хотя с 1С правы). Вам не надо всем навязывать и толкать SaaS язык. Глупо всех заставлять его учить и толкать в массы. Сам по себе он применим только в вашей платформе. Суть его создания:
1) Упростить своей компании дальнейшую разработку, разрабатывать в 3-5 раз быстрее конкурентов пользуясь своими средствами автоматизации и блочной архитектурой. Сложность его создания достаточно быстро окупается. Я тут знаю о чем говорю.
2) Дать клиентам ВОЗМОЖНОСТЬ доработки под их ниши. Это не значит заставить клиента, он берет продукт какой есть, но если ВДРУГ ему понадобиться доработать, он имеет ВОЗМОЖНОСТЬ это сделать. А это далеко не везде так.
Вам не надо учить всех людей вашему языку. Клиент должен в первую очередь пользоваться вашим продуктом, а язык это можно назвать бонусом.
Вам тут надо:
1) написать хороший мануал, на случай если кто-то захочет его заюзать
2) обучать своих сотрудников, благо это не сложно если человек знает что такое PLSQL. Вам там даже php то не нужен, конфигурация окон составляется мышкой…
или рассматривают систему как черный ящик
Черный ящик это как раз таки системы без встроенного языка, а тут вы как раз знаете, что даже в самом плохом случае, вы прочтете мануал и сможете сделать необходимые вам изменения.khim
16.03.2017 20:10+3Я конечно не утверждаю что возможна идеальная безопасность, наверное такого не бывает. Но ее можно приблизить к этому архитектурно.
Вы пока до сих пор не обьяснили почему для этого нужен свой, особый, язык. сотни разработчиков как-то обходятся без этого, однако — и только вам, вдруг, приспичило создавать свой язык.mail-online
17.03.2017 09:16-3Я написал что есть ниша для языков необжитая. Она будет в будущем перспективно развиваться.
Дискуссия развилась потому что люди не понимаю до конца этой темы и считают что можно обойтись стандартными вещами. Я попытался это все это аргументировано развеять, ибо проходил уже через все это и участвую в разработках ERP систем уже около 10 лет и знаю о чем говорю. Я видел разные способы и просто уже знаю как надо делать оптимально и почему. Но люди разные, кто-то понимает, кто-то нет, кто-то думает и пишет какие-то аргументы, у кого-то аргументов нет и просто минусует. Кто понял — я рад, кто нет — ну нет так нет.
Для вас напишу еще раз преимущества:
а) Скорость разработки системы на своей платформе. Вы можете сделать удобный редактор и типовые блоки для типовых и частых действий.
б) Безопасность системы. Давая стандартные языки, затруднительно обеспечить безопасность и защиту кода, при этом давая доступ к любому элементу.
с) Дать свободное редактирование любого существующего элемента (а не только новое) в рамках аккаунта
г) Деление системы на элементарные блоки дает большие преимущества. Можно сделать ту же систему назначения прав, можно делать типовые блоки упрощая разработку, можно вводить всякие интересные свойства элементов.
И т.д. нюансов миллионы. Все не описать.
Минусы:
а) Сложность разработки движка
б) Стоимость тестирования безопасности
Обучение новых сотрудников сюда не ставлю, ибо это не так сложно на самом деле и разово. А клиентов никто не заставляет учить, разве что сами не захотят. Они пользуются в первую очередь самим продуктом, а не средствами его разработки. Для них это просто бонус и гарантия что это не черный ящик.
Но если компания хочет развиваться в будущем, она должна будет это сделать, ибо ее в перспективе вытеснят те кто это сделал (ИХМО)khim
17.03.2017 13:18+5Я написал что есть ниша для языков необжитая. Она будет в будущем перспективно развиваться.
Я, похоже, вас понял. И даже частично с вами согласен.
Ниша для ваших языков (вернее даже ниши!) есть, но, увы и ах, для них есть ёмкое название: НИАСИЛИЛ.
Что, в общем, обозначает, что из этого никогда не вырастет того, о чём говорится в статье. Об этом, мы, кстати, спорили и раньше (правда с другим автором),.
И т.д. нюансов миллионы. Все не описать.
И не надо. Всё, что вы тут описываете, по сравнению с почти любой современной технологией для любого популярного языка выглядит как трёхколёсный велосипед рядом с современным авиалайнером. Если не авианосцем.
И потому все, читающие весь этот лепет на Хабре офигевают: «как? зачем? почему? кому?». Ответ — непрограммистам. Тем, кто НИАСИСИЛ.
Все задачи, которые вы тут описали — это мизер от любой современной Enterprise-Java системы. Но вот беда: люди, способные освоить Enterprise-Java — составляют небольшой процент населения. Их мало, они капризны и дорого стоят.
А что делать остальным? Нельзя ли для них сделать что-то попроще и на этом экономию на персонале устроить? Ответ: да. Вот для них — подобные языки и составляют.
Это — действительно огромная ниша. Однако вот беда: выйти из неё «на широкий простор» — не получится. Хороший пример Visual Fred и то, что с ним произошло.
В прошлом веке самым популярным языком программирования был Visual Basic. Вплоть до того, что чуть не половина программистов работали на нём. И вот у него были многие из вещей, о которых вы говорите: всякие «удобные редакторы и типовые блоки для типовых и частых действий» и прочее.
И все думали, что популярность ему приносит вот это вот всё — чего он такого хитрого умеет, чего всякие академические Java и C++ не могут.
Но со временем — оказалось, что добавить эти фичи в IDE для «полноценных» язков не так и сложно. А можно ещё «потянуть за уши» и вытянуть Visual Basic до полноценного языка. Обе вещи было проделаны.
Результат? Visual Basic умер. Он оказался слишком сложным для того, чтобы на нём писали те, кто работали в нише НИАСИЛИЛ, а его преимущества типа описанных вами выше — оказались никому ненужными при наличии тонн Wizard'ов.
А вот гораздо более убогие FBD со-товарищи — живут и здравствуют.
Так что не тешьте себя иллюзиями: вы живёте в нише НИАСИЛИЛ. Если вам повезло и для вас создали достаточно простой и функциональный язык — вам очень повезло. Радуйтесь. Но не думайте, что вы когда-либо выйдете из своей ниши.
Обучение новых сотрудников сюда не ставлю, ибо это не так сложно на самом деле и разово.
Ну вот. Наконец-то ответ. То есть ваш язык — настолько прост, что ему «можно обучить секретаршу»? Да — это классический признак языка класса НИАСИЛИЛ. Для них не нужны программисты, умеющие программировать. Для них — достаточно «специалистов» прочитавших тоненькую инструкцию. К сожалению это же и ограничивает (и очень сильно ограничивает!) область применения подобных языков.mail-online
19.03.2017 00:23-2Об этом, мы, кстати, спорили и раньше (правда с другим автором),.
Ну это что-то прояснило ) Зачем вы на OPCSenator так наехали то? Он кстати хорошую статью написал. Я до вашей ссылки и не знал что некто FBD есть. Кстати он LabView мне напомнил, правда он намного примитивней LabView конечно.
Вы просто совсем не понимаете визуального программирования. Для вас это «безумные схемы». Я кстати вас могу понять. В далеком 2005 году, когда я заканчивал МАИ, я устроился работать на нашу кафедру. Попал в команду которая занималась разработкой программы вибрационной диагностики воздушно-реактивного двигателя в полете. Можно было по анализу сигнатур вибраций определить в каком элементе двигателя поломка (или скоро будет поломка) и что произошло (скоро произойдет). Все это естесвенно делалось на LabView. До этого я все делал в основном на Delphi и честно скажу, первые дня 3 я от LabView плевался, но когда на меня снизошло озарение и я понял как это работает, я забыл Delphi как страшный сон, и кстати по сей день к нему не возвращался ни разу. Именно поэтому могу вас понять, вспомнив те первые ощущения.
Визуальное программирование, это просто офигенская вещь, там все наглядно, там потрясающие системы отладки кода, вы просто визуально можете посмотреть куда какие данные перемещаются и как преобразуются. Вы просто этого не поймете пока вас жизнь не заставит реально на этом поработать. Я до сих пор многие вещи на LabView делаю, это очень удобно.
А FBD я думаю для техников офигенская вещь, и она реально будет популярна в своей нише.
То есть ваш язык — настолько прост, что ему «можно обучить секретаршу»?
Тут вы сразили просто наповал! Я просто даже не думал что нужны какие-то подробности. Главное требование, хорошее знание процедурного SQL, если человек это знает, ему не составит труда освоить язык программирования в ERP-Плтаформе. Причем даже все равно с какими базами человек работал, SQL он везде SQL. Отличия минимальные. Все остальное мимо. Ну желательно конечно чтобы на html и php не смотрел человек как баран на новые ворота, но это не столь критично.
Как вы думаете, много в мире людей работающих с процедурным SQL? Море.
А «секретарша» знаете, у нее задача владеть языком без приставки «программироания» ;)khim
19.03.2017 00:53+1Визуальное программирование, это просто офигенская вещь, там все наглядно, там потрясающие системы отладки кода, вы просто визуально можете посмотреть куда какие данные перемещаются и как преобразуются.
Это всё работает пока у вас данных немного.
Главное требование, хорошее знание процедурного SQL, если человек это знает, ему не составит труда освоить язык программирования в ERP-Плтаформе.
Собственно это и означает что ваш язык попадает в нишу «НИАСИЛИЛ».
Все современные «большие» языки родились из попыток обуздать сложность. Когда команды из тысяч разработчиков пишут программы в сотни миллионов строк кода — то методы, отлично работавшие в 70е — работать перестают. И с этим нужно что-то делать. Отсюда — все эти новые парадигмы и прочее.
Однако, похоже, мы упёрлись: хотя существующие языки не идеальны, но наши попытки создать что-то ещё более удобное успехом не увенчались: небольшое упрощение (а многие новые языки, претендовавшие на статус «больших» этого реально достигают) приводит к тому, что существующие наработки приходится выкидывать — чего делать никто не хочет.
То же, что вы описываете выше — это сложность совсем другого рода: задача, сама по себе, не то, чтобы уж очень сложна (сложность скорее заключается в том, чтобы её правильно сформулировать), но люди, которые её решают — не хотят или не могут использовать «большие» языки. Что автоматически формирует очередную небольшую нишу, где может жить очередной специализированный мини-язычок. Но, как уже говорилось: он так и будет там жить ибо «путь наружу» для него закрыт. Попытка его «растянуть» до большого языка просто сделает его негодной для ЦА и всё, он умрёт.
Визуальное программирование, это просто офигенская вещь, там все наглядно, там потрясающие системы отладки кода, вы просто визуально можете посмотреть куда какие данные перемещаются и как преобразуются.
Когда у вас разных видов обьектов в программе — десятки, если не сотни, тысяч? Причём большая часть — это всевозможные контейнеры? Хотел бы я на это посмотреть.
Визуальное программирование — классная вещь, но, к сожалению, оно позволяет решать только очень простые задачи. Вы можете в качестве «атомов» для визуального языка взять разные весьма хитрые вещи, и, тем самым, сделать систему для очередной НИАСИЛИЛ ниши — но попытка сделать на этом что-то универсальное обречена на провал. Именно поэтому Wikipedia перечисляет буквально десятки подобных языков — каждый из которых живёт в своей отдельной, маленькой, нише.
А статья говорит о больших, то есть, универсальных языках.mail-online
19.03.2017 13:51-2Это всё работает пока у вас данных немного.
О чем вы вообще? На LabView реализуются крупнейшие проекты. Создаются программы любой сложности. А National Instruments, создатель языка G, одна их крупнейших международных корпораций с многомиллиардными активами и имеющая представительства в большинстве стран мира.
Когда у вас разных видов обьектов в программе — десятки, если не сотни, тысяч? Причём большая часть — это всевозможные контейнеры? Хотел бы я на это посмотреть.
Да хоть миллионы, это будет в 100 раз удобнее чем в тексте. Там все продумано, вы можете убирать код в блоки (можно обозвать их процедурами) и направлять и выводить из них потоки данных, вы можете группировать различные потоки данных в кластеры, причем даже подписывать каждый поток, вы можете делать «Stacked Sequence Structure» и писать поддиаграмы в последовательных закладках. Просто вы об этих вещах не знаете, ибо такого в «текстовых» языках просто нет.khim
19.03.2017 19:12+2На LabView реализуются крупнейшие проекты. Создаются программы любой сложности.
Примеры можно? Понятно, что сравнить с кодом на традиционных языках нельзя, потому давайте рассмотрим другой параметр. Количество контрибуторов.
Рассматривать экстремальные случаи типа ядра Линукса (где буквально тысячи разработчиков меняют один и тот же код), ограничимся примерами от ста разработчиков, имеющих право «трогать» код в одном компоненте.
Есть примеры?mail-online
19.03.2017 23:00-3Ну вот что сходу нашел:
1) Имитационный стенд для тестирования алгоритмов управления объектов нефтегазовой отрасли
2) Автоматезированная информационно-измерительная система испытания элементов авиационной техники на удар посторонними предметами
3) Создание испытательного стенда для тестирования атомного реактора нового поколения
4) Разработка имитатора паровой турбины для отладки системы управления
5) Разработка инструментальных средств для исследования алгоритмов поиска маршрута передвижения мобильного робота в условиях частичной неопределенности
и т.д.
можете покапаться тут по разделам (ссылка), тут сотни проектов, и это только в России и только о том что написали.
А вообще можете просто погуглить.
В чем я участвовал уж извиняйте, не буду описывать. Повторюсь только что можно писать программы любой сложности и у меня никаких проблем никогда не возникало. Если что-то понадобилось, то просто берешь и делаешь.
Для универстетов National Instruments свое ПО кстати бесплатно предоставляет насколько я знаю (хотя может что уже и изменилось). Решили что пусть студенты учатся. Так что уже выросло и еще вырастет поколение которое знает что такое LabView.Crandel
19.03.2017 23:19+2- Automating Measurements and Processing Signal Data
- Instrument Control
- Automating Test and Validation Systems
- Designing Embedded Control and Monitoring Systems
- Academic Teaching
Вот что у них на сайте сказано про сферы применения LabView.
С трудом и натяжкой к программированию можно отнести первый пункт. Все остальное — удел специализованного ПО, по типу автокада, которое помагает создавать модели домов или чего-то подобного. Мониторинг различных систем не является целью программирования.mail-online
20.03.2017 00:05-1Поверьте, сферы применения любые. Язык абсолютно универсален. Просто то их целевая аудитория.
khim
20.03.2017 02:46+3Так что уже выросло и еще вырастет поколение которое знает что такое LabView.
Да ради бога! Никто ж не против! Только какое это имеет отношение «к системам любой сложности»?
Повторюсь только что можно писать программы любой сложности и у меня никаких проблем никогда не возникало. Если что-то понадобилось, то просто берешь и делаешь.
Как именно? Я вам конкретный вопрос задал:Что будет если Вася решит добавить в формочку новый элемент (скажем забытое поле «Отчество»), а Петя, в это время, решит добавить в выбор пола новый вариант «Не Указано». Сможет ваша система это разрулить или нет?
Разработка больших систем состоит из одновременного редактирования компонент чуть более, чем полностью. Вы же тут рассказываете про какие-то стенды, имитаторы паровых турбин и прочее. С точки зрения программирования всё это — мелкие, очень простые проекты. В предметной области — да, там всё непросто. Но результирующая программа — достаточно мала для того, чтобы, условно говоря, «поместиться в голову» одному человеку. На этих масштабах — работает что угодно.
Сложности начинаются когда это сделать невозможно! И, я извиняюсь, ни одного подобного проекта на LabView я не видел…mail-online
20.03.2017 18:05-3Как именно? Я вам конкретный вопрос задал:
При помощи клавиатуры и мышки…
Разработка больших систем состоит из одновременного редактирования компонент чуть более, чем полностью
Причем тут язык то, вам нужна хорошая система контроля версий
Я извиняюсь, но времени не очень много с вами спорить днями и писать сочинения с доказательствами. Дел и так полно. Я уже написал вроде все.khim
20.03.2017 19:26+3Я извиняюсь, но времени не очень много с вами спорить днями и писать сочинения с доказательствами.
Да не нужны мне ваши сочинения. Примера того, как вы будете решать в графических языках проблему, которая для других языков решена diffом и patchем — будет вполне достаточно.
Причем тут язык то, вам нужна хорошая система контроля версий.
Как система контроля версий решит фундаментальную проблему: невозможность менять файл, который сейчас редактирует другой человек?
Я тоже когда-то работал с SourceSafe, который требовал «забирать» себе файл, который редактировал. И думал на тему, как бы этот процесс сделать поудобнее. Но современное решение, позволившее резко повысить сложность систем, с которыми люди работают — оказалось из совсем другой оперы. Нет никаких блокировок в git'е. Просто нет. Правки, сделанные разными людьми просто сливаются и всё. И это — позволяет разрабатывать системы на порядок более сложные, чем было до того.
И как вы это будете делать в LabView? Как вам «хорошая система контроля версий» поможет?mail-online
21.03.2017 10:23Тут бинарные файлы. Я вас понял что вы хотите.
diff может показать разницу между бинарными, но patch-ем насколько я знаю вы не сольете их.
У меня получилось слить так.
xdelta3 -e -s /var/tmp/test1.vi /var/tmp/test2.vi /var/tmp/patch
xdelta3 -d -s /var/tmp/test1.vi /var/tmp/patch /var/tmp/test_res.vi
Результирующий файл открылся. Проблем нет.
Но стало интересно. Провел еще более сложный эксперимент.
Например Вася и Петя взяли файл, одновременно отредактировали в нем разные вещи.
Пусть исходный будет (test1.vi):
Вася сделал так (test2.vi)
Петя сделал так (test3.vi)
Сначала сливает Вася, все ок.
xdelta3 -e -s /var/tmp/test1.vi /var/tmp/test2.vi /var/tmp/patch
xdelta3 -d -s /var/tmp/test1.vi /var/tmp/patch /var/tmp/test_res.vi
Потом с результирующим файлом (после Васи) сливает Петя.
Вычисляем разницу между файлом после обновления Васи и Петеным
xdelta3 -e -s /var/tmp/test_res.vi /var/tmp/test3.vi /var/tmp/patch2
Патчим в новый
xdelta3 -d -s /var/tmp/test_res.vi /var/tmp/patch2 /var/tmp/test_res2.vi
И получаем test_res2=test3. Т.е. изменения Васи были затерты Петей.
Вообще на мой взгляд это нерешаемая ситуация и с точки зрения текстового файла в diff. Ибо вот как слить итоговый:
так:
или так:
т.е. без подсказки программа не сможет понять сделать ей преобразование в текст до умножения или после.khim
21.03.2017 20:37+3т.е. без подсказки программа не сможет понять сделать ей преобразование в текст до умножения или после.
Это правда. Это и для текстовых языков верно. Однако для них — было обнаружено, что в большинстве случаев изменения даже в одном файле всё-таки затрагивают разные строки. И даже если 10 человек меняют там разные вещи — всё это, в большинстве случаев, можно автоматически слить.
Если не получается автоматически — git даст вам файл, где покажет все правки и вы сможете делать выбор — который будет запомнен в качестве шаблона!
И это — не какие-то трюки, которые показывают на выставке! Это — рутина! На этом построены все большие команды из сотен и тысяч разработчиков! Иначе — вы быстро упрётесь в то, что эти сотни и тысячи разработчиков «буксуют», у них нет возможности работать параллельно!
Потому когда вы тут говорите о том, что «можно делать проекты любой сложности» и даже не упоминаете эти проблемы у меня возникает реакция как у Станиславского: «не верю».
develop7
21.03.2017 14:49http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/merging_vis/ похоже, всё в порядке
ну то есть, какой-то инструмент для просмотра различий и 3-way merge в коробке имеется
khim
21.03.2017 20:40+1Уже хорошо. Показывает что контора об этом, по крайней мере, думает (в отличие от вас). Но это — только начало!
Дальше — возникают вопросы на тему «а насколько это всё можно автоматизировать», «как хорошо это всё тестируется» и т.д. и т.п.
То есть наличие таких унструментов указывает на то, что, по крайней мере среднего размера проекты на этом делать можно, но вот насчёт больших… сомнительно пока.
khim
19.03.2017 19:28+3Просто вы об этих вещах не знаете, ибо такого в «текстовых» языках просто нет.
Серьёзно? Нет модулей и нет передачи данных между ними? Это вы чего-то обкурились.
А вот чего нет в графических языках — так это удобной замены для «сладкой парочки» diff и patch. Как в этих ваших графических средах происходит работа, когда два человека одновременно меняют один компонент?
Параллельная работа десятков человек над разными компонентами не делает проект сложным. Сложности возникают тогда, когда десятки, сотни, иногда тысячи, разработчиков работают над одним компонентом!
Все «графические среды», которые я видел, этого в принципе не предполагают.
Что будет если Вася решит добавить в формочку новый элемент (скажем забытое поле «Отчество»), а Петя, в это время, решит добавить в выбор пола новый вариант «Не Указано». Сможет ваша система это разрулить или нет?
mail-online
19.03.2017 14:19-2Хех. Для «секретарши» — «НИАСИЛИЛ», не для «секретарши» — «НИАСИЛИЛ». Вы определитесь что ли.
Не, вполне возможно что и «НИАСИЛИЛ» пользуясь вашей терминологией, но понимаете, нет цели «АСИЛИЛ». Такие языки создаются для определенных вещей и никто не планирует на них захватывать и заставлять работать весь мир. Они сделаны для своих ниш, как и ваши «шаровые шарниры», которые сделаны для автомобилей, а не самолетов. Но в своих нишах они «короли» и универсальные языки там явно проигрывают.
PS: кстати, например трактор «Кировец» может поворачивать без использования ваших шаровых шарниров. Они ему просто не нужны. И это гораздо проще и надежнее.khim
19.03.2017 19:40+2Такие языки создаются для определенных вещей и никто не планирует на них захватывать и заставлять работать весь мир.
Поздравляю! Наконец-то! А теперь — внимание вопрос: нафига мы тогда мы их тут обсуждаем?!
Вы название статьи видели, нет? Речь во всей тутошней дискуссии идёт только и исключительно о больших языках, которые могут выйти из своей ниши и, условного говоря, «захватить мир». Ну пусть не весь мир, но, в общем — больше чем ты маленькую нишу, где они родились…
Как это сделали C, Lua, Python…
И к чему мы приходим после недели обсуждений? К тому что вы говорите о совсем другой реальности и о совсем других вещах нежели все остальные! О языках, которые, как ваш Кировец, «по трассам» не ездят! Ну и нафига их обсуждать на форуме таксистов?
Зачем?! Почему?!mail-online
20.03.2017 00:03-2Мир фрагментируется. Специализированные языки для своих ниш будут на порядок лучше решать задачи, чем универсальный язык. Они будут его оттуда вытеснять. Сферы применения специализированных языков будет все меньше и меньше, но конечно же останутся.
Беря ваш форум таксистов: на заре автомобилестроения были только легковые, грузовые и трактора. Сейчас легковые делятся на классы А, B, C и т.д. Грузоые по грузоподьемности и конструкции. А спецтехники вообще море необъятное. И никакие универсальные вещи их оттуда не вытеснят, потому что специализированная техника умеет лучше решать поставленные для ее ниши задачи.
Летняя и зимняя резины решают поставленные им задачи гораздо лучше чем демисезонная. Демисезонную покупает сейчас только ленивый.
Со временем универсальные языки будут находить все меньшее применение. Это мое мнение.
Но не об этом была речь. Дискуссию то вы развели. Я просто искренне поблагодарил автора за интересную статью, и указал ему что в нише где он находится, еще поле особо не копанное. Да и в целом о том что в статье не указан целый класс языков (можно это рассматривать как класс) которые будут постоянно появляться и теснить основные. Эволюцонно думаю останутся только программы поддерживающие систему локализации, они просто вытеснят конкурентов. Все более-менее крупные компании работающие в гибких бизнес нишах обзаведутся специализированными средствами локализации для своих программ.
Меня же вы пытаетесь убедить что все это ерунда и надо встараивать везде стандартный язык и это круче нет. Нет, это не круче, и это не будет работать. Почему я уже много раз описал.
Если говорить эволюционно, то попрут во всех нишах стандартные языки рано или поздно, они со специализированными не будут выдерживать конкуренции.khim
20.03.2017 03:20+2Мир фрагментируется. Специализированные языки для своих ниш будут на порядок лучше решать задачи, чем универсальный язык. Они будут его оттуда вытеснять.
Это очень смелое утверждение.
Со временем универсальные языки будут находить все меньшее применение. Это мое мнение.
Мнение иметь всегда полезно, но какие-нибудь подтверждающие факты будут?
Пока что происходит противоположное. Всякие SCUMMы и Sawzallы меняются на Python, Lua и Google Go. Вот последний пример. Просто потому что проще работать с одиним-двумя-тремя универсальными языками, чем с десятком специализированных.
Беря ваш форум таксистов: на заре автомобилестроения были только легковые, грузовые и трактора. Сейчас легковые делятся на классы А, B, C и т.д. Грузоые по грузоподьемности и конструкции. А спецтехники вообще море необъятное.
Угу. Но вот беда: за исключением очень узких ниш — всё это управляется одними и теми же рулём и педалями. В «спецтехнике» — да, встречаются какие диковинку, но разнообразия разных способов «порулить» (характерных для XIX века) не наблюдается.
Статья — о том, что и в программировании мы пришли туда же…
Меня же вы пытаетесь убедить что все это ерунда и надо встараивать везде стандартный язык и это круче нет. Нет, это не круче, и это не будет работать. Почему я уже много раз описал.
Вы много раз это постулировали — и ни разу не обосновали.
Если говорить эволюционно, то попрут во всех нишах стандартные языки рано или поздно, они со специализированными не будут выдерживать конкуренции.
Это шутка такая? Или вы действительно в это верите? Посмотрите вокруг! В других нишах — этим уже переболели и от собственных языков отказались: офисные пакеты и отладчики, не говоря уже об играх отказываются от специализированных языков и начинают использовать стандартные.
Все кругом идиоты, один вы — Д'Артаньян? Так, что ли?
Вместо голословных утверждений о том, что в вашей нише движение идёт в противоположную сторону от того, что происходит во всей индустрии, и рано или поздно вся индустрия обязательно развернётся и побежит за вами какие-нибудь доводы будут?
splav_asv
20.03.2017 16:29+2Вы же понимаете, что в конечном итоге в вопросе выбора языка всех интересует только завтраты на получение конечного продукта? Надеюсь, в этом моменте расхождений нет. Представим что везде пользуются исключительно специализированными языками. Для каждого из них поддерживаются обвязки для общих библиотек(та же математика). Для каждого нужно поддерживать актуальную документацию, развивать компиляторы, стандартную библиотеку… И, главное, какждого взятого на работу человека нужно обучать практически с нуля этому языку. И этот человек при этом будет понимать, что в соседней области ему опять нужно будет переучиваться. Я понимаю, что для большей части профессиональных программистов это не сильно проблема, но для нишевых, которые еще и знают предмет, задача выучить язык обычно воспринимается в штыки, особенно если особых плюсов не вижно. На языке общего назначения получается если и хуже, то не сильно. Дяже в среди языков общего назначения обычно популярны те, под которые просто нанять людей. Остальные, даже имеющие некоторые преимущества обычно с большим трудом прорываются на массовый рынок.
В университете нам преподавали LabView. Первая реакция была — а это зачем так всё сложно? Да, он нагляднее, его может быть проще осваивать профильному специалисту, но для человека уже умеющего программировать на, к примеру, Python и C это кажется дикой дичью. И это учитывая опыт Delphi с ее визуальным подходом, некоторый опыт работы с схемотехническими пакетами для FPGA и какой-никакой опыт работы с средами аналогового моделирования(Micro CAP).
Порог вхождения разменивается на скорость и удобство разработки в долгосрочной перспективе. При наличии удобных профильных библиотек и опяты разработки на языке общего назначения сложно заставить себя писать на специализированном. Даже на таком хорошем, как Matlab, к примеру.mail-online
20.03.2017 17:55-1Да, все верно, расхождений нет.
Один только нюанс, в специализированном языке постараются сделать чтобы логика была подбна типовому. Иначе никого просто не научите. Да и авторы языка делать ведь его будут не на пустом месте, а исходя из своего опыта в других языках и видения того что надо изменить в лучшую сторону.
интересует только завтраты на получение конечного продукта
Это один из пунктов ради которого и делается. Затраты на разработку движка разовые, зато потом идет постоянный выигрыш в скорости разработки на постоянной основе. В итоге это выигрышно.
По LabView — то что преподавали это хорошо. Я рад что преподают. Но мне кстати не преподавали а кинули сразу в бой, садись и разбирайся, и первые 3 дня мне тоже казалось дичью. Но когда пошла именно боевая практика, я понял насколько это офигенская штука в итоге. Просто кода учат, не пропускаешь через себя все нюансы. Нужна практика.
YemSalat
17.03.2017 06:00Вы опять же ограничиваете пользователей рамками ваших API. Если брать опять же пример ERP-Платформы — там пользователь может создавать свой API
Вы, похоже, не поняли что до вас пытаются донести.
Чем по-вашему собственное АПИ для сервисов отличается от собственного языка для тех же сервисов? (помимо более трудозатратной разработки во втором случае)
а компилятор не даст сделать того что не разрешено
Интерпретатор наверное? А то как вам компилятор «поймает», например вот такой код,:
readFile(userInput)
конфигурация окон составляется мышкой
Мне кажется что большинство разработчиков править конфиги предпочитает все-таки клавиатурой. А еще разрабатывать на том языке, который уже знают, вместо того чтобы изучать какой-то новый, да еще и с безумно низкой сферой применения.
mail-online
17.03.2017 09:27-2Интерпретатор наверное?
Именно компилятор. Вернее даже немного сложнее: интерпретаторо-компилятор. Сначала конфигурация интерпретатором переводится в понятный формат для компилятора, потом уже компилируется. Иначе вы не получите приемлемую скорость работы, если на ходу будите все составлять из конфигурации. Это касается логики работы.
Еще есть внешний интерпретатор, который располагает элементы в окне и дергает именно нужные в текущий момент для работы процедуры (тоже экономя ресурсы), процедуры для скрытых закладок он будет опускать.khim
17.03.2017 13:31+3Еще есть внешний интерпретатор, который располагает элементы в окне и дергает именно нужные в текущий момент для работы процедуры (тоже экономя ресурсы), процедуры для скрытых закладок он будет опускать.
Кошмар, просто кошмар. Вещи, которые в каком-нибудь Android'е — этот малозаметная деталька реализации — тут вынесены в качестве отдельного, чуть ли не центрального, элемента языка.
Собственно она потому и заметна что в этом мини языке мало чего есть — и именно это является его достоинством. А не то, что он умеет какие-то вещи, которые без него сделать нельзя.
P.S. Почитайте Лема. Тамошние дискуссии очень похожи на то, что у нас тут произошло… Только тут у нас — кучи «Големов» (ну ресурс такой… специфический) и появление «обычного человека» сбило всех с толку.mail-online
19.03.2017 00:29-2Вещи, которые в каком-нибудь Android'е — этот малозаметная деталька реализации — тут вынесены в качестве отдельного, чуть ли не центрального, элемента языка.
Скажите это разработчикам ядра андройда.khim
19.03.2017 01:00+2Скажите это разработчикам ядра андройда.
Я, в принципе, со многими из них знаком — и они не испытывают никаких иллюзий. Они прекрасно понимают, что то, что они делают с точки зрения Android'а — это всего-навсего «мешок с драйверами».
Что совершенно не означает, конечно, что это — ерунда, без которой можно обойтись без этого «мешка с драйверами» железка работать не будет. Такая себе подвеска.
И тут, так же, как и везде: когда, в своё время, технологический прогресс позволил сделать надёжные шаровые шарниры — это перевернуло всю отрасль автомобилестроения! Но не сделало этим самые шарниры чем-то центральным в нём…
khim
17.03.2017 13:24+1Чем по-вашему собственное АПИ для сервисов отличается от собственного языка для тех же сервисов?
Собственно mail-online дал ответ на этот вопрос — вот тут: Обучение новых сотрудников сюда не ставлю, ибо это не так сложно на самом деле и разово.
Если вы делаете свой, специальный язык для какой-то ниши, то вы можете сделать его настолько простым, что людям, работающим на этом языке, можно будет платить меньше, чем тем, кто способен освоить «полноценный» язык и API к нему.
Это — действительно огромная ниша, вернее даже десятки, сотни ниш. Но все они «заперты». Ровно то, что даёт им право на существование не даёт языкам из этой ниши возможности выйти «на оперативный простор».
dm_wrike
15.03.2017 00:09Спасибо за идею!
Если честно, расширять платформу языком программирования это действительно сложно и не всегда практично.
У нас есть публичный API, что решает часть потребностей в кастомизации.mail-online
15.03.2017 09:57На самом деле тут еще глубже. Нельзя именно «расширить».
Чтобы дать пользователю управление любым элементом, все эти элементы уже должны быть созданы при помощи внутреннего языка. В общем надо сначала сделать платформу с движком языка, а потом на нем уже написать существующую систему управления проектами.
Просто доработать то что есть, вряд ли возможно.
Свой язык в платформе, это глобальная и очень сложная задача.napa3um
15.03.2017 10:43«Глобальная и сложная задача» решена уже давно и многократно (например, в виде IActiveScript).
mail-online
15.03.2017 11:26С IActiveScript знаком чисто теоретически, поэтому не могу глубоко судить.
1) Эта технология от microsoft, т.е. для linux скорее всего не подойдет.
2) Как вы дадите пользователю аккаунта работать с базой данных?
mail-online
14.03.2017 23:12Еще отдельная интересная ниша, это LabView. И SaaS программирование и LabView (визуальное программирование) имеют немного непривычную логику с точки зрения привычных языков. Это отпечатки своих специфических ниш. И у них там пока мало конкурентов.
potorof
14.03.2017 23:58А по-моему наоборот, быстрый рост IT-индустрии как раз и тормозит появление новых языков. Так как надо все время бежать вперед, а не улучшать существующее.
am-amotion-city
15.03.2017 08:19тормозит появление новых языков
надо все время бежать вперед, а не улучшать существующееЯ вижу логическое противоречие в этих двух соседствующих тезисах :)
Leo_Gan
15.03.2017 08:14Вполне себе проглядывают ниши, где могут зародиться новые языки. Нужны для этого некие новые (но стабилизировавшиеся) условия, большая территория и незаселенность, так?
Вот к примеру незаселенная территория: GPU, TPU и разные перенастраиваемые массивы. Это было на периферии, а тут вдруг стало мэйнстримом, в кот. MSFT, Google, Amazon вкладывают сейчас немыслимые средства. Очень лакомая область. Так и просится, чтобы на ней появился язык для сборки логики на хардваре. Я в курсе, что подобные уже есть. Может быть один из них и стрельнет в нас.
Опять же территория Erlang. Вроде только сейчас она поспевает для массового заселения девелоперами. У Go почему-то не получилось. Надо разобраться, почему.
Еще просится на сцену метаязык, на котором можно собирать программы из любых других языков. Но это — типичная "интелектуальная штучка", которая никогда не приносит практич.результатов :(Prolych
15.03.2017 08:29У Го как раз получилось занять своё место в бекенде.
am-amotion-city
15.03.2017 10:38А есть какой-нибудь пример успеха, что-то не получается нагуглить? Только именно нормальный нагруженный backend, типа whatsapp, flickr, — такого уровня а не наколенную поделку?
То есть, про Java и эрланг это ясно и, так сказать, временем проверено. Вот для Go есть что-то такое, типа, как у твиттера было «из руби мы быстро выросли, пересисали все на JVM».
Prolych
15.03.2017 11:01Не получаеца нагуглить, то нахабрим в пару сек:
Яндекс
там же список лавок с бекендом на го
vedenin1980
15.03.2017 12:45+1А есть какой-нибудь пример успеха, что-то не получается нагуглить?
Не совсем бек, но на Go написан докер. А докер это сейчас практически стандарт де-факто для управления микросервисами (в том числе беками критичных сайтов) и вообще очень популярная технология.
am-amotion-city
15.03.2017 16:29С приложениями понятно,
goберут из-за его пакетной стратегии формирования исполняемых файлов. Vault, Consul, их вагон и маленькая тележка. И про докер я случайно слышал тоже.
Тезис был про «своё место в бекенде». Я просто совершенно себе не представляю, кто бы и зачем выбрал
goдля бекенда: навалять прототип гораздо проще и осмысленнее на руби/пхп/питоне/перле. А под нагрузкой у меня нет никакой уверенности в его выдержке, и success stories как-то нет. Если, конечно, не считать «Мы в Яндексе пробуем Го» за success story.
Мне понятен эрланг, мне понятна джава, мне пока совершенно непонятен го в этой роли.
Prolych
15.03.2017 16:35саксесс стори мона найти в отчётах с конференций: о)
недавно было что-то с хайлоада++
ErhoSen
19.03.2017 01:06+2Мажорное обновление Python 3, ломающее обратную совместимость, сформировалось в 2006 и называется Python 3000. Первый релиз вышел в 2008. Судя по тому что Python 2 бодр, весел, и все еще с нами, изначальные оценки по внедрению третьей версии к 3000 году были недалеки от истины.
Ради справедливости, и чтобы такого рода мысли не оседали в головах людей далёких от мира пайтона, следует заметить, что в 2017 начинать проект на python2 это моветон и крайне недальновидно. И как же приятно осознавать, что этого почти никто не делает.khim
19.03.2017 02:11-1Вот только не надо рассказывать сказок, а? Как и положено, люди не захотели мириться с бреднями людей, засевших у себя в «башне из слоновой кости» и развитие python2 продолжилось. Так что пользуйтесь python2 и не парьтесь.
vedenin1980
Почему? На данный момент, новых перспективных "островов" много: интернет вещей, виртуальная реальность, дополненная реальность, слабый специализированный ИИ (автономные машины, боты-секретари и т.п.). Другое дело сколько дадут нам новые языки.
Вообще, на мой взгляд через лет 10-15 должны появится языки в комбинации со слабым ИИ, где основное шаблонное кодирование будет делать ИИ, а программист будет исправлять ошибки и задавать условия на почти естественном языке, "аля сделай мне Rest сервис со следующими параметрами". Полностью автономный сильный ИИ появится не скоро, а вот ИИ для парного программирования с человеком — вполне уже возможен при текущих технологиях. Собственно современные IDE к этому все более идут. ИМХО, конечно.
MonkAlex
— Вот это больше не делай!
— Что вот это?
— Вот это, когда вот это и это!
…
— А куда делись мои деньги\моя работа\etc?
— Но ты же сказал вот это не делать >_<
Мечтать не вредно, но правильное обучение ИИ приблизительно равно обучению человека. Быстрее, но не дешевле.
vedenin1980
Естественно, но я говорил о шаблонных вещах, вроде верстки обычных страниц, реализации типовых вебсервисов (вот честно, сделать типой сайт с Rest, web. беком, который тупо делает CRUD сущностей с проверкой прав пользователей). Естественно, программиста они не заменять, но позволят ускорить его работу в разы, как современные IDE ускоряют работу программистов по сравнению с 80-ми.
Да потребуется долгое обучение ИИ, но один раз для миллионов клиентов, а потом их можно штамповать и продавать, как приложение к IDE. Сейчас статические анализаторы, IDE, анализаторы покрытия тестами и т.п. достаточно умны, чтобы поправлять программиста, если тот делает явные и не очень явные ошибки. Даже могут в теории делать рефакторинг почти в автоматическом режиме. Я не вижу никаких особых преград, чтобы связка "умная IDE + программист" не превратилась в связку "IDE со слабым ИИ + программист". Но, конечно, программиста ИИ в ближайшие десятилетия полностью не заменит, если не появится полноценный сильный ИИ (к тому же экономически более выгодный, чем человек, что тоже важно).
splav_asv
мимо.
sentyaev
Так это и так делается на автомате. Не скажу за все платформы, но на .NET это есть, а если вам не REST, а просто достаточно сайта с CRUD, он вам еще и стандартные формы нагенерит. Все что останется сделать это — сделать модельки данных и расставить аттрибуты валидации.
Уверен то же и для Rails есть и для Node.js (sails.js очень близко к этому).
Source
Это scaffolding называется, собственно в Rails 1.x он и появился (в Rails 1.2 его с REST подружили), а потом уже все остальные скопировали.
napa3um
Справедливости ради, визардов в своей Визуал-Студии для скафолдинга шаблона проекта Микрософт придумал задолго до хипстеров из веба (и наверняка эта идея ещё раньше была реализована в промышленных системах разработки других производителей).
sentyaev
Еще в '99 на Delphi можно было практически без написания кода накидать на форму контролов и получть вполне себе сносный CRUD.
napa3um
MFC с визардами появился у Микррсофта раньше таки лет на 5 — 10. Конкурентом от Борланда тогда была не VCL, а OWL.
Source
Можно скриншотик компонента для сносного CRUD? Почему-то я не помню в Delphi 6 ничего подобного…
sentyaev
Скриншотика нет, но помню был там TSQLClientDataSet.
Но могу конечно и ошибаться, у меня все что с Delphi 3 как в тумане, и только про D7 еще что-то помню.
Source
Ну, это не то… DataSet, насколько я помню, предполагал редактирование и создание записей прямо в табличном представлении, даже без визарда.
Source
Так причём тут визарды в VisualStudio? Или они позволяли REST-сервисы создавать ещё до появления такого понятия как REST? xD
napa3um
Принципиальным в вопросе был именно REST? Нет, тогда архитектурный подход веба и HTTP-протокол ещё не успели объединить этим баззвордом, придуманным чуть позже, но у Микррсофта был CRUD поверх HTTP в том числе (RPC, SOAP), помимо бинарных COM/DCOM.
sentyaev
Да это же как раз история последних 20 лет в разработке. Мы постоянно переизобретаем языки и фреймворки, причем они не решают ни одной новой задачи. А переизобретаем по одной простой причине — «Not invented here».
DjOnline
Самый толковый комментарий.
Source
В данной ветке да. Обсуждались конкретно типовые веб-сервисы, которые делают CRUD на базе REST. И "визарды" для них MS скопировала уже с Rails в рамках ASP.NET MVC.
napa3um
Да не нужно было ей ничего копировать, достаточно было добавить в визарде вариант «HATEOAS/REST/ODATA» к имевшимся «WSDL/SOAP», прикладной программист даже разницы может не заметить, переключая эти варианты. Не защищаю Микрософт, не дискредитирую Рэйлз, а всего лишь уличаю вас в синдроме утёнка. Конструктива в этом не так много, потому, пожалуй, на этом завершу свою компульсию.
(А WebComponents, если присмотреться, оказывается развитием концепции ActiveX, и именно Микрософтовцы продвигали компонентную философию в промышленность, и они сейчас входят в W3C.)
Source
Хм, я программировал на C# до Ruby… И довольно странно спорить о том, что ASP.NET MVC — это калька с Rails. Имхо, это очевидный факт для любого, кто видел классический ASP.NET. Естественно, MS не переписывала ради этого Visual Studio и использовала свои наработки в плане интерфейсов. Но концептуально всё скопировали и это хорошо, потому что до этого ASP.NET был ужасен (это я постарался наиболее мягкий эпитет подобрать).
napa3um
А почему, по-вашему, именно с Рэилз, а не с Джанго? Или почему не со Смалтолка, например? (Очевидно, потому, что вы как утёнок знаете только о Рэйлз.)
am-amotion-city
Ну вам, как знающему обо всем, включая smalltalk, наверняка не составит труда дать ссылку на
CRUD, реализованный в языке (Seaside не подойдет, извините, это не core smalltalk).Почему не django тоже в объяснении не нуждается любому, кто хотя бы примерно себе представляет, что такое джанго и как там реализуется CRUD.
Знание умных слов типа «Смалтолк» и «Джанго» вас, может, и сделает королем баззвордов, но не тут, это уж точно. Деффки.ру — вот прекрасное место для вашего кругозора.
napa3um
А вам?
Source
Потому что тогда был взлёт Rails и все с него копировали, не только MS.
Становление ASP.NET MVC я наблюдал ещё с момента бета-версий 1.0.
Если бы Вы были знакомы с Django и Seaside, то знали бы, что там есть весьма принципиальные отличия от Rails. В ASP.NET MVC 1.0 единственным "принципиальным" отличием было то, что они не успели весь функционал с Rails скопировать.
P.S. Пока по вашим коментам складывается ощущение, что Вы лично знаете про утёнка, но ни один из вышеназванных фреймворков в глаза не видели.
napa3um
Тогда же взлетала Джанго (и даже чуть раньше).
P.S.: Моё впечатление о вас аналогичное, не смущайтесь сильно.
potan
Дешевле, по скольку плохо обученные экземпляры утилизируются практически бесплатно.
Holahola
«правильное обучение ИИ приблизительно равно обучению человека. Быстрее, но не дешевле.» есть инфа о стоимости обучения ИИ?
dimm_ddr
Можно прикинуть. Для обучения ИИ нужны размеченные данные. Не знаю насколько точно можно оценить необходимое количество данных для еще не решенной задачи, может быть что и нельзя, но можно взять уже известные примеры и посмотреть на количество данных которыми обучали их. После оценки количества можно посчитать стоимость получения самих данных (тоже не всегда просто) и стоимость разметки оценив час работы специалиста и его производительность. Оценка будет грубая, но сделать можно.
Теоретически, чем больше слабых ИИ решающих определенную задачу, тем дешевле каждый новый — данные уже есть. Но нужно учесть что, во-первых, данные могут устаревать (для каких то задач, леопард будет и через десять лет также выглядеть скорее всего), во-вторых, данные могут быть закрытыми, в-третьих, каждый новый ИИ в уже освоенной области приносит все меньше и меньше пользы, либо требует все больше и больше данных для получения хоть какого-то преимущества.
splav_asv
Да пусть даже и дороже(если не порядки, конечно). ИИ можно неограниченно тиражировать, а это очень многое меняет.
sentyaev
Вот вам пример: Есть корзина с товарами.
Задача: получить размер скидки.
Расчет скидки:
1) Каждый 5 товар бесплатно.
2) В полнолуние в високосный год на «группу товаров А» условие #1 не действует.
3) По средам, если идет дождь скидка 10% на «группу товаров А», кроме Петербурга. Для Петербурга действует условие #1, но не действует условие #2.
А вот другая задача. Допустим у нас простой CRUD и десятки миллионов пользователей.
Я все это к тому, что результат работы программиста это не «код», а «решение задачи». Написание кода — рутина.
SumerkBogov
Приведенная вами задача уже лет 15 решается несколькими строчками на Prolog.
yshurik
Запустили 15 лет назад и все ещё ждем распечатку этой задачи? :)))
Eldhenn
«Программа разрабатывает способ этого достичь, но синтаксис языка не позволяет объяснить этот способ вам.»
grossws
42
sentyaev
Это понятно. Но я не про количество строк кода.
Если обобщить то, первая задача — это бизнес логика, вторая — архитектура.
И суть в том, что Prolog (или любой другой язык) не поможет вам создать алгоритм решения задачи, также как и не поможет вам спроектировать хорошую архитектуру.
Все упирается в то, что «Войну и мир» пишет не язык, а человек.
SumerkBogov
Подразумеваемые вами языки — императивные-алгоритмические. В них программист сочиняет и излагает в коде алгоритмы решения. Однако задача, которую вы привели выше, как невозможно сложную для написания императивного алгоритма, тем не менее очень легко решается прологом; программисту придется лишь изложить для программы правила задачи, «декларировать» их. Пролог решит задачу сам, без какого-либо переданного ему алгоритма. Приведенная вами задача — типичная задача для пролога на уровне букваря, пятой главы учебника. На хабре приличное число статей об этом ЯП.
sentyaev
Я ничего не подразумеваю. Задача не сложная, а стандартная.
Декларировать кто будет, Пролог?
Ну как вам Пролог архитектуру системы спроектирует? (это вторая задача)
khim
И не нужно нам тут рассказывать про то, что всё на свете можно свести к DFS с отрезаниями, пожалуйста: да, это правда — но ровно в том же смысле в каком любой алгоритм можно свести к программе на Malbolge с лентой. Да, это правда, но… зачем?