Pull to refresh
11
0
Андрей Курдюмов @kant2002

Программист

Send message

но, то что вы описываете это еще один ЯП

Для меня это выглядит как градация "языков" с очень не четкими границами. Даже сами "контролируемые естественные языки" деляются на две группы, Одна это языки которые программно верифицируемы, и вторые это языки нацеленные на снижение ошибок у людей. Т.е. выглдит что "контролируемые естественные языки" это пока еще не удавшаяся попытка найти в какой момент "формальный язык" становится "естественным языком".

Не думаю, что понятность алгоритма измениться от языка на котором он написан.

В целом да. У меня просто есть надежда, что подобные эксперименты помогут найти педагогические методики которые будут помогать писать более "понятные" алгоритмы, или просто оценить что есть более понятно. Но это так, фантазии конечно.

Естественный язык появился как способ записывать звук. Даже если мы его формализуем то в нум останется легаси вот этой последовательной одномерности.

Пожалуй да, но сейчас кажется что чтение попало в свой отдельный кусок мозга. Насколько он близок программированию, хз. Ну и если мы формализуем, то это будет прорыв в лингвистике насколько я знаю.

Имхо плюс может быть только в пороге входа. А минус - эта последовательная одномерность (конечно есть костыли в виде всякого форматирования, но все равно если порог входа и так большой - как в математике - то лучше уж переориентировать систему обозначений на визуальную).

Да, я согласен и с плюсом и с минусом. Но было бы хорошо получить на руки тушканчика, и посмотреть где он сломался. Пока я так понимаю его нет.

Возможно так же сама похожесть на естестенный язык будет не только помогать но и мешать.

Очень вероятно.

Я думаю, именно поэтому даже для обычных слов в науке вводят какие-то специальные термины

Да, это тоже проблема. Но выглядит так что мы как отрасль справляемся как-то с этим. Всякие контроллеры, энтити, медиаторы(посредники) и так далее, это пример введения новых слов в том числе и в "код". Выглядит что это естественный процесс и его можно будет применить и в "языке".

А чем эти языки отличаются от ЯП? В них просто больше слов, правил и ограничений!

Я исхожу из предположений что именно ЯП обладают более строгим набором органичений. В то время как естественные языки наоборот более всеядны. Контролирумые естественные языки с моей точки зрения могут обладать следующим интересным свойством - они лучше будут "читаться", и это само по себе может сделать алгоритмы и процессы более прозрачными. "читабельность" никак не улучшить "писабельность" и мучаться очевидно с этим прийдется.

Проблема программирования не в количестве слов, а в умении составить алгоритм решения задачи.

Это известный факт. Но кроме написания кода, сейчас остро стоит вопрос, тренировки новых сотрудников в понимании того что написано, или прозрачности ключевых программ для общественности. Что если "сухой и формальный язык" облегчит жизнь не программистам, а всем сопутствующим профессиям? Сереьезно обсуждать "улучшения" процесса я не могу, так как непонятно что за фрукт будет этот "язык", если он будет.

И, скорее всего, один алгоритм будет сформулирован одними и теми же словами и их синонимами. Не думаю, что количество слов упростить составление алгоритма, скорее наоборот!

Думаю мы и сейчас как программисты дублируем алгоритмы и шаблоны в большом количестве. Потому что как и в жизни нужно "так же как тут, но чуток по другому".

Программисту надо будет выучить значения всех слов, или же программировать как на Паскале, некоторым ограниченным набором слов.

Для меня это не очевидно. Когда мы говорим про языки программирования в современном понимании, то если я не ошибаюсь, они состоят из

  1. вспомогательной среды исполнения для компилятора, помогающей ему писать код

  2. базовой библиотеки функций/классов

  3. экосистемы общеизвестных библиотек для данного языка

  4. И еще в приложении у вас может быть свой DSL в виде бизнес-логики.

Все это достиглось годами работы в данном направлении. Если даже сейчас придумать "язык", то врядли он покроет что-то кроме пунктов 1 и 2. Это будет не честное сравнение как мне кажется. И да, если даже "язык" возможен, то он выглядит затратным предприятием.

Также сейчас очень много кода который просто служит склейкой для разных слоев, вдруг там бы подобный простой вариант "языка" применился бы. При условии что это не калька с языка программирования разумеется.

Всем мои придирки также основаны на том, что было бы не плохо опиратсья на конкретный пример "естественного языка программирования" который был хреновым, и были понятные проблемы. Сейчас обсуждается сферический конь в вакууме. Разумеется то что "предки" не смогли сделать этот язык, хоть и сильно старались, это аргумент в пользу того что попытки тщетны, но это не гаранированный аргумент, учитывая сколько путей даже не рассматривалось.

Да, конечно это будет не обычная повседневная разговорная речь. Именно потому я привожу примеры контролируемых естественных языков. Они "выглядят" как естественный язык, одновременно с этим они могут быть проверены на соответствие грамматике.

В первую очередь это не должно быть просто калька с текущих языков программирования, иначе это действительно есть пример Паскаля и продолжения. В вышеупомянутом ACE проблема с неоднозначным использованием И и ИЛИ решается ограничениями на шаблоны использования фраз.

The screen blinks and John waits.
The screen blinks or John waits.
The screen blinks or John waits, and Mary enters a card.

Небольшое отступление почему мне любопытно это направление.
Вот пример статьи 1964г. где говорится про то что "отрицание" и пассивная форма имеют задержки при обработке читаемого текста и предположительно активная утвердительная форма является основным механизмом мышления, и пассивная форма и форма отрицания являются дополнительными процессами которые выполняются последовательно и независимо. В практике как мне кажеся это выливается в следующие эвристики.

Мне это дает почву спекулировать о том что "языки программирования" и конструкции в них основаны на некоих особенностях психики и возможно исследования в данном направлении помогут улучшить эргономику языков программирования.

Было бы круто, если бы кто-то из психолингвистов прокомментировал актуальность данной статьи, и что нового есть в данном вопросе.

Я с всеми тезисами согласен. Я могу высказывать свои оговорки, но они не меняют картину того что

  • Для программирования требуется дициплина.

  • Для дисциплины нужен свой язык.

  • Каждая домохозяйка не может писать программы

Одновременно с этим, в ходе подобных дискуссий я не вижу ответов на вопросы

  • Можно ли придумать контролируемый естественный язык который был бы пригоден как для программирования, так и для чтения?

  • Каковы механизмы которые делают один социолект языка более формальным чем другой? Но это конечно уведет нас в дебри лингвистики и я так понимаю мы как общество даже близко не можем этими понятиями оперрировать.

  • Почему не учитывается изменившаяся демография программистов? Сейчас намного более широкий спектр людей прграммируют, и может быть этой демографии лучше будут другие вещи, чем те которые были полезны первоначальной демографии?

Наверное у меня вопросов побольше будет, просто мне их тяжело артикулировать пока связно.

А какие причины отказаться от естественного языка были описанного в https://habr.com/ru/post/531400/ ? сложность распознавать языковые конструкции? Получилось хоть какую то идею в виде кода или спецификации оформить?

Потому что это по факту это оказывается ненужным

Мы сейчас обсуждаем насколько я знаю сугубо исследовательские вещи, которые еще и крайне нишевые.Я сходу вспомню только китайский язык который недавно был в новостях. Я китайский не знаю, потому судить о сложности не могу и попробовать тоже не могу.

Не соглашусь что не нужно. Социальный запрос судя по всему огромный. Copilot не просто так шороху навел. Людям нравится эта идея, они хотят ее. Если конечно это сейчас не рабочая схема, это уже другой вопрос. Такого же ажиотажа от Haskell я не видел.

Использование естественного языка вынужденно ограничивает пользователей только носителями данного языка с относительно сложной грамматикой. 

я и не пытался сказать что весь язык можно использовать. Это действительно выглядит тупиковым направлением. Но контролируемые языки, где есть как раз упрощенная грамматика, есть. И они применяюся, но только в крупных компаниях, например для масштабирования усилий по автоматическому переводу. Для меня это говорит что технические писатели осилили и как раз основные усилия по тому чтобы наоборот упростить грамматику и сделать ее максимально широко доступной.

И выгода от такого использования отсутствует.

Да, конечно сейчас отсутсвует. Но также стоит оговориться что у нас даже игрушечных пседо-промышленных примеров раз два и обчелся. Академики показывают идею, и до того чтобы она была выгодной еще шагать и шагать. Серьезные работы и деньги в НИОКР в данном направлении насколько я понимаю велись в районе 60х-70х, а потом все бабки рубили на том что уже работало и реинвестировали в существующие технологии.

Я бы хотел конечно посмотреть на попытки сделать именно полноценный язык на основании английского/русского, что получилось, и почему не взлетело.

Есть ли Гитхаб вашего проекта? Посмотреть или покритиковать, или помочь :) любопытно однозначно

Я бы немного покритиковал беапелляционую позицию статьи.

Да, формальные определения алгоритмов нужны, но предположение, что формальным может быть язык только со спец-символами, я бы рассматривал как гипотезу, которая имеет большое эмпирическое подтверждение.

Сразу оговорюсь, даже если будет техническое демо, подтверждающее обратное, и можно будет писать на английском языке программы, то экономические причины переписать все что есть на "английский" не появятся. Никто не будет выбрасвать колоссальные инвестиции. Но это практический аспект, а я бы хотел обсудить для начала только теоретический.

Второе неявное предположение, раз написано на человеческом языке, значит любой сможет писать программы. Если предположить что существует подмножество языка, на котором можно точно описывать алгоритм, то писать на нем смогут все равно только люди со специальной подготовкой. Но читать смогут больше людей, без специальной подготовки. Косвенное подтверждение это законотворчество, юриспруденция и отчасти технические задания. Избыточность в описании процессов, присущая языкам программирования присутсвует, и которая крайне важна для подробного описания алгоритма, в трех примерах присуствует, но в гораздо меньшей форме чем в ЯП.

Одной из причин, как мне кажется, по которым естественные языки не взлетают, это потому что однозначный разбор грамматики пока не решенная проблема, и если лингвисты найдут на нее положительный ответ, то может быть ситуация поменяется. Примеры исследований в подобном направлении - http://attempto.ifi.uzh.ch/site/resources/ . Этот проект использует ограниченное и контролируемое подмножество английского языка для представления знаний. Я понимаю что это намного более простая задача. Посмотреть примеры можно по ссылке ACE in a Nutshell  на вышеупомянутой страница. Для меня подобные исследования говорят о том что вердикт не вынесен и люди хотят иметь более удобный для "чтения" формат кода. Опять таки, для чтения, а писать мучаться надо будет также.

Кроме Дейкстры, есть еще Кнут с концепцией Literate Programming. Также есть математика, которая использует вставки спец-языка в естественный язык, может быть также возможно с программированием.

Да, я кажется не туда метку вставил. Каюсь.

Просто мне показалось что оригинальный автор видит код как-то так, а не в виде FSM.
goto я выбрал только потому что наиболее близкая конструкция которая напоминает директивные переходы между состояний в v-нотации.Хотя возможно я тут и борюсь в ветряными мельницами.
from goto import with_goto

M = [1,2,7,1]
i = 0

def Action_00():
    sum = 0
    i = 0
	
def Action_10():
    sum = sum + M[i]

Action_00()
Action_10()
label .Direction_20
i = i + 1
if i < len(M):
    goto .Direction_20

label .Action_END
print("\nsum is [" + str(sum) + ']')
print('\nThe End')     


Пришлось применять сторонний модуль, но это «ограничение» питона, на Java/C#/C++ будет без проблем.
посмотрите на проек Google AMP. это конечно для приложений в текущем виде не очень подходит но как повод задуматься, интересно почитать
Спасибо, а вы какой то UI фреймворк используете?
я бы хотел попробовать повторить вашу ошибку, чтобы можно было сделать баг-репорт.
Может быть у вас есть какой-то мини пример как повторить нежелаемое поведение?
я несколько плаваю в терминологии SemVer так как мне никогда не надо была так жестко фиксировать зависимости. Из того что я помню по списку рассылки, и что я отразил в статье, то теперь каждая версия платформы, которая устанавливается CLI не имеет жесткой привязки к версии, и новые патч релизы будут устанавливаться с помощь. CLI.

Например выпуск версии cordova-android@4.0.2 потребовал обновления CLI чтобы устанавливалась версия cordova-android@4.0.2 вместо cordova-android@4.0.0. Без обновления CLI вы бы создавали новые проекты с имеющейся уязвимостью. Сейчас у команды имеется возможность выкатить обновление и вы бы получили его, без обновления CLI. Разумеется уже существующие проекты в обеих случаях надо обновлять ручками. Перед этим где то тоже в конце 2014 года был еще подобный инцидент с обновлением безопасности. Так как ребята понимают что от подобных инцидентов они никак не застрахованы, то они просто делают жизнь лучше.

Далее они сузили устанавливаемые версии, потому что в большинстве случаев хочется иметь тильду, чем ^. Это более безопасные настройки для разработчиков Cordova так как существенно уменьшают необходимость тестирования зоопарков для каждой версии CLI.
Тут соглашусь, но большинству разработчиков этот функционал показался лишним в связи с тем что эта кнопка более не рекомендуется Google. У Cordova есть определенные проблемы с ресурсами, в том числе для тестирования, поэтому компромиссы по функционалу неизбежны. Если вам кажется что это полезный функционал и сможете показать что есть аудитория и поможете с тестированием, то вы можете обратиться прямо на dev рассылку. Вас определенно выслушают как минимум.
а можно пример того что тупит? если есть какой-то минимальный кейс где это видно. я с Windows Phone не особо дружен, поэтому сам помочь не могу, но ведь можно в качестве бага оформить и попробовать добиться исправления
Согласен, размер уменьшается до 12Мб, но пока судя по всему им нужно несколько релизов для того чтобы реализовать это. Сейчас в рассылке для разработчиков не видать пока никаких серьезных движений в этом направлении, поэтому еще с полгодика подождать надо мне кажется.
Насколько я знаю нет.
Вариантов защиты интеллектуальной собственности я вижу несколько:
1. В случае с Android можно расширить процесс построения с помощью Gradle и добавить дополнительный шаг построения, который будет использовать обфускацию.
2. В случае с iOS и так код компилируемый, поэтому более менее вы спите спокойно.

Обфусцирование HTML, JS можно делать с помощью агрессивной минификации, кажется Google Closure Compiler подойдет вам.
Скажем так, если вы не будете писать с использованием компилируемых языков (C++, Objective-C) то никакая система защиты надолго не остановит заинтересованного в копировании вашей интеллектуальной собственности.
Вы были правы изначально. PhoneGap это чуть больше чем Cordova. В частности PhoneGap дополнительно предоставляет возможность интегрироваться с PhoneGap Build что дает возможность например собирать приложения для iPhone без мака. Это как минимум. Так как я не пользователь PhoneGap то не могу точнее сказать про доп возможности по сравнению с Cordova. Все выше перечисленное я почерпнул из наблюдения за тем что пишут сами разработчики.
Именно так, на 20Mb, потому что Intel SDK как раз использует Crosswalk насколько я понимаю. Вокруг Cordova достаточно большое кол-во оболочек — PhoneGap, AppGyver Steroids, Intel XDK, Ionic, Chrome App Developer Tool for Mobile. Все предоставляют набор плагинов и доп инструментарий. Глядишь и MS что-то свое предложит

Information

Rating
Does not participate
Location
Алматы (Алма-Ата), Алма-Атинская обл., Казахстан
Registered
Activity