Симонов Сергей : другие произведения.

Комментарии: Программирование
 ()

Самиздат: [Регистрация] [Найти] [Рейтинги] [Обсуждения] [Новинки] [Обзоры] [Помощь|Техвопросы]
  • © Copyright Симонов Сергей (gann.lector@yandex.ru)
  • Размещен: 20/03/2017, изменен: 20/03/2017. 0k. Статистика.
  • Интервью: Фантастика
  • Аннотация:
    Тема для обсуждения всего, связанного с программированием и софтом. Для "железа" будет скоро восстановлена тема "Электроника, ЭВМ, железо".
    		• ОБСУЖДЕНИЯ: Фантастика (последние)
    09:37 Орлов Д.Е. "Маленький Саша. Прода. 96" (248/1)
    09:34 Кротов С.В. "Чаганов: Война. Часть 4" (185/16)
    09:20 Чернов К.Н. "Записки Империалиста Книга " (588/17)
    09:12 Безбашенный "Запорожье - 1" (970/13)
    Добавить комментарий Отсортировано по:[убыванию][возрастанию]
    Страниц (10): 1 2 3 4 5 6 7 8 9 10 Архивы (1): 1
    ОБЩИЕ ГОСТЕВЫЕ:
    09:01 "Технические вопросы "Самиздата"" (172/35)
    09:00 "Форум: все за 12 часов" (248/101)
    08:12 "Форум: Трибуна люду" (850/21)
    19:02 "Диалоги о Творчестве" (207/1)
    15/11 "Форум: Литературные объявления" (664)
    25/11 "О блокировании "Самиздата"" (294)
    ОБСУЖДАЕМ: Симонов С.
    07:55 "Сельское хозяйство" (623/1)
    04:12 "Электронная периферия, связь, " (183/1)
    04:08 "Автомобили, мотоциклы автомотохотелки," (92/1)
    04:07 "Общественный транспорт, градостроительство" (228/1)
    21/11 "Коммунизм, сталинизм, троцкизм, " (961)
    18/11 "Контейнеры и грузоперевозки, " (927)
    17/11 "Новые технологии в промышленности" (624)
    16/11 "Центральный флуд" (827)
    12/11 "Вооружённые силы и техника" (970)
    06/11 "Атомная промышленность, энергетика, " (851)
    03/11 "Флот. Морские системы вооружений" (788)
    02/11 "Проект советской космической " (960)
    02/11 "Создание правильного образа " (557)
    30/10 "Огас и Плановая экономика" (393)
    30/10 "Медицина, биология" (1007)
    26/10 "Законодательство, правоприменительная " (584)
    24/10 "Гражданская авиация" (1004)
    19/10 "Вертолёты" (820)
    14/10 "Робототехника, сложная бытовая " (279)
    13/10 "Наука и образование как ключ " (266)
    10/10 "День хризантем" (33)
    10/10 "Военная авиация" (715)
    06/10 "Химия и материалы" (347)
    04/10 "Строительство и быстровозводимые " (739)
    22/09 "Цвет сверхдержавы - красный " (527)
    13/09 "Демография и сопутствующее" (849)
    29/08 "Цвет сверхдержавы - красный " (500)
    18/08 "Цвет сверхдержавы - красный " (551)
    16/07 "Кино" (108)
    12/07 "Пво, Про, Зрк, Урвв" (1006)
    07/06 "Жизнь бесценна" (41)
    07/06 "Орион. Возможности, проблемы " (986)
    28/05 "Музыка" (577)
    25/05 "Цвет сверхдержавы - красный " (446)
    09/05 "Телевидение, фототехника, " (466)
    20/04 "Цвет сверхдержавы - красный " (234)
    19/04 "Предложения по палубной авиации " (988)
    20/02 "Дружба миров" (48)
    13/02 "Культура" (990)
    31/01 "Программирование" (361)
    25/01 "Теории заговора" (130)
    09/01 "Геология и горная промышленность" (484)
    06/01 "Четвёртый Интернационал" (44)
    26/06 "Цвет сверхдержавы - красный " (21)
    05/05 "Low Orbital Ion Cannon" (46)
    05/05 "Спираль истории Книга 1" (44)
    23/04 "Система Енонла" (11)
    21/04 "Невоенное противостояние с " (480)
    21/03 "Председатель Галактики" (111)
    20/11 "Актуальная тема - Международное " (963)
    07/11 "Цвет сверхдержавы - красный " (78)
    04/09 "Металлургия" (236)
    14/05 "Время, континуум, и параллельные " (415)
    16/03 "Цвет сверхдержавы - красный " (983)
    23/02 "Разведка и контрразведка" (605)
    22/01 "Экранопланы" (200)
    13/07 "Нетехнические фанфики" (123)
    09/07 "О магии стихий, рыжем кошаке " (96)
    24/10 "Проект конституции Аи-Ссср" (116)
    29/05 "Выставки 1959 года" (438)
    16/10 "Спираль истории Книга 2" (30)
    20/12 "Цвет сверхдержавы - красный " (30)
    ОБСУЖДЕНИЯ: (все обсуждения) (последние)
    09:37 Чваков Д. "Поэту позавчерашней молодости" (4/3)
    09:37 Орлов Д.Е. "Маленький Саша. Прода. 96" (248/1)
    09:36 Егорыч "Ник Максима" (6/5)
    09:34 Бурель Л.Л. "В королевы я б пошла" (4/3)
    09:34 Кротов С.В. "Чаганов: Война. Часть 4" (185/16)
    09:25 Березина Е.Л. "Как-то юнга Дудочкин бросил " (4/3)
    09:24 Никитин В. "Обращение к читателям" (2/1)
    09:22 Никитин А.Д. "Единство Которое все ждут" (1)
    09:21 Чернов К.Н. "Армия, флот, вооружение (Записки)" (338/4)
    09:19 Берг D.Н. "Мы из Кронштадта, подотдел " (583/1)
    09:15 Юрьев О. "Когда будет 3-я или 4-я мировая " (1)
    09:15 Нейтак А.М. "В порядке похихи" (263/8)
    09:13 Ролько Т., Юрцва "Трансформации электрона и " (298)
    09:12 Русова М. "Утро" (2/1)
    09:12 Давыдов С.А. "Флудилка Универсальная" (584/3)
    09:12 Безбашенный "Запорожье - 1" (970/13)
    09:09 Уралов А. "Мясо "из пробирки"" (612/4)
    09:08 Карелин Р.Ф. "Законы истории не ведут к " (1)
    09:01 Самиздат "Технические вопросы "Самиздата"" (172/35)
    09:00 Осипцов В.T. "Реинкарнация, Часть 3 - "Полководцы" " (1)

    РУЛЕТКА:
    Путь Шамана. Шаг
    Ночлежка "У Крокодила"
    В родном краю
    Рекомендует Пузеп Н.В.

    ВСЕГО В ЖУРНАЛЕ:
     Авторов: 108551
     Произведений: 1670555

    Список известности России

    СМ. ТАКЖЕ:
    Заграница.lib.ru     | Интервью СИ
    Музыка.lib.ru | Туризм.lib.ru
    Художники | Звезды Самиздата
    ArtOfWar | Okopka.ru
    Фильм про "Самиздат"
    Уровень Шума:
    Интервью про "Самиздат"

    НАШИ КОНКУРСЫ:
    Рождественский детектив-24


    24/11 ПОЗДРАВЛЯЕМ:
     Белашова Ю.Ю.
     Белль С.В.
     Богатикова О.Ю.
     Богданов А.
     Бонд. П.Б.
     Бредникова Е.Е.
     Букаринов Д.Н.
     Веденин В.А.
     Ветер К.
     Визмор Э.Н.
     Виноградова А.В.
     Галицкая Д.И.
     Гамова Д.
     Гончарова Е.В.
     Егорова В.Ю.
     Ежова Е.С.
     Елисеева Н.В.
     Ельников А.Д.
     Жалилова Л.С.
     Желнов П.
     Иванов А.А.
     Инеева С.
     Ищенко Г.В.
     Казарян М.В.
     Келлер Е.
     Кизяева А.А.
     Кичилова К.Ф.
     Колодиец Д.Н.
     Кольцо-Гид
     Команов С.С.
     Кондрашов В.А.
     Копышов А.Н.
     Корнеева Т.М.
     Коршунова Т.В.
     Ксения
     Лобков А.
     Луковкин К.
     Лучистая Д.Т.
     Макарчук С.С.
     Маковская Н.
     Маркевич П.
     Митусова Л.П.
     Можар Е.П.
     Морозов М.
     Пашкевич С.
     Пимонов В.В.
     Пирумова А.Б.
     Приходько О.
     Пятница М.
     Радонин С.
     Ревельский Х.
     Романов Н.П.
     Рябенкова Д.П.
     Серебряная Е.
     Силаков Г.
     Соколовская Е.
     Солнечная
     Соцкая С.
     Сперанская И.В.
     Таа
     Трещев Ю.А.
     Тягин П.А.
     Шаповалова Д.В.
     Шеннон Р.А.
     Шишкина Д.
     Щедрин Р.
     Ak108u
     Ive
     Mollydolly
     Natkam
     Valxalla
     Viligodaeum
     Viscount M.D.
    ПОСЛЕДНИЕ ПОСТУПЛЕНИЯ: (7day) (30day) (Рассылка)
    00:39 Патрацкая Н.В. "Маг Грановский"
    21/11 Кукин В. "Случайные рифмы"
    21/11 Моисеева О.Ю. "Сердце Кометы"
    191. Antonov Andy (andy.antonov@gmail.com) 2021/03/04 23:21 [ответить]
      > > 189.Хм
      >> > 187.Antonov Andy
      >>Ну, к виндовс эксплореру одна претензия - принципиальное отсутствие двух панелей
      > Хороший дизайн интерфейса предполагает использование и написание юзером аддонов и плагинов на DSL языке (предметно-ориентированный язык)
      А чем Вам тот же Free Commander - не адд-он?
      
      > Например, обычный калькулятор при всём совершенстве UX-дизайна не отвечает потребностям - потому что в нём не предполагается использование DSL языка, который был бы удобен для пользователя.
      Я себе поставил эмуль МК-61 в телефон. Он вполне отвечает моим потребностям.
      ЗЫ Калькулятор венды в режиме "инженерный" и с учётом хоткеев (а их там очень даже есть) - тоже вполне юзабелен.
      
      > Как очевидно, в лучшем случае могут дать только дизайн калькулятора и это в лучшем случае.
      Очень много шипка вумных слов ниачом. Переведите с русского высокопарного на русский обнакновенный...
    190. Хм 2021/03/04 23:27 [ответить]
      Всё же хороший вопрос, какой "контент" может создавать юзер с помощью DSL языка.
       Например, как юзер может расширять функционал калькулятора и значит настраивать интерфейс.
      
       Как очевидно, плагин по работе с графикой (черчение графиков), в частности экспорт и импорт картинок это всё во многом про иерархию функций. А сама программа это всего лишь оболочка.
       То есть пользователь создаёт скрипты в интуитивно-понятной среде (каналы и перенаправления).
      
       ***
      
       Вообщем подход философии (!) Unix имеет преимущества, но никто не будет в это вкладывать деньги. Как мы знаем, мододелы сейчас приравнены к пиратам. Как пример, реверс-инженеринг ГТА-3 мододелами.
    189. Хм 2021/03/04 23:19 [ответить]
      > > 187.Antonov Andy
      UX-дизайн - это проектирование интерфейса на основе исследований пользовательского опыта и поведения.
      >> То есть в современном мире важно учитывать ещё и это, а не количество сданных строк кода ради зарплаты.
      >За это не платят.
      
       Очень многие кодеры бравируют, насколько глупо писать Гуру комментарии к своему коду. В переводе на русский это означает:
      
      1. На вопрос КАК должен отвечать компилятор (перевод исходного кода в целевой)
      2. На вопрос ЧТО:
       Сопровожде́ние (поддержка) программного обеспечения - процесс улучшения, оптимизации и устранения дефектов программного обеспечения (ПО) после передачи в эксплуатацию.
       И значит блок-схему не должен создавать этот Гуру.
      3. На вопрос ЗАЧЕМ - не нужно задумываться об архитектуре, ведь UX-дизайн не важен, как и не важна юзабельность продукта.
      
      >Ну, к виндовс эксплореру одна претензия - принципиальное отсутствие двух панелей
      
       Хороший дизайн интерфейса предполагает использование и написание юзером аддонов и плагинов на DSL языке (предметно-ориентированный язык)
       Например, обычный калькулятор при всём совершенстве UX-дизайна не отвечает потребностям - потому что в нём не предполагается использование DSL языка, который был бы удобен для пользователя.
      
       Как очевидно, в лучшем случае могут дать только дизайн калькулятора и это в лучшем случае.
      
      > > 188.Талипов Артём
      >> При этом сейчас ценится интуитивно-понятный интерфейс, а не стиль Windows когда большая часть API (и пользовательского интерфейса) являются недокументируемыми и не интуитивно-понятными.
      >Ой, да ладно? Почти всё там понятно и задокументировано. Это просто кто-то ту самую документацию поленился открывать.
      
       Документация это ответ на вопрос ЗАЧЕМ. То есть как устроена архитектура. В частности это нужно для DSL языка - создание пользовательских аддонов и плагинов.
      
       Например, чтобы калькулятор был настроен под конкретного юзера.
      
      >Я вот ходил как-то искал програмку для напоминаний. Десяток перепробовал. И все мне чем-то не нравились. То функции глючные. То интерфейс кривой.
      
       Как это решается, выше написал.
      
      >программисты, особенно в корпорациях, близко не подпускаются, к дизайну.
      >Возможно и правильно, ибо лично я такое бы надизайнил, что чертям стало бы тошно.
      
       Имхо глупо рассчитывать, что для программы калькулятор кто-то будет создавать идеальный интерфейс и функционал на основе DSL языка.
    188. *Талипов Артём (eric50@yandex.ru) 2021/03/04 22:57 [ответить]
      > > 186.Хм
      > Всё относительно.
      
      
      Согласен.
      
      > Например, можно пользоваться встроенным проводником от Windows, а можно специально (!) предназначенным для этого файловым менеджером.
      
      Я пользуюсь файловым менеджером. Но это, думаю, привычка, вот как начал с nc (norton commander) так и не хочу менять привычек.
      Но от explorer тоже не отказываюсь, им вполне можно пользоваться для различных задачь.
      
      > При этом сейчас ценится интуитивно-понятный интерфейс, а не стиль Windows когда большая часть API (и пользовательского интерфейса) являются недокументируемыми и не интуитивно-понятными.
      
      Ой, да ладно? Почти всё там понятно и задокументировано. Это просто кто-то ту самую документацию поленился открывать.
      
      > Это не проблема пользователя, а проблема интуитивно-понятного интерфейса.
      
      Отчасти, где-то так. Но именно отчасти. Есть документация. Есть сам интерфейс, который нужно методично изучить.
      
      Я вот ходил как-то искал програмку для напоминаний. Десяток перепробовал. И все мне чем-то не нравились. То функции глючные. То интерфейс кривой.
      Всё закончилось тем, что я востановил приложение от производителя, которое было предустановлено на мой смартфон. После покупки, счёл его ненужным, удалил и забыл.
      А оно мне идеально подошло, ничего лишнего, а всё что нужно есть в наличии.
      Тот самый случай, когда сам себе злобный буратино.
      
      > То есть в современном мире важно учитывать ещё и это, а не количество сданных строк кода ради зарплаты.
      
      Дизайном занимаются дизайнеры, психологи и ещё много других специалистов.
      А программисты, особенно в корпорациях, близко не подпускаются, к дизайну.
      Возможно и правильно, ибо лично я такое бы надизайнил, что чертям стало бы тошно.
    187. Antonov Andy (andy.antonov@gmail.com) 2021/03/04 22:50 [ответить]
      > > 186.Хм
      >> > 183.Талипов Артём
      >>Я угараю с многих пользователей. Сидят, жалуются, что нет каких-то функций. Ставят дополнительные платные приложения, чтобы получить те функции, которые у них уже есть из коробки, но пользователи их не нашли или даже не знали об их существовании.
      > Всё относительно.
      Очень.
      
      > Например, можно пользоваться встроенным проводником от Windows, а можно специально (!) предназначенным для этого файловым менеджером.
      > При этом сейчас ценится интуитивно-понятный интерфейс, а не стиль Windows когда большая часть API (и пользовательского интерфейса) являются недокументируемыми и не интуитивно-понятными.
      Ну, к виндовс эксплореру одна претензия - принципиальное отсутствие двух панелей (что суксь с появления NC в лохматом году). Тот же Free Commander, по умолчанию использующий API Windows, вполне юзабелен, например.
      А с документированностью, на самом деле, беда отнюдь не только у венды.
      
      >>Типичный цирк, когда пользователи смартфона, не могут найти кнопку включения и выключения фанарика, ставят стороннее приложение фанарика с рекламой.
      > Это не проблема пользователя, а проблема интуитивно-понятного интерфейса.
      Это:
      1. Проблема документации. Она в подавляющем большинстве случаев весьма фрагментарна. Даже если она полна, её полнота одностороння, как флюс: есть только "эта функция делает то-то", но пользователю гораздо важнее "мне нужно то-то, как это сделать". При кажущемся сходстве вопросов, между ними - концептуальная пропасть.
      2. Проблема структуры/удобства меню. Чётко следует из п.1. Например, некоторые функции в Libre Office упрятаны так хорошо, что их невозможно найти. Даже со справкой (см. п.1 же). Отдельный прикол - распихивание функций по разделам меню. Когда "Разделить/фиксировать" лист 25 лет привык искать в меню "Окно", искать его в меню "Вид" - не по-детски рвёт шаблон (7-я Либра отожгла). Это скромненький такой пример, что юзверги - весьма консервативные твари, и за привычный интерфейс - могут и ногами побить! Ога, смотрим на количество сторонних приблуд для M$O 2007, возвращающих интерфейс в привычному виду, а не уродским лентам. Ещё приколов: применение шаблонов в Ворде/Райтере. В Ворде их использование интуитивно понятно, в ООо/Либре/апач райтере - ну, мягко говоря...
      3. Проблема обучаемости юзвергов. Over 95% юзвергов хотят, чтобы в программе была всего одна кнопка - "Сделайте мне волшебно!" Их мнение важно. И было учтено - в большинстве программ поисчезали любые настройки, которые были ранее. Правда, чуда не произошло, но это совсем другая история...
      
      > То есть в современном мире важно учитывать ещё и это, а не количество сданных строк кода ради зарплаты.
      За это не платят. И, да, абсолютным наплевательством на мнение пользователя страдает и свободный софт тоже. Сравните, например, M$O и Libre/OOo/Apache. Некоторые вещи принципиально можно сделать только в M$O. Иногда эти вещи - критически важны.
    186. Хм 2021/03/04 21:51 [ответить]
      > > 183.Талипов Артём
      >Я угараю с многих пользователей. Сидят, жалуются, что нет каких-то функций. Ставят дополнительные платные приложения, чтобы получить те функции, которые у них уже есть из коробки, но пользователи их не нашли или даже не знали об их существовании.
      
       Всё относительно.
       Например, можно пользоваться встроенным проводником от Windows, а можно специально (!) предназначенным для этого файловым менеджером.
       При этом сейчас ценится интуитивно-понятный интерфейс, а не стиль Windows когда большая часть API (и пользовательского интерфейса) являются недокументируемыми и не интуитивно-понятными.
      
      >Типичный цирк, когда пользователи смартфона, не могут найти кнопку включения и выключения фанарика, ставят стороннее приложение фанарика с рекламой.
      
       Это не проблема пользователя, а проблема интуитивно-понятного интерфейса.
      
      UX-дизайн - это проектирование интерфейса на основе исследований пользовательского опыта и поведения.
       Первый Macintosh - один из ярких примеров работы UX-дизайнеров. Идея использовать окна вместо командной строки существовала и до 1984 года, но именно проектировщики Apple сделали графический интерфейс массово доступным.
      
       То есть в современном мире важно учитывать ещё и это, а не количество сданных строк кода ради зарплаты.
    185. Хм 2021/03/04 13:43 [ответить]
      Жизненный цикл системы - это стадии процесса, охватывающие различные состояния системы, начиная с момента возникновения необходимости в такой системе и заканчивая её полным выводом из эксплуатации
      
      
      > > 184.Талипов Артём
      >> То есть бот от разработчика не имеет смысла.
      >> Обычно функция у менеджера чтобы продукт просто присутствовал на рынке.
      >Если что, то я писал о функции в продукте.
      
       А я про то, что грамотный менеджер прекрасно понимает насколько вредны хотелки студента-кодера по внедрению разных фич... а вдруг в энтерпрайзе понадобится эта фича.
      
       Например, на хабре регулярно пишут почему серверная логика в играх регулярно оказывается на "клиенте". Просто всё стоит денег.
      
      >>Бустинг аккаунта.
      >А в чём собственно проблема?
      >Пользователя можно идентифицировать, явным образом, например по номеру телефона, электронной почте, отпечатку пальца, фотографии лица, адресу компьютера и другим признакам.
      >В чате по голосу и стилю сообщений. Даже по манере игры, клавишам, жестам, интересам и прочим особенностям.
      >Это не делают, потому, что в этом нет проблемы.
      
       Просто всё это стоит денег. При этом компетенций студента-кодера не хватит чтобы всё это реализовать во время жизненного цикла продукта (около 6 месяцев).
      
      >>Создание пиратских серверов
      >Пиратский сервер можно создать, только если утекли исходные коды сервера.
      
       А может быть и другая ситуация.
      
      1. Делается реверс-инженеринг зашифрованного сетевого протокола игры.
      2. После с нуля создаётся кастомный клиент
      3. Если этого мало создаются пиратские сервера.
      
       При этом те кто этим занимаются прекрасно знают как работают юристы, чтобы заблокировать пиратские сервера.
       Вообщем забавны представления почему жизненный цикл продукта... это что-то не нужное.
    184. *Талипов Артём (eric50@yandex.ru) 2021/03/04 03:03 [ответить]
      > > 181.Хм
      > Всё несколько сложнее.
      
      Я писал о принципиальной проблеме. Или мой коммент никто не читал?
      
      Чтобы игра хоть как-то продавалась, человеку нужно дать шанс выйграть. А если компьютер будет гарантированно уделывать игрока, то такая игра не принесёт прибыли.
      
      >1. Создание пиратских серверов
      
      Пиратский сервер можно создать, только если утекли исходные коды сервера.
      Да и вообще это не проблема. Выложить всё в opensource и пиратских серверов не станет в принципе.
      
      >2. Читерство
      
      Чит-код можно ввести если в игре предусмотрены и запрограммированы эти самые чит-коды.
      Если бы хотели избавиться от читеров, просто убрали бы консоль из релизной версии.
      
      >3. Бустинг аккаунта.
      
      А в чём собственно проблема?
      Пользователя можно идентифицировать, явным образом, например по номеру телефона, электронной почте, отпечатку пальца, фотографии лица, адресу компьютера и другим признакам.
      В чате по голосу и стилю сообщений. Даже по манере игры, клавишам, жестам, интересам и прочим особенностям.
      Это не делают, потому, что в этом нет проблемы.
      
      > В реальности менеджер прекрасно понимает, что кодер-студент не обладает компетенциями
      
      В реальности разработчик, даже не студент, с академическим образованием, попав например в игровую индустрию, нуждается в переучивании. Потому, что его учили разраббатывать алгоритмы, а в игровой индустрии надо выжимать деньги из пользователя.
      
      Была смешная история. Сделали сервис для аналитики.
      Пользователь загружает данные.
      Алгоритм быстро всё проверяет перекрёстными расчётами, сверяется со своими базами данных.
      У живого крутого бугалтера на такую работу с бумагами уходит несколько дней.
      А сервис результат даёт почти мгновенно, там что-то не более 0.1 секунды было.
      Так всякие бизнесмены, ссказали фу, не может такого быть, расчёты слишком сложные. Компьютер не мог сосчитать так быстро, а значит это какой-то обман.
      Разработчики обновили сервис. Загруженные данные быстренько обсчитывались, а пользователю выводилась анимация, с крутящимися фитюльками и медленно ползущей полосой прогресса.
      Бизнесмены сказали вау и стали пользоваться.
      В третьей версии, сервис доработали. Ввели тарифные планы, быстрый, стандартный и полный. Быстрый показывал результаты через минуту, стандартный через десять минут, а полный через 30 минут.
      Алгоритм один и тот же. Справлялся за те же 0.1 секунду. А деньги платили за длительность анимации, чем она дольше крутилась, тем больше денег.
      
      > То есть бот от разработчика не имеет смысла.
      
      Потому, что он гарантировано валит человека.
      
      > Обычно функция у менеджера чтобы продукт просто присутствовал на рынке.
      
      Если что, то я писал о функции в продукте.
    183. *Талипов Артём (eric50@yandex.ru) 2021/03/04 02:38 [ответить]
      > > 182.Antonov Andy
      >Это просто пользователи не умеют и не понимают 99,99% того что там есть.
      
      Очень справедливое замечание. Я угараю с многих пользователей. Сидят, жалуются, что нет каких-то функций. Ставят дополнительные платные приложения, чтобы получить те функции, которые у них уже есть из коробки, но пользователи их не нашли или даже не знали об их существовании.
      Типичный цирк, когда пользователи смартфона, не могут найти кнопку включения и выключения фанарика, ставят стороннее приложение фанарика с рекламой.
      
      
      Мой товарищ в одно время со мной, купил такой же смартфон как у меня. Используем одинаково, для одинаковых задач. Но мой смартфон работает быстрее и дольше, чем его. А я всего лишь выключил лишние функции, удалил лишние приложения и настроил гаджет под себя.
      
      Не могу сказать, что я спец по офисным приложениям. Только по верхам, то что мне было нужно. Но когда опытная секретарша отбивает заголовки пробелами, крутит размеры шрифтов, чтобы настроить заголовок, то это полный 3.13здец. Там же прямо в меню есть стили для заголовков! Как это можно было не заметить?!
    182. Antonov Andy (andy.antonov@gmail.com) 2021/03/03 01:21 [ответить]
      > > 177.Поляков Дмитрий
      >> > 176.Antonov Andy
      >>> > 175.Хм
      >>взять тот же мелкомягкий охвес. Да, начиная с 2007-го там лютейшая дичь, но ООо/Либра/Апач до сих пор не могут в то, что умел ещё 2000.
      >не могут потому что оно банально 99,(9)% пользователей нафиг не сдалось
      Гм, мною, например, "фильтр" используется каждодневно. Когда в документе десяток тысяч строк, его использование - суровая реальность. Его реализация в ООо/Либре/Апаче заставляет материться шестиэтажно и лезть в МСО с терминалке (т.к. лицухи на локальный комп у мну нет).
      >офис как и браузер перегружен всякой фигней на овер 9000%.
      Это просто пользователи не умеют и не понимают 99,99% того что там есть. Я знаю вряд ли 5% его возможностей, но обычный пользователь знает бесконечно меньше меня.
      
      > > 178.Хм
      >> > 177.Поляков Дмитрий
      >>офис как и браузер перегружен всякой фигней на овер 9000%.
      > Flash Player удален с сайта Adobe
      Поддержка Flash Player браузерами прекратилась 4 или 5 лет назад!
    181. Хм 2021/03/02 23:19 [ответить]
      > > 180.Талипов Артём
      >например, делают компьютерную игру. Пришёл студент, сделал бота, который рвёт всех врагов. Он сделал очень красивый, простой и эффективный алгоритм. Или же воткнул самообучаемую нейросеть.
      >Но начальство посмотрело и говорит, что надо выбросить этот код.
      
       Всё несколько сложнее.
       Основные проблемы от клиентов в играх это:
      
      1. Создание пиратских серверов
      2. Читерство
      3. Бустинг аккаунта.
      
       В реальности менеджер прекрасно понимает, что кодер-студент не обладает компетенциями чтобы бороться с задротами, которые ЗАРАБАТЫВАЮТ на бустинге аккаунтов (и часто продаже читов), как пример чтобы новичок мог играть не в своей лиге.
      
       То есть бот от разработчика не имеет смысла.
      
      >В корпорациях всё крутится вокруг того, как слупить денег побольше. А специалисты и функции оцениваются именно по доходности.
      
       Обычно функция у менеджера чтобы продукт просто присутствовал на рынке. Потому что есть проблемы от клиентов, так и в сфере корпоративных войн.
    180. *Талипов Артём (eric50@yandex.ru) 2021/03/02 23:03 [ответить]
      > > 178.Хм
      > Вот только в современном мире зарабатывают на клиентской базе и специально тратят огромные ресурсы чтобы клиентскую базу наработать.
      
      А зачем? Нормальному человеку для жизни нужно не так уж много. Зарабатывать больше денег, как самоцель? Это уже какое-то буржуйство.
      
      Конечно, можно пойти, за деньги, лизать задницы, но противно же! У человека должно быть самоуважение!
      
      В корпорациях всё крутится вокруг того, как слупить денег побольше. А специалисты и функции оцениваются именно по доходности.
      
      А что, вот например, делают компьютерную игру. Пришёл студент, сделал бота, который рвёт всех врагов. Он сделал очень красивый, простой и эффективный алгоритм. Или же воткнул самообучаемую нейросеть.
      
      Но начальство посмотрело и говорит, что надо выбросить этот код. Потому, что у игрока, даже самого крутого геймера, в принципе нет шансов на победу. Бот умнее и быстрее человека. А значит человек обидеться на правду и потребует вернуть деньги. Надо подлизывать клиентов, прогнуться, чтобы они платили деньги!
    179. *Талипов Артём (eric50@yandex.ru) 2021/03/02 22:50 [ответить]
      > > 177.Поляков Дмитрий
      >а путь то тупиковый
      >зуб даю проблема была не в языке а в архитектуре сайта
      >недавно "легким движением руки", а точнее поменяв десяток строчек кода на одном сайте я уменьшил время отклика на 2 мать их порядка
      
      Всё может быть. Я подробностей не знаю. Но разных историй встречал очень много и в одну и в другую сторону.
      Только вот общая тормознутость интерпретируемых языков, на обычных платформах, всё же объективный факт. Как не крути, а для выполнения одинаковых инструкций, он тратит больше ресурсов.
      Конечно, где-то и как-то интерпретируемые языки, могут вырваться вперёд.
      А языки компилируемые в нативный код не гарантируют, что код будет эффективным.
      Но например, перекодировка utf-32 le в utf-8 туда и обратно, на интерпретируемом языке это тормознутая жуть. Именно силами самого интерпретатора, а не встроенных перекодировщиков, которые используют нативные функции.
      
      >не могут потому что оно банально 99,(9)% пользователей нафиг не сдалось
      >офис как и браузер перегружен всякой фигней на овер 9000%.
      
      И тут вы тоже правы. Я перебрался на open office и в целом доволен. Но переход был долгим и мучительным, поскольку где-то что-то не работало. Пришлось перебрать разные пакеты и отвергнуть несколько попсовых.
      
      Да и с этим open office тоже не всё так хорошо, как хотелось бы. С кодировками он путается. С проверкой орфографии лагает. И прочие мелочи. Приходится периодически сражаться. В итоге, мне удобнее набирать текст в блокноте, а oo writer запускаю, когда прижмёт.
      
      Зато всяких излишних украшательств, тоже натащили. Часть анимации, эффектов, я отключил. Оно нафиг никому разумному не нужно. Но ведь сделали же! А зачем? Именно just for fun.
      
      Вот реально, лучше бы сделали поддержку дефисов, мягких переносов, коррекцию буквы "ё", поддержку ударений, ограничение длины строк, замену с учётом морфологии, раздельный документ с метками для частей...
    178. Хм 2021/03/02 22:11 [ответить]
      Legacy-код - это большое НЕТ
      Добавление нового функционала, который можно выпустить в версии X, в версии X-1, только для того, чтобы не обижать пользователей X-1 - абсолютно и 100% нет. Аналогично, добавление X-1 кода в версию X только потому, что он может 'пригодиться', должно быть признано недопустимым. Если вы по-прежнему берете с людей плату за X-1 и строите свои апгрейды поверх этого, то у вас очень плохой бизнес-план.
      
       В чём-то разумный подход.
       Вот только в современном мире зарабатывают на клиентской базе и специально тратят огромные ресурсы чтобы клиентскую базу наработать.
      
      > > 177.Поляков Дмитрий
      >не могут потому что оно банально 99,(9)% пользователей нафиг не сдалось
      >офис как и браузер перегружен всякой фигней на овер 9000%.
      
       Flash Player удален с сайта Adobe
      
      Компания Adobe с радостью готова помочь сформировать следующую цифровую эру
    177. Поляков Дмитрий 2021/03/02 21:58 [ответить]
      > > 169.Талипов Артём
      >Банально, сделали проект на рельсах. Поставили дюжину мощнейших серверов. А сайт всё равно тормозит. переписали проект на крестах и продали лишние 11 серверов.
      а путь то тупиковый
      зуб даю проблема была не в языке а в архитектуре сайта
      недавно "легким движением руки", а точнее поменяв десяток строчек кода на одном сайте я уменьшил время отклика на 2 мать их порядка
      > > 176.Antonov Andy
      >> > 175.Хм
      >взять тот же мелкомягкий охвес. Да, начиная с 2007-го там лютейшая дичь, но ООо/Либра/Апач до сих пор не могут в то, что умел ещё 2000.
      не могут потому что оно банально 99,(9)% пользователей нафиг не сдалось
      офис как и браузер перегружен всякой фигней на овер 9000%.
    176. *Antonov Andy (andy.antonov@gmail.com) 2021/03/02 15:29 [ответить]
      > > 175.Хм
      Кроме старт-апов есть ещё и свои продукты. Взять тот же мелкомягкий охвес. Да, начиная с 2007-го там лютейшая дичь, но ООо/Либра/Апач до сих пор не могут в то, что умел ещё 2000. Точнее, понимать сделанное могут, а вот как это сделать в них - тайна великая есть. Плюс крайне своеобразное понимание некоторых весьма критичных для меня вещей, из-за чего приходиться использовать именно МСО.
    175. Хм 2021/03/02 15:05 [ответить]
      Любой гаражный стартап в какой-то момент может стать корпорацией.
       И старая корпорация может выдавать регулярно конкурентоспособный продукт... потому что поглощает стартапы.
    174. *Antonov Andy (andy.antonov@gmail.com) 2021/03/02 14:29 [ответить]
      > > 173.Хм
      > Вполне логично почему корпорации не способны создавать конкурентоспособный продукт. Ведь корпорации ориентированы на конвейерное производство и создание соответствующей дисциплины.
      Гм, Вы уверены? Создают, очень даже. Но затем в какой-то момент начинается звёздная болезнь и головокружение от успехов. И лютая дичь в решениях...
    173. Хм 2021/03/02 14:00 [ответить]
      > > 172.Талипов Артём
      >>Программирование начинается с проекта который создаёт архитектор. И вот архитектор отвечает на вопрос зачем.
      >На этот и подобные вопросы может быть лишь один правильный ответ - just for fun!
      
       Вполне логично почему корпорации не способны создавать конкурентоспособный продукт. Ведь корпорации ориентированы на конвейерное производство и создание соответствующей дисциплины.
       То есть менеджеры лучше знают как нужно отвечать на вопрос зачем... как выстраивать архитектуру у кода, а значит решать задачи заказчика.
       Потому что конвейерное производство предполагает сокращение издержек, а это всегда про "борьбу с украшательством" с точки зрения высшего менеджмента.
      
       ***
      
       Фишка в том, что попадают в высший менеджмент не за талант и гениальность, а за верность. Так что кодерам не обязательно подтверждать свою компетентность перед заказчиком и менеджером - и так схавают.
    172. *Талипов Артём (eric50@yandex.ru) 2021/03/01 23:43 [ответить]
      > > 170.Хм
      >Достаточно ответить на вопрос зачем
      
      На этот и подобные вопросы может быть лишь один правильный ответ - just for fun!
      Я живу пока прикольно. А когда надоест, упаду и сдохну.
      Иного смысла, что-то делать, вообще нет и не может быть.
      
      > > 171.Antonov Andy
      >Это ты так Ruby on Rails попинал, да?
      
      Их самых.
      
      > Может, их просто не там и не так применяли?
      
      Скорее всего именно так.
      Оно годится для прототипирования, попробовать, прикинуть... Но для бизнес логики, слишком медленно.
      
      >Вообще, Ruby - достаточно любопытственная штука.
      
      Знаю, колупал. Одно время даже пытался проектик пилить.
      
      > И многие вещи Сям или Паскалю и не снились.
      
      Угу, рефлексия из коробки. Всё есть объект, даже то, что не объект. Ням! Фкусняшка.
      Но вообще-то, сам язык, тоже прототип. Он показал несколько вкусных идей и заглох.
      Идеи поюзали, а затем скомуниздили в другие языки.
      И на сегодняшний день, рубин ничего уникального и особенного не может предложить.
      
      > Но - всему своё место...
      
      Вот именно! Я уже об этом писал.
      
      >Там же даже типизация не нужна, ога. Прям как в Экселе:
      
      Вот-вот, только для прототипирования и годиться. А когда нужна серьёзность, то облом. Динамическая типизация хороша там и тогда, когда она нужна. Во всех же прочих случаях строгая типизация надёжнее.
      И да, на C++ динамическую типизацию можно сделать, если нужно.
      
      
      > И если кто-то в таком штиле изваяет сайт - там и гросса (дюжина дюжин) серваков не хватит!
      
      Угу. Но при этом, довольно много сайтов, как раз начинали именно с рельс. А потом отходили.
      
      Так-то вкусных языков много. К примеру erlang. Но нишевые решения почти всегда проигрывают попсовым, за счёт лучшей документации, большей совместимости и развитой поддержки.
    171. Antonov Andy (andy.antonov@gmail.com) 2021/03/01 23:21 [ответить]
      > > 169.Талипов Артём
      >> > 168.Хм
      >Банально, сделали проект на рельсах. Поставили дюжину мощнейших серверов. А сайт всё равно тормозит. переписали проект на крестах и продали лишние 11 серверов.
      Это ты так Ruby on Rails попинал, да? Может, их просто не там и не так применяли?
      ЗЫ Вообще, Ruby - достаточно любопытственная штука. И многие вещи Сям или Паскалю и не снились. Но - всему своё место...
      Там же даже типизация не нужна, ога. Прям как в Экселе: любая переменная без явно объявленного типа - универсальный контейнер, причём - ещё и бесконечной разрядности! Но расплачиваться за это нужно жутко тормозным рантаймом. И если кто-то в таком штиле изваяет сайт - там и гросса (дюжина дюжин) серваков не хватит!
    170. Хм 2021/03/01 22:33 [ответить]
      > > 169.Талипов Артём
      >> А основная задача языка программирования это
      >Объяснить машине, что она должна сделать, пока человек будет лежать на диване и плевать в потолок.
      >"вкалывают роботы, счастлив человек"
      
       Кроме вопросов как и что, есть ещё и вопрос зачем.
       Программирование начинается с проекта который создаёт архитектор. И вот архитектор отвечает на вопрос зачем.
       Например, в комментариях к коду грамотный разработчик не пишет ответы на вопросы КАК, и даже на вопросы ЧТО (что делает инструкция или блок инструкций).
      
       А как мы знаем, не каждый может стать архитектором... кодеров можно легко заменить, а вот архитекторов отвечающих на вопрос ЗАЧЕМ (!) уже не так просто. Потому что заказчик сам не знает, но доверять машине в этом тяжело.
      
      >Пока, ещё никто не описал, как же в реальности думает человек. Есть лишь общие предположения.
      
       Если не вдаваться в философию всё проще. Достаточно ответить на вопрос зачем - этим занимаются архитекторы. И как очевидно, сложные и инструменты и качественное образование не всем нужно.
    169. *Талипов Артём (eric50@yandex.ru) 2021/03/01 22:23 [ответить]
      > > 168.Хм
      >Сверхвысокий язык программирования это Prolog.
      
      Сверхвысокоуровневый язык программирования (язык программирования сверхвысокого уровня, англ. very high-level programming language, VHLL) - язык программирования с очень высоким уровнем абстракции. В отличие от языков программирования высокого уровня, где описывается принцип 'как нужно сделать', в сверхвысокоуровневых языках программирования описывается лишь принцип 'что нужно сделать'. Термин впервые появился в середине 1990-х годов для обозначения группы языков, используемых для быстрого прототипирования, написания одноразовых скриптов и подобных задач.
      Так, разработчики Icon (и его диалекта Unicon (англ.)русск.) описывают его как VHLL. К языкам сверхвысокого уровня также часто относят такие современные сценарные и декларативные (в частности функциональные) языки как Ruby, Haskell, а также Perl и предшествовавший ему мини-язык AWK.
      Большой класс языков сверхвысокого уровня - это языки, используемые для специфических приложений и задач (то есть предметно-ориентированные). В связи с этой ограниченностью они могут использовать синтаксис, который никогда не используется в других языках программирования, например, непосредственно синтаксис английского языка. Примером VHLL, распознающего синтаксис английского языка, может служить язык компилятора текстовых квестов Inform версии 7.
      
      > Императивный язык далёк от стиля на котором думает человек.
      
      Конечно. Но от этого стиля далеко вообще всё. Пока, ещё никто не описал, как же в реальности думает человек. Есть лишь общие предположения.
      
      Зато императивный стиль, как раз давно известен и описан, даже в сказках.
      "пойди туда - не знаю куда, принеси то - не знаю что"
      
      А итальянские забастовки, действуют только на тупых начальников и на тупые законы.
      
      
      > А основная задача языка программирования это
      
      Объяснить машине, что она должна сделать, пока человек будет лежать на диване и плевать в потолок.
      "вкалывают роботы, счастлив человек"
      
      > меньше тратить "мыслетоплива"(например, можно в HEX кодах программировать, а можно использовать компилятор).
      
      Это уже вторично. Оно, конечно важно и нужно, но вторично.
      
      Банально, сделали проект на рельсах. Поставили дюжину мощнейших серверов. А сайт всё равно тормозит. переписали проект на крестах и продали лишние 11 серверов.
    168. Хм 2021/03/01 21:26 [ответить]
      Сверхвысокий язык программирования это Prolog.
      
       Известна классификация языков программирования по их близости либо к машинному языку, либо к естественному человеческому языку. Те, что ближе к компьютеру, относят к языкам низкого уровня, а те, что ближе к человеку, называют языками высокого уровня. В этом смысле декларативные языки можно назвать языками сверхвысокого или наивысшего уровня, поскольку они очень близки к человеческому языку и человеческому мышлению.
      
      > > 167.Талипов Артём
      >Любой императивный язык описывает, "что нужно сделать".
      
       Императивный язык далёк от стиля на котором думает человек.
       А основная задача языка программирования это меньше тратить "мыслетоплива"(например, можно в HEX кодах программировать, а можно использовать компилятор).
    167. *Талипов Артём (eric50@yandex.ru) 2021/03/01 21:21 [ответить]
      > > 165.Хм
      > Язык программирования с очень высоким уровнем абстракции. В отличие от языков программирования высокого уровня, где описывается принцип 'как нужно сделать', в сверхвысокоуровневых языках программирования описывается лишь принцип 'что нужно сделать'.
      
      Любой императивный язык описывает, "что нужно сделать".
      
      Разница в уровне деталировки. Причём, эту самую деталировку выносят в отдельные функции.
      
      На высоком уровне говорят "сложить a, b"
      А на низком уровне описывают, что сделать, чтобы сложить a и b.
    166. Хм 2021/03/01 21:02 [ответить]
      По факту языки сверхвысокого уровня нужны.
       Какая основная задача использования языков программирования? Чтобы "мыслетопливо" в процессе удержания внимания (и переключения) минимально тратилось.
      
       Для одних задач нужны регулярки, для других уже скрипты... а сверхвысокие языки, когда вопрос задаётся ОК Гугл, при этом разработчик всего лишь экономит своё "мыслетопливо" внимания на удержании и переключениях контекста.
    165. Хм 2021/03/01 21:02 [ответить]
      > > 164.Талипов Артём
      
      > Язык сверх высокого уровня, сам по себе, потребляет очень много ресурсов.
      > Один и тот же алгоритм, написанный на языке сверхвысокого уровня, будет работать в 10000 раз медленнее, чем тот же алгоритм, написанный на языке сверхнизкого уровня.
      
       Язык программирования с очень высоким уровнем абстракции. В отличие от языков программирования высокого уровня, где описывается принцип 'как нужно сделать', в сверхвысокоуровневых языках программирования описывается лишь принцип 'что нужно сделать'.
      
      >Увы, серебренной пули нет! Иначе все бы использовали только один язык программирования, который самый лучший и подходит для всех.
      
       Чтобы программировать в стиле 'что нужно сделать' - это не про ОК Гугл. Тут мозги нужны. Как пример, решение комбинаторных задач (например шахматы). То есть создание алгоритмов (!) уровня AlphaGo. Так что использование сверхвысокого языка наоборот позволяет использовать минимальные ресурсы, например классические алгоритмы для шахмат больше потребляют ресурсов для решения комбинаторных задач.
    164. *Талипов Артём (eric50@yandex.ru) 2021/03/01 20:36 [ответить]
      > > 160.Симонов Сергей
      >Сразу вспомнились векторные функции и операторы в UE4, которые движения персонажа задают. Но там всё сделано визуально, типы данных помечены на плашках разными цветами, координаты поименованы - захочешь - не запутаешься
      
      Создание графического интерфейса для разработки это отдельная морока.
      Причём никак не получается удовлетворить сразу всех.
      Самым универсальным оказывается простой текстовый редактор и консольный компилятор.
      А когда вокруг него выстраивают какую-то обвязку то возникают искусственные сложности, при этом процесс нельзя автоматизировать.
      
      На счёт же ошибиться... когда цветовая маркировка, то например дальтоники путаются. Ой, да есть чудики, которые умудряются даже путать лево и право, к примеру евреи и арабы, пишут в другую сторону.
      
      А в некоторых языках программирования есть фишечка, называется "строгая статическая типизация".
      Когда функция ожидает параметр определённого типа, а ей передают параметр иного типа, то компилятор вообще не захочет компилировать.
      
      К примеру есть старая функция Sleep(). Она просит время, но какое время? Где-то в секундах. Где-то в миллисекундах. де-то в тиках. А где-то в квантах.
      Sleep( 600 );
      И что это значит? Надо лезть в справочник для конкретной среды разработки.
      
      А можно указывать строгим типом:
      Sleep( seconds( 600 ) );
      Если, конечно, поддерживаются строгие типы.
      Это будут уже не просто какая-то цифра 600, а именно секунд.
      А вот числовое значение длины, массы или количество яблок, уже не указать.
      Sleep( length( 600 ) );
      Уже вызовет ошибку компиляции.
      
      Очень простая и довольно надёжная защита от дурака. Причём на конечную программу вообще не влияет. Типы нужны для человека и компилятора. А компьютер в любом случае работает с числами.
      
      Ещё можно использовать абстрактный тип и приведение к нему. Например та же Sleep ожидает тип времени time_base. А от этого типа наследуются другие типы.
      Sleep( seconds( 600 ) );
      Sleep( minutes( 60 ) );
      В последнем случае, компьютер автоматически может пересчитать единицы, из пользовательских в нужные. Он ведь знает, что 1 minutes это 60 seconds.
      
      Одна из совместных космических миссий на Марс, завершилась крахом. Европейцы растояние указали в метрах, а пиндосы в футах. Для программы же все числа были просто числами.
      Но можно сделать базовый тип длины length_base. От него унаследовать типы metres и futes. А дальше указывать программе, что и как удобно.
      drive( metres( 123456 ) );
      drive( futes( 123456 ) );
      И это будут разные длины, поскольку компьютер пересчитает значения к нужным единицам.
      
      >Вот-вот, типичная линуксовая программа занимает единицы, или десятки мегабайт, виндовая - от 500 Мб и до бесконечности
      
      Ну, эм-эм-эм... Мне, в первую очередь, память была нужна для своих замут. От банальной базы данных в памяти (bd in memory).
      Ещё, например, компилирую, помещая промежуточные файлы в ramdrive. Ну и одновременно у меня много всякого запущено.
      А так... Много памяти это не всегда хорошо. Надо смотреть, сколько тянет процессор, материнская плата, операционная система и так далее.
      Много памяти это дорого. А ещё дешевая память глючит чаще. И на больших объёмах это заметно.
      
      > > 161.Габдрафиков Руслан Рамилевич
      >Не хочу разрушать вашу идиллию. Но.
      
      Это не идиллия, а даже очень наоборот.
      
      >Языки программирования разделены на уровни абстракции.
      
      Давно не новость.
      
      > И какие нибудь сверхвысокоуровневые языки программирования вполне могут удовлетворить все ваши запросы.
      
      Я уже писал, но повторю, что у всего есть своя цена.
      
      Язык сверх высокого уровня, сам по себе, потребляет очень много ресурсов.
      Один и тот же алгоритм, написанный на языке сверхвысокого уровня, будет работать в 10000 раз медленнее, чем тот же алгоритм, написанный на языке сверхнизкого уровня.
      
      Язык низкого уровня компилируется напрямую в машинный код.
      Язык высокого уровня, компилируется в байткод и выполняется на виртуальной машине.
      А язык сверхвысокого уровня, выполняется как есть, без компиляции.
      
      Там где язык низкого уровня, просто знает откуда читать или куда писать значение переменной (по адресу памяти).
      Языку сверхвысокого уровня, надо найти эту переменную, причём искать по имени.
      
      Увы, серебренной пули нет! Иначе все бы использовали только один язык программирования, который самый лучший и подходит для всех.
    163. *Antonov Andy (andy.antonov@gmail.com) 2021/03/01 14:08 [ответить]
      > > 160.Симонов Сергей
      >> > 158.Талипов Артём
      > >Угу. Я был вынужден поставить 32 gb оперативки. Не хватало!
      >Вот-вот, типичная линуксовая программа занимает единицы, или десятки мегабайт, виндовая - от 500 Мб и до бесконечности
      Браузер возьмите. Свежие версии ФФ/Оперы/Хрома что под виндой, что под линуксом память жрут как не в себя. На одной из домашних машин после переползания с ХП на Убунту 18 только из-за этого пришлось насыпать 16ГБ ОЗУ (больше мать всё равно не умеет согласно мана).
      Просто в ХП ФФ был 45-й, которому лет немало, а в Убунте - свежий, 80-какой-то-там.
      Да даже разница между 48-м и 52-м ФФ по жручести памяти такая, что запустить 52-й с профилем от 48-го (в котором 695 табов было прописано на тот момент) на той же машине не удалось.
      ЗЫ 52-й - последний гарантированно запускаемый под ХП ФФ.
      ЗЗЫ Все они, которые современные, на каждый таб порождают отдельный процесс (или два, не помню), который минимум 60МБ занимает. Не то, чтоб это сильно повышало стабильность, т.к. всё равно в случае проблем падает всё сразу. Аналогично в ООо/Либре/Апач офисах.
    162. *Симонов Сергей (gann.lector@yandex.ru) 2021/03/01 13:53 [ответить]
      > > 161.Габдрафиков Руслан Рамилевич
      
       >Не хочу разрушать вашу идиллию. Но.
      
      Да ладно :) "Полное единство мнений бывает только на кладбище" (с)
      
       >Языки программирования разделены на уровни абстракции. И какие нибудь сверхвысокоуровневые языки программирования вполне могут удовлетворить все ваши запросы.
       >Например Dart.
      
      Ничего не могу возразить, т.к. незнаком с вопросом. Полагаюсь на мнение специалистов.
    161. Габдрафиков Руслан Рамилевич (the28awg@gmail.com) 2021/03/01 13:49 [ответить]
      Не хочу разрушать вашу идиллию. Но.
      Языки программирования разделены на уровни абстракции. И какие нибудь сверхвысокоуровневые языки программирования вполне могут удовлетворить все ваши запросы.
      Например Dart.
    160. *Симонов Сергей (gann.lector@yandex.ru) 2021/03/01 13:12 [ответить]
      > > 158.Талипов Артём
      
      >К примеру параметры функции, могут быть трёх видов:
      
      Вот, на конкретных примерах понятно, спасибо
      
       >Но можно сделать именованные параметры, вызывать их в любом порядке и только те, которые нужны
       >coordinate( x=1, y=2, z=3, t=0 );
      
      Сразу вспомнились векторные функции и операторы в UE4, которые движения персонажа задают. Но там всё сделано визуально, типы данных помечены на плашках разными цветами, координаты поименованы - захочешь - не запутаешься, только если с бодуна лепить.
      
       >Угу. Я был вынужден поставить 32 gb оперативки. Не хватало!
      
      Вот-вот, типичная линуксовая программа занимает единицы, или десятки мегабайт, виндовая - от 500 Мб и до бесконечности
    159. *Симонов Сергей (gann.lector@yandex.ru) 2021/03/01 12:51 [ответить]
      > > 157.Еромеев Андрей Валерьевич
      
      Спасибо, это интересно. Особенно доставило:
      "Тенденции 'биологизаторства' в СССР противостояли философы. Они видели в его проявлении редукционизм, сведение системы более высокой ступени организации к системе более низкой ступени. Точно так же, как жизнь человека нельзя свести к одним лишь биологическим процессам, нельзя даже в далёком приближении приравнивать вычислительную модель к реальному нейрону. Такая тенденция была характерна и для западной школы, но для советской школы она была более ярко выражена. Учёные подвергались большому давлению со стороны философов, которые критиковали любую попытку назвать какой-то технический предмет термином из арсенала биологов."
      
      Д,Б!
    158. *Талипов Артём (eric50@yandex.ru) 2021/03/01 12:45 [ответить]
      > > 154.Симонов Сергей
      >А вот это засада для начинающих, кто не знает.
      
      Это и для знающих засада. На своей машине запарно запускать и утомительно ждать. Так что настраивают build сервера. Не один, а сразу несколько, которые анализируют и компилируют под разные платформы. Но вся эта настройка, синхронизация, получения отчётов, ещё та мутотень.
      
      >Само собой, "что один человек сделал - другой завсегда сломать может" (с)
      
      А то! Но если бы "сломать", а то тупо отключают, "я лучше знаю, как правильно, а он мне только мешается".
      
      >Хотя бы так, 90% ошибок - типичные.
      Ну, я базовые правила, точнее их направления, описывал чуть раньше. Если всё сделано как надо, то 99.999% ошибок отлавливается на этапе разработки или тестирования.
      
      >Честно признаю, что концепция "выразительности" языка программирования мне непонятна.
      
      К примеру параметры функции, могут быть трёх видов:
      1. входные
      2. выходные
      3. изменяемые
      
      В принципе, входной параметр, может быть даже двух подвидов:
      1.1. входной константный
      1.2. входной локально изменяемый
      
      Зачастую смешивают. Разделяют слабо. А если разделяют, то по технологии доступа. А на счёт смысла ничего нет. Но если учитывать смысл, то внезапно компилятор может ловить логические ошибки.
      
      // константный параметр
      function foo( const object arg )
      arg = new object(); // ошибка, потому что он константный
      arg.modified(); // ошибка, потому, что запрещено изменять
      end function
      
      // локально изменяемый параметр
      function foo( in object arg )
      arg = new object(); // ошибка, потому что нужно использовать переданный объект
      arg.modified(); // изменения разрешены
      end function
      
      // возвращаемый параметр
      function foo( out object arg )
      arg = new object(); // всё верно, потому, что надо что-то вернуть, а если не возвращать, то будет ошибка
      arg.modified(); // изменения разрешены
      end function
      
      // изменяемый параметр
      function foo( ref object arg )
      arg = new object(); // ошибка, параметр нужно только изменять
      arg.modified(); // изменения разрешены и даже нужны
      end function
      
      То есть, программист помечает аргумент функции одним из специальных атрибутов. А компилятор уже проверяет, что именно делается с этим аргументом. В разных сценариях, что-то разрешено, а что-то запрещено.
      
      Причём, это касается, не только внутренностей функции, но и вызова самой функции.
      
      Например, для вызова функции с передачей входного параметра, достаточно указать сразу значение:
      foo( new object() );
      
      Для возвращаемого параметра, нужно передать пустую переменную, в которую будет помещено возвращенное значение:
      var result;
      foo( out result );
      Если что-то есть в переменной, то компилятор ругнётся.
      
      А для изменяемого параметра, наоборот, надо передавать не пустую переменную:
      var edit = new object();
      foo( ref edit );
      
      Отчасти такое есть. Но именно отчасти. Самое близкое это техналогия sal от microsoft. Она как раз помагает анализатору лучше понять, что программист ожидает от кода.
      
      А ещё удобно для автоматической генерации документации.
      
      > Но выразительность объявления класса или вызова метода?
      
      И это тоже. Вот про те же параметры. К примеру У функции куча параметров. А в каком порядке эти параметры? Если их десяток, то уже нужен справочник, а если больше? А код непонятный, когда всё в кучую
      coordinate( 0, 1, 2, 3, 4, 5, 6 );
      
      Но можно сделать именованные параметры, вызывать их в любом порядке и только те, которые нужны
      coordinate( x=1, y=2, z=3, t=0 );
      
      Или возвращаемые параметры из функций. Вообще-то сейчас это считается некашерным.
      Утверждается, что в параметре надо значения передавать, а функция уже вернёт результат.
      А если надо вернуть сразу несколько значений?
      var x,y,z = coordinate();
      Уже сразу разложено по переменным, не надо прыгать с бубном и лепить структуры или кортежи.
      
      >Ну, сейчас так и происходит. После 11 лет на Линуксе, поставив Win10 для UE4, был в шоке, сколько вся эта лабуда отжирает дискового пространства и памяти.
      >16 ГБ оперативки достаточно только для относительно простых проектов.
      
      Угу. Я был вынужден поставить 32 gb оперативки. Не хватало!
    157. *Еромеев Андрей Валерьевич (bookrat4@boson.nom.za) 2021/03/01 11:29 [ответить]
      История нейронных сетей в СССР
      https://habr.com/ru/company/sberdevices/blog/543988/
    156. *Симонов Сергей (gann.lector@yandex.ru) 2021/03/01 11:03 [ответить]
      > > 155.Antonov Andy
      
      Йа ф курсе. И сразу предупредил: "что на ум пришло"
    155. *Antonov Andy (andy.antonov@gmail.com) 2021/03/01 10:44 [ответить]
      > > 151.Симонов Сергей
      >> > 150.Талипов Артём
      >
      >Согласен, хотя и не настолько хорошо разбираюсь в теме.
      >Конечно, надо бы, чтобы компилятор отслеживал, к примеру, пары New - Delete, вроде как в HTML отслеживают открывающие и закрывающие теги (кривая аналогия, знаю, но первое, что на ум пришло)
      Очень кривая. В HTML нет строгого требования к парности тегов. Даже в XHTML, который куда проще для синтаксического разбора, допускаются конструкции, в которых закрывающий тег фактически в строен в отрывающий. Ну, и строгого требования к строгому следованию стандарту тоже нет, потому браузеры приходится учить разбирать код любой корявости (с результатом опять же любой корявости).
      Кроме того, с Delete возникает вопрос - когда его, собссно, применять.
    154. *Симонов Сергей (gann.lector@yandex.ru) 2021/03/01 10:05 [ответить]
      > > 153.Талипов Артём
      
       >В принципе вы правы. Но не всё так просто. Эти пары могут быть разнесены. И для их отслеживания нужен глубокий анализ. Тут нужно и статическое отслеживание, просматривающее все ветви, а также динамическое, контролирующее то, что реально получилось.
      
      Так глубоко я уже не лезу :)
      
      >
       >Угу. Именно так и делают. Но! Часть предупреждений компилятора скрыта! То есть их надо дополнительно включать. А что ещё хуже, некоторые библиотеки написаны так, что заваливают пользователя кучей предупреждений.
      
       >А есть ещё, ранее упомянутые статические анализаторы. Они ковыряют код гораздо глубже и находят больше подозрительных мест.
       >Причём, может получиться так, что предупреждение появится лишь однажды, будучи пропущенным через пяток анализаторов и тройку компиляторов. У всех разные проверки и только кто-то один, может заметить ошибку.
      
      А вот это засада для начинающих, кто не знает.
      
      
       >Некоторые компиляторы, можно заставить выводить сообщение на языке пользователя. Но порой, читая такие сообщения, я думаю, что лучше уж он выводил на английском.
      
      В том и беда. Я тоже там, где нет русской справки, но программа сложная, оставляю интерфейс на английском. Потому что, читая английскую справку, гадать, что имел в виду переводчик интерфейса, и как он по русски это обозвал - это ппц 90 уровня.
      К сообщениям об ошибках тоже относится. На английском решение нагуглить проще.
      
       >К сожалению, компиляторы и анализаторы, не могут выявить все ошибки. Человек может написать такую ерундень, которая сведёт машину с ума.
      
      Само собой, "что один человек сделал - другой завсегда сломать может" (с)
      >
       >Конечно, надо работать над анализаторами. Но туда попадут типичные ошибки.
      
      Хотя бы так, 90% ошибок - типичные.
      >
       >Надо работать над выразительностью языка, чтобы компилятор понимал желаемое, и мог дополнительно проверять код.
      
      Честно признаю, что концепция "выразительности" языка программирования мне непонятна. :) Художественная выразительность - это понятно. Но выразительность объявления класса или вызова метода? О_О
      >
       >А ещё, надо делать более защищённые сущности языка, затрудняя их ошибочное использование. Ну, то есть со встроенной самопроверкой и защитой от дурака.
      
      Однозначно да.
      >
       >Только вот за всё придётся платить! Компиляторы и программы будут требовать более мощные компьютеры. Так что придётся искать компромиссы.
      
      Ну, сейчас так и происходит. После 11 лет на Линуксе, поставив Win10 для UE4, был в шоке, сколько вся эта лабуда отжирает дискового пространства и памяти.
      16 ГБ оперативки достаточно только для относительно простых проектов.
    153. *Талипов Артём (eric50@yandex.ru) 2021/03/01 09:51 [ответить]
      > > 151.Симонов Сергей
      >> > 150.Талипов Артём
      >Конечно, надо бы, чтобы компилятор отслеживал, к примеру, пары New - Delete, вроде как в HTML отслеживают открывающие и закрывающие теги (кривая аналогия, знаю, но первое, что на ум пришло)
      
      В принципе вы правы. Но не всё так просто. Эти пары могут быть разнесены. И для их отслеживания нужен глубокий анализ. Тут нужно и статическое отслеживание, просматривающее все ветви, а также динамическое, контролирующее то, что реально получилось.
      
      >По уму, надо, чтобы компилятор не исправлял сам, а вывешивал предупреждения.
      
      Угу. Именно так и делают. Но! Часть предупреждений компилятора скрыта! То есть их надо дополнительно включать. А что ещё хуже, некоторые библиотеки написаны так, что заваливают пользователя кучей предупреждений.
      
      А есть ещё, ранее упомянутые статические анализаторы. Они ковыряют код гораздо глубже и находят больше подозрительных мест.
      Причём, может получиться так, что предупреждение появится лишь однажды, будучи пропущенным через пяток анализаторов и тройку компиляторов. У всех разные проверки и только кто-то один, может заметить ошибку.
      
      Ах да. Вспоминается язык ada. Он разрабатывался по заказу американских военных. И там слишком много требовалось, проверки были очень злые. В итоге, компиляторы оказались слишком сложными и могли работать лишь на крутых компьютерах.
      
      >Основная трудность - понять всё это, т.к. на английском.
      
      Некоторые компиляторы, можно заставить выводить сообщение на языке пользователя. Но порой, читая такие сообщения, я думаю, что лучше уж он выводил на английском.
      
      А вообще, например у C++, из-за шаблонной магии, такие заковыристые сообщения об ошибках, что там не то, что понять суть ошибки, там даже трудно понять место самой ошибки. Поскольку ошибка проявляется в самом шаблоне, но может возникнуть из-за плохих параметров шаблона. В итоге, компилятор указывает все места и фактической ошибки, и места раскрытия шаблона и ещё параметры шаблона.
      
      К сожалению, компиляторы и анализаторы, не могут выявить все ошибки. Человек может написать такую ерундень, которая сведёт машину с ума.
      
      Конечно, надо работать над анализаторами. Но туда попадут типичные ошибки.
      
      Надо работать над выразительностью языка, чтобы компилятор понимал желаемое, и мог дополнительно проверять код.
      
      А ещё, надо делать более защищённые сущности языка, затрудняя их ошибочное использование. Ну, то есть со встроенной самопроверкой и защитой от дурака.
      
      Только вот за всё придётся платить! Компиляторы и программы будут требовать более мощные компьютеры. Так что придётся искать компромиссы.
    152. Глaвнигра 2021/03/01 09:33 [ответить]
      > > 151.Симонов Сергей
      >Конечно, надо бы, чтобы компилятор отслеживал, к примеру, пары New - Delete
      
      Современные могут. Могут даже вставлять специальные защитные объекты в кучу и стек, чтобы если ошибка таки просочилась, она была выявлена во время исполнения. Так же есть специальные анализаторы исходных текстов, которые отлавливают и это и многое другое.
      
      Проблема в сущности одна - все это требует МНОГО памяти и МНОГО времени. Настолько что даже сейчас не хватает.
    Страниц (10): 1 2 3 4 5 6 7 8 9 10 Архивы (1): 1

    Связаться с программистом сайта.

    Новые книги авторов СИ, вышедшие из печати:
    О.Болдырева "Крадуш. Чужие души" М.Николаев "Вторжение на Землю"

    Как попасть в этoт список

    Кожевенное мастерство | Сайт "Художники" | Доска об'явлений "Книги"