Лингвофорум

Вопросы только для тех, кому данная сфера не чужда.

1. Какие языки программирования вы изучали?
2. Какой из них вы предпочитаете использовать?

В учебных целях приходилось иметь дело с Паскалем, Си, Ассемблером, Лиспом и Scheme.

Я про себя не рассказал. В довольно мохнатые годы (начало 1990-х) учил я сначала Бейсик, потом Паскаль и азы Ассемблера. Бейсик явно шел лучше. И потом мне пригодился, потому что на его турбо-диалекте, обладающем, в отличие от большинства других тогдашних бейсиков, тем достоинством, что он позволял компилировать полноценные exe-файлы, я сделал себе некоторые облегчающие жизнь программы, в частности, для обработки текстов. Сейчас-то такие задачи, вроде составления частотного словаря для определенного текста, стандартными программами решаются, но тогда их в доступе не было, так что приходилось вот так самому подобные инструменты изобретать.

В лицее, где проучился один год, изучал Турбопаскаль. Тогда мало что понимал и разбираться не хотел, по сути. Позднее, в первых двух семестрах (прежде всего, во втором) универа изучал С++. Вот тогда реально разобрался, мне понравилось, я даже некоторое время жалел, что не пошёл учиться на программиста. Ну и, естественно, что С++ мне ближе любого другого языка программирования. Впрочем, по-настоящему я не углулялся, конечно. А главным все же считаю не умение использовать синтаксис языка, а построение алгоритма. Но это к слову.

ХТМЛ - не язык программирования, но его упомяну тоже. В начале 2010-го активно занялся сайтостроительством, тогда же изучал и использовал его самостоятельно (при этом там были условные операторы, хотя мне позже говорили, что вроде их в ХТМЛ быть не должно). Параллельно изучал и использовал таблицы стилей, то есть, CSS.

В детстве читал учебник информатики, там был какой-то BASIC, потом читал учебник по Турбо Паскалю.
Впоследствии у друга на компе первое пригодилось для кодинга на QBASIC (хотя больше глядели в хелп, благо он там достаточно мощный). ТП потом установил на комп, но так особенно и не попробовал.
Более-менее занимался на Pythonʼе, трогал PHP, Lua, Ruby, в игре Colobot используется C-подобный CBot (по сути урезанный C с несколькими встроенными игровыми типами и функциями).
Ну а основное, конечно, JavaScript, пишу юзерскрипты для тех сайтов, где не хватает юзер-CSS, и занимаюсь всякой фигнёй типа рисования на canvas.

Начну с конца. В последнее время увлекся APL (на самом деле, книжка по APL попала ко мне еще в школьные годы, но тогда у меня не было на чем программировать на нем — просто почитал и забросил) — использую преимущественно свой вариант на основе NGN APL, куда я добавил некоторые фичи, которых мне в его изначальном варианте не хватало (некоторые примеры кода можно посмотреть в теме Считаем до миллиона). Сам NGN APL (и, следовательно, мой его форк) написан на JavaScript'е, что делает его изменение более простым, чем если бы это был, например, исходник на C/C++, хотя, вероятно, снижает производительность программы. APL мне нравится своей сверхлаконичностью и нестандартной логикой — своего рода аналог регексов для работы с массивами. JavaScript — ну, язык как язык, с C-подобным синтаксисом и некоторыми возможностями функционального программирования, интересный преимущественно тем, что доступен в каждом браузере (хотя я предпочитаю консоль и, следовательно, NodeJS), с низким порогом вхождения и быстрым осознанием того, как топорно там все сделано. Стандартный ввод-вывод в NodeJS — это нечто, по сравнению с ним Java'овские ридеры и райтеры кажутся песней...

Перед этим был период Python'а (который не имеет отношения к моему нику, придуманному независимо и из другого источника — собственно, тогда я еще не был знаком с этим языком; позже долго избегал его — меня отталкивал его «детский» синтаксис, и лишь спустя годы распробовал и обнаружил в нем кучу интересностей, с которыми чуть раньше встретился в Clojure и других лиспах). Язык многопарадигматичный — при желании, можно программировать на нем почти как на лиспе, и такой код будет вполне валидным (хотя язык и более заточен на тот самый «детский» стиль — процедурный код плюс, возможно, ООП-обертка воспринимается как нечто более мейнстримное, делать все через лямбды без костылей не получится...). Или взять генераторные функции с yield, позволяющим вывернуть алгоритм наизнанку.

(Тут я несовсем согласен с мыслью, что язык второстепенен по сравнению с алгоритмом. Безусловно, очень многие вещи делаются на разных языках практически иденично, но некоторые синтаксические и алгоритмические средства, присутствующие в том или ином языке, не имеют точных аналогов в другом — да, при желании, их можно имитировать, но результат может получиться некрасивым, слишком костыльным и/или громоздким. И наоборот, отсутсвие чего-либо в языке способствует использованию чего-то другого — взять, к примеру, классический BASIC, в котором нет структурных типов данных и процедур в обычном смысле, но зато имеется DATA/READ/RESTORE — в сущности, возможность задавать предопределенный список значений с последовательной выборкой из него. И если некий алгоритм на BASIC'е построен вокруг этих операторов, то переделка его, например, на C потребует реализовать собственный аналог такой очереди — что, в общем-то, просто, пока дело не доходит до RESTORE на метку, аналог чего, в общем-то, тоже не так уж и сложно придумать — но для изначального языка это средство «из коробки» и поэтому более самоочевидное, а для конечного — лишь надстройка, к изобретению которой надо додуматься. И наоборот, при переписывании на тот самый классический BASIC (при отсутствии в нем настоящих процедур и стека данных) чего-то типа ханойских башен или другого рекурсивного алгоритма, приходится либо имитировать стек при помощи массива, либо, лучше, вообще без него обойтись, заменив временное хранение обратным вычислением. В конечном итоге, различные языки позволяют взглянуть на один и тот же алгоритм под разным углом.

Ну а так, что-угодно можно сделать при помощи чего-угодно — видел, например, в одном старом учебнике реализацию двоичного дерева на ALGOL-60 — при том, что в нем нет ни структур, ни указателей — только массивы фиксированной длины — но, на самом деле, даже и этого вполне достаточно для реализации той же логики).

Clojure и чуть раньше перед ним Scheme — в общем, LISP (хотя к собственно Common LISP я так и не успел достаточно приблизиться). Другой взгляд на построение алгоритмов, другой набор средств: например, неизменяемые локальные «переменные», или рекурсия везде, где в других языках это считается плохим тоном и ведет к переполнению стека. Впрочем, присмотревшись, в рекурсивных алгоритмах начинаешь угадывать обычные циклы (коими хвостовая рекурсия на самом деле и является). С переходом от Scheme (заточенной под рекурсию) к Clojure (где основная фишка — ленивые последовательности) постепенно отказался и от рекурсивных циклов, их место заняли map, filter и прочие функции для манипуляций с последовательностями (и позже знакомство с ними пригодилось и в Python'е. В принципе, ФП сейчас достаточно мейнстримно, и подобные средства добавляются во все уважающие себя современные языки). Да, и макросы — в лисповском варианте, ломающие сишный стереотип, что это лучшее средство сделать свою программу максимально бажной и неотлаживаемой. Впрочем, Clojure изначально имеет достаточно мощный их набор, так что определять свои макросы мне практически не требовалось. Python или JS многое теряют, не имея подобных средств.

В период увлечения лиспами, я ориентировался на их JVM-реализации (напр., в случае Scheme — SISC или KAWA), хотя собственно Java тогда мне не казалась особо интересной — мне нравилась концепция виртуальной машины, организация библиотек, кроссплатформенность — но сам язык, для которого эта виртуальная машина была построена, воспринимался как слишком громоздкий, перенасыщенный дидактическим ковырянием и навязчивым ООП там, где хватило бы и процедурного кода. Но имея дело с Clojure, я так или иначе пользовался Java-библиотеками, и некоторая часть моего кода позже была написана на собственно Java'е.

SED — как правило, его считают несовсем языком программирования, а, скорее, утилитой для манипуляций с текстом, хотя некоторые умельцы создавали на нем, например, программу для игры в шахматы. Не могу похвастаться тем же, но одна из первых моих программ с использованием sed — форумный бот для ЛФ — представляла собой батник, где обмен с сервером осуществлялся при помощи wget, а обработка полученных данных производилась при помощи sed и некоторых других утилит. В общем, это язык программирования, но очень урезанный, где нет переменных в обычном смысле, алгоритмические средства ограничиваются меткой и переходом, а основной инструмент — регексы (они же регулярные выражения — шаблоны для поиска (и замены) в тексте. Кстати, еще одно средство, которое в наши дни есть в любом уважающем себя языке — после победного шествия perl'а в 90-е, подхватившего эту идею. Регексы в sed'е не самые мощные — например, Java использует их более продвинутый вариант, но на sed весь код может состоять из регексов ПОЛНОСТЬЮ). В общем, хотите освоиться с регулярными выражениями — поиграйтесь с sed.

В принципе, и язык командной оболочки (который используется в окне командной строки и на котором пишутся батники) тоже можно рассматривать как язык программирования. Просто сам по себе он мало что умеет — его работа сводится преимущественно к вызову других программ... Ну а так, там есть переменные, процедуры, цикл for с довольно неудобным синтаксисом, ветвление и переход на метку, в конце-концов. В общем, менее удобный, чем bash, но тоже вполне себе алгоритмический язык.

PHP — серверный язык для веб-страниц. Что тут еще добавить. Использую для расширений функционала собственного блога и некоторых других мелочей. Подразумевается, что php-шник html тоже должен знать.

Assembler. К сожалению, я уже не застал времен, когда допиливание на асме всяких мультиэдитов было еще актуально. С другой стороны, моей мечтой было написание компиляторов, для чего знание ассемблера более чем полезно. Мой курсач по системному программированию представлял собой компилятор с языка ассемблера, дававший на выходе .com-файл (простейший выполняемый формат). К сожалению, довести его до полноценного состояния я так и не успел — среди поддерживаемых команд были только арифметические операции, чего хватило для получения пятерки, но не для того, чтобы я сам мог им пользоваться, позже появились другие дела — в общем, проект так и остался в сыром виде...
А еще ассемблер дает понимание того, насколько в этом мире все неоптимально...

Pascal, Delphi. Основной институтский язык (хотя немного странно, почему нам преподавали, в первую очередь, паскаль, а не С++, например, что более соответствовало бы программисткой специальности.
Сейчас в сети я чаще натыкаюсь на студентов, изучающих C++, чем паскаль. Возможно, Delphi и TurboPascal в 90-е были более актуальны, чем сейчас). Основное преимущество Delphi — простота в создании GUI (чего мне не хватало в «школьных» языках, как и в TP), хотя позже пришел к выводу, что кнопкотаскание лишь убивает время, давая в конечном итоге программу, лишенную по сравнению с консольником средств внешней автоматизации, таких как перенаправление потоков ввода/вывода. Так что со временем я начал писать консольные программы на Delphi (не на TP, поскольку и в самом языке появились некоторые дополнительные возможности, которых до Delphi не было), а позже перешел на опенсорсный FreePascal (он же FPC) с теми же языковыми средствами. Если подумать, ООП-средства Delphi и его клонов имеют много общего с имеющимися в Java'е и C# — наследование от единственного класса плюс множественное наследование интерфейсов, свойства и пр. — и намного удобнее громоздких наворотов С++, просто созданных для простреливания себе ног всевозможными способами — только Java'у все хвалят, как и C#, а С++ так вообще стандарт, а вот Delphi почему-то «для ламеров». Все дело в низком пороге вхождения?..

BASIC — основной школьный язык программирования. Вначале был GW-BASIC, позже в школе появились более навороченные TurboBASIC и QBASIC. Моего желания создать на всем этом нечто выдающееся, типа компьютерной игрушки или своего собственного языка программирования, было явно больше, чем опыта написания чего-то большого и при этом работоспособного :( Хотя, в общем-то, программирование было моим любимым предметом в старших классах и в пределах школьной программы трудностей не вызывало. Сейчас тоже иногда играюсь, отдавая предпочтение «ностальгичным» диалектам (т.е., VBA — уже не бейсик, ІМНО: совершенно другая философия языка и парадигма типов, да и классический BASIC-код в нем попросту не работает). В неосуществленных планах — написать собственный BASIC, наследующий синтаксис и общую философию старых диалектов, но при этом позволяющий использовать самостотельные программы в качестве процедур и функций, расширяющий набор доступных типов, использующий некоторые элементы ФП... — в общем, это можно сравнить с примерно тем путем, по которому пошло развитие APL. Кстати, классическая интерактивная среда разработки этих языков имеет много общего — дань эпохи печатных терминалов, где вместо технически невозможных в то время экранных редакторов при редактировании больших программ использовалась ручная нумерация строк.

Хотя первым языком, с которым я познакомился, был C. Правда, на нем я тогда не программировал (разве что немного на бумаге) — просто читал хорошо написанную книжку. Простой понятный минималистичный язык с прозрачной логикой, где есть все необходимое и ничего лишнего. Впрочем, практического опыта написания кода на нем у меня не так уж и много — всегда был какой-то другой язык, преимущественно на котором я программировал. Вот C++, кстати, не люблю — хотя некоторые идеи из него мне были близки в свое время, мне в нем видится преимущественно язык-монстр с кучей переусложнений непонятно ради чего. Либо это последствия первого впечатления (Страуструп пишет хуже, чем Прата)?..

Вернее, самая первая «моя» программа была написана на PL/1. «Моя» в кавычках, потому что писала ее преимущественно мама, а я лишь смотрел и мало что понимал в происходящем. Впрочем, некоторые моменты все же принесли пользу, кое-что отложилось в памяти, и когда я позже по-настоящему начал знакомство с программированием, основные понятия уже были для меня знакомы.

ЦитироватьИли взять генераторные функции с yield, позволяющим вывернуть алгоритм наизнанку.

Ой, а «наизнанку» — это как?

P.S. Еще можно написать про языки, мое знакомство с которыми ограничилось написанием одной-двух программ без дальнейшего углубления — Lua, FORTRAN, Haskell, perl, C#, встроенные скриптовые языки некоторых программ, а также языки разметки (HTML, LaTeX, ABC), языки запросов (SQL в различных вариациях), и пр., и пр. Я много чем интересуюсь, и далеко не всегда это находит практическое применение — скорее, мне интересны концепции, используемые в том или ином языке (см. выше про взгляд на один и тот же алгоритм под разным углом).

Цитата: Vertaler от ноября  1, 2018, 23:53

ЦитироватьИли взять генераторные функции с yield, позволяющим вывернуть алгоритм наизнанку.

Ой, а «наизнанку» — это как?

Например, так: https://docs.python.org/2.5/ref/yieldexpr.html

Впрочем, и в более общем случае yield превращает подпрограмму в сопрограмму, позволяя любой алгоритм, циклически генерирующий последовательности значений, сделать «ленивым» (т.е., приостанавливающимся и возобновляющим работу по мере необходимости). Как сделать нечто подобное в языке типа JS, где yield/сопрограммы/континуации или другие подобные средства отсутствуют — только return? Именно что руками вывернуть весь алгоритм наизнанку, превратив его в серию вызовов функции, которая при каждом вызове должна каким-то образом продолжить вычисление с того места, где в прошлый раз остановилась... Выглядит так, что yield выворачивает алгоритм подпрограммы, не выворачивая его.

Цитата: From_Odessa от октября 31, 2018, 20:21
ХТМЛ - не язык программирования, но его упомяну тоже. В начале 2010-го активно занялся сайтостроительством, тогда же изучал и использовал его самостоятельно (при этом там были условные операторы, хотя мне позже говорили, что вроде их в ХТМЛ быть не должно).

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

Это не считая условных операторов во встроенном JavaScript'е, который хоть формально и считается чем-то отдельным от HTML, но на практике является полноценной его частью.

Цитата: Python от ноября  2, 2018, 00:21Как сделать нечто подобное в языке типа JS, где yield/сопрограммы/континуации или другие подобные средства отсутствуют — только return?

Ну, во-первых, уже есть (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/yield).
Во-вторых, такое легко реализовывалось через замыкания и синглетоны.

В детстве впечатлился, как брат делает делает игры и медиаплееры на Паскале, вот и добился, чтобы меня тоже научили. Брат правда и на Бейсике игры делал, но в какое-то время у нас все стали считать Бейсик неполноценным языком. Сделал на нём несколько игр. Одной из основных были лабиринты. Потом перешёл на Visual C++. На нём тоже делал игры, в том числе -- клон одной из моих любимых игр Supaplex и клон одной из анимационных программ. Правда после того, как у нас появился Flash, на свой движок векторных мультиков забил. Ещё сделал 3d-версию лабиринтов и небольшой симулятор метро (просто бродить и ездить на поездах, больше ничего). Это всё до 18 лет. В 18 лет пошёл работать и делал финансовую базу данных, в основном на VBA и SQL, но и для C# применение нашлось. C# конечно намного удобнее VBA, особенно после того как Linq появился. В свободное от работы время кодил на Java, участвовал в разработке JOSM. Потом эта работа мне надоела и я стал искать другую. И нашёл -- сделал довольно специфический медиасервер под nginx на чистом C. По счастью, работодатель оказался из Киева. Потом этот же работодатель предложил мне проекты на Golang для разных сетевых бекендов. Быстренько изучил этот язык и с тех пор он у меня основной. Для побочных проектов и мелких утилит использую Python.

Цитата: Bhudh от ноября  2, 2018, 01:03
Во-вторых, такое легко реализовывалось через замыкания и синглетоны.

Даже если так:

def generator():
    for i in range(10):
        for j in range(10):
            yield i*j

Хотя, если переделать for на while, а while — на функцию с рекурсией, и потом присобачить куда-то замыкания... Да, возможно, но легко?

Цитата: Bhudh от ноября  2, 2018, 01:03

Цитата: Python от ноября  2, 2018, 00:21Как сделать нечто подобное в языке типа JS, где yield/сопрограммы/континуации или другие подобные средства отсутствуют — только return?

Ну, во-первых, уже есть (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/yield).

Круто :up:
Даже мой древний WinXP-совместимый нод эту фичу поддерживает. Почему я никогда о ней не слышал?

Цитата: Bhudh от ноября  2, 2018, 01:03

Цитата: Python от ноября  2, 2018, 00:21Как сделать нечто подобное в языке типа JS, где yield/сопрограммы/континуации или другие подобные средства отсутствуют — только return?

Ну, во-первых, уже есть (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/yield).
Во-вторых, такое легко реализовывалось через замыкания и синглетоны.

Вот-вот. Только хотел сказать, что в ES6 есть генераторы, правда, как ими пользоваться на практике, я ещё не вкурил.

Вообще сейчас период бурного развития JS. Каждый год появляются новые "фенечки" вроде использования промисов в стиле Си-шарпа через async/await и т. п.

Ещё матёрые JS-программеры очень любят call/apply и "прививать" методы объекту через подмену прототипа родительского класса. Такие программы тяжело исправлять, сиди и гадай, от кого эта функция в конечном итоге на следует свой this. В общем, JS я люблю, он какой-то эстетически красивый, в противоположность PHP, в котором то же самое будет выглядеть как какое-то жуткое нагромождение $this->, array ('obj' => и т. п.

Цитата: Python от ноября  2, 2018, 00:33
На самом деле, есть директивы условной обработки, которые поддерживались IE и использоались преимущественно для автоматического определения версии браузера. В других браузерных движках, насколько мне известно, их поддержка отсутствует — не зная о них, Мозилла или Хром увидит на их месте лишь закомментированный код.

Это не считая условных операторов во встроенном JavaScript'е, который хоть формально и считается чем-то отдельным от HTML, но на практике является полноценной его частью.

Эти условные операторы нормально воспринимались и ФФ, и Оперой, и Хромом. В общем, я не знаю, что это было, я думал, что это обычная часть ХТМЛ) Это было при работе с сайтом на Юкозе. Там, собственно, приходилось активно использовать эти условные операторы. Может, это как раз встроенный ДжаваСкрипт?

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

Цитата: From_Odessa от ноября  2, 2018, 07:30

Цитата: Python от ноября  2, 2018, 00:33
На самом деле, есть директивы условной обработки, которые поддерживались IE и использоались преимущественно для автоматического определения версии браузера. В других браузерных движках, насколько мне известно, их поддержка отсутствует — не зная о них, Мозилла или Хром увидит на их месте лишь закомментированный код.

Это не считая условных операторов во встроенном JavaScript'е, который хоть формально и считается чем-то отдельным от HTML, но на практике является полноценной его частью.

Эти условные операторы нормально воспринимались и ФФ, и Оперой, и Хромом. В общем, я не знаю, что это было, я думал, что это обычная часть ХТМЛ) Это было при работе с сайтом на Юкозе. Там, собственно, приходилось активно использовать эти условные операторы. Может, это как раз встроенный ДжаваСкрипт?

А как они хоть выглядели, и для чего использовались?
Если Юкоз, то еще, возможно, это даже не HTML, а что-то свое юкозовское, обрабатываемое на их сервере — в общем, часть синтаксиса юкозовского шаблонизатора. Либо, Юкоз позволяет размещать у себя php (где условные операторы тоже есть, как и во всяком алгоритмическом языке)?

Цитата: Devorator linguarum от октября 31, 2018, 18:59
Вопросы только для тех, кому данная сфера не чужда.

1. Какие языки программирования вы изучали?
2. Какой из них вы предпочитаете использовать?

1. Ой, каких только не изучал. Правда систематически - только C (с C++) и Ассемблер, на заре карьеры, связанной с вычислительной техникой. Всё остальное - "галопом по Европам".
2. Никакой. ::) Из того, что реально хоть как-то использовал - пару сайтов на PHP делал, и несколько скриптов для караоке на Lua.

Цитата: Devorator linguarum от октября 31, 2018, 18:59
Вопросы только для тех, кому данная сфера не чужда.

1. Какие языки программирования вы изучали?
2. Какой из них вы предпочитаете использовать?

Изучил всего один: C++.
Понимаю, естественно, C#, немного Дельфи и Паскаль. На последнем приходилось даже контрольные писать в школе.

2Python

Вот пример кода оттуда:

Цитировать<?if($MODULE_ID$='forum')?><div class="header-right-forum"><div class="header-forum">
<div class="date"><font color="black">$WDAY$, $DATE$, $TIME$</font></div>
<div class="user-bar"><font color="black"><?if($USER_LOGGED_IN$)?><!--<s5200>-->Вы вошли как<!--</s>--> <a href="$PERSONAL_PAGE_LINK$"><font color="black"><b>$USERNAME$</b></font></a></b><?else?><!--<s5212>-->Приветствуем Вас,<!--</s>--> <b>$USERNAME$</b><?endif?></font></div>
<h1><!-- <logo> --><img src="http://earlyedition.ucoz.ru/bezymjannoe-2.png"><!-- </logo> --></h1>
<?else?>
<div class="header-right"><div class="header">
<h1><!-- <logo> --><img src="http://earlyedition.ucoz.ru/bezymjannoe-2.png"><!-- </logo> --></h1>
<?endif?>
<div class="navigation"><a href="$HOME_PAGE_LINK$"><!--<s5176>-->Главная<!--</s>--></a> <?if($USER_LOGGED_IN$)?><a href="$PERSONAL_PAGE_LINK$"><!--<s5214>-->Мой профиль<!--</s>--></a><?else?> <a href="$REGISTER_LINK$"><!--<s3089>-->Регистрация<!--</s>--></a><?endif?> <?if($USER_LOGGED_IN$)?> <a href="$LOGOUT_LINK$"><!--<s5164>-->Выход<!--</s>--></a><?else?> <a href="$LOGIN_LINK$"><!--<s3087>-->Вход<!--</s>--></a><?endif?></div>
</table>
</div></div>

Выглядит внушительно и угрожающе.

Не JS и не эксплореровские условные директивы. Некоторое внешнее сходство с php есть, но разница в деталях (т.е., это вообще не php). Думаю, всё же шаблонизатор.

Цитата: Python от ноября  2, 2018, 11:58
Не JS и не эксплореровские условные директивы. Некоторое внешнее сходство с php есть, но разница в деталях (т.е., это вообще не php). Думаю, всё же шаблонизатор.

Юкозовский шаблонизатор в рамках ХТМЛ (в смеси с ХТМЛ)? Или нет?

Цитата: From_Odessa от ноября  2, 2018, 11:59

Цитата: Python от ноября  2, 2018, 11:58
Не JS и не эксплореровские условные директивы. Некоторое внешнее сходство с php есть, но разница в деталях (т.е., это вообще не php). Думаю, всё же шаблонизатор.

Юкозовские шаблонизатор в рамках ХТМЛ (в смеси с ХТМЛ)? Или нет?

Скажем так, если этот код скормить непосредственно браузеру, работающему с html, такой код будет несовсем рабочим (что-то отобразится, но не так, как задумал автор, возможно, некоторые теги шаблонизатора отобразятся в виде мусора либо нарушат структуру документа). Шаблонизатор — серверная программа, встраивающая в текст (в данном случае, html-текст) некоторые данные и производящая с ним некоторые другие манипуляции, это не часть собственно html (так же, как и php нельзя назвать языком в рамках html, хотя вместе с ним он чаще всего используется). Хотя все, что за пределами <?...?>, можно считать чистым html (впрочем, если просто их убрать, то в html-код попадут обе ветки if и, очевидно, не попадут встраиваемые данные, что, опять же, не соответствует изначальному замыслу создателя шаблона, а полученный html-код может оказаться невалидным).

Цитата: From_Odessa от ноября  2, 2018, 11:59Юкозовский шаблонизатор в рамках ХТМЛ (в смеси с ХТМЛ)? Или нет?

Именно так.
Обрабатывается это не HTML-парсером браузера, а PHP-парсером Юкоза.
То, что между <? и ?> это вообще чистый PHP (это его скобки).

Цитата: Bhudh от ноября  2, 2018, 13:38

Цитата: From_Odessa от ноября  2, 2018, 11:59Юкозовский шаблонизатор в рамках ХТМЛ (в смеси с ХТМЛ)? Или нет?

Именно так.
Обрабатывается это не HTML-парсером браузера, а PHP-парсером Юкоза.
То, что между <? и ?> это вообще чистый PHP (это его скобки).

Скобки такие же, а вот их содержимое — не php. Напр., обратите внимание на $, обрамляющие переменные с обеих сторон (в php $ только слева), или на if/else/endif, отличающийся от обоих вариантов синтаксиса, принятого в php — нужно либо двоеточия добавить, либо убрать endif и добавить фигурные скобки.

Цитата: Bhudh от ноября  2, 2018, 15:53

Цитата: Python от ноября  2, 2018, 14:54обратите внимание на $, обрамляющие переменные с обеих сторон

Так это переменные шаблонизатора, те же, что и в HTML-части кода.
Шаблонизатор их переводит в их значение, а потом уже подаёт на вход PHP-интерпретатору.

Цитата: Python от ноября  2, 2018, 14:54на if/else/endif, отличающийся от обоих вариантов синтаксиса, принятого в php

:??? Фигурные скобки в PHP, как и в JS, для единственного оператора не обязательны.
И двоеточия зачем? Там же не тернарный оператор.

В php есть два варианта if:
1) аналогичный используемому в C/Java/JS — ключевое слово endif не используется, два и более оператора требуют фигурных скобок. (Фрагмент внешнего html-текста — это точно один оператор? Как ведется подсчет — где кончается else?.. В общем, без {} пропадает ясность и возникает риск создать нечто глючное.)
2) позже добавленный вариант с endif и elseif — с двоеточиями вконце заголовков секций и возможностью нескольких операторов в каждой секции условной конструкции:
if ($a == 5):
    echo "a равно 5";
    echo "...";
elseif ($a == 6):
    echo "a равно 6";
    echo "!!!";
else:
    echo "a не равно ни 5 ни 6";
endif;

Да, еще обратите внимание в юкозовском примере на = там, где по логике php должно быть ==

Уже посмотрел, что напрочь забыл Pythonʼоподобный вариант ветвления.
Значит, это всё PHP-подобный шаблонизатор.

Цитата: Python от ноября  1, 2018, 23:39
Тут я несовсем согласен с мыслью, что язык второстепенен по сравнению с алгоритмом

Если Вы отвечали (хотя бы частично) на мои слова, то тут надо учесть, что я - дилетант ) С программированием знаком слабо, а с языками - совсем слабо, с тем же С++ поверхностно (да и пользовался им последний раз, кажется, 15 лет назад), с другими - почти никак (если не считать вот тот самый шаблонизатор Юкоза). Так что, конечно, я могу нести полную или частичную ерунду. И не с Вами мне об этом спорить ) Правда, такое же мнение высказывал мой преподаватель информатики в университете (что главное - алгоритм), который к тому времени, если не ошибаюсь, был практикующим программистом где-то с 30-летним стажем. Но это мнение лишь одного специалиста. К тому же, возможно, он как раз всю или почти всю карьеру пользовался языками, где все делается сходным образом.

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

Python, Вы не могли (или кто-то другой) на пальцах и простым языком объяснить мне, чем отличаются языки с ООП (для ООП) от других? Лучше всего на примере сходных языков, один из которых ООП, а второй - нет.

Цитата: From_Odessa от ноября  2, 2018, 16:35чем отличаются языки с ООП (для ООП) от других?

Наличием ООП ;D.
Ну, вернее, наличием специальных средств для объединения разнородных данных в одну сущность, причём с наличием в этой же сущности (или в более высокой, но это относится уже конкретно к наследованию) средств обработки этих данных.
Сущность, объединяющая данные, зовётся объект, а конкретная функция, находящаяся в объекте и имеющая доступ к его данным, обычно называется метод.

ООП отлаживать/радактировать хорошо. Изменил в одном месте - и всё. А при традиционном структурном программировании лазишь по всей программе и переделываешь, переделываешь.
Поздно я это поняла, когда делали последний хоздоговор.

Цитата: Bhudh от ноября  2, 2018, 16:55
Наличием ООП ;D.
Ну, вернее, наличием специальных средств для объединения разнородных данных в одну сущность, причём с наличием в этой же сущности (или в более высокой, но это относится уже конкретно к наследованию) средств обработки этих данных.
Сущность, объединяющая данные, зовётся объект, а конкретная функция, находящаяся в объекте и имеющая доступ к его данным, обычно называется метод.

Спасибо. Попробую уточнить. Вот тот же С++. Он - язык ООП. Что в нем есть, чего нет в языках не ООП? В С++ есть классы. Это и делает его языком ООП?

Цитата: _Swetlana от ноября  2, 2018, 17:13
ООП отлаживать/радактировать хорошо. Изменил в одном месте - и всё. А при традиционном структурном программировании лазишь по всей программе и переделываешь, переделываешь.

Вы имеете в виду, что при ООП достаточно изменить что-то там, где объявлялся класс, изменить что-то в теле класса, и это изменит все, что в программе связо с ним?

ЦитироватьТак что, конечно, я могу нести полную или частичную ерунду.

Не ерунду — мысль вполне правильная, очень многие вещи на разных языках различаются лишь внешним оформлением, либо эти различия не так уж сложно устранить/заменить близким аналогом. К тому же, активно развивающиеся языки стремятся к реализации одних и тех же возможностей, которые были реализованы раньше у других. Допустим, C, Pascal и другие типичные языки того времени используют примерно один и тот же набор типов данных, алгоритмических конструкций, базовых операций — как и любой другой процедурный язык, создвавшийся в 70-е—80-е под влиянием идей ALGOL-60, а чуть позже BASIC и FORTRAN начала 90-х тоже уже имели вполне структурированный вид. В 90-е установилась мода на объекты и классы — место процедурных языков заняли их объектно-ориентированные диалекты/потомки (C++, Delphi, VisualBasic, Java и пр.), после 2010 модной тенденцией стало функциональное программирование (в последних версиях популярных языков, как правило, есть лямбды, замыкания и пр.)... В конечном итоге, программисты на разных языках используют примерно один и тот же инструментарий.

Я говорил лишь, что несовсем согласен. Чтобы можно было ощутить влияние языков на код, их возможности должны различаться достаточно радикально. «Интересный» язык должен быть в чем-то очень оригинальным, а в чем-то, возможно, очень урезанным.

Цитата: From_Odessa от ноября  2, 2018, 17:31Вот тот же С++. Он - язык ООП. Что в нем есть, чего нет в языках не ООП? В С++ есть классы. Это и делает его языком ООП?

Если есть классы, это уже более узкий тип класс-ориентированного программирования.
Но в принципе верно. Делает его языком ООП то, что в нём есть классы и экземпляры этих классов.
Не будь экземпляров-объектов: какое тут к чертям ООП?

Цитата: From_Odessa от ноября  2, 2018, 17:31
В С++ есть классы. Это и делает его языком ООП?

Безусловно.
Хотя, с другой стороны, классы в С++ можно и не использовать, а писать программы в C-подобном процедурном стиле. А вот если взять более чистый в плане ООП язык, как Java, то там попросту нельзя написать программу, не создав хотя бы один класс, в который заворачивается функция main (впрочем, неуверен, можно ли считать классом такой класс без экземпляров и потомков, или же его правильнее было бы считать модулем).

Если быть точным, классы — лишь один из вариантов реализации ООП, и, в принципе, существуют и объектно-ориентированные языки, где понятие «класс» не используется, а наследование обеспечивается через механизм прототипов. Подобная концепция используется в JavaScript'е, но в последних версиях классы там тоже появились. Ключевым пунктом для ООП являются объекты — сущности, содержащие в себе и данные, и код (инкапсуляция), подлежащие замене объектом с другой реализацией методов (полиморфизм) и, как правило, способные использовать методы, определенные ранее для других объектов (наследование).

С точки зрения внутренней реализации, объект (экземпляр класса) представляет собой структуру с указателями на функции-методы (размещенные непосредственно в структуре или вынесенные за ее пределы в таблицу методов). Такого рода структуру можно создать и в процедурном языке типа C, где понятие «класс» изначально отсутствует. Так что ООП-подход возможен и в языках, непосредственно под ООП не заточенных.

Цитата: Python от ноября  2, 2018, 18:09в последних версиях классы там тоже появились

Там появился лишь синтактический сахар с зарезервированным с момента создания JS словом class.
Прототипное наследование как было, так и осталось.
Даже приватных и статических свойств не ввели.

Да, изменяешь в описании класса, автоматически меняется во всех экземплярах.
До какого-то размера программы структурное программирование - милое занятие, и нечего тут огород городить. А потом вдруг раз - пушной зверь подкрался незаметно.
У меня, правда, была специфика. Эвристические алгоритмы отлаживают на реальных данных - вносят изменения, меняют настроечные константы и пр. И мне в голову приходили разные хорошие мысли,  два-три раза в день. Каждый день два раза я меняла алгоритм и вносила изменения в программу. Вот тут я поняла, что ООП - это сила, но было уже поздно.

Цитата: _Swetlana от ноября  2, 2018, 18:52Каждый день два раза я меня алгоритм

Цитата: Bhudh от ноября  2, 2018, 18:53

Цитата: _Swetlana от ноября  2, 2018, 18:52Каждый день два раза я меня алгоритм

Offtop

Начинает что-то подозревать.

А что?

From_Odessa, вот спэшлфою на Хабре историческая статья: https://habr.com/company/ruvds/blog/428582.

На работе пишу, в основном, на C# и Powershell.
Самый любимый -- язык Mathematica.

Вот, например, как задать в Mathematica функцию факториал.

f[1]:=1
f[n_]:=n*f[n-1]


Цитата: svarog от ноября  2, 2018, 19:13
На работе пишу, в основном, на C# и Powershell.
Самый любимый -- язык Mathematica.

Вот, например, как задать в Mathematica функцию факториал.

Код Выделить Развернуть


f[1]:=1
f[n_]:=n*f[n-1]


На первый взгляд напоминает Лисп и прочую лямбду.

Цитата: svarog от ноября  2, 2018, 19:13
На работе пишу, в основном, на C# и Powershell.
Самый любимый -- язык Mathematica.

Вот, например, как задать в Mathematica функцию факториал.

Код Выделить Развернуть


f[1]:=1
f[n_]:=n*f[n-1]


Испорченный Пролог  ;D
Программа неправильная. Задайте n=0, например.

       

Ещё в последнее время в моде асинхронность. Правда, у тех же Node.js и PHP она не совсем настоящая, однопоточная, но это, с одной стороны, и хорошо, с истинной параллельностью выполнения и реентерабельностью кода вообще мозги в  баранку скрутятся, как сделать так, чтобы одна функция не убегала вперёд другой. Хотя, кажется, есть истинно многопоточная реализация асинхронности для Java, и вроде как Erlang. Сам с ними не работал.

 :) from Z₀⁺, конечно.
(https://preview.ibb.co/b2io3L/factorial.jpg) (https://ibb.co/cSaPcf)

Цитата: злой от ноября  2, 2018, 19:44Хотя, кажется, есть истинно многопоточная реализация асинхронности для Java

Что есть по вашему "истинно многопоточная реализация асинхронности"?
Если уж на то пошло, то любой поток работает асинхронно. Проблемы возникают если разные потоки используют одни и те же данные. Классический способ решения этих проблем -- мютексы.
Но в последнее время всё более проявляется мода на другой подход -- вообще свести к минимуму расшаренные между разными потоками данных. Насколько я слышал, например в Rust каждый объект жёстко привязан только к одному потоку и другой поток может к нему обратиться только "одолжив" его -- на время перепривязав к себе.
Аналогично в Golang -- мютексы там есть, но считаются "неизбежным злом", жёсткой привязки объектов к потокам тоже нет. Однако использование мютексов не рекомендуется, и вместо этого рекомендуется, чтобы с данными работал только один поток, а остальные потоки получали данные от этого потока по специальным каналам.

Если сделать данные по умолчанию immutable, как в Clojure, то половина проблем с синхронизацией отпадает. Впрочем, изменяемые объекты в нескольких вариантах для межпоточного взаимодействия там тоже имеются.

Цитата: злой от ноября  2, 2018, 19:44Правда, у тех же Node.js и PHP она не совсем настоящая, однопоточная

В JS (Node.js — это всего лишь серверная реализация JS-движка V8, а не отдельный язык) для параллельных вычислений есть Web Workers (https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API).

Цитата: Bhudh от ноября  2, 2018, 20:41
Web Workers

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

Цитата: Python от ноября  2, 2018, 18:09
Хотя, с другой стороны, классы в С++ можно и не использовать, а писать программы в C-подобном процедурном стиле

Что я и делал...

Цитата: Bhudh от ноября  2, 2018, 19:10
From_Odessa, вот спэшлфою на Хабре историческая статья: https://habr.com/company/ruvds/blog/428582.

Спасибо!)

Что сейчас актуально для изучения?

Смотря для какой цели.
Для написания прикладного софта в основном форсятся Go(lang), C# новых серий, для iOS — Swift.
Менее: Rust, Python.
Для Web само собой JS, для бэка Ruby (on Rails), фреймворки на PHP и Python.

А джава?

На Джаве, как я понимаю, в основном поддержка ранее написанного.

Для Андроида Джава была актуальна пару лет назад. Сейчас уже нет?..

:donno: Она и для Symbian была актуальна.
По традиции для смартов на ней пишут?
Просто после появления той штуки, которая из пачки js и html файлов делает аппликуху под Андроид, на серьёзных языках делаются только по-настоящему серьёзные программы.

Цитата: Bhudh от декабря 12, 2018, 19:41
Просто после появления той штуки, которая из пачки js и html файлов делает аппликуху под Андроид, на серьёзных языках делаются только по-настоящему серьёзные программы.

Такие штуки и лет 10 назад существовали. Просто действительно ли они дают преимущества? Если у нас есть сайт, его нужно быстренько переделать в андроид-приложение — тогда да, писать с нуля на серьезном языке бессмысленно. А если это, например, игра в «дополненной реальности», работающая с видеокамерой, акселерометром и GPS, то я не очень представляю, как на html+js делается такое.

Еще слышал мнение одного андроид-программиста, что позиционирование объектов в html/css реализовано хуже, чем в собственно андроиде. Впрочем, вопрос вкуса и привычки.

Цитироватьдля бэка Ruby (on Rails)

Уже снова актуально? Просто, мне показалось, перед этим наблюдался спад спроса на Ruby.

Цитата: Python от декабря 12, 2018, 20:01А если это, например, игра в «дополненной реальности», работающая с видеокамерой, акселерометром и GPS, то

...это уже по-настоящему серьёзная программа.
С доступом напрямую к железу, как положено.

Цитата: Python от декабря 12, 2018, 20:03

Цитироватьдля бэка Ruby (on Rails)

Уже снова актуально? Просто, мне показалось, перед этим наблюдался спад спроса на Ruby.

Что-то не могу догадаться, что здесь обозначает слово "бэк" (как то не довелось встречать), даже после того, как прочёл, что такое Ruby on Rails, и что на нём создано.

Back end?

Цитата: Karakurt от декабря 13, 2018, 09:52
Back end?

Спасибо.

( :fp: <-- выдал себе награду за "догадливость")

Цитата: Python от декабря 12, 2018, 20:03Уже снова актуально?

Цитата: https://weblog.rubyonrails.org/newsAs you may know, the release of Ruby 2.6.0 is right around the corner!

Для кого-то ж выпускают...

Дополненная реальность на js уже существует
https://www.auduno.com/clmtrackr/examples/facesubstitution.html
(Чтобы посмотреть, нужна вебка)

В детстве изучал Паскаль. Забыл за ненадобностью. Знаю C. Неплохо знаю PHP и чуток Kotlin. Недавно выучил Python, тяжело даётся, сложный.

Цитата: Pigra_kojoto от января  8, 2019, 20:26
Недавно выучил Python, тяжело даётся, сложный.

Что именно в нём Вам показалось сложным?
(Долгое время мне он казался слишком простым, чтобы его учить)

Цитата: Python от января 10, 2019, 01:45

Цитата: Pigra_kojoto от января  8, 2019, 20:26
Недавно выучил Python, тяжело даётся, сложный.

Что именно в нём Вам показалось сложным?
(Долгое время мне он казался слишком простым, чтобы его учить)

У него сильно отличающийся синтаксис от C, посему чтобы на нем начать писать, его надо было заново учить как бы "с нуля".

Сильно? Вы еще LISP и APL не видели. ))
Идея синтаксически маркировать блоки отступами оригинальна, конечно, но что в ней такого, чего не делает правильно воспитанный программист на том же C?
Хотя, например, операции и их приоритет, в основном, такие же, как в C-подобных языках — в этом плане, python более C-подобен, чем тот же pascal.

Цитата: Devorator linguarum от октября 31, 2018, 18:59
1. Какие языки программирования вы изучали?

Если по-настоящему изучил, то есть тот язык, с которым более-менее спокойно себя чувствую, то наверное только Си, но всё равно постоянно спотыкаюсь о сегфолты и непонятные конструкции, написанные каким-нибудь умником.
Если изучал, то какое-то мелкое подмножество C++, когда-то пришлось потрогать JavaScript и TypeScript, совсем немного Python и уже забытый C#. Ну и Unix Shell и AWK заинтересовали в последнее время.

Цитата: Devorator linguarum от октября 31, 2018, 18:59
2. Какой из них вы предпочитаете использовать?

Тот, на котором написан проект. Как правило C или C++.

Я считал себя умным человеком, пока не начал изучать Scheme. А конкретно Guile (хорошая вещь, советую). Сколько ни бился, так и полностью не разобрался в continuation'ах. Это же надо так плохо объяснять! Проще дизассемблировать компилятор и самому понять, что это такое, чем по их объяснениям.

В упрощенном варианте, continuation можно использовать как многоуровневый выход из функции (примерно как exception) — в некоторых реализациях (например, kawa) они могут только это. Более сложные выкрутасы с возвратами обратно в функцию, из которой был осуществлен выход, сложнее для понимания сами по себе.

Говорят, самым естественным является порядок слов SOV. Поэтому такой "тюркский" язык программирования был бы удобен, естествененен и компактен. Есть PL Factor, но он слишком мудреный. Хочу тюркский язык такой же простой как Fortran 77.

Естественно в нём должна быть RPN, и ключевые слова на яңалифе.

Пример нахождения среднего арифметического двух введёных чисел:

a b oku  #считываем числа
orta = a b + 2 /
orta jaz #вывод

Цитата: maratique от июля 21, 2021, 15:08
orta = a b + 2 /

(wiki/ru) Обратная_польская_запись (https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%80%D0%B0%D1%82%D0%BD%D0%B0%D1%8F_%D0%BF%D0%BE%D0%BB%D1%8C%D1%81%D0%BA%D0%B0%D1%8F_%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C)

Цитата: maratique от июля 21, 2021, 15:08RPN

Это Reverse Polish notation.

RPN она сама по себе тюркская. Точнее алтайская.

Надо чтоб в языке обращения к массивам не отличались бы от вызова функций:

a = (1, -7.93, "hggjg", x)
1 a jaz   #выводит -7.93

Как бы 1'ci a'nı jaz

Так будет понятнее:

jaş = Lejla:23, Ajgül:59, Hasan:17, Ivan:6
Hasan jaş jaz   #выводит 17

Типа Hasannıñ jaşın jaz

Цитата: maratique от июля 21, 2021, 19:11
Надо чтоб в языке обращения к массивам не отличались бы от вызова функций:

a = (1, -7.93, "hggjg", x)
1 a jaz   #выводит -7.93

Как бы 1'ci a'nı jaz

Forth покурите. Там что-то, на первый взгляд, близкое по идее.

Если ввести правило, что идентификаторы либо состоят из одной строчной буквы, либо начинаются и кончаются на заглавную, то пробелы будут не нужны, вроде:

a1 2 3 4;           # ";" — это оператор присваивания
k1;
qka>>k++k5<?q;      # цикл = рекурсивной функции
q

Что эквивалентно

a={1,2,3,4}
for k=1,4 do print(a[k])end

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

Это в сторону всяких brainfuck'ов.

Цитата: maratique от июля 21, 2021, 15:08
Говорят, самым естественным является порядок слов SOV.

Кто говорит? Турки и японцы?

Цитата: злой от августа 27, 2021, 09:16
Это в сторону всяких brainfuck'ов.

Brainfuck наоборот длинный. А мне надо без лишней писанины. А то все существующие языки убогие.

ЦитироватьКто говорит? Турки и японцы?

SOV   "She him loves."   45%   
SVO   "She loves him."   42%   
VSO   "Loves she him."   9%   
VOS   "Loves him she."   3%   
OVS   "Him loves she."   1%   
OSV   "Him she loves."   0%      Warao

Там в пределах статистической погрешности разница. Вот то, что номинативный строй победил эргативный, можно констатировать.

Цитата: maratique от августа 27, 2021, 09:40
SOV   "She him loves."   45%   
SVO   "She loves him."   42%   
VSO   "Loves she him."   9%   
VOS   "Loves him she."   3%   
OVS   "Him loves she."   1%   
OSV   "Him she loves."   0%      Warao

Это говорит только против вашего утверждения. Если SOV очевидно самый удобный, откуда 55% языков с другим строем?

qka>>k++k5<?q; можно упростить до
qka>>k5+<q; можно упростить до
ka>>k5+<:

Короче можно for k=1,4 do print(a[k]) end записать в виде
— никакой лишней писанины. Вот это я понимаю язык

Цитата: злой от августа 27, 2021, 12:21
Там в пределах статистической погрешности разница. Вот то, что номинативный строй победил эргативный, можно констатировать.

А разве у них когда-то была борьба?

Цитата: злой от августа 27, 2021, 12:21Вот то, что номинативный строй победил эргативный, можно констатировать.

Это SVO или OVS?

Цитата: Bhudh от августа 27, 2021, 18:07

Цитата: злой от августа 27, 2021, 12:21Вот то, что номинативный строй победил эргативный, можно констатировать.

Это SVO или OVS?

Я так понял, это как тёплое и сладкое. Эргативный способ обозначения агенса и пациента, в теории, мог бы сочетаться с любым порядком слов. Как на практике, не знаю, врать не буду.

Цитата: kemerover от августа 27, 2021, 14:12

Цитата: злой от августа 27, 2021, 12:21
Там в пределах статистической погрешности разница. Вот то, что номинативный строй победил эргативный, можно констатировать.

А разве у них когда-то была борьба?

Если в процентах сравнивать. Хотя вот хинди, если мне не изменяет память, приобрёл какие-то черты эргативного языка, в то время как древнеиндийский язык, из которого он произошёл, был номинативным. Так что какие-то процессы идут.

Цитата: злой от августа 27, 2021, 18:17Я так понял, это как тёплое и сладкое.

Я про порядок в самой цитате спросил.

Цитата: Python от ноября  2, 2018, 00:21
Как сделать нечто подобное в языке типа JS, где yield/сопрограммы/континуации или другие подобные средства отсутствуют — только return?

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

Притом сам Хьюитт не оценил идею

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

Цитата: Bhudh от августа 27, 2021, 19:03

Цитата: злой от августа 27, 2021, 18:17Я так понял, это как тёплое и сладкое.

Я про порядок в самой цитате спросил.

А, теперь понятно. Это SVO. Аналогичные языковые казусы встречаются, когда рассказывают как одна компания с несклоняемым буржуйским названием купила другую такую же буржуйскую компанию.

Вот поэтому пассив пока и не умрёт. «XXX была куплена YYY».
Правда, с «XXX была продана YYY» уже будут проблемы, хоть и другого рода.

Оказывается, в последнее время стали появляться такие вот ЯПы без лишней писанины — так называемые golfing languages. А сам процесс написания чрезвычайно лаконичного кода называется code golf(ing).

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

Лучшее, что я нашел — это язык программирования CJAM: http://cjam.aditsu.net/ — он реально рабочий, на нем можно писать консольки. Но в нем есть явные недостатки:

• Зачем-то среди постфиксных операций затесалась одна инфиксная.
• Доступ к элементу массива и вызов функции имеют разный формат.
• Символы [, ], {, } идут парами и поэтому половина их зря пропадает

А так в целом отлично. Особенно удобно писать функции — не нужны формальные параметры, ибо ты уже знаешь, что они на стеке. Например, функция, суммирующая два своих аргумента будет выглядеть просто
0$2$+

В этом языке пробелы нужны разве что между числами. И поэтому там невозможны произвольные многобуквенные имена переменных и функций. А если сделать такой синтаксис, чтобы доступ к полю массива был как вызов функции, то возможен любой идентификатор — просто введем таблицу L для библиотечных сторонних функций, и таблицу l для своих локальных нужд:

'BesselJ''math'L — функция BesselJ из библиотеки math
'sum_of_squares'l — пользовательская переменная sum_of_squares

Во-первых, буква l — первая буква слова library - библиотека, а во-вторых, из-за сходства с цифрой 1 она редко используется как идентификатор.

Цитата: maratique от сентября  7, 2021, 18:45
Оказывается, в последнее время стали появляться такие вот ЯПы без лишней писанины — так называемые golfing languages. А сам процесс написания чрезвычайно лаконичного кода называется code golf(ing).

Вроде как код-гольфинг был популярен лет 7 назад, сейчас как-то меньше о нём слышно.

Цитата: kemerover от сентября  7, 2021, 19:34

Цитата: maratique от сентября  7, 2021, 18:45
Оказывается, в последнее время стали появляться такие вот ЯПы без лишней писанины — так называемые golfing languages. А сам процесс написания чрезвычайно лаконичного кода называется code golf(ing).

Вроде как код-гольфинг был популярен лет 7 назад, сейчас как-то меньше о нём слышно.

Так и ничего полноценного не создали. Забрасывали на полдороге.

Цитата: kemerover от сентября  7, 2021, 19:34

Цитата: maratique от сентября  7, 2021, 18:45
Оказывается, в последнее время стали появляться такие вот ЯПы без лишней писанины — так называемые golfing languages. А сам процесс написания чрезвычайно лаконичного кода называется code golf(ing).

Вроде как код-гольфинг был популярен лет 7 назад, сейчас как-то меньше о нём слышно.

Это прикольно до того момента, когда тебе приходится читать ранее написанную программу. Как говорят, машина поймёт любую программу, у которой правильный синтаксис, писать программы нужно так, чтобы их в состоянии был понять человек. Вдобавок, там где серьёзная разработка, нередко применяют кросс-чек, другой человек вычитывает твою программу. Одним словом, писать программу нужно так, чтобы её можно было читать.

Цитата: maratique от сентября  7, 2021, 19:47
Так и ничего полноценного не создали. Забрасывали на полдороге.

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

Насчет того, что такие языки трудновоспринимаемы — так это спорно. Там просто в примерах, возможно, сама идея решения очень экономная и нетривиальная. А если решать по-простому, то ничем не хуже обычных языков. Если я например напишу цикл алгоритма Флойда-Уоршелла на Си и на абстрактном гольф-языке, то чем сложнее-то?

for (int k = 0; k < 26; k++)
      for (int i = 0; i < 26; i++)
        for (int j = 0; j < 26; j++)
          b[i ][j] = min(b[i ][j], b[i ][k] + b[k][j]);



fk26
  fi26
    fj26
      ijb ijb ikbkjb+ min;

Цитата: maratique от сентября  7, 2021, 18:45Доступ к элементу массива и вызов функции имеют разный формат.

Так это в большинстве языков так. Я даже и не вспомню, в каких он одинаковый.

Цитата: Bhudh от сентября  7, 2021, 21:15

Цитата: maratique от сентября  7, 2021, 18:45Доступ к элементу массива и вызов функции имеют разный формат.

Так это в большинстве языков так. Я даже и не вспомню, в каких он одинаковый.

Lisp  :yes:
Брат-антиблизнец форта, в каком-то смысле.

Этот вообще ни в одну категорию не лезет. Нет у него ни функций, ни массивов, одни кортежи...

Цитата: Bhudh от сентября  7, 2021, 21:15

Цитата: maratique от сентября  7, 2021, 18:45Доступ к элементу массива и вызов функции имеют разный формат.

Так это в большинстве языков так. Я даже и не вспомню, в каких он одинаковый.

Фортран, Кобол, ПЛ/1...

Цитата: Bhudh от сентября  7, 2021, 21:21
Этот вообще ни в одну категорию не лезет. Нет у него ни функций, ни массивов, одни кортежи...

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

Цитата: Andrey Lukyanov от сентября  7, 2021, 21:25Кобол

А что Вы называете массивами в Коболе? :???

Хаскелл, кстати.

Цитата: Bhudh от сентября  7, 2021, 21:31

Цитата: Andrey Lukyanov от сентября  7, 2021, 21:25Кобол

А что Вы называете массивами в Коболе? :???

Там они определяются конструкциями типа

Цитировать
01 WEEK-TABLE.
      05 DAY-NAME OCCURS 7 TIMES PIC X(9) .

Но функции, как оказалось, там вызываются по-другому, так что Кобол вычёркиваем.

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

А ведь массив — это просто целочисленная функция и все. Например, следующие равносильны:

int f={1,2,3}

int f(int i){
  switch(i){
  case 0:return 1;
  case 1:return 2;
  case 2:return 3;
  }
}

А квадратные скобки можно было как-нибудь поумнее применить

Цитата: maratique от сентября  7, 2021, 21:58
Это вообще тупо, что в функциях и массивах используются разные виды скобок. Ладно еще, если бы можно было иметь одноименные массив и функцию. Но нет, нельзя в Си.

Я думаю, что разные типы скобок () [] {} используются исключительно для удобства программиста, чтобы сразу было понятно, где что.

ЦитироватьЯ думаю, что разные типы скобок () [] {} используются исключительно для удобства программиста, чтобы сразу было понятно, где что.

Но это расточительно.

Более того, если запретить вложенные конструкции, то необязательно иметь парные скобки, можно иметь одинарные разграничители —  / или \ или | или кавычки.
А так как в Си при инициализации массива надо писать запятые, то можно и вложенные:

int matrix[][] = ||1,2,3|,|4,5,6|,|7,8,9||

Можно проще: int matrix[3][3] = 1,2,3,4,5,6,7,8,9;.

Цитата: maratique от августа 27, 2021, 09:40
А мне надо без лишней писанины. А то все существующие языки убогие.

Цитата: maratique от августа 27, 2021, 07:45
Знаете какой-нибудь такой же минималистичный упоротый язык?

Кажется, Вы созрели для APL (https://en.wikipedia.org/wiki/APL_(programming_language)). При условии, что не боитесь языков с экзотической письменностью. Если боитесь — наверно, лучше что-то из APL-производных с обычным ascii-набором символов, напр., J. (https://en.wikipedia.org/wiki/J_(programming_language))

Цитата: Bhudh от сентября  7, 2021, 23:06
Можно проще: int matrix[3][3] = 1,2,3,4,5,6,7,8,9;.

matrix←3 3⍴⍳9

 А чем вообще языки программирования отличаются?
Мне, как человеку, покалеченному в юности ассемблером ( да и сейчас его практикующим время от времени ), ЯВУ кажутся братьями-близнецами, различающимися исключительно рукожопостью их авторов.
Ну есть Ц; прикрутили к нему классы, стал ЦПП; были до этого Паскаль и Басик - всё ж одно и тоже ( это я про процедурные языки ). А "мастерство" программиста заключается в знании конкретных глюков реализации компилятора и ключей командной строки... Ну, мне так кажется.

Цитата: Yougi от сентября  8, 2021, 11:21
А чем вообще языки программирования отличаются?

С точки зрения теории алгоритмов - математической моделью алгоритма.
3 варианта: ДМТ, частично-рекурсивная функция и исчисление предикатов.

ЯПы отличаются смыслом вот этих 33-х товарищей:
32   
33   !
34   "
35   #
36   $
37   %
38   &
39   '
40   (
41   )
42   *
43   +
44   ,
45   -
46   .
47   /
58   :
59   ;
60   <
61   =
62   >
63   ?
64   @
91   [
92   \
93   ]
94   ^
95   _
96   `
123   {
124   |
125   }
126   ~

ЦитироватьЯВУ кажутся братьями-близнецами, различающимися исключительно рукожопостью их авторов.

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

Цитата: maratique от сентября  8, 2021, 12:20Для себя и близких у них годные языки, а если что-то распиарить, то только избыточное и неочевидное гавно.

А если "для себя и близких" вообще ничего нет,

Цитата: maratique от августа 27, 2021, 09:40то все существующие языки убогие

:yes: Это не заговор, это психология. К чему привык, то и нравится.

Цитата: Yougi от сентября  8, 2021, 11:21
А чем вообще языки программирования отличаются?
Мне, как человеку, покалеченному в юности ассемблером ( да и сейчас его практикующим время от времени ), ЯВУ кажутся братьями-близнецами, различающимися исключительно рукожопостью их авторов.
Ну есть Ц; прикрутили к нему классы, стал ЦПП; были до этого Паскаль и Басик - всё ж одно и тоже ( это я про процедурные языки ). А "мастерство" программиста заключается в знании конкретных глюков реализации компилятора и ключей командной строки... Ну, мне так кажется.

На мой взгляд, есть три разных типа языков программирования:
1. Все вот эти Си, Фортраны, JS-ы, Питоны и прочие;
2. Лямбда (Лисп и прочие);
3. Похожие на то, что выдаёт интерпретатор (Форт и т.п.)

Ну есть ещё собственно ассемблер. Мне в своё время довелось поработать с ассемблером MIPS'а. RISC-архитектура, все команды занимают один такт, только скачки - два такта. Big endian, численные значения читаются невооружённым глазом. После MIPS'а ассемблер IA-32 - это боль. Возможно поэтому ничего большего, чем пару простеньких поделий я на последнем не создал.

А есть, интересно, ЯПы, в которых оператор выбора switch case выполнен в виде массива кодов? Например:
вместо
switch(n)
{
case 1: n++;break;
case 2: n+=2;break;
case 3: n+=3;break;
}
просто:
{n++,n+=2,n+=3}[n] — то есть тупо n-ый код из массива

Так и if else не нужен — просто условимся, что true = 1, false = 2 и вместо
if(condition)op1;else op2;
пишем просто{op1, op2}[condition]

В JavaScript это позволяет просто синтаксис массивов и тот факт, что там функции суть граждане 1-го класса.
[n => ++n, n => n += 2,n => n += 3][n]();
[op1, op2][+condition]()

Цитата: Bhudh от ноября 10, 2021, 14:09
В JavaScript это позволяет просто синтаксис массивов и тот факт, что там функции суть граждане 1-го класса.

Код (ES5) Выделить Развернуть

[n => ++n, n => n += 2,n => n += 3][n]();
[op1, op2][+condition]()

Зачем здесь изменяющие операторы в лямбдах, если параметры-числа передаются по значению?
(Вернее, по ссылке на объект, но поскольку объект-число все равно immutable, изменение значения формального параметра никак не отражается на фактическом параметре).

Цитата: Python от ноября 10, 2021, 15:03Зачем здесь изменяющие операторы в лямбдах, если параметры-числа передаются по значению?

Именно для того, чтобы они возвращали изменённое значение иммутабельного аргумента. Это же стрелочные функции, в них не нужен return при отсутствии фигурных скобок.
До ES5 это выглядит так:
[ function(n){ return ++n; }, function(n){ n += 2; }, function(n){ n += 3; } ][n](n);

Цитата: Bhudh от ноября 10, 2021, 15:06

Цитата: Python от ноября 10, 2021, 15:03Зачем здесь изменяющие операторы в лямбдах, если параметры-числа передаются по значению?

Именно для того, чтобы они возвращали изменённое значение иммутабельного аргумента. Это же стрелочные функции, в них не нужен return при отсутствии фигурных скобок.
До ES5 это выглядит так:

Код (ES5) Выделить Развернуть

[ function(n){ return ++n; }, function(n){ n += 2; }, function(n){ n += 3; } ][n]();

Так этот код вообще ничего, фактически, не делает. В лямбдах там хотя бы неявным образом происходит return, а в старом синтаксисе изменяется значение только формального параметра (т.е., фактически, локальной переменной, в которую подставляется значение фактического параметра — но не наоборот, значение из формального параметра в фактический параметр не передается). К тому же, здесь формальный параметр опущен — вместо него подставляется undefined, что делает вычисления еще более бессмысленными.

Вот так это работает в node:

> n=1
1
> [ function(n){ return ++n; }, function(n){ n += 2; }, function(n){ n += 3; } ][n]();
undefined
> n
1
> n=0
0
> [ function(n){ return ++n; }, function(n){ n += 2; }, function(n){ n += 3; } ][n]();
NaN
> n
0
>


Цитата: Python от ноября 10, 2021, 15:19К тому же, здесь формальный параметр опущен

Я уже исправил.

Цитата: Bhudh от ноября 10, 2021, 15:24

Цитата: Python от ноября 10, 2021, 15:19К тому же, здесь формальный параметр опущен

Я уже исправил.

На результат влияет, на сам фактический параметр — нет:
> n
0
> [ function(n){ return ++n; }, function(n){ n += 2; }, function(n){ n += 3; } ][n](n);
1
> n
0
>

Исправить несложно:

> n = 0
0
> [() => ++n, () => n += 2,() => n += 3][n]();
1
> n
1


А если сразу спроектировать язык по этому замыслу, то все гораздо изящнее будет:

if(a<b)
   {b=3;a=sin(b);}
else
   {a=5,b=cos(a);}
Станет
ab<{b3:ab'sin':,a5:ba'cos':}

Кавычки нужны, чтобы отличить переменную sin, от трех переменных s, i, n.
А если основным функциям дать однобуквенные имена типа sin = S, cos = C, tan = T, exp = E, log = L, то совсем классно:
ab<{b3:abS:,a5:baC:}

Не, тупо гнаться за компактностью -- гиблое дело. Это не намного длиннее, и гораздо понятнее:
a,b = (sin(b), 3) if a<b else (5, cos(a))

Это ж тернарный оператор:
a, b = a < b ? (sin(b), 3) : (5, cos(a))

Цитата: Upliner от ноября 10, 2021, 16:33
Исправить несложно:

Код Выделить Развернуть


> n = 0
0
> [() => ++n, () => n += 2,() => n += 3][n]();
1
> n
1


Цивилизованнее (т.е., ближе к канонам ФП) было бы так, ІМНО:

n=[n=>n+1, n=>n+2, n=>n+3][n](n)


Я когда еще начинал только изучать программирование, сразу почувствовал, что ЯПы несовершенны. Но про себя, наверное, думал, что это я так от незнания думаю, а сами создатели языков — умнющие мужики: если бы было можно попроще сделать, то сделали бы.
Но чем больше я узнавал, тем больше я в этом убеждался. А ведь если подумать немного, то вот факторы, способствовавшие несовершенству:

1)Европейское мышление авторов большинства популярных ЯПов, обусловленное грамматикой их родных языков. И принятой математической нотацией(на 99% европейской)

2)Механизм популяризации, когда популярность набирает не самый изысканный и идейный, а самый блатной. Например, наверняка, богатство фирмы, где работал Риччи, стало причиной распространения Unix'а и Си.
А дальше уже работал принцип преимущества, когда самый успешный захватывает всю землю своими потомками: Си++, Java, C#...

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

Например, вместо европоцентристского Вольфрамовского
solve[{2x+8y-z=4,x-3y+6z=0,7x+5y+2z=3},{x,y,z}]
можно было бы написать
2 8 -1 4 1 -3 6 0 7 5 2 3 3L
Здесь L — унарная функция, значение которой для 3 будет 3*3+3 = 12-арной функцией, принимающей коэффициенты системы.

Или например функция A — addition, сложение. Вместо
1+2+3+4+5+a+b+c
можно написать
1 2 3 4 5abc8A — арность как последний аргумент.

Или можно для ходовых функций договориться, что sin = S, cos = C, tan = T. Тогда, используя особую величину-нечисло _, можно выразить и аркфункции:
sin(x) = xS, но sin(_) = _S уже не число, а обратная функция. Поэтому
arcsin(x) = x_S.

Символов
!"#$%&'()*+,-./0123456789:;<=>@?
ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`{|}~
с учетом полиморфизма и неограниченной гибкости в определении функций хватило бы на огромное кол-во математических и алгоритмических операций.

Цитата: maratique от ноября 12, 2021, 20:16
можно было бы написать
2 8 -1 4 1 -3 6 0 7 5 2 3 3L

Нечитаемую хрень. Вы чисто покритиковать, или свой ЯП пишете?

Зато не надо Shift'ами набирать всякие скобки и знаки препинания. Для того, кто много этим занимается, потом уже все очень понятно становится и его эта избыточность бесит.

ЦитироватьНечитаемую хрень. Вы чисто покритиковать, или свой ЯП пишете?

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

Говорят же, что художниктар — не тот, кто умеет рисовать, а тот, кто умеет видеть. Если он увидел, что-то великолепное и захотел это изобразить, то как-нибудь уж нарисует. Хотя рисовать грех или не грех, не понятно.

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

То есть, хотите сказать, ЯПы намеренно такие избыточные и негибкие, чтобы человеку трудно было ошибиться?
Но тогда, хотя бы те ЯПы, которые предназначены для самого компьютера — байт-коды, например, — они-то хотя бы изысканны и гибки?

Главное же не синтаксис, а возможности.

Цитата: maratique от ноября 12, 2021, 20:43
То есть, хотите сказать, ЯПы намеренно такие избыточные и негибкие, чтобы человеку трудно было ошибиться?

Это один из критериев, который учитывается при разработке ЯП, да. Самые наглядные примеры негибкости ради блага человечества это весь язык Go и borrow checker в Rust.

Цитата: maratique от ноября 12, 2021, 20:43
Но тогда, хотя бы те ЯПы, которые предназначены для самого компьютера — байт-коды, например, — они-то хотя бы изысканны и гибки?

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

В чем негибок Го?

Цитата: Karakurt от ноября 12, 2021, 20:50
Главное же не синтаксис, а возможности.

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

Кушающий.

Цитата: Karakurt от ноября 12, 2021, 21:07
Кушающий.

Вот именно. Приходится прибегнуть к совсем другой конструкции. Например, приходится писать cosh(x), хотя можно и cos(i*x)

Это разве так важно?

Цитата: maratique от ноября 12, 2021, 21:05Например, можно сказать пьющий человек, но нельзя едящий человек.

Кто Вам это сказал⁈ :o Это абсолютно нормативное причастие от есть.

Цитата: Karakurt от ноября 12, 2021, 20:54
В чем негибок Го?

Нету наследования, дженериков, исключений, нулевых типов; даже тернарного оператора нету. Это первое, что в голову пришло.

Цитата: kemerover от ноября 12, 2021, 21:21

Цитата: Karakurt от ноября 12, 2021, 20:54
В чем негибок Го?

Нету наследования, дженериков, исключений, нулевых типов; даже тернарного оператора нету. Это первое, что в голову пришло.

И без этого нормально. Просто непривычно.

Цитата: kemerover от ноября 12, 2021, 21:21Нету наследования, дженериков, исключений, нулевых типов; даже тернарного оператора нету. Это первое, что в голову пришло.

Ну, анонимки довольно неплохо заменяют наследование, вот в js до 15 года наследование было совсем уж костыльное, квази-исключения в виде panic-recover тоже есть, нулевой тип никто не мешает сделать из struct{}. Вот генериков и нормальных коллекций не хватает, это да.

Цитата: Upliner от ноября 12, 2021, 21:53
Ну, анонимки довольно неплохо заменяют наследование,

А не встраивание? Сет из мапы делается.

Цитата: Karakurt от ноября 12, 2021, 21:58

Цитата: Upliner от ноября 12, 2021, 21:53
Ну, анонимки довольно неплохо заменяют наследование,

А не встраивание? Сет из мапы делается.

Вроде как анонимные поля в go -- это не встраивание.
Сет из мапы -- это да, типа map[string]struct{}. Кстати, во втором шарпе нельзя было сделать Dictionary<string,void>, тоже приходилось для этого объявлять пустой struct MyVoid {}. В третьем шарпе появился Set, поэтому такие фокусы стали не нужны.

Это все мелочи, ведь фишка го в конкурентности.

Цитата: maratique от ноября 12, 2021, 20:16
2)Механизм популяризации, когда популярность набирает не самый изысканный и идейный, а самый блатной. Например, наверняка, богатство фирмы, где работал Риччи, стало причиной распространения Unix'а и Си.

Не-не-не. Попробуйте представить себе ОС, написанные на Паскале или Фортране. Страшный сон.

Так Си, Фортран и Паскаль однотипны. Просто в Си меньше писанины, чем в Паскале. А Фортран ничем не хуже Си. Даже лучше.

Да, чего такого страшного в Паскале? Begin-End вместо фигурных скобок?

Паскаль - для поделок школьников и студентов.

Ну правда есть одна крутая фишка в Си — оператор запятая. Благодаря ему можно не писать фигурные скобки:
if(a)
{
   b=c;
   d=e;
}
Равносильно
if(a)b=c,d=e;
Я б с удовольствием писал на Фортране 77, если бы его компиляторы были так же доступны, как gcc.

Цитата: злой от ноября 12, 2021, 22:26
Паскаль - для поделок школьников и студентов.

Но чисто с функциональной точки зрения какие у него недостатки по сравнению с сями?

Цитата: maratique от ноября 12, 2021, 22:28Ну правда есть одна крутая фишка в Си — оператор запятая.

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

Цитата: Upliner от ноября 12, 2021, 22:28

Цитата: злой от ноября 12, 2021, 22:26
Паскаль - для поделок школьников и студентов.

Но чисто с функциональной точки зрения какие у него недостатки по сравнению с сями?

Арифметика указателей, управление памятью - в Сях есть.

Цитата: злой от ноября 12, 2021, 22:30Арифметика указателей, управление памятью - в Сях есть.

В Паскале тоже.

Цитата: Upliner от ноября 12, 2021, 22:28
Сейчас никто так не пишет и считается дурным тоном, хуже goto, который всё-таки иногда допускают использовать для обработки ошибок в отсуствие исключений.

Я своими глазами видел goto во вполне серьёзных программах. Стереотип про goto - это примерно такая же дичайшей пережиток, как тот, чтт функция должна умещаться в 25 строк. Понятно, что не нужно пользоваться goto, потому что лень разбить на функции и расчесать спагетти-код, но там, где goto уместно, пусть все критики идут лесом.

Цитата: Upliner от ноября 12, 2021, 22:34

Цитата: злой от ноября 12, 2021, 22:30Арифметика указателей, управление памятью - в Сях есть.

В Паскале тоже.

Хотя да, арифметика не совсем кошерная -- в некоторых случаях приходилось кастовать указатель в Longint и там уже выполнять все манипуляции.

Цитата: Upliner от ноября 12, 2021, 22:34

Цитата: злой от ноября 12, 2021, 22:30Арифметика указателей, управление памятью - в Сях есть.

В Паскале тоже.

В классическом Паскале аналогов malloc/free нету, там вроде только куча. В Дельфях вроде всё есть, действительно. Как-то это мимо меня прошло.

Всё равно, почему-то программы серьёзнее электронного склада на Паскале/Delphi писали крайне редко, даже в эпоху его лютой популярности.

Цитата: злой от ноября 12, 2021, 22:47В классическом Паскале аналогов malloc/free нету, там вроде только куча. В Дельфях вроде всё есть, действительно. Как-то это мимо меня прошло.

Я начинал с Borland Pascal 6, там уже были GetMem и FreeMem.
В любом случае, к языку как таковому это отношения не имеет, это фича стандартной библиотеки.

Цитата: злой от ноября 12, 2021, 22:35
Я своими глазами видел goto во вполне серьёзных программах. Стереотип про goto - это примерно такая же дичайшей пережиток, как тот, чтт функция должна умещаться в 25 строк. Понятно, что не нужно пользоваться goto, потому что лень разбить на функции и расчесать спагетти-код, но там, где goto уместно, пусть все критики идут лесом.

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

Что же до ограничения в 25 строк – не вижу ничего плохого в этом. Если программист не может функцию уместить в такое число строк – с огромной вероятностью его мысль неправильна, он не вынес какие-то структурные части, нарушает DRY, смешивает уровни абстракции и так далее. Если же он и не делает всего этого, по счастливой случайности – другой программист сделает это за него, не разобравшись в длинном непонятном коде.

Цитата: Michael F от ноября 12, 2021, 23:23

Цитата: злой от ноября 12, 2021, 22:35
Я своими глазами видел goto во вполне серьёзных программах. Стереотип про goto - это примерно такая же дичайшей пережиток, как тот, чтт функция должна умещаться в 25 строк. Понятно, что не нужно пользоваться goto, потому что лень разбить на функции и расчесать спагетти-код, но там, где goto уместно, пусть все критики идут лесом.

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

Что же до ограничения в 25 строк – не вижу ничего плохого в этом. Если программист не может функцию уместить в такое число строк – с огромной вероятностью его мысль неправильна, он не вынес какие-то структурные части, нарушает DRY, смешивает уровни абстракции и так далее. Если же он и не делает всего этого, по счастливой случайности – другой программист сделает это за него, не разобравшись в длинном непонятном коде.

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

Я эту мантру про 25 строк лет 15 назад впервые услышал (про goto вообще в школе). Это что-то сродни религиозным догмам. Мне интересно, люди которые тиражируют подобные тезисы - сколько строк практически работающего в production кода они написали? Про 25 строк - это банальное ограничение древних терминалов, когда на экране помещалось ровно 25 строк, и функцию нужно было видеть целиком. Сейчас уже давно нет тех деревянных терминалов. Когда мне пришлось заниматься практическим программированием, у меня в голове какое-то время эта мантра про 25 строк гвоздём сидела в голове, и я любой ценой пытался функции в 30-35 строк ужать до 25, потом понял, насколько это глупое занятие. Как предложение выражает законченную мысль, так функция должна выражать законченное действие. Если для законченного действия нужно 40-45 строк, не надо заниматься ерундой и выдумывать, как там её располовинить, потому что какой-то там дядя, сто лет назад, когда у него на экране помещалось 25 строк, что-то написал в книжке по этому поводу.

Насчёт goto - про привязку к парадигме и прочее. Основной критерий хорошей программы - её работоспособность. Дополнительные - читаемость, возможность переиспользования кода, лёгкость в отладке и прочее, но уж точно не соответствие парадигмам. Можно всю жизнь разводить философию о парадигмах, а реального кода написать два поделия и "Hello, World" на десяти языках, конечно же, в строгом соответствии с парадигмами. Запрет goto в среде программистов сроден религиозному запрету на поедание свинины у иудеев и мусульман.

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

Про 25 строк кода впервые слышу.
Три немаленьких поделия в дельфях написала. 2 в качестве хоздоговорных работ, третье в 2020 годом в качестве дипломной работы в магистратуре.
По-моему, у меня не более 25 строк только в сортировке "пузырёк"  ;D

а встроенных нет?

Цитата: Upliner от ноября 12, 2021, 22:28

Цитата: злой от ноября 12, 2021, 22:26
Паскаль - для поделок школьников и студентов.

Но чисто с функциональной точки зрения какие у него недостатки по сравнению с сями?

http://www.lysator.liu.se/c/bwk-on-pascal.html

Сейчас ситуация, конечно, иная, но это про это, почему Паскаль так и не сыскал успеха в реальном программировании, ну а потом поезд ушёл.

Кстати, кто-нибудь тут разделяет взгляды Н. Вирта? Знаком с Компонентным Паскалем и т.д.?
Не для спора, просто интересно.

Когда прочитал насчет устаревшести 25 строк кода в функции, то поперхнулся. Ну то есть, конечно устарело, ведь сегодня функция должна содержать в идеале одну строку, а две уже много. Но чтоб больше 25?! Думаю, не прошли бы ваши коммиты ревью через меня. ;D

Кстати, лучше переменные кириллицей писать, а то иногда не понятно где что.

Я так писал на JS, но, к сожалению, кириллических аналогов ключевым словам в нём нет, макросов тоже, а смешение некузяво выглядит :(.

Цитата: maratique от ноября 12, 2021, 22:28
Я б с удовольствием писал на Фортране 77, если бы его компиляторы были так же доступны, как gcc.

В чем сложность? Гнушный фортран (https://gcc.gnu.org/fortran/) можно установить вместе с gcc. Или еще есть Watcom FORTRAN в составе (wiki/ru) Open_Watcom (https://ru.wikipedia.org/wiki/Open_Watcom) (впрочем, он больше не развивается).

Цитата: злой от ноября 13, 2021, 10:59
Запрет goto в среде программистов сроден религиозному запрету на поедание свинины у иудеев и мусульман.

:+1:
Проблема плохого кода — в плохом коде. Даже не имея goto в своем распоряжении и делая все функции максимально краткими, нет ничего проще, чем слепить достаточно большой кусок кода в макаронное месиво — разбросав логически единую последовательность действий по разным функциям в разных концах программ. Код в стиле «много мелких функций» неудобочитаем: заголовков в нем оказывается больше, чем полезных действий, названия функций становятся избыточно длинными, и никакая конвенция именования не гарантирует, что функция будут делать именно то, что написано в ее названии.

Это да. Самое плохое то, что большинство кода таким и есть.

Все думаю, что эта сфера какая-то неправильная, потому что писать код надоедает задолго до того, как человек научится его более менее сносно писать.

Выходит, пишут код в основном новички или те, кому вообще пофиг.

И что с этим поделать я даже не представляю.

Цитата: RawonaM от ноября 13, 2021, 14:28Ну то есть, конечно устарело, ведь сегодня функция должна содержать в идеале одну строку, а две уже много. Но чтоб больше 25?! Думаю, не прошли бы ваши коммиты ревью через меня. ;D

Хотелось бы всё-таки посмотреть на реальный проект с такими функциями. При желании конечно и сам могу писать в две строчки, но выглядеть это будет не очень:
def calc_group_weights(groups, co):
    z = list(zip(*((g, co2) for g, co2 in ((g, vg_full_to_avg(g)) for g in groups) if co2 is not None)))
    return list(zip([vg_full_to_dict(group) for group in z[0]], barycentric_weight_calc(z[1], co)))

В конце концов задолбался при каждом изменении в этом копаться и переписал в более понятном виде:

def calc_group_weights(groups, co):
    groups2 = []
    coords = []
    for g in groups:
        co2 = vg_full_to_avg(g)
        if co2 is not None:
            groups2.append(g)
            coords.append(co2)
    return [(vg_full_to_dict(g), weight) for g, weight in zip(groups2, barycentric_weight_calc(coords, co))]


Как минимум не хватает строчекweights = barycentric_weight_calc(coords, co)
zipped_weights = zip(groups2, weights)
result = [(vg_full_to_dict(g), weight) for g, weight in zipped_weights]

И все их в отдельную функцию. ;D

Я уже увидел где лоханулся. List comprehension тут вообще не нужен. Хотя и первый вариант можно было бы сделать чуть понятнее, хотя бы если вместо z = list(zip(*... написал бы groups2, coords = tuple(zip(*

Цитата: Upliner от декабря 10, 2021, 01:45
Я уже увидел где лоханулся.

Недавно узнал, что в Питоне байт-код для list comprehension идентичен коду для цикла с append-ом. Так что я зря переживал, что с циклами будет медленнее работать.

Цитата: RawonaM от ноября 13, 2021, 14:28сегодня функция должна содержать в идеале одну строку, а две уже много.

Кстати, в этой связи бесит, что pep-8 требует отделять функции верхнего уровня двумя пустыми строчками. Если в файле куча однострочных функций, то в нём пустого пространства столько же, сколько и кода, и количество строк для реализации нужного функционала по сравнению с одной большой функцией тупо утраивается.
Хорошо хоть для методов классов разрешили обходиться одной пустой строчкой.

Меня вообще раздражает ASCII-документация в коде. Когда уже UI/UX вокруг исходников займутся зумеры? Должна быть нормальная интеграция графиков, табличек, маркдауна, тиктоков в процесс написания кода.

Цитата: kemerover от мая  1, 2022, 18:18
Меня вообще раздражает ASCII-документация в коде. Когда уже UI/UX вокруг исходников займутся зумеры? Должна быть нормальная интеграция графиков, табличек, маркдауна, тиктоков в процесс написания кода.

А чем Jupyter в этом плане не устраивает?

Цитата: Upliner от мая  1, 2022, 18:20А чем Jupyter в этом плане не устраивает?

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

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

Цитата: Upliner от мая  1, 2022, 18:59
Понятно подо что заточен, но теоретически ничто не мешает просто использовать .ipynb файлы вместо обычных исходников.

Ничто не мешает и в блокноте писать, но зачем... Хочется просто нормальной среды разработки для 2к22.

Цитата: Upliner от мая  1, 2022, 18:59
Но я лично всё равно буду по старинке документировать в ASCII

Вот-вот. Поэтому я и жду, когда к власти придут зумеры.

Цитата: kemerover от мая  1, 2022, 19:11Хочется просто нормальной среды разработки для 2к22.

Нормального четверга тоже хочется. И вообще...

Цитата: kemerover от мая  1, 2022, 19:11Вот-вот. Поэтому я и жду, когда к власти придут зумеры.

Чувствую, это будет нечто монструозное, которым только из-под палки пользоваться будут...

Электрон?

Цитата: Upliner от мая  1, 2022, 20:49Чувствую, это будет нечто монструозное, которым только из-под палки пользоваться будут...

Это всё где-то кусками реализовано так или иначе, но нету общепринятых стандартов и практик, чтобы это было чем-то юзабельным.

Цитата: Bhudh от мая  1, 2022, 20:51
Электрон?

VS Code и так на Электроне, самый популярный тул для кодинга.

Цитата: From_Odessa от октября 31, 2018, 20:21ХТМЛ - не язык программирования, но его упомяну тоже.

Цитата: RawonaM от июля 18, 2022, 09:01Я решил закрыть Lingvowiki, в конце месяца она уйдет из интернета, если кому-то еще что-то оттуда надо, то выкачивайте.

Каюсь, прокрастинатор я.

Хотел для обучения  HTML Living Standard использовать LingvoWiki в качестве черновика для обучения (https://lingvoforum.net/index.php/topic,84226.0.html#:~:text=%23-,12,-29%2D05%2D2022). Но если не там, то где можно потренироваться? Википедия тоже ввела какой-то упрощённый режим правки, который мне кажется сложнее прямого доступа к веб-странице.

Цитата: Rusiok от июля 18, 2022, 10:11Хотел для обучения  HTML Living Standard использовать LingvoWiki в качестве черновика для обучения. Но если не там, то где можно потренироваться? Википедия тоже ввела какой-то упрощённый режим правки, который мне кажется сложнее прямого доступа к веб-странице.

Банально https://jsfiddle.net/ ?

Слово Rustacean внезапно оказалось труднопереводимым. С большинством языков программирования никаких проблем:
сишник, сиплюсплюсник, пхпшник, питонщик, гошник (может означать как игрока в Го, так и программиста, в зависимости от консекста).
Но вот именно от Rust образовать такую форму не получается. Как бы вы называли программиста на Расте?
А название Let's get rusty конечно прикольное. Давайте заржавеем :)

Цитата: Upliner от марта 18, 2023, 16:15Слово Rustacean внезапно оказалось труднопереводимым.

А откуда вырос суффикс -ac-? Почему не Rustian/Rustean?

Цитата: Upliner от марта 18, 2023, 16:15Как бы вы называли программиста на Расте?

Растовщик :D.

Цитата: Bhudh от марта 18, 2023, 18:32А откуда вырос суффикс -ac-? Почему не Rustian/Rustean?

Потому что маскот Раста это рак (crustacean).

А, так это неофициальное название. Прикольно.
Но тогда ой, языковая игра вообще фигово переводится, тут надо Демурову приглашать.

Да мне-то игру слов и не нужно переводить, главное смысл. Наверное, лучше растовца ничего не придумаешь.

Цитата: Upliner от марта 18, 2023, 19:58лучше растовца ничего не придумаешь.

Растер?

Цитата: Rusiok от марта 18, 2023, 20:51

Цитата: Upliner от марта 18, 2023, 19:58лучше растовца ничего не придумаешь.

Растер?

Думал о таком варианте, но может с растром путаться.

Растаман.

Растовик же.

Цитата: kemerover от марта 18, 2023, 18:49

Цитата: Bhudh от марта 18, 2023, 18:32А откуда вырос суффикс -ac-? Почему не Rustian/Rustean?

Потому что маскот Раста это рак (crustacean).

Точнее, ракообразное.
«Растообразное»?..