Записки на полях

Refal -- уважаю. Про него слышали-то единицы. Скриптовые языки операционки, наверное, надо бы в один пункт объединить. Ну чем REXX принципиально от bash'а отличается. А про Assembler Z80 я и забыл, спасибо, что напомнили. Тоже баловался.

From:

igor-abramov.livejournal.com

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

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

From:

1) С++, Delphi, VBA, ActionScript, SQL, PHP, 1C, MBL (C-like), Lua, Squirrel
2) Erlang, C, Scheme, Haskell, Octave, Assembler (x86, 8051), TurboPascal
3) R, Assembler (Z80, MSP430), Prolog, Perl, J, Agda, Mercury

Edited Date: 2014-12-10 08:48 am (UTC)

From:

Из твоего списка меня заинтересовал Mercury. Не слышал о таком, сейчас посмотрел -- интересная штука и вполне себе живая.

From:

Ну я его только палочкой потыкал и все.
Счас вот смотрю другие ответы и вижу что не написал Tex, C# в 1 и APL, LOGO в 3.

Edited Date: 2014-12-10 10:27 am (UTC)

From:

А APL ты тоже палочкой тыкал? Там нужна довольно экзотическая палочка

From:

Да чего там экзотического?! Я такого не учуял. Ну я его, впрочем, только в историческом контексте тыкал, как предшественника J.

From:

> Да чего там экзотического?!

Не ASCII-шная

From:

Ну это ж разве экзотика... 1С вон тоже не совсем ASCII.
Вот Планкалкюль вроде экзотика, как и другие двумерные языки (сейчас не могу навскидку вспомнить)

From:

1. C++, C, python, bash, Fortran, самописные DSL
2. Basic, Scala, Haskell
3. LOGO, Gofer (тот же Хаскел, считай), SQL, R, Pascal, FORTH, Octave

кстати, на си или баше я писал меньше, чем на бейсике :)

Edited Date: 2014-12-10 09:34 am (UTC)

From:

Я, правда, не совсем (или совсем не) программист, но...

1) Fortran, C, dBASE, Pascal, Prolog, C++, Lua, SQL, bash, JS, TeX (написание пакетов, по идее, является программированием), MATLAB/Octave, Maxima.
2) Ada, LISP, Forth, Java, Delphi, R, PL/1, REXX, BASIC, Python, пара ассемблеров, ну и МК-52/61. :)
3) Haskell, Scala, C#, PHP, Julia, Erlang, VB, ALGOL (и 60, и 68), COBOL, Logo, Focal, APL, несколько DSL.

Вроде в основном все.

From:

Интересно. А можно несколько вопросов, если позволите.

- Что Вы делали на Прологе? (то есть какого рода практическую задачу)

- Я про Julia как раз на днях спрашивал (http://ushastyi.livejournal.com/246141.html), какие у Вас впечатления?

Удивительно, что уже второй человек упоминает Rexx. Видимо, OS/2 не прошла мимо многих :) Я ее тоже использовал вместо виндов (винды в эмуляторе) до выхода Windows NT 4, но необходимости писать скрипты как-то не было.

From:

igor-abramov.livejournal.com

Ну в моем то случае REXX был вовсе не на OS/2 а на VM/SP, то есть, на мейнфрейме

From:

А, вот как. Я не знал, что он в VM тоже использовался.

From:

С Прологом задач было два типа: специфические доморощенные СУБД и, в конечном счете, обработка изображений.

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

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

From:

Обработка изображений на Прологе. Хм.

Как раз в Julia основной selling point в том, что это быстрый комбайн. Остальные преимущества по сравнению с R небольшие (типы получше).

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

Кстати, как нынче студенты? Что хотят изучать и что приходится?

From:

Обработка изображений на Прологе. Хм.

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

Как раз в Julia основной selling point в том, что это быстрый комбайн. Остальные преимущества по сравнению с R небольшие (типы получше).

По сравнению с R - пожалуй, но это все равно соревнование черепах в скорости бега. Для серьезных вычислительных задач не годятся (пока?) оба.

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

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

Кстати, как нынче студенты? Что хотят изучать и что приходится?

У нас с этим попроще - мы не готовим программистов (они, конечно, получаются как побочный продукт, но все же нам не нужно объяснять, почему на 1-м курсе не изучается "самый модный в этом сезоне" язык).

Edited Date: 2014-12-10 09:41 pm (UTC)

From:

> Но в данном случае речь идет о Фортране как о вычислительном языке (и, естественно, о его современных стандартах).

Понял. Я не знаком с современным состоянием фортрана. Насколько я понимаю, R придумали именно потому, что фортран (и другие языки) не очень удобны для статистических расчетов. Впрочем, можно дать и другое объяснение: что авторы R просто не знали фортран :)

> мы не готовим программистов (они, конечно, получаются как побочный продукт)

Про побочный продукт улыбнуло :)

From:

прошу прощения, что вмешиваюсь, но не могу не сказать за Фортран.
Фортран (пусть будет Фортран77) - это компилируемый язык общего назначения с устаревшей по сегодняшним меркам "механикой" (каково жить сейчас без рекурсии, а? :) и большим числом библиотек.
R - это свистелка для вычисления среднего у массива из тысячи чисел и отрисовки графика, зато из командной строки в два действия.
я, конечно, утрирую, на R в том числе перемалывают базы с генотипами по нескольку гигабайт, но если речь идет о сложном, длинном вычислении, то это Фортран, если о быстрой обработке не очень большого объема данных стандартными инструментами, то эр, а где-то посередине (но ближе к концу с эр) сидит питон. это всего лишь баланс времени между написанием-и-поддержкой кода и исполнением кода.
нельзя не отметить в последнее время активность питонщиков, которые всё норовят затащить под питон под крики об "обширных библиотеках" и вообще без учета необходимой культуры программирования, накладных расходов на исполнение и всего такого :)

From:

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

К слову, во всех случаях, когда требуются длинные сложные вычисления, с которыми я сталкивался, использовался вовсе не Фортран, а C/C++.

Другой немаловажный аспект состоит в том, что с развитием параллельных вычислений в последнее время получают преимущество языки, для которых параллелизация проще. Скажем, на Фортране или С++ эффективно параллельную программу надо именно специально разрабатывать. А операции над массивами, которые стандартны в R, J или Julia параллелятся практически автоматом. В свое время для инмосовских транспьютеров разрабатывали специальный язык Оккам -- а теперь многие языки позволяют настолько же эффективно реализовывать параллельность.

From:

К слову, во всех случаях, когда требуются длинные сложные вычисления, с которыми я сталкивался, использовался вовсе не Фортран, а C/C++.

Это встречается. Почти всегда причина сводится к тому, что программисты обладают запредельно архаичными сведениями о Фортране, а также совершенно уверены, что писать надо на чем-то "современным" (каковым Фортран в силу первого обстоятельства не считается). Как правило, кончается это либо неэффективным кодом (если это C++), либо кодом с большим количеством ошибок (если это C).

Скажем, на Фортране или С++ эффективно параллельную программу надо именно специально разрабатывать. А операции над массивами, которые стандартны в R, J или Julia параллелятся практически автоматом.

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

From:

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

Угу, я уже освежил свои сведения, но все же "встроенные языковые конструкции, обеспечивающие организацию параллельных вычислений" были включены не в Фортран-90, а в Фортран-95 и 2008, если верить википедии. С другой стороны, операции над массивами появились в Фортране-90, а их распараллелить большого ума не надо.

From:

В 95 появился FORALL, и то его, похоже, просто забыли включить в 90 (реализован он был практически везде и раньше). WHERE был уже в 90, как и основная часть операций с массивами. Coarray действительно вошел в стандарт только в 2008 году, но это уже инструмент, аналога которого в других языках пока просто нет.

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

From:

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

> во всех случаях, когда требуются длинные сложные вычисления, с которыми я сталкивался, использовался вовсе не Фортран, а C/C++
в свою очередь сообщаю, что иногда даже в тех случаях, когда лучше подошли бы плюсы, у нас граждане норовят написать на фортране :) но у нас программисты тоже побочный продукт (хотя кода эти непрограммисты вбрасывают поболе, чем в иной софтверной конторе)
в нашей области много чего уже написано и отлажено на фортране, писать на нем опять же проще, если логика простая.

> в последнее время получают преимущество языки, для которых параллелизация проще
1. как ниже отметил ффантом, собственно параллелизм впихивается в любой язык, более того, в фортран его добавить проще, чем в некоторые другие языки.
2. параллелизм, на мой взгляд, подразумевает несколько иную парадигму, чем просто "давайте делать как раньше, но теперь ещё равномерно загрузим все процессоры" - ну там, персистентность данных (как это по-русски-то?) хорошо бы иметь, например. поэтому даже если Фортран проиграет Ррр на этом поле, то это не будет значить, что Фортран абстрактно "хуже" или "устарел".

From:

Матлаб, по-моему, платный. А так, да, отличный инструмент. Он уже 15 лет назад им был, когда R в помине не было.

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

"Персистентность данных" -- ты имел ввиду immutable data, наверное. Не знаю, как по-русски :) Immutable data -- это сразу функциональные языки. Собственно, одна из причин, по которой они набирают популярность -- хорошо параллелятся.

From:

Фортран (пусть будет Фортран77)

А смысл? Прошло 37 лет, с тех пор появилось четыре других стандарта языка, не считая мелких изменений. Соответственно, Фортран 77 сейчас интересен только тем, что код на нем удастся скомпилировать и современным компилятором (за поддержанием обратной совместимости в языке тщательно следят), но писать что-то новое на нем совершенно бессмысленно.

From:

исключительно потому, что по семьдесят седьмому я бы смог ответить на вопросы, а по новым скорее нет :) конечно, если вы можете сказать за современный фортран, то это ещё лучше.

From: