Обсуждение проекта:Информационные технологии: различия между версиями
Oleg4280 (обсуждение | вклад) →[[Уязвимости AJAX]]: новая тема |
: новая тема из Обсуждение:Skype Ошибка в Википедии, вводящая в заблуждение igor ~~~~ |
||
Строка 1: | Строка 1: | ||
{{Обсуждение проекта:Информационные технологии/Шапка}} |
{{Обсуждение проекта:Информационные технологии/Шапка}} |
||
'''Оригинал интервью, слова интервьюируемого.''' |
|||
'''Кто придумал Skype.''' |
|||
Программа Skype была написана в 2003 г. шведскими предпринимателями Янусом Фриисом и Никласом Зеннстремом. Сначала она использовалась лишь для звонков с компьютера на компьютер. Потом добавились звонки на мобильные и стационарные телефоны, а также видеосвязь. |
|||
Интервью с Джошем Сильверманом. Ведомости (13.04.2010). Проверено 28 ноября 2012. Архивировано из первоисточника 28 ноября 2012. |
|||
http://www.comnews.ru/print?nid=50468 |
|||
---------------- |
|||
'''В Википедии же тут заменена - первая строка не верная, хотя ссылка та оригинальная.''' |
|||
== [[Уязвимости AJAX]] == |
== [[Уязвимости AJAX]] == |
Версия от 19:32, 11 марта 2016
- → К редактированию статей ИТ
- ↓ К обсуждению статей ИТ
- → К новым статьям
- → К лучшим статьям
- → К редакторам
- → К обзору тем ИТ
Оригинал интервью, слова интервьюируемого. Кто придумал Skype.
Программа Skype была написана в 2003 г. шведскими предпринимателями Янусом Фриисом и Никласом Зеннстремом. Сначала она использовалась лишь для звонков с компьютера на компьютер. Потом добавились звонки на мобильные и стационарные телефоны, а также видеосвязь.
Интервью с Джошем Сильверманом. Ведомости (13.04.2010). Проверено 28 ноября 2012. Архивировано из первоисточника 28 ноября 2012. http://www.comnews.ru/print?nid=50468
В Википедии же тут заменена - первая строка не верная, хотя ссылка та оригинальная.
Есть такая статья. На её странице обсуждения говорится, что очень многое не соответствует действительности и статья должна быть полностью переписана либо удалена. Прошу посмотреть и решить, что делать. Статья была создана 18.12.2008, интервик нет. Предлагать к удалению? Oleg3280 13:12, 9 марта 2016 (UTC)
Русскоязычные вики-проекты со свободным контентом
Хочу обратить внимание коллег на существование таких вики-проектов, распространяющих интересный контент на русском языке под свободной лицензией: algowiki-project.org и machinelearning.ru. Возможно, некоторые статьи из этих ресурсов могут быть заимствованы целиком или частично, с соблюдением, конечно, авторских прав (думаю, лучше всего будет соорудить шаблон по типу {{Статья Товики}} для этих источников и ставить его на страницу обсуждения). Предлагаю обсудить применимость текстов этих ресурсов, и заодно поделиться другими известными проектами со свободными текстами по заданной теме, bezik° 19:49, 27 февраля 2016 (UTC)
- Отдельное спасибо за первую ссылку. Есть в закладках ресурс на английском: www.algorithmist.com. Oleg3280 22:49, 27 февраля 2016 (UTC)
- Или, например, такой ресурс: AlgoXY Book of Elementary Algorithms and Data structures. Oleg3280 22:55, 27 февраля 2016 (UTC)
- У Википедии ограничение "энциклопедии". Википедию далее копируют и клонируют. Вики - это самостоятельно изданные источники. Скопировать лицензия позволяет да, но достоверности у текстов нет. Риск en:Wikipedia:List of hoaxes on Wikipedia. В виках бывает хороший материал, который просится в раздел внешних ссылок в статьи. Нужно обращать внимание на то, что у них нет гарантий существования - могут загнуться через пару лет и и пропасть из интернета ещё через пару, к тому же бывало, что потом ни одной версии сайта не оказывалось в архив.орг и весь полезный контент бесследно пропадал. / Сделал Проект:Информационные технологии/Источники. Дополнение и оформление приветствуется. / Викии внизу главной страницы проекта смотрели? --Hrum-Hrum 12:04, 28 февраля 2016 (UTC)
- И что? В algowiki я смотрюстатьи тоже принято с источниками писать, и формат от нашего не так, чтобы далёк. --be-nt-all 13:30, 28 февраля 2016 (UTC)
- Это к тому, что копируя не нужно ссылаться на них как на источники и поддерживать версии указанных "звёздных" авторов вик когда изменят скопированный текст в части не имеющей источника. --Hrum-Hrum 13:36, 28 февраля 2016 (UTC)
- Шаблоны вот Шаблон:Machinelearningru, Шаблон:Algowiki-projectorg. В Википедия:Перенос текстов#Перенос текстов из внешних источников говорится ещё про обязательность упоминания в комментарии к правке. --Hrum-Hrum 13:36, 28 февраля 2016 (UTC)
- И что? В algowiki я смотрюстатьи тоже принято с источниками писать, и формат от нашего не так, чтобы далёк. --be-nt-all 13:30, 28 февраля 2016 (UTC)
- be-nt-all. Просто для информации: Обсуждение участника:Hrum-Hrum#Вопрос. Oleg3280 14:29, 28 февраля 2016 (UTC)
Модель акторов
Коллеги, думаю имеет смысл добавить модель акторов в проект. Bsivko 20:22, 25 февраля 2016 (UTC)
- Просто добавляйте шаблон проекта на страницу обсуждения таким же образом. --V0d01ey 03:51, 26 февраля 2016 (UTC)
- Спасибо. Ок. Bsivko 13:41, 26 февраля 2016 (UTC)
Нужно дать описание новых версий, статусная статья, основной автор неактивен. --Pessimist 05:25, 24 февраля 2016 (UTC)
- Сейчас посмотрю. Oleg3280 14:34, 24 февраля 2016 (UTC)
- Pessimist. Сделано. Убрал промежуточные версии. Oleg3280 14:57, 24 февраля 2016 (UTC)
- Спасибо. Нужно чтобы кто-нибудь тут взял себе в СН статусные статьи по этой тематике. Чтобы оперативно патрулить. --Pessimist 15:00, 24 февраля 2016 (UTC)
Портал
Новый инструмент просмотра pageviews говорит, что у портала неплохая посещаемость [1]. Есть какие-нибудь идеи чего добавить интересного для читателя, взять с других порталов, наполнить, привлечь в проект? Дополнил бы, чтобы он разнообразнее автоматически обновлялся. --Сунприат 10:01, 13 февраля 2016 (UTC)
- Получается, что у портала в 3 раза выше посещаемость, чем у проекта. Я бы начал с переименования портала в Информационные технологии (до 1 ноября 2007 года это название уже использовалось, потом переименовали в Компьютерные технологии). Можно посмотреть как в других Порталах и взять лучшее и самое интересное. Oleg3280 10:43, 13 февраля 2016 (UTC)
- В том и вопрос - "что где есть интересного?". По мне все одинаково неживые. Есть Википедия:Популярные статьи/2015/Портал, но эта посещаемость может быть вызвана большим числом ссылок на порталы. --Сунприат 11:35, 13 февраля 2016 (UTC)
- Где обсуждается переименование порталов: здесь или здесь? Oleg3280 11:19, 13 февраля 2016 (UTC)
- Текущее название 1) оправдывает наличие в нём железной тематики 2) более народное - "что-то о компьютерах". --Сунприат 11:35, 13 февраля 2016 (UTC)
Обновился syntaxhighlight
Добавлено несколько новых языков в тег syntaxhighlight (он же source). https://lists.wikimedia.org/pipermail/wikitech-l/2016-February/084695.html --Сунприат 12:40, 7 февраля 2016 (UTC)
Ну и раз уж речь пошла про историю IT, то теперь к истории отечественной (советской) вычислительной техники. Словником Глушковской Энциклопедии никто не занимается? --be-nt-all 14:25, 6 февраля 2016 (UTC)
- В .djvu лежащих в сети нет алф.списка. Вот же бородатая 70-х. Ок, попробую сделать, пара моментов, представляющих исторический интерес там есть. --Сунприат 14:58, 6 февраля 2016 (UTC)
- Ну, не пара, больше. Присрединюсь. Историю отчественной вычислительной техники поднимать надо. Впрочем не только отечественной, у нас, оказывается, про WordStar[англ.] нет статьи --be-nt-all 15:31, 6 февраля 2016 (UTC) Собственно уже занялся, составляю словник оглавление с номерами страниц --be-nt-all 15:45, 6 февраля 2016 (UTC)
- Проект:Информационные технологии/Словники/Энциклопедия кибернетики --Сунприат 18:33, 6 февраля 2016 (UTC)
- А я начал Проект:Информационные технологии/ЭКI --be-nt-all 20:14, 6 февраля 2016 (UTC)
- @be-nt-all: Обработал том2. Всего чуть меньше 1668. Теперь будет легче, чем вручную всё набирать. / Зачем страницы? - полистать до нужного слова не проблема. --Сунприат 21:05, 6 февраля 2016 (UTC)
- Ну мне кажется так удобней и для поиска, и для оформления сноски. Да удобней, но всё равно сверять глазами надо, потому и страницы заодно проставлю --be-nt-all 21:14, 6 февраля 2016 (UTC)
- @be-nt-all: Обработал том2. Всего чуть меньше 1668. Теперь будет легче, чем вручную всё набирать. / Зачем страницы? - полистать до нужного слова не проблема. --Сунприат 21:05, 6 февраля 2016 (UTC)
- Ну, не пара, больше. Присрединюсь. Историю отчественной вычислительной техники поднимать надо. Впрочем не только отечественной, у нас, оказывается, про WordStar[англ.] нет статьи --be-nt-all 15:31, 6 февраля 2016 (UTC) Собственно уже занялся, составляю словник оглавление с номерами страниц --be-nt-all 15:45, 6 февраля 2016 (UTC)
- Профильная нам (куда уж боле) статья из ПРО:1000. Раньше там объём бог знает чем догонялся, я написал более-менее приличную заготовку исторического раздела (так-то тема сама по себе тянет на отдельную ВП:ИС), в общем приглашаю если не к доработке, то к написанию переводу статей по красным ссылкам, что-то там их многовато --be-nt-all 14:25, 6 февраля 2016 (UTC)
Релевантность
Есть статья в основном пространстве Релевантность и статья в Инкубаторе Инкубатор:Релевантность. Как лучше поступить? Учитывая претензии к статье в основном пространстве, может быть, просто заменить её статьёй из Инкубатора, где материала намного больше? Прошу помочь, кто хорошо разбирается в этой теме. Участник конструктивный, пытаюсь ему помочь в написании и правильном оформлении статей. Первой была статья из Инкубатора Индивидуальный бренд. Заранее спасибо. Oleg3280 20:43, 2 февраля 2016 (UTC)
- Вижу два выхода (1) Вынести существующую статью на КУ, рассказав, что в инкубаторе написана статья куда лучше (2) переименовать то что есть в Релевантность (поисковые системы) или как-то так. Мне кажется, второй путь предпочтительней --be-nt-all 22:34, 2 февраля 2016 (UTC)
- Переименовал. --Сунприат 12:01, 4 февраля 2016 (UTC)
- Статья Релевантность была переименована в Релевантность (информационный поиск). Oleg3280 12:32, 4 февраля 2016 (UTC)
- Статья из Инкубатора была перенесена в основное пространство. Oleg3280 13:05, 4 февраля 2016 (UTC)
- Статья на ВП:КУ, там ядро, это уже философия, но занятся стоит. Дойдуть руки, проверю, как там с обобщающими источниками (то есть состояние статьи в любом случае доработки триебует, оформлено хорошо, но, к примеру, куча сносок на нас или английский раздел ВП как на ВП:АИ --be-nt-all 14:19, 6 февраля 2016 (UTC)
Последняя версия в шаблонах-карточках ПО
Предлагаю убрать параметры шаблонов-карточек программного обеспечения: последняя версия, дата последней версии. Эту информацию всегда можно найти на официальном сайте ПО, и размещённая на странице она быстро становится неактуальной. В результате мы имеем очень много правок просто изменяющие эти данные. Для примера правка: [2] --V0d01ey 20:36, 23 января 2016 (UTC)
- Против. Лучше наличие неактуальной информации, чем её отсутствие. Версию программы всегда можно исправить. В некоторых статьях подобные данные находятся на Викиданных, где они могут использоваться во всех проектах Фонда, но не всегда оперативно и правильно обновляются. Если подобные правки делаются, значит это кому-то нужно. Oleg3280 21:10, 24 января 2016 (UTC)
- С другой стороны неактуальность можно считать как один из способов привлечения новых редакторов. --V0d01ey 20:06, 25 января 2016 (UTC)
- Таких незначительных правок действительно много. У идеи удалить совсем мало шансов т.к. будут возвращать или вносить другим образом, ведь "это есть в других вики". Можно было бы попробовать посылать добавлять в Викиданные, но там есть только текущая версия и нет чем заполнить два параметра тестовых версий. Можно ведь делать как в enwiki - через en:Template:LPR. --Сунприат 17:24, 25 января 2016 (UTC)
- Аргумент "есть в других вики" из рода стадного чувства. Нужно приводить более существенные аргументы. Не примите на личный счет. --V0d01ey 20:06, 25 января 2016 (UTC)
- В номере последней версии я никогда смысла не видел, а вот дата показывает хотя бы примерное состояние актуальности проекта. Если с последней версии прошло лет 10, то он явно не поддерживается. Arachnelis 19:00, 25 января 2016 (UTC)
- Если проект не поддерживается, то об этом лучше каким-либо образом указать в статье. --V0d01ey 20:06, 25 января 2016 (UTC)
- Поле "статус" вроде тоже есть, но тут кому как удобнее воспринимать. В принципе, не настаиваю, но лично мне хотелось бы видеть дату первой (вот её сейчас нету) и дату последней актуальной. Примерно как в карточках музыкантов есть годы активности. Arachnelis 17:07, 26 января 2016 (UTC)
- Arachnelis {{Карточка программы}} (первый выпуск, released). Oleg3280 20:05, 26 января 2016 (UTC)
Переименование DDD
Википедия:К переименованию/9 декабря 2015 Подведите итог кто-нибудь. Статья была названа по подобию статьи с msdn [3]. В литературе больше используется другое название. --Сунприат 17:39, 17 января 2016 (UTC)
Всем привет!
Всем привет, недавно присоединился к вашему проекту! Начал участвовать активно в переводе статей с англовики (планы можно посмотреть у меня на странице, буду рад если кто поможет с черновиками). Несколько вопросов:
1. Зашел на главную страницу проекта, потом на страницу болванки статей, попал я явно не в болванки, нажал сразу же в этой программе "Вперед", надеюсь ничего страшного не натворил. Вроде как эта вещь расставляет категории (оно)
2. Где мне задавать вопросы, взывать к помощи и устраивать обсуждения? Здесь правильное место?
Yanpas 19:53, 14 января 2016 (UTC)
- Добро пожаловать! Все вопросы можно задавать здесь. Oleg3280 20:39, 14 января 2016 (UTC)
- Я смотрю, Вы планируете тонко оттачивать направление C-way. Осмелюсь предложить разработанный мной шаблон статьи о ЯП, потихоньку проходящий опробацию на OCaml и Язык модулей ML. Шаблон составлен с прицелом на грамотное, теоретически обоснованное изложение очень широкого класса языков. Если понравится - можете начать потихоньку тянуть Си и С++ в его сторону. Я сам давно планировал, но чувствую, что не успеваю. Arachnelis 22:56, 14 января 2016 (UTC)
- Спасибо, учту. Я по природе своей больше люблю создавать статьи, чем улучшать. Но, возможно, займусь :) Yanpas 23:15, 14 января 2016 (UTC)
- На мой взгляд, Си и С++ требуют переписывания с нуля. Так что это как посмотреть. Arachnelis 18:48, 17 января 2016 (UTC)
- Ну у вас-то взгляд критический . Но даже если и так, ни историческая часть, ни к, примеру, синтаксическая, радикального переписывания уж точно не требуют. И в любом случае предлагать новичку, что называется, для начала, переписать статью на такую тему, это как то… жестоко. --be-nt-all 18:56, 17 января 2016 (UTC)
- Да, я тот ещё злыдень :) Потому и предлагаю шаблонную структуру - она не железобетонная, но является одновременно и напоминанием, чтобы ничего не забыть, и компасом, чтобы правильно всё разделить и соотнести. В нынешней статье начало раздела про синтаксис хорошее, но потом внезапно там же (в синтаксисе - не в семантике) идёт описание, как определять функции и зачем. Я бы мог на скорую руку разнести, но без переписывания и дописывания текста станет лишь хуже, так что это работа. Arachnelis 19:46, 17 января 2016 (UTC)
- И потом, человек же сам сказал, что чукча не читателя, чукча писателя. Вашему покорному слуге это ещё как знакомо. Ну и вот — он напишет в личке черновик с нуля, мы прочитаем, проанализируем и зарубим как полный отстой, а ему лишний опыт в написании. Ведь когда он решит взяться за то, что планировал, то не факт, что с первого раза выйдет хорошо, так что лишняя тренировка не повредит :))) Arachnelis 19:09, 19 января 2016 (UTC)
- Инструмент показал болванки и перенаправления. Значит в перенаправлении стоит категория.По идее в них не должно быть категорий для статей. --Сунприат 12:55, 15 января 2016 (UTC)
Здесь рассмотрено много общих случаев, связанных с экономической составляющей проекта и непосредственно с процессом разработки. Рассмотрены его "ключевые точки". Поэтому, думаю, что можно поднять значимость. 93.92.200.193 19:49, 11 января 2016 (UTC)
- Я за, представляется, что это не просто один из антипаттернов. --be-nt-all 21:55, 14 января 2016 (UTC)
вы в сервисах гугл не написали про сервер 211 тоисть google TrashDeep — Эта реплика добавлена с IP 178.137.214.240 (о)
- [4], даже в англовики такого нет. Oleg3280 20:46, 14 января 2016 (UTC)
К сожалению, не знаю всех тонкостей метапедийного процесса, но было бы интересно разработать минимальные требования к мобильным устройствам. (см. также обсуждение Википедия:Форум/Вниманию участников#Чего народ ждёт от статей по (старым) телефонам?) РоманСузи 18:26, 5 января 2016 (UTC)
- Ну сначала их надо написать. Для этого неплохо было бы несколько образчиков приличных статей о трубках. Не добротных, а именно приличных… Ну а дальше идти с проектом правила на ВП:Ф-ПРА. Кстати, у нас в проекте где-нибудь «рыба» «правильной» статьи о языках программирования лежит? А то взялся сейчас за приведение в чувство двух из них --be-nt-all 19:37, 5 января 2016 (UTC)
- Так вроде кое-что уже написал (см. ссылку в заголовке). На тему языков программирования тут недавно была целая дискуссия: см. Обсуждение проекта:Информационные технологии/Архив/3, а также: Участник:Arachnelis/PL (язык программирования). По моим ощущениям, лучше посмотреть хорошие / избранные статьи и принять во внимание специфику языка. РоманСузи 20:33, 5 января 2016 (UTC)
- Сразу по требованию об указании ОС, ну вот про Huawei G6600 мы знаем, что там ОС некая MTK, но про эту МТК мы ничего не знаем, статьи о ней нет, и сильно не факт, что она возможна, а про что-нибудь более старое, и того можем не знать. А у какого-нибудь Samsung GT-E1080 (нету такой статьи) вообще не факт что об операционной системе говорить корректно. Ну и я бы написал, что хотя бы два пункта из необязательного списка нужны (или что-то в этом роде). Иначе мы получим то, что и так уже имеем. --be-nt-all 21:37, 5 января 2016 (UTC)
- Учёл пожелания. Про ОС - это я к тому, чтобы читатель не гадал, андроидный телефон или что ещё. Конечно, пункт необязателен. Про обязательность 2-х пунктов тоже написал. РоманСузи 10:54, 7 января 2016 (UTC)
- Сразу по требованию об указании ОС, ну вот про Huawei G6600 мы знаем, что там ОС некая MTK, но про эту МТК мы ничего не знаем, статьи о ней нет, и сильно не факт, что она возможна, а про что-нибудь более старое, и того можем не знать. А у какого-нибудь Samsung GT-E1080 (нету такой статьи) вообще не факт что об операционной системе говорить корректно. Ну и я бы написал, что хотя бы два пункта из необязательного списка нужны (или что-то в этом роде). Иначе мы получим то, что и так уже имеем. --be-nt-all 21:37, 5 января 2016 (UTC)
- Так вроде кое-что уже написал (см. ссылку в заголовке). На тему языков программирования тут недавно была целая дискуссия: см. Обсуждение проекта:Информационные технологии/Архив/3, а также: Участник:Arachnelis/PL (язык программирования). По моим ощущениям, лучше посмотреть хорошие / избранные статьи и принять во внимание специфику языка. РоманСузи 20:33, 5 января 2016 (UTC)
- Забыл сказать, что это пока предварительное обсуждение, чтобы потом менее сырое предложение выставить на ВП:Ф-ПРА. Так что прошу критиковать жёстко, если есть уверенность в консенсусе, править напрямую — добавления, убавления, изменения — (и если правка логически важная — написать здесь). РоманСузи 10:59, 7 января 2016 (UTC)
- По электронике (напр. видеокарты, процессоры) в журналах бывают обзоры и сравнения после которых выбирают "победителя" или обзывают в плохом/хорошем смысле. Не всегда очевидно, что здесь можно кроме http ссылок давать ссылки на бумажную литературу. То есть в желательно можно про это и ш:статья упомянуть. В историческом аспекте потом трудно найти конкретную/начальную стоимость на то время. Географические ограничения лучше назвать "особенностями" (напр. блокировка шифрования в партиях для рф). Кажется желательно упоминать отличия от предыдущих телефонов мира/страны/производителя (первый с n пикселями, на n больше предыдущего) - на момент написания их легче сформулировать, чем через n лет. --Сунприат 15:55, 7 января 2016 (UTC)
- (попутно) Как вы думаете, подобный глоссарий: [5] мог бы быть значимым для Википедии? Ведь если серьёзно браться за статьи о телефонах нужно иметь некий глоссарий, на которым можно ссылаться. РоманСузи 15:08, 7 января 2016 (UTC)
Тест новой кнопки
Собственно, нажал на кнопку и пишу здесь. РоманСузи 20:57, 4 января 2016 (UTC)
Возможно появление мелких тем
В шаблон "Статья проекта" добавлена кнопка, через которую со страницы обсуждения статьи можно написать в обсуждение проекта. Вообще попытка привлечь в проект больше людей. "Проект как общая площадка обсуждений". Хоть кнопка и под спойлером... посмотрим, что получится. Пользы от того, что все проекты с шаблоном под копирку было немного. На этой странице далее могут появляться новые небольшие запросы/вопросы. Просьба их не отменять и не откатывать, при необходимости отвечать, добавлять заголовки и ш:unsigned. Срока годности и фильтра для таких запросов пока не предусмотрено. Если вдруг это начнет мешать списку наблюдения (пинги почтой), пожалуйста выскажитесь здесь. --Сунприат 19:05, 11 января 2016 (UTC)
- Сунприат. У меня другое предложение: перенести эти обсуждения на отдельную страницу и сделать изменения в шаблоне проекта. То есть сделать что-то типа ВП:СО, иначе будут теряться остальные сообщения, связанные с проектом. Oleg3280 20:56, 14 января 2016 (UTC)
- Пока не ясно их возможное количество. Ниже вон #Второй этап объединения обсуждения трёх проектов в один хотели объединить из-за небольшого количества тем. Мелкие темы здесь постоянно висели (напр. Обсуждение проекта:Информационные технологии/Архив/1#Псевдомегагерцы в статьях о процессорах). Отдельная подстраница боюсь будет как Википедия:К созданию/Информатика или ВП:ИТ - см. их посещаемость/редактируемость. Переходов (и тем более правок) по подстраницам во всех проектах очень мало. Таким образом, убрав на отдельную, вероятность помощи будет существенно ниже. --Сунприат 09:53, 15 января 2016 (UTC)
В связи с большим дополнением к статьям проекта, глянул сегодня на статистику и создалось впечатление, что критерии, по которым статьи относятся к различным степеням важности, непонятны. Например, в высшей важности фигурирует из персоналий только Хоппер, Грейс (спасибо, раньше о ней совсем не знал, расширил кругозор, просто богиня ИТ). Из структур данных только стек и кэш суперважны и т. д. К сожалению, не нашёл «нормативной базы» для этой классификации. А поле деятельности большое: Категория:Статьи проекта Информационные технологии неизвестного уровня неизвестной важности (2400 статей было когда смотрел). Ну а качество, я полагаю, вот по этому Шаблон:Градации качества статей ? РоманСузи 14:09, 29 декабря 2015 (UTC)
- Отталкиваюсь от переводов англовики найденных для другого проекта Участник:Сунприат/оценки (в англовики шаблон отличается от того, что в рувики, наверное в рувики одна из его старых версий), Проект:Астрономия/Оценки. --Сунприат 14:25, 29 декабря 2015 (UTC) en:Wikipedia:Version 1.0 Editorial Team/Release Version Criteria#Importance of topic --Сунприат 14:31, 29 декабря 2015 (UTC)
- Извините, увлёкся и нашёл сам: Проект:Информационные технологии/Оценки. Скопировал туда из астрономии рыбу. Надо ещё по факту посмотреть, что не учтено. После этого можно наверное и красивый шаблон состряпать. РоманСузи 14:49, 29 декабря 2015 (UTC)
- Беспокоят сайты и телефончики, по обоим дофига, надо ли их вообще в проект тянуть... Железо и ПО нужно отдельно. --Сунприат 14:58, 29 декабря 2015 (UTC)
- Не понял, в каком плане отдельно? Нужно разумную градацию важности предусмотреть. Я так понял, что она строится не только по важности в области (когда об этой важности известно только специалистам), но и «общественной» важности, то, что на слуху? Получается, критерий раздваивается. Кроме того, я не совсем понимаю, почему важность устаревает. Если сайты и телефоны не тянять, хаос будет расти. РоманСузи 15:21, 29 декабря 2015 (UTC)
- Это к главе "аппаратное и программное обеспечение" - казалось критерии под них лучше сразу разделить. Общественная есть и научная есть по количеству публикаций, упоминаний СМИ. Например о звезде могут много писать фантасты или некий информационный всплеск по объекту без научных данных. "Популярнось" статьи по просмотрам/правкам тоже важный показатель для проекта. По устареванию не знаю. --Сунприат 16:19, 29 декабря 2015 (UTC)
- Не понял, в каком плане отдельно? Нужно разумную градацию важности предусмотреть. Я так понял, что она строится не только по важности в области (когда об этой важности известно только специалистам), но и «общественной» важности, то, что на слуху? Получается, критерий раздваивается. Кроме того, я не совсем понимаю, почему важность устаревает. Если сайты и телефоны не тянять, хаос будет расти. РоманСузи 15:21, 29 декабря 2015 (UTC)
- Беспокоят сайты и телефончики, по обоим дофига, надо ли их вообще в проект тянуть... Железо и ПО нужно отдельно. --Сунприат 14:58, 29 декабря 2015 (UTC)
- Извините, увлёкся и нашёл сам: Проект:Информационные технологии/Оценки. Скопировал туда из астрономии рыбу. Надо ещё по факту посмотреть, что не учтено. После этого можно наверное и красивый шаблон состряпать. РоманСузи 14:49, 29 декабря 2015 (UTC)
- Разделить — разделю (в ходе работы большой разницы не заметил). Сейчас я разбросал из Неизв. колонки и дополнил критерии. За редкими исключениями, чем точнее категория, тем ниже важность. Правда, система категорий просто ужас в Википедии, поэтому, может быть, и не получится. А так, если выделить костяк (это не сложно), которому назначить от высшей до средней, остальное в низкую важность (очень редко что вообще выкинул — только принцип Оккама). С ЯП все просто — есть TIOBE, по нему и разнёс. (только Паскаль и Бейсик думаю тоже к высокой важности нужно будет отнести). РоманСузи 19:54, 29 декабря 2015 (UTC)
- Разгрёб статьи до уровня 3 включительно, притянул ДС и ХС ИТ тематики (для улучшения статистика ;-). Дополнил критерии важности примерами и приблизительными руководящими принципами. РоманСузи 14:12, 30 декабря 2015 (UTC)
- Важность можно ещё из проекта англовики взять. Там над большой частью уже проделана работа по оценке. Их высокорейтинговые должны быть и здесь с таким же рейтингом или хотя бы с пустым (неизв.) шаблоном. --Сунприат 14:25, 30 декабря 2015 (UTC)
- У них в топе немного по-своему, например, Fortinet. Так что совсем один к одному не получится. РоманСузи 14:51, 30 декабря 2015 (UTC)
- Важность можно ещё из проекта англовики взять. Там над большой частью уже проделана работа по оценке. Их высокорейтинговые должны быть и здесь с таким же рейтингом или хотя бы с пустым (неизв.) шаблоном. --Сунприат 14:25, 30 декабря 2015 (UTC)
- Я в это дело ни разу не совался и не знал зачем оно нужно. Сейчас подумал, что это теоретически должно влиять на приоритетность активных разработок статей так? Если да, то считаю необходимым заметить, что отсутствующая у нас статья Система типов Хиндли — Милнера в английской имеет высокую важность, а SML — среднюю (хотя я бы поднял вопрос о повышении обеих на одну ступень). Просветите? Arachnelis 16:21, 1 января 2016 (UTC)
- Несуществующим статьям нельзя присвоить важность (или редиректу это можно сделать? высокая — согласен, система типов — высшая должна быть). Что касается SML, поставил ML высокую важность, а вот SML — конкретный язык, поэтому, так как не было в топе TIOBE, на общих основаниях, вместе с OCaml. (Хаскель тоже средняя должна быть). Но это всё можно обсуждать, я лишь пытался хоть какие-то критерии выработать. Эти оценки нужны (как я понимаю) для развития темы, чтобы в первую очередь заниматься более приоритетными и посещаемыми статьями. Никто не запрещает довести SML до избранной и т. д. Более того, я заметил, что «вдохновляют» как раз не очень важные темы. РоманСузи 17:00, 1 января 2016 (UTC) А вот Язык модулей ML поставил формально «среднюю» важность как подтема или элемент ML (высокой важности), но это немного натянуто. РоманСузи 17:06, 1 января 2016 (UTC)
- Лямбда-исчисление в английской имеет высшую важность в CS (всего у статьи стоит четыре важности для разных проектов), и вряд ли это спорно для кого-то. Х-М это прямое развитие лямбда-исчисление в направлении типобезопасности. Но типобезопасность там имеет среднюю важность — всё же, может это динамическая величина — «надо разрабатывать», а не статичная. Почему и задал вопрос. Что язык ниже, чем его фундаментальная база, а его система модулей ещё ниже — это бесспорно. Касательно SML ситуация такая: язык на практике мало популярен, большинство считает его «исследовательским», но совет по его развитию возглавляют ведущие информатики современности, и сам он является вроде как единственным промышленно-ориентированным языком с математически доказанной надёжностью (если не считать интерактивные системы доказательства), что его сильно выделяет из семейства (вплоть до приравнивания к важности самого ML). Arachnelis 17:36, 1 января 2016 (UTC)
- upd: Правильнее сказать, что все ведущие собрались в этот совет — там и Митчел, и Феллайзен - работами по ML так или иначе отметились почти все кто жив и движет информатику вперёд (разве что хаскельщики меньше отмечены, т.к. уже специализируются). Arachnelis 17:53, 1 января 2016 (UTC)
- Полагаю, что оценки всё-таки абсолютные (с точки зрения доработки есть шкала уровень), но несколько зависят от времени (что-то может устареть, что-то не устаревает, появляется новое). Я думаю, что критерии должны быть простые, исключения — индивидуальные. У нас тысячи статей, если каждую обсуждать, никуда дело не двинется, поэтому если греет душу, поставьте важность повыше. («проект — это мы»). РоманСузи 18:56, 1 января 2016 (UTC)
- LLVM (и, кстати, GCC) ещё не оценены. Как по мне, несмотря на относительную молодость продукта/технологии (книги, целиком ей посвящённые появились относительно недавно), первая тянет никак не меньше высокой (основа для многих-многих трансляторов, в том числе для референсных и единственных реализаций таких языков, как Swift, Julia (язык программирования) и др.) --be-nt-all 18:08, 1 января 2016 (UTC)
- думаю, у GCC высшая в проекте СПО, здесь на ступень меньше (иначе «у семи нянек»). РоманСузи 18:56, 1 января 2016 (UTC) Но может быть и на две ступени, всё-таки конкретика. РоманСузи 21:50, 1 января 2016 (UTC)
Наверно, Архитектура фон Неймана сверхважная, или нет? Д.Ильин 21:59, 1 января 2016 (UTC).
- Хорошо, у GCC пусть будет средняя, высшая она действительно именно для СПО, а что называется, с общеIT-шной т.з. может как-раз таки средняя… У Visual Studio такая-же будет? Но вот LLVM я никак ниже высокой не вижу. Кто-нибудь против? --be-nt-all 21:55, 5 января 2016 (UTC)
- Вы правы, поставил этой и гарвардской высшую важность. РоманСузи 06:58, 2 января 2016 (UTC)
- Поставил плашку с высокой важностью в несколько "компьютерных заболеваний" - воздействует абсолютно на каждого взаимодействующего с техникой. --Сунприат 10:25, 7 января 2016 (UTC)
Психологический аспект
Задумался ещё об одной возможной проблеме. Скажем, кто-то только что написал статью (Manual Data Input). Кто-то другой пришёл и совершенно корректно влепил важность=низкая для проекта. У меня такое ощущение, что если так делать в масштабе, это скорее деструктивное действие с психологической точки зрения... Может низкую важность вообще не размечать (те, что размечены оставить конечно)? Какие будут соображения? РоманСузи 07:26, 2 января 2016 (UTC)
- Ну, лично меня, к примеру, низкая важность, к примеру, IDE Decoda для всего IT никак не напрягает, объективно оно так и есть. Но за новича говорить не могу. --be-nt-all 07:33, 2 января 2016 (UTC) Ну или, к примеру Конкатенативное программирование или Комбинаторное программирование (для которого адекватный русскоязычный термин пришлось выгугливать по не самым авторитетным источникам) это не объектно-ориентированное программирование или функциональное программирование. Хотя Комбинаторное программирование обобщающее понятие для того-же комбинаторного, ну и у истоков стоял ни много, ни мало, а сам Джон Бэкус, так что для него наверное важность средняя… --be-nt-all 07:44, 2 января 2016 (UTC)--be-nt-all 07:44, 2 января 2016 (UTC) Однако, смотрю, у комбинаторного программирования смотрю, уже высокая стоит. Что-ж, хорошо, тогда конкатенативное должно быть средним? --be-nt-all 07:55, 2 января 2016 (UTC)
- ООП — парадигма с высшим, посчитал, что менее известные парадигмы всё-таки высокое? (хотя очень часто парадигмой называют всё направо и налево…). Поправьте. РоманСузи 09:36, 2 января 2016 (UTC)
- Да нет, я-то не против, особая разновидность функционального программирования с отличной от аппликативного функционального программирования математической базой. И сам Джон Бэкус, который будущие языки видел именно такими, в отцах основателях. Смущает только то, что по какой нибудь несчастной реактивной или аспектно-ориентированной парадигме отдельные книги есть, вроде даже на русском, а тут — как-то не попадались. --be-nt-all 13:11, 2 января 2016 (UTC)
- Кстати, является ли «важность» на самом деле градациями значимости? Другими словами, мы пытаемся определить, что более значимо:аспектно-ориентированное программирование или Комбинаторное программирование? С другой стороны, даже по значимости проходят баталии (на КУ), этот процесс очень сложный. Здесь же у нас критерий должен быть попроще. По взгляду на начало статьи, её категории/под/надкатегории обычно уже некоторое впечатление складывается. Правда, в результате оценивания кое-что и на КУ нужно выностить… А так, у АОП посещаемость на порядок выше. Нам же нужно интегрированно оценить в важности 1) важность темы в системе знаний 2) популярность. РоманСузи 14:06, 2 января 2016 (UTC)
- Связь между важностью в шаблоне и значимостью может быть, но она неочевидна. Сейчас просмотрел список статей IV уровня низкой важности, там есть статьи, с удалением которых по незначимости лично я бы не согласился. По другим уровням такие статьи тоже есть. С другой стороны, даже здесь увидел несколько статей, баталии по которым на КУ могу себе представить. Кроме того, на КУ значимость либо есть, либо нет, а у важности несколько градаций. — Stannic(обс)(вкл)(выкл) 19:16, 2 января 2016 (UTC)
- Кстати, является ли «важность» на самом деле градациями значимости? Другими словами, мы пытаемся определить, что более значимо:аспектно-ориентированное программирование или Комбинаторное программирование? С другой стороны, даже по значимости проходят баталии (на КУ), этот процесс очень сложный. Здесь же у нас критерий должен быть попроще. По взгляду на начало статьи, её категории/под/надкатегории обычно уже некоторое впечатление складывается. Правда, в результате оценивания кое-что и на КУ нужно выностить… А так, у АОП посещаемость на порядок выше. Нам же нужно интегрированно оценить в важности 1) важность темы в системе знаний 2) популярность. РоманСузи 14:06, 2 января 2016 (UTC)
- Да нет, я-то не против, особая разновидность функционального программирования с отличной от аппликативного функционального программирования математической базой. И сам Джон Бэкус, который будущие языки видел именно такими, в отцах основателях. Смущает только то, что по какой нибудь несчастной реактивной или аспектно-ориентированной парадигме отдельные книги есть, вроде даже на русском, а тут — как-то не попадались. --be-nt-all 13:11, 2 января 2016 (UTC)
- ООП — парадигма с высшим, посчитал, что менее известные парадигмы всё-таки высокое? (хотя очень часто парадигмой называют всё направо и налево…). Поправьте. РоманСузи 09:36, 2 января 2016 (UTC)
- Лично меня бы не задело, но про новичков трудно сказать. Вот я пришёл, написал статью, приходит кто-то другой, ставит важность=низкая. С одной стороны, мою статью заметили, с другой стороны, посчитали маловажной. Можно, наверно, вначале просто ставить плашку с незаполненным параметром (может быть даже независимо от важности - т.е. от низкой до высшей), хотя и говорят, что надо сразу заполнять. Спустя какое-то время (пара недель - месяц) периодически проходить по неоценённым статьям и оценивать, или оценивать вместе с другими правками в обсуждении. — Stannic(обс)(вкл)(выкл) 07:58, 2 января 2016 (UTC)
- Давайте добавим, что для сравнительно «молодых» статей, для которых важность не выше низкой, ставить плашку с пустыми важностью и уровнем (кто знает, может автор в течение года допишет). Низкий предлагаю массово не ставить. Не вижу в нём дополнительной информации по сравнению с неизвестным, а труда по проставлению много. Думаю, что опытным участникам хоть на КУ выставляй — ко всему привыкли, а редакторов-новичков лучше поначалу ограждать. Если не будет возражений, можно добавить примечанием к оценкам. РоманСузи 09:41, 2 января 2016 (UTC) Другой свежий пример в процессе: Обсуждение:ALOHAnet, где не поставил пока что ни важности, ни уровня (статья в процессе доработки до ДС — зачем дёргаться раньше времени) РоманСузи 09:50, 2 января 2016 (UTC)
- Тогда обидятся новички, которые как-то узнают, что не проставлено = низкая важность :) Вариант — какое-то время после создания статьи вовсе никакие уровни не ставить, хоть она важная, хоть нет. Но пусть другие участники выскажутся — Stannic(обс)(вкл)(выкл) 10:09, 2 января 2016 (UTC)
- Давайте добавим, что для сравнительно «молодых» статей, для которых важность не выше низкой, ставить плашку с пустыми важностью и уровнем (кто знает, может автор в течение года допишет). Низкий предлагаю массово не ставить. Не вижу в нём дополнительной информации по сравнению с неизвестным, а труда по проставлению много. Думаю, что опытным участникам хоть на КУ выставляй — ко всему привыкли, а редакторов-новичков лучше поначалу ограждать. Если не будет возражений, можно добавить примечанием к оценкам. РоманСузи 09:41, 2 января 2016 (UTC) Другой свежий пример в процессе: Обсуждение:ALOHAnet, где не поставил пока что ни важности, ни уровня (статья в процессе доработки до ДС — зачем дёргаться раньше времени) РоманСузи 09:50, 2 января 2016 (UTC)
- Для новичка важность статьи для какого-то там проекта дело последнее. По моему опыту статья пишется на интересности для себя. Автор в шаблоне смотрит уровень и пытается понять что нужно добавить. Автор лучше знает тему. Когда ему поставят низкую, если его это заденет, он может возразить, пойти ознакомится по ссылке с описанием и поднять уровень лучше чем сторонний человек (лучше, если в тексте оценок будет отдельным абзацем про возможность "править смело" оценку). На напр. сайты/телефоны низкую можно спокойно ставить. --Сунприат 12:56, 2 января 2016 (UTC)
- Ну а правила вообще где-нибудь описаны? Я вот пару дней думал в своей специфике, и понял, что таки надо так: лямбда-исчисление как фундаментально теоретическое исчисление, лежащее в основе много чего, должно иметь высшую. Система F, Х-М, полиморфизм и т. п. — либо тоже высшую, либо на ступень ниже, как продолжения и детали, то есть высокую. Следом идут ML, Lisp, Algol, Simula, Smalltalk, Prolog и т. д. — языки, возглавляющие семейства языков, вехи истории и максимально семантически различные. Их потомки и конкретные диалекты — следом. Ну и затем детали по этим языкам, библиотеки, «Операторы в C и C++» — всё низкое. По частностям типа Язык модулей ML можно спорить, здесь плюс-минус одна ступень максимум. Все «идиоматические парадигмы» в этой схеме будут, видимо «высокие» либо «средние» (но так или иначе равные), а вот «математические парадигмы» (динамическое, автоматное) — выше на шаг. Так же и с архитектурами — машина Тьюринга высшая, фон-Неймана следом. Кто что скажет? Arachnelis 21:40, 2 января 2016 (UTC)
Сравнения
Вот отсюда: Категория:Сравнение программного обеспечения заводить как список? (Несколько уже завёл так, смотря на ВП:Списки-2). РоманСузи 18:03, 3 января 2016 (UTC)
- Ага. Сложно представить для них 1-й и 2-й уровни. Полуориссная спискота. --Сунприат 22:52, 3 января 2016 (UTC)
Языковеды опять против
Обращаю внимание всех ещё не заметивших на обсуждение массового переименования: Википедия:К переименованию/22 декабря 2015#Контекстно-xxx, объектно-xxx, телесно-xxx на основе gramota.ru и каких-то неизвестно откуда притянутых правил. РоманСузи 21:06, 22 декабря 2015 (UTC)
- Пока был занят защитой слова кэш, то не заметил этого обсуждения. Oleg3280 21:54, 22 декабря 2015 (UTC)
Второй этап объединения
Прошу обратить внимание на обсуждение: Википедия:Совет вики-проектов/Обсуждение проектов/2015#IT-проекты.--Abiyoyo 19:47, 26 сентября 2015 (UTC)
Kik Messenger
Коллеги, оказалось в рувики нет статьи про очень популярный сервиз Kik Messenger (англ. статья - https://en.wikipedia.org/wiki/Kik_Messenger), которым пользуются сотни миллионов людей. Статья про него есть во всех основных языковый разделах, кроме русского. Кто нибудь возьмется за создание статьи? Миша Карелин 13:44, 17 сентября 2015 (UTC)
- За час поиска так и не понял за что там миллионы вливаний. Это кто-то знающий должен писать. --Сунприат 17:14, 20 сентября 2015 (UTC)
Буферы обмена и ввода/вывода
Так как это обсуджение имеет прямое отношение к проекту, прошу принять участие. Спасибо. Oleg3280 13:20, 16 августа 2015 (UTC)
- Кто вникал, добавьте про разное написание термина в саму статью. --Сунприат 10:57, 19 сентября 2015 (UTC)
Перенёс из основного пространства, так как это не дизамбиг (нет омонимов), а скорее координационный список по «типизация X». РоманСузи 10:05, 17 января 2015 (UTC)
Есть предложение делать статью "Значения, индексированные типами", а "Класс типов" туда разделом (как встроенную в язык поддержку) и сам термин направлять на этот раздел. Для начала, конечно, можно просто английскую en:Type class перевести, остальное-то самим писать придётся. Всё ещё не могу вернуться к работе, но мысль пока закидываю. Arachnelis 19:51, 25 июня 2015 (UTC)
- upd: или наоборот. Arachnelis 20:20, 27 июня 2015 (UTC)
Ещё предложение. Я давеча сделал статью Конструктор данных, но это название не-АИшечное. Положено переименовать в «Конструктор (функциональное программирование)» (по аналогии с «Конструктор (объектно-ориентированное программирование)»), но тогда хорошо бы подумать как её лепить в Шаблон:Типы данных и другие подобные места, где дисамбигов не предполагается (прежде всего под шапку Конструктор типов, где «не путать»), и не надо ли туда же ООПный вариант вставить, и как тогда их различить. Можно, конечно, в лобовую:
" • Конструктор (ФП) • Конструктор (ООП) • ". Arachnelis 20:52, 30 июня 2015 (UTC)
Перенос координационного списка
Уважаемые коллеги, прошу обратить внимание, что согласно итогу на КУ к вам в проект перенесён следующий координационный список: Проект:Информационные технологии/Списки/Список программ для скринкастинга.----Ferdinandus 07:23, 15 января 2015 (UTC)
Команды Unix
Встречаю много статей вроде unset и подобных из
Есть ли у отдельных команд значимость (я лично сомневаюсь)? Некоторое время назад удалили (с моей подачи) список этих самых команд, так как он оброс не относящимися к POSIX командами. Нужно ли Википедии дублировать систему man или спецификации POSIX? На тему unset больше абзаца не написать: статья заведомо нежилец. Полагаю, что наиболее известные команды имеют право быть в Википедии (они в основном известны и для них выполняются требования по значимости), остальные нужно либо под каким-то зонтиком собрать, либо от них избавиться. Аналогично и команды других ОС. РоманСузи 08:28, 10 января 2015 (UTC) Может быть, больше подходит форма списка ВП:ГЛОССА, если использовать собирательный источник? РоманСузи 08:53, 10 января 2015 (UTC)
- Пример (правда, не совсем оформленный): Список команд DOS. Так правильнее или плохо? РоманСузи 08:59, 10 января 2015 (UTC)
- См. en:Wikipedia:Articles for deletion/Date (Unix), en:Wikipedia:Articles for deletion/DATE (command). ~Сунприат 17:06, 10 января 2015 (UTC)
- Не понял? Перефразируя: удалить нельзя оставить? Распихать по другим статьям? РоманСузи 07:12, 16 января 2015 (UTC)
Ещё из той же серии sstream и компания, из которых наиболее вопиющий string (C++). РоманСузи 13:33, 25 января 2015 (UTC)
- А не перебор ли писать целую пачку статей, да ещё со своим нав.шаблоном, по библиотеке одного языка? Если так можно, я тоже по SML забадяжу :P Arachnelis 14:47, 25 января 2015 (UTC)
- С одной стороны есть разные Диплатинатрииндий и звёзды оставляли при нахождении хоть одного исследования по ним. С другой - на эти статьи распространяется ВП:СОФТ, а описание в пару строк в учебниках по этому языку недотягивает до подробного рассмотрения в АИ. Пока применил бы шаблон на Значимость. Что скажете, у:Higimo? --Сунприат 19:02, 25 января 2015 (UTC)
- У:Сунприат, про STL есть книги, но вот конкретно по её частям, там наврятли написано. Классический случай «не значимо в отрыве от основной статьи». Вероятно, надо удалять сразу. Хотя считаю, что лучше всего написать на форум для привлечения внимания. Всё такие программистов достаточно много, авось у кого-то литература на руках. --higimo (обс.) 21:49, 25 января 2015 (UTC)
- Скажем, про sstream целый параграф в C++ in Nutshell с его 12 классами. Нужно ли оно в полном составе в Википедии? Кое-какие наиболее известные (типа vector) вполне, но весь Library reference? (при этом я не призываю тут же начать удалять массово — это больше к тому, чтобы такого больше не плодить, а выставить на удаление желающих найдётся) РоманСузи 04:47, 26 января 2015 (UTC)
- Доктор, меня все игнорируют. Ссылок на библиотеку SML Basis - как звёзд на небе, и не Хабре, а в академических статьях и диссертациях. Тем не менее, я счёл бы абсурдом написание более чем одной обзорной статьи по общей структуре и идеологии. Пачка статей про STL может быть разве что где-нибудь на Викискладе или чём там. Но в энциклопедии общего назначения ей не место. Arachnelis 19:16, 16 февраля 2015 (UTC)
- Давно сюда не заглядывал, так что пардон за почти некропостинг. За отдельные части STL на вскидку не скажу, но по крайней мере часть команд unix shell точно значима. И я не только о sed и awk, о многих командах попроще (без собственных языков программирования) пишут целые журнальные статьи. Но копия man-страницы, конечно, в ВП не очень нужна --be-nt-all 21:33, 27 июня 2015 (UTC)
Листинги кода в статьях
Что делать с длинными листингами? Бывает листинги даже горизонтально не влезают и отображаются с прокруткой (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)
- @РоманСузи: До переносов хотел затронуть проблему указания/сохранения авторства при переносах в другие проекты... ~Сунприат 20:49, 3 января 2015 (UTC)
- FYI, задал вопрос здесь: b:Обсуждение участника:Ivan Shmakov#Реализации алгоритмов РоманСузи 21:08, 3 января 2015 (UTC)
- миниитог: про авторство уточнили и занесли в ВП:ИТ --Сунприат 21:18, 26 июня 2015 (UTC)
- @РоманСузи: До переносов хотел затронуть проблему указания/сохранения авторства при переносах в другие проекты... ~Сунприат 20:49, 3 января 2015 (UTC)
- (Пока не уверен с консенсусом о переносе, хотя уже много чего до нас перенесли). Но технически наверное стоит оставлять некий комментарий, чтобы Реализации и не добавляли в статью? Или во всяком случае не на N+1-м языке? В общем, какой-то намёк, но где. Может, на СО (уже в ВП)? РоманСузи 22:22, 3 января 2015 (UTC)
- По мне, лучшим указателем (тот "комментарий") послужит "а как это оформлено в других статьях". Первое, что представилось - смесь Ш:wikibooks и Ш:Внешние медиафайлы со справочной ссылкой на пояснение в ВП:ИТ, но это значит перелопатить все статьи, нужно подумать. ~Сунприат 22:57, 3 января 2015 (UTC)
- Но у проекта уже есть шаблон на СО многих статей (хотя в случае с алгоритмами там может быть и проект Математика). Может там какой «подвальчик» можно открыть? Кроме того, правила не обязывают участников следовать нормам какого-то проекта. Полагаю, что наиболее верный вариант — это продумать до конца процесс (критерии плохих листингов, инструкцию по переносу, какие шаблоны куда ставить) и включить в нормативные документы. РоманСузи 08:23, 4 января 2015 (UTC)
- По мне, лучшим указателем (тот "комментарий") послужит "а как это оформлено в других статьях". Первое, что представилось - смесь Ш:wikibooks и Ш:Внешние медиафайлы со справочной ссылкой на пояснение в ВП:ИТ, но это значит перелопатить все статьи, нужно подумать. ~Сунприат 22:57, 3 января 2015 (UTC)
- (Пока не уверен с консенсусом о переносе, хотя уже много чего до нас перенесли). Но технически наверное стоит оставлять некий комментарий, чтобы Реализации и не добавляли в статью? Или во всяком случае не на N+1-м языке? В общем, какой-то намёк, но где. Может, на СО (уже в ВП)? РоманСузи 22:22, 3 января 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)
- Недолго место пустовало: [6]... РоманСузи 20:01, 9 января 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)
- В основном обсуждение не пошло, не восприняли всерьёз. Кое-где [7] подошли радикально. В некоторых вики (вроде 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)
- В основном обсуждение не пошло, не восприняли всерьёз. Кое-где [7] подошли радикально. В некоторых вики (вроде pl и de) видел мало кода в противовес количеству кода по другим интервикам на тех же статьях. Значит они где-то обсуждали - поищу. --Сунприат 07:23, 24 января 2015 (UTC)
- В англоВикиучебнике на 4-х языках, в статье на двух. Так в нескольких статьях видел - два в статье, остальные в учебнике. Требовать ссылку на код (подобный) имеет смысл в сложных/длинных случаях. По fair-use вопрос интересный, т.к. текст из Википедии далее может использоваться в коммерческих целях. Копировать - плохо, пригодилась бы подборка ссылок на тему лицензий - стоит рассмотреть отдельно; после замены стиля/названия переменных код считается тем же. --Сунприат 07:23, 24 января 2015 (UTC)
- Код считается тем же после эквивалентных преобразований? Но тогда он может считаться подобно математической формуле: en:Idea–expression divide. РоманСузи 07:42, 24 января 2015 (UTC)
- Перевод части про код из рекомендаций по стилю из англовики как основу для своей рекомендации. Опрос/обсуждение (RFC запрос на комментарии) по тому подходят ли нам эти части и есть и чем их дополнить. Написал в примерно 10 вики с примером декоратора или прототипа. В трёх сказали, что их статьи это перевод англовики и в англовики есть такие листинги при том, что в англовики есть упомянутые рекомендации. В некоторых сказали, что это не проблема. Кстати, в польской совсем нет кода (в статьях о шаблонах), а в немецкой только на одном языке и там пока ответили что это больше нормально, чем нет. Посмотрю, разовьется ли в других вики обсуждение. Пока количество заинтересованных сторон можно сузить до нашего раздела и проекта в англовики. Все ваши ответы держу на виду, но хочу менее голословно подойти к ответам, т.к. задаюсь теми же вопросами. --Сунприат 21:17, 21 января 2015 (UTC)
- Не совсем понял: перевод книги или чего? И по пунктам чего опрос (там был какой-то опрос)? Забавно, в англовики en:Adapter_pattern по качеству хуже, чем b:en:Computer_Science_Design_Patterns/Adapter. А реализации и там, и там... Мне кажется, что до сих пор листинги вообще не снабжают источниками: если листинг из источника скопирован, то это копивио, а если не скопирован, то что с ним делать? Переименовывать переменные и функции. Или это fair-use? (извиняюсь за отклонение от темы, но я уже около двух десятков алгоритмов перевёл в Викиучебник, в том числе выковырял из Истории правок (BioMaxHazard любил удалять реализации) и такой вопрос о соответствии листинга заявленному всегда крутится в голове. То есть, хотелось бы в Википедии иметь шаблоны проектирования по источникам, а не то, что Вася Пупкин посчитал написанным по шаблону. РоманСузи 14:20, 21 января 2015 (UTC)
- О крестовом походе никто и не говорит. В каждом конкретном случае, в том числе в случае длинного листинга, следует рассматривать его энциклопедическую ценность для статьи. С другой стороны, у нас есть ВП:ПРОВ, и я могу прямо сейчас отметить большинство листингов из шаблонов требованиями источников, потому как почему без АИ я должен верить, что приведённый листинг является реализацией шаблона, даже если ВП:ПДН, автор может ошибаться? Конечно, для каких-то языков АИ найдутся и более того, пример на реальном языке может много дать читателю (псевдокод тут будет выглядеть несколько странно), но сразу на нескольких? В любом случае, пока ничего с этим не делаем за исключением вопиющих случаев, если таковые найдутся. РоманСузи 07:11, 16 января 2015 (UTC) Добавил в черновик, посмотрите пожалуйста, что добавление имеет смысл. РоманСузи 07:18, 16 января 2015 (UTC)
- Предложили такой план: перевод англовики, организация по его пунктам опроса, создание рекомендации по результатам. Каждое сообщество должно решать само что делать - попробую им на форумы что-нибудь написать. --Сунприат 09:48, 21 января 2015 (UTC)
- Вывод: 1) схожесть оформления позволяет использовать поиск mw:Help:CirrusSearch/ru, например по "пример реализации". 2) добавления/оформления/удаления отслеживаются в истории. Крестовый поход против кода мы в одиночку не объявляем. Предлагаю участникам из истории расставлять на личной странице обсуждения приглашение сюда в виде "приглашаю присоединиться к проекту. сейчас в проекте обсуждается оформление кода в текстах, где нам интересно ваше мнение." 3) Это проблема не только нашего раздела (см. французский) нужна консультация в англовики и уровня мета-вики. Посмотрю, что можно сделать. / В более развитом en.wikibook шаблоны собраны в отдельную книгу. Пока проще сделать по их подобию, а перекомпоновать всегда успеем. --Сунприат 05:29, 16 января 2015 (UTC)
- Ещё 1) в комп. журналах, конференциях, сборниках, наших/зарубежных, куда отдаются статьи, есть правила публикации и оформления и там может быть про цитирование кода. 2) Тут en:Software design pattern#Documentation примеры кода и реализация разделены - можно этот момент развить на одной статье и дать как пример. Вообще, попадающиеся хорошо оформленные статьи (о, можно посмотреть по хорошим/избранным) в других вики стоит упоминать в наших рекомендациях как ориентиры. --Сунприат 02:26, 24 января 2015 (UTC)
- Ок, буду иметь в виду. РоманСузи 07:42, 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)
Конкретные предложения
- Черновик с предложением об оформлении. Поправьте, пожалуйста, если что-то забыл или что-то не нравится. РоманСузи 11:03, 4 января 2015 (UTC)
- А что делать с такими Обсуждение:Алгоритм Коэна — Сазерленда доброжелателями? Из обсуждений тоже вырезать в обсуждения викикниг? Судя по англовики b:en:Talk:Algorithm Implementation/Sorting/Bubble sort обсуждения в викикнигах та ещё трясина. Шаблонов Статья проекта там вроде бы нет. ~Сунприат 19:49, 8 января 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)
- Осмелюсь вставить пять копеек, хоть и начал уже было отрекаться от залезания в правила. Народ, вы забыли провести самую главную разграничительную линию: примеры кода в статье о языке и примеры кодов на разных языках в статье об алгоритме (паттерне, пр, нужное подчеркнуть). ИМХО, эта вилка должна породить не одно, а два правила. Что по первому, то вобщем-то очевидно: не слишком длинно, не слишком мудрёно алгоритмически, и чтобы давало представление о языке. Псевдокод тут ни при чём — это как зубы удалять по фотографии. С недетерминированными языками псевдокод читателя так запсевдокодит, что тот без алкоголя спать не ляжет. По второму я предлагаю пройтись по АИшечкам и составить список языков, которые считаются достаточно легко читаемыми для демонстрации алгоритмов. Есть классические примеры — C (но не С++), Pascal (но не Delphi), Java (но не С#), Python, SML (или OCaml), Haskell (но не Scala). Лиспы лучше не трогать, ибо синтаксис ваистену (не в обиду Лиспу), в крайнем случае Scheme. Могу заметить, что когда в литературе по ФП рассматривают ИП/ООП, то примеры приводят на Java (пример). upd: Ещё нужно требовать либо обходиться без API совсем, либо использовать только «самые стандартные» библиотеки, идущие от корней
- Нужно удобное указание ссылки на примеры. Ссылка из шаблона навигации в конце статьи плохо подходит. Её текст "тема в викиучебнике" читателю не понятен. Как вариант, текст, подобный Ш:См. также, "см. примеры темы на разных языках" курсивом после блока с примером в статье. --Сунприат 18:12, 26 мая 2015 (UTC)
- Вариант: не накладывать ограничения на язык. В статье остаётся тот код, к которому есть пояснения текстом (или внутренние комментарии) на русском. Что должно оставаться в каждом случае решается отдельно обсуждением на СО статьи. @РоманСузи: ещё про обычный текст спросил b:Обсуждение участника:Ivan Shmakov#Реализации алгоритмов. --Сунприат 21:18, 26 июня 2015 (UTC)
- Тем не менее, читабельность должна быть. У читателя не должно быть лишних препятствий в понимании алгоритма из-за каких-то неочевидных особенностей, побочных эффектов и т. п. языка. РоманСузи 16:31, 27 июня 2015 (UTC)
Найденные обсуждения
- Википедия - не stackoverflow. РоманСузи 16:49, 26 января 2015 (UTC)
- https://en.wikipedia.org/wiki/Special:Search?search=source&prefix=Wikipedia+talk:WikiProject+Computing/&fulltext=Search+archives&fulltext=Search https://en.wikipedia.org/wiki/Special:Search?search=source&prefix=Wikipedia+talk:WikiProject+Computer+science/&fulltext=Search+archives&fulltext=Search --Сунприат 08:24, 9 февраля 2016 (UTC)
GitHub, GitHub Gist и т.д.
- Есть предложение писать листинги на GitHub, и выводить их в статьи с помощью плагина. Плюсы: кроме участников Wiki, код могут проверить и исправить пользователи GitHub, минусы те же, что и плюсы, и к ним еще хранение на внешнем сайте. Тем не менее предлагаю обсудить. --Sergey Funn 20:41, 14 октября 2015 (UTC)
- В этом, конечно, что-то есть, но проекты Викимедиа, полагаю, должны быть самодостаточны. Если бы была уйма времени, для примеров можно было бы не только сами листинги, тесты к ним, но и строгие доказательства правильности алгоритмов для подходящих случаев. Не думаю, что дойдёт до автоматической синдикации, но для раздела Ссылки мог бы быть шаблончик. Другая проблема — кто бы был админом такого github-проекта? РоманСузи 06:25, 15 октября 2015 (UTC)
- Для листингов есть Викитека. -- Andrew Krizhanovsky 07:03, 15 октября 2015 (UTC)
- Туда только куски книг можно "уже изданных книг, журналов, газет." По сборникам рецептов "отсебя" пока сотрудничаем с викикнигами. --Сунприат 07:11, 15 октября 2015 (UTC)
- А формат «код говорит сам за себя» больше для викиверситета, IMHO. --be-nt-all 00:12, 15 января 2016 (UTC)
- Как это может выглядеть? В v:en:Category:Computer science нет стен из листингов на разных языках. --Сунприат 13:32, 15 января 2016 (UTC)
- А формат «код говорит сам за себя» больше для викиверситета, IMHO. --be-nt-all 00:12, 15 января 2016 (UTC)
- Туда только куски книг можно "уже изданных книг, журналов, газет." По сборникам рецептов "отсебя" пока сотрудничаем с викикнигами. --Сунприат 07:11, 15 октября 2015 (UTC)
- Для листингов есть Викитека. -- Andrew Krizhanovsky 07:03, 15 октября 2015 (UTC)
- В этом, конечно, что-то есть, но проекты Викимедиа, полагаю, должны быть самодостаточны. Если бы была уйма времени, для примеров можно было бы не только сами листинги, тесты к ним, но и строгие доказательства правильности алгоритмов для подходящих случаев. Не думаю, что дойдёт до автоматической синдикации, но для раздела Ссылки мог бы быть шаблончик. Другая проблема — кто бы был админом такого github-проекта? РоманСузи 06:25, 15 октября 2015 (UTC)
- Предложение не выдерживает критики: не реально следить за изменениями. Кто-то один будет администрировать пул реквесты — уйдёт, загнётся всё. Будут в общественном доступе — можно вандализировать, пока никто не заметит. Сильно лучше код не станет, но усложнит его улучшение для рядового википедиста, который не готов мучаться с этими ssh-ключами и они сторонники этого вашего пароля, а онлайн редактирования, насколько мне известно, пока нет (могу ошибаться). Всего улучшения от выноса на гитхаб это то, что его могут найти местные жители и улучшить или дополнить, чего нам не надо. Мы тут не код пишем, а энциклопедические статьи. Заходишь, например, в факториалы, а там «каждый уважающий себя говнокодер» уже написал характерный код на своём любимом языке, когда гораздо правильнее использовать псевдокод. Может, я чего-то не знаю, но как будут находить наши репозитории? Архитектура тоже не понятна. Снипеты это будут или реальные файлы репозитория? --higimo (обс.) 08:22, 15 января 2016 (UTC)
- @Sergey Funn: Из Википедии можно расставить ссылки. Как это будет в GitHub? Как можно организовать столько тем? Как можно организовать комментарии, пояснения на разных языках? Как дела с лицензией? CC BY-SA для копирования частей туда и обратно? Есть ли уже там что-нибудь подходящее начатое? --Сунприат 17:36, 8 февраля 2016 (UTC)