Комментарии 222
Новых естественных островов, на которых мог бы закрепиться свежий лидер, похоже не планируется
Почему? На данный момент, новых перспективных "островов" много: интернет вещей, виртуальная реальность, дополненная реальность, слабый специализированный ИИ (автономные машины, боты-секретари и т.п.). Другое дело сколько дадут нам новые языки.
Вообще, на мой взгляд через лет 10-15 должны появится языки в комбинации со слабым ИИ, где основное шаблонное кодирование будет делать ИИ, а программист будет исправлять ошибки и задавать условия на почти естественном языке, "аля сделай мне Rest сервис со следующими параметрами". Полностью автономный сильный ИИ появится не скоро, а вот ИИ для парного программирования с человеком — вполне уже возможен при текущих технологиях. Собственно современные IDE к этому все более идут. ИМХО, конечно.
— Что вот это?
— Вот это, когда вот это и это!
…
— А куда делись мои деньги\моя работа\etc?
— Но ты же сказал вот это не делать >_<
Мечтать не вредно, но правильное обучение ИИ приблизительно равно обучению человека. Быстрее, но не дешевле.
Мечтать не вредно, но правильное обучение ИИ приблизительно равно обучению человека. Быстрее, но не дешевле.
Естественно, но я говорил о шаблонных вещах, вроде верстки обычных страниц, реализации типовых вебсервисов (вот честно, сделать типой сайт с Rest, web. беком, который тупо делает CRUD сущностей с проверкой прав пользователей). Естественно, программиста они не заменять, но позволят ускорить его работу в разы, как современные IDE ускоряют работу программистов по сравнению с 80-ми.
Да потребуется долгое обучение ИИ, но один раз для миллионов клиентов, а потом их можно штамповать и продавать, как приложение к IDE. Сейчас статические анализаторы, IDE, анализаторы покрытия тестами и т.п. достаточно умны, чтобы поправлять программиста, если тот делает явные и не очень явные ошибки. Даже могут в теории делать рефакторинг почти в автоматическом режиме. Я не вижу никаких особых преград, чтобы связка "умная IDE + программист" не превратилась в связку "IDE со слабым ИИ + программист". Но, конечно, программиста ИИ в ближайшие десятилетия полностью не заменит, если не появится полноценный сильный ИИ (к тому же экономически более выгодный, чем человек, что тоже важно).
Это scaffolding называется, собственно в Rails 1.x он и появился (в Rails 1.2 его с REST подружили), а потом уже все остальные скопировали.
Можно скриншотик компонента для сносного CRUD? Почему-то я не помню в Delphi 6 ничего подобного…
Так причём тут визарды в VisualStudio? Или они позволяли REST-сервисы создавать ещё до появления такого понятия как REST? xD
В данной ветке да. Обсуждались конкретно типовые веб-сервисы, которые делают CRUD на базе REST. И "визарды" для них MS скопировала уже с Rails в рамках ASP.NET MVC.
(А WebComponents, если присмотреться, оказывается развитием концепции ActiveX, и именно Микрософтовцы продвигали компонентную философию в промышленность, и они сейчас входят в W3C.)
Хм, я программировал на C# до Ruby… И довольно странно спорить о том, что ASP.NET MVC — это калька с Rails. Имхо, это очевидный факт для любого, кто видел классический ASP.NET. Естественно, MS не переписывала ради этого Visual Studio и использовала свои наработки в плане интерфейсов. Но концептуально всё скопировали и это хорошо, потому что до этого ASP.NET был ужасен (это я постарался наиболее мягкий эпитет подобрать).
Потому что тогда был взлёт Rails и все с него копировали, не только MS.
Становление ASP.NET MVC я наблюдал ещё с момента бета-версий 1.0.
Если бы Вы были знакомы с Django и Seaside, то знали бы, что там есть весьма принципиальные отличия от Rails. В ASP.NET MVC 1.0 единственным "принципиальным" отличием было то, что они не успели весь функционал с Rails скопировать.
P.S. Пока по вашим коментам складывается ощущение, что Вы лично знаете про утёнка, но ни один из вышеназванных фреймворков в глаза не видели.
Теоретически, чем больше слабых ИИ решающих определенную задачу, тем дешевле каждый новый — данные уже есть. Но нужно учесть что, во-первых, данные могут устаревать (для каких то задач, леопард будет и через десять лет также выглядеть скорее всего), во-вторых, данные могут быть закрытыми, в-третьих, каждый новый ИИ в уже освоенной области приносит все меньше и меньше пользы, либо требует все больше и больше данных для получения хоть какого-то преимущества.
Пролог решит задачу сам, без какого-либо переданного ему алгоритма.Не надо только рассказывать сказки про Пролог, а? Пролог — это всего-навсего DFS с хитрым синтаксисом. Не более того.
И не нужно нам тут рассказывать про то, что всё на свете можно свести к DFS с отрезаниями, пожалуйста: да, это правда — но ровно в том же смысле в каком любой алгоритм можно свести к программе на Malbolge с лентой. Да, это правда, но… зачем?
К тому же нельзя исключать катастроф, вроде появления на порядок превосходящего традиционные компьютера с троичной системой счисления или появление доступных квантовых вычислений.
А в квантовые вычисления я как-то не верю. Квантовый компьютер может одновременно решать много задач — но вот на выходе будет суперпозиция из всех этих решений. А разделение результата будет занимать много времени.
Ну все, надо сообщить в IBM и Google, что бы работы сворачивали.
Но почему ни слова о Haskell?
Но почему ни слова о Haskell?
На данный момент в мире есть примерно 7 (семь!!!) коммерческих вакансий на Хаскеле: https://wiki.haskell.org/Jobs
вымершими будем считать те языки, на которых никто не разрабатывает в настоящий момент
его нельзя назвать живым. Впрочем это верно, только если верно предположение, что если нет большого количества открытых вакансий, то никто ничего и не разрабатывает.
его нельзя назвать живым.
Глупости. Я практически каждый день пишу на Haskell, можно пойти пособирать статистику коммитов по github-у какому-нибудь, из чего будет явно очевидно что на нём таки ежедневно пишет куча людей. Или сходите для разнообразия на #haskell на freenode, который обычно не замолкает более чем на несколько минут (ну ещё на ряд haskell-ориентированных более узко специализированных каналов вроде #haskell-lens, #haskell-beginners, #haskell-game, #haskell-infrastructure, etc). Один приятель ведёт стримы, где пишет на Haskell: и т.д. и т.п. Мне известна компания в городе, где я раньше жил, которая использует Haskell для критически важных частей своей системы. В настоящий момент на нём-таки разрабатывают, и не полтора анонимуса.
Поэтому, хотя ваш опыт безусловно имеет некоторую ценность, нельзя сказать что это объективный показатель. Собственно как и мой, как и чей либо еще. Это только слабое свидетельство в пользу, но никак не доказательство.
Каналы на фриноде тоже не могут таким доказательством считаться — они точно также никак не отображают количества людей разрабатывающих на хаскеле профессионально.
Тут ключевое — это то, как автор определил живость языка. У вас, как мне кажется, несколько другое понимание этого термина и в таком понимании хаскель безусловно жив.
Я и не утверждаю что это именно так. Но «я каждый день пишу» не попадает под данное определение живого языка. Компания с критической частью написанной на хаскеле — уже да, попадает.
Вы же сами сослались на определение, под которое-таки попадает:
вымершими будем считать те языки, на которых никто не разрабатывает в настоящий момент
Это уже боюсь ваши личные какие-то критерии и оценки, я обратил внимание именно на озвученный критерий, по которому вы и возразили, что якобы ему не соответствует, но ведь это не так от слова «совсем».
А личные критерии «о живости/мёртвости» языка программирования, — это такая разношёрстная и отнюдь не единогласная солянка, что я бы не стал придавать отдельным частностям какое-либо значение, если только критерии чётко и стройно не сформулированы. Я вот например вообще не связываю понятие «живости» языка с деятельностью коммерческих компаний, что видимо входит в прямое противоречие с вашим видением, но это моё личное и сюда я не вплетал.
Тут ключевое — это то, как автор определил живость языка. У вас, как мне кажется, несколько другое понимание этого термина и в таком понимании хаскель безусловно жив.
В том всё и дело, что я зацепился за авторское определение:
Используя аналогию с устной речью, вымершими будем считать те языки, на которых никто не разрабатывает в настоящий момент. Даже если компиляторы этих языков существуют, программы на них написанные можно запустить, а некоторые “историки программирования” все еще могут написать на них новый код.
Понимая его буквально, без каких-то особых личных «додумок» за кулисами, не добавляя ничего своего. В рамках этого определения Haskell бесспорно — жив.
Честно говоря навскидку сказать как еще можно объективно оценить количество разработчиков на хаскеле я не знаю.
Есть же рейтинги популярности ЯП. Например, по данным Redmonk он занимает 16-е место (между Go и Swift). Да, он только по данным Github и StackOverflow, но это даёт представление о размере сообщества.
Самый простой способ оценки, хоть и естественно крайне ненадежный — по количеству открытых вакансий
Я всегда считал, что кол-во открытых вакансий показывает показывает насколько рабочих мест больше, чем подходящих специалистов. Если их примерно поровну, то кол-во открытых вакансий будет стремиться к нулю, даже если есть миллион трудоустроенных специалистов. Разве не так?
Насчет открытых вакансий. В общем случае вы тут тоже правы, но можно учесть большую текучку кадров и частую смену работы программистами — сейчас это очень распространенное явление. А раз это явление распространено, то, при миллионе работающих программистов вакансий будет тоже много просто из-за текучки. С другой стороны я не могу утверждать, что это верно для любого языка. В среде людей пишущих на коболе или фортране, например, текучка может быть (и скорее всего есть) гораздо меньше.
Скорость выполнения — как в C, и при этом — со сборщиком мусора? Любопытно...
А вообще нужно иметь в виду что раскладывать и оптимизировать чисто-функциональный код на порядок проще, чем завязаный на последовательность действий и постоянные мутации состояния, эдакое педалирование регистров ручным приводом, не говоря уже о том, что чисто-функциональный код пустить в плеяду тредов ничего не стоит, чего отнюдь нельзя сказать об C например. Haskell помимо всего прочего по-настоящему «ленив», он не станет маппать весь список из 9000 элементов, если в итоге из него понадобилось только 3, замаппится только 3 элемента из 9000. Суммируя все особенности, можно зачастую получать больший перформанс, чем эквивалентная по смыслу реализация на С, но есть различные нюансы, которые нужно понимать и иметь в виду. Но основная соль-то даже не в этом, вот взять систему типов, тайпклассы, настоящий лаконичный полиморфизм, не перегруженный необходимостью писать полотна мета-манускриптов, чтобы сделать код действительно абстрактным, как это происходит с случае с C++ каким-нибудь, C даже рядом поставить не получится.
Есть старая, но почему-то плохо заполненная ниша языка описания аппаратуры. Есть Verilog и VHDL, несущие дух своей эпохи 80-х. Новое пока зарождается только в виде экспериментальных языков, которым пока не удается пробиться в промышленность.
Почему-то на картинке у o'reilly ISWIM и ML не имеют ничего общего, хотя читая статью (http://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf) у меня было ощущение, что таки ML прямое развитие.
И communicating sequential processes и actorы это фактически две разные модели.
Так и в языках программирования пора уходить от естественного отбора в сторону «разумного дизайна».
В условиях свободной конкуренции это вряд ли возможно. Как минимум, потребуется мощная организующая сила с ресурсами, суммарно превышающими возможности крупнейших корпораций. Думаю также, что каждый из создателей больших языков, от Бьярна до Гвидо, далее везде, готов привести массу доводов о том, что его-то дизайн как раз и есть самый разумный.
<xkcd-14-конкурирующих стандартов.jpg>
Совершенно неверный вывод из верных посылок.
Эволюция идёт во многом балгодаря изменичивости окружающей среды, а в нашей отрасли она крайне изменчивая.
Есть увеличение сроков изменений, но оно обусловлено взрослением индустрии и ни в коем случае не свидетельствует о конце времён.
Нет. Развитие квантового компьютера выльется в что то типа видеокарт, то есть доп. плата в комп вставляется, а ОСь уже решает для каких задач что использовать. Так что новых языков не будет, будет какая то небольшая надстройка над существующими типа cuda.
Распространение кроликов (в австралии) стало самым быстрым распространением млекопитающего вида в известной истории.
Остров нужен чтобы «кролики» появились и окрепли, а когда они окажутся в «австралии» их уже будет не остановить.
Но подходящей изоляции, кажется, нет.
Однако большинство новых видов появилось в обычных условиях
Да, и сейчас мы наблюдаем расцвет языков программирования. Их много, много новых, и многие из новых хороши.
С разнообразием, как раз, все в порядке.
Просто никто из новичков не станет лидером.
Уже есть. http://sneezy.cs.nott.ac.uk/QML/
Даже если квантовые вычисления случатся — они будут крайне ограниченными.
Для них будут использовать специальные микропрограммы, как для шейдеров в графике,
которые будут встраивать в программы на обычных языках программирования.
По поводу нового языка программирования, как мне видится, можно рассматривать с точки зрения либо нового устройства компьютера либо самого процесса программирования. В любом случае, для компьютеров настоящего любой код — компилируется в машинный…
Я бы представил программирование завтрашнего дня в терминах распределенных вычислений…
Но в целом, самое первое, что произойдет: будущий большой язык программирования свяжет ландшафты платформ воедино. Это будет замена фреймворков и платформенных «миксджетов», вероятно.
Просто сейчас все эти «гены-мемы» не очень-то просматриваются. Чтобы язык программирования стал большим он должен дать очередную волну массовости. То есть то, что сейчас делается большими усилиями глубоких специалистов должно стать массовым развлечением.
И в этом смысле, конечно же, есть предпосылки для множества новых языков. Огромного множества.
Просто пока об этом рассуждают люди не понимающие глубины «трендообразования», они не способны такие гены разглядеть.
Просто посмотрите сейчас на разнообразие средств программирования и множество узкоспециализированных систем, изучение и использование которых крайне дорого (трудозатратно) и Вы увидите лакуны для новых больших языков.
Можно просто взять тот же хабр по хабам и посмотреть на разнообразие сильно специализированных статей. Вот и перечисление будущих фич будущих языков.
Казалось бы, все идет по пути синтаксического сахара и новых онтологий, но если посмотреть на платформенный ландшафт, то очевидно, что идет только заполнение лакун. Так и работает естественный отбор. Как только некая фича оказывается достаточно значимой для организма или системы, она начинает трансформировать генотип или мемотип.
К слову, в том же 2009 году появился язык программирования Go, которые решает проблему массовой многозадачности гораздо более надежным способом — ”go routines”. Фактически, в нем реализован тот же принцип легковесной многозадачности, что и в Erlang.
Go уже научился прерывать работу зацикленной горутины, считать редукции?
Я именно спрашиваю, а не утверждаю. Потому что, очевидно, Golang развивается. И может быть там эти решения появляются. И я бы хотел об этом узнать, если так.
Моя критика тут в том, что утверждение в выделенной мной цитате, ИМХО не соответствует действительности. Ни первое, ни второе:
К слову, в том же 2009 году появился язык программирования Go, которые решает проблему массовой многозадачности гораздо более надежным способом — ”go routines”.
Более надежным способом, чем где? Чем в windows 1? Принцип тот же: процесс завис — система зависла. В Go приложении корутина зависла — приложение зависло. Спасает только то, что Go приложение берет gomaxprocs по умолчанию больше, чем 1. Если выставите 1, то приложение зависнет на горутине. Никаких средств переключения на другую корутину нет. Никаких средств прибить зависшую корутину нет. А проблема массовой многозадачности — ну да, решается. Только переключения между горутинами происходит в момент вызова функций внешних библиотек.
Фактически, в нем реализован тот же принцип легковесной многозадачности, что и в Erlang.
Даже рядом нет. Потому что у ерланга виртуальная машина интерпретирует код, поэтому может легко в любой момент переключаться между процессами. В го нет никакого интерпретатора или виртуальной машины.
В 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..")
}
Ну то есть, как будто бы в цикле какой-то сложный расчет, который залип.
Внешний вызов — он да, как раз позволит прервать эту корутину. Я об этом и писал.
Может какой-то есть аналог yield или Application.ProcessMessages?
На 1995 пришелся «массовый старт» интернета, при том Dial Up соединения были доступны и ранее.
Возможно я что то упускаю, но в списке «Острова не только для языков программирования»
нет чего то столь же масштабного, по крайней мере такого что еще не «выстрелило».
Возможно я скептик, но сомневаюсь что за углом нас ждет новый, не открытый, континент.
если метеорит не упадёт или ядерным грибом не накроет раньше
Если после такого в живых останется хоть сколько-то много людей, то инноваций в ИТ будет море — знания во многом есть, а рук для выполнения работ хватать не будет — автоматизация будет крайне необходимой и, скорее всего, сложно настраиваемой. Только полное уничтожение человечества может спасти ИТ от инноваций.
Android этого не сделал, следующая надежда — на IoT. Но там вначале должна произойти крупная катастрофа, возможно, с человеческими жертвами, для того чтобы люди отказались от подхода «тяп-ляп и в продакшн».
За последние 30 лет принципы работы компьютеров не изменились, как и не изменились основные концепции программирования. Я считаю, что нужно делать больший упор на создании и развитии фреймворков под конкретные задачи для существующих относительно низкоуровневых языков программирования, а не изобретать каждый раз велосипед.
Хорошие примеры расширения существующих языков фрейморками: JavaScript (Angular, Ember, React), PHP (Laravel), Java (Spring), C и C++ (Macintosh Toolbox, Qt, Gtk).
Изменились задачи и способы (или, скорее, масштабы) их реализации. Фреймворки и ЯП ведь не только «математические» новые принципы и фичи несут, они так же упрощают в проекте взаимодействие людей с очень разными ролями. Написать что угодно можно и на ассемблере, а вот чтобы написать это быстро, с миниумом багов и задействовав сразу кучу программистов, а потом ещё чтобы это поддерживалось много лет, — вот это уже нужно покумекать, какой инструмент выбрать. Я считаю, что нужно делать больший упор на экономику ИТ-отрасли, а не на идеалистические представления о том, каким должен быть сферический ЯП в вакууме.
Статья забывает про массовые вымирания. Нечто может поменяться и целая ветка очень быстро отправится на мороз. Вот тут нишевые языки могут внезапно стать мейнстримом.
Плюс старые языки уже не могут быстро адаптироваться к изменениям. А новые могут наследовать их лучшие свойства, убирая слабые. Рано или поздно старый яп внезапно может умереть, например, вместе со своим островом.
А вообще, если понимать программирование на уровне "генов", то можно легко адаптироваться к тому, как все течет и меняется
В 1980-х были очень популярна концепция экспертных систем построенных на LISP,
дело дошло до того что выпускали компьютеры исполняющие его непосредственно (lisp machines).
Но в какой то момент стало понятно что идея тупиковая, и и все довольно быстро прекратилось.
Вот если бы Брендан Эйх выполнил требования спецификации к языку для Netscape и написал Scheme-подобный язык (да с макросами, и с оптимизацией хвостовой рекурсии...) то масса новичков-программистов не удивлялась бы скобочкам, а бодро изучала SCIP и это, правда, пошло бы им и всем нам на пользу.
Уверяю вас, о Лиспе в том или ином виде, вы будете слышать всегда. Он невероятно живуч. Это ли не победа в эволюционной борьбе?
Просто обралось слишком большое комьюнити, очень чувствительных к тому, где писать знак операции — если он не между операндами у них начиналась паника.
Но вымер. Вымер резко, внезапно и без каких-либо предпосылок к этому. Наверное, историки до сих пор гадают, как так получилось.
Эволюция работает не только в животном мире, но и в любой подходящей среде.Это не аксиома, а утверждение, которое нужно сначала доказать, но автор почему-то принимает его за истину и строит на нём все дальнейшие рассуждения. А так как это утверждение ложно, то дальнейшие рассуждения не имеют смысла.
Думаю, что многим будет полезно ознакомиться с учебником логики, чтобы самим не делать подобных ошибок и сразу видеть их у других.
Думаю, вам будет полезно хотя бы Докинза почитать, на которого автор сослался.Откуда вы знаете, что я его не читал? Например, совершенно очевидно, что вы не читали учебник логики, но то что я не читал Докинза ниоткуда не следует.
У Докинза та же самая проблема, что и у автора — неправомерное расширение законов на другую область. Но даже если мы на минуту допустим, что Докинз прав, то это вообще никак не доказывает правоту автора статьи, потому что это три совершенно разных области, поэтому любые выводы и законы одной области совершенно неправомерно применять к другой без доказательств.
Эволюционные принципы уже очень давно вылезли за пределы биологииЧто значит «вылезли за пределы»? Развитие (эволюция) происходит в совершенно разных областях, но из этого не следует, что всё и везде развивается по одним и тем же законам.
и ни у кого нет сомнений в том,Это классическая манипуляция. У меня есть сомнения, поэтому ваше утверждение ложно. Более того, у меня есть не только сомнения, но и доказательства ложности этого утверждения.
эти принципы математическиеВсё наоборот, не эти принципы были выведены из математики, а были построены математические конструкции, взяв за основу некоторые из этих принципов. Но почти всё что угодно можно описать математическим языком, так что это ничего не значит.
не следствие какой-то божественной природы живой материиПричём здесь это? Не надо приписывать мне утверждений, которых я не делал.
Эволюция проявляется в очень широком классе естественных и неестественных систем, состоящих из множества однородных элементов, во взаимодействии которых можно сформулировать репликацию, изменчивость и отборДля лучшего понимания слово «эволюция» здесь лучше заменить на слово «развитие».
И развитие действительно происходит в очень широком классе систем, только в каждом классе оно происходит по своим законам. Дарвин вывел законы эволюции только для биологии, и никто ещё не доказал, что эти законы также действуют во всех остальных системах. Даже если есть какие-то общие законы с другой системой, то это совершенно не значит, что в другой системе будут действовать и другие законы.
Так же как и термодинамические модели не обязательно применять к физическим задачам, они хорошо себя показывают и в социологии, напримерГде доказательства? Возможно, какие-то модели и действуют, и что с того? Если доказана применимость модели к другой области — то всё отлично, но если доказательства нет — то это всё что угодно, но не наука. Это может быть религия или обычное балабольство, но чаще всего этим пользуется лженаука.
Ограниченность кругозора не всегда возможно компенсировать логикойА какой смысл в кругозоре, если он практически целиком состоит из заблуждений и логических противоречий? К сожалению, такое сейчас не редкость.
Кажется, что выполнение этих требований для языков программирования достаточно очевидно.
Я игнорируют только доказательство утверждения непосредственно, но не необходимость доказательства.
Есть тонкая разница.
Было бы куда правильнее привести существенную аргументационную базу в подтверждение базового предположения,
но и безумно занудно, при том.
Ваше утверждение что утверждение автора ложно тоже не аксиома и требует доказательства. Пока же такого доказательства нет автор вполне вправе делать предположения и выводы из них. Если его начальное утверждение окажется верным — все его утверждения (если в них нет самостоятельных логических ошибок) будут верны. Если не верным, то, в общем случае, выводы не будут иметь смысла. Но в данном конкретном частном случае, возможно, может получиться скорректировать первоначальное утверждение и выводы из него так, чтобы рассуждения остались корректными.
В математике это достаточно распространенный случай, когда на недоказанных утверждения строятся новые конструкции и делаются выводы. Не имеет смысла работать только с уже доказанно ложными утверждениями.
насколько язык должен распространиться, чтобы называться «большим» языком программирования?
P.S.
Если даже подвести статистику появления новых ЯП за последние 10 лет — статья уже кажется абсурдной.
- FPGA. Verilog? VHDL?
- Сверхмалый embeded. FORTH?
- SIMD. APL?
- Транспьютеры и графические сопроцессоры. Occam?
- ПЛК. Ladder?
- DSP.???
Думаю, что на стыке verilog, matlab и apl появится язык для массового проектирования FPGA
Сравнивая эволюционные ветви, можно обратить внимание на численность представителей вида, семейства или отряда. В этом смысле Земля — планета жуков, а не людей. Мы построили города, а поселились в них тараканы и голуби. В IT-сфере в этом смысле победят не С, не Haskell и не Ruby, а HTML, CSS и плохие программисты, их просто много и они постоянно откуда-то появляются, хватают самый простой для пищеварения язык, что непонятно выплёвывают и пишут, пишут… :) Новые успешные в этом смысле языки появляются вместе с новыми технологиями и новыми потребностями (например, веяниями моды).
Можно сравнить кто кого победит в схватке. Тут на Земле человеку с автоматом нет равных. В программировании во время соревнований сильнейший язык выбрать трудно. Я бы, если мне нужно было выбирать язык для себя, выбрал Haskell или Mathematica :) в первом можно быстро написать мощную и корректную программу, во втором — воспользоваться гигантской базой знаний и гибкостью, унаследованной от Лиспа. Python и R — тоже подходят, но мне они не практически нужны были в моей работе. Новый сильный язык родится тогда, например, когда параллельные вычисления станут формализованы до такой степени, чтобы об этом мог позаботиться компилятор. Мы наблюдали такое, когда родились сборщики мусора — классная история!
Можно сравнивать живучесть. Бактерии термофилы заняли нишу экстремальных температур и ни с кем не конкурируют. Их никто не съест — сварится, а они съедят кого угодно, варёного. Ледяные черви научились жить в снегу, а человек на вездеходе есть повсюду. В программировании такие экстремальные ниши будут появляться всегда. И всегда будут рождаться разновидности FORTH или того же Лиспа, просто в силу простоты реализации и интерпретации. И человек с С (или, возможно, с Rust) тоже будет повсюду.
Наконец, есть долгожители. Это тоже эволюционный успех! Хрящевые рыбы, гаттерии, гинкго и другие представители живой природы, хоть и немногочисленны, пережили массовые вымирания и населяют планету миллионы лет. Лямбда-исчисление, насление Дональда Кнута, а также Лисп, с нами надолго и, похоже, навсегда. И они не просто существуют, они развиваются! Mascyma, Wolfram Mathematica, Maple — это достижения Лиспа и филигранно отточенных алгоритмов! Haskell развивается медленно, и каждый свой шаг обмозговывает, обсуждает, но при этом рьяно ощупывает множество перспективных направлений. Может быть, он эволюционирует и изменится, но идеи, родившиеся благодаря ему, никуда уже не денутся. Именно на Haskell реализованы языки для формального доказательства теорем: Agda, Coq и Idris. Это тоже кусочек будущего.
Сила биосферы Земли в её разнообразии. Если человек, как самый сильный всех победит, ему же хуже будет. То что языков программирования много это очень хорошо, а вот сравнивать их и называть победителя неверно.
Вообще то раньше в высших заведениях изучали философию и даже заставляли по ней сдавать экзамены.
И сейчас учат и заставляют, вопрос только в том, какой именно части философии учат. Нам например рассказывали исключительно о первых древнегреческих философах, половина из которых даже не удосуживалась доказывать свои утверждения. Интересно, но практического применения никакого. Разве что как база для дальнейшего изучения.
А ещё странно, что ни автор, ни комментаторы не упоминают лекцию Роберта Мартина "The last programming language", в которой эта тема подробнейшим образом освещается. Очень рекомендую её всем интересующимся историей ЯП.
Эволюция — это непрерывный процесс проектирования и постройки создателями новых сущностей, от животных до языков программирования.
2. Новый язык обязательно появится, когда сделают процессоры, умеющие работать с двумерной+ памятью, а не с одномерной, в который мы все мучительно жаримся на сковородках многопоточности.
Грубо говоря, поток — это метрика времени, а память — это метрика пространства. На текущий момент мы пытаемся втиснуть большое количество метрик времени в одномерное пространство, и из-за этого мучаемся.
То есть правильная красивая программа, похожая на человека — это один поток исполнения в трёхмерной памяти. А то, что есть сейчас — многопоточные программы в одномерной памяти — это ад и чудовище.
Но на сегодняшний день, дешевле улучшать существующие языки. Но когда то наступит момент когда из-за принципа обратной совместимости уже будет невозможно улучшать существующий язык.
Если считать новую версию языка, новым языком. То можно сказать что новые языки появляются постоянно, просто под тем же названием.
Скажу вот что. Следующему языку скорее быть (и причин на это достаточно). И мне очень хочется ответить на эту статью другой статьей, воторую возможно предстоит написать. Для нового языка есть ряд предпосылок.
- проблемы с платформами (такими как JVM)
- недостаток производительности (упираемся в кремний)
- высокая сложность текущих языков
- проблемы с эволюцией текущий языков (неудачная модель развития Python и неудачная модель развития Java).
- параллельность на уровне языка
- возможность составлять dsl, при максимальной простоте грамматики языка.
проблемы с платформами (такими как JVM)
Например? Какая есть такая проблема в JVM, которую есть у любого провайдера JVM и которую нельзя обойти своей реализацией JVM?
неудачная модель развития Java
Например? С точки зрения бизнеса Java (и, скажем, PHP) вполне удачны, они относительно просты и стоимость разработчиков нижнего уровня (манкикодеров) относительно невысока при том что производительность таких разработчиков достаточно приемлемая. То что Java достаточно консервативна, большому бизнесу тоже на руку, он сам обычно весьма консервативен. В своей нише энтерпрайза Java вполне себе неплохо чувствует.
Начнем пожалуй с неудачной модели. Вы понимаете на что создатели обрекают язык, декларируя обратную совместимость? Java исчерпала свой бюджет сложности (для манкикодеров) когда вышла версия 5.0 Tiger. И это не я сказал, а Джошуа Блох. Java сложный язык. И те, кто считает Java простой не знают Java. Дальше будет тоже что и в случае с С++. И, поправочка, Java была консервативной, когда ей рулил Sun.
Т.е. по вашему мнению платформа идеальна?
Сторонние вендоры вам type-erasure починят? И unsigned типы добавят? и добавят большие массивы? И числовые типы заданной длины (как это сделано например в LLVM)? Там знаете можно сделать Int_256 или Int_128 (уже не помню как типы называются, знающие люди простят). И Java все-равно будет медленной.
Конечно же производительность Java адекватна решаемым ею задачам, однако сейчас мы упираемся в не только в тактовую частоту процессоров (которая не растет), но и в количество ядер, которое… тоже не очень то и растет.
И софт придется оптимизировать. И тут на сцену выйдут языки, с бекендом на LLVM. И, возможно, будут достаточно долго доминировать.
Беззнаковые типы нужны языку для низкоуровневых задач, а ля разбор бинарных форматов и упакованных структур данных, без UInt-ов это может оказаться предельно неоптимально.
А ещё беззнаковые целые ведут себя куда предсказуемей при операциях сдвига — что как раз и важно при разборе бинарных данных, где важное значение имеют отдельные биты
А ещё беззнаковые целые ведут себя куда предсказуемей при операциях сдвига — что как раз и важно при разборе бинарных данных, где важное значение имеют отдельные битыА вот как раз с этим в Java всё в порядке: >>> и >>>= вполне достаточная замена беззнаковости при работе с битовыми полями.
и добавят большие массивы?
Уже есть. Для этого достаточно библиотеки
И числовые типы заданной длины
Для произвольной длины ограниченной только памятью есть 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
В энтерпрайзе? Сомнительно, там не так важна скорость работы сколько надежность и поддержка старого кода.
Это понятно, но есть ли в них иной смысл кроме производительности и снижения затрат памяти? На мой взгляд, если вам требуется настолько низкоуровневый тюнинг и настолько экономить на спичках, то вы выбрали неправильный язык для своей задачи. Java этого не может просто потому что для её задач это не нужно. В теории реализовать в Java что-то подобное можно с помощью сишных библиотек (или даже просто массива байтов и обычного Java кода), но зачем? Зачем лимузину добавлять фичи внедорожников, если нормальные владельцы все равно по бездорожью на нем гонять не будут? Просто чтобы были?
Использование этих типов не дает никакой производительности и снижения затрат памяти (разве что на некоторых платформах), только семантику.
А в чем тут семантика? Всегда можно взять тип "с запасом", если нужно сделать валидацию на значения типов, то в Java (например в Spring) тоже самое можно сделать аннотациями (и куда более гибко, надежно и наглядно):
@Min(18)
@Max(120)
private Integer age; // возраст пользователя в нашем сайте для взрослых должен быть от 18 до 120 лет.
Причём мне кажется, что дело не только в «островках», но и в том, что начиная примерно с 80-90-х эволюция чуть ли не каждого заметного языка программирования пошла экстенсивным путём. В мире языков программирования не только у млекопитающей летучей мыши есть крылья; у всех есть крылья (и ноги, и хвосты).
Если посмотреть старые учебники программирования, там обычно языки делят по сфере применения: у этого есть средства для работы с графикой, у этого с математикой, а у этого удобный файловый ввод-вывод. Сейчас, конечно, тоже можно рассуждать о подобных вещах, но наши проблемы даже близко нельзя поставить с теми, старыми. Если сейчас нужен, скажем, пакет линейной алгебры, вы всегда найдёте его для любого меинстримного языка, в то время как раньше его могло не быть вообще.
Мода началась, наверно, с Java. В своё время это был язык, как мне кажется, с самой развитой стандартной библиотекой. Сейчас аналогичным образом поступает и Python, и .Net. Таким образом, в девяностых годах стимулом к переходу могли быть более развитые средства для работы с чем-нибудь. Сейчас эта разница стремительно сократилась, и можно рассуждать разве что о большем или меньшем удобстве работы, но принципиальных проблем для использования старых языков в новых областях всё меньше и меньше.
Рассмотрим островное происхождение языка 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 (был такой "динозавр") разбирали.
Иначе говоря: Неисповедимы пути Господне. (С)
Есть большая и не обжитая ниша, совсем не упоминаемая в статье. Можно их назвать «веб ориентированными 1С подобными языками». Поясню: 1С — это программа позволяющая себя произвольно редактировать изнутри. Не просто добавить поле, как в том же Wrike, или подредактировать интерфейс. А задать сложную логику работы по событиям, написать новый модуль, сделать сложный интерфейс.
Тот же подход применим к системе управления проектами по SaaS концепции. Это очень круто. За этим будущее. И этого практически нет. Вот ваш Wrike, по сути позволяет только добавлять новые поля и менять внешний вид интерфейса аккаунта (насколько я понял и справки). А чтобы клиент мог не выходя из аккаунта САМ разработать какой-то модуль, создать таблицу в базе данных, поставить какой-то триггер, написать хранимую процедуру, модернизировать любой элемент интерфейса, добавить новые поля ввода вывода?
Ведь в Wrike, да и во всех аналогичных системах: как сделано — так сделано. И бизнес должен подстраиваться под существующие структуры. Пользователь например не может дописать какие-то автоматические действия по событию изменения тех или иных данных. Или разработать необходимый компании модуль.
Будущее за SaaS системами, которые имеют встроенные языки программирования позволяющие это делать. Они обладают фантастически гибкими возможностями и на мой взгляд они буду вне конкуренции.
Вот пример пока единственной подобной системы: https://erp-platforma.com/. Здесь можно почитать как устроен сам язык: справка (Главы 3 и 4).
И эта ниша слабо развита ввиду очень большой сложности создания такого языка. Основная сложность — безопасность. Пуская в SaaS аккаунт — вы пускаете на свой сервер. И нельзя просто так давать программировать на вашем сервере. Это должна быть очень продуманная с точки зрения безопасности система, иначе вас просто сломают.
В ERP-Платформе например применены очень нестандартные схемы реализации языка, с внешним (пользовательским) и внутренним (системным) уровнями, общающиеся между собой через компилятор. А так же реализация пользовательской логики не в интерфейсе, а в базе данных. Интерфейс там служит только для вывода и редактирования данных, а вся логика обработки всего и вся задается в БД на аналоге PLSQL. Этим он как раз кардинально отличается от 1С, где логика реализуется в интерфейсе, а в БД только хранятся данные (насколько я в курсе, хотя не специалист по 1С).
Такого насколько я знаю нигде больше нет, и никто больше не делал. И это на мой взгляд единственный пусть для SaaS языка.
На практике благодаря взаимоинтеграции программирования интерфейса и базы, а так же встроенной CURD у меня получалось создать рабочий модуль раз в 5 быстрее, чем если это делать на PHP+SQL. Интерфейс вы можете разметить как в экселе, в ячейки накидать элементы форм управления, а к формам подцепить элементы базы данных. Очень удобно и быстро.
Но конечно это надо уметь. Как любой язык, его сначала надо изучить.
Это должна быть очень продуманная с точки зрения безопасности система, иначе вас просто сломают.Да — но причём тут язык? Засунуть в «песочницу» можно любой язык и, более того, вся история показывает что попытки сделать полноценную «песочницу» на уровне языка — обречены на провал.
И это на мой взгляд единственный пусть для SaaS языка.С чего вы взяли? Чем это отличается от требований того же AppEngine?
С чего вы взяли? Чем это отличается от требований того же AppEngine?
Да всем отличается. Это принципиально разные продукты. AppEngine это по сути хостинг с возможностью разработки. Вы можете стем же успехом арендовать сервер и там разворачивать свои приложения.
SaaS система управления проектами — это готовый продукт с определенной функциональностью, и вот этот продукт дает возможность управлять собой при помощи встроенного языка. Вы можете подредактировать и автоматизировать нюансы работы вашей компании. Такой тип языков — своя отдельная ниша.
Вы можете стем же успехом арендовать сервер и там разворачивать свои приложения.Не ставя при этом на свой сервер NoSQL, библиотеки манипуляции изображениями и прочим?
Такой тип языков — своя отдельная ниша.Почему? Зачем? Что вам мешает взять подходящую песочницу и вкрутить туда Python, Lua или, прости господи, PHP? Чего такого должны уметь все эти языки такого, чем не умеет Ruby или тот же Perl?
Просто вы говорите:
И это на мой взгляд единственный пусть для SaaS языка.Но не подкрепляете это громкое утверждение ровным счётом ничем.
Это должна быть очень продуманная с точки зрения безопасности система, иначе вас просто сломают язык, собственно, никак не ограничивает: как я уже сказал в песочницу можно засунуть любой язык.
Вы не можете «взять» песочницу, вам надо «сделать свою» песочницу. Вот вы возьмете тот же AppEngine. Максимум что вы там сделаете, это аля интернет магазин. Вот представим что вы там сделали свою платформу управления проектами, дает аккаунты пользователям, они заходят и пользуются теми алгоритмами что вы сделали. И вот вы этим пользователей пустите в свой аккаунт на котором у вас написана платформа чтобы они могли что-то редактировать? Они вам там такое наредактируют… Чтобы пользователю управляли аккаунтом на вашей платформе (которую вы создали в AppEngine) вам опять же надо сделать свою песочницу внутри той песочницы.
Если я не прав, приведите пример. Вот имея сервер, на нем имея сайт с платформой управления проектами, что я могу на этот сервер поставить, чтобы дать пользователю возможность произвольно менять алгоритмы работы именно его аккаунта, не затрагивая всех остальных пользователей?
Вот имея сервер, на нем имея сайт с платформой управления проектами, что я могу на этот сервер поставить, чтобы дать пользователю возможность произвольно менять алгоритмы работы именно его аккаунта, не затрагивая всех остальных пользователей?
Например, Docker и реализовать микросервисную архитектуру. Каждый пользователь будет иметь свои собственные инстансы микросервисов, полученные как образы доскера. Или использовать микросервисы и облака, у пользователей физически не будет доступа к чужому коду иначе чем через API с авторизацией.
В принципе, SAP подобные системы используют Java и при нормальных настройках безопасности достаточно сложно пользователю выйти за пределы своих прав (впрочем, идеальной защиты это не дает, всегда есть шанс что пользователь-хакер сможет найти дыру и повысить полномочия, но это проблема для любого доступа к серверу), но в принципе JVM достаточно хорошо умеет защищаться от таких пользователей, запрещая доступ куда не нужно при правильных настройках безопасности.
Но вопрос не в этом. Вопрос в том зачем нужен новый язык, когда тот же SAP и его аналоги прекрасно живут той же Java. Что есть такого в каком-нибудь 1С, чего не могут универсальные языки? И главное почему вы считаете что придуманная вами песочница будет безопаснее известных проверенных аналогов?
Пока правда не уверен что это может иметь практическое применение к облаку. Надо тут подумать.
Каждый контейнер будет иметь веб сервер и свой IP, надо как-то авторизировать пользователя и пробрасывать его за НАТ в нужный контейнер. Мне кажется это еще та задачка, особенно с двухфактороной авторизацией. Плюс есть файловые сервера где хранятся БД (это не веб сервер, он не резиновый), т.е. из контейнера надо туда давать доступ, причем базы тогда должны быть тоже изолированы в контейнерах. Как то не давать доступ из контейнера с вебом к файлам чужих контейнеров по IP (что проблематично давая доступ к php коду в контейнере).
Плюс вся эта инфростуктура должна создаваться автоматически при регистрации аккаунта.
В общем на мой взгляд это довольно сложная логистическая задача. Но повторюсь, надо подумать, так сходу не могу сказать что не имеет права на жизнь.
Плюс встает вопрос защиты ПО, т.е. код вашей системы будет в конейнере, и вы даете доступ к этому коду и средства программирования. Ничего не помешает его получить. Обфускация не сильно помогает в этом случае. Нужен хотя бы ionCube. SaaS тем и хороша, что код защищен.
В общем решение с контейнерами и доступом к штатному языку программирования на мой взгляд имеют свои минусы. Хотя не скажу что не имеют права на жизнь. Надо переварить поглубже.
А вот свой внутренний язык с пользовательским уровнем абстракции и интерпритатором, решает все эти проблемы. Напрямую доступа нет, но при этом есть возможность произвольного редактирования своего аккаунта.
В общем обобщая, свой язык в платформе решает проблему защиты кода смой платформы, проблему безопасности, проблему удобства доработки аккаунта, можно реализовывать свои нужные функции этого языка, которых нет в штатных. Понадобилось, сел, доделал и все пользователи радостно пользуются.
К структуре базы тоже надо дать доступ, в том числе к служебной информации, что явно не хорошо. Молчу уж удобстве редактирования базы, о CURD, снапшетах процедур, автоматических логов, автоматической структуре прав доступа к элементам и т.п. что реализуемо в качестве функций встроенного языка.
Есть микросервисы авторизации. Есть микросервисы работающие с базой данных. Они не доступны для редактирования, только для запросов (REST, SOUP, MQ query), они определяют какой пользователь имеет право на редактирования каких сущностей (например, запрещают админу одного проекта редактировать чужой проект). Ваши клиенты не должны иметь доступ к базе данных, только к сервисы, работающему с базой данных и под своей авторизацией и правами. Так же клиенты должны иметь возможность загружать свой код только в виде классов, реализующих определенные интерфейсы (явно заданными вами) и только для "своих" запросов.
что реализуемо в качестве функций встроенного языка
Ужасный костыль, к тому же глючный. Вместо того чтобы взять стандартные сервисы, стандартные библиотеки разграничения прав и безопасности (какой-нибудь Spring Security) и использовать их вы предлагаете КАЖДОЙ SAP системе придумывать свой язык? Проводить тестирования на безопасность (огромные деньги), обучение пользователей и программистов (ещё более дикие деньги), иметь проблемы с поиском специалистов (так как мало кто хочет изучать ваш ЯП, опыт в котором потом нельзя "продать" на рынке труда).
решает проблему защиты кода смой платформы, проблему безопасности
Серьезно? То есть язык сам раздает права на все объекты, сам определяет политики безопасности, сам по себе решает такие проблемы как SQL инжектион, кросс-браузерные запросы или кражу кук сессий? Или вы хотите создавать заново велосипед и писать заодно свой фреймворк, аля Spring Security?
А как вы будите давать доступ к элементам страницы если не можете их построить как индивидуальные сущности? При помощи чего можно их строить? Такие возможности дает только встроенный в SAP язык программирования. Иначе никак. А система без удобной системы настройки прав (одним-двумя кликами) и возможности настройки прав вплоть до каждого элемента, она просто ущербна.
Потом посмотрите на систему с точки зрения разработчика. Вот вы сделали свою SAP систему и решили сделать встроенный язык программирования для того чтобы дать возможность гибкой настройки системы пользователям. Ваш подход с использованием стандартного языка априоре обречен на провал. Я поясню: например система написана на php. По вашему, чтобы дать возможность редактирования каждого элемента системы, вы должны сделать пользователю изолированный контейнер с системой, поставить туда php и дать доступ к коду, причем вы даже не сможете обфусцировать код, ибо как дать доступ к редактированию каждого элемента, если пользователь просто не сможет найти данный элемент. Т.е. вы всем в свободный доступ дате код многолетней разработки своей компании… Ваш бизнес просто долго не просуществует.
вы предлагаете КАЖДОЙ SAP системе придумывать свой язык?
К сожалению именно так. Почему я выше описал. Да, это сложно, да это дорого. Но если вы хотите заниматься этим бизнесом и дать пользователям сервис универсального редактирования, вам придется это сделать, придется для СВОЕЙ SAP разработать СВОЙ язык программирования. Иначе бизнеса не будет.
Именно поэтому 99% SAP систем своего языка программирования не имеют. Я знаю попытки встроить php код, но именно отдельным индивидуальным новым модулем, но не в коем случае не редактор существующего кода. Никакая компания в здравом уме пускать в свой исходный код не будет (если вы не open source конечно).
По поводу обучения и опыта который нельзя продать.
1С программисты не могут продать опыт свой? Да они очень неплохо зарабатывают, гораздо больше чем большинство программистов популярных языков. И все потому, что их не так много и они ценятся. Они нужны, ибо система распространена.
Обучение: да, проводите обучение. Включите в свои тарифы определенный объем ежемесячного бесплатного обслуживания своими программистами клиента (чтобы он мог не ведя большие расходы доработать свои мелкие нюансы). Если клиенту необходимо разработать крупный модуль и он не шарит в языке этом, да это будет за деньги, как и в случае любого другого языка.
В любом деле производя продукт вы будите нести какие-то издержки.
Почитал про 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С, то свой язык бесполезен (кроме как для маркетинга), так как им никто вообще пользоваться не будет. Наличие нормального языка для настройки может быть определенным преимуществом.
Во-первых, 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 то не нужен, конфигурация окон составляется мышкой…
или рассматривают систему как черный ящикЧерный ящик это как раз таки системы без встроенного языка, а тут вы как раз знаете, что даже в самом плохом случае, вы прочтете мануал и сможете сделать необходимые вам изменения.
Я конечно не утверждаю что возможна идеальная безопасность, наверное такого не бывает. Но ее можно приблизить к этому архитектурно.Вы пока до сих пор не обьяснили почему для этого нужен свой, особый, язык. сотни разработчиков как-то обходятся без этого, однако — и только вам, вдруг, приспичило создавать свой язык.
Дискуссия развилась потому что люди не понимаю до конца этой темы и считают что можно обойтись стандартными вещами. Я попытался это все это аргументировано развеять, ибо проходил уже через все это и участвую в разработках ERP систем уже около 10 лет и знаю о чем говорю. Я видел разные способы и просто уже знаю как надо делать оптимально и почему. Но люди разные, кто-то понимает, кто-то нет, кто-то думает и пишет какие-то аргументы, у кого-то аргументов нет и просто минусует. Кто понял — я рад, кто нет — ну нет так нет.
Для вас напишу еще раз преимущества:
а) Скорость разработки системы на своей платформе. Вы можете сделать удобный редактор и типовые блоки для типовых и частых действий.
б) Безопасность системы. Давая стандартные языки, затруднительно обеспечить безопасность и защиту кода, при этом давая доступ к любому элементу.
с) Дать свободное редактирование любого существующего элемента (а не только новое) в рамках аккаунта
г) Деление системы на элементарные блоки дает большие преимущества. Можно сделать ту же систему назначения прав, можно делать типовые блоки упрощая разработку, можно вводить всякие интересные свойства элементов.
И т.д. нюансов миллионы. Все не описать.
Минусы:
а) Сложность разработки движка
б) Стоимость тестирования безопасности
Обучение новых сотрудников сюда не ставлю, ибо это не так сложно на самом деле и разово. А клиентов никто не заставляет учить, разве что сами не захотят. Они пользуются в первую очередь самим продуктом, а не средствами его разработки. Для них это просто бонус и гарантия что это не черный ящик.
Но если компания хочет развиваться в будущем, она должна будет это сделать, ибо ее в перспективе вытеснят те кто это сделал (ИХМО)
Я написал что есть ниша для языков необжитая. Она будет в будущем перспективно развиваться.Я, похоже, вас понял. И даже частично с вами согласен.
Ниша для ваших языков (вернее даже ниши!) есть, но, увы и ах, для них есть ёмкое название: НИАСИЛИЛ.
Что, в общем, обозначает, что из этого никогда не вырастет того, о чём говорится в статье. Об этом, мы, кстати, спорили и раньше (правда с другим автором),.
И т.д. нюансов миллионы. Все не описать.И не надо. Всё, что вы тут описываете, по сравнению с почти любой современной технологией для любого популярного языка выглядит как трёхколёсный велосипед рядом с современным авиалайнером. Если не авианосцем.
И потому все, читающие весь этот лепет на Хабре офигевают: «как? зачем? почему? кому?». Ответ — непрограммистам. Тем, кто НИАСИСИЛ.
Все задачи, которые вы тут описали — это мизер от любой современной Enterprise-Java системы. Но вот беда: люди, способные освоить Enterprise-Java — составляют небольшой процент населения. Их мало, они капризны и дорого стоят.
А что делать остальным? Нельзя ли для них сделать что-то попроще и на этом экономию на персонале устроить? Ответ: да. Вот для них — подобные языки и составляют.
Это — действительно огромная ниша. Однако вот беда: выйти из неё «на широкий простор» — не получится. Хороший пример Visual Fred и то, что с ним произошло.
В прошлом веке самым популярным языком программирования был Visual Basic. Вплоть до того, что чуть не половина программистов работали на нём. И вот у него были многие из вещей, о которых вы говорите: всякие «удобные редакторы и типовые блоки для типовых и частых действий» и прочее.
И все думали, что популярность ему приносит вот это вот всё — чего он такого хитрого умеет, чего всякие академические Java и C++ не могут.
Но со временем — оказалось, что добавить эти фичи в IDE для «полноценных» язков не так и сложно. А можно ещё «потянуть за уши» и вытянуть Visual Basic до полноценного языка. Обе вещи было проделаны.
Результат? Visual Basic умер. Он оказался слишком сложным для того, чтобы на нём писали те, кто работали в нише НИАСИЛИЛ, а его преимущества типа описанных вами выше — оказались никому ненужными при наличии тонн Wizard'ов.
А вот гораздо более убогие FBD со-товарищи — живут и здравствуют.
Так что не тешьте себя иллюзиями: вы живёте в нише НИАСИЛИЛ. Если вам повезло и для вас создали достаточно простой и функциональный язык — вам очень повезло. Радуйтесь. Но не думайте, что вы когда-либо выйдете из своей ниши.
Обучение новых сотрудников сюда не ставлю, ибо это не так сложно на самом деле и разово.Ну вот. Наконец-то ответ. То есть ваш язык — настолько прост, что ему «можно обучить секретаршу»? Да — это классический признак языка класса НИАСИЛИЛ. Для них не нужны программисты, умеющие программировать. Для них — достаточно «специалистов» прочитавших тоненькую инструкцию. К сожалению это же и ограничивает (и очень сильно ограничивает!) область применения подобных языков.
Об этом, мы, кстати, спорили и раньше (правда с другим автором),.
Ну это что-то прояснило ) Зачем вы на OPCSenator так наехали то? Он кстати хорошую статью написал. Я до вашей ссылки и не знал что некто FBD есть. Кстати он LabView мне напомнил, правда он намного примитивней LabView конечно.
Вы просто совсем не понимаете визуального программирования. Для вас это «безумные схемы». Я кстати вас могу понять. В далеком 2005 году, когда я заканчивал МАИ, я устроился работать на нашу кафедру. Попал в команду которая занималась разработкой программы вибрационной диагностики воздушно-реактивного двигателя в полете. Можно было по анализу сигнатур вибраций определить в каком элементе двигателя поломка (или скоро будет поломка) и что произошло (скоро произойдет). Все это естесвенно делалось на LabView. До этого я все делал в основном на Delphi и честно скажу, первые дня 3 я от LabView плевался, но когда на меня снизошло озарение и я понял как это работает, я забыл Delphi как страшный сон, и кстати по сей день к нему не возвращался ни разу. Именно поэтому могу вас понять, вспомнив те первые ощущения.
Визуальное программирование, это просто офигенская вещь, там все наглядно, там потрясающие системы отладки кода, вы просто визуально можете посмотреть куда какие данные перемещаются и как преобразуются. Вы просто этого не поймете пока вас жизнь не заставит реально на этом поработать. Я до сих пор многие вещи на LabView делаю, это очень удобно.
А FBD я думаю для техников офигенская вещь, и она реально будет популярна в своей нише.
То есть ваш язык — настолько прост, что ему «можно обучить секретаршу»?
Тут вы сразили просто наповал! Я просто даже не думал что нужны какие-то подробности. Главное требование, хорошее знание процедурного SQL, если человек это знает, ему не составит труда освоить язык программирования в ERP-Плтаформе. Причем даже все равно с какими базами человек работал, SQL он везде SQL. Отличия минимальные. Все остальное мимо. Ну желательно конечно чтобы на html и php не смотрел человек как баран на новые ворота, но это не столь критично.
Как вы думаете, много в мире людей работающих с процедурным SQL? Море.
А «секретарша» знаете, у нее задача владеть языком без приставки «программироания» ;)
Визуальное программирование, это просто офигенская вещь, там все наглядно, там потрясающие системы отладки кода, вы просто визуально можете посмотреть куда какие данные перемещаются и как преобразуются.Это всё работает пока у вас данных немного.
Главное требование, хорошее знание процедурного SQL, если человек это знает, ему не составит труда освоить язык программирования в ERP-Плтаформе.Собственно это и означает что ваш язык попадает в нишу «НИАСИЛИЛ».
Все современные «большие» языки родились из попыток обуздать сложность. Когда команды из тысяч разработчиков пишут программы в сотни миллионов строк кода — то методы, отлично работавшие в 70е — работать перестают. И с этим нужно что-то делать. Отсюда — все эти новые парадигмы и прочее.
Однако, похоже, мы упёрлись: хотя существующие языки не идеальны, но наши попытки создать что-то ещё более удобное успехом не увенчались: небольшое упрощение (а многие новые языки, претендовавшие на статус «больших» этого реально достигают) приводит к тому, что существующие наработки приходится выкидывать — чего делать никто не хочет.
То же, что вы описываете выше — это сложность совсем другого рода: задача, сама по себе, не то, чтобы уж очень сложна (сложность скорее заключается в том, чтобы её правильно сформулировать), но люди, которые её решают — не хотят или не могут использовать «большие» языки. Что автоматически формирует очередную небольшую нишу, где может жить очередной специализированный мини-язычок. Но, как уже говорилось: он так и будет там жить ибо «путь наружу» для него закрыт. Попытка его «растянуть» до большого языка просто сделает его негодной для ЦА и всё, он умрёт.
Визуальное программирование, это просто офигенская вещь, там все наглядно, там потрясающие системы отладки кода, вы просто визуально можете посмотреть куда какие данные перемещаются и как преобразуются.Когда у вас разных видов обьектов в программе — десятки, если не сотни, тысяч? Причём большая часть — это всевозможные контейнеры? Хотел бы я на это посмотреть.
Визуальное программирование — классная вещь, но, к сожалению, оно позволяет решать только очень простые задачи. Вы можете в качестве «атомов» для визуального языка взять разные весьма хитрые вещи, и, тем самым, сделать систему для очередной НИАСИЛИЛ ниши — но попытка сделать на этом что-то универсальное обречена на провал. Именно поэтому Wikipedia перечисляет буквально десятки подобных языков — каждый из которых живёт в своей отдельной, маленькой, нише.
А статья говорит о больших, то есть, универсальных языках.
Это всё работает пока у вас данных немного.
О чем вы вообще? На LabView реализуются крупнейшие проекты. Создаются программы любой сложности. А National Instruments, создатель языка G, одна их крупнейших международных корпораций с многомиллиардными активами и имеющая представительства в большинстве стран мира.
Когда у вас разных видов обьектов в программе — десятки, если не сотни, тысяч? Причём большая часть — это всевозможные контейнеры? Хотел бы я на это посмотреть.
Да хоть миллионы, это будет в 100 раз удобнее чем в тексте. Там все продумано, вы можете убирать код в блоки (можно обозвать их процедурами) и направлять и выводить из них потоки данных, вы можете группировать различные потоки данных в кластеры, причем даже подписывать каждый поток, вы можете делать «Stacked Sequence Structure» и писать поддиаграмы в последовательных закладках. Просто вы об этих вещах не знаете, ибо такого в «текстовых» языках просто нет.
На LabView реализуются крупнейшие проекты. Создаются программы любой сложности.Примеры можно? Понятно, что сравнить с кодом на традиционных языках нельзя, потому давайте рассмотрим другой параметр. Количество контрибуторов.
Рассматривать экстремальные случаи типа ядра Линукса (где буквально тысячи разработчиков меняют один и тот же код), ограничимся примерами от ста разработчиков, имеющих право «трогать» код в одном компоненте.
Есть примеры?
1) Имитационный стенд для тестирования алгоритмов управления объектов нефтегазовой отрасли
2) Автоматезированная информационно-измерительная система испытания элементов авиационной техники на удар посторонними предметами
3) Создание испытательного стенда для тестирования атомного реактора нового поколения
4) Разработка имитатора паровой турбины для отладки системы управления
5) Разработка инструментальных средств для исследования алгоритмов поиска маршрута передвижения мобильного робота в условиях частичной неопределенности
и т.д.
можете покапаться тут по разделам (ссылка), тут сотни проектов, и это только в России и только о том что написали.
А вообще можете просто погуглить.
В чем я участвовал уж извиняйте, не буду описывать. Повторюсь только что можно писать программы любой сложности и у меня никаких проблем никогда не возникало. Если что-то понадобилось, то просто берешь и делаешь.
Для универстетов National Instruments свое ПО кстати бесплатно предоставляет насколько я знаю (хотя может что уже и изменилось). Решили что пусть студенты учатся. Так что уже выросло и еще вырастет поколение которое знает что такое LabView.
Так что уже выросло и еще вырастет поколение которое знает что такое LabView.Да ради бога! Никто ж не против! Только какое это имеет отношение «к системам любой сложности»?
Повторюсь только что можно писать программы любой сложности и у меня никаких проблем никогда не возникало. Если что-то понадобилось, то просто берешь и делаешь.Как именно? Я вам конкретный вопрос задал:
Что будет если Вася решит добавить в формочку новый элемент (скажем забытое поле «Отчество»), а Петя, в это время, решит добавить в выбор пола новый вариант «Не Указано». Сможет ваша система это разрулить или нет?Разработка больших систем состоит из одновременного редактирования компонент чуть более, чем полностью. Вы же тут рассказываете про какие-то стенды, имитаторы паровых турбин и прочее. С точки зрения программирования всё это — мелкие, очень простые проекты. В предметной области — да, там всё непросто. Но результирующая программа — достаточно мала для того, чтобы, условно говоря, «поместиться в голову» одному человеку. На этих масштабах — работает что угодно.
Сложности начинаются когда это сделать невозможно! И, я извиняюсь, ни одного подобного проекта на LabView я не видел…
Как именно? Я вам конкретный вопрос задал:
При помощи клавиатуры и мышки…
Разработка больших систем состоит из одновременного редактирования компонент чуть более, чем полностью
Причем тут язык то, вам нужна хорошая система контроля версий
Я извиняюсь, но времени не очень много с вами спорить днями и писать сочинения с доказательствами. Дел и так полно. Я уже написал вроде все.
Я извиняюсь, но времени не очень много с вами спорить днями и писать сочинения с доказательствами.Да не нужны мне ваши сочинения. Примера того, как вы будете решать в графических языках проблему, которая для других языков решена diffом и patchем — будет вполне достаточно.
Причем тут язык то, вам нужна хорошая система контроля версий.Как система контроля версий решит фундаментальную проблему: невозможность менять файл, который сейчас редактирует другой человек?
Я тоже когда-то работал с SourceSafe, который требовал «забирать» себе файл, который редактировал. И думал на тему, как бы этот процесс сделать поудобнее. Но современное решение, позволившее резко повысить сложность систем, с которыми люди работают — оказалось из совсем другой оперы. Нет никаких блокировок в git'е. Просто нет. Правки, сделанные разными людьми просто сливаются и всё. И это — позволяет разрабатывать системы на порядок более сложные, чем было до того.
И как вы это будете делать в LabView? Как вам «хорошая система контроля версий» поможет?
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. Ибо вот как слить итоговый:
так:
или так:
т.е. без подсказки программа не сможет понять сделать ей преобразование в текст до умножения или после.
т.е. без подсказки программа не сможет понять сделать ей преобразование в текст до умножения или после.Это правда. Это и для текстовых языков верно. Однако для них — было обнаружено, что в большинстве случаев изменения даже в одном файле всё-таки затрагивают разные строки. И даже если 10 человек меняют там разные вещи — всё это, в большинстве случаев, можно автоматически слить.
Если не получается автоматически — git даст вам файл, где покажет все правки и вы сможете делать выбор — который будет запомнен в качестве шаблона!
И это — не какие-то трюки, которые показывают на выставке! Это — рутина! На этом построены все большие команды из сотен и тысяч разработчиков! Иначе — вы быстро упрётесь в то, что эти сотни и тысячи разработчиков «буксуют», у них нет возможности работать параллельно!
Потому когда вы тут говорите о том, что «можно делать проекты любой сложности» и даже не упоминаете эти проблемы у меня возникает реакция как у Станиславского: «не верю».
Дальше — возникают вопросы на тему «а насколько это всё можно автоматизировать», «как хорошо это всё тестируется» и т.д. и т.п.
То есть наличие таких унструментов указывает на то, что, по крайней мере среднего размера проекты на этом делать можно, но вот насчёт больших… сомнительно пока.
Просто вы об этих вещах не знаете, ибо такого в «текстовых» языках просто нет.Серьёзно? Нет модулей и нет передачи данных между ними? Это вы чего-то обкурились.
А вот чего нет в графических языках — так это удобной замены для «сладкой парочки» diff и patch. Как в этих ваших графических средах происходит работа, когда два человека одновременно меняют один компонент?
Параллельная работа десятков человек над разными компонентами не делает проект сложным. Сложности возникают тогда, когда десятки, сотни, иногда тысячи, разработчиков работают над одним компонентом!
Все «графические среды», которые я видел, этого в принципе не предполагают.
Что будет если Вася решит добавить в формочку новый элемент (скажем забытое поле «Отчество»), а Петя, в это время, решит добавить в выбор пола новый вариант «Не Указано». Сможет ваша система это разрулить или нет?
Не, вполне возможно что и «НИАСИЛИЛ» пользуясь вашей терминологией, но понимаете, нет цели «АСИЛИЛ». Такие языки создаются для определенных вещей и никто не планирует на них захватывать и заставлять работать весь мир. Они сделаны для своих ниш, как и ваши «шаровые шарниры», которые сделаны для автомобилей, а не самолетов. Но в своих нишах они «короли» и универсальные языки там явно проигрывают.
PS: кстати, например трактор «Кировец» может поворачивать без использования ваших шаровых шарниров. Они ему просто не нужны. И это гораздо проще и надежнее.
Такие языки создаются для определенных вещей и никто не планирует на них захватывать и заставлять работать весь мир.Поздравляю! Наконец-то! А теперь — внимание вопрос: нафига мы тогда мы их тут обсуждаем?!
Вы название статьи видели, нет? Речь во всей тутошней дискуссии идёт только и исключительно о больших языках, которые могут выйти из своей ниши и, условного говоря, «захватить мир». Ну пусть не весь мир, но, в общем — больше чем ты маленькую нишу, где они родились…
Как это сделали C, Lua, Python…
И к чему мы приходим после недели обсуждений? К тому что вы говорите о совсем другой реальности и о совсем других вещах нежели все остальные! О языках, которые, как ваш Кировец, «по трассам» не ездят! Ну и нафига их обсуждать на форуме таксистов?
Зачем?! Почему?!
Беря ваш форум таксистов: на заре автомобилестроения были только легковые, грузовые и трактора. Сейчас легковые делятся на классы А, B, C и т.д. Грузоые по грузоподьемности и конструкции. А спецтехники вообще море необъятное. И никакие универсальные вещи их оттуда не вытеснят, потому что специализированная техника умеет лучше решать поставленные для ее ниши задачи.
Летняя и зимняя резины решают поставленные им задачи гораздо лучше чем демисезонная. Демисезонную покупает сейчас только ленивый.
Со временем универсальные языки будут находить все меньшее применение. Это мое мнение.
Но не об этом была речь. Дискуссию то вы развели. Я просто искренне поблагодарил автора за интересную статью, и указал ему что в нише где он находится, еще поле особо не копанное. Да и в целом о том что в статье не указан целый класс языков (можно это рассматривать как класс) которые будут постоянно появляться и теснить основные. Эволюцонно думаю останутся только программы поддерживающие систему локализации, они просто вытеснят конкурентов. Все более-менее крупные компании работающие в гибких бизнес нишах обзаведутся специализированными средствами локализации для своих программ.
Меня же вы пытаетесь убедить что все это ерунда и надо встараивать везде стандартный язык и это круче нет. Нет, это не круче, и это не будет работать. Почему я уже много раз описал.
Если говорить эволюционно, то попрут во всех нишах стандартные языки рано или поздно, они со специализированными не будут выдерживать конкуренции.
Мир фрагментируется. Специализированные языки для своих ниш будут на порядок лучше решать задачи, чем универсальный язык. Они будут его оттуда вытеснять.Это очень смелое утверждение.
Со временем универсальные языки будут находить все меньшее применение. Это мое мнение.Мнение иметь всегда полезно, но какие-нибудь подтверждающие факты будут?
Пока что происходит противоположное. Всякие SCUMMы и Sawzallы меняются на Python, Lua и Google Go. Вот последний пример. Просто потому что проще работать с одиним-двумя-тремя универсальными языками, чем с десятком специализированных.
Беря ваш форум таксистов: на заре автомобилестроения были только легковые, грузовые и трактора. Сейчас легковые делятся на классы А, B, C и т.д. Грузоые по грузоподьемности и конструкции. А спецтехники вообще море необъятное.Угу. Но вот беда: за исключением очень узких ниш — всё это управляется одними и теми же рулём и педалями. В «спецтехнике» — да, встречаются какие диковинку, но разнообразия разных способов «порулить» (характерных для XIX века) не наблюдается.
Статья — о том, что и в программировании мы пришли туда же…
Меня же вы пытаетесь убедить что все это ерунда и надо встараивать везде стандартный язык и это круче нет. Нет, это не круче, и это не будет работать. Почему я уже много раз описал.Вы много раз это постулировали — и ни разу не обосновали.
Если говорить эволюционно, то попрут во всех нишах стандартные языки рано или поздно, они со специализированными не будут выдерживать конкуренции.Это шутка такая? Или вы действительно в это верите? Посмотрите вокруг! В других нишах — этим уже переболели и от собственных языков отказались: офисные пакеты и отладчики, не говоря уже об играх отказываются от специализированных языков и начинают использовать стандартные.
Все кругом идиоты, один вы — Д'Артаньян? Так, что ли?
Вместо голословных утверждений о том, что в вашей нише движение идёт в противоположную сторону от того, что происходит во всей индустрии, и рано или поздно вся индустрия обязательно развернётся и побежит за вами какие-нибудь доводы будут?
В университете нам преподавали LabView. Первая реакция была — а это зачем так всё сложно? Да, он нагляднее, его может быть проще осваивать профильному специалисту, но для человека уже умеющего программировать на, к примеру, Python и C это кажется дикой дичью. И это учитывая опыт Delphi с ее визуальным подходом, некоторый опыт работы с схемотехническими пакетами для FPGA и какой-никакой опыт работы с средами аналогового моделирования(Micro CAP).
Порог вхождения разменивается на скорость и удобство разработки в долгосрочной перспективе. При наличии удобных профильных библиотек и опяты разработки на языке общего назначения сложно заставить себя писать на специализированном. Даже на таком хорошем, как Matlab, к примеру.
Один только нюанс, в специализированном языке постараются сделать чтобы логика была подбна типовому. Иначе никого просто не научите. Да и авторы языка делать ведь его будут не на пустом месте, а исходя из своего опыта в других языках и видения того что надо изменить в лучшую сторону.
интересует только завтраты на получение конечного продукта
Это один из пунктов ради которого и делается. Затраты на разработку движка разовые, зато потом идет постоянный выигрыш в скорости разработки на постоянной основе. В итоге это выигрышно.
По LabView — то что преподавали это хорошо. Я рад что преподают. Но мне кстати не преподавали а кинули сразу в бой, садись и разбирайся, и первые 3 дня мне тоже казалось дичью. Но когда пошла именно боевая практика, я понял насколько это офигенская штука в итоге. Просто кода учат, не пропускаешь через себя все нюансы. Нужна практика.
Вы опять же ограничиваете пользователей рамками ваших API. Если брать опять же пример ERP-Платформы — там пользователь может создавать свой API
Вы, похоже, не поняли что до вас пытаются донести.
Чем по-вашему собственное АПИ для сервисов отличается от собственного языка для тех же сервисов? (помимо более трудозатратной разработки во втором случае)
а компилятор не даст сделать того что не разрешено
Интерпретатор наверное? А то как вам компилятор «поймает», например вот такой код,:
readFile(userInput)
конфигурация окон составляется мышкой
Мне кажется что большинство разработчиков править конфиги предпочитает все-таки клавиатурой. А еще разрабатывать на том языке, который уже знают, вместо того чтобы изучать какой-то новый, да еще и с безумно низкой сферой применения.
Интерпретатор наверное?
Именно компилятор. Вернее даже немного сложнее: интерпретаторо-компилятор. Сначала конфигурация интерпретатором переводится в понятный формат для компилятора, потом уже компилируется. Иначе вы не получите приемлемую скорость работы, если на ходу будите все составлять из конфигурации. Это касается логики работы.
Еще есть внешний интерпретатор, который располагает элементы в окне и дергает именно нужные в текущий момент для работы процедуры (тоже экономя ресурсы), процедуры для скрытых закладок он будет опускать.
Еще есть внешний интерпретатор, который располагает элементы в окне и дергает именно нужные в текущий момент для работы процедуры (тоже экономя ресурсы), процедуры для скрытых закладок он будет опускать.Кошмар, просто кошмар. Вещи, которые в каком-нибудь Android'е — этот малозаметная деталька реализации — тут вынесены в качестве отдельного, чуть ли не центрального, элемента языка.
Собственно она потому и заметна что в этом мини языке мало чего есть — и именно это является его достоинством. А не то, что он умеет какие-то вещи, которые без него сделать нельзя.
P.S. Почитайте Лема. Тамошние дискуссии очень похожи на то, что у нас тут произошло… Только тут у нас — кучи «Големов» (ну ресурс такой… специфический) и появление «обычного человека» сбило всех с толку.
Вещи, которые в каком-нибудь Android'е — этот малозаметная деталька реализации — тут вынесены в качестве отдельного, чуть ли не центрального, элемента языка.
Скажите это разработчикам ядра андройда.
Скажите это разработчикам ядра андройда.Я, в принципе, со многими из них знаком — и они не испытывают никаких иллюзий. Они прекрасно понимают, что то, что они делают с точки зрения Android'а — это всего-навсего «мешок с драйверами».
Что совершенно не означает, конечно, что это — ерунда, без которой можно обойтись без этого «мешка с драйверами» железка работать не будет. Такая себе подвеска.
И тут, так же, как и везде: когда, в своё время, технологический прогресс позволил сделать надёжные шаровые шарниры — это перевернуло всю отрасль автомобилестроения! Но не сделало этим самые шарниры чем-то центральным в нём…
Чем по-вашему собственное АПИ для сервисов отличается от собственного языка для тех же сервисов?Собственно mail-online дал ответ на этот вопрос — вот тут: Обучение новых сотрудников сюда не ставлю, ибо это не так сложно на самом деле и разово.
Если вы делаете свой, специальный язык для какой-то ниши, то вы можете сделать его настолько простым, что людям, работающим на этом языке, можно будет платить меньше, чем тем, кто способен освоить «полноценный» язык и API к нему.
Это — действительно огромная ниша, вернее даже десятки, сотни ниш. Но все они «заперты». Ровно то, что даёт им право на существование не даёт языкам из этой ниши возможности выйти «на оперативный простор».
Чтобы дать пользователю управление любым элементом, все эти элементы уже должны быть созданы при помощи внутреннего языка. В общем надо сначала сделать платформу с движком языка, а потом на нем уже написать существующую систему управления проектами.
Просто доработать то что есть, вряд ли возможно.
Свой язык в платформе, это глобальная и очень сложная задача.
Вполне себе проглядывают ниши, где могут зародиться новые языки. Нужны для этого некие новые (но стабилизировавшиеся) условия, большая территория и незаселенность, так?
Вот к примеру незаселенная территория: GPU, TPU и разные перенастраиваемые массивы. Это было на периферии, а тут вдруг стало мэйнстримом, в кот. MSFT, Google, Amazon вкладывают сейчас немыслимые средства. Очень лакомая область. Так и просится, чтобы на ней появился язык для сборки логики на хардваре. Я в курсе, что подобные уже есть. Может быть один из них и стрельнет в нас.
Опять же территория Erlang. Вроде только сейчас она поспевает для массового заселения девелоперами. У Go почему-то не получилось. Надо разобраться, почему.
Еще просится на сцену метаязык, на котором можно собирать программы из любых других языков. Но это — типичная "интелектуальная штучка", которая никогда не приносит практич.результатов :(
А есть какой-нибудь пример успеха, что-то не получается нагуглить?
Не совсем бек, но на Go написан докер. А докер это сейчас практически стандарт де-факто для управления микросервисами (в том числе беками критичных сайтов) и вообще очень популярная технология.
Мажорное обновление Python 3, ломающее обратную совместимость, сформировалось в 2006 и называется Python 3000. Первый релиз вышел в 2008. Судя по тому что Python 2 бодр, весел, и все еще с нами, изначальные оценки по внедрению третьей версии к 3000 году были недалеки от истины.
Ради справедливости, и чтобы такого рода мысли не оседали в головах людей далёких от мира пайтона, следует заметить, что в 2017 начинать проект на python2 это моветон и крайне недальновидно. И как же приятно осознавать, что этого почти никто не делает.
Начнём с того, что «старые» языки программирования рождались, всё-таки, в академической среде. А это означает, что их появление всегда обуславливалось насущной необходимостью, а сами языки оказывались хорошо проработанными. С приходом персональных компьютеров, создание новых языков существенно упростилось, и никто не мешает создать любой новый (на вкус и цвет) язык программирования. Языки программирования так и создаются: под задачу, под оборудование или, даже, под целую предметную область. Никто не ставит задачу, сделать «большой» язык, который… что сдалает? Заменит все т.н. «нишевые» языки? А оно нам надо? Хорошо, Вы, предположим, «сделаете» такой «язык», а Вам скажут: «а зачем?»…
Далее, как только появляется какой-либо востребованный язык программирования, он начинает стремиться к некой универсальности, и, тогда, вопрос практического выбора между языками программирования может решаться уже исходя исключительно из эстетических соображений (синтаксис языка, используемая в нём модель памяти, и, если можно сказать, философия языка). Раз, различия (со временем) стираются, нет градиента, нет движения, нет развития, и никто не предложит ничего нового. Совершенно экстенсивный путь развития! Если к этому ещё добавить такой безумно больной вопрос, как следование стандартам, то о чём, вообще, можно говорить?
Современное состояние информационных технологий выглядит чрезвычайно пёстрым клубком множества локальных технологий, сред, систем и языков программирования. На каждый «чих» есть куча вариантов. Легко ошибиться с выбором. Очень часто, архитектурные решения рождаются и функционируют по принципу «так исторически сложилось», потому как никто и никогда не осуществляет никакого толкового сравнительного анализа, позволяющего сделать обоснованный выбор. Дело ещё упирается в низкую квалификацию разработчиков, которые могут (о, ужас!) не знать, например, о возможности написать «цепкий» SQL-запрос, предоставляющий то, что нужно, (ну, или, почти то, что нужно), и писать безумные «фреймворки» и создавать тонны «слоистых» абстракций (см. об этом более подробно в книге «Совтостроение изнутри» С. Тарасова), но язык программирования здесь оказывается совершенно ни при чём!
Кстати, о «фреймворках»! Сколько за последние 30 лет было создано всевозможных библиотек на всевозможных языках программирования! В статье (в столь короткой) соверешенно не учитывается этот фактор! А, ведь, библиотеки более подвержены старению и забвению, чем сами языки. Но сколько же на них было потрачено человеко-часов и сколько при помощи них было создано приложений. Даже, если, просто, ткнуть пальцем, то можно вспомнить, хотя бы, про линейку «Turbo Professional — Object Professional — Turbo Vision [Graphics Vision] — Object Windows — Visual Components Library», приведшую сегодня к новой библиотеке компонентов под названием «FireMonkey».
И еще. Автор пишет:
Для работы эволюционных принципов необходимы следующие механизмы: изменчивость, наследование признаков и естественный отбор.
А эти механизмы работают? Если бы они работали, то у нас был бы «другой мир», а не упорное наследование старого с сохранением обратной совместимости.
Изменчивость? Появление нового языка программирования всегда связано с необходимостью выявлять «паттерны поведения» и кодировать эти паттерны новыми именами (ключевыми словами). Если бы работала изменчивость, мы смогли бы придти уже к тому, что можно было бы назвать компонентным программированием, когда программы собираются из неких функциональных «кусков», обладающих замкнутым поведением, но обязательно предполагающим связь с другими компонентами.
Наследование? Очень часто появление нового языка происходит путём наследования синтаксиса языка-предшественника. В этом смысле, следует говорить о Си-подобных языках (восходящих к BCPL) и об Алголо-подобных языках, а эти ветки, как раз, никуда не деваются. В каждый конкретный момент времени используется конкретный язык программирования, причём, важно то, что всегда имеется в виду конкретная реализация (компилятор). Никто не программирует на Си-вообще, на Паскале-вообще. Вот почему, довольно мало смысла в утверждениях о смерти того или иного языка программирования.
Естественный отбор? К сожалению, в реальном мире действуют корпорации (с их навязчивым и вездесущим «маркетингом»), поэтому практическая ценность и историческая роль того или иного языка программирования, во многом, определяется вложениями и авторитетом продвигающей язык компании. Если бы языки и технологии побеждали бы благодаря исключительно своим качествам, то огромную роль должны были бы играть языки программирования, предлагающие ясные вычислительные концепции для реализации вычислений (генераторы в Питоне, списки в Лиспе, стек и связанные с ним связки рекурсивных функций в Форте, матрицы в MATLAB и т.д. и т.п.), и, вообще, всё то, что называется «функциональным программированием». (Очень хорошо, что на современном этапе, этот вид программирования постепенно отвоёвывает себе хорошее место под солнцем и возвращает платежом возложенные на них в прошлом надежды программистов предшествующих поколений.)
Когда появится следующий большой язык программирования с точки зрения Дарвина