Эта страница архивируется ботом

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

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Содержимое удалено Содержимое добавлено
[[Уязвимости 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

Пожалуйста, добавляйте новые темы в начало страницы.  Добавить
К удалению
  1. BeOS API1 декабря 2024
  2. Тема оформления23 ноября 2024
  3. PIO21 ноября 2024
  4. Рогов, Александр Николаевич (стилист)16 ноября 2024
  5. Мессенджер eXpress14 ноября 2024
  6. Карельское национальное движение9 ноября 2024
  7. Хуевая Одесса9 ноября 2024
  8. Тодд, Питер18 октября 2024
  9. Каттинг, Дуглас Рэд14 октября 2024
  10. Wynk Music12 октября 2024
  11. Trucker Guide11 октября 2024
  12. Дата-центр Covilhã11 октября 2024
  13. Бробанк.ру9 октября 2024
  14. Мультимодельная база данных7 октября 2024
  15. .porn6 октября 2024
  16. Embox6 октября 2024
  17. .fun1 октября 2024
  18. TsiLang Components Suite1 октября 2024
  19. Сторонние библиотеки Python30 сентября 2024
  20. Scriptol29 сентября 2024
  21. Тамаев, Асхаб Лечаевич27 сентября 2024
  22. Codemasters Code Cup5 сентября 2024
  23. Программно-ориентированные ускорители (набор команд)3 сентября 2024
  24. Список систем управления пакетами программного обеспечения1 сентября 2024
  25. Редькин, Николай Романович31 августа 2024
  26. Pytest23 августа 2024
  27. Дадван Юсуф15 августа 2024
  28. Список устройств на базе Android TV15 августа 2024
  29. Slony-I11 августа 2024
  30. Разворот (YouTube-канал)7 августа 2024
  31. Чебыкина, Ольга Юрьевна5 августа 2024
  32. Armadillo V24 августа 2024
  33. CHESS (динамический анализатор)1 августа 2024
  34. Сравнение FTP-клиентов30 июля 2024
  35. MDLC17 июля 2024
  36. Степанова, Вероника Юрьевна8 июля 2024
  37. Grimacecoin1 июля 2024
  38. КВН для всех24 июня 2024
  39. Крыгина, Елена Александровна19 июня 2024
  40. Запись-ориентированная файловая система18 июня 2024
  41. Список версий Microsoft SQL Server3 июня 2024
  42. Thomas Register23 мая 2024
  43. Xiaomi HyperOS7 мая 2024
  44. NFS-LAN2 мая 2024
  45. Direct2D27 апреля 2024
  46. Лексикон (ролевая игра)27 апреля 2024
  47. OpenModelica22 апреля 2024
  48. The Breakfast Show16 апреля 2024
  49. Comodo Cleaning Essentials14 апреля 2024
  50. Fabasoft eGov-Suite13 апреля 2024
  51. Open-E13 апреля 2024
  52. Строгий выговор (фильм)8 апреля 2024
  53. Цензор.нет29 марта 2024
  54. Яндекс Народная карта22 марта 2024
  55. LanDrive12 марта 2024
  56. SocialEngine2 марта 2024
  57. Mellstroy27 февраля 2024
  58. Оверселлинг18 февраля 2024
  59. VolunteerMatch12 февраля 2024
  60. STO (криптовалюты)3 февраля 2024
  61. Fake Taxi30 января 2024
  62. KMON29 января 2024
  63. .орг28 января 2024
  64. CBOSS28 января 2024
  65. East Imperial Soft28 января 2024
  66. Gurtam28 января 2024
  67. T-Systems CIS28 января 2024
  68. Простой тип25 января 2024
  69. Список языков описания пользовательских интерфейсов23 января 2024
  70. E107 CMS22 января 2024
  71. Список кодов ответов FTP22 января 2024
  72. Мёллер, Эрик20 января 2024
  73. Сравнение языков разметки документов20 января 2024
  74. Старлинг, Анджела Бизли20 января 2024
  75. CommEX18 января 2024
  76. FamilySpace17 января 2024
  77. Familypedia17 января 2024
  78. Аурига (компания)16 января 2024
  79. Гогуль15 января 2024
  80. Simply Nailogical8 января 2024
  81. Windows Embedded Compact 20133 января 2024
  82. Яндекс.ТВ28 декабря 2023
  83. Atlas VPN3 декабря 2023
  84. Сажина, Елена Дмитриевна3 декабря 2023
  85. Okino.ua1 декабря 2023
  86. СЭД Канцлер1 декабря 2023
  87. Графика Python: модуль "turtle"24 ноября 2023
  88. Адаптивный робот3 ноября 2023
  89. Офисный пакет1 ноября 2023
  90. Umidigi C229 октября 2023
  91. Ким, Алина28 октября 2023
  92. Список самых популярных аккаунтов TikTok28 октября 2023
  93. Пензфильммаш14 октября 2023
  94. Р-ФОН25 сентября 2023
  95. Печатные символы15 сентября 2023
  96. HijackThis14 сентября 2023
  97. Код (фильм, 2001)31 августа 2023
  98. Кубок по образовательной робототехнике29 августа 2023
  99. Optic ID27 августа 2023
  100. C++268 августа 2023
  101. Порог догерти7 августа 2023
  102. Список десептиконов2 августа 2023
  103. Список закрытых Википедий2 августа 2023
  104. Madness Combat1 августа 2023
  105. Упаковка и распаковка значимых типов31 июля 2023
  106. Bocad-3D26 июля 2023
  107. Win95.Boza19 июля 2023
  108. ПроГород19 июля 2023
  109. Различие типа и токена19 июля 2023
  110. Ремонтное кафе17 июля 2023
  111. Direct Revenue16 июля 2023
  112. Коваленко, Святослав Владимирович7 июля 2023
  113. Phraser30 июня 2023
  114. Казахский голосовой алфавит для диктовки побуквенного написания23 июня 2023
  115. Орфограммка21 июня 2023
  116. Архитектура системы для энтузиастов20 июня 2023
  117. PreSonus FaderPort4 июня 2023
  118. Буфеев, Константин Валентинович4 июня 2023
  119. Гиперпараметр (машинное обучение)4 июня 2023
  120. Exile (блогер)3 июня 2023
  121. Монгрейн, Эрик27 мая 2023
  122. Кулаичев, Алексей Павлович20 мая 2023
  123. Василенко, Елизавета Вадимовна14 мая 2023
  124. Вычислительная среда14 мая 2023
  125. Чэнь Инхао25 апреля 2023
  126. Миллер, Брэндон18 апреля 2023
  127. OpenRC15 апреля 2023
  128. Syskey13 апреля 2023
  129. Aqua (интерфейс)4 апреля 2023
  130. Distributed.net3 апреля 2023
  131. CSI-DOS2 апреля 2023
  132. Галлюцинация (искусственный интеллект)23 марта 2023
  133. Shtab (программа)22 марта 2023
  134. Anacron14 марта 2023
  135. GPM (программное обеспечение)14 марта 2023
  136. Getty14 марта 2023
  137. Образовательное программное обеспечение12 марта 2023
  138. Дифференцируемое программирование10 марта 2023
  139. Структурированный тип8 марта 2023
  140. Movavi Picverse4 марта 2023
  141. Movavi Screen Recorder Studio4 марта 2023
  142. Movavi Video Editor4 марта 2023
  143. Movavi Video Suite4 марта 2023
  144. Movavi Видео Конвертер4 марта 2023
  145. Ранняя остановка27 февраля 2023
  146. MSConfig9 февраля 2023
  147. Андре Кронье7 февраля 2023
  148. GraphicsMagick31 января 2023
  149. Pivot Animator31 января 2023
  150. Омнинет25 января 2023
  151. Информационный работник13 января 2023
  152. HTML-цвета8 января 2023
  153. Просмотрщик30 декабря 2022
  154. Inspur K-UX27 декабря 2022
  155. Stylus (язык таблиц стилей)26 декабря 2022
  156. Лавренко, Виктор Сергеевич25 декабря 2022
  157. NASS19 декабря 2022
  158. ADVANTA15 декабря 2022
  159. Mylyn12 декабря 2022
  160. Патч22 ноября 2022
  161. Исполнение произвольного кода16 ноября 2022
  162. Битовая карта15 ноября 2022
  163. Таймер (информатика)15 ноября 2022
  164. Хащі6 ноября 2022
  165. Free Audio Editor5 ноября 2022
  166. Тушенцов, Руслан Сергеевич9 октября 2022
  167. Текстовый интерфейс пользователя8 октября 2022
  168. G.ho.st1 октября 2022
  169. 128 бит29 сентября 2022
  170. 256 бит29 сентября 2022
  171. 26 бит29 сентября 2022
  172. Mapul29 сентября 2022
  173. Дескриптор (программирование)27 сентября 2022
  174. Kid Security20 сентября 2022
  175. C-3615 сентября 2022
  176. Столяров, Алексей Викторович15 сентября 2022
  177. Это Минск, детка15 сентября 2022
  178. IVA MCU12 сентября 2022
  179. Bad command or file name3 сентября 2022
  180. Genesi27 августа 2022
  181. Catholic.by20 августа 2022
  182. Contact17 августа 2022
  183. Апротех11 августа 2022
  184. Православная архитектура Беларуси (сайт)8 августа 2022
  185. IdChess23 июля 2022
  186. O(n) scheduler10 июля 2022
  187. Windows 9x30 июня 2022
  188. Windows.h25 июня 2022
  189. Windows Live Events19 июня 2022
  190. D4X18 июня 2022
  191. Windows (клавиша)13 июня 2022
  192. Клавиша-модификатор13 июня 2022
  193. Клавиши управления курсором13 июня 2022
  194. AMOS (язык программирования)9 июня 2022
  195. MobileBASIC4 июня 2022
  196. Набор символов ZX Spectrum4 июня 2022
  197. Нестандартные шрифты4 июня 2022
  198. Музыкальное программирование2 июня 2022
  199. Предметная область2 июня 2022
  200. Распределённая система2 июня 2022
  201. Информационная система по грузоперевозкам1 июня 2022
  202. Конференц-система1 июня 2022
  203. Унифицированные коммуникации1 июня 2022
  204. Контакты Windows31 мая 2022
  205. Список файлов (Direct Connect)31 мая 2022
  206. Терминальный режим работы31 мая 2022
  207. Транспортное кодирование31 мая 2022
  208. Коллекция (Shareaza)30 мая 2022
  209. .jad29 мая 2022
  210. Ассоциация файлов29 мая 2022
  211. Двоичный файл29 мая 2022
  212. Развёртывание программного обеспечения29 мая 2022
  213. Текстовые данные29 мая 2022
  214. Текстовый файл28 мая 2022
  215. Текстовый видеорежим26 мая 2022
  216. ZipGenius25 мая 2022
  217. Zoo (формат файлов)25 мая 2022
  218. Установка программного обеспечения25 мая 2022
  219. Клавиатура (блок Юникода)19 мая 2022
  220. Майнинг-отель17 мая 2022
  221. Вебтоп11 мая 2022
  222. Видимая сеть11 мая 2022
  223. Кибероружие7 мая 2022
  224. По умолчанию7 мая 2022
  225. 0 марта6 мая 2022
  226. Апплет6 мая 2022
  227. Дистрибутив6 мая 2022
  228. Break (клавиша)4 мая 2022
  229. MilkyTracker4 мая 2022
  230. Док-станция4 мая 2022
  231. Мультимедийные клавиши4 мая 2022
  232. Раскладка клавиатуры дзонг-кэ4 мая 2022
  233. Local 583 мая 2022
  234. Специализированные ОС2 мая 2022
  235. Фоновая задача2 мая 2022
  236. Аптайм1 мая 2022
  237. Виртуальный прибор1 мая 2022
  238. Перезагрузка1 мая 2022
  239. Отравление торрент-файла30 апреля 2022
  240. Typeof29 апреля 2022
  241. .sys28 апреля 2022
  242. Графические форматы28 апреля 2022
  243. Сравнение форматов исполняемых файлов28 апреля 2022
  244. MiniCommander27 апреля 2022
  245. OpenTracker27 апреля 2022
  246. Tracker.NewFS27 апреля 2022
  247. Соединительная линия27 апреля 2022
  248. Жестовый интерфейс26 апреля 2022
  249. Алгоритм планирования по ближайшему сроку завершения25 апреля 2022
  250. Выключение вычислительной системы25 апреля 2022
  251. Вырезать, копировать, вставить25 апреля 2022
  252. Лаг (компьютерный сленг)24 апреля 2022
  253. Моделирование электронных схем24 апреля 2022
  254. Устройство ввода24 апреля 2022
  255. Янукс24 апреля 2022
  256. Высокопродуктивные компьютерные системы (программа)19 апреля 2022
  257. Даунгрейд19 апреля 2022
  258. Даунгрейд программного обеспечения19 апреля 2022
  259. Информационно-управляющая система19 апреля 2022
  260. Aku no musume18 апреля 2022
  261. Вертикальная синхронизация18 апреля 2022
  262. Безопасное извлечение устройства17 апреля 2022
  263. Самин, Михаил Иванович17 апреля 2022
  264. Тестирование безопасности17 апреля 2022
  265. Alt (клавиша)16 апреля 2022
  266. F-Lock16 апреля 2022
  267. Num Lock16 апреля 2022
  268. Print Screen16 апреля 2022
  269. Scroll Lock16 апреля 2022
  270. Абстракция (информатика)15 апреля 2022
  271. Автоматизация процесса программирования15 апреля 2022
  272. Gettr12 апреля 2022
  273. 3Q (компания)11 апреля 2022
  274. Peace Data11 апреля 2022
  275. ALT Linux (компания)9 апреля 2022
  276. ВС Школьный Линукс9 апреля 2022
  277. Набор символов9 апреля 2022
  278. Псевдографика9 апреля 2022
  279. Система отслеживания ошибок7 апреля 2022
  280. Basilisk (браузер)6 апреля 2022
  281. SureType5 апреля 2022
  282. Импорт и экспорт данных5 апреля 2022
  283. Машинописные работы5 апреля 2022
  284. Щелчок (нажатие клавиши)4 апреля 2022
  285. Жесты мышью3 апреля 2022
  286. Любая клавиша3 апреля 2022
  287. Список клавиатурных тренажёров3 апреля 2022
  288. Кардридер1 апреля 2022
  289. 16 бит31 марта 2022
  290. 31 бит31 марта 2022
  291. 32 бита31 марта 2022
  292. 36 бит31 марта 2022
  293. 45 бит31 марта 2022
  294. 60 бит31 марта 2022
  295. 64 бита31 марта 2022
  296. 8 бит (компьютерная архитектура)31 марта 2022
  297. Oakley протокол31 марта 2022
  298. Число восьмерной точности31 марта 2022
  299. Число двойной точности31 марта 2022
  300. Число одинарной точности31 марта 2022
  301. Число половинной точности31 марта 2022
  302. Число четверной точности31 марта 2022
  303. Устройство ввода-вывода30 марта 2022
  304. Устройство вывода30 марта 2022
  305. Широкоформатный принтер30 марта 2022
  306. Сравнение растровых графических редакторов28 марта 2022
  307. StudyFree26 марта 2022
  308. Ищи своих23 марта 2022
  309. Промышленная ЖК-панель22 марта 2022
  310. Appodeal20 марта 2022
  311. Ulteo9 марта 2022
  312. Пилотный проект по автоматическому и дистанционному судовождению25 февраля 2022
  313. OpenGL Extension Wrangler Library23 февраля 2022
  314. История версий Java EE23 февраля 2022
  315. История версий Java SE23 февраля 2022
  316. История версий iTunes23 февраля 2022
  317. Сравнение устройств с Symbian21 февраля 2022
  318. Фрагментация платформы21 февраля 2022
  319. Nokia Store20 февраля 2022
  320. P2K20 февраля 2022
  321. Курирование контента20 февраля 2022
  322. Эмулятор сервера20 февраля 2022
  323. Gupta Technologies19 февраля 2022
  324. Проектные сети18 февраля 2022
  325. Тактильный интерфейс18 февраля 2022
  326. Jack PC14 февраля 2022
  327. Домашний сервер14 февраля 2022
  328. FileHippo13 февраля 2022
  329. WINE@Etersoft13 февраля 2022
  330. Пространственный модулятор света11 февраля 2022
  331. Accelerated Processing Unit10 февраля 2022
  332. Аппаратная платформа компьютера10 февраля 2022
  333. Слоткет10 февраля 2022
  334. Климова, Екатерина Владимировна6 февраля 2022
  335. RCSED4 февраля 2022
  336. Клэйтроника3 февраля 2022
  337. Picotux2 февраля 2022
  338. WorldWise31 января 2022
  339. Системная консоль27 января 2022
  340. Google Опросы16 января 2022
  341. Программно-аппаратный комплекс DATAPK14 января 2022
  342. АйТиБорода12 января 2022
  343. Multipoint Control Unit10 января 2022
  344. KChart1 января 2022
  345. KFormula1 января 2022
  346. Kdf1 января 2022
  347. Kview1 января 2022
  348. Reindexer1 января 2022
  349. Jove22 декабря 2021
  350. Бабешкин, Вадим22 декабря 2021
  351. Белова, Мария22 декабря 2021
  352. Гордей, Дмитрий Михайлович22 декабря 2021
  353. Мингалимова, Татьяна Ильдаровна22 декабря 2021
  354. Шпагина, Анастасия22 декабря 2021
  355. Трейсер, Сергей11 декабря 2021
  356. Поиск подстроки5 декабря 2021
  357. .日本2 декабря 2021
  358. Matchless Raijin-Oh1 декабря 2021
  359. Щелевая решётка20 ноября 2021
  360. БЭСТ (программы)17 ноября 2021
  361. Flussonic Media Server10 ноября 2021
  362. Беру (маркетплейс)9 ноября 2021
  363. Кшиштовский, Михаил Александрович8 октября 2021
  364. Gozle25 сентября 2021
  365. Secure Token6 сентября 2021
  366. TechnologiCS26 августа 2021
  367. BartPE17 августа 2021
  368. APPIUS10 августа 2021
  369. Система управления конференцией8 августа 2021
  370. Оптический поток7 августа 2021
  371. Полная виртуализация4 августа 2021
  372. Автоматизация ресторанов1 августа 2021
  373. Программная закладка1 августа 2021
  374. Randonautica27 июля 2021
  375. Метод синтаксических шаблонов23 июля 2021
  376. Embarcadero RAD Studio21 июля 2021
  377. Медиасервер21 июля 2021
  378. Ppi9 июля 2021
  379. Zaurus1 июля 2021
  380. НаПоправку1 июля 2021
  381. Таблица фактов1 июля 2021
  382. Microsoft GIF Animator25 июня 2021
  383. Nexus Player24 июня 2021
  384. Ангара (суперкомпьютер)19 июня 2021
  385. Защита от несанкционированного копирования12 июня 2021
  386. Сравнение Microsoft Windows NT и Linux31 мая 2021
  387. Сравнение браузерных движков31 мая 2021
  388. Сравнение виртуальных машин31 мая 2021
  389. Сравнение медиаконтейнеров31 мая 2021
  390. Сравнение операционных систем на основе System V31 мая 2021
  391. Сравнение операционных систем семейства BSD31 мая 2021
  392. Сравнение панелей управления веб-хостингом31 мая 2021
  393. Сравнение файловых систем31 мая 2021
  394. KPercentage20 мая 2021
  395. POSTQUEL19 мая 2021
  396. Fc (Unix)4 мая 2021
  397. MicroSIP19 апреля 2021
  398. Boosteroid14 апреля 2021
  399. Линкбилдинг7 апреля 2021
  400. Цифровая юриспруденция7 апреля 2021
  401. WikiPilipinas21 марта 2021
  402. Архитектура системы базы данных18 марта 2021
  403. Программное обеспечение DewesoftX15 марта 2021
  404. FinalRender10 марта 2021
  405. Карта москвича7 марта 2021
  406. Машинный перевод на основе правил21 февраля 2021
  407. Саундвейв17 февраля 2021
  408. Скандалист (трансформер)17 февраля 2021
  409. Список нотных редакторов11 февраля 2021
  410. Омар в большом городе19 декабря 2020
  411. Code Aster29 ноября 2020
  412. Aviata24 ноября 2020
  413. PowerDirector11 ноября 2020
  414. Познаватель12 октября 2020
  415. Разработка программного обеспечения8 октября 2020
  416. Движок13 сентября 2020
  417. 8.38 сентября 2020
  418. START-PROF5 сентября 2020
  419. Электролюминесцентный дисплей25 августа 2020
  420. Прогноз.ССВ16 августа 2020
  421. Купюроприёмник31 июля 2020
  422. Бабияк, Вячеслав Вячеславович15 июля 2020
  423. Поисковый спам12 июля 2020
  424. Autospot16 июня 2020
  425. Genesis Mining14 июня 2020
  426. Кассетные роботы4 июня 2020
  427. Джетфайер12 мая 2020
  428. Код стука24 апреля 2020
  429. Белоногов, Герольд Георгиевич20 апреля 2020
  430. Обходной приём19 апреля 2020
  431. Барвина11 апреля 2020
  432. Иоффе, Анатолий Фёдорович10 апреля 2020
  433. РЕД ОС30 марта 2020
  434. Технокоммунизм30 марта 2020
  435. Escobar Fold 112 марта 2020
  436. Rock Musicians Map5 марта 2020
  437. Гештальт (трансформер)18 февраля 2020
  438. Гаджет и Гаджетины21 января 2020
  439. Родимус Прайм12 января 2020
  440. Исаев, Игорь Игоревич5 октября 2019
  441. Strikeplagiarism.com10 сентября 2019

Оригинал интервью, слова интервьюируемого. Кто придумал 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)[ответить]
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)[ответить]
  • Профильная нам (куда уж боле) статья из ПРО:1000. Раньше там объём бог знает чем догонялся, я написал более-менее приличную заготовку исторического раздела (так-то тема сама по себе тянет на отдельную ВП:ИС), в общем приглашаю если не к доработке, то к написанию переводу статей по красным ссылкам, что-то там их многовато --be-nt-all 14:25, 6 февраля 2016 (UTC)[ответить]

Релевантность

Есть статья в основном пространстве Релевантность и статья в Инкубаторе Инкубатор:Релевантность. Как лучше поступить? Учитывая претензии к статье в основном пространстве, может быть, просто заменить её статьёй из Инкубатора, где материала намного больше? Прошу помочь, кто хорошо разбирается в этой теме. Участник конструктивный, пытаюсь ему помочь в написании и правильном оформлении статей. Первой была статья из Инкубатора Индивидуальный бренд. Заранее спасибо. Oleg3280 20:43, 2 февраля 2016 (UTC)[ответить]

Последняя версия в шаблонах-карточках ПО

Предлагаю убрать параметры шаблонов-карточек программного обеспечения: последняя версия, дата последней версии. Эту информацию всегда можно найти на официальном сайте ПО, и размещённая на странице она быстро становится неактуальной. В результате мы имеем очень много правок просто изменяющие эти данные. Для примера правка: [2] --V0d01ey 20:36, 23 января 2016 (UTC)[ответить]

(−) Против. Лучше наличие неактуальной информации, чем её отсутствие. Версию программы всегда можно исправить. В некоторых статьях подобные данные находятся на Викиданных, где они могут использоваться во всех проектах Фонда, но не всегда оперативно и правильно обновляются. Если подобные правки делаются, значит это кому-то нужно. Oleg3280 21:10, 24 января 2016 (UTC)[ответить]
Таких незначительных правок действительно много. У идеи удалить совсем мало шансов т.к. будут возвращать или вносить другим образом, ведь "это есть в других вики". Можно было бы попробовать посылать добавлять в Викиданные, но там есть только текущая версия и нет чем заполнить два параметра тестовых версий. Можно ведь делать как в enwiki - через en:Template:LPR. --Сунприат 17:24, 25 января 2016 (UTC)[ответить]
  • Аргумент "есть в других вики" из рода стадного чувства. Нужно приводить более существенные аргументы. Не примите на личный счет. --V0d01ey 20:06, 25 января 2016 (UTC)[ответить]
  • В номере последней версии я никогда смысла не видел, а вот дата показывает хотя бы примерное состояние актуальности проекта. Если с последней версии прошло лет 10, то он явно не поддерживается. Arachnelis 19:00, 25 января 2016 (UTC)[ответить]
  • Поле "статус" вроде тоже есть, но тут кому как удобнее воспринимать. В принципе, не настаиваю, но лично мне хотелось бы видеть дату первой (вот её сейчас нету) и дату последней актуальной. Примерно как в карточках музыкантов есть годы активности. Arachnelis 17:07, 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)[ответить]
  • Ну у вас-то взгляд критический :-). Но даже если и так, ни историческая часть, ни к, примеру, синтаксическая, радикального переписывания уж точно не требуют. И в любом случае предлагать новичку, что называется, для начала, переписать статью на такую тему, это как то… жестоко. --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)[ответить]

вы в сервисах гугл не написали про сервер 211 тоисть google TrashDeep — Эта реплика добавлена с IP 178.137.214.240 (о)

К сожалению, не знаю всех тонкостей метапедийного процесса, но было бы интересно разработать минимальные требования к мобильным устройствам. (см. также обсуждение Википедия:Форум/Вниманию участников#Чего народ ждёт от статей по (старым) телефонам?) РоманСузи 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)[ответить]
  • Забыл сказать, что это пока предварительное обсуждение, чтобы потом менее сырое предложение выставить на ВП:Ф-ПРА. Так что прошу критиковать жёстко, если есть уверенность в консенсусе, править напрямую — добавления, убавления, изменения — (и если правка логически важная — написать здесь). РоманСузи 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)[ответить]

В связи с большим дополнением к статьям проекта, глянул сегодня на статистику и создалось впечатление, что критерии, по которым статьи относятся к различным степеням важности, непонятны. Например, в высшей важности фигурирует из персоналий только Хоппер, Грейс (спасибо, раньше о ней совсем не знал, расширил кругозор, просто богиня ИТ). Из структур данных только стек и кэш суперважны и т. д. К сожалению, не нашёл «нормативной базы» для этой классификации. А поле деятельности большое: Категория:Статьи проекта Информационные технологии неизвестного уровня неизвестной важности (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)[ответить]
  • Разделить — разделю (в ходе работы большой разницы не заметил). Сейчас я разбросал из Неизв. колонки и дополнил критерии. За редкими исключениями, чем точнее категория, тем ниже важность. Правда, система категорий просто ужас в Википедии, поэтому, может быть, и не получится. А так, если выделить костяк (это не сложно), которому назначить от высшей до средней, остальное в низкую важность (очень редко что вообще выкинул — только принцип Оккама). С ЯП все просто — есть TIOBE, по нему и разнёс. (только Паскаль и Бейсик думаю тоже к высокой важности нужно будет отнести). РоманСузи 19:54, 29 декабря 2015 (UTC)[ответить]
  • Разгрёб статьи до уровня 3 включительно, притянул ДС и ХС ИТ тематики (для улучшения статистика ;-). Дополнил критерии важности примерами и приблизительными руководящими принципами. РоманСузи 14:12, 30 декабря 2015 (UTC)[ответить]
    Спасибо Важность можно ещё из проекта англовики взять. Там над большой частью уже проделана работа по оценке. Их высокорейтинговые должны быть и здесь с таким же рейтингом или хотя бы с пустым (неизв.) шаблоном. --Сунприат 14:25, 30 декабря 2015 (UTC)[ответить]
    У них в топе немного по-своему, например, Fortinet. Так что совсем один к одному не получится. РоманСузи 14:51, 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)[ответить]

Наверно, Архитектура фон Неймана сверхважная, или нет? Д.Ильин 21:59, 1 января 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)[ответить]
  • Лично меня бы не задело, но про новичков трудно сказать. Вот я пришёл, написал статью, приходит кто-то другой, ставит важность=низкая. С одной стороны, мою статью заметили, с другой стороны, посчитали маловажной. Можно, наверно, вначале просто ставить плашку с незаполненным параметром (может быть даже независимо от важности - т.е. от низкой до высшей), хотя и говорят, что надо сразу заполнять. Спустя какое-то время (пара недель - месяц) периодически проходить по неоценённым статьям и оценивать, или оценивать вместе с другими правками в обсуждении. — Stannic(обс)(вкл)(выкл) 07:58, 2 января 2016 (UTC)[ответить]
    • Давайте добавим, что для сравнительно «молодых» статей, для которых важность не выше низкой, ставить плашку с пустыми важностью и уровнем (кто знает, может автор в течение года допишет). Низкий предлагаю массово не ставить. Не вижу в нём дополнительной информации по сравнению с неизвестным, а труда по проставлению много. Думаю, что опытным участникам хоть на КУ выставляй — ко всему привыкли, а редакторов-новичков лучше поначалу ограждать. Если не будет возражений, можно добавить примечанием к оценкам. РоманСузи 09:41, 2 января 2016 (UTC) Другой свежий пример в процессе: Обсуждение:ALOHAnet, где не поставил пока что ни важности, ни уровня (статья в процессе доработки до ДС — зачем дёргаться раньше времени) РоманСузи 09:50, 2 января 2016 (UTC)[ответить]
      • Тогда обидятся новички, которые как-то узнают, что не проставлено = низкая важность :) Вариант — какое-то время после создания статьи вовсе никакие уровни не ставить, хоть она важная, хоть нет. Но пусть другие участники выскажутся — Stannic(обс)(вкл)(выкл) 10:09, 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)[ответить]

Ещё из той же серии 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)[ответить]
Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.
        • (Пока не уверен с консенсусом о переносе, хотя уже много чего до нас перенесли). Но технически наверное стоит оставлять некий комментарий, чтобы Реализации и не добавляли в статью? Или во всяком случае не на 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)[ответить]
    В основном обсуждение не пошло, не восприняли всерьёз. Кое-где [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)[ответить]
    В англоВикиучебнике на 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)[ответить]

Найденные обсуждения

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)[ответить]