Comments 93
Вам бы для начала сделать сайт про него. Написать какую-то документацию, примеры, только после этого можно как-то двигаться на его распротсранение. Жа и название, не простое ;)
а зачем?
Чтоб программы писать. Нет?
Нет
Этой статье существенно не хватает «киллер-примера».
Небольшого, но взятого из практики.
Так, чтобы сразу было понятно: «ух как гдесь просто, а я вот на своём c++ (python, haskell, ...) такие костыли для этого случая нагородил».
Без примера не проникся, присоединяюсь к VerTox («а зачем?»)
Небольшого, но взятого из практики.
Так, чтобы сразу было понятно: «ух как гдесь просто, а я вот на своём c++ (python, haskell, ...) такие костыли для этого случая нагородил».
Без примера не проникся, присоединяюсь к VerTox («а зачем?»)
На самом деле языки нужны и теоритически и практически. Очень хорошо, что например процесс компиляции идет в LLVM, значит что оптимизацией и компиляцией в native код, будут заниматься профессиональные отлаженные тулы.
То есть, тут есть ответ на вопрос, а как я буду компоновать программы с библиотеками и старым кодом, а что если я хочу Windows и другие очень важные для production вопросы.
Возвращаясь к вопросу, а зачем вообще язык нужен? Не секрет, что химия использует свой язык для, математика свой, причем для различных предметных областей свои закорючки и свои термины. Почему мы не должны совершенствоваться и пробовать новые языки? Мне к примеру язык понравился именно тем, что он не обычный. Не какой-то процедурный, когда бы мы сказали так это же «C», не C#/Java объектно-ориентированный, не Haskell с кучей синтаксического сахара и смежных идей. А такой как LISP простой и основанный на одной идее… А ведь во сколько языков перекочевала идея Функционального программирования и именно потому что она прозрачно реализовывалась в LISP. То есть простые чистые идейные! языки нужны, даже тот же brainfuck :) А вот комплексные языки, как F# или objective c (вместо smalltalk), это большой вопрос и обычно за этим стоят корпорации…
Правда, в статье действительно чего-то не хватает. Либо должна быть приведена, какая-то математическая теория (LISP — лямбда вычисления, Пролог — теория предикатов и резолюций), либо должны быть какие-то яркие иллюстрирующие примеры. А так получается недосказанность, для какой конкретной задачи он предназначен или какую математическую идею он иллюстрирует…
То есть, тут есть ответ на вопрос, а как я буду компоновать программы с библиотеками и старым кодом, а что если я хочу Windows и другие очень важные для production вопросы.
Возвращаясь к вопросу, а зачем вообще язык нужен? Не секрет, что химия использует свой язык для, математика свой, причем для различных предметных областей свои закорючки и свои термины. Почему мы не должны совершенствоваться и пробовать новые языки? Мне к примеру язык понравился именно тем, что он не обычный. Не какой-то процедурный, когда бы мы сказали так это же «C», не C#/Java объектно-ориентированный, не Haskell с кучей синтаксического сахара и смежных идей. А такой как LISP простой и основанный на одной идее… А ведь во сколько языков перекочевала идея Функционального программирования и именно потому что она прозрачно реализовывалась в LISP. То есть простые чистые идейные! языки нужны, даже тот же brainfuck :) А вот комплексные языки, как F# или objective c (вместо smalltalk), это большой вопрос и обычно за этим стоят корпорации…
Правда, в статье действительно чего-то не хватает. Либо должна быть приведена, какая-то математическая теория (LISP — лямбда вычисления, Пролог — теория предикатов и резолюций), либо должны быть какие-то яркие иллюстрирующие примеры. А так получается недосказанность, для какой конкретной задачи он предназначен или какую математическую идею он иллюстрирует…
Нет. «Чтобы программы писать» есть куча языков, и многие из них существенно понятнее.
«Привычнее» Вы хотели сказать. Чтобы решить понятнее или нет — нужно сначала попробовать понять.
Но вот те, кто спрашивает «зачем?» ответа не ожидают. Их всё и так устраивает. Так что ничего понимать они и не собираются. Зачем?
Но вот те, кто спрашивает «зачем?» ответа не ожидают. Их всё и так устраивает. Так что ничего понимать они и не собираются. Зачем?
Нет, я сказал именно то, что хотел сказать. (хорошая) программа на Boo читается действительно как английский текст. Программа на C# читается уже хуже, и поэтому там так активно развиваются Fluent-интерфейсы. А вот ваш язык не читается.
Чтобы не быть голословным. Вот C# (с Fluent-интерфейсом):
Вот Boo (для него даже подсветки на хабре нет):
А на o42a?
Кстати, это именно потому, что вы сделали «единую абстракцию» (уже всем успевшее надоесть everything is an object), забыв про то, что человек — и язык — оперируют не только объектами, но и действиями (а так же определениями и обстоятельствами, но это уже нюансы).
Чтобы не быть голословным. Вот C# (с Fluent-интерфейсом):
new FluentTask("warn if website is down")
.Every( TimeSpan.FromMinutes(3) )
.StartingFrom( DateTime.Now )
.When(() => new WebSite("http://example.org").IsNotResponding )
.Execute(() => Notify("admin@example.org", "server down!"))
.Schedule();
Вот Boo (для него даже подсветки на хабре нет):
task "warn if website is down":
every 3.Minutes()
starting now
when WebSite("http://example.org").IsNotResponding
then:
notify "admin@example.org", "server down!"
А на o42a?
Кстати, это именно потому, что вы сделали «единую абстракцию» (уже всем успевшее надоесть everything is an object), забыв про то, что человек — и язык — оперируют не только объектами, но и действиями (а так же определениями и обстоятельствами, но это уже нюансы).
В o42a есть фразы. С их помощью можно делать вполне читаемые выражения. Что-то вроде:
Можно изобразить и ещё более специфичный DSL.
Но синтаксис вторичен.Язык рассчитан не только на однократное «красивое» написание программы. Основной замысел посвящён процессу разработки, включающему рефакторинг например.
Про объекты в o42a вы не до конца поняли. Объект — это не только объект из ООП. Это и действие тоже. Так что это не то же, что обычно имеют ввиду под «всё есть объект», а на самом деле стыдливо умалчивают о множестве других сущностей. o42a в этом смысле идёт до конца. Зачем? Вот здесь я привёл пример.
Task "warn if website is down"
_every [3] minutes
_starting [date 'now']
_when [web site ["http://example.org"]: not responding] {
Notify "admin@example.org" with "Server down!"
}
_: schedule()
Можно изобразить и ещё более специфичный DSL.
Но синтаксис вторичен.Язык рассчитан не только на однократное «красивое» написание программы. Основной замысел посвящён процессу разработки, включающему рефакторинг например.
Про объекты в o42a вы не до конца поняли. Объект — это не только объект из ООП. Это и действие тоже. Так что это не то же, что обычно имеют ввиду под «всё есть объект», а на самом деле стыдливо умалчивают о множестве других сущностей. o42a в этом смысле идёт до конца. Зачем? Вот здесь я привёл пример.
Но синтаксис вторичен.Язык рассчитан не только на однократное «красивое» написание программы. Основной замысел посвящён процессу разработки, включающему рефакторинг например.
А должно быть наоборот. Синтаксис первичен, потому что читается программа намного чаще, чем пишется и/или рефакторится. Рефакторинг делается компьютером, а читается программа — человеком.
Про объекты в o42a вы не до конца поняли. Объект — это не только объект из ООП. Это и действие тоже. Так что это не то же, что обычно имеют ввиду под «всё есть объект», а на самом деле стыдливо умалчивают о множестве других сущностей. o42a в этом смысле идёт до конца.
Я, как раз, понял до конца. Именно поэтому я и говорю, что вы забыли, что (естественный) язык оперирует не только объектами.
Про пример под примером и отвечу.
Синтаксис вторичен. Это лишь форма, а важно содержание. Синтаксис лишь предоставляет к ней доступ и должен делать это хорошо.
Сколько-нибудь сложный рефакторинг может сделать только человек, а не компьютер.
Что касаемо частоты изменений — зависит от задачи. В сколько-нибудь сложном проекте изменения в уже написанном коде неизбежны. Это даже не рефакторинг. Это называется разработка.
И нет, Вы не поняли про объекты. Вы упорно воспринимаете «объект» как то, над чем производятся действия. Расширьте своё понимание. Замените термин «объект» на другой, подходящий как действиям так и, собственно, объектам.
Сколько-нибудь сложный рефакторинг может сделать только человек, а не компьютер.
Что касаемо частоты изменений — зависит от задачи. В сколько-нибудь сложном проекте изменения в уже написанном коде неизбежны. Это даже не рефакторинг. Это называется разработка.
И нет, Вы не поняли про объекты. Вы упорно воспринимаете «объект» как то, над чем производятся действия. Расширьте своё понимание. Замените термин «объект» на другой, подходящий как действиям так и, собственно, объектам.
Это лишь форма, а важно содержание.
Это до тех пор, пока форма не мешает получить доступ к содержанию.
Сколько-нибудь сложный рефакторинг может сделать только человек, а не компьютер.
Человек выбирает только что нужно сделать. Переименовать, инкапсулировать, переместить, реорганизовать. Выполняет эту операцию (в нормальных современных языках и IDE) — компьютер.
В сколько-нибудь сложном проекте изменения в уже написанном коде неизбежны.
Тем не менее, читается код чаще.
Вы упорно воспринимаете «объект» как то, над чем производятся действия. Расширьте своё понимание. Замените термин «объект» на другой, подходящий как действиям так и, собственно, объектам.
Потому что это нормальное понимание для естественного языка. В английском термином object вообще обозначается дополнение. Так что это не мне надо заменить термин, а вам, это у вас в языке выбрана неверная абстракция.
Это до тех пор, пока форма не мешает получить доступ к содержанию.
Верно. Разве я с этим спорю?
Человек выбирает только что нужно сделать. Переименовать, инкапсулировать, переместить, реорганизовать. Выполняет эту операцию (в нормальных современных языках и IDE) — компьютер.
Ох, какое же наивное понимание рефакторинга. Не думаю, что смогу Вас в чём-то убедить, пока вы не столкнётесь с реально тяжёлыми случаями.
Тем не менее, читается код чаще.
Ну, да. Хотя бы потому, что перед тем, как менять код, его нужно прочитать. Где я писал, что читать код — не важно?
Потому что это нормальное понимание для естественного языка.
Это — термин. Да, он не соответствует таковому из классического ООП, у которого также есть несоответствия с многообразным человеческим пониманием слова «объект».
Верно. Разве я с этим спорю?
Да; когда говорите, что синтаксис не важен.
Ох, какое же наивное понимание рефакторинга.
Нет, это цель. Я хочу, чтобы рефакторинг был таким.
Где я писал, что читать код — не важно?
Там, где пишете, что форма не важна, важно содержание.
Это — термин.
… введенный вами. Не ожидайте, что все остальные будут его понимать; особенно учитывая, что он противоречит понятию из естественного языка.
Да; когда говорите, что синтаксис не важен.
Я говорю, что он «вторичен», а не «не важен». Вот мои слова:
Синтаксис вторичен. Это лишь форма, а важно содержание. Синтаксис лишь предоставляет к ней доступ и должен делать это хорошо.
Нет, это цель. Я хочу, чтобы рефакторинг был таким.
То есть Вы никогда не хотите делать ошибок и решать проблемы одним махом? Нет уж, я Вашей страсти не разделяю. Я мыслю — значит я ошибаюсь. Ошибки и работа над ними — основа нашей профессии, а также основа человеческого мышления. Просто нужно уметь это делать. Не будьте роботом.
… введенный вами. Не ожидайте, что все остальные будут его понимать; особенно учитывая, что он противоречит понятию из естественного языка.
Любая новая предметная область требует терминов. И в качестве терминов, чаще всего, используются уже известные слова, но в несколько новом значении.
Объект — вообще универсальное слово. Применять его можно к чему угодно. Даже к алгоритму. Метапрограммирование, например, относится к алгоритмам как к объектам.
Я говорю, что он «вторичен», а не «не важен». Вот мои слова:
Вот и перечитайте слова. «это лишь форма, а важно содержание».
То есть Вы никогда не хотите делать ошибок и решать проблемы одним махом?
Нет. Я хочу, чтобы рефакторинг был тем, чем он должен быть по определению — структурной реорганизацией, не меняющей поведение.
И да, в моем высказывании не было ничего про «не делать ошибки». Если не делать ошибок, то рефакторинг не нужен.
Метапрограммирование, например, относится к алгоритмам как к объектам.
Рекомендую обратить внимание, что когда метапрограммирование относится к какому-то алгоритму как к объекту, это означает, что сейчас над этим алгоритмом будут производить какие-то действия, поэтому естественный смысл сохраняется. А вот собственные алгоритмы метапрограммы как объект не рассматриваются.
Я прочитал слова. Я вижу в них логику расстановки приоритетов. Я нигде не вижу пренебрежения синтаксисом. Прочтите цитату до конца, что-ли?
Ошибки разные бывают. Вы хотите совершать лишь определённые их виды и не хотите совершать другие, пусть и более серьёзные.
По поводу терминологии мы, видимо, не договоримся. Вы цепляетесь к словам, а приведённые примеры отказываетесь трактовать всего лишь как контр-примеры вашим постулатам, просто не желая смотреть на вещи шире.
Ошибки разные бывают. Вы хотите совершать лишь определённые их виды и не хотите совершать другие, пусть и более серьёзные.
По поводу терминологии мы, видимо, не договоримся. Вы цепляетесь к словам, а приведённые примеры отказываетесь трактовать всего лишь как контр-примеры вашим постулатам, просто не желая смотреть на вещи шире.
Ошибки разные бывают. Вы хотите совершать лишь определённые их виды и не хотите совершать другие, пусть и более серьёзные.
Приведите пример, что ли. Ваш пример с Extract Method to Method Object легко автоматизируется (хотя я и не уверен, что такой рефакторинг где-то есть. Про Extract Class from Parameters я даже не говорю, это вообще тривиально, и, если мне память не изменяет, есть в Resharper.
Вы цепляетесь к словам, а приведённые примеры отказываетесь трактовать всего лишь как контр-примеры вашим постулатам, просто не желая смотреть на вещи шире.
Просто пока ни один ваш пример не оказался достаточно общим. А частности, действительно, легко опровергаются.
BTW, цикл у вас тоже объект? А условное выражение?
Алгоритмы задаются предписаниями (statements) внутри объектов. Алгоритм — это составная часть объекта. Объект предоставляет доступ к этому алгоритму.
Можно сделать объект, который будет представлять из себя цикл. Только не вижу в этом особого смысла.
Можно сделать объект, который будет представлять из себя цикл. Только не вижу в этом особого смысла.
То есть какие-то управляющие конструкции у вас не объекты?
А как у вас записывается цикл? А условное выражение?
А как у вас записывается цикл? А условное выражение?
Это называется предложения. Если предложение заканчивается вопросительным знаком, то это условие выполнения следующим за ним предложения.
Пример условных выражений:
Любой императивный блок кода (в фигурных скобочках) можно сделать циклом. Цикл от одного до десяти:
Пример условных выражений:
Sign := > integer ( ~~ Функция арифметического знака.
Arg :=< integer ~~ Аргумент функции
Arg < 0? = -1 ~~ Если аргумент отрицателен - вернуть `-1'.
Arg > 0? = 1 ~~ Иначе, если аргумент положителен - вернуть `1`.
= 0 ~~ Иначе - вернуть `0`.
)
Любой императивный блок кода (в фигурных скобочках) можно сделать циклом. Цикл от одного до десяти:
I := ``1 ~~ Переменная - счётчик цикла.
{
Print [i] nl
I = i + 1
I <= 10? ...
}
So much for readability.
(я уж молчу про ваши смайлики в коде)
(я уж молчу про ваши смайлики в коде)
Не вижу, чем это хуже чем, например, C.
Хотите рафинированный DSL? Не проблема. Вот только если вы уже добрались до чтения реализации алгоритма (например, в поисках ошибки), то весьма спорно что DSL поможет, скрывая от вас её детали.
И уж лучше такие смайлики, чем раздражающие вездесущие
Хотите рафинированный DSL? Не проблема. Вот только если вы уже добрались до чтения реализации алгоритма (например, в поисках ошибки), то весьма спорно что DSL поможет, скрывая от вас её детали.
И уж лучше такие смайлики, чем раздражающие вездесущие
def, пыжащиеся поднять читаемость, а на самом деле воспринимаемые как всё те же значки. Но это только моё мнение.Не вижу, чем это хуже чем, например, C.
Ничем. Но C и не самый читаемый в мире язык.
Вот только если вы уже добрались до чтения реализации алгоритма (например, в поисках ошибки), то весьма спорно что DSL поможет, скрывая от вас её детали.
Это, очевидно, зависит от уровня реализации алгоритма. И если вы читаете прикладной алгоритм в терминах бизнеса, то DSL поможет.
> а библиотеки практически отсутствуют
> В ближайшие месяцы я планирую реализовать библиотеку коллекций, а также библиотеку ввода-вывода.
Сам где-то c 1992 одержим идеей своего языка и последние годы основательно окопался также в районе prototype-based (правда с большим уклоном на декларативность, DSLность и генеративность) поэтому в представленный продукте вижу скорее винигрет из различных идей, нежели целостную концепцию. Посему рискну поделиться своим опытом. Библиотеки — первичны. Они должны являться своего рода вдохновением и вызывать мурашки по телу, когда ты видишь, сколь изящно их удается реализовать, какую согласованную экосистему они образуют, дышащую в такт и т.п. Если язык создан сам в себе, то сколько бы слов не было о том, что в основе его лежит практический опыт (уверяю, у многих авторов мертворожденных языков были таки же аргументы), отсутствие библиотек говорит само за себя. Под вдохновением от удачного языка, поэзия коллеций, ввода-вывода и т.п. должна просто литься «из под пера». Если спустя годы их еще нет и требуются месяцы, то я позволю себе некоторый скепсис. Но и исключать успешности мероприятия не буду.
> В ближайшие месяцы я планирую реализовать библиотеку коллекций, а также библиотеку ввода-вывода.
Сам где-то c 1992 одержим идеей своего языка и последние годы основательно окопался также в районе prototype-based (правда с большим уклоном на декларативность, DSLность и генеративность) поэтому в представленный продукте вижу скорее винигрет из различных идей, нежели целостную концепцию. Посему рискну поделиться своим опытом. Библиотеки — первичны. Они должны являться своего рода вдохновением и вызывать мурашки по телу, когда ты видишь, сколь изящно их удается реализовать, какую согласованную экосистему они образуют, дышащую в такт и т.п. Если язык создан сам в себе, то сколько бы слов не было о том, что в основе его лежит практический опыт (уверяю, у многих авторов мертворожденных языков были таки же аргументы), отсутствие библиотек говорит само за себя. Под вдохновением от удачного языка, поэзия коллеций, ввода-вывода и т.п. должна просто литься «из под пера». Если спустя годы их еще нет и требуются месяцы, то я позволю себе некоторый скепсис. Но и исключать успешности мероприятия не буду.
Спасибо за мнение. Скепсис понятен. Тем не менее, я постараюсь его развеять просто продолжая работу.
В режиме «библиотека льётся из-под пера» работали Керниган и Ричи над языком Си. Они были так вдохновлены лаконичностью синтаксиса для задач работы с памятью, что куски стандартной библиотеки приводили в книгах, как произведения искусства:
void strcpy (char *s, char *t) {
while (*s++ = *t++) ;
}
Произведения искусства! Ну просто заглядение! Красота просто!
Свалить все все проверки на вызывающую сторону.
Конкретно приведенный код привел к целому классу уязвимостей «переполнение буфера».
Зато красиво!
Безусловно С великолепен, но приведенный пример — демонстрация скорее минуса, чем плюса.
Свалить все все проверки на вызывающую сторону.
Конкретно приведенный код привел к целому классу уязвимостей «переполнение буфера».
Зато красиво!
Безусловно С великолепен, но приведенный пример — демонстрация скорее минуса, чем плюса.
Код полностью соответствует спецификации, в нём нет ошибок.
По сравнению с тем, что было в те годы (Asm, Cobol, Fortran) действительно загляденье.
К переполнению буфера приводит невнимательность при работе с языками, которые не верифицируют все операции с памятью, а не особенности синтаксиса языка Си.
По сравнению с тем, что было в те годы (Asm, Cobol, Fortran) действительно загляденье.
К переполнению буфера приводит невнимательность при работе с языками, которые не верифицируют все операции с памятью, а не особенности синтаксиса языка Си.
Про синтаксис не было ни слова. Синтаксис С для своих целей близок к идеалу.
Я даже ни чего не имею против представления массива как указателя на первый элемент (с потерей информации о размере массива). Этот подход обоснован.
Но вот представление строки как указателя на первый элемент подобного массива char — вот это я считаю минусом. С легкой руки корифеев такой необоснованный подход привел к огромному количеству ошибок. И ладно ошибок — уязвимостей.
Такой способ работы со строками оправдан только когда требуется отыграть крохи производительности за счет увеличения вероятности допустить ошибку. Это меньшинство случаев. Но так как именно такой подход постулирован правильным он используется в большинстве случаев, что не оправдано.
Я даже ни чего не имею против представления массива как указателя на первый элемент (с потерей информации о размере массива). Этот подход обоснован.
Но вот представление строки как указателя на первый элемент подобного массива char — вот это я считаю минусом. С легкой руки корифеев такой необоснованный подход привел к огромному количеству ошибок. И ладно ошибок — уязвимостей.
Такой способ работы со строками оправдан только когда требуется отыграть крохи производительности за счет увеличения вероятности допустить ошибку. Это меньшинство случаев. Но так как именно такой подход постулирован правильным он используется в большинстве случаев, что не оправдано.
Это вам хорошо с высоты 2012 года говорить.
А представьте ситуацию 1969 года, когда большинство архитектур 8-битны.
Регистр общего назначения, куда можно удобно положить длину — 8 бит (или извращаться с половинками 16-битного регистра).
И, например в Z80 или 6502, один регистр, с кем можно делать арифметические операции (в т.ч. проверку на 0).
Лишние проверки в примитивных операциях очень существенно просадят производительность. Тогда было правильнее хорошо заранее всё продумать, минимизировав проверки, а не «Свалить все все проверки на вызываемую сторону»
А представьте ситуацию 1969 года, когда большинство архитектур 8-битны.
Регистр общего назначения, куда можно удобно положить длину — 8 бит (или извращаться с половинками 16-битного регистра).
И, например в Z80 или 6502, один регистр, с кем можно делать арифметические операции (в т.ч. проверку на 0).
Лишние проверки в примитивных операциях очень существенно просадят производительность. Тогда было правильнее хорошо заранее всё продумать, минимизировав проверки, а не «Свалить все все проверки на вызываемую сторону»
То есть, была дилемма: сделать как сделано, или передавать длину в байте (строки до 255 знаков) или передавать в регистре, соразмерном size_t (с тормозами на арифметике), или сделать две версии строк — короткие и длинные и думать, что вернёт конкатенация коротких строк, если на выходе появится длинная
Это вам хорошо с высоты 2012 года говорить.
Именно так.Тогда в 1969 этот подход мог иметь смысл.
Но сегодня, в 2012 году, лучше привести не этот пример, говоря о произведениях искусства в библиотеках С.
Ибо это не произведение искусства, а частное решение, пережившее свое время на несколько десятков лет.
Даже сейчас звучат отголоски такого подхода. Даже сейчас в книгах по программированию встречаются эти строки. Еще несколько лет назад я слышал от преподавателя в ПМ-ПУ этот пример как «произведение искусства», без оговорки о минусах такого подхода.
Этот пример — ложный идол. Он одурманивет молодых программистов, которые не видят сколь он плох здесь и сейчас.
Сейчас нужно делить код на высокоуровневую логику (написанную хоть на о42а) и производительные вставки Си/асм (если они нужны). В производительных вставках проверки невыгодно писать — это лучше делать в высокоуровневом коде, т.к. там больше языковых средств (exception-ы удобнее кидать, например). Так что пример годен для той области, где должен в настоящее время использоваться Си.
Тот же пример с сишной strcpy. Ну проверили на размер буфера, не влезает строка, и что? Исключений в Си нет. Молча проигнорировать переполнение — это большой фейл. Так или иначе, возможность нехватки буфера должна быть явно предусмотрена си-программистом, и на эти случаи ему всё равно писать ветки кода, независимо от того, проверяет strcpy буфер или нет.
Тот же пример с сишной strcpy. Ну проверили на размер буфера, не влезает строка, и что? Исключений в Си нет. Молча проигнорировать переполнение — это большой фейл. Так или иначе, возможность нехватки буфера должна быть явно предусмотрена си-программистом, и на эти случаи ему всё равно писать ветки кода, независимо от того, проверяет strcpy буфер или нет.
К ошибкам привел не код, а выбранная реализация строк.
Метамодели, компактная основа и близость к смысловым конструкциям человеческого мышления?) Более развернуто мыслями поделиться можете?
Полагаю, вопрос адресован мне?
В Вашем изложении это звучит как-то сложно. Для меня это просто термины, которых я не понимаю.
А вот пример того, что я понимаю.
Ведя разработку на Java, требуется выполнять рефакторинг. Как пример — нужно передать в метод больше параметров. А потом делать это снова. При этом набор параметров (или сам метод) в определённый момент превращается в отдельный класс, поскольку параметров становится слишком много. То есть моё изначальное решение сделать это именно методом было неверным по форме. Но неверным ли по существу? Ведь и метод, и класс — всего лишь языковые конструкции, которые в данном случае представляют одно и то же. Так зачем же мне вообще выбирать между «методам» или «классом», тратя время на выбор, а затем — на рефакторинг? Да только потому, что такова специфика языка.
И не надо говорить, мол, надо было всё продумать заранее. Кто так вообще разрабатывает? NASA?
В o42a такой проблемы нет. Есть сущность (или действие) — есть объект ей соответствующий. Форма всегда одна и та же, так что ошибок «по форме» больше нет (ну или их гораздо меньше).
В Вашем изложении это звучит как-то сложно. Для меня это просто термины, которых я не понимаю.
А вот пример того, что я понимаю.
Ведя разработку на Java, требуется выполнять рефакторинг. Как пример — нужно передать в метод больше параметров. А потом делать это снова. При этом набор параметров (или сам метод) в определённый момент превращается в отдельный класс, поскольку параметров становится слишком много. То есть моё изначальное решение сделать это именно методом было неверным по форме. Но неверным ли по существу? Ведь и метод, и класс — всего лишь языковые конструкции, которые в данном случае представляют одно и то же. Так зачем же мне вообще выбирать между «методам» или «классом», тратя время на выбор, а затем — на рефакторинг? Да только потому, что такова специфика языка.
И не надо говорить, мол, надо было всё продумать заранее. Кто так вообще разрабатывает? NASA?
В o42a такой проблемы нет. Есть сущность (или действие) — есть объект ей соответствующий. Форма всегда одна и та же, так что ошибок «по форме» больше нет (ну или их гораздо меньше).
Это надуманная проблема.
Метод выделяется в отдельный класс не тогда, когда параметров слишком много, а тогда, когда внутренняя логика (и машина состояний) метода слишком сложны, чтобы сохранять его в пределах одной структурной единицы.
И нет, класс и метод представляют не одно и то же, поэтому выбор между ними достаточно очевиден.
Метод выделяется в отдельный класс не тогда, когда параметров слишком много, а тогда, когда внутренняя логика (и машина состояний) метода слишком сложны, чтобы сохранять его в пределах одной структурной единицы.
И нет, класс и метод представляют не одно и то же, поэтому выбор между ними достаточно очевиден.
Рефакторинг — надуманная проблема? Эволюция ПО — надуманная проблема???
Что значит «логика слишком сложна»? Это не меняет того, для чего этот метод предназначен. И выбор способа реализации — это всего лишь детали реализации, обусловленные ограниченностью языка.
Что значит «логика слишком сложна»? Это не меняет того, для чего этот метод предназначен. И выбор способа реализации — это всего лишь детали реализации, обусловленные ограниченностью языка.
Конкретный приведенный вами пример — надуманная проблема. В ней нет ничего ни настолько частого, ни настолько сложного, чтобы изобретать ради этого отдельный язык, в котором не будет разделения на действия и сущности.
И что, мне теперь писать книгу по всем возможным применениям подхода? Можно же подумать над этим самостоятельно — нужно лишь желание познавать, а не отрицать новое.
Понимаете ли, в чем дело… в нашей индустрии так много «нового», что необходим bullshit-filter, позволяющий не тратить времени на то «новое», которое этого самого времени не стоит.
Вы, видимо, богатый человек, если у вас было три с половиной человекогода подряд на собственный язык. У меня таких ресурсов нет, и не будет. Пока что вы не продемонстрировали ничего, ради чего ваш язык стоило бы изучать (особенно учитывая, что он пока неработоспособен) или тем более развивать.
Вы, видимо, богатый человек, если у вас было три с половиной человекогода подряд на собственный язык. У меня таких ресурсов нет, и не будет. Пока что вы не продемонстрировали ничего, ради чего ваш язык стоило бы изучать (особенно учитывая, что он пока неработоспособен) или тем более развивать.
Касательно близости к модели нашей когнитивной деятельности — навряд ли смогу помочь. Я никогда не строил иллюзий, что смогу найти эдакий «эсперанто» для специалистов в различных предметных областях. Одни мыслят математическими формулами, другие — документарыми языками разметки, третьи — бизнес-кейсами и т.п. Для меня описание некоторой сложной визуальной модели в фотошопе со всякими слоями, пачками наложенными фильтрами, различным образом параметризованными — такая же программа как математическая числодробильня, но ее автор мыслит далеко не так, как это делают люди, для которых создан Matlab. Поэтому я больше исследовал в направлении DSL, динамических AST, которые могут модифицироваться в процессе трансляции и т.п. Метамодели и компактная основа меня вполне устраивали на стыке smalltak/self с lisp. Что-то вроде Io. Плюс ко всему, меня никогда не интересовало написание еще одного компилятора или интерпретатора. Их предостаточно. Меня интересовала трансляция в более широком смысле этого слова, которая может продуцировать артефакты самого различного типа. То есть, результатом «трансляции» программы для отдельно взятого проекта может быть код на Python для бэкенда, sql-скрипты для базы, html/css/js-код для фронтенда, проектная документация, пользовательская документация, отчеты о тестировании, шаблон письма с уведомлением о новом релизе и изменениях в нем и т.п.
Да-да-да.
Насчет когнитивных моделей — здесь, по моему, достаточно соображений, что мыслят люди связями и моделями, а не последовательностями (как в языках как таковых). В конце концов универсальной модели действительно может не быть, но почему бы не быть универсальной модели, которая бы описывала модели мышления?
Про Io читал, хотя и давно, был впечатлен… но в итоге пришел к мысли, что нужен вообще не язык, но некая довольно большая система — эдакая мега-ide, которая позволит интегрированно работать с раносмысловыми данными с нужным однообразием. Сложность такой системы меня испугала, из-за чего отложил все на далекое «потом».
Насчет когнитивных моделей — здесь, по моему, достаточно соображений, что мыслят люди связями и моделями, а не последовательностями (как в языках как таковых). В конце концов универсальной модели действительно может не быть, но почему бы не быть универсальной модели, которая бы описывала модели мышления?
Про Io читал, хотя и давно, был впечатлен… но в итоге пришел к мысли, что нужен вообще не язык, но некая довольно большая система — эдакая мега-ide, которая позволит интегрированно работать с раносмысловыми данными с нужным однообразием. Сложность такой системы меня испугала, из-за чего отложил все на далекое «потом».
Я так и не понял, какие задачи решает этот язык? Примеры бы хоть привели для сравнения.
В текущем состоянии никаких задач он не решает и решить не может. Я лишь поделился замыслом. Видимо, замысел не нашёл отклика.
Однозначно, всё было бы проще, если бы версия была 1.0, а не 0.2.4. Но, увы и ах, это пока не так.
Однозначно, всё было бы проще, если бы версия была 1.0, а не 0.2.4. Но, увы и ах, это пока не так.
Обычно, насколько я понимаю, сначала определяют задачу или категорию задач, которую должен решать язык. А уже после этого идет процесс создания языка.
А какую задачу или категорию задач решает Java? C++? C#? Ruby? Python?
Языки общего назначения не зря так называются.
Есть ещё нишевые языки, вроде PHP (по крайней мере в его первоначальном замысле) или Lua. Только для них и есть такая задача.
Языки общего назначения не зря так называются.
Есть ещё нишевые языки, вроде PHP (по крайней мере в его первоначальном замысле) или Lua. Только для них и есть такая задача.
Если у Вас язык общего назначения, то чем он лучше Java, C++, C#, Ruby, Python? Yet another programming language? Какие задачи он лучше решает? А если не лучше, то зачем тогда он вообще? То, что Вы пишите язык, это очень увлекательно и расширяет кругозор. Но все-таки мы говорим о «серьезности» языка, да еще какая-то монетизация была упомянута. Я не зря спросил про назначение языка, потому что синтаксис в том виде, в котором Вы его привели, кажется специализированным, правда непонятно на чем.
Ну, очевидно, что я считаю что он «лучше». А чем — я постарался объяснить в статье. Замыслом. Основой. Практическое же сравнение невозможно, поскольку должно базироваться на конкретных примерах использования. И простыми примерчиками тут не обойтись. Нужны, как минимум, библиотеки, которых нет. Так что как только спор переходит в практическую плоскость — я безоружен. Пока что.
Ясно. Я надеюсь, в скором времени будут и примеры и библиотеки, желаю Вам успехом в этом непростом деле. Хочу только сказать, что мне больше по душе Си-подобный синтаксис, его намного проще читать, чем, например, Ваш.
Не нужно иметь реализацию библиотек, чтобы показать мощь языка. Достаточно интерфейса.
Например, перегрузка операторов наглядно показывает как удобно становится работать с матрицами и векторами, для её демонстрации не обязательно в деталях расписывать операции сложения и умножения матриц.
Аналогично с контейнерами STL — не нужно показывать, как изнутри устроены хеши. Достаточно показать, что программист может соединить несколько абстракций (любой класс, любую хеш-функцию от объекта этого класса и обобщённый хеш-контейнер) в один объект.
Например, перегрузка операторов наглядно показывает как удобно становится работать с матрицами и векторами, для её демонстрации не обязательно в деталях расписывать операции сложения и умножения матриц.
Аналогично с контейнерами STL — не нужно показывать, как изнутри устроены хеши. Достаточно показать, что программист может соединить несколько абстракций (любой класс, любую хеш-функцию от объекта этого класса и обобщённый хеш-контейнер) в один объект.
Вы бы просто привели примеры из головы… Ваш язык не преднаначен для решения алгоритмических задач или для чудес метапрограммирования (хотя кто знает). Ваш язык можно так сказать решает архитектурные проблемы…
Например, паттерн singleton у вас в кармане, так как у вас все объекты, а не классы. Эта проблема не надумана в ООП, так как все больше вокруг singleton Сервисы, Factory (отсюда и возник spring).
Например, паттерн singleton у вас в кармане, так как у вас все объекты, а не классы. Эта проблема не надумана в ООП, так как все больше вокруг singleton Сервисы, Factory (отсюда и возник spring).
Как-то пугают статьи о программировании начинающиеся со слов «Я не люблю программировать». Зачем тогда вы занимаетесь программированием? :)
Так и знал, что такой вопрос возникнет.
Вы неправильно расставили акценты. Задумайтесь: «Я не люблю программировать» не означает, что я испытываю к процессу программированию хоть какое-то неприятие. Это лишь означает, что «любви» к нему я не испытываю. Это труд. А к своему труду нужно относиться с должным уважением, иначе нужно менять сферу деятельности.
Теперь касаемо «любви». Когда-то я «любил» программировать. Мне доставлял удовольствие процесс сам по себе. Вернее сказать, удовольствие мне доставлял процесс познания. С каждым днём я учился делать новые вещи, о которых не знал, или которых не умел раньше. Это будоражило, вдохновляло. Но со временем — перестало. Процесс познания нового стал само собой разумеющей частью работы. Зато куда большее вдохновление я начал испытывать видя её результат.
Так что перефразирую: мне интереснее создавать, чем познавать. (Опять же, чтобы не быть неправильно понятым: мне нравится познавать!)
Вы неправильно расставили акценты. Задумайтесь: «Я не люблю программировать» не означает, что я испытываю к процессу программированию хоть какое-то неприятие. Это лишь означает, что «любви» к нему я не испытываю. Это труд. А к своему труду нужно относиться с должным уважением, иначе нужно менять сферу деятельности.
Теперь касаемо «любви». Когда-то я «любил» программировать. Мне доставлял удовольствие процесс сам по себе. Вернее сказать, удовольствие мне доставлял процесс познания. С каждым днём я учился делать новые вещи, о которых не знал, или которых не умел раньше. Это будоражило, вдохновляло. Но со временем — перестало. Процесс познания нового стал само собой разумеющей частью работы. Зато куда большее вдохновление я начал испытывать видя её результат.
Так что перефразирую: мне интереснее создавать, чем познавать. (Опять же, чтобы не быть неправильно понятым: мне нравится познавать!)
> Я не люблю программировать.
Php также начинался.
Php также начинался.
— Современные языки программирования мешают излагать мысли
— Имена в o42a регистронезависимы
Очень спорно
а в именах по бокам могут быть пробелы?
— Имена в o42a регистронезависимы
Очень спорно
а в именах по бокам могут быть пробелы?
Вспомнил статью в тему
Не уловил проблематики, но поставил «плюсик» за усердия.
Во-первых, респект за то, что это не просто придумали новый язык, но и реально пытаетесь сделать компилятор.
Во-вторых, языки программирования — это моя любимая тема, не пропускаю мимо ни одного нового языка, сам разрабатываю свой язык (хотя сейчас это скорее работа по сравнению многочисленных фич существующих языков, систематизации и попытки продумать архитектуру «идеального» языка, включающего как можно больше возможностей).
По сути — многого не понял, с тем что понял — не согласен:) Вы как-то очень резко порвали с традиционной архитектурой языков программирования… одни пробелы и дефисы в идентифиакторах чего стоят. Вы пишете «лучший синтаксис придуманный человечеством — это письменная речь» — позволю с вами не согласиться. Письменная речь — это нечто, наименее приспособленное для программирования (как и для многих других прикладных задач). В математике, физике и химии есть формулы, в инженерном деле — чертежи и схемы, а человеческая речь используется как средство комментирования (собственно, как и в программировании). Всякие попытки протащить естественный синтаксис в программирование — это бейсикописательство в чистом виде под лозунгами «программирование для домохозяек». Оно нам надо? Я считаю — не надо. Это не значит, что программирование должно быть сложным (и тем более это не значит, что его следует искусственно делать сложным). Программирование должно быть простым и логичным для профессионалов. Не стоит заботиться о новичках — пусть порог вхождения будет высокий, это даже хорошо. Но те, кто таки вошел — должны испытывать только восхищение от продуманности и гениальности тех языков, которыми они пользуются.
Ну и то что уже отмечали — хочется видеть развернутый пример и сравнение с реализациями на других языках, с пояснением «почему на вашем языке это лучше».
Во-вторых, языки программирования — это моя любимая тема, не пропускаю мимо ни одного нового языка, сам разрабатываю свой язык (хотя сейчас это скорее работа по сравнению многочисленных фич существующих языков, систематизации и попытки продумать архитектуру «идеального» языка, включающего как можно больше возможностей).
По сути — многого не понял, с тем что понял — не согласен:) Вы как-то очень резко порвали с традиционной архитектурой языков программирования… одни пробелы и дефисы в идентифиакторах чего стоят. Вы пишете «лучший синтаксис придуманный человечеством — это письменная речь» — позволю с вами не согласиться. Письменная речь — это нечто, наименее приспособленное для программирования (как и для многих других прикладных задач). В математике, физике и химии есть формулы, в инженерном деле — чертежи и схемы, а человеческая речь используется как средство комментирования (собственно, как и в программировании). Всякие попытки протащить естественный синтаксис в программирование — это бейсикописательство в чистом виде под лозунгами «программирование для домохозяек». Оно нам надо? Я считаю — не надо. Это не значит, что программирование должно быть сложным (и тем более это не значит, что его следует искусственно делать сложным). Программирование должно быть простым и логичным для профессионалов. Не стоит заботиться о новичках — пусть порог вхождения будет высокий, это даже хорошо. Но те, кто таки вошел — должны испытывать только восхищение от продуманности и гениальности тех языков, которыми они пользуются.
Ну и то что уже отмечали — хочется видеть развернутый пример и сравнение с реализациями на других языках, с пояснением «почему на вашем языке это лучше».
Не согласен.
Научные дисциплины оперируют формальными моделями, это так. Но эти модели не обладают возможностями собственного объяснения. Они замкнуты в себе. Так что письменная речь, например, в математическом доказательстве, — это не комментарии, а изложение фактов формальной модели на человеческом языке.
Что до программирования, то здесь общепринятая формальная модель отсутствует. У каждой программы она если и есть — то своя собственная. Так что программа — это объяснение сути в ней происходящего. Программа должна быть понятна читающему. Её не нужно разгадывать как головоломку. Те же, кто этому принципу не следует — поступают по-свински по отношению к товарищам по команде. Это заставляет их тратить больше времени на изучение такого кода. И это просто подло, поскольку выставляет их неэффективными разработчиками, хотя вина — на авторе такого «кода».
Научные дисциплины оперируют формальными моделями, это так. Но эти модели не обладают возможностями собственного объяснения. Они замкнуты в себе. Так что письменная речь, например, в математическом доказательстве, — это не комментарии, а изложение фактов формальной модели на человеческом языке.
Что до программирования, то здесь общепринятая формальная модель отсутствует. У каждой программы она если и есть — то своя собственная. Так что программа — это объяснение сути в ней происходящего. Программа должна быть понятна читающему. Её не нужно разгадывать как головоломку. Те же, кто этому принципу не следует — поступают по-свински по отношению к товарищам по команде. Это заставляет их тратить больше времени на изучение такого кода. И это просто подло, поскольку выставляет их неэффективными разработчиками, хотя вина — на авторе такого «кода».
Программа должна быть понятна читающему, и это достигается более строгой формализацией и «универсализацией» синтаксиса, никак не приближением его к человеческому языку. Приведу вам пример: в Си «имя массива это указатель на первый элемент массива», Может быть когда-то это было удобно, но это нарушает логику языка: почему тогда имя структурной переменной — не указатель на первый элемент структуры?
Еще была такая тема, что переменная без указания типа была по умолчанию int. Тоже нелогичность, хорошо что в С++ это сразу выпилили.
Далее: в С++ классы могут быть вложенными в другие классы; классы могут быть вложенными в функции, функции могут быть вложенными в классы (собственно методы классов), но функции не могут быть вложенными в функции! Вот пример нелогичности. Да, сдедали лямбды, но это лямбды а не вложенные функции, нелогичность все равно осталась.
Аналогично с пространствами имен. Они не могут быть вложенными никуда, кроме как в другие пространства имен. А в некоторых случаях было бы удобно сделать пространства имен внутри классов (вспомните огромные «оконные „классы в разных библиотеках — CWnd, QWidget и т.д.). Ну и так далее. Проблема всех существующих языков в том, что в них многие фичи существуют как-бы по отдельности, синтаксис неуниверсален (нередко в угоду “читаемости»), нередко тянутся какие-то legacy вещи из глубины веков (ужасные #include в С/С++, от которых нужно было бы избавиться прежде чем сочинять лямбды и метапрограммирование) и т.д.
При универсальном подходе те же шаблоны С++, на которых в boost наворотили такого, что в кошмарном сне не приснится, можно было бы сделать куда проще: разрешите передавать в шаблоны ЛЮБЫЕ объекты времени компиляции, а не только типы и константы. Например, блоки кода. И сделайте синтаксические макросы. Все, навороты никому не будут нужны, все станет просто и понятно.
Еще была такая тема, что переменная без указания типа была по умолчанию int. Тоже нелогичность, хорошо что в С++ это сразу выпилили.
Далее: в С++ классы могут быть вложенными в другие классы; классы могут быть вложенными в функции, функции могут быть вложенными в классы (собственно методы классов), но функции не могут быть вложенными в функции! Вот пример нелогичности. Да, сдедали лямбды, но это лямбды а не вложенные функции, нелогичность все равно осталась.
Аналогично с пространствами имен. Они не могут быть вложенными никуда, кроме как в другие пространства имен. А в некоторых случаях было бы удобно сделать пространства имен внутри классов (вспомните огромные «оконные „классы в разных библиотеках — CWnd, QWidget и т.д.). Ну и так далее. Проблема всех существующих языков в том, что в них многие фичи существуют как-бы по отдельности, синтаксис неуниверсален (нередко в угоду “читаемости»), нередко тянутся какие-то legacy вещи из глубины веков (ужасные #include в С/С++, от которых нужно было бы избавиться прежде чем сочинять лямбды и метапрограммирование) и т.д.
При универсальном подходе те же шаблоны С++, на которых в boost наворотили такого, что в кошмарном сне не приснится, можно было бы сделать куда проще: разрешите передавать в шаблоны ЛЮБЫЕ объекты времени компиляции, а не только типы и константы. Например, блоки кода. И сделайте синтаксические макросы. Все, навороты никому не будут нужны, все станет просто и понятно.
Программа должна быть понятна читающему, и это достигается более строгой формализацией и «универсализацией» синтаксиса…
Так чем же плох выбор (псевдо-) человеческого языка для такой «универсализации»? Посмотрите рекомендации по само-документированному коду. Разве предложение выделять код в функции с говорящими названиями не есть попытка приближения кода к человеческому языку?
Тем что программирование — это не человеческое общение. Это нечто совершенно особое, с уже выработанными за десятилетия правилами и внутренней логикой. У людей, имеющих отношение к программированию, эта логика уже сидит в подсознании. Например, зная C/С++, можно легко читать программу на C#, Java, JavaScript, ObjectiveC, D, PHP, Perl и т.д. Это и священное правило «идентификатор — это последовательность букв, цифр и символов подчеркивания, начинающаяся с буквы или символа подчеркивания», и синтаксис блочных и однострочных комментариев, и операции ++, --, += и т.д., и общепринятые ключевые слова if, else, for, и имена базовых типов, и фигурные скобки в качестве операторных… да и вообще иерархическая структура программы (также как в XML/HTML — понятие тегов и угловые скобки). Это стандарт де-факто, и в целом, надо сказать, весьма неплохой. Это все уже в крови, на таком же уровне как у физиков — определенные буквы для обозначения физических величин, а у математиков — символы корней, производных и интегралов. Зачем нам вместо этого «человеческий язык»?
Появляются новые парадигмы, новые возможности, совершенствуются старые — но базовый синтаксис остается, он всем понятен, он удобен для изучения новых возможностей… он возник не просто так, а в результате жесткого естественного отбора и огромной практики. Зачем от этого отказываться?
Появляются новые парадигмы, новые возможности, совершенствуются старые — но базовый синтаксис остается, он всем понятен, он удобен для изучения новых возможностей… он возник не просто так, а в результате жесткого естественного отбора и огромной практики. Зачем от этого отказываться?
Не верю я в естественный отбор языков программирования. Напротив, отбор носит совершенно неестественный характер. Языки навязываются корпорациями и учебными заведениями. То, что C-подобный синтаксис — это широко распространённый стандарт спорить не буду. С тем, что он хорош настолько, что не надо и пытаться что-то менять — не соглашусь. По мне так он носит все признаки «тяп-ляп, чтобы было». Это просто временное решение, которое стало постоянным.
И да, главное. Программирование — это всё-таки общение. Да, профессиональное. Но то, что ему нечего почерпнуть из естественной речи — совершеннейшая неправда.
И да, главное. Программирование — это всё-таки общение. Да, профессиональное. Но то, что ему нечего почерпнуть из естественной речи — совершеннейшая неправда.
Убогость псевдочеловеских языков просвечивает своим «псевдо».
Дело в том, что существующие ЯП по иерархии Хомского — контекстно-свободные (т.е., описываемые БНФ-нотацией). В этих условиях, запись, похожая на естественную, только мешает сосредоточиться на конструкциях языка, описанных в его грамматике.
Например,
while (cond) statement;
сразу настраивает программиста чётко разграничить блоки cond и statement.
Если позволять вольности типа
«Цикл 10 раз и пока x > 0», то всё равно весь этот синтаксический сахар будет заперт в рамки БНФ-грамматики. Как только появится конструкция, не предусмотренная сахаром-грамматикой, типа
«Цикл пока x > 0 но не более 10 раз», программист будет ломать голову, как же ему переписать предложение, чтобы оно соответствовало грамматике. А это неповзолительные трудозатраты.
Т.е. всё равно естественного языка не получается. Если вы поднимете синтаксис по иерархии Хомского выше БНФ, то вперёд!
зы. лол, Хомский в корейском клипе недавно снялся )) -> www.youtube.com/watch?v=lJtHNEDnrnY&feature=player_detailpage#t=200s
Дело в том, что существующие ЯП по иерархии Хомского — контекстно-свободные (т.е., описываемые БНФ-нотацией). В этих условиях, запись, похожая на естественную, только мешает сосредоточиться на конструкциях языка, описанных в его грамматике.
Например,
while (cond) statement;
сразу настраивает программиста чётко разграничить блоки cond и statement.
Если позволять вольности типа
«Цикл 10 раз и пока x > 0», то всё равно весь этот синтаксический сахар будет заперт в рамки БНФ-грамматики. Как только появится конструкция, не предусмотренная сахаром-грамматикой, типа
«Цикл пока x > 0 но не более 10 раз», программист будет ломать голову, как же ему переписать предложение, чтобы оно соответствовало грамматике. А это неповзолительные трудозатраты.
Т.е. всё равно естественного языка не получается. Если вы поднимете синтаксис по иерархии Хомского выше БНФ, то вперёд!
зы. лол, Хомский в корейском клипе недавно снялся )) -> www.youtube.com/watch?v=lJtHNEDnrnY&feature=player_detailpage#t=200s
Перестаньте показывать новые языки программирования на тупых математических задачах. Покажите практический пример. Например, как выглядит простенький статический веб-сервер (принять соединение, открыть, прочитать и отдать файл).
А когда описание языка начинается с «а вот это у нас блочный комментарий, а вот знак равно», то это 60ые годы. Тогда да, было круто. И называлось это «программирующие программы», в том смысле, что они брали текст, а на выходе делали программу. Но сейчас не 60ые, и даже не 80ые.
А когда описание языка начинается с «а вот это у нас блочный комментарий, а вот знак равно», то это 60ые годы. Тогда да, было круто. И называлось это «программирующие программы», в том смысле, что они брали текст, а на выходе делали программу. Но сейчас не 60ые, и даже не 80ые.
Потребительский подход? Да, очень современно.
Этой статьёй я хотел дать пищу для размышления, а не готовые решения.
Этой статьёй я хотел дать пищу для размышления, а не готовые решения.
Не потребительский, а содержательный. Потому что описывать язык можно либо с лингвистических позиций (LR, тьюринг-полный, с поддержкой того, сего, и еще того), либо с экспрессивных — т.е. показывая реальные примеры. «здравствуй, избитый пример» к таковым не относится.
Это статья о разрабатываемом языке, в котором применены новые идеи. Это не реклама продукта, готового к применению.
Я описал основные принципы, семантику языка, эти самые новые идеи, побуждая вас взглянуть на программирование по-новому. А синтаксис вторичен. Описание его основ я привёл лишь для того, чтобы примеры, иллюстирующие конкретные функции, были понятны.
Я описал основные принципы, семантику языка, эти самые новые идеи, побуждая вас взглянуть на программирование по-новому. А синтаксис вторичен. Описание его основ я привёл лишь для того, чтобы примеры, иллюстирующие конкретные функции, были понятны.
Занятно, я пока искал (упомянутый выше) пример кода на Boo, заметил, что Айенде Райен, автор DSLs in Boo, с вами, похоже, солидарен.
Во-первых, сразу после Hello, World он приводит «более сложный пример», и это — веб-сервер.
А во-вторых, описывая пользовательские руководства для DSL, он настоятельно рекомендует начинать с реальных примеров.
Ну и цитата на закуску:
Во-первых, сразу после Hello, World он приводит «более сложный пример», и это — веб-сервер.
Если любопытно
import System.Net
import System.IO
if argv.Length != 2:
print "You must pass [prefix] [path] as parameters"
return
prefix = argv[0]
path = argv[1]
if not Directory.Exists(path):
print "Could not find ${path}"
return
listener = HttpListener()
listener.Prefixes.Add(prefix)
listener.Start()
while true:
context = listener.GetContext()
file = Path.GetFileName(context.Request.RawUrl)
fullPath = Path.Combine(path, file)
if File.Exists(fullPath):
context.Response.AddHeader("Content-Disposition", "attachment; filename=${file}")
bytes = File.ReadAllBytes(fullPath)
context.Response.OutputStream.Write(bytes, 0, bytes.Length)
context.Response.OutputStream.Flush()
context.Response.Close()
else:
context.Response.StatusCode = 404
context.Response.Close()
А во-вторых, описывая пользовательские руководства для DSL, он настоятельно рекомендует начинать с реальных примеров.
Ну и цитата на закуску:
I can’t emphasize enough the importance of making a good first impression with your DSL. It can literally make or break your project. You need to make a real effort to ensure that the user’s first impression of your system will be positive.
Я вот посмотрел пример.
И, вот, в упор не понимаю чем этот язык отличается от любого другого языка. И зачем его развивать, и вкладывать в него силы.
И, вот, в упор не понимаю чем этот язык отличается от любого другого языка. И зачем его развивать, и вкладывать в него силы.
А можно назвать это DSL.
Простите, что можно назвать DSL?
Вторая идея o42a — это возможность разделения языковой семантики и синтаксиса. Синтаксис не обязан один-в-один соответствовать языковым сущностям, сколь бы универсальны они ни были. Синтаксис должен выражать семантику программы, а не языка программирования. Он должен быть удобен для восприятия и достаточно строг. Это задача компилятора, а не программиста, приводить текст программы к языковым сущностям.
Можно сопоставить синтаксис с представлением, а программные сущности — с моделью из парадигмы MVC. А можно назвать это DSL.
Как понятнее изложить?
Как идёт разработка?
Sign up to leave a comment.
Язык программирования o42a