Википедия

Обсуждение проекта:Информационные технологии/Архив/2

< Обсуждение проекта:Информационные технологии
Последнее сообщение: 8 лет назад от Hrum-Hrum в теме «Листинги кода в статьях»
Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

Листинги кода в статьях править

Последнее сообщение: 8 лет назад56 сообщений9 человек в обсуждении

Что делать с длинными листингами? Бывает листинги даже горизонтально не влезают и отображаются с прокруткой (BMP#Пример программы на C). Размещение их в сворачиваемых элементах не выход - трудно представить другую Энциклопедию с таким внутри. В англовики видел предложение убирать в Викиучебник(Викикниги) (en:Wikipedia:Articles for deletion/Bresenham's line algorithm C code) - можно будет ссылаться на главы в одной свободной книге - сборнике рецептов. Есть en:Wikipedia:WikiProject Computer science/Manual of style#Code samples. Какие будут предложения? На форумах ранее эта тема поднималась? ~Сунприат 12:44, 3 января 2015 (UTC)

  • Соображения за и против. Вот конкретный пример: Алгоритм Коэна — Сазерленда. Пользы от такого листинга маловато, а мутоты с патрулированием хватает: кто-то вдруг меняет условие на обратное и поди разбери — вандализм или исправление. Но что считать длинным (и широким листингом)? Полагаю, что листинг должен быть не шире 80 символов (из исторических соображений). Но его ширина обычно растёт за счёт комментариев, которые в других изданиях сделали бы как-то по-другому, вне самого листинга. Кроме того, некоторые языки в несколько раз многословнее других (сравните APL, Python, C, ассемблер). С другой стороны, встречался с тем, что народ плохо воспринимает, когда алгоритм записан на сверхвысокоуровневом языке, да и алгоритмы часто формулируются для алголо-подобного языка (или некого псевдокода) и выглядят (в энциклопедии) на других нелепо… В тоже время, считаю, что листинги всё-таки должны быть в статьях или быть легко доступны из этих статей, как изображения с медиасклада. Другой пример: XML#Пример документа. В данном случае листинг можно сравнить с иллюстрацией, которой, конечно же, должно найтись место в статье. Войну против листингов развернуть очень легко, но без консенсуса о критериях допустимости это не будет продуктивным. Для иллюстрации тоже должно быть обоснование её применения, а уж размер — дело техники. То есть, должны быть содержательные критерии допустимости листингов (а может они и есть, замучаешься в правилах что-то подобное найти). РоманСузи 13:27, 3 января 2015 (UTC)
  • Кстати, полагаю, что в моих двух примерах листинг допустим (у Алгоритм Коэна — Сазерленда после рефакторинга), в Вашем (BMP) — нет, так как это пример использования кучи библиотек для работы с форматом, а не, скажем, парсер формата. То есть, листинг несамодостаточен без знания API нескольких библиотек. Другое дело, Очередь с приоритетом (программирование) — там я вставил листинг на Python, так как он достаточно компактно иллюстрирует работу с типом данных. Конечно, туда требуется добавить хотя бы один листинг реализации, но на Python его писать нехорошо, так как у него слишком высокоуровневые конструкции для иллюстрации алгоритма (только затуманят дело). В общем, я полагаю, что только не более 20-25 процентов листингов в настоящий момент неадекватны. РоманСузи 13:35, 3 января 2015 (UTC)
  • Википедия:Форум/Архив/Правила/2014/07#Википедия - не stackoverflow вот было. Попросил обзорный список Википедия:Запросы к ботоводам#Листинги. ~Сунприат 16:10, 3 января 2015 (UTC)
    • К единому мнению никто там не пришёл, хотя предложения были отчасти логичные. По-моему, использование только псевдокода — слишком ограничивающее решение, нужное лишь для того, чтобы в статье не появлялись реализации на всех без разбора ЯП. Более того, листинги есть не только в статьях по алгоритмам, но и в статьях, для которых важен конкретный синтаксис. Например, на каком псевдокоде можно объяснить Метод расширения? То есть, когда получите список, пожалуйста проанализируйте и роль листингов в разных статьях. Например, когда я писал Erlang рецензент хотел убрать многочисленные примеры. Но я был против (как можно говорить о языке программирования без примеров кода?). С другой стороны, на базе Викиучебника можно создать новую книгу типа Cookbook (Справочник по реализациям алгоритмов) типа как раньше были справочники по расчетам на микрокалькуляторах, в которые будем собирать по-алгоритменно реализации на каких душе угодно языках! Вот только давайте сначала создадим такой ресурс, перенесём туда наиболее вопиющие случаи (например, Поиск в глубину), посмотрим реакцию сообщества. Причём, я предлагаю возможность оставить в статье возможность реализации на псевдокоде, а также наиболее подходящем языке, на котором АИ алгоритм приведён в АИ (ну и другие хорошие предложения в указанном Вами обсуждении и в этом обсуждении). РоманСузи 18:56, 3 января 2015 (UTC)
    • Более того, такой учебник уже есть! Реализации алгоритмов. РоманСузи 18:59, 3 января 2015 (UTC)
Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.
        • (Пока не уверен с консенсусом о переносе, хотя уже много чего до нас перенесли). Но технически наверное стоит оставлять некий комментарий, чтобы Реализации и не добавляли в статью? Или во всяком случае не на N+1-м языке? В общем, какой-то намёк, но где. Может, на СО (уже в ВП)? РоманСузи 22:22, 3 января 2015 (UTC)
          По мне, лучшим указателем (тот "комментарий") послужит "а как это оформлено в других статьях". Первое, что представилось - смесь Ш:wikibooks и Ш:Внешние медиафайлы со справочной ссылкой на пояснение в ВП:ИТ, но это значит перелопатить все статьи, нужно подумать. ~Сунприат 22:57, 3 января 2015 (UTC)
          • Но у проекта уже есть шаблон на СО многих статей (хотя в случае с алгоритмами там может быть и проект Математика). Может там какой «подвальчик» можно открыть? Кроме того, правила не обязывают участников следовать нормам какого-то проекта. Полагаю, что наиболее верный вариант — это продумать до конца процесс (критерии плохих листингов, инструкцию по переносу, какие шаблоны куда ставить) и включить в нормативные документы. РоманСузи 08:23, 4 января 2015 (UTC)

Я считаю, следует выбросить листинги из статей на любом конкретном языке программирования. Мои аргументы: не видно подключенных библиотек, масса трудновылавливаемых без прогона на машине ошибок (см., например, Алгоритм Ли), любая нетривиальная правка любого участника в нетривиальных листингах ставит в тупик, или это реально улучшение, или ошибка/вандализм. Возможно, при их сохранении на листинге следует ставить шаблон типа: "прогнано на машине тем-то тогда-то с таким-то набором данных". Но, а как быть с другим набором данных с побочными результатами? Призываю оставлять в статьях только листинги на абстрактном псевдокоде, например, как в алгоритм Евклида. Д.Ильин 08:59, 4 января 2015 (UTC).

@Д.Ильин: Псевдокод, конечно хорошо выглядит полностью на русском. Ещё есть возможность подсвечивать части цветом (например) В других статьях используют мега шаблоны, например Ш:Плей-офф/doc, вероятно можно из шаблонов собирать и блок-схемы Файл:Euclid_flowchart_1.png.проще рисунок вставить Можно выбрать способ создания анимаций (gif) прохода по алгоритму, есть несложные способы. Что-то такое представляется уместным использовать? ~Сунприат 09:51, 4 января 2015 (UTC)
  • Приведённый пример (Алгоритм Ли), конечно, не ах, но я бы не стал столь радикально подходить к вопросу. Даже Кнут, который придумал свой псевдокод и MIX-машину, таки определил их формально. В этом смысле код на реальном ЯП обладает тем преимуществом, что семантика однозначна, так как язык обычно имеет определение каноническое определение. Например, алгоритмы типа XTEA лучше всего иллюстрировать на Си (из-за битовых операций). Кое-что лучше иллюстрировать в функциональном стиле, наконец, есть алгоритмы, для которых лучше подойдёт R, Octave и т. п. Также я бы сделал исключение (компромисс) для статей без алгоритма на псевдокоде. Но в целом я с Вами согласен, что за некоторыми исключениями алгоритмы лучше всего представлять в псевдокоде. И ещё одно соображение. Последнее время некоторые источники дают не только алгоритм, но и его обоснование, например, на языке доказателя теорем (типа Coq). В идеале ВП:ПРОВ наилучшим образом бы удовлетворялось, если к алгоритму шло бы доказательство. В этом случае копипастишь доказательство в coq — и вуаля! (но в этом случае пример должен быть на диалекте ML или Haskell). Но такой подход, полагаю, дело не столь близкого будущего. К листингу, кстати, можно приложить цифровую подпись того, кто делал сверку. Извините, если размечтался. Коллега Сунприат заказал ботоисследование, и полагаю, будет правильным сначала изучить масштаб проблемы. И ещё. Мы пока что касаемся только реализаций алгоритмов. У листингов есть и другие применения: иллюстрация синтаксиса, иллюстрация концепций языков программирования и значимых фреймворков, иллюстрация применения API, библиотек, работы со структурами данных и прочее РоманСузи 10:12, 4 января 2015 (UTC)
  • Кстати, кроме упорядоченного переноса в викиучебник-справочник, есть еще и дикие попытки переноса. Например, b:Редакционное предписание перенёс под сень учебника. Не знаю, правда, сколько таких, и как их выявить. РоманСузи 11:27, 4 января 2015 (UTC)
Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

Пригодится ли категория К:Статьи с примерами кода на псевдокоде, как К:Статьи с примерами кода? ~Сунприат 18:21, 8 января 2015 (UTC)

  • Сложно сказать: я бы поставил +0. В некоторых случаях сложно понять, имеем ли дело с псевдокодом или же с математической нотацией. Если будет точный критерий, позволяющий их разделить, то проблем не вижу, хотя и особой надобности тоже. Если бы псевдокод был унифицированным, тогда другое дело. (В какую категорию она войдёт?) РоманСузи 18:56, 8 января 2015 (UTC)
  • Ещё один кладезь листингов — шаблоны проектирования, например: Декоратор (шаблон проектирования). Эти тоже предполагается выносить, оставлять один (на каком языке?). И если выносить, то тоже в Реализации алгоритмов? РоманСузи 04:42, 16 января 2015 (UTC)
    Вывод: 1) схожесть оформления позволяет использовать поиск mw:Help:CirrusSearch/ru, например по "пример реализации". 2) добавления/оформления/удаления отслеживаются в истории. Крестовый поход против кода мы в одиночку не объявляем. Предлагаю участникам из истории расставлять на личной странице обсуждения приглашение сюда в виде "приглашаю присоединиться к проекту. сейчас в проекте обсуждается оформление кода в текстах, где нам интересно ваше мнение." 3) Это проблема не только нашего раздела (см. французский) нужна консультация в англовики и уровня мета-вики. Посмотрю, что можно сделать. / В более развитом en.wikibook шаблоны собраны в отдельную книгу. Пока проще сделать по их подобию, а перекомпоновать всегда успеем. --Сунприат 05:29, 16 января 2015 (UTC)
    Предложили такой план: перевод англовики, организация по его пунктам опроса, создание рекомендации по результатам. Каждое сообщество должно решать само что делать - попробую им на форумы что-нибудь написать. --Сунприат 09:48, 21 января 2015 (UTC)
    Не совсем понял: перевод книги или чего? И по пунктам чего опрос (там был какой-то опрос)? Забавно, в англовики en:Adapter_pattern по качеству хуже, чем b:en:Computer_Science_Design_Patterns/Adapter. А реализации и там, и там... Мне кажется, что до сих пор листинги вообще не снабжают источниками: если листинг из источника скопирован, то это копивио, а если не скопирован, то что с ним делать? Переименовывать переменные и функции. Или это fair-use? (извиняюсь за отклонение от темы, но я уже около двух десятков алгоритмов перевёл в Викиучебник, в том числе выковырял из Истории правок (BioMaxHazard любил удалять реализации) и такой вопрос о соответствии листинга заявленному всегда крутится в голове. То есть, хотелось бы в Википедии иметь шаблоны проектирования по источникам, а не то, что Вася Пупкин посчитал написанным по шаблону. РоманСузи 14:20, 21 января 2015 (UTC)
    Перевод части про код из рекомендаций по стилю из англовики как основу для своей рекомендации. Опрос/обсуждение (RFC запрос на комментарии) по тому подходят ли нам эти части и есть и чем их дополнить. Написал в примерно 10 вики с примером декоратора или прототипа. В трёх сказали, что их статьи это перевод англовики и в англовики есть такие листинги при том, что в англовики есть упомянутые рекомендации. В некоторых сказали, что это не проблема. Кстати, в польской совсем нет кода (в статьях о шаблонах), а в немецкой только на одном языке и там пока ответили что это больше нормально, чем нет. Посмотрю, разовьется ли в других вики обсуждение. Пока количество заинтересованных сторон можно сузить до нашего раздела и проекта в англовики. Все ваши ответы держу на виду, но хочу менее голословно подойти к ответам, т.к. задаюсь теми же вопросами. --Сунприат 21:17, 21 января 2015 (UTC)
    В основном обсуждение не пошло, не восприняли всерьёз. Кое-где [2] подошли радикально. В некоторых вики (вроде pl и de) видел мало кода в противовес количеству кода по другим интервикам на тех же статьях. Значит они где-то обсуждали - поищу. --Сунприат 07:23, 24 января 2015 (UTC)
    Нашёл - способ de-вики de:Liste von Singleton-Implementierungen, способ pl-вики s:pl:Singleton (wzorzec projektowy)/kod - в Викитеке! --Сунприат 07:47, 24 января 2015 (UTC)
    В англоВикиучебнике на 4-х языках, в статье на двух. Так в нескольких статьях видел - два в статье, остальные в учебнике. Требовать ссылку на код (подобный) имеет смысл в сложных/длинных случаях. По fair-use вопрос интересный, т.к. текст из Википедии далее может использоваться в коммерческих целях. Копировать - плохо, пригодилась бы подборка ссылок на тему лицензий - стоит рассмотреть отдельно; после замены стиля/названия переменных код считается тем же. --Сунприат 07:23, 24 января 2015 (UTC)
    Код считается тем же после эквивалентных преобразований? Но тогда он может считаться подобно математической формуле: en:Idea–expression divide. РоманСузи 07:42, 24 января 2015 (UTC)
    • О крестовом походе никто и не говорит. В каждом конкретном случае, в том числе в случае длинного листинга, следует рассматривать его энциклопедическую ценность для статьи. С другой стороны, у нас есть ВП:ПРОВ, и я могу прямо сейчас отметить большинство листингов из шаблонов требованиями источников, потому как почему без АИ я должен верить, что приведённый листинг является реализацией шаблона, даже если ВП:ПДН, автор может ошибаться? Конечно, для каких-то языков АИ найдутся и более того, пример на реальном языке может много дать читателю (псевдокод тут будет выглядеть несколько странно), но сразу на нескольких? В любом случае, пока ничего с этим не делаем за исключением вопиющих случаев, если таковые найдутся. РоманСузи 07:11, 16 января 2015 (UTC) Добавил в черновик, посмотрите пожалуйста, что добавление имеет смысл. РоманСузи 07:18, 16 января 2015 (UTC)
  • Ещё 1) в комп. журналах, конференциях, сборниках, наших/зарубежных, куда отдаются статьи, есть правила публикации и оформления и там может быть про цитирование кода. 2) Тут en:Software design pattern#Documentation примеры кода и реализация разделены - можно этот момент развить на одной статье и дать как пример. Вообще, попадающиеся хорошо оформленные статьи (о, можно посмотреть по хорошим/избранным) в других вики стоит упоминать в наших рекомендациях как ориентиры. --Сунприат 02:26, 24 января 2015 (UTC)

@РоманСузи: По букве правила.

Подборки исходных материалов и информации, находящейся в общественном достоянии,

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

Полные тексты оригинальных источников (в том числе исходные коды программ) помещайте в Викитеку.

— ВП:НЕАРХИВ

По этому: 1) является ли приведение примеров на 6-и - 8-и языках "подборкой" 2) в общем виде здесь о полных и законченных документах. в этот ряд тот кусочный код, что сейчас в статьях, не совсем подходит (т.е. выходит, что букве "ВП:ЧНЯВ не противоречит") 3) из s:Викитека:Описание „не может быть помещено в Викитеку: Исходные коды программ.“ и Викитека „Викитека может хранить следующие материалы только при условии, что они являются частью более общей публикации: Исходные коды программ.“ Т.е. к последней части тоже кусочный код не совсем подходит. Отсюда вопрос - не подразумевается ли тут "полный исходный код программы, например, Блокнота"; к кусочному коду подходит ВП:НЕАРХИВ или же его следует рассматривать относительно к другому правилу подобно иллюстрациям (количеству картинок на статью). --Сунприат 08:43, 26 января 2015 (UTC)

Пограничные случаи (к применимости критериев) править

Случаи, в которых вопрос о листингах не совсем тривиален:

  • Двоичный поиск — нет псевдокода, часть текста опирается на листинг. С другой стороны, смахивает на инструкцию по правильной реализации алгоритма.
  • Задача о восьми ферзях — часть текста опирается на пример кода. Но реализаций слишком много, по идее, нужно переносить.
  • Я считаю, надо убрать два С++, C# и Бейсик, оставив Си и Java. Не вижу смысла в Ерланге. Зато обязательно надо добавить на констрейнах - либо с Пролога (классика), либо с AliceML (тогда и Хаскел убрать можно). SQL удивил, честно, даже думал тоже лишнее (экзотичное же решение), но подумал, что для proof of concept очень даже полезно в дидактическом смысле. Извините, что не беру на себя. Arachnelis 19:25, 24 января 2015 (UTC)
  • Не вижу смысла в таком количестве. Достаточно показать императивный на псевдокоде, ФП - на ML (пока пусть Erlang или Хаскел), логическое - Пролог. Остальное вынести в Викиучебник. Проблема с этой статьёй ещё в том, что там слишком много листингов, слишком мало объяснительного материала. РоманСузи 20:46, 24 января 2015 (UTC)
  • Мне кажется, три - это уж очень скромный верхний порог. Могу такую циферку дать - человек одновременно способен усваивать семь плюс-минус две единицы информации. Например, если я назову 10 слов и повторю этот ряд несколько раз, то большинство людей запомнит 5-9 слов. Поэтому, например, эргономические стандарты требуют меню в программе дробить по 7: не более 7 групп, в каждой не более 7 пунктов, если не хватат, то делается вложенное меню. Т.е. с точки зрения науки больше 9 листингов - это точно перебор, их никто никогда не прочитает. А 5-7 - вполне допустимо. Arachnelis 14:53, 25 января 2015 (UTC)
  • Листинги в неограниченных количествах пусть в викиучебник идут читать или сюда. В статье же самая суть и средства её иллюстрации. Ну что поделать, enwiki, dewiki, ruwiki у нас есть, а cwiki, pythonwiki, prologwiki — у Викимедии нет, интервики не поставишь. РоманСузи 15:22, 25 января 2015 (UTC)

Конкретные предложения править

  • Кому нужно, найдут. По-хорошему, нужно каждую программу проверить, сделать тесты, снабдить объяснениями и т. д. и т. п. Может, кто-то там когда-нибудь и займётся, а когда займётся, увидит, откуда ноги растут (я полагаю, что у части примеров ноги вообще из англовики растут). К сожалению, шаблоны я делать не умею, а так сделал бы для Викиучебника стандартный шаблон, в котором можно было нужные нити дать. РоманСузи 21:07, 8 января 2015 (UTC)
  • Осмелюсь вставить пять копеек, хоть и начал уже было отрекаться от залезания в правила. Народ, вы забыли провести самую главную разграничительную линию: примеры кода в статье о языке и примеры кодов на разных языках в статье об алгоритме (паттерне, пр, нужное подчеркнуть). ИМХО, эта вилка должна породить не одно, а два правила. Что по первому, то вобщем-то очевидно: не слишком длинно, не слишком мудрёно алгоритмически, и чтобы давало представление о языке. Псевдокод тут ни при чём — это как зубы удалять по фотографии. С недетерминированными языками псевдокод читателя так запсевдокодит, что тот без алкоголя спать не ляжет. По второму я предлагаю пройтись по АИшечкам и составить список языков, которые считаются достаточно легко читаемыми для демонстрации алгоритмов. Есть классические примеры — C (но не С++), Pascal (но не Delphi), Java (но не С#), Python, SML (или OCaml), Haskell (но не Scala). Лиспы лучше не трогать, ибо синтаксис ваистену (не в обиду Лиспу), в крайнем случае Scheme. Могу заметить, что когда в литературе по ФП рассматривают ИП/ООП, то примеры приводят на Java (пример). upd: Ещё нужно требовать либо обходиться без API совсем, либо использовать только «самые стандартные» библиотеки, идущие от корней до самых кончиков <^_^>. Нужно выбрать по одному языку для демонстрации определённого рода концепций, чтобы предельно чисто и предельно однопарадигменно (никаких Oz’ов), и вместе с тем более-менее популярно в смысле количества литературы (то есть Ocaml, а не Eiffel). Вилка «Си или Java» — как раз пример, почему не С++. Тогда кол-во примеров в статьях будет заведомо ограничено, а желающие будут направляться в Викиучебник или куда там. Надо всё-таки добавить CLOS как (АИшно-доказуемо) самый первый и при том самый мощный стандарт ООП, либо Smalltalk. Вобщем, если моё предложение встретит одобрение, надо будет затеять отдельное обсуждение, что куда. upd2: А ещё пункт типа "Разрешается использовать любые из этих N языков, но не более пяти примеров на статью". Arachnelis 19:23, 23 января 2015 (UTC)
  • Это (апдейты) уже слишком. Полагаю, вместо всех этих конкретностей для начала достаточно сказать, что язык реализации должен наилучшим образом подходить для иллюстрации алгоритма. В англовики за критерий взяли читабельность кода. Конечно, если статья о колмогоровской сложности, то полагаю, что unlambda вполне хорош. И т. д. РоманСузи 21:05, 23 января 2015 (UTC)
  • А сама идея списка "избранных языков"? Критерий "читабельности" я считаю некорректным возводить в правила. Во-первых, получится, что примеры на Перле недопустимы, даже если задача аккурат под регулярки. Во-вторых, на эту тему холиварят только так - кому-то темплейты нечитабельно, кому-то Хаскел. Arachnelis 12:46, 24 января 2015 (UTC)
  • Нужно удобное указание ссылки на примеры. Ссылка из шаблона навигации в конце статьи плохо подходит. Её текст "тема в викиучебнике" читателю не понятен. Как вариант, текст, подобный Ш:См. также, "см. примеры темы на разных языках" курсивом после блока с примером в статье. --Сунприат 18:12, 26 мая 2015 (UTC)
  • Вариант: не накладывать ограничения на язык. В статье остаётся тот код, к которому есть пояснения текстом (или внутренние комментарии) на русском. Что должно оставаться в каждом случае решается отдельно обсуждением на СО статьи. @РоманСузи: ещё про обычный текст спросил b:Обсуждение участника:Ivan Shmakov#Реализации алгоритмов. --Сунприат 21:18, 26 июня 2015 (UTC)
    • Тем не менее, читабельность должна быть. У читателя не должно быть лишних препятствий в понимании алгоритма из-за каких-то неочевидных особенностей, побочных эффектов и т. п. языка. РоманСузи 16:31, 27 июня 2015 (UTC)
  • Подобно карточкам, у которых внизу ссылка на викисклад, в карточки (ш:Алгоритм) можно добавить поле для викиучебника. --Hrum-Hrum 09:00, 27 апреля 2016 (UTC)

Найденные обсуждения править

GitHub, GitHub Gist и т.д. править

  • Есть предложение писать листинги на GitHub, и выводить их в статьи с помощью плагина. Плюсы: кроме участников Wiki, код могут проверить и исправить пользователи GitHub, минусы те же, что и плюсы, и к ним еще хранение на внешнем сайте. Тем не менее предлагаю обсудить. --Sergey Funn 20:41, 14 октября 2015 (UTC)
  • Предложение не выдерживает критики: не реально следить за изменениями. Кто-то один будет администрировать пул реквесты — уйдёт, загнётся всё. Будут в общественном доступе — можно вандализировать, пока никто не заметит. Сильно лучше код не станет, но усложнит его улучшение для рядового википедиста, который не готов мучаться с этими ssh-ключами и они сторонники этого вашего пароля, а онлайн редактирования, насколько мне известно, пока нет (могу ошибаться). Всего улучшения от выноса на гитхаб это то, что его могут найти местные жители и улучшить или дополнить, чего нам не надо. Мы тут не код пишем, а энциклопедические статьи. Заходишь, например, в факториалы, а там «каждый уважающий себя говнокодер» уже написал характерный код на своём любимом языке, когда гораздо правильнее использовать псевдокод. Может, я чего-то не знаю, но как будут находить наши репозитории? Архитектура тоже не понятна. Снипеты это будут или реальные файлы репозитория? --higimo (обс.) 08:22, 15 января 2016 (UTC)
  • @Sergey Funn: Из Википедии можно расставить ссылки. Как это будет в GitHub? Как можно организовать столько тем? Как можно организовать комментарии, пояснения на разных языках? Как дела с лицензией? CC BY-SA для копирования частей туда и обратно? Есть ли уже там что-нибудь подходящее начатое? --Сунприат 17:36, 8 февраля 2016 (UTC)

Словники править

Последнее сообщение: 8 лет назад45 сообщений7 человек в обсуждении

Нужно бы сделать тематический словник, а лучше несколько. Может есть какие-то нормальные (дотягивающие до АИ) тематические энциклопедии или книги с алфавитным указателем, но таким, чтобы на каждое слово можно было создать по статье или перенаправлению? Год не важен. ~Sunpriat 04:30, 14 декабря 2014 (UTC)

  • По всей теме информационных технологий или более конкретно? Полагаю, что это неподымная задача. Самое близкое, что видел: Воройский Ф. С. Информатика. Новый систематизированный толковый словарь-справочник, Терминологический словарь по основам информатики и вычислительной техники / Ершов А. П., Шанский Н. М., Толковый словарь по вычислительным системам / Под ред. В. Иллингуорта и др. — М.: Машиностроение, 1990. — 560 с. В начале 1990-х было много попыток выпускать что-то подобное. РоманСузи 08:14, 14 декабря 2014 (UTC)
    @РоманСузи: В целом, да, выглядит тяжёлой задачей. На деле же, даже если посмотреть на словари, есть общие и спец. по областям и чтобы сравнить с Википедией нужны и те и другие. Например, по существующим статьям Википедии, берём общую книгу, за её пределами остается большой кусок программирования, который покрывается уже другим словариком. Все темы охватить будет сложно, поэтому приоритет и цель на сейчас - некий общий словник и 1-3 спец. словника, тему которых нужно взять исходя из посещаемости и популярности редактирования тематических групп статей, если это можно как-то предположить. Тоже сначала подумал о словарях, в процессе нашёл Першикова с его 10к терминами..., поэтому и спросил, может есть что-то отличное от словарей. Два словарика 90х выглядят убедительно, а вот воройский, хоть и поновее, но труд одного автора без рецензентов под редакцией непонятно кого... ~Sunpriat 08:57, 15 декабря 2014 (UTC)
  • Про Воройского — посмотрите материал, а не рецензентов. Он с точки зрения библиографа труд написал, имея, скорее всего, доступ к большой библиотеке. Это полезно тем, что у него были все источники под руками. Вам же слова нужны, а не конкретные определения? РоманСузи 10:33, 15 декабря 2014 (UTC) PS. Собственно, этот справочник уже 3-е издание и по качеству (с точки зрения Википедийного материала) на мой взгляд выше двух других. РоманСузи 10:42, 15 декабря 2014 (UTC)
    Попробовал его начать Проект:Информационные технологии/Словники/Воройский (русский). ~Sunpriat 15:03, 16 декабря 2014 (UTC)
    • По-моему, очень даже неплохо (визуально где-то 10-12-я часть статей даже нашлась в таком виде, или подрихтованы?). Конечно, не все понятия значимы для Википедии до уровня отдельной статьи, кроме того, не факт что названия даны в наиболее узнаваемой форме, как принято в Википедии. РоманСузи 17:44, 16 декабря 2014 (UTC)
      Часть не туда попала(атака асо), часть под другими названиями (эль гамаль был). А вообще полезно разукрашивает гаджет «Выделить другим цветом ссылки на перенаправления» из настроек - часть попала на перенаправления, сделанные в 2007-09 годах - так что в них есть смысл :) ~Sunpriat 18:00, 16 декабря 2014 (UTC)
      • Кстати, в оригинале часть терминов указателя полужирным выделена. Наверное, это как раз те понятия, для которых должна быть отдельная статья. РоманСузи 18:04, 16 декабря 2014 (UTC)
    • По-моему, алфавитный способ следует сочетать с тематическим. Задача — построить достаточно полный словник. Тут надо как-то объединить данные из разных источников. --OZH 20:25, 16 декабря 2014 (UTC)
      @OZH: Проект:Словники существует опираясь на отдельные издания и создавая ядра - пересечения словников. Взять пару небольших общих словников - их пересечение будет словник общей тематики. Вычитая это пересечение из словников по специальным узким темам останется некий тематический словник. Ботоводы или табличные редакторы с таким могут справиться. Для этого всё равно нужны списки-алфивитные указатели из отдельных книг. Или как вы представляете тематический способ и полный словник? ~Sunpriat 09:48, 17 декабря 2014 (UTC)
      • Просто когда в одном списке всё-всё-всё, то труднее работать. Да, действуя подряд, можно выяснить, как Википедия покрывает этот словник. Наша цель, как я её понимаю, это развитие Википедии, а тут удобно действовать по темам. То есть: взяли какую-то тему и собрали по этой теме кусты из предметного указателя — вот вам и примерная структура того что и как описывать в Википедии. --OZH 12:27, 17 декабря 2014 (UTC)
        @OZH: Таки да, словари с их over 10k охватом раздуты. Вопрос в том, есть ли такие кусты, (может иерархические тезаурусы [3]?) или что можно взять, чтобы не заниматься оригинальными исследованиями. ~Sunpriat 13:16, 17 декабря 2014 (UTC)
        • По теме программирования — возьмите Одинцова, там прекрасные «кусты» по всей технологии программирования. Предлагаю найти подобные обзорно-систематизирующие источники по всем темам проекта. В Воройском тоже есть кусты, для более прозаичных тем. Но надо бы что-то еще. Может, какие вузовские учебные планы могут для выявления самого верхнего уровня или существующая категоризация Википедии? Или на худой конец какой продвинутый библиотечный каталог? РоманСузи 19:49, 17 декабря 2014 (UTC)
          Огромное спасибо за Воройского. Я нашёл: 1) Воройский Ф. С. Информатика. Новый систематизировансистематизированный толковый словарь-справочник (Введение в современные ининформационные и телекоммуникационные технологии в терминах и фактах). — 3-е изд., перераб. и доп. — М.: ФИЗМАТЛИТ, 2003. — 760 с. — ISBN 5-9221-0426-8. и 2) Воройский Ф. С. Информатика. Энциклопедический словарь-справочник: введение в современные информационные и телекоммуникационные технологии в терминах и фактах. - М.: ФИЗМАТЛИТ, 2006. - 768 с. - ISBN 5-9221-0717-8. — Видимо, это различные варианты одного и того же. Нам будет очень полезно использовать ещё и оглавление/содержание. Думаю, что Воройский нам пригодится в первую очередь. --OZH 18:07, 19 декабря 2014 (UTC)
  • Ещё есть вот такой: Кочергин В. И. Англо-русский толковый научно-технический словарь по системному анализу, программированию, электронике и электроприводу. — Томск: ОАО «НПЦ «Полюс», 2008. — Т. 1. — 652 с. — (В 2-х т.). — ISBN 5-7511-1937-1. (но уже не помню, насколько качественный) РоманСузи 11:09, 15 декабря 2014 (UTC)
    Как-то не очень. Качество форматирования алф.списка низкое, много лишнего (напр. бруто дыхание) и того на что даже перенаправления не сделаешь. --Сунприат 04:59, 3 января 2016 (UTC)
  • Я набросал свой список на страннице Проект:Информационные технологии/Литература. Особенно примечательны (в плане составления словника) книги Бауэра и Дейтела, где можно найти сопоставления терминологий, а также, книга Шуракова, в которой нашёл отражение советский подход. Я буду последовательно викифицировать пункты своего списка, дописывать аннотации, сканировать оглавления-содержания и предметные указатели и пополнять список другими доступными мне источниками. Можете составит на указанной странице свои списки с аннотациями, и тогда мы сможем сделать первичный обзор по информационным технологиям и наметить план для реализации проекта. --OZH 17:11, 15 декабря 2014 (UTC)
  • Забыл ещё одного хорошего кандидата (из своего списка):
    • Одинцов И. О. Профессиональное программирование. Системный подход. — 2-е изд.. — СПб.: БХВ-Петербург, 2004. — 624 с. — ISBN 5-94157-457-6. — все понятия, связанные с программированием в широком смысле, удобно разложены по полочкам, то есть, систематизировано. РоманСузи 18:45, 15 декабря 2014 (UTC)
    • И ещё один важный источник забыли: стандарты. Например, ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств РоманСузи 10:29, 19 декабря 2014 (UTC)

Нашёл у себя вот что:

А. Б. Борковский. Англо-русский словарь по программированию и информатике. — М.: Московская международная школа переводчиков, 1992. — 335 с. — ISBN 5-8234-0003-9.

В конце (С. 284—333) есть указатель русских терминов. Пожалуй, с него и начну: тут и русские термины в последней стабильной версии (со времён СССР), и соответствующие им английские. Лучшего нельзя и придумать. Если, конечно, позже не был издан аналогичный словарь. (Я ещё не проверял данные вами здесь ссылки.) --OZH 21:06, 16 декабря 2014 (UTC)

Коллеги, если будут конкретные задачи по сканированию и выверке словников (по доступным нам книгам) - рутинная и средней сложности интеллектуальная работа, то я мог бы в следующем году предложить такую работу отстающим студентам. Неотстающие пишут вот эти статьи: Участник:AKA MBG/Todos :) -- Andrew Krizhanovsky 11:47, 17 декабря 2014 (UTC)
@Andrew Krizhanovsky: Нужны словники по отдельным областям. Можно оттолкнуться от этого (стр. 20) - взять отдельный пункт(ы), учебник (рекомендуемая литература/аи), который идёт по ней и из него оглавление (уточнение, что охватывает) (как Проект:Информационные технологии/Литература/Воройский, 2003) и алфавитный перечень (словник). Затраты времени на проверку можно посмотреть здесь https://ru.wikipedia.org/w/index.php?title=Проект:Информационные_технологии/Словники/Воройский_(русский)&action=history (т-я это ту, ф-я уже были готовы) +распознавание +оглавление. ~Sunpriat 12:51, 23 декабря 2014 (UTC)
@Andrew Krizhanovsky:, в Математическом энциклопедическом словаре есть раздел «Словарь школьной информатики» (стр. 805—846), полагаю, был бы неплохой и довольно базисный словник. Тогда же (четверть века назад) выходили ещё такие книги:
  • Владимир Иванович Першиков, Владимир Макарович Савинков. Толковый словарь по информатике: более 10,000 терминов. — М.: Финансы и статистика, 1991.
  • Андрей Петрович Ершов, Николай Максимович Шанский. Терминологической словарь по основам информатики и вычислительной техники. — М.: Просвещение, 1991. — 158 с.
  • Иллингуорт В., Глейзер Э., Пайл И. (ред.). Толковый словарь по вычислительным системам. — М.: Машиностроение, 1990. — 560 с. bezik° 13:52, 4 января 2015 (UTC)
    @bezik: У Першикова нет списка русских сочетаний, только английских. Мат словарь попробую.--Сунприат 16:43, 3 января 2016 (UTC)
@РоманСузи, bezik: Из интернета оказалось проблематично выудить Ершова и Иллингуорта. Напишите сюда или на почту если есть рабочие ссылки или сканы алфавитного указателя. --Сунприат 15:16, 2 января 2016 (UTC)
@РоманСузи, bezik: Иллингуорта скачал. bezik, там в алф. списке английский терминов нет получается, только русских?--Сунприат 16:00, 2 января 2016 (UTC)
@РоманСузи, bezik: Ершова скачал. А как его обработать? Только с полужирным выделением? --Сунприат 16:25, 2 января 2016 (UTC)
@Сунприат: Ершова кто-то сюда вынес: [4] (и он тут в более приличном виде, чем в скане). РоманСузи 16:27, 2 января 2016 (UTC)
Видел, думал в книге будет алф. указатель. А его и в ней нет (вернее есть, но совсем краткий), но хоть видно жирное выделение. --Сунприат 16:31, 2 января 2016 (UTC)
Нет, там всё просто: в конце только «редиректы» на понятия внутри статей (они вполне до "см." берутся), а в самом тексте ВОТ ТАКИМ ОБРАЗОМ начало статьи, а вот с уточнениями сложнее. РоманСузи 16:38, 2 января 2016 (UTC)

WANTED: Computing Classification System, 2012 Revision - перевод править

А ещё студентов (может, и не отстающих, и, может даже, и не студентов) можно было бы озадачить таким творческим делом: перевести и оформить статейными ссылками предметную классификацию ACM [5]. Это будет и отличный словник, и подсказка по вопросам системы категорий, bezik° 13:52, 4 января 2015 (UTC)
  • Может, с этим сначала боты поработают по алгоритму: 1) читай строку 2) смотри в enwiki (или на викиданных?), учитывая редиректы 3) если найдена статья на русском, пиши оба варианта, иначе только на английском 4) если не найдено - лезем за переводом (куда-нибудь? multitran?) и пишем его как fuzzy 5) если файл не закончен, goto 1. К тому, что боты не переведут, нужно уже специалистов подключать... РоманСузи 14:03, 4 января 2015 (UTC)
На случай, если кто-то захочет разобрать отдельные ветки - творчество гугла Проект:Информационные технологии/Словники/ACM @bezik, РоманСузи: --Сунприат 03:53, 3 января 2016 (UTC)

Воройский править

Подготовил, пока, страницу «Проект:Информационные технологии/Литература/Воройский, 2003». --OZH 10:30, 20 декабря 2014 (UTC)

Справочное руководство «Компьютеры» править

Есть ещё:

Хеллерман Г. и др. Компьютеры. Справочное руководство. В 3-х т.. — Пер. с англ.. — М.: Мир, 1986.

У меня есть только первые два тома. Третьего тома не видел. --OZH 19:15, 29 декабря 2014 (UTC)

@OZH: Посмотрел Хеллермана и Бауэра. Такие алф.списки (уточнения с тире) сложно делать нормальными. Приходится вручную копировать и додумывать как правильно вместо прочерка вставить. Может знаете что-то более удобное, где нет тире, чтобы только распознать текст и убрать номера страниц. --Сунприат 13:16, 3 января 2016 (UTC)
@Сунприат: Всё-равно много ручной работы. Тут нужно какую-то базу данных «лепить». Другое дело, если бы в Википедии было бы специальное пространство имён «Источник:», где можно было бы иметь вполне себе энциклопедические описания используемых в Википедии источников, но где можно было бы также хранить и предметные указатели (по аналогии с механизмом категорий). ;-) --OZH 12:56, 13 января 2016 (UTC)
@OZH: Ладно, останутся с тире. Дейтела и Шуракова, упомянутых выше, не нашёл. Напишите сюда или на почту если есть рабочие ссылки на сканы их книг(или только алфавитного указателя).--Сунприат 13:07, 13 января 2016 (UTC)

WANTED: По компьютерной графике править

В теме компьютерной графики особенно острый недостаток в словниках на русском (в статьях пишут английскими, например: Рельефное текстурирование). Надежды найти мало, но всё-таки. РоманСузи 21:17, 3 января 2015 (UTC)

Краткое описание информатики править

Кстати, для подтемы информатика в англовики есть готовое краткое содержание: en:Outline_of_computer_science. У нас списков, конечно, не любят но может быть как-то поможет. РоманСузи 15:06, 24 января 2015 (UTC)

2010 Mathematics Subject Classification править

И ещё один источник таксомонии (правда, на английском): 2010 Mathematics Subject Classification. Информационных технологий касается краешком: например, классификация алгоритмов 65-XX, computer science 68-XX. (Интересно, что они раз в десять лет пересматривают классификацию). РоманСузи 15:25, 24 января 2015 (UTC)

Из книги «Введение в теорию языков программирования» править

Книга: Довек Жиль, Леви Жан-Жак. Введение в теорию языков программирования. — М.: ДМК Пресс, 2013. — 134 с. — ISBN 9785940749134. Добавил небольшой словник после некоторой обработки: Проект:Информационные технологии/Словники/Введение в теорию языков программирования. РоманСузи

Корректировка словников править

Нужно ли корректировать ссылки? Например в мат.энцикл.словаре «вывода устройство» (страница 814) на человекочитаемое «устройство вывода». Или делать такие перенаправления? --Сунприат 15:48, 2 февраля 2016 (UTC)

Сунприат. Исправить словник. Oleg3280 16:04, 2 февраля 2016 (UTC)
Пока буду рядом с оригиналом(не ссылкой) дописывать человекочитаемое(с ссылкой) название. --Сунприат 16:14, 2 февраля 2016 (UTC)

Навигация по вычислительной науке править

Последнее сообщение: 9 лет назад10 сообщений4 человека в обсуждении

Предлагаю пересмотреть набор навигационных шаблонов по ИТ.

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

Такой набор имеет кучу недостатков:

1) Он избыточен. Много мелких нав.шаблонов - это всё равно что никакой навигации. Если, находясь, скажем, в статье "типобезопасность", я не могу быстро найти ссылку на "параметрический полиморфизм первого класса", то я должен либо крутить статью в её поисках, либо набирать название в ручную. В некоторых случаях дополнительно приходится пользоваться поиском или разрешать дисамбиги. Т.е. вместо прямой навигации мы имеем чистый гуглёж.
2) Он не полон. Отсутствует какая бы то ни было навигация по тематике ООП, по лямбда-кубу и теориям типов (обратите внимание, что "у них" шаблон зовётся "type systems", а не "data typing", т.е. теории типов в него не вклеить), по организации памяти ЭВМ. "Стратегии вычисления" - узковатый список, по параллелизму и управляющим конструкциям навигация отсутствует.

Сочетание двух этих свойств уже плохо: "что не надо - сделано; что надо - не сделан Википедия:Форум/Вниманию участников#Шаблон НП". Но это ещё не всё.
Шаблон "типы данных" имеет собственные недостатки:

3) иная структура: он не вертикально-боковой, а подвальный. Прежде всего, это как-то отрывает его от "систем типов". Далее, подвальная таблица хороша, когда список в ней настолько широк и иерархически сложен, что вертикальные не справляются. В данном же случае мы видим, что она не только абсолютно плоская, даже не требующая каких-либо свёрток, но к тому же верхняя её половина справа пустует, и заполнять её ровным счётом нечем, т.е. это лишняя трата экранного пространства.
4) верхняя строка не имеет никакого отношения к нижним. Я ни разу не встречал контекста, где бы одновременно фигурировали монады и нибблы, или рекурсивные типы и биты. Это потому, что эта верхняя строчка собирает темы, связанные вовсе не с типами в абстрактном (теоретическом) понимании, а с машинным представлением типов. Причём список ещё и не полный: в нём, например, отсутствует "выравнивание (alignment)", но в такой шаблон его вставить тем более трудно: в верхнюю строчку было бы некорректно, а в нижнюю - опять же будет диссонировать с конструкторами типов.

Я предлагаю отказаться от копирования английской структуры навигацию и продумать её с нуля. (Глядишь, со временем можно будет и "им" предложить новое решение). Проект нового набора шаблонов в моём черновике:

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

Прошу оценить идею, рассмотреть предлагаемые эскизы, указать на ошибки, предложить дополнения.Arachnelis 08:08, 5 декабря 2014 (UTC)

  • @Arachnelis:И эти узкие предлагаете ставить в начало статьи? Так добавляется много "прямо не относящейся" к объекту статьи информации. Съедая полезное пространство для текста/изображений + недовольство длинными шаблонами часто поднимается на форумах (недавний пример Википедия:Форум/Вниманию участников#Мегакарточки на пустых страницах, уже упомянутое Википедия:Форум/Вниманию участников#Шаблон НП , Википедия:«Болезни» википедистов#Шаблонность мышления). Вашу структуру разносит до непонятности в мобильной версии. Что-то по оформлению можно подчерпнуть отсюда en:Wikipedia:Navigation templates. ~Sunpriat 06:12, 9 декабря 2014 (UTC)
    • Аналогия с географией совершенно не в тему: в статьях о программировании рисунки не встречаются. И речь не о пустых таблицах «ради самих таблиц», а о навигации. Я не изобрёл велосипед: есть, например, Шаблон:Парадигмы программирования. Что же касается «отношения информации к объекту статьи», то повторяю вопрос: ваши конкретные замечания по навигационным спискам? Я собрал то, что я соотношу тесно, и что мне частенько приходится набирать вручную при разборе некоторой темы. Узколобый подход "Ничего не хочу знать кроме того, что непосредственно запросил" - дело субъективное, читать никто не заставляет, а запрещать любознательным права нет, Вики - это по определению собрание информации. Что там в мобильном исполнении — не ко мне, а к разработчикам движка, я мобильный интернет не признаю религиозно. Если с вертикальными шаблонами есть технические проблемы — так и скажите, я подумаю, как сделать эти таблицы горизонтально. Arachnelis 09:37, 9 декабря 2014 (UTC)
      • @Arachnelis:Аналогия тут - узкость, длинность и общие принципы оформления. Замечательный пример километра на пять сточек Программирование потоком данных. Тему точно стоит поискать/поднять на общих форумах перед тем как штамповать такое в статьи. Вся навигация ({{Навигационная таблица}} - navbox и {{Боковая навигационная таблица}} - infobox noprint, vertical-navbox) оформлена в классах, которые не выводятся на печать (для pdf, версия для печати, мобильная версия). Где-то про это должно быть пояснение. То, что сейчас вижу, такая структура, обычно находится в разделе см.также. В боковых нав.шаблонах обычно перечисления в строчку, а не в столбик + можно попробовать использовать сворачивание, например, как в en:Template:Close relationships. Без маркера эти списки намного лучше читаются. Было бы интересно (и привычнее) посмотреть горизонтальный вариант (расчёт расположения элементов берётся с поддержкой минимум 1024х768). ~Sunpriat 11:00, 9 декабря 2014 (UTC)
      • @Arachnelis: Вот Википедия:Форум/Технический#Избавиться от шаблона Конфликт было очередное недовольство вертикальными шаблонами. ~Сунприат 15:01, 11 января 2015 (UTC)
  • Крайне любопытно, но… тут и вправду придётся действовать «с нуля». Мне очень импонирует, когда в книге приводится предметный указатель. Нам, в Википедии, не помешает иметь некий аналог предметных указателей. Другое дело, что у нас есть страницы разрешения неоднозначностей и навигационные шаблоны. Навигационный шаблон не так просто составить. Попытка участника Arachnelis поучительна: есть о чём размышлять. Спасибо. --OZH 20:32, 9 декабря 2014 (UTC)

Статьи о языках программирования править

Последнее сообщение: 9 лет назад189 сообщений7 человек в обсуждении

Было бы неплохо иметь в Википедии качественные статьи, посвящённые языкам программирования. Я предлагаю использовать для написания таких статей одну и туже структуру, которая приводится ниже. Смысл предлагаемой структуры в том, чтобы, во-первых, задать общий стиль оформления, в-вторых, максимально упростить и упорядочить написание самих статей (всегда будет ясно, что и где писать, а само изложение всегда будет заранее нейтральным), и, в-третьих, упростить написание сравнительных статей (если, конечно, речь идёт о значимых сравнительных статьях, вроде статьи «Сравнение C Sharp и Java»). В моих ближайших планах — работа над статьями, посвящённым таким языкам программирования, как

«C++»
«C Sharp»
«Java»

Я предлагаю организовать команду для совместной работы над этими статьями. Цель — написать к Новому году три качественные статьи, обладающие энциклопедической полнотой и точностью изложения. В одиночку такие статьи не пишутся. Заодно, следует обратить внимание и на другие языки программирования, и на другие статьи, посвящённые информационным технологиям. --OZH 05:29, 21 ноября 2013 (UTC)

Раз уж предлагается такая массивная работа над статьями, давайте в качестве ещё одной конечной цели возьмём достижение статуса хорошая, а потом избранная. ~Нирваньчик~ øβς 10:09, 21 ноября 2013 (UTC)
Создал ВП:ИТ для сбора рекомендаций. ~Sunpriat (обс) 16:18, 23 ноября 2013 (UTC)
Попробую в пятничный вечер выделить туда из обсуждения черновой вариант. ~Sunpriat (обс) 19:36, 27 ноября 2013 (UTC)

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

«Erlang»

При этом попробую всё-таки придерживаться выработанной структуры (не уверен, что дословно), о которой мы здесь почти договорились. @Нирваньчик: надеюсь, что будет по крайней мере хорошая статья. РоманСузи 20:41, 23 ноября 2013 (math>UTC)

Erlang править

  • Поставил статью на рецензию: Википедия:Рецензирование/Erlang РоманСузи 19:09, 2 декабря 2013 (UTC)
  • Прошу обратить внимание на комментарии (два последних) от рецензента по статье Erlang (рецензирую статью на избранную). Какие будут возражения/комментарии и т. п.? У меня сложилось представление, что так, как он, считают не все, но тем не менее (см ВП:СТАРТ — там явно сказано о желательном научно-популярном стиле статей)? РоманСузи 18:19, 5 января 2014 (UTC)
  • Статья Erlang стала относиться к числу хороших. РоманСузи 17:53, 24 февраля 2014 (UTC)
    Поздравляю, конечно, но я бы многое поправил - как по сути, так и просто по стилю изложения. Например, странно видеть фразу "В языке также широко применяются заимствованные из функциональной парадигмы..." в статье о типичном функциональном языке. Не спешите с выводом её в "избранные". Там, глядишь, и структуру подключим - вам вроде понравилась. Arachnelis 09:54, 26 февраля 2014 (UTC)
  • Спасибо, исправил о функ. парадигме. Структуру можно попробовать на другом языке, для которого еще нет хорошей статьи (работа над Erlang несколько измотала). РоманСузи 18:25, 22 марта 2014 (UTC)
  • Если хотите, можете помочь мне с переводами "фундаментных" статей (значения, типы, операторы и т.п.). Я сам на них отдыхаю от "ЯОП" третий месяц. Работа ненапряжная, а пользы для проекта не меньше, к тому же много нового для себя узнаётся, но главное, что это поможет устранить дублирование текста по статьям. Arachnelis 08:50, 26 марта 2014 (UTC)
  • У меня в личке - могу разместить отдельным подразделом здесь, или скажите как оформить по правилам. Я не выкладывал потому как особо не надеялся, что кто-то возьмётся. Сам я иду по списку снизу вверх, желающим помочь предлагаю идти сверху вниз. Arachnelis 13:10, 26 марта 2014 (UTC)

Типовая структура статьи править

1 править

Структура статьи в целом должна содержать следующие разделы:

  1. История [языка программирования] — раздел, содержащий обзор истории развития языка (историю создания языка, историю стандартов и историю компиляторов).
  2. Введение в [язык программирования] — обзорный раздел, содержащий общую характеристику языка, и который сожжет быть написан как аннотация к основному тексту статьи.
  3. Синтаксис [язык программирования] — раздел, содержащий описание основных синтаксических конструкций.
  4. Элементы [языка программирования] — раздел, содержащий описание основных изобразительные средства, которые предоставляет язык (встроенные типы переменных, структуры, функции)
  5. Реализация [языка программирования] — раздел, содержащий описание того, какие именно реализации (компиляторы) есть и что является «комплектом поставки» (библиотеки подпрограммы, библиотеки классов и прочее)основных этапов создания программ на рассматриваемом языке программирования (например: кодирование, компиляция, трансляция, сборка).
  6. Программирование на [языке программирования] — раздел, содержащий описание того, какие парадигмы программирования поддерживает рассматриваемый язык программирования, а, также, в целом описание того, каковы изобразительные средства имеет рассматриваемый язык программирования для решения прикладных задач.
  7. Применение [языка программирования] — раздел, содержащий описание того, для решения каких прикладных задач используется рассматриваемый язык программирования (например, системное программирование, программирования под Windows/Unix и т.д. и т.п.).
  8. [Язык программирования] и другие языки программирования — раздел, содержащий описание всех связей языка программирования с другими языками программирования:
    Связь с другими языками программирования — раздел, содержащий исторические связи с другими языками программирования (в частности, влияние одного языка на другой).
    Сравнение с другими языками программирования — раздел, содержащий анализ сходства и различия рассматриваемого языка программирования с другими языками программирования.
  9. Примеры на [языке программирования] — раздел, в котором приводятся примеры, призванные продемонстрировать наиболее важные аспекты рассматриваемого языка программирования.

Это — лишь некоторый набросок, и я буду ещё уточнять его. Я оформлю предполагаемую структуру на отдельной подстранице проекта, где и вы сами сможете что-либо добавить, уточнить или, наоборот, убрать. Я хочу сделать эту заготовку таким образом, чтобы провести ревизию основных понятий, связанных с программированием, проверить отражение этих понятий в статьях Википедии, и, затем, существенно их улучшить, полностью прояснив для себя что и каким образом надо описывать в Википедии. --OZH 05:29, 21 ноября 2013 (UTC)

  • Рекомендую посмотреть избранную статью по языку программирования Python на предмет неотраженных в данной схеме пунктов (типы данных, семантика, библиотеки, разработка языка) и относительного порядка разделов. Кроме того, не все разделы следует жестко фиксировать. У Python есть признанная философия, а у Java — возможно она так не называется. В целом я за стандартизацию и предложенный вариант. РоманСузи 06:43, 21 ноября 2013 (UTC)
    • Да, в статье Python можно найти многое из того, чего хотелось бы иметь в статье о любом языке программирования. --OZH 11:57, 21 ноября 2013 (UTC)
    • Я привёл только разделы верхнего уровня. Типы данных, семантика, библиотеки — это всё — должно располагаться на следующих уровнях. Если каждый такой объект рассмотрения найдёт своё место в предлагаемой мною схеме, то хорошо. Если схема окажется в чём-то искусственной, то откажемся от искусственности. --OZH 11:57, 21 ноября 2013 (UTC)
      • Не совсем понимаю, почему элементы не относятся к синтаксису? Какие средства кроме синтаксических могут быть? Визуальные оболочки? Также такое важное на мой взгляд замечание: заголовки структуры верхнего уровня должня хорошо смотреться и в виде отдельных статьей. Как минимум, я бы убрал Элементы и назвал раздел Синтаксис и семантика. КРоме того, реализация на мой взгляд слишком близка к началу. Можно ее немного вниз сдвинуть. РоманСузи 14:26, 21 ноября 2013 (UTC)
        • Очень хорошая мысль про отдельные статьи! Я так и думал. Не стоит бояться некоторого дублирования, тем более, что статья про язык программирования — это б-о-оольшой обзор, и было бы самонадеянным отделаться парой строк там, где в источниках написаны целые главы (а то и целые книги!). Но у каждой статьи в Викиепдии свой предмет. Вот и у раздела статьи тоже должен быть свой предмет. Синтаксис — это набор тех средств, при помощи которых программист вводит те объекты, которые ему нужны. Таким образом, в разделе про синтаксис мы описываем, например, как определить класс, а в разделе про элементы описываем классы как таковые. Вполне возможно, что разделение синтаксиса и семантики несколько притянуто за уши, но я хочу попробовать их развести (что, мне кажется, более отвечает энциклопедичности) и посмотреть, что получится. А аргумент про отдельные статьи — это ещё один аргумент в пользу разделения синтаксиса и семантики. --OZH 10:49, 22 ноября 2013 (UTC)
        • Как примеры элементов, не имеющих отношения к синтаксису: ленивость и типизация Хиндли-Милнера. Arachnelis 09:52, 23 ноября 2013 (UTC)
        • Новые объекты программист вводит далеко не только при помощи синтаксиса. Между "int a = 5;" и "(define a 5)" разница существенная, и кажется сугубо синтаксической лишь по незнанию. Arachnelis 09:55, 23 ноября 2013 (UTC)
    • Да, про Python весьма неплохая статья. Arachnelis 10:49, 23 ноября 2013 (UTC)
  • а где раздел про краткий обзор имеющихся библиотек? я про наличие хороших библиотек для той или иной области применения. например, если язык не имеет библиотеки для работы с базами данных, то для работы с ними (каким бы он не был замечательным) он будет с практической точки зрения бесполезен. потому что, на практике, мало какой менеджер отвечающий за проект согласится специально выделить время разработчикам для написания отсутствующих библиотек. то же самое и с другими областями практического примения(Idot 10:14, 21 ноября 2013 (UTC))
    • Тут вопрос в том, являются ли библиотеки частью реализации. Часть функций являются реализацией стандарта. Некоторые библиотеки поставляются с конкретным компилятором. Я предполагаю упоминать библиотеки в трёх разделах: Реализация [языка программирования], Программирование на [языке программирования] и Применение [языка программирования]. Но это всё будет ясно, когда я попробую уложить в эту схему статью «C++». Также не вижу ничего предосудительного в том, чтобы в статье существовал раздел, в котором говорится, что такой-то вещи в данном языке программирования нет. Это тоже важная энциклопедическая информация: раз нет, то и бессмысленно искать. --OZH 11:57, 21 ноября 2013 (UTC)
      • В статье про Go так и написано: «В Go отсутствуют такие возможности как: …» РоманСузи 20:51, 24 ноября 2013 (UTC)
      • Наиболее значимые библиотеки должны быть в статье. Насчет «отсутствует», то, наверное, следует заострять внимание только на самые яркие вещи (множественное наследование в Java, goto в Python, …). Было бы хорошо, если бы во введении были указаны принципы проектирования языка — какие цели стояли перед разработчиками. РоманСузи 14:26, 21 ноября 2013 (UTC) Попробую сделать анализ структур существующих статей о языках программирования де-факто в Википедии. РоманСузи 14:31, 21 ноября 2013 (UTC) Проанализировал: "введение", "элементы" и "программирование" не встречаются — предлагаю заменить. О парадигмах можно в преамбуле, элементы - наверное в синтаксис. Мой вариант выглядел бы так:

2 править

См. Участник:РоманСузи/Структура статьи по языку программирования

  1. История (в том числе влияние других языков на данный)
  2. Философия, Основные принципы/концепции, Обзор, Парадигмы программирования или т. п., где среди прочего описываются цели создания, теоретические основы и тп
  3. Основные понятия (подразделы в зависимости от количества материала: семантика, элементы: алфавит, лексемы; синтаксис, структура программы, структуры данных, определения, выражения, операторы, директивы, области видимости, пространства имен, модули, пакеты и т.п.)
  4. Библиотеки (здесь о стандартной библиотеке и об устройстве библиотек вообще, включая средства дистрибуции)
  5. Реализации, в том числе связь с аппаратными реализациями (если есть), портируемость
  6. Программирование и среды разработки (о стиле, документировании, тестировании, а также наиболее значимых инструментах)
  7. [Язык программирования] и другие языки программирования
    Связь с другими языками программирования (встраивание, использование библиотек, влияние и т.п.)
    Сравнение с другими языками программирования (возможности, производительность, тренды, распространение и т.п.)
    Критика (иначе участники все равно будут упорно это добавлять и будут правы)
  8. Применение (в том числе приложения и библиотеки, которые сделали язык популярным. Например, Ruby on Rails для Ruby).
  9. Версии и стандарты
  10. Примеры кода, Hello, world и т.п. (если статья маленькая - иначе при разборе синтаксиса-семантики выше)

Тем не менее, в зависимости от языка могут потребоваться и другие разделы. Например, Perl имеет раздел о поэзии. РоманСузи 19:42, 21 ноября 2013 (UTC) Пожалуйста, заметьте, что я попытался сделать структуру на основании того, что фактически делается в Википедии, чтобы предлагаемая «стандартизация» была более консенсусной. Кроме того, чтобы из названий было в основном ясно, о чем где писать. РоманСузи 19:47, 21 ноября 2013 (UTC) Есть такая книга "Профессиональное программирование. Системный подход" Игоря Одинцова. Там все так хорошо разложено по полочкам, что выдумывать ничего не нужно: классификация, характеристики, семейства языков и т.д. РоманСузи 19:59, 21 ноября 2013 (UTC)

Думаю, это хороший ход - посмотреть и отчасти заимствовать структуру из печатных изданий (можно сюда выписать «полочки» из Одинцова?), или, для начала, список книг-аи, в которых можно посмотреть структуру. Стоит поискать обсуждения в en-вики и учесть оформление их статусных статей, чтобы проще ориентироваться после перехода по интервикам. ~Sunpriat (обс) 08:17, 22 ноября 2013 (UTC)
  • У Одинцова нет конкретно по языку программирования, скорее у него хороший материал для структурирования знаний по программированию вообще (и он дает первоисточники) (в Википедии со структурирование знаний на тему программирования большая проблема!). Но для примера приведу Языковые абстракции:
  • Абстракция данных
  • Абстракция управления
  • Абстракция модульности
В статьи их можно называть так или эдак, но все три вида абстракций должны быть в статье. Кроме того, где-то нужно описать характеристики языков: уровень языка, мощность, концептуальная целостность, и другие (надежность, удобочитаемость, полнота, гибкость, переносимость, эффективность реализации и т. п., место в эволюции языков, классификация: по поддерживаемым методологиям (императивное, ФП, ООП, логическое, в ограничениях), принадлежность к семействам (универсальные, уникальные, параллельного программирования и т. п.), по ориентации на предметные области (от языков разметки до языков описания аппаратуры), по степени абстракции от аппаратуры (низкий — ассемблер, и выше). Конечно, эта классификация — творение одного автора, но я не видел попыток столь грандиозной классификации, и кроме того, эта классификация не является его исследованием: он обобщает источники. РоманСузи 09:12, 23 ноября 2013 (UTC)
Как раз хорошая абстракция - это когда абсолютно невозможно из контекста использования понять, что это - данные, или методы, или ещё что. А "Сравнение с другими языками программирования" и "Критика" - порой могут тесно пересекаться (в случае с С++ это вообще одно и то же), так что лучше, как в статье про Python - "критика" входит в состав "сравнения". Попробуйте поглядеть на моё творение: Предметно-ориентированный язык - это, конечно, набросок, но, надеюсь, поможет. Arachnelis 10:49, 23 ноября 2013 (UTC)
Возможно, я не совсем точно донёс смысл абстракций. «Хорошесть» абстракции, конечно, можно понимать по её близости к спецификации результата (и отдалении от вопроса «как»). Однако, от этого наша задача по описанию языков программирования не облегчается: языки остановились на определённых методологиях и в статье по C рассуждения о концепциях обобщённого программирования с крутыми абстракциями едва ли будут хорошо восприняты. Критика может быть и в составе сравнения, но межъязыковая критика — это одно (и она достаточно дешева), а есть ещё критика внутреннего развития. Например, разработка от Python 2 к Python 3 была отчасти вызвана критикой Python 2. То есть, когда сам автор языка и сообщество осведомлены о проблемах. РоманСузи 15:43, 23 ноября 2013 (UTC)
Со сказанным по большей части согласен. Единственное - в Си средства абстрагирования особо и не претендовали на то, чтобы быть качественными и сильными - он же разработан в качестве кроссплатформенного ассемблера, а тут не до абстракций. Arachnelis 16:12, 23 ноября 2013 (UTC)
IDE (если есть) там же где и стандартные библиотеки? (так как, после распространения визуальных средств разработки, нередко на них завязан) Idot 10:56, 22 ноября 2013 (UTC)
Я стараюсь максимально развести разнородные аспекты и советую другим тоже избегать смешения. Выводить библиотеки и среду разработки на верхний уровень в статье о языке — не очень удачная идея. Я же предлагаю найти оптимальную структуру. Но об этом всём довольно трудно разговаривать без живого примера. Надо будет сначала посмотреть, как это будет выглядеть на практике, а то многие вопросы возникают из-за того, что наши рассуждения — это рассуждения из общих соображений. Постараюсь за выходные переписать статью «C++» по новой форме, и тогда наш разговор станет предельно предметным. --OZH 11:09, 22 ноября 2013 (UTC)
  • Это может быть и так, но следует учитывать, что статья про С++, Java — монстры. Если ставить более общие цели, то иерархию стоит продумывать с расчетом и на языки, по которым будет написано не так много. Кроме того, структура статьи не должна вызывать удивления — иначе люди заблудятся в ней. Поэтому я и предложил свой вариант, в котором минимум искусственных авбстрактных структурообразующих пунктов. Например, у Вас есть Элементы и есть Синтаксис. Я посмотрел в книжках и руководствах по языкам — элементы языка — это алфавит, лексемы и т. п., то есть, это тесно связано с синтаксисом, а не с функциями и т. п. Разумеется, можно придумать какую угодно структуру для статьи, но легче всего люди (как редакторы, так и читатели) будут воспринимать что-то знакомое, узнаваемое. Например, а какие библиотеки есть для языка и откуда их получать? А какие циклы и вообще основные конструкции? (синтаксис) И в длинной статье оглавление служит этой цели (без примечаний типа «раздел, содержащий описание того, какие парадигмы программирования поддерживает…»). И т. п. С другой стороны, редактор, который хочет дополнить статью, должен как можно более однозначно найти нужную полочку в структуре. Заметьте, что я не хочу затягивать обсуждение - но в предложенной Вами структуре есть 3-4 проблемы, которые я указал. РоманСузи 08:36, 23 ноября 2013 (UTC) PS. Скопируйте в личное пространство C++ и перекидайте материал крупноблочно в соответствии с предложенной Вами структурой - это уже много даст для размышления. РоманСузи 08:40, 23 ноября 2013 (UTC) Не заметил Вашей последней фразы: конечно, перепишите на месте — это статью не испортит! РоманСузи 09:15, 23 ноября 2013 (UTC)
    • Вы всё правильно пишете, даже то, что я ещё не написал, но ещё подразумеваю. И, конечно, я не буду вводить какие-либо дополнительные разделы без чёткого понимания того, что должно быть в вводимых мною разделах. Проблема написания статьи про «C++» заключается в необходимости сначала написать статью про «Си». Я посмотрел статью про «Си» и обнаружил, что это ещё только заготовка статьи о языке программирования, и, в первую очередь, необходимо описать аспекты, связанные с языком программирования «Си», и уже при написании статей, связанных с языком программирования «C++» существенным образом опираться на уже существующие статьи по «Си». Наиболее важный аспект — это синтаксис, с него и придётся начать в первую очередь. --OZH 09:41, 23 ноября 2013 (UTC)
    • Попробуйте с вашим подходом к структуре языка изучить Рефал. Для того, чтобы начать писать на нём, вики-статьи хватает, а мощь языка колоссальна - парсер Виртовского Паскаля пишется out-of-a-box (т.е. безо всяких сторонних библиотек) играючи за полчаса-час. Однако, все опытные программисты на императивных языках, которых я наблюдал, приходят к выводу "у меня нет такой травы, чтоб понять". Arachnelis 11:19, 23 ноября 2013 (UTC)
      • Понятно, что Лисп или Forth имеют простой синтаксис. Тем не менее, структура статьи от этого может и не зависеть (только пропорции объёма разделов), так как Основные понятия будут расти на более крупноблочных конструкциях кода. Какой «универсальный» (это короче, чем каждый раз «общего назначения») язык ни возьми, в нём будут «вырастать» «идиоматические» решения, адекватные решаемым задачам. Парсер напишется ещё быстрее на специализированном языке или при помощи специализированной библиотеки в универсальном, и что теперь? Сложность никуда не девается. Когда я предлагал свою структуру, я рассматривал структуры статей по разным языкам, в том числе и Лиспу (про Форт забыл, но там структура весьма посредственная). Есть ещё такой момент. Если бы статья в Википедии была учебником, то абстракции управления и данных следовало бы рассматривать параллельно, по нарастанию сложности. В статье Википедии порядок может быть иным, так как здесь можно раскладывать по полочкам и делать ссылки. Цель настоящей дискуссии выработать типичную структуру, чтобы редакторы могли на неё ориентироваться. РоманСузи 16:14, 23 ноября 2013 (UTC)
        • К разделам "история", "реализации" и т.п. претензий нет. Но это всё окружение, вода, так сказать. Вот "мясцо" - это проблема. Возможно даже, проще окажется для него не задавать единую структуру. Возможно, будет резонно пересекать описание сразу с критикой (описали множественное наследование классов, и сразу объяснили связанные с ним сложности). Arachnelis 20:55, 23 ноября 2013 (UTC)
        • Они "там" не ленятся всегда писать "general purpose". Я нигде, ни разу, ни в одной самой замшелой статейке не встречал словосочетания "universal programming language". Даже специально гуглом проверил — нашёл лишь один мутный проект "язык мечты UPL" (Universal Programming Language), где авторы целенаправленно взялись за это гиблое дело. Больше никто эти слова рядом не ставит. Предлагаю отвыкать, а в статье "Язык общего назначения" мельком приписать, что дескать "в угрёбищной русской литературе можно встретить такой неправильный термин".Arachnelis 11:10, 27 ноября 2013 (UTC)
  • Кстати, в книге по Эрлангу, которую я сейчас читаю (Cessarini et al. Erlang Progrmming) в разделе о сравнении С++ и Erlang, если замечательные слова к нашей дискуссии:

When comparing programming languages, however, you must benchmark whole systems in the application domain for which those languages were designed, not code snippets or simple functions.

РоманСузи 10:44, 24 ноября 2013 (UTC)

    • Разумеется. На хеллоуворлдах все языки примерно одинаковы. В связи с чем я весьма негодую, что нельзя сослаться на независимый бенчмарк ЯЗЫКОВ с ffcounsultancy - там хоть и тоже не шибко большая задача, но бенчмарка на более крупной мы ещё не скоро дождёмся. Arachnelis 15:46, 24 ноября 2013 (UTC)
      • бенчмарки нужно делить на группы: на многпроцессорный и на одном процессоре, потому что на одном процессоре и C и Forth уделают любой язык паралельного програмирования, а вот в на многопроцессорной системе - наоборот (Idot 15:52, 24 ноября 2013 (UTC))
        • В этом есть резон. Но есть и языки, семантика которых имеет огромный потенциал к оптимизации, и для таких языков могут появляться компиляторы, способные утереть нос всем остальным на любой машине. Пример - компилятор MLton для SML, доказательство - на ввв-ffconsultancy-дотком/languages/ray_tracer/ Arachnelis 11:10, 27 ноября 2013 (UTC)
  • В наших структурах отсутствует (или неочевидно), в каком разделе описывать вопросы, связанные со стилем программирования (style guide), тестирование, документирование, профилирование и т. п. периферийные темы, которые тем не менее являются очень зависимыми от языка и для полноты изложения требуют упоминания. В своей структуре добавил к средствам разработки. Встретился с этим, уже почти заканчивая статью Erlang к (надеюсь) подходящему для избранной статьи виду. РоманСузи 06:49, 2 декабря 2013 (UTC)
    • В "неформальном описании" - оно как раз и подразумевает определение элементов с немедленным рассмотрением возможностей их использования. Arachnelis 13:15, 8 декабря 2013 (UTC)

3. Трудности структуризации править

Раздел «Введение» и раздел «Программирование на [языке программирования]» править

Пришёл к следующему выводу: очень нужен обзорный раздел, предшествующий описанию синтаксиса, реализации и примеров применения языка, и содержащий краткий обзор того, что же это за язык и с чём его едят, какие стили, подходы и парадигмы он поддерживает. Отсюда вытекает и назначение раздела «Программирование на [языке программирования]»: в таком разделе следует описывать то, какие задачи решаются при помощи описываемого языка программирования, и какие изобразительные средства (как на уровне синтаксиса, так и на уровне реализованных библиотек функций и/или классов) предлагает рассматриваемый язык программирования. Этот раздел было бы удобнее оформить в виде тематических блоков, соответствующих решаемым задачам. --OZH 09:53, 23 ноября 2013 (UTC)

Раздел «Возможности» править

У меня пока затык в другом месте. Пока что не нашел ничего лучшего, чем использовать раздел Возможности (как это сделано в статье Python) для «изюминок», о которых говорят источники по Erlang. Подумываю добавить к структуре. РоманСузи 14:26, 24 ноября 2013 (UTC)

4. Подструктура неформального описания править

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

== Язык ==
=== Общая характеристика ===
==== Философия, идиоматика, идеология ====
==== Поддержка верификации программ ====
==== Результативность разработчиков ====
=== Система типов ===
=== Значения и модель вызова ===
==== Конкурентность ====
=== Абстракция данных ===
=== Абстракция функций и полиморфизм ===
=== Модульность, инкапсуляция, проектирование ===
=== Метапрограммирование ===
=== Синтаксис и синтаксический сахар ===

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

=== Модульность, инкапсуляция, проектирование] ===
С++

В С++ нет специальных средств обеспечения модульности и инкапсуляции, их роль играют средства абстракции данных. Дополнительно доступна конструкция выделения пространства имён, позволяющая нестрого инкапсулировать глобальные и статические определения в идентификаторе, полностью устраняемом в процессе трансляции. С++ не поощряет "проектирование прототипированием", как ML, Haskell или Erlang. При использовании в разработке С++ становится очень важным внимательно продумать все детали архитектуры перед началом собственно кодирования (см. Waterfall), и для этой цели традиционно применяется UML. Ошибки, допущенные при проектировании, обходятся дорого (цитата Линуса Торвальдса). нет отделения интерфейса от реализации, всё описывается в едином публичном блоке кода и изменения требуют рекомпиляции всего проекта (Joyner, loc=3.34, с.34) бла бла бла

Standard ML

Язык ориентирован на разработку больших и сложных программных систем. Для обеспечения модульности и инкапсуляции поверх ядра языка (Core Language) предусмотрена развитая система модулей, косметически повторяющая модель значений и вызовов ядра. Определения ядра инкапсулируются в структуры, а их абстрагированием можно гибко управлять при помощи сигнатур. Абстракция структур, в свою очередь, осуществляется посредством функторов, за счёт чего изменение интерфейса модуля требует перекомпиляции не всего проекта, а лишь зависимых от него функторов. В SML, как и во многих ФЯ, практикуется "проектирование прототипированием". бла бла бла

Arachnelis 08:33, 26 декабря 2013 (UTC)

Забыл добавить, что у такой структуры есть одно преимущество с т.з. тех, кто со мной не согласен, и одно с т.з. тех, кто меня поддерживает.
Второе - это то, что и сама наукообразная структура, и страшные слова в ней, скорее всего, отпугнут большинство быдлокодеров, что обеспечит статьям несколько лучшую стабильность. Например, перегрузка операторов в С++ здесь имеет строго определённое место - как средство ввода синтаксического сахара в программу - а не размазывается по нескольким параграфам, будто бы на ней свет клином сошёлся. Определённое строго место полиморфизма также не даёт права на типичную для Алголоподобных языков ложь в этом вопросе (ибо полиморфизм - это значит полиморфное поведение, т.е. единообразное использование разнотипных данных; данные же полиморфными не бывают).
Первое же преимущество - то, что в спорном разделе "Достоинства и критика" отпадает нужда. Выделение в шаблонную структуру языковых (а не синтаксических) элементов поощряет к тому, что особенности их реализации будут неотъемлемо зашиваться в текст со ссылкой на идейные предпосылки к их появлению и к хронологии их наследования из языков-предков. Что и даст нам эту вашу непредвзятость и нетрибунность. Например, сразу проявится, что С++ от Симулы наследован со значительными искажениями, что ООП в С++ вовсе не точно такое же, как в Симуле, да и конструкции конкурентного программирования кудай-то затерялись - недостатки выплыли, но обвинить критиков в предвзятости тут уже не удастся (зато предвзятость фанатов станет видна невооружённым глазом, если они начнут лепить оправдания или просто удалять текст). Объём и сложность статей также не будет подлежать обвинениям в предвзятости - бОльший объём текста будет выплывать лишь из объективной сложности самого языка - и тогда не придётся ни критиковать, ни вкручивать формулировки типа «расплаты за то-сё» - читатель из холодного энциклопедического текста сам увидит, что язык А тяжелее в использовании, чем язык Б, потому что надо следить за бОльшим числом деталей, и сам сделает вывод, является ли скорострельность веским оправданием за это.
Если в конкретном языке напрочь отсутствует что-то из этой структуры - раздел не убирается, а в нём прямо и пишем об отсутствии. Для HTML/XML в разделе "Значения и модель вызова" указываем, что язык не Тьюринг-полный, так что никаких вызовов нет. Для VB/Delphi в разделе "Метапрограммирование" пишем, что возможности МП в самом языке отсутствуют, зато IDE накатывают поверх него всякие GUI-билдеры, ORM и прочую лобудистику, как слабые формы порождающего программирования. Для Эрланга или Рефала их ключевые особенности, очевидно, попадут в "Значения и модель вызова" - т.о. экзотические языки не будут нарушать строй статей. Для каждого метаязыка в разделе "Метапрограммирование" первой строкой пишем, что он для него непосредственно и предназначен, второй - что компиляторы для любых языков на нём пишутся как два пальца обосфальт, в следствие чего bootstrap весьма распространён.
Для С++ философия не размазывается по каждой строчке - можно чётко написать, что это один из немногих языков, где автор диктует помимо самого языка ещё и правила его применения, но его советы не всеми соблюдаются, так что общая идеология С++ размыта. Каждый элемент языка определяется "как есть", и какие бы демагогии не подписывались фанатами, утаить отличия от аналогов в других языках не удастся, равно как и степень необходимости/лишнести. Унаследованные от Си элементы С++ выбросить из рассмотрения оказывается невозможно - каждый упоминается как унаследованный, и если это наследие для данного элемента оказывается "тяжёлым", то от этого тоже никак не уйти. Например, в "Значения и модель вызова" пишем так: «В С++ доступны call-by-value и call-by-reference, выбор для каждого контекста осуществляется программистом явно. Кроме того, в определённых случаях при вызове функции осуществляется копирование параметра (вызов конструктора копирования), после чего копия передаётся по ссылке. В Си был только вызов по значению и для эмуляции вызова по ссылке использовался специальный тип - указатели. С++ унаследовал и их, в результате чего модель вызова утратила очевидность при использовании (в одних случаях приходится искусственно избегать копирования объекта, в других, напротив, явно создавать временный объект)» - и поднимите руки, кто может оспорить такую формулировку. Про раздувание кода полиморфизмом - непредвзято уже написано в статье "полиморфизм", так что "спор ссылок" о том, значительно это раздувание или терпимо, становится бессмысленным: в С++ оно просто есть, а в некоторых других языках (даже в Си) его нет.
Эволюция С++ опять же станет видна объективно (сиречь как недостаток), без иезуитской демагогии про «да, раньше было плохо, но теперь всё будет по-новому». Лично я считаю, что в энциклопедии изложение должно идти в стиле "о вечном". А это значит, что надо писать, что С++ является непрерывно эволюционирующим языком, т.е. пока он жив, всегда будут проблемы обратной совместимости, и всегда будет необходимость изменять уже отлаженные программы. OCaml имеет те же недостатки - непрерывная эволюция и страшно громоздкий синтаксис - но на него и стандартов не выпускается, и реализация всего одна, портабельная подо что угодно сама по себе безо всякого стандарта. Т.е. вместо громких деклараций «вот так вы все должны писать компиляторы, но формальную спецификацию мы вам определять не будем», его разработчики определяют формальную семантику и собственноручно следят за её реализацией. Не нравится - не ешь. То же самое и в Python. И ни окамлисты, ни питонисты не станут обижаться на критику в вопросе эволюции. В С++ же сейчас изложение идёт примерно так: «вот, наконец, дождались... нет, вот, теперь наконец дождались... ой, тут придётся исправить старую проблему... нет, эта проблема определена стандартом, а значит она не проблема... а, теперь проблема устранена, можно признаться, что она была... ой, тут ещё проблема... но зато язык стандартизирован!!! И будет ещё неоднократно стандартизирован! Самый стандартный язык из всех, с чётко определёнными стандартом проблемами!».
Заметьте: в структуре не предусмотрено место для "стандартной библиотеки". Это не упущение. В С++ без STD - как в анекдоте - всё равно что опять за ЕС садиться. Зато для метаязыков её можно легко выбросить и переписать с нуля, а то и вообще обойтись без. Во многих языках (даже в Java) стандартная библиотека бутстрапится над языком, который в голом виде почти ничего не умеет, зато является целостной самодостаточной системой. Кроме того, одни и те же возможности в одних языках зашиты в примитивы (и при выбрасывании примитивов никак обратно в язык не вводятся); в других воплощаются естественным образом (т.е. при выбрасывании примитивов или стандартных библиотек тут же воспроизводятся собственноручно); в третьих подключаются через громоздкие библиотеки, которые адепты держат под стеклом и берегут как святыню; в четвёртых - раз за разом кодируются паттернами (т.е. нужно проектировать то, что в других языках записывается одной строкой или даже не записывается вообще, а просто подразумевается). И в каждом случае характеристики качества свои. В С++ язык темплейтов не предоставляет никаких средств для оптимизации, поэтому эффективность библиотек заведомо ограничена, и ad hoc решение в частном случае может оказаться эффективнее. И это всё важно отмечать, не позволяя перечислять "широту возможностей" STD на правах достоинств языка. Достоинством в этом смысле является низкая трудоёмкость собственноручного переписывания возможностей STD и её расширения.

Имеет смысл добавить отдельным разделом "конкурентность" подразделом в "модели вызова". В Симуле и Аде для неё есть примитивы, но С++ её не унаследовал, и надо городить городушки (проектировать то, что в других языках пишется одной строкой). В Lisp-ML-Haskell конкурентность делается при помощи продолжений. Эрланг основан на пи-исчислении, так что непосредственно под заголовком "Значения и модель вызова" пишем о данных, потом говорим, что все вызовы конкурентны, и входим в подраздел (само использование пи-исчисления в качестве основы для Эрланга раскрываем в "Общей характеристике").

Сим прошу голосовать (но только тех, кто знает чуть побольше, чем всего лишь набор одинаковых и однообразных потомков Алгола).
И ещё у меня есть отдельное предложение: для каждого (без исключения) языка в название статьи добавить постфикс «(язык программирования)», а ещё лучше - более общий постфикс «(информатика)». Имена в информатике дублируются не так часто, и в случае дисамбига разрешаются более полным наименованием, зато дисамбиги с другими сферами возникают спонтанно, и в результате сейчас "кто в лес - кто по дрова". Более того, согласно изоморфизму Карри-Ховарда (лучше на английском), proofs can be run, т.е. доказательство корректности балансирует на грани между теоретической моделью и языком программирования. Аналогичную двойственность имеют и ΤΕΧ, и денотационная семантика, и БНФ, и ещё много чего, даже M$Excel - см. DSL. Бывает, что в старых статьях появляются красные дисамбиг-полоски, ведь за всем не уследишь. С не-Тьюринг-полными языками типа XML или SQL обратная проблема - скажи "язык программирования", и найдутся негодующие. А заголовки типа «XML (информатика)» в большинстве случаев будут "раз и навсегда". Arachnelis 14:02, 26 декабря 2013 (UTC)

  • Как-то раз я присутствовал при спора двух участников о том, какой должна быть конкретная статья (по статистике). Один городил максимально абстрактные формулы, другой настаивал на сильно прикладном подходе (они, кажется, даже умудрились править каждый свою статью на одну и ту же тему). Поэтому, не читая сильно других обоснований, считаю эти обоснования серьёзно нарушающими ВП:ПДН ("страшные слова в ней, скорее всего, отпугнут большинство быдлокодеро"). Общая направленность (насолить С++) не придаёт обоснованию веса, так как создаётся впечатление, что структура специально придумана для дискриминации C++. Будем считать, что мы пишем для обычного читателя, а ему нельзя навязывать понимание неких произвольно выбранных теоретических построений от computer science. Уверен, что язык программирования можно описать без сильной теоретизации (сам этим страдаю) и в то же время энциклопедично. Кстати, что за "конкурентность"? Это от concurrent что-ли? На русском, конечно, нет удачного перевода, но этот коробит слух. Я против и добавления "(язык программирования)" ко всем названиям - это часто излишне. Здесь предложено уже три структуры. В рецензии по Erlang рецензентом высказаны и другие мысли. Я всё больше начинаю думать, что может ли в принципе быть единая структура? РоманСузи 16:05, 26 декабря 2013 (UTC)
    • С++ я приводил в пример как горячую тему, и постарался на конкретных частных примерах фрагментов текста показать, что как раз стараюсь максимально поднять объективность и пресечь излишне предвзятые правки (с ним проблема именно в превалировании фанатизма). Конкурентное программирование - широко используемый термин (по крайней мере, в англоязычном сообществе), и меня удивил перевод "конкуренции" в "параллельность" - почти в антоним. Некоторые названия коробят слух и по-сильнее, но мы же должны быть объективны? Про Эрланг статью ещё не глядел, посмотрю потом. Думаю накидать в личке грубые наброски пятка статей для демонстрации подхода (передеру текст из имеющихся) - пока решил предложить структуру для осмысления другими участниками. Arachnelis 17:48, 26 декабря 2013 (UTC)
      • Собственно, противосиплюсплюсный пафос как раз и мешает воспринять структуру, так как здесь мы обсуждаем большое множество языков и такая завязка на С++ сильно искажает. По поводу concurrency — я не смог найти упоминания в солидных источниках (которые не дружат с ложными друзьями переводчика) перевода «конкуренция». Поэтому и интересно, где Вы взяли такой перевод? По существу структуры: модульность, инкапсуляция, проектирование — это так или иначе «Сокрытие данных» в той или иной степени (по Дэвиду Парнасу, если память не изменяет)? Где сферы применения и «надсистемы»? Где нефункциональные аспекты (надёжность, например)? Юзабилити? Что значит «Результативность разработчиков»? Раздел критика, как я уже где-то говорил, не упрячешь: сразу спросят, если статью выше уровня 3 пишешь. Это обычно то, что ищут и спрашивают. Как систему типов отделите от абстракции данных в энциклопедической статье (какой язык ни возьми, модель данных, управления и модель сокрытия/организации кода/данных — его определяют, но нужно ли это явно вычленять, чтобы разделить?)? Такая структура хороша для академической диссертации, но в Википедии нужно писать более просто, не с высоты башни из слоновой кости. Ещё один аспект. Структура должна не только быть эффективной «по чтению», но и писать по ней должно быть просто. Некоторые вещи днём с огнём в источникам не найдёшь. Например, с Erlang повезло — кто-то написал на тему «метапрограммирование» страницу. Но я в статью по Erlang включить не могу, так как даже при указании источника будет выглядеть ориссом, как и рассуждение целых двух гуру о том, что Erlang — самый ООПэшный язык в мире, так как именно передачу сообщений (и изоляцию), а не классы Алан Кэй (третий гуру) имел в виду главным в своих принципах ООП. Де-факто, раз уж взялись за дизайн статьи по языку программирования вообще, давайте учитывать реалии, как читателей, так и имеющихся источников. И, как я говорил, сейчас Erlang проходит рецензирование на избранную статью, и я надеюсь, что ход этого процесса будет полезен для данной дискуссии. И ещё. Куда у Вас раздел История делся? Он — самый распространённый в статьях по ЯП, на эту тему отдельные конференции проходят en:HOPL. Полагаю, что нужно взять какой-нибудь язык программирования, который приглянулся, и официально довести статью до уровня хорошей/избранной. Поэтому я пока не готов сильно спорить. От этой «горячей темы» C++ уже просто тошно. Забавно, что по многим обсуждениям у нас взгляды обычно сходятся, за исключением понимания методов работы в Википедии. РоманСузи 18:37, 26 декабря 2013 (UTC)
        • Ну, за методы необессутьте - я таки тут новичок. Я не против использовать в рассуждениях любые примеры - можно и Питон брать, он тоже мультипарадигменный. То, что инкапсуляция и сокрытие - не одно и то же, источников много: в аспекте нашего набившего аскомину языка миф о тождественности этих понятий развеивает Джойнер, а в ФП кортежи ничего не скрывают (инкапсулируют без сокрытия). В Питоне сокрытие вообще отсутствует. Надёжность у меня есть - "поддержка верификации". Там как раз следует писать и про встроенное док-во корректности в ФЯ, и про внешние статические анализаторы. Юзабилити языка - это что? Я, уж извините, этот термин привык в иных целях использовать. Удобство и элегантность как инструмента, как я сказал, раскрываются по ходу. Сводную критику, если надо, можно и приписать - но до сих пор меня за неё ругали, так что я и постарался от неё избавиться. Стиль же изложения я не навязываю - структура призвана упорядочить изложения и защитить от "каши". Про конкурентное программирование поищу что у нас тут есть переводное (я же обычно английские работы читаю), но международный общепринятый термин, повторюсь, "concurrent programming" или "concurrency". Arachnelis 19:09, 26 декабря 2013 (UTC)
          • Не имею в виду, что инкапсуляция и сокрытие — одно и то же. Я к тому, что сокрытие — это более общий термин, а «проявления» сокрытия в разных ЯП разные. Я просто пытался спросить, означают ли три сложенные вместе термина как раз сокрытие? Верификация — это как-то очень жёстко, если Вы имеете в виду формальная верификация. Usability of programming languages - например http://www.cl.cam.ac.uk/teaching/1213/R201/, можно погуглить, но в общем-то удобством можно назвать. Заметьте, что в этом плане стоит понимать, что, скажем, на Java код могут писать кодогенерацией из UML и т. п., поэтому кому-то может быть странным вообще постановка вопроса об элегантности синтаксиса и т. п., что важно для тех, кто пишет на языке непосредственно. О сводной критике — я даже не знаю. Ругали за обилие критики, наверное. Об английских терминах я не спорю (речь о переводе). Например, не нахожу ни одного примера или фразы, скажем, при помощи http://www.multitran.ru . Мы не можем вводить в Википедии свои переводы терминов, даже более удачные. См. также Параллелизм (компьютерные науки). РоманСузи 20:00, 26 декабря 2013 (UTC)
  • Про раздел "История" я вовсе не забыл - напоминаю, что это были подразделы описания собственно языка, а не структура статьи целиком. Какой термин брать за основной для конкурентности - решим отдельно (кстати, Лингво тоже мне дал перевод "concurrency" как "параллелизм"), но как минимум есть смысл сделать два редиректа - "Конкурентное программирование" и "Конкурентность (информатика)" (или "Конкурентность (программирование)") - ибо раз я пытался искать именно по ним, то и другие могут. А почему сейчас "Параллелизм (компьютерные науки)", а не "Параллелизм (информатика)"? Кстати, я могу сам создавать редиректы, или лучше не стоит? Я многое поправил, приведу структуру полностью:
= Место и роль в информатике =
= История, философия, терминология =
= Критика = /или/ = Общая характеристика =
== Удобство ==
== Результативность ==
= Язык =
== [[Система типов]] ==
=== Значения и модель вызова ===
==== [[Параллелизм (программирование)|Параллелизм]] ====
=== Агрегатные типы и [[абстракция данных]] ===
=== Абстракция функций и [[Полиморфизм (программирование)|полиморфизм]] ===
=== [[Модульность]] и [[проектирование]] ===
== [[Метапрограммирование]] ==
== [[Синтаксис]] и [[синтаксический сахар]] ==
= Реализации =
= Примеры программ =
= См.также =
= Примечания =
= Ссылки =
= Литература =
"Инкапсуляцию" из структуры убрал, ибо она действительно блуждает между просто агрегатными типами и модульностью/проектированием. Но вот абстракция данных - это не во всех языках опора для модульности. Если в языке нет отдельных средств для модульности - так и запишем (и это будет повышение объективности, т.к. отсутствие не будет ускользать от внимания безо всякой дополнительной критики), а если есть - для этого нужно место. Примитивные типы не требуют отдельного раздела - при их наличии в языке они прекрасно разместятся в разделе "Значения и модель вызова", при отсутствии - в "Агрегатные типы и абстракция данных".
Характеристики качества (в т.ч. "надёжность", согласен на такой вариант, и "юзабилити") будут в разделе характеристики/критики, как бы мы его не назвали. Кстати, понятие "критика" не обязательно подразумевает "ругание" - критическая оценка бывает и положительной, а объективная критика вообще обязана в полной мере раскрывать достоинства и недостатки. Я думаю, в нём самое главное выделить характеристики при взглядах изнутри (от программиста) и снаружи (от заказчика) - зачастую раскрывается лишь первое, хотя конкретный читатель может как раз искать второе. Сложность менеджмента может отмечаться и здесь, и в "Модульность и проектирование", в зависимости от текста для конкретного языка.
Можно назначать структуру жёстко лишь на 1-2 уровне, и по мере спуска к подразделам всё лояльнее позволять их склеивать или дробить, но только в случае действительных на то оснований со стороны семантики языка. Т.е. по умолчанию структура назначается на копипасту целиком, но если в процессе заполнения её текстом неизбежно возникают неэлегантные пересечения разделов, то по итогам обсуждения нижний уровень может слегка подвигаться.
Плохо, что сейчас "Примеры программ" идут "кто в лес - кто по дрова" и изобилуют выводом строки "Hello, world". В энциклопедии гораздо показательнее и полезнее для читателя будут полноценные решения канонических задач длиной хотя бы в пол-экрана - только так можно оценить лаконичность языка. Как я уже сказал, их можно брать с shootout.debian и подобных ресурсов (ведь там их тоже не случайно выбирают, а ради объективности), и изобретать свои лишь при их отсутствии. Думается мне, что примеры лучше поместить в самый низ, чтобы текст было удобнее прокручивать, если вдруг читатель не намерен въедаться в коды. "Реализации" можно и присоединить к "истории", но выделенное перечисление компиляторов весьма удобно (история может быть громоздкой).
  • Насчёт инкапсуляции/сокрытия/проектирование добавлю показательный пример в развитие темы. В ML есть три вида модулей: сигнатуры, структуры и функторы (в Окамле дополнительно к ним ещё и классы, помощнее Smalltalk'овских). Определения языка инкапсулируются в структурах. Сигнатуры - это интерфейсы структур, т.е. модули, управляющие сокрытием определений, инкапсулированных в других модулях. Одна структура может "фильтроваться сквозь" разные сигнатуры, а "сквозь" одну сигнатуру можно "пропускать" разные структуры. Типы можно определять как прозрачно, так и с управлением видимостью (например, можно решать, допускает этот тип проверку на равенство, или нет). Так что сокрытие - это вовсе не "более общее понятие", а совершенно самостоятельное. Да, оно используется при проектировании, но не неизбежно. Вообще в ФП "принцип чёрного ящика" заменяется на "принцип абстракции", и это не одно и то же. В ФП скрывают только реализацию, а "приватные методы" практически не встречаются (вложенные функции - это другое).
    Далее, функторы - это модули, которые получают на входе (как функции) одну структуру и порождают на выходе другую. Это то, для чего в С++ придуман статический полиморфизм на шаблонах, только на порядки проще. Входной параметр функтора задаётся сигнатурой как типом, и конкретная структура на входе - как значение этого типа. Чтобы реализовать "наследование классов", надо сделать структуру, определяющую "родительский класс", и функтор, порождающий "потомка". Т.о., механизм сигнатур позволяет управлять расширением функциональности и перегрузкой (сокрытие при наследовании). Всё это независимо от полиморфизма (читать про параметрический полиморфизм), т.е. каждая функция и каждый тип, определённые в структуре, являются полиморфными сами по себе (а "полиморфизм при наследовании классов" - это на самом деле размножение неполиморфных функций). Когда в ООЯ надо создать 5 похожих иерархий классов по 5 поколений (итого 25 определений классов), эквивалентный код в ML будет содержать лишь 5+4=9 определений модулей плюс 20 копипастных строк инстанцирования, и изменения в определениях "родительских" структур не обязательно потребуют перекомпиляции всего проекта. А если эти 25 классов только для полиморфизма и делаются (как это часто бывает, особенно если предполагается вкручивать паттерн Visitor), то в ML хватит одной структуры из одного полиморфного ADT и нескольких функций над ним (в 25 раз меньше кода и проще управление проектом). Всё это по скорострельности идёт ноздря в ноздрю с С++ (это не Питон и не Хаскел), по скорости компиляции оставляет его далеко в очковой зоне, портируется без напрягов и физически не может содержать глюков. Теперь скажите мне, что я предвзят в отношении С++.
  • Вообще вы меня затроллили, я поддался и потерял тему. То, что от С++ тошнит, я сказал ещё раньше вас, но увы, отталкиваться мы таки обязаны именно от него и его братьев-близнецов Java, C#, Delphi, Php. Ибо именно от них по проекту расползается вирус безграмотности. Уверен, вам обидно, что Википедию называют Педивикией - а вы не задумывались, почему? Мне, например, в своё время стоило огромных усилий собрать информацию про то, что такое хорошее программирование - куда ни плюнь, я всюду врезался в кирпичную стену Алгольной безграмотности, везде было написано по схеме «Камаз хороший, только собаки быстро устают» (типа того, что некий паттерн изначально встроен в язык). Т.е. этот ваш ВП:ВЕС не просто перевешен, а лежит одной чашей на полу. Писать статьи по-быдлокодерски, чтобы, как вы изволили выразиться, быдлокодерам было легче их читать,- это гонять из пустого в порожнее. Я пытаюсь дать обществу ту информацию, которой в своё время аццки не хватало самому мне. Написать энциклопедию «как правильно», а не «чтобы дурачкам не было обидно» - это значит сэкономить время и силы тем, кто любознателен и усердно саморазвивается. Нерадивых же учеников надо сечь розгами. Подчёркиваю - надо, это закон морали. Тех, кто сейчас в школах двойки отменил, тоже надо высечь розгами, желательно публично. И не говорите мне здесь про непредвзятость и нетрибунность - если у них есть право приносить вред науке и обществу, то у меня равно есть право защищать науку от профанации - это и есть ВП:ВЕС. Я начинал было развивать критику, но быстро увидел, что это попытка носить воду в решете. Критика вторична, начинать надо со структуры статей, а дальше всё пойдёт естественным образом: грамотные люди легко и с радостью поддержат грамотную структуру в своих статьях, если увидят, что весы вернулись в ровное состояние. А если в сообществах сразу нескольких хороших языков возникнут одни и те же замечания к структуре статьи - мы получим адекватную обратную связь и внесём коррективы. Единая структура может спускаться сверху вниз, но не может подниматься снизу вверх - ибо писать "VB/С++/Delphi/Java-программу на Smalltalk, Lisp/ML, Forth" - это всё равно что программу с Фортрана переводить на Си, используя всё те же кружева из GOTO. То есть, да, единой структуры не будет, если писать "от простачка". Но будет, если не стесняться подкидывать простачкам ссылки на что-то, что существует за границами их маленького мирка. Нет желания изучать - не изучай, но и не называй себя потом "квалифицированным программистом". Сейчас у нас кухарки управляют наукой вместо академиков, и тем, кто мне скажет, что это и есть непредзятость, я посоветую смотреть Дару О'Бриена.Arachnelis 13:44, 28 декабря 2013 (UTC)
  • upd: А, ещё надо операторы воткнуть. Придётся немного ещё пересмотреть - не в систему типов же их запихивать. А параллелизм, наверно, должен быть поближе к операторам. Arachnelis 14:14, 28 декабря 2013 (UTC)
  • upd2: Сделал черновик, чтобы не писать тут структуру раз за разом: Участник:Arachnelis/PL (язык программирования) Arachnelis 14:44, 28 декабря 2013 (UTC)
  • Извиняюсь, если затроллил. Я стараюсь только только сэкономить Ваши усилия, так как литература про «близнецов-братьев» уже пришла к общему знаменателю (я тут по ошибке добавил к статье ООП один пример… Сразу не раскусил, теперь у меня на mysafari будет месяц слот занимать), и назвать её безграмотной сложно — она просто ограничена и причина этого в сложившейся надсистеме (в ТРИЗовском смысле): пойди найди кодера на Хаскеле (даже как-то сочетание не звучит), а для C++/Java/C#/VB — целая армия за воротами стоит! Они звезд не хватают, но вполне предсказуемы. Слишком грамотные — дороги, их сложно заменять и т. д. К сожалению (или счастью), я последние N лет «братьями» не интересовался, поэтому и не заметил, что они (и литература по ним) пришли к такому единству. Учитывая, что все вместе они — подавляющее большинство, очень сложно просветительством/подвижничеством заниматься в Википедии. И структура здесь не поможет, так как даже литература по «правильным» языкам ориентируется на представление материала для тех, кто знает одного «из братьев». Теперь Вы представляете, что задача, которую Вы поставили, очень сложна и на грани выполнимости? ВП:ВЕС в этом смысле инструмент большинства, то есть с этой лысенковщиной в информатике он бороться не поможет. Надежда остаётся в этом проекте авторам прийти к консенсусу о том, что полезно, а что вредно в статье по ЯП. Но так как тут три с половиной землекопа, нужно просто писать статьи. Я (кажется) уже предлагал собрать библиографию из действительно представительных источников. Да, туда необходимо попадет и «Лысенко» (и мы не сможем не отразить эту линию), но по крайней мере будет виден ландшафт. Что же я сейчас наблюдаю, так это каждый ЯП погрузился в свою «идеологию», и лишь некоторые авторы пытаются строить «мосты» (особенно запомнилась мне книжка по Java, Python, Prolog — и было обрадовался, но быстро огорчился, так как часть про Пролог фактически состояла из небольшого описания всех этих прологовских «чудес», после чего с большим облегчением было сказано: в современном прологе можно писать в императивном стиле — и весь остаток был этому и посвящен). С другой стороны, я не предлагаю упрощать: Википедия не должна быть популярной литературой, я предлагаю искусственно не вносить «наукообразности»! У редакторов остается выбор источников. Что касается предложенной выше структуры, то она, по-моему, лучше, хотя я бы поставил Критику ближе к концу. С другой стороны, по опыту написания статьи по Erlang скажу, что некоторые ключевые Особенности могут быть в начале — обычно источники их тоже выделяют как таковые. Еще один вариант — напишите аналитическую статью в какой-нибудь журнал (типа Открытых систем), где будет изложена вся сложность ситуации с призывами к революции, со ссылками на гуру и т. д. В отличие от Вас, я не верю в непробиваемость ваших «быдлокодеров» — такова надсистема и конъюктура, и, уверен, многие развиваются и расширяют кругозор за пределы принятых сегодня промышленных технологий (эти технологии обладают к тому же огромной инерцией, так как там уже не только надсистема, там и наднадсистема выстроена). РоманСузи 15:56, 28 декабря 2013 (UTC)
  • Что усилия могут быть апстенку горохом - я понимаю. Но ортодоксальность часто приводит к хорошим результатам, если удастся сместить общество хоть на три с половиной процента. Текущая структура (посмотрите ещё раз) уже весьма многообещающая, подходит для самых разных языков, и для семейств языков, и даже парадигм и сравнительных статей. Она не противоречит политике большинства, и уже даже не столь витиевата - только что с намёками. "Критику" можно переименовать в "Общую характеристику", если нет статистических данных о том, что публика часто ищет именно "критику" - тогда это слово не будет мозолить глаза в начале статьи. Уйму библиографии я дал в ЯОП, внутри каждой статьи ещё фамилий море, отличная отправная точка. Лет несколько искал, а как нашёл, получил лавину инфы, пользуйтесь наздоровье. Arachnelis 22:23, 28 декабря 2013 (UTC)
  • Ну, это не новость - в ЯОП у меня неоднократно делается противопоставление «традиционному» программированию и языкам. Arachnelis 07:35, 30 декабря 2013 (UTC)
  • Существование единой структуры очень удобно - становится возможным изучить лишь нужную сейчас часть от содержания. Становится очень удобным сравнение языков, семейств языков и парадигм (теоретически можно будет даже написать движок, который динамически составляет таблицу для выбранных путём выдирания соответствующих фрагментов текста). Что касается моего предложения насчёт постфиксов в наименовании: текущие статьи с названиями без постфиксов остаются, в них просто ставится редирект. Со временем редирект может замениться на дисамбиг, а постфиксные названия никуда не денутся. Т.е. написать "[[XML]]" по-прежнему можно, но читатель попадает на статью "XML (программирование)", например.
  • Переименуйте что ль "Параллелизм (компьютерные науки)" в "Параллелизм (информатика)". Arachnelis 22:30, 28 декабря 2013 (UTC)
  • Кстати, мы что-то при обсуждении сокрытия ушли в Высокие Материи и забыли про Си. А ведь даже в Си соотношение инкапсуляции с сокрытием совершенно не то же, что в С++. Структуры инкапсулируют без сокрытия, а для сокрытия функция или переменная убираются из заголовочного файла, и при изменении интерфейса чего-то скрытого перекомпилируется только модуль, но не весь проект. Глобальные переменные являются нормой при проектировании и там, и там, только в Си они называются честно "глобальными переменными", а в С++ "паттерном Синглтон". В С++, согласно идеоматике, если мы хотим видеть "чистый С++", а не "гремучую смесь из Си и С++", мы должны все определения инкапсулировать в классы, а они целиком определяются в заголовочных файлах, и только реализация методов уходит в "истинную скрытость". В результате не важно, что какой-то метод в класс скрыт (приватен) - стоит измененить его интерфейс (просто переименовать), и будет пересобран весь или почти весь проект. Сокрытие оно такое сокрытое, ага.Arachnelis 08:46, 30 декабря 2013 (UTC)

Компетенция править

Писать статьи про языки не должны люди, которые о языках ничего не знают. Те, чей "кругозор" ограничивается рамками стандартного набора одинаковых и однообразных родичей Алгола (чтоб их всех не стало разом!) - Basic/Pascal/VB/C++/Delphi/Java/C#/Oberon/Ada... - а также низкоуровневых (Ассемблер x86, Си, Фортран), не должны в этом участвовать - иначе будет постоянно возникать вздорная чушь вроде того, что "полиморфизм - значит, один интерфейс, много реализаций", и нарушаться структура (типа того, что типизация рассматривается отдельно от семантики, а элементы языка входят в синтаксис). Как говорится, умелый автор сможет на любом языке написать программу на Фортране. Я видел, как человек написал на Хаскеле программу со сложностью O(n^2) на задаче, предполагающей O(n), просто за счёт того, что использовал Хаскелевские структуры данных по-С++овски. Кроме того, разные языки допускают разные подходы к проектированию системы на макро-уровне, так что, если уж разрабатывать единую структуру статей о языках, то проектирование должно учитываться на верхнем уровне. VB/C++/Delphi/Java предполагают ровно один подход к проектированию - программирование в Королевстве Существительных. Русскоязычную литературу по программированию лучше не использовать - хорошей просто не существует, кроме Колмогорова и Турчина. Наши быдлокодеры чего только не пишут - и вводят термин "универсальный язык программирования", и классифицируют абстракции (что само по себе противоречит определению термина "абстракция")... Так что лучше не торопитесь, а то улучшений не будет. Arachnelis 11:02, 23 ноября 2013 (UTC)

СССР править
А кто тогда должен писать статьи? Те, кто не программировал, ничего в этом не понимают и не захотят писать. Или это те, кто не программировал на перечисленных языках? Я не знаю таких. ~Нирваньчик~ øβς 11:15, 23 ноября 2013 (UTC)
"Русскоязычную литературу по программированию лучше не использовать" - хаха, я даже не знал что такая существует) Всё что я встречал по программированию - переводы с англ. языка. ~Нирваньчик~ øβς 11:15, 23 ноября 2013 (UTC)
почему же? например, Боресков (steps3d.narod.ru) вполне авторитетный автор по OpenGL и CUDA (Idot 11:53, 23 ноября 2013 (UTC))
Речь не об "авторитетности" и уж тем более не о библиотеках. Arachnelis 12:26, 23 ноября 2013 (UTC)
А статьи об атомной энергетике может писать любой, кто умеет включать утюг в розетку? Arachnelis 12:26, 23 ноября 2013 (UTC)
Я говорю не об административном запрете, я взываю к совести. Лично я бы не осмелился писать про атомную энергетику, хотя разводку на розетки я прокладывал. Аналогично, я пытаюсь указать на узость, однобокость и заблуждения мейнстримного "программирования", в надежде, что те, кто считает его Данностью, скромно отойдут в сторону. Arachnelis 13:08, 23 ноября 2013 (UTC)
предложение "Русскоязычную литературу по программированию лучше не использовать" слишком категорично, так как в случае языков советского и российского авторства (например, ДРАКОН) - оно абсурдно (Idot 12:51, 23 ноября 2013 (UTC))
Лично я хороших книг от русских авторов не видел. Переводные хорошие есть, но их единицы. Пример хорошей книги, после беглого ознакомления с которой, как мне кажется, ни один С++-ник/паскалист не осмелился бы уже писать про языки - Larry Paulson, ML for the working programmer. Переводные: Структура и интерпретация компьютерных программ; Siebel, Practical Common Lisp. upd: Чтобы Полсон легче воспринимался, можно сперва почитать переведённого Харпера "Введение в стандартный ML" - для изучения Харпера недостаточно. Arachnelis 13:08, 23 ноября 2013 (UTC)
в данном случае я не про иностранные языки вроде C++, а про те что созданы в СССР и после (Idot 13:12, 23 ноября 2013 (UTC))
В СССР был создан один замечательный язык, оказавший влияние на всю Computer Science - Рефал. Есть работы по Прологу, но это - очень узко специализированная сфера, и русские проложисты зачастую отмечены тем, что всё, что выходит за рамки Пролога, они делают на Delphi. Ну Душкин неплохо про Хаскел написал, но по сути это калька с Хьюдака, так что можно отнести к "переводной литературе". Arachnelis 16:31, 23 ноября 2013 (UTC)
PS а так я видел прекрасную книгу "OpenGL. Графика в проектах Delphi." авторства Краснова (Idot 13:15, 23 ноября 2013 (UTC))
Delphi - это очень, очень плохой образ мышления. Дейкстра говорил, что людей с отпечатком Бейсика невозможно обучить хорошему программированию - так вот это в полной мере применимо и к Дельфи. Arachnelis 16:31, 23 ноября 2013 (UTC)
Вы случайно его с Visual Basic не перепутали? lol Delphi это дальнейшее развите Borlnad Pascal (с радикально переделанными классами), а Pascal создан Виртом, как воплощение идей Дейкстры, на которого Вы сослались lol ну, а RAD, который и воплощает Delphi крайне практичен, потому даёт надёжный результат в приемлимые сроки (Idot 18:15, 23 ноября 2013 (UTC))

В Delphi есть уже готовые и весьма разнообразные средства работы с БД (всякие там ADO, FIB+, ODAC и прочие AnyDAC, за которые нужно выложить приличную сумму), до которых C++нутым еще фапать и фапать (и которые типовому С+±ку в голову вообще не придет использовать в повседневной работе — он сразу-же начнет свои писать, особо оптимизированные велосипедные, затратив сразу своего времени на сумму, раз в двадцать превышающую стоимость какого-нибудь AnyDAC, а потом потратив еще по столько-же раз десять, но уже в последующие лет пять исправлений постоянных глюков своего чудного велосипеда, вместо того, чтобы делом заниматься). В результате, пока красноглазики на C++ сидят со своим говнокодом, дельфикодеры обычно сидят уже с гешефтом, правда небольшим, но уже!


PS ну, а сама книга Краснова хороша именно для изучения OpenGL (а вот для практической работы с графикой Delphi слишком медленен, тут уж лучше C++, а Delphi оставить для задач скорость в которых зависит от обработки сервером запросов, то есть для клиентов) Idot 18:22, 23 ноября 2013 (UTC)
Ничего не путаю. Чрезмерный опыт во всех клонах Бейсика и Паскаля очень вреден. А Виртовский Паскаль - всего лишь учебный язык, он создан быть первым, но плохо, когда он же остаётся и последним. Керниган очень чётко объяснил, почему он не подходит для практического использования. Arachnelis 20:26, 23 ноября 2013 (UTC)
это всё теория про Pascal, на практике же Delphi для многих практических задач даёт хороший результат за минимальный срок разработки - быстро и надёжно, а не долго и глюкаво :-D Idot 06:28, 24 ноября 2013 (UTC)
Не знаю таких абсолютных величин как "быстро и надёжно" - знаю "быстрее и надёжнее, чем то-то". Так что вопрос - насколько быстрее и надёжнее разрабатывать десктоп-гуи-СУБД приложения на Дельфи в сравнении с Lisp, SML, OCaml, Haskell, Scala, Nemerle, Python, Tcl? Про задачи, которые на Дельфи физически не решаются, говорить не будем, так уж и быть. Arachnelis 06:49, 24 ноября 2013 (UTC)
а всё что Вы перечислили содержит средства RAD? если нет, то Ваш вопрос странен (Idot 07:14, 24 ноября 2013 (UTC))
Всё, что я перечислил - языки настолько высокого уровня, что их легко можно портировать на любую платформу или компилировать в другие языки (в Си - обычная практика). Можно и в JVM и в .Net. Ведь RAD, кроме громких слов - это дотНет, я правильно понимаю? Просто я эту фигню никогда не использовал, т.к. перечисленные языки обеспечивают разработку в несколько раз быстрее и качественнее, чем дельфи. В частности, слова "концепция rapid developement" рядом не валяются с "rapid prototyping". 100 строк кода на Хаскеле и день работы - это больше результата, чем тысяча строк на RAD Delphi и неделя работы. Arachnelis 15:51, 24 ноября 2013 (UTC)
не поясните сказанное Вами применительно к написанию клиента баз данных? :-) при типичном использовании Delphi, сам код на Delphi занимает 5-10% времени, всё остальное время (90-95%) уходит на SQL или PL/SQL (Idot 16:04, 24 ноября 2013 (UTC))
Про СУБД: В Common Lisp код запроса пишется просто руками, с нормальной реляционной идеологией, не искажённой чьими-то готовыми компонентами, и на этапе компиляции подключается к серверу и оптимизирует запрос на основе полученных данных. Всё это делает сам язык, без участия программиста и тем более IDE. Учебник тут раскатывать не буду - всё нужное вы найдёте легко. Про GUI: для него я возьму Tcl. На Хаскеле, если вы погуглите, гуйня в основном на кроссплатформенной wxWidjets, а не квадратно-гнездовых компонентах посредственного качества. Если что, есть SML-Tk. Если скорость не критична, то выгоду вы получите, уже пересев на Python с Tkinter. Теперь встречный вопрос: допустим, нужен сервер в режиме работы 24/7 без перезагрузки годами, но с возможностью апгрейда логики и отката назад. Стойки должны отключаться на профилактику. Программа должна в рантайме мигрировать между железками со всеми динамическими данными. Можете не отвечать - на Дельфи такое не пишется чисто физически.Arachnelis 16:27, 24 ноября 2013 (UTC)
я что предлагал на Delphi писать сервер?! речь о клиенте который обеспечивает интерфейс, а всё остальное делается на сервере через стандарный PL/SQL (Idot 16:35, 24 ноября 2013 (UTC))
насчёт Tcl для интерфейса, судя по статье Вам придётся писать код для каждой кнопки, в случае Delphi я не пишу кучу кода для рисования каждой кнопочки, а просто рисую кнопочку, затем кликаю на неё и указываю что делать - что явно быстрее чем написанние кода по рисованию каждой кнопки на супер-Tcl :-D Idot 16:35, 24 ноября 2013 (UTC)
кстати, насчёт отладки: как Вы отлаживаете запрос к базе данных на LISP? в случае Delphi я каждый SQL-запрос могу нормально отладить, стандартными SQL-инструментами, и в Delphi вставляется уже готовый запрос, который легко заменить (а то и вовсе читать запросы из файлов) Idot 16:42, 24 ноября 2013 (UTC)
Давайте не будем превращать энциклопедический совет в консультативный форум. Я дал общее понятие. А за что я больше всего изначально ненавидел Delphi/Builder - так это за жёсткое навязывание абсолютно неправильного подхода к проектированию человеко-машинного взаимодействия. Советую вам почитать книгу Алана Купера "Психбольница в руках пациентов" - это популярная работа про мышление Algol style программистов (он не говорит об Алголе, но портрет характерен). Насчёт визуального программирования а-ля Дельфи там хорошая фраза: "с таким же успехом оператор бетономешалки мог бы сказать плотникам, что они могут начать строить каркас после того, как он закончит заливать бетон". Arachnelis 16:55, 24 ноября 2013 (UTC)
почему "жёсткое навязывание"? если Вам абсолютно нечем заняться на работе, то Вы и на Delphi можете в ручную создавать кнопочки и в ручную игнорируя компоненты подключаться к базе данных, а если совсем нечем заняться работе, то писать с нуля свои библиотеки по работе с базами данных...
но обычно начальство требует предъявить их глазам результат, а не кучу строк неотлаженного кода (Idot 17:08, 24 ноября 2013 (UTC))
и всё таки как Вы отлаживаете запрос к базе данных на LISP, из того как Вы старательно уходите от ответа, я могу заключить, что Вам для этого приходится запускать всю програму и добираться до того места, где у Вас запрос (Idot 17:08, 24 ноября 2013 (UTC))
а насчёт "с таким же успехом оператор бетономешалки мог бы сказать плотникам, что они могут начать строить каркас после того, как он закончит заливать бетон" - один фиг эти кнопочки приходиться рисовать на стадии обсуждения ТЗ. и если Вы сначала рисуете их сначала в Word'е (или ещё где), а затем пишете код, и только затем озабочиваетесь созданием интерфейса, то Вам эти кнопочки приходится рисовать дважды! в случае же визуального програмирования c RAD эти кнопочки уже готовы к моменту утверждения ТЗ, и при написании кода уже не придётся их рисовать, потому что они уже готовы, что даёт существенный выйгрыш времени (Idot 17:16, 24 ноября 2013 (UTC))
Я вижу вы вообще не имеете ни малейшего представления о проектировании человеко-машинного взаимодействия, поэтому повторяю совет - прочитайте Купера. Кнопочки тут ни при чём, совсем. То, что программа была написана на Дельфи, видно всегда извне невооружённым взглядом, т.к. в обращении они омерзительны. Я не понимал, почему у меня AIMP вызывает такое омерзение, пока случайно не узнал, что он написан на Дельфи. Arachnelis 19:36, 24 ноября 2013 (UTC)
ну и альтернативный пример использования Delphi: мне понадобилось написать удобный в пользовании редактор материалов, вся суть которого сводится к удобному интерфейсу с кнопочками и скроллерами с отрисовкой стандартного чайника, и поскольку вся программа более чем на 90% это интефейс (ну и запись циферок на интерфейсе в файл и чтение циферок из файла), а на скорость в данном случае наплевать, я его написал не на C++, а на Delphi, ну так вот мне интересно куда Вы приткнёте тут Хаскель, если вся программа это интерфейс и рисование чайника :-D Idot 16:22, 24 ноября 2013 (UTC)
Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.
ответа как я вижу Вы тщательно избегаете => слив засчитываем? :-) Idot 17:08, 24 ноября 2013 (UTC)
Ваш троллинг защщитан. Здесь не место для подобных споров. Вы что, думаете, что на Хаскеле невозможно написать всё то же, что на Дельфи? Arachnelis 19:36, 24 ноября 2013 (UTC)
я такого не утверждал, я про Ваше утверждение о то что на Хаскеле обязательно будет в 10 раз меньше строк кода :-) Idot 05:03, 25 ноября 2013 (UTC)
а спор и флейм подняли - Вы, в ответ на приведённый пример книги, так кто тут флейм разводит? (Idot 05:05, 25 ноября 2013 (UTC))
(UTC)

Очень прошу избегать личных выпадов! Здесь вам не форум по обсуждению языков программирования, а место для обсуждения статей. --OZH 05:36, 25 ноября 2013 (UTC)

Вы уж извините, дам одну ссылку, чтобы избежать обвинений в голословности: Haskell GUI. Эквивалентный код на Delphi будет экранов в двадцать (здесь и одного экрана нет). Больше по техническим деталям отвечать здесь не буду. Arachnelis 17:56, 27 ноября 2013 (UTC)
Поглядел про ДРАКОН. Умных обещаний много, мелькают идеи ЯОП. "Двумерность" сразу намекает на заблуждения - у Пролога, Хаскела и даже Питона двумерный синтаксис (т.е. код нельзя записать в одну строчку, как в Си или Паскале). А дальше - императивные блок-схемы, которыми невозможно описать, например, Хаскел-программирование (да вообще семантику, основанную на континуэйшенах). Т.е. мы приходим к тому же Algol style программированию, только с кучей псевдопсихологии. Так что незачот. Arachnelis 16:41, 23 ноября 2013 (UTC)
upd: Кстати, Ф.Брукс в книге "Мифический человеко-месяц" (если не путаю) отметил, что программисты вообще ненавидят блок-схемы - они их рисуют уже после того, как код написан, но не перед.Arachnelis 20:50, 23 ноября 2013 (UTC)
зависит от внутренних правил, в некоторых кампаниях ТЗ изначально содержит блок-схему и рисовать её программеру не надо :-) Idot 15:53, 25 ноября 2013 (UTC)
upd2: Статью про ДРАКОН я бы урезал раз в шесть, а то она похожа на рекламную презентацию, приписывающую гамбургеру лечение глаукомы и остеопороза. Arachnelis 06:49, 24 ноября 2013
Сердитая точка зрения править
  • Весьма сердитая точка зрения, однако. И слишком крайняя, чтобы быть близкой к истине. Если оставить в стороне выпады на большую группу авторов оригинальной русскоязычной компьютерной литературы и, по всей видимости, почти всех российских теоретиков, спрошу по существу для расширения кругозора, так сказать:
    • Чем плох термин "универсальный язык программирования", если его понимать в смысле не узко специализированный?
      • "Универсальный" - это значит не просто Тьюринг-полный, а применимый вообще везде, в любых условиях под любую задачу. Таких не бывает и быть физически не может. У любого, без исключения, языка всегда будут ограничения применимости, сколь бы Тьюринг-полным он ни был. Arachnelis 16:31, 23 ноября 2013 (UTC)
        • По-моему, универсальный язык программирования — это синоним языка программирования общего назначения = general purpose programming language, но может быть еще и «многоцелевой». Другой нагрузки у этого слова я не нашёл (если у Вас есть на эту тему что-нибудь серьёзнее записи в блоге - прошу дать ссылку). Полнота по Тьюрингу может быть и у языков специального назначения (eg, Postscript). РоманСузи 18:16, 23 ноября 2013 (UTC)
          • "Универсальный" - не синоним "многоцелевому". Опасно заменять одно на другое. Низкая грамотность русской CS - тому подтверждение: изучили дети один универсальный язык, и не видят необходимости изучать другие - тут ведь вам и GUI, и СУБД, и все прочие вкусности. Как только мы отрезаем саму гипотетическую возможность существования универсального инструмента - сразу возникает вопрос о границах применимости, о пересечении границ применимости разных инструментов и сразу тянется вся остальная наука. Arachnelis 20:39, 23 ноября 2013 (UTC)
    • Что Вы понимаете под элементами языка?
      • То же, что все люди понимают под словом "элемент" - неделимую составную часть от целого. В случае с языками это система типов, модель вызова (нормальная, аппликативная, с передачей продолжений), детерминированность (языки бывают строгие, ленивые, вообще с непрямым порядком вычислений, как Пролог), средства модульности и абстракции (в С++ это классы, в ML это сама система типов плюс три вида модулей, в Рефале нет вообще ничего кроме функций), и т.д. и т.п. Arachnelis 16:31, 23 ноября 2013 (UTC)
        • Слово «элемент» настолько нагружено, что я бы не стал его использовать в структуре статьи. Элемент (системы), элемент синтаксиса, элемент контейнера, наконец (в Вашем понимании) — элемент семантики-синтаксиса-прагматики. Несколько просмотренных мной (не претендую на полноту анализа) описаний языков используют слово «элемент» на уровне лексемы, алфавита.
          • Для всех этих значений есть свои термины. "Элемент синтаксиса" - это строка БНФ. Элемент языка - более сложное понятие. Arachnelis 20:39, 23 ноября 2013 (UTC)
          • upd: но я не настаиваю на использовании этого слова в структуре. Вполне достаточно сделать "Описание языка", или "Будь мужиком, прочти суть" :), или как-то ещё. Arachnelis 05:55, 24 ноября 2013 (UTC)
    • Допустимо ли по-вашему вообще рассматривать семантику оторванно от синтаксиса?
      • В целом - да. Семантика, разумеется, может накладывать некоторые ограничения на синтаксис, но обычно их можно обходить. Есть языки вообще с неопределённым синтаксисом. Например, у Окамла синтаксис параметрический, настраивается путем работы с модулем компилятора CamlpX. Common Lisp теоретически можно превратить в почти любой язык (а если уйти от стандарта, то в любой вообще). Тысяча строк кода на Лиспе - и Лисп становится Хаскелем. Точно также можно добиться того, что Лисп станет С++ом, и любой С++ник сможет программировать на Лиспе, не замечая разницы (но этот аццкий труд вряд ли кто-нибудь когда-нибудь реально выполнит). Вот связи семантики с синтаксисом важно отмечать. Например, алфавит Рефала похож на алфавит Си, но грамматика Си принципиально несовместима с семантикой Рефала. (Для примера: у каждой функции ровно один аргумент, который не имеет ни имени, ни типа, и вообще не записывается, и при этом может представлять из себя что угодно, любую структуру данных). А вообще, к любому языку можно "приделать" почти любой другой синтаксис, и преобразование реализуется несложно. upd: И кстати, уже только поэтому VB/C++/Delphi/Java/C# можно смело считать за ОДИН язык - у них почти одинаковые AST, так что эквивалентный преобразователь программ сделать не так сложно (для случаев, когда не используются своеобразные библиотеки). Могу предложить лёгкое чтиво: RSDN: Синтаксический сахар или C++ vs. Nemerle Arachnelis 16:31, 23 ноября 2013 (UTC)
    • Что плохого в классификации абстракций? (ок. выше Вы объяснили, хотя и не очень убедительно)
      • Смотря что под этим понимать. Выше вы отметили, что очень важно в каждой статье разделить все абстракции на три группы. Если вы сделаете это для Хаскела, бы убъёте половину возможностей языка и распрощаетесь с эквациональными рассуждениями. Т.е. одно дело - раскрывать СПОСОБЫ абстрагирования, и другое дело - описывать "чем использование абстракций типа А отличается от использования абстракций типа Б" (ну, как в С++) Arachnelis 16:31, 23 ноября 2013 (UTC)
        • Три абстракции, возможно, не самый удачный пример. Я только хотел подчеркнуть, что когда мы имеем дело с языковыми абстракциями, то обычно у нас есть понимание того, относятся ли они к данным, инструкциям или же к системе модулей. Хоть в Haskell, хоть в Лисп, хоть в языке для системы с Гарвардской архитектурой мы имеем дело с ними в той или иной степени. Эти вещи настолько фундаментальны, что будут иметь место даже в совершенно дикой архитектуре (которая занимается универсальными вычислениями), так как они берут начало от базовых алгоритмических моделей (будь то абстрактная машина Тьюринга, лямбда-исчисление, алгорифмы Маркова). Другой вопрос, нужно но ли использовать это основание для текстуального разделения описания языка программирования? Тут я не уверен. На настоящий момент императивный и ОО подходы все-таки в большинстве, поэтому вводить в язык программирования нужно с известных понятий, а не чего-то «верного». Конечно, меня лично коробит, когда в книге про Пролог или Лисп с гордостью пишут почти от начала до конца в императивном стиле, но мы не сделаем статью о языке программирования без наведения понятийных мостиков. РоманСузи 18:38, 23 ноября 2013 (UTC)
          • Я предлагаю идти строго от "что" к "как", т.е. начать с вопроса "насколько мы вынуждены программировать вообще", затем "насколько мы вынуждены использовать такой-то способ декомпозиции и разделения труда", и т.д. до отдельных строк БНФ. Прямо сейчас не предложу конкретно, но постараюсь дать свой вариант в ближайшее время.Arachnelis 20:39, 23 ноября 2013 (UTC)
          • upd: Поясню - я говорю о том, чтобы фокус делать на "способах реализации абстракций", а не "способах использования абстракций" - т.е. абстракции можно классифицировать изнутри, но не снаружи. Снаружи, повторюсь, хорошие абстракции должны образовывать чёрный ящик, столь же целостный и неделимый, что и элементы, встроенные в язык. В языках, основанных на лямбда-исчислении (потомки Lisp и ML), стандартной практикой является моделирование данных посредством поведения - т.е. состояния в абстракции как такового и нет, но при использовании её извне кажется, что оно есть.Arachnelis 06:00, 24 ноября 2013 (UTC)
            • Это интересно пожелание начать с вопроса "насколько мы вынуждены программировать вообще", затем "насколько мы вынуждены использовать такой-то способ декомпозиции и разделения труда", однако, мы можем идти в этом направлении только настолько, насколько источники позволяют, иначе мы можем уйти в ВП:МАРГ, если начнём выпячивать какую-то точку зрения. Ведь дело в истории языков программирования происходило так (на примере ООП): жил-был язык императивный структурный. ООП стало получать популярность. В язык решили привнести эту парадигму, насильно. И все во имя того, чтобы "не программировать". И что? По Вашей логике нам следует в статье на ассемблере максимально забыть про MOV и DEC и написать о том, скажем, как на нем родимом заниматься метапрограммированием (или другим текущим супер-пупером)? Или я чего-то не понял в Вашем предложении? Давайте новое вино не заливать в старые меха (если на то нет источников РоманСузи 11:34, 24 ноября 2013 (UTC)
              • Историю рассмотрят в разделе "история" статьи про конкретный язык. Я же говорил о построении структуры повествования от "что" к "как", а не наоборот. Ассемблер же строится изначально, ставя "как" во главу угла, он не для человека, а для машины - т.е. к нему такой подход не факт что применим. Должен признать, это меткое замечание. Arachnelis 15:38, 24 ноября 2013 (UTC)
А вообще говоря в Википедии есть основополагающие принципы, в соответствии с которыми в Википедию должны попадать энциклопедические знания из авторитетных источников. Такими русскоязычная литература, прошедшая редакционное редактирование, является. Разумеется, есть исключения, и выбор литературы за редактором статьи, но статью всегда можно расширить за счет более качественного источника (если, конечно, источник не является маргинальным). Другими словами, Ваша изначальная реплика несёт очень мало смысловой нагрузки без приведения контр-аргументов в виде: «абстракции нельзя классифицировать»<ref>Признаный гуру, Известная книга, 2012</ref> РоманСузи 15:27, 23 ноября 2013 (UTC)
Это понятно. Меня беспокоит, на чём будет сделан акцент. Одно дело - раскрыть в статье верные сведения и потом уделить абзац на ссылку на неверные - и совсем другое дело поступить наоборот. Arachnelis 16:31, 23 ноября 2013 (UTC)
Вообще в Википедии нет принципа "надо выбирать эти источники, потому что они правильные" (хотя вообще это хорошее стремление), тут главный принцип "надо выбирать эти источники, потому что их написали общепризнанные эксперты и научные авторитеты, или издало старое авторитетное издательство". ~Нирваньчик~ øβς 18:42, 23 ноября 2013 (UTC)
+ источники могут использоваться не обязательно для написания всего текста статьи сключительно по ним, а бывает нужно подтвердить всего-лишь один малозначительный фактик, одну буковку/циферку, по которому/-рой могут быть сомнения, и для таких целей любой бульварный роман типо "Изучи С++ за 3 дня" может сгодиться. ~Нирваньчик~ øβς 18:42, 23 ноября 2013 (UTC)
Я не уверен что здесь есть профи, способные написать на таком уровне, как вы говорите. Да и задачи такой нет - писать (в прямом смысле). Мы просто пересказываем то, что пишут профи в других источниках. Главное грамотно составить этот пересказ. Я немного разделяю ваши опасения. Но не уверен что мы должны на таком уровне писать. Лучше описать язык простым и доступным языком, для интересующегося человека, без "высокой философии", которую понимают только академики. Иначе статья станет скучной и нудной. ~Нирваньчик~ øβς 18:48, 23 ноября 2013 (UTC)
Само собой. Просто не следует забывать, что для многих людей Вики является именно источником новых знаний, а не возможностью перепроверить забытую формулу, так что у размеров статей должен быть предел, а значит, надо стараться распределять её доли. Кстати, самое главное - создать структуру, основываясь на правильных источниках, а уже к ней дописывать абзацы со ссылками на "так себе". Arachnelis 20:39, 23 ноября 2013 (UTC)
Ну, если составлять структуру по источникам, тогда непонятно по каким источникам это делать. Обычно структуру статей составляют из здравого смысла. Иногда само название статьи это диктует. Иногда статья в другой Энциклопедии. В данном случае - трудно. Учебники по языку - не факт что подходят на 100%. Их задача - обучить языку программиста. У нас такой цели нет. У нас скорее дать общий взгляд, не вдаваясь в детали. Это нужно какой-то специальный обзорный талмуд по языкам программирования найти. ~Нирваньчик~ øβς 12:18, 25 ноября 2013 (UTC)
«Хорошее» и «так себе (ad hoc)» программирование править

Хочу объяснить две вещи.

Прежде всего, причину споров насчёт синтаксиса/семантики/элементов языка. Я даже где-то видел это в литературе, надеюсь, отыщу ссылку - будет АИ. Все алголоподобные (они же мейнстримные) языки претендуют на то, чтобы называться "высокоуровневыми" (ЯВУ), но в действительности содержат лишь те "высокоуровневые" конструкции, которые однозначно компилируются в блоки машинного кода. Т.о. фактически они все представляют собой разновидность макро-ассемблера. Так вот, поэтому и получается, что любой "элемент языка" соотносится с единственным "элементом синтаксиса". Такой путь построения языка приводит к языкам, емнип, второго-третьего поколения, не дальше. В языках более высокого уровня (четвёртого-пятого поколения) это уже неверно - зачастую элементы языка не имеют в принципе синтаксического отражения, но компилируются (сложным, неоднозначным образом) в большие объёмы кода. Причём в одних случаях это - промежуточный код, который сильно влияет на оптимизацию, и почти полностью удаляется из машинного, в других это целевой код. Пример: выведение типов по Хиндли-Милнеру избавляет программиста от необходимости вводить типы вручную и повышает лаконичность кода. Просто так встроить его, например, в С++, невозможно - он требует нескольких проходов по AST, и потому может быть лишь фундаментальным элементом семантики целостного языка. Применение алгоритма выведения возможно, только если программа уже типизирована в соответствии с моделью типизации Хиндли-Милнера, а она даёт возможность строго проверить корректность на этапе компиляции и убрать всякий контроль из целевого кода. Т.е., например, в Си при переборе массива программист вручную задаёт длину перебора и имеет возможность выйти за границы (семантика чётко соответствует синтаксису). В Паскале длина перебора также задаётся вручную, но выход за границы контролируется рантаймом языка (уже имеем неявно порождаемый код - т.е. элемент языка, скрытый под синтаксисом). В ML невозможно даже написать код, выходящий за границу (т.е. наоборот, границы программист не указывает, целевой рантайм их не контролирует, но семантика языка защищает от ошибки).

Теперь насчёт отличия "хорошего" программирования от неквалифицированного (на жаргоне - "быдлокодирования"). Оно фактически вытекает из вышесказанного. Быдлокодер действует следующим образом: получает ТЗ от заказчика, долго согласовывает с ним детали того, что заказчик желает увидеть, вычленяет из ТЗ объекты, которыми оно манипулирует, выстраивает каркас кода, описывающий эти объекты, исходя из недюжинного опыта работы с ЭВМ выдумывает ещё бОльшее число объектов вокруг них, выстраивает сложную систему взаимосвязей между ними, распараллеливает работу на подчинённых, затем запускает отладку. И тут происходит следующее: звонит заказчик и говорит: «да, я забыл, ещё мне нужны суммы по такому-то показателю при группировке по такому-то в реальном времени. Это всего лишь ещё одно окошко к программе, так что несложно и недорого.» Тот факт, что этих данных для суммирования гигабайты, и лопатит их кластер, и как их синхронно в реальном времени суммировать, никто никогда не думал — его не волнует. И 90% работы программист переделывает за свой счёт. А сам виноват. Ведь 90% работы он выполнил сам, в своей голове, со всеми вытекающими последствиями. Хороший же программист с самого начала направляет 90% усилий на то, чтобы устранить себя и своих подчинённых из процесса программирования. Он старается объяснить компьютеру все особенности предметной области задачи, с тем, чтобы ТЗ компилировалось сразу в машинный код. Тогда при изменении ТЗ ему нужно будет только нажать кнопку перекомпиляции. Это известно уже лет 40 и восходит к докладу Джона Бэкуса «Можно ли освободить программирование от стиля фон-Неймана». После этого вся академическая CS была направлена на развитие формальных методов, и хотя цель ещё недостигнута (и даже есть её низвержения), она очень существенно приближена. Поэтому важно писать статьи про языки исходя не из позиции «мы уже знаем этот язык, так давайте же рассмотрим, какой он замечательный и что мы в него ещё добавить можем», а из «а нужен ли нам этот язык вообще?». Arachnelis 06:07, 24 ноября 2013 (UTC)

Вы хотите заменить информацию о языках программирования (история создания/синтаксис-семантика/библиотеки-реализации/области применения/производительность и т.д.) на размышления о полезности данных языков? Не понимаю мысль. ~Нирваньчик~ øβς 08:45, 26 ноября 2013 (UTC)
как я понял он хочет написать что Delphi - "вреден", а Хаскель - "до жути полезен", то есть статьи рискуют превратиться в срач (Idot 14:57, 26 ноября 2013 (UTC))
За Хаскел особо не радею (моим любимым языком общего назначения, если уж на то пошло, является StandardML) - я делаю акцент на том, что вред для образа мышления от Бейсика уже давно известен (и на это есть АИ - Дейкстра), и что это в равной степени применимо к Дельфи (на это АИ, увы не дам - но и вы не дадите АИ, который бы доказывал, что разница между VB и Delphi столь уж существенна). А вот "заменять на размышления о полезности" я не предлагал, нет в моих словах такого. Arachnelis 11:21, 27 ноября 2013 (UTC)
Справедливости ради, Дийкстра писал не о алголоподобном «modern basic’е», а о старом-недобром спагетти-бейсике с номерами строк. Высказываний Дийкстры против алголоподобных языков как-то не помню. Бэкус в тьюринговской лекции пропагандировал отказ от «традиционного» программирования в пользу функциональщины и (кстати) конкатенативщины, но это вопрос другой. --be-nt-all 12:31, 9 апреля 2014 (UTC)
а Вы способны дать источник доказывающий что разница между Вороной и Верблюдом существенна? :-D а так если Вы утверждаете, что разница между VB и Delphi не существенна, то доказывать это должны именно Вы! (Idot 11:43, 27 ноября 2013 (UTC))
PS такое очущение что Вы никогда не видели памятный в своё время (до моды на Джаву) срач VB vs Delphi --Idot 11:43, 27 ноября 2013 (UTC)
Не буду сейчас искать источник, объясню своими словами. Ни в Бейсике, ни в Паскале нет средств для построения ADT и абстракции функций (сиречь функций высшего порядка). Т.е. в системе типов этих языков нет ничего похожего на функциональный тип. Даже в Си есть, хотя он не претендует на разработку прикладных приложений. По этой причине создание программных "продуктов" посредством VB/Delphi имеет такое же отношение к программированию, как включение утюга в розетку - к атомной энергетике. Arachnelis 18:04, 27 ноября 2013 (UTC)
то есть по твоим Машина Тьюринга словам тоже "имеет такое же отношение к программированию, как включение утюга в розетку - к атомной энергетике"?! и это не говоря уже от такой классике програмироавния как Fortran и C, да и Fort тоже отнюдь не функциональный язык програмирования, то есть фактически ты хочешь форсить функциональное програмирование откровенно наплевав на ВП:НТЗ и ВП:НЕТРИБУНА, и ради своей цели намерен наполнять статьи ОРИССом под видом "логики" => (−) Против (Idot 18:28, 27 ноября 2013 (UTC))
Ну нет этого в моих словах, хоть убейте. Я говорю, что Дельфи для мозга вреден, я не говорил такого про Форт. Наоборот, Форт рулит, как и все метаязыки. На Форте любой ADT строится играючи. Вы очень сильно перевираете мои слова. Типичные для дельфина когнитивные искажения... Arachnelis 18:52, 27 ноября 2013 (UTC)
upd: Машина Тьюринга не делает различий между "кодом" и "данными". В Форте, в Лиспе и в функциональных языках "код" - это "данные, предназначенные для исполнения". Для Бейсика и Дельфи это не верно, так что они воплощают лишь частный, очень убогий и уродливый подвид машины Тьюринга. Чем дальше вы спорите о том, в чём не разбираетесь, тем глупее выглядите. Вам оно надо? Arachnelis 18:58, 27 ноября 2013 (UTC)
Вы вообще в курсе об истории этих языков? Basic это упрощённый Fortran, зная который легче овладеть Fortran'ом - именно для этого он и разрабатывался. нуа Delphi как и Pascal - живое воплощение Структурного Програмирования (Idot 03:48, 28 ноября 2013 (UTC))
История-то тут при чём? Скажу иначе: Бейсик и Паскаль при компиляции задействуют лишь некоторое подмножество возможностей машины Тьюринга, оставляя за кадром такую важную вещь как изоморфизм кода и данных. Это лишает программиста возможности строить алгоритмы, основыванные на манипулировании алгоритмами. Такая банальная вещь как GUI-меню на Си реализуется банальным массивом указателей на функции, а поскольку и массивами, и указателями можно играться динамически, то для построения модифицируемого в рантайме GUI достаточно написать одну простую функцию. Раз что-то делается просто, то это становится стандартным трюком и попадает в состав "идеологии языка". В VB/Delphi эту проблему за вас уже решили разработчики библиотек компонентов, и вы её не замечаете. Но стоит переключиться на задачку по-интереснее, скажем, на какое-нибудь агентное моделирование, и нехватка изоморфизма кода и данных сразу скажется на принципиальной возможности решить задачу, не говоря уже о трудозатратах. И ФП тут тоже ни при чём. Агентную модель можно и на ФЯ, построить, конечно же, но вполне нормально она строится и на Smalltalk'е (т.е. и на Objective-C тоже). Классификация языков на "структурные, ООПные" и т.п. - это детский сад. Языки делятся по типу семантики (операционные, денотационные), по полноте системы типов, по детерминированности... Не думайте, что ФВП есть только в ФЯ - указатели на функции в Си - это тоже в чистом виде ФВП. А Бейсик вы, стало быть, таки используете не на основании технических характеристик, а как историческую ценность? Раз от Фортрана произошёл - то удобнее и выразительнее, чем любой другой язык? Arachnelis 15:28, 28 ноября 2013 (UTC)
RE: "Но стоит переключиться на задачку по-интереснее...", не понял, а зачем писать на Delphi то в чём он мало эффективен? (O_O) он хорош именно в своей нише и в неё идеально вписывается :-) Idot 16:24, 28 ноября 2013 (UTC)
RE: "А Бейсик вы, стало быть, таки используете...", поскольку я на Fortrane давно уже не пишу ;) то я его использую только, если мне приспичило вывести результа в Excel-овский или Word-овский файл, да и то я пишу не на самом VB, а вызываю VBA-скрипты из Delphi! :-D Idot 16:24, 28 ноября 2013 (UTC)
RE: "В VB/Delphi эту проблему за вас уже решили разработчики библиотек компонентов, и вы её не замечаете": чтобы послать что-то на принтер мне не нужно знать о том как устроен драйвер принтера, и прочие подробности, а чтобы вывести что-то на экран нет нужды знать о том как устроен драйвер видеокарты. то что мне нет нужды знать такие подробности и нет нужды каждый раз создавать велосипед писать собственный драйвер, позволяет абстрагироваться от подобных low-level деталей и сосредоточиться на выполнении поставленной задачии и скорейшего получения надёжно работающего результата (Idot 16:32, 28 ноября 2013 (UTC))
Если вопрос ставить так - то да, у VB/Delphi есть своя ниша - низкий порог вхождения. Но не надо манипулировать направлениями беседы: я начал с того, что это слишком низкий порог вхождения, и потому знающие только их люди не могут считаться достойными участниками обсуждений данного рода. Используйте эти языки, ваше право, но не кричите здесь, что ненавидящие их предвзяты и ненейтральны. Кстати, мне показалось, или вы путаете Forth и Fortran? Arachnelis 13:08, 8 декабря 2013 (UTC)
что касается тех претензий, что Pascal был создан для учебных целей, то для рабочих целей Вирт создал Modula, только вот он на практике не прижился и эту нишу сначала занял Object Pascal, а затем его дальнейшее развитие - Delphi (Idot 16:24, 28 ноября 2013 (UTC))
А также Java и C#. Не будем забывать, что весь мейнстрим основан на творениях Вирта (хотя хорошего в этом мало). Arachnelis 13:08, 8 декабря 2013 (UTC)
  • «Уровневость» определяется от отдаленности от аппаратной архитектуры. Наверное, Вы правы, что сейчас это уже больше анахронизм. Что касается подхода к программированию в сторону «программирования в ограничениях» (в широком смысле) и использования ЯОП, то выбор методологии здесь зависит от предметной области. Сейчас уже не могу вспомнить где я видел интересную диаграмму из четырех позиций, где в начале была hardcoded конфигурация, промежуточные пункты не помню (XML кажется и еще что-то), а четвертым пунктом было создание DSL. Посыл же там был, что важно правильно остановиться в выборе гибкости конфигурирования, так как для некоторых проектов DSL — выстрел из пушки по воробьям. РоманСузи 11:26, 24 ноября 2013 (UTC)
    • Про "Уровневость" правильно. Что касается DSL, то он должен идти первым, иначе попросту теряет смысл и превращается в громкое слово. Хьюдак приводит график грубого сравнения ЯОП с классическим подходом, на котором есть точка перехода на выгоду. Arachnelis 15:34, 24 ноября 2013 (UTC)

Нашёл обещанную ссылку:

Традиционные «высокоуровневые» языки программирования не обеспечивают уровень абстракции сколько-нибудь выше машинного языка. Они предоставляют удобные нотации, но только те, что напрямую транслируются в машинный код.

Оригинальный текст (англ.)
Conventional 'high level' programming languages do not provide a level of abstraction significantly above machine language. They provide convenient notations, but only those that map straightforwardly to machine code.
— Larry Paulson, ML for the Working Programmer, с.1

{{книга |автор = Lawrence C. Paulson |заглавие = ML for the Working Programmer |издание = 2nd edition |страницы = 478 |isbn = 0-521-57050-6 (hardback), 0-521-56543-X (paperback) |год = 1991, 1996 |место = Cambridge |издательство = University Press |ref = Paulson }}Arachnelis 11:15, 27 ноября 2013 (UTC)

Я составил свой вариант структуры статей, применимый и к Ассемблеру i86, и к предметно-специфичным языкам типа TeX, и к языкам общего назначения:

1. Место и роль в информатике (можно как общую часть, хотя под этим заголовком будет нагляднее)
2. Неформальное описание (или просто "Язык", как в английских статьях) — собственно описание общих черт и элементов семантики, синтаксиса («неформальное описание» (informal description) — это принятый термин, обычно противопоставляемый «формальному определению» (formal definition) или «спецификации»)
3. Примеры кода — не обязательный на мой взгляд раздел (т.к. предыдущий не обойдётся без мелких примеров), но он много где уже есть, поэтому от себя лишь доработаю требования к нему: не изобретать велосипедов, а выбрать пяток-десяток классических алгоритмических задач, на которых обычно оценивают языки (например, отсюда) и приводить во всех статьях полноценные решения одних и тех же задач, плюс одно-два специфичных, которыми язык может похвастаться (например, изменение синтаксиса в метаязыках, фокусы с битами и адресами на Си, квайн для интерпретируемых, и пр.).
4. История и философия развития — понятно.
5. Реализации — понятно.
6. Оценка характеристик — анализ особенностей, достоинств и недостатков, сравнение с альтернативами (если они есть)

Известные проблемы портируемости следует перечислять в разделе "Реализации". Общую оценку потенциальной портируемости языка рассматривать в "оценке характеристик". Историю с философией разделять считаю ошибкой, т.к. с одной стороны, философия как раз историю и предопределяет; с другой — глядя на историю, можно оценить правдивость заявленной философии. Кроме того, философия может эволюционировать вместе с языком. Я уверен, что история и философия развития должны идти ПОСЛЕ собственно описания того, что есть на данный момент, т.к. это либо сведения для любознательных, либо отчаянная попытка самооправдания, и так или иначе, имеет сугубо вторичное отношение к объективному результату. Это особенно важно для пары Си — С++: многие С++ники упорно отсылают читателя к Си, отказываясь рассматривать язык С++ как самостоятельную единицу (это при том факте, что на чистом Си они больше тысячи строк за всю жизнь не написали и его философию видят в искажённом сквозь призму С++ свете). Если история (последовательность выхода стандартов) не будет предшествовать описанию, то неполнота описания С++ в современном виде сразу станет видна невооружённым взглядом. Почему так важно помещать в статью о С++ даже всё то, что он унаследовал из Си? Для тех, у кого слабовато с аксиоматикой теории множеств, опишу наглядный мысленный эксперимент. На пол кладём конфету, на конфету сверху роняем коровью лепёшку, в результате чего получаем кучу, подмножеством которой является конфета. Согласно логике среднестатистического С++ника получается, что из того факта, что конфета изначально сладкая, прямо следует, что и накрывающий её навоз будет столь же сладким — в каком бы количестве мы его ни навалили, и чем бы корова до этого ни питалась. Тем, у кого слабовато и с проведением мысленных экспериментов, предлагаю самостоятельно поставить этот опыт и сравнить вкус конфеты до объединения множеств и после. Инструмент, в отличие от предмета антиквариата, выбирается перед началом работ на основании объективных технических характеристик, а не потому что имеет богатую историю. Поэтому всё, что С++ получил от Си, должно содержаться в статье про С++ (хотя и в другом порядке изложения, и совсем иначе влиять на оценку характеристик). Если выкинуть наследие Си, то можно с равным успехом выкинуть и наследие и Симулы, и ML, и тогда всё описание языка в статье будет состоять из одной строчки: «С++ является суммой Си, Симулы и плохо украденных идей ML, принципиально не совместимых с Си, вот и представьте себе результат.» Т.е. или не выкидываем элементы НИ ОДНОГО предка, или выкидываем все на равных. Arachnelis 11:15, 27 ноября 2013 (UTC)

А что вы скажете по поводу фразы в статье C++: «C++ не является надмножеством C и не включает его в себя» ? (Честно говоря я немного удивлен, прочитав это, хорошо что АИ там не указано). ~Нирваньчик~ øβς 12:52, 27 ноября 2013 (UTC)
Я думаю, вы и так предугадаете мой ответ ;) Arachnelis 18:04, 27 ноября 2013 (UTC)

Если идея уже нравится, хочу сразу поднять вопрос об использовании следующих двух строк в разделе "Место и роль в информатике":

  • Standard ML: « Язык ориентирован на разработку больших и сложных программных систем. »
  • С++: « Язык часто используется в разработке больших и сложных программных систем, хотя и плохо подходит для этого. »

Проблема с формулировочкой в том, что второе утверждение полностью доказуемо, но повесить один конкретный АИ может оказаться затруднительным, а тянуть гирлянду ссылок прямо в голову статьи не хотелось бы. То, что С++ плохо подходит для сложного проектирования, будет рассмотрено в анализе его системы типов и средств абстрагирования - ссылки на Джойнера (до страниц) для этого есть. Но этот анализ составит экран текста, а в голове статьи нужна общая фраза. Обязательно ли вообще вешать ссылку, если далее по тексту вся необходимая информация точно будет? Или написать «(см.ниже)»?Arachnelis 11:15, 27 ноября 2013 (UTC)

  • Второй пункт должен быть снабжен ссылкой на АИ. Такие резкие высказывания нужно подтверждать АИ обязательно. Я например первый раз слышу про это и для меня это смахивает на маргинальную теорию. Хотя я не занимался большими системами и некомпетентен в этом. А требуется ли АИ, если такой вывод можно сделать из самого текста статьи - это хороший вопрос, я бы и сам хотел узнать ответ. Надо наверное на Форуме спросить. ~Нирваньчик~ øβς 12:52, 27 ноября 2013 (UTC)
  • В "маргинальных теориях" написано "Представляя то или иное явление в Википедии, не следует делать его более значимым, чем оно есть на самом деле". Значимо то, что С++ часто используется в разработке больших и сложных программных систем. Очевидно, тот факт, что он для этого плохо подходит, малозначим для тех, кто разрабатывает большие и сложные программные системы на С++. Экспоненциальный рост трудности разработки по мере укрупнения и усложнения проекта на С++ общеизвествен и ни у кого сомнений не вызывает. Увеличение проекта в два раза требует не удвоения персонала и/или сроков - усложняется работа каждого из разработчиков, усложняется менеджмент проекта, и общая сложность разработки подскакивает раз в восемь. Просто адепты С++ уверены, что такой рост сложности присущ программированию как таковому, а не специфичен для С++, т.к. никогда не видели крупных проектов на языках с развитыми средствами абстрагирования. Они не представляют себе, как 8 человек могут вести качественный, безглючный проект в 140 тыс.строк, например (я говорю о разработчиках MLton, который на С++ составлял бы под миллион строк). Но если обобщить (мы же тут говорим про все статьи о языках сразу), то энциклопедически некорректно было бы для одного плохого языка вместо "плохо" говорить "хуже, чем все остальные" или вешать примечание "а во всех остальных лучше". Беспристрастная формулировка такова, что С++ объективно плох в проектировании, но использующих его это мало волнует. Arachnelis 18:16, 27 ноября 2013 (UTC)
  • Спасибо, хорошо разъяснили. В принципе, в таких формулировках можно этот кусок прямо в статью и вписать) только бы АИ найти). Просто, в своё время С++ создал себе негласную репутацию, что "лучше С++ ничего нет", что и ставило логический барьер... Хотя в моей голове он уже разрушен после знакомства с Java и Python. Т.е. каждому языку - своё место применения, своя ниша. ~Нирваньчик~ øβς 07:24, 28 ноября 2013 (UTC)
  • Можно ещё так переформулировать, по-строже. В математике подвыражение всегда можно обозначить переменной (т.е. вынести в отдельную формулу), что обеспечивает возможность модифицировать это подвыражение без затрагивания общего выражения, благодаря чему изменение мат.модели на 50% требует переписывания лишь 50% формул. Усложнение мат.модели в десять раз собственно в десять раз её и усложняет, пардон за тавталогию. Если усложнение ТЗ на разработку (сиречь мат.модели) в десять раз приводит к усложнению разработки на С++ даже в двадцать раз (а на деле как минимум в тысячу), то с проблемой сложности С++ справляется по факту плохо (хуже голой математики). Какой язык справляется лучше - это уже другой вопрос. В гипотетической вселенной, где С++ реально является единственным способом программирования, найдётся кто-то, кто напишет, что это «программирование плохо справляется с ростом сложности ТЗ», и эту ошибку можно было бы счесть естественной, раз программирование - это ровно то же самое, что реализация математики посредством С++. У нас всё же есть и другие языки, и с проблемой сложности программирования они - о чудо! - справляются лучше. Вот как-то так. Добавлять такие сравнения в статью или нет - пусть решат администраторы. Лично мне всегда хватает одного упоминания, что где-то есть что-то другое - я сразу отправляюсь ознакомиться с этим "чем-то" - а вот предотвратит ли одно упоминание войну правок... Arachnelis 15:20, 28 ноября 2013 (UTC)
Логика править

Теперь я повторю вопрос насчёт очевидности, на который до сих пор не получил ответа.

Есть такая наука — логика. Во-первых, я не верю, что логические рассуждения в статье нельзя строить самостоятельно на основе АИ, а не цитировать откуда-то. Если в одной книге делается утверждение "A", в другой "B", а из "A+B" логически следует "C", которое не обнаружено ни в одной публикации — то разве нельзя прямо так взять и описать всю эту логику самостоятельно? Можно только цитировать, никаких рассуждений? Во-вторых, согласно законам логики, утверждение об отсутствии чего-либо по своей природе само не может подкрепляться доказательными примерами и может только опровергаться контр-примерами. Ну так, так ли уж обязательно ссылаться на конкретного Авторитетного Дядю, который на это отсутствие пожаловался в Научном Труде? Я считаю, что даже в случае войны правок можно составить абзац из двух частей — (1) ссылку на любого автора, упомянувшего хотя бы вскользь важность наличия этой вещи где бы то ни было и (2) собственно утверждение об отсутствии её в предмете статьи (уже, по определению, без ссылки). Обычно это сделать как минимум проще, чем перелопачивать всю библиографию всех изданий.

Вопросы эти важны, ибо имеет место фундаментальная проблема: реально потрудился опубликовать и закопирайтить обилие критики на С++, похоже, один только Ян Джойнер. Это не потому что на самом деле на С++, кроме Джойнера, никто не жалуется — любой профессионал может легко разнести в пух и прах С++ со всеми его идеями, обещаниями и фактами, и можно привести мириады постов с форумов — нет, этому есть конкретные причины. Во-первых, для профессионала утруждаться критикой лень, ему проще выбрать для себя удобный инструмент и работать себе в своё удовольствие; во-вторых, он считает, что спорить с дураками — значит, опускаться на их уровень, т.е. считает критику ниже своего достоинства; в-третьих, в современной академической науке, к сожалению, вообще нет практики обливать чужие творения помоями, даже если все в редакции данного научного журнала согласны, что это вещь из рук вон плоха — они дружно вернутся к первому пункту. Как следствие, в мире столько лженауки, словоблудий и паразитизма (один Фаулер чего стОит). В частности, малограмотные адепты С++ с остекленелым взором могут продолжать завлекать в свою тотально-деструктивную секту молодняк, продолжая приносить вред обществу, и потому нормального ПО до сих пор так мало и кругом одно говно (что С++ники наотрез отказываются хоть как-то соотносить с природой самого С++ — дескать, «это вот та конкретная группа была из криворучек, а сам С++ превосходен!»). Всвязи с этим я настаиваю, что совершенно корректным будет писать проверяемые ЛОГИКОЙ утверждения, в т.ч. сравнения («вот язык А так может, а С++ не может»), даже если их неоткуда процитировать. Я утверждаю, что если сторонник С++ захочет подобное утверждение удалить, то он должен сделать это строго следующим образом: перенести опровергаемое утверждение в особый раздел в обсуждении, повесив конкретную опровергающую ссылку — либо «С++ тоже так может», либо «на самом деле язык А тоже так не может». Только так! Никаких «а С++у этого и не требуется, потому что бла-бла-бла!». С++у требуется абсолютно всё — так его Автор Сказал — С++ прямо претендует на универсальность. Если конкретной опровергающей ссылки нет, то администраторы должны игнорировать жалобы от С++ников, что мол «этот обидный факт ни в одном АИ не отмечен, значит он не важен, удалите его». Вопрос общий, но я фокусирую его на С++ по причине того, что НИ К ОДНОМУ языку просто не будет столько критики, и сторонники НИ ОДНОГО ЯЗЫКА приводимую критику не будут столь отчаянно оспаривать.

Прошу администраторов проголосовать за согласие с этим.Arachnelis 11:15, 27 ноября 2013 (UTC)

  • Не вступая сейчас в дискуссию по существу затрагиваемых здесь вопросов, хочу напомнить о том, что все языки эквивалентны машине Тьюригна. (Если я, конечно, ничего не путаю.) Различаются языки своими выразительными средствами. Чем выше уровень языка программирования, тем больше в нём выразительных средств. Когда средства хорошо развиты, то решение задачи можно предоставлять в естественных терминах. Если язык требует написания низкоуровнего кода, то, да, конечно, это можно назвать недостатком. Если бы был ровно один универсальный язык программирования, то все на нём и писали бы. Но здесь, в Википедии, задача не создать этот самый универсальный язык, а, всего лишь, грамотно описать существующие. Не в смысле, научить программировать (для этого давайте напишем несколько Викиучебников), а в том, смысле, чтобы дать чёткое представление о каждом языке. И тут надо не копья ломать, а статьи делать. А это уже работа с источниками, ибо нельзя просто так что-то такое основательное написать. И администраторы здесь, как мне кажется, совсем ни причём. --OZH 11:58, 27 ноября 2013 (UTC)
    • насчёт "язык требует написания низкоуровнего кода, то, да, конечно, это можно назвать недостатком": а драйвера на чём писать? (Idot 14:57, 27 ноября 2013 (UTC))
      • Драйвера - на Си. Когда Си перестаёт хватать, надо либо повышать уровень семантики (например, перейдя на BitC или Cyclone), либо производить декомпозицию на несколько языков и сращивать их посредством Си. Но не склеивать несколько несовместимых между собой семантических моделей в один "язык". Например, исключения (exceptions) не применимы в языке с ручным управлением памятью - они требуют автомата, иначе резко страдает стабильность программ. Arachnelis 18:22, 27 ноября 2013 (UTC)
      • upd: Поэтому и получается картина, искренне изумляющая всех адептов С++: если Си хороший язык, и ML хороший язык, и Симула вроде ничего так, то почему же 
        Си + Симула + ML = тихий ужас
        ??? Из-за несовместимости хороших вещей между собой! Между исключениями в ML и исключениями в С++ разница получается примерно такая же, как между прогулками слона по Африке и по посудной лавке. И на вопросы о том, на какой стадии находятся реализация в С++ чего-нибудь (например, темлейтов и библиотек на них), всегда можно будет отвечать строкой из старого советского анекдота: «пока только намазывается хорошо». Природу С++ предопределил автор, и очень подробно описал все свои заблуждения в D&E. И то, что "язык" - это НЕ система (хотя по определению язык - это формальная система, и структурная лингвистика об этом не забывает), и то, что он не должен исключать человеческий фактор (это из формального-то процесса, ага), и всё прочее. Страуструп открытым текстом противоречит всем наукам о языках. При этом в "предвзятости" обвиняют почему-то именно критиков, а не сторонников С++. Arachnelis 15:15, 28 ноября 2013 (UTC)
    • Так и я пытаюсь добиться объективности и непредвзятости! В этом-то и проблема, что адепты С++ чихать хотели на объективность и непредвзятость. Для них С++ священен, его нельзя поминать в суе, и пути страусовы неисповедимы. Вы вспомните, с чего начался весь этот сыр-бор - с того, что некий Enerjazzer принялся удалять из статьи про С++ объективную критику, потому что она роняла авторитет Великого и Могучего Языка Программирования Си С Двумя Плюсами! Arachnelis 18:49, 27 ноября 2013 (UTC)

Организация править

Википедия и Викиучебник править

Единственное, о чём следует подумать отдельно, так это о написании (параллельно написанию статьей в Википедии) соответствующих статей в Викиучебнике: статья в Виипедии — это развёрнутое введение в предмет (язык программирования), а статья (или цикл статей) в Викиучебнике — это введение в практику программирования с упором на решение задач. --OZH 05:29, 21 ноября 2013 (UTC)

Шаблон о сравнении языков править

Случайно наткнулся на Шаблон:Сравнения языков программирования. Очень жалкое зрелище, в таком виде просится на КУ. Может быть, будут какие предложения и по нему, раз уж занимаемся статьями по языкам? РоманСузи 21:41, 4 января 2014 (UTC)

  • А он вообще зачем по идее? Чего хотел создатель? Я что-то смысла в шаблоне со сравнением не вижу. Пятью строчками в этой теме не обойдёшься, это тема для статьи, даже нескольких. Если мне кто-нибудь не объяснит реальное назначение его, я за удаление. upd: а может, в названии не орфографическая ошибка, а автор как раз хотел систематизировать системы классификаций? Типа, сравнение по парадигмам, по эффективности, по цвету и вкусу... Arachnelis 17:15, 9 апреля 2014 (UTC)
  • Решил проверить наличие аглицкого эквивалента, залез на en:Comparison of programming languages и офигел. Можно не заморачиваться с поиском глубинного смысла в находке, а просто переводить. Текста там кот наплакал, в основном форматирование. Arachnelis 14:12, 10 апреля 2014 (UTC)

Учебный язык программирования править

Статья мной потихоньку пишется. В планах — доведение до хорошего/избранного списка. Хотя пока времени мало, а у статьи — со времени её попадания на КУ, где я её и приметил — единственный автор — это я. Что несколько обидно. Когда обеспечу сколь-нибудь приемлемую широту охвата, выставлю на рецензирование, но пока это такой стаб (пусть большой и со сносками) — рано. Но хотелось бы обратится к единомышленникам, заинтересованным в её развитии. --be-nt-all 17:56, 8 апреля 2014 (UTC)

  • Я заинтересован, но по времени не гарантирую. Буду заглядывать если чего поправить. Возникнут конкретные вопросы — обращайтесь в личке. Только про ML не забудьте — и Standard ML, и OCaml весьма часто преподаются первыми языками. Ими я планирую плотно заниматься, так что по ходу что-то может всплыть. Удивило, что в английской статье я поиском по странице их не нашёл — только Окамл в скобках один раз упоминается. Arachnelis 18:26, 8 апреля 2014 (UTC)
  • Помнить то помню… Но вот к примеру курс вроде SICP или en:CTM для ML не припомню. Есть конечно Little MLer, есть курс по ФП Джона Харрисона (пусть и неизданный). Но тут кстати и Hope не упомянуть нельзя, книга другого Харрисона, который Питер — обязывает. В общем это не ради спора — жду наводок --be-nt-all 19:07, 8 апреля 2014 (UTC)

Навигационный шаблон "Языки программирования" править

Обтачиваю в личке уже давно, близится к завершению (последние правки уже идут абразивом тыщ на 10-12). Прошу оценить, указать на откровенно неправильные решения и мелкие недочёты. Если серьёзных претензий не будет, к маю запущу на чисто. Arachnelis 18:34, 8 апреля 2014 (UTC)

  • Ну лично мне (как админу и википедисту) тут ОРИСС чудится, но я вообще к навигационным шаблонам скептически настроен, как к классу. Хотя как программист — в общем согласен. Правда удивлён, отсутствием Симулы в верхней строке, да и Снобол, хотя бы как предтеча Регекспов достоин чуть большего чем помещения в список DSL. Но мне формат подобных списков кажется уместным скорей привязанным к википорталам. Посему, скажем воздерживаюсь… --be-nt-all 19:28, 8 апреля 2014 (UTC)
  • Чем он будет удобнее ссылки на Список языков программирования по категориям? Таблицей можно и существующий список украсить, зачем же пихать большой список во все статьи. ~Sunpriat (обс) 08:32, 9 апреля 2014 (UTC)
  • Да, этот список явно стоит допиливать как в плане оформления, так и в плане источников. Шаблон если и нужен, то как производный к этому списку. --be-nt-all 12:45, 9 апреля 2014 (UTC)
  • Что-то суждение только о Большом Брате, а о Малом и самом факте раздвоения — ни слова. А ведь это самая главная фишка — вместо былых споров «что вставлять в него, а что нет» я сделал все с выделением статистически значимых. И удобно, и полноценно одновременно. Ладно, рассматриваем Большого. Во-первых, что за брезгливое отношение к DSL’ям? Они всегда рулили и всегда будут рулить, гораздо больше, чем все языки общего назначения вместе взятые. То есть помещение языка общего назначения в разряд DSL’ей — это вообще-то комплимент. Я бы продублировал многое в разделе DSL (Смолток, например), но то действительно будет орисс. Ладно. Я вчитался в английскую статью про Снобол, да, продублирую его в высокоуровневых и в списке реализаций регэкспов. Такие вещи подкидывайте кто чего знает, один человек не может знать все языки на свете. Что до самих РегЭкспов, то они вроде как ещё в 40-х появились, так что не Сноболу принадлежит новация. Симула ничего нового науке не дала — это «Алгол с классами» - банальное синтаксическое помещение функций в записи. Это не смена семантики, а просто структурирование кода, которое легко выполняется ручками в чисто процедурных языках. ООП породил Смолток, это доказано, только упёртыми фанатами потомков Алгола не признаётся. Они пишут в процедурном стиле, синтаксически обрамляя свой код классами и разными buzzword типа метаклассов, и думают, что строят объектные модели, когда на деле это просто модульность+инкапсуляция, и не более того. То есть де-факто именно приписывание новации ООП Симуле как раз ориссом и является. Объективно первым ОО-языком является Смолток. Arachnelis 17:02, 9 апреля 2014 (UTC)
  • Что до категории, то этот шаблон удобнее на порядок, так как наглядно отражает семантические и хронологические связи между языками. Это не только позволяет быстро отыскать глазами известный язык, но и открыть для себя неизвестный. То есть он, в отличие от плоского списка, имеет познавательный эффект, и делает пользование энциклопедией куда более интересным. Категория эта ваша воспринимается как тихий ужас, я бы ей не стал пользоваться. При составлении шаблона я даже не задумывался о её существовании. Arachnelis 17:02, 9 апреля 2014 (UTC)
  • … по-хорошему, я против подобных шаблонов в принципе, но проект всяко лучше нынешней каши, стоящей в подвале статей о ЯП, так что скорее за… --be-nt-all 05:22, 12 апреля 2014 (UTC)
  • Благодарю. Поправить всегда можно, я хочу задать хороший посыл, заложить структуру. Arachnelis 18:22, 12 апреля 2014 (UTC)
  • А с вёрсткой не подсобите? Пытаюсь сделать так, чтобы строка научно-значимых языков имела слева заголовок, но не имела свой шапки со сворачиванием. Чёта не получается. Arachnelis 18:39, 12 апреля 2014 (UTC)
  • Шаблон выставили на удаление. К сожалению, не знаю чем можно помочь. Источник найти не проблема — взять например Одинцова Проф. программирование системный подход (там кстати HTML к ЯП отнесён), да ещё что-нибудь по функциональной специфике. Другое дело, нужно сообразить, use cases для данного шаблона, исходя из чего можно будет его разбить на части или поменять. То есть, представить реального читателя: для чего ему нужен этот шаблон? Если нужны параллели (например, зашёл на Agda, откуда узнал, что есть Coq), то и шаблон должен быть только для данной категории. Если при этом читателя просвещаем, что языки есть «лямбда» и «не лямбда», «Х-М» и «предикат», то боюсь мимо цели: те, кто на основе этих ориентиров будет искать, не нуждаются в шаблоне. Может, в Википедии есть какое средство сделать динамический шаблон, чтобы скажем выбрать набор признаков (уровень языка, парадигма, применение), а «шаблон» бы открыл список? В общем, немного в сомнениях как можно спасти труд коллеги. Может, на страницах проекта или Портала ИТ может пригодиться? РоманСузи 21:02, 27 декабря 2014 (UTC)
  • Что значит "не нуждаются в шаблоне"? Возможность быстрого перехода без ручного ввода в поиск - это удобно. Arachnelis 08:09, 28 декабря 2014 (UTC)
  • Узок круг этих читателей, для которых удобно. Но тут пожалуй проблема формального плана: правило: ВП:НАВШАБЛОНЫ. Видимо, на этой основе сейчас и происходит удаление подобных шаблонов... РоманСузи 20:49, 28 декабря 2014 (UTC)

Мультипарадигмальный язык программирования править

Предложил переименовать, но не могу найти АИ. Простая логика превратилась в холивар. Принять участие есть желающие? Arachnelis 18:42, 12 апреля 2014 (UTC)

Tcl спасать надо править

В своё время статья Tcl была избрана хорошей. Сейчас на мой взгляд она более не удовлетворяет (посмотрите сами). Может быть, найдётся герой, который ситуацию изменит? Не так много у нас хороших и избранных статей по ЯП! РоманСузи 07:44, 9 декабря 2014 (UTC)

@РоманСузи: можно конкретизировать? Содержание нормальное, проблемы традиционные: вп-некатклог, вп-проверяемость. ~Sunpriat 07:58, 9 декабря 2014 (UTC)
Конкретизировал на Обсуждение:Tcl#О качестве статьи. Вы правильно указали две основные проблемы, но есть ещё и общее необъяснимое чувство «неряшливости», из-за которого я и удивился, увидев звездочку. РоманСузи 14:33, 9 декабря 2014 (UTC)
За конкретизацию спасибо, а так сам знаю что надо спасать… (Это таки моя первая статья как зарегистрированного редактора). Да и просто устарело многое. Сейчас собираю материал. --be-nt-all 06:54, 23 февраля 2015 (UTC)
Источник — https://ru.wikipedia.org/w/index.php?title=Обсуждение_проекта:Информационные_технологии/Архив/2&oldid=92466064