Что мне в ZX не нравится - это фиксированная странная палитра и по своей сути однобитная графика
Которая при этом была цветной. С ограничениями, но цветной. Что обеспечивало бюджет в 10,12 тактов на байт экрана в кадр. Для сравнения, у атари будет примерно 2,31 такта на байт экрана (с цветом). Или 4.6 для монохрома, но там у спектрума будет почти 15. Потому что тактов меньше, а экран в байтах больше.
Вот этот факт, вместе с неприлично низкой ценой спектрума и возможность грузиться с кассеты и сделали его популярным.
Моё поле и мой тезис: «хаскель эффективнее». Ваша цитата: «Так что в данном случае шарп с хаскелем будет 1:1.»
Опять ложь. "В данном случае" касалось аггрегирования списка и контекст был там.
Ваша цитата: «Вот пусть и там и там будет 100%, тогда можно сравнивать.»
Вот это я говорил.
и важны только 100%-о работающие компиляторы
А это - нет.
Я больше не хочу говорить с человеком, перевирающим мои слова на каждый аргумент. С человеком, который не понимает мои аргументы и продолжает настаивать на своём.
Исходный код ваш мне нужен был, чтобы понять, с кем я вообще спорю. Потому что в интернете много неопытных теоретиков, не видевших в глаза проектов больше 10к строк. Какой смысл мне с такими спорить о методах управления сложностью?
Я откровенно устал указывать на ложь. В каждом сообщении. Ложь, манипуляции, демагогия. Никакой конструктивности. Так что я сворачиваюсь. Мы похоже на разных языках говорим.
Степени оптимизации, разворачивание циклов, поддержка разных типов архитектур, всяких версий наборов sse/avx, скорость компиляции, кроссплатформенность, логгирование. Я не разбираюсь в компиляторах, никогда не писал, но это список навскидку.
На что вы ответили, что либо 100%, либо не считается. Так вот, компилятор плюсов (любой) не обрабатывает 100% исходников, соответствующих стандарту, так, как того требует стандарт. В чём разница?
Разница в том, что проценты поддержки семантики нельзя сравнивать напрямую. Я, к примеру, могу написать компилятор, с поддержкой 90% семантики за месяц. С кучей нюансов, да. И говорить, что эти идиоты писали свой годами. Что тоже будет некорректно.
Впрочем, в том месте я имел в виду, что мне всё равно, что моя программа корректно скомпилится на 90% или на 40%. Она всё равно не запустится.
Я утверждал, что судить о сложности проекта по количеству строк — бред
Нет, не бред. Только это работает только в одну сторону. Много строк не означает сложность проекта. Но сложный проект обязательно имеет много строк.
потому что разные языки обладают разной выразительной силой
Не в 10 раз никак.
я уже привёл в виде измеримых критериев: объём кода
Я утверждал, что судить о сложности проекта по количеству строк — бред
Определитесь.
Потому что остальные ещё хуже [по совокупности доступных критериев]. Неважно, на самом деле, является ли инструмент «плохим» или «хорошим».
Циркулярка может пилить доски вдоль. Торцовочная - только поперёк. Остальные ваши рассуждения про "пересекающиеся области" смысла не имеют.
А к чему эти слова были написаны?
Потому что мне надоела демагогия и манипуляция.
Вы пользовались отрицаниемвашего утверждения для вывода, что критика инструментов, могущих нанести много вреда долбоёбу — плохая идея.
Нет. I said what I said. Я сказал, что ваше утверждение ошибочно.
Собрать все ошибки, если есть хоть одна, выразить семантику «либо ошибка, либо коммент», и ещё ряд пунктов по списку. Мне его сюда закопипастить?
Нет таких задач. У ПО есть всего две задачи: делать то, что требуется и не делать то, что не требуется. Выражать какую-либо семантику - это уже мой инструментарий, через который я делаю эти две задачи.
И у вас там в голове ничего не щёлкнуло, когда это писали, не? No bells ringing? Нормально вообще требовать семантики хаскеля от кода на шарпе?
И я не вижу ваших проектов. Ни гитхаба ни продуктов в паблике. И у меня возникает интересный вопрос.
Вы делаете вывод, что до дописывания до 100% сравнивать нельзя.
Правильно. А ещё я объяснил, почему. Это я ещё не касался других параметров. Скажем так, одну и ту же работу можно сделать множеством способов и помимо очевидного процента разборки токенов есть ещё сотни нюансов.
Начнём с того, что это не соответствует действительности: в компиляторах есть известные баги, компиляторы известно реализуют стандарты/спеки не до конца
Я устал от демагогии. Речь шла про, цитирую " 90% набора в правильно исполняемый код ".
Вера в нахождении всё менее реалистичных и всё более неопровержимых причин.
Неопровержимих причин чтобы что? Не кажется, что уже далеко от изначальной темы отбились?
Возвращаю: я утверждал, что ООП нужен для управления сложностью. Вы утверждали, что ваш "большой" проект на 5к строк справляется без ООП. Я утверждаю, что проект на 5к строк не может считаться большим. Какая нахуй вера?
То, что я пишу - это вполне научные методы. Есть ваше утверждение, что ваш вариант лучше. Есть моё предположение, что возможно вы переоцениваете своё творение. Это ни разу не фантастика, а характерное когнитивное искажение разработчика. Мерить успешность в процентах ключевых слов - бред. При незаконченности обоих вариантов - тем более. Кстати, есть ещё третий вариант people forget exists. Но он вам тем более не понравится.
Мне не видно, я её для выпиливания плинтусов купил вообще и не шарю, но неважно.
Есть пересечение задач, которое может быть решено обоими видами пил. На этом пересечении эти вещи вполне можно сравнивать.
Мне опять придётся к теме возвращать? Речь была про то, что "инструмент, который может отпилить пальцы - плохой инструмет". Так чтож вы плохим инструментом-то пользуетесь?
Можно же, ну я не знаю, хлебным ножиком плинтуса пилить. Пальцы не пострадают.
Окей, справедливо. Переформулирую в ваших терминах: язык C++ не позволяет управлять сложностью потому, что там компилятор жрёт много памяти и компилирует долго. Правильно, да?
Неправильно. Опять демагогия. Опять манипуляции. Ненавижу этот манипулятивный приём, когда собеседник берёт мои слова и начинает искажать, гиперболизируя. Или, например, инвертируя, как было с инструментами:
Из этого не следует, что любой инструмент, могущий нанести много вреда долбоёбу, заведомо более мощный.
Отличный вывод, да? А я что, говорил, что следует?
Наоборот, это значит, что с точки зрения управления сложностью (типы — они для этого) сишарп в этом аспекте хуже.
Шарп - статически типизированный язык. У него всё нормально с типами. Они есть, они проверяются на этапе компиляции и всевозможные чекеры работают в реалтайме, пока пишешь код.
Но у вас и задача до конца не решена.
Решена. Метод вызывается? Ошибки ловятся? Дерево обходится? Чего ещё надо?
Хватит уже. Я не школьник и не на олимпиаде. Ваша сраная задачка вообще ничего не говорит ни об ФП, ни о том, что вы умеете делать. Что действительно может показать - ваш готовый продукт. Talk is cheap. Show me your code.
Смотря какая задача. Мы, было дело, переписали 15 мегабайт исходного кода на C++ в 250 килобайт на Scheme
У нас сейчас давно контекст про шарп, который мультипарадигменный, с элементами функциональщины и без темплейтов. Это совсем не то же самое, что раздутые кресты.
Думать в начале разработки - сложно, дорого и потому не поощряется. А ООП позволяет быстро получить прототип говнокода.
Думать приходится везде и на любом этапе. Я видел много проектов, которые просто умирали под тяжестью техдолга в определённый этап своего развития. Просто не были готовы к взрывному росту сложности.
То, что в начале предпочитают из говна и палок собирать - это логично. Нужно обогнать конкурентов и проверить идею. В этом нет ничего странного.
их сравнивать нельзя. Надо починить 100%, и потом сравнивать.
Вот эта часть правильная. Делать выводы, что программисты - негодные неправильно. Делать выводы что компилятор не понимающий 100% - негодный правильно. В чём разница? Компилятор может быть дописан, программист - нет.
Как я и говорил выше, это для вас вопрос веры: вы, «не зная книг по которым я учился», делаете выводы.
Это не вопрос веры. Я сказал "возможно в варианте В были решены более сложные задачи". Где здесь вера? Это за что меня в религию записывают?
То, о чём я говорю, называется допущение. Я его привёл, чтобы доказать, что вывод "90% поддержки конструкций всегда больше 40%". Это не так, области могут быть разными, вес у задач разный.
то я предпочитаю miter saw
Торцовочная пила. У неё другие задачи, как видно из названия. Циркулярки тоже, кстати, современные с защитой. Они тоже бывают стационарными, как торцовочная и ручными.
И судить о готовности языка к проду по скорости компиляции и потреблению памяти — плохая идея.
Во-первых я так не делал. Я говорил про управление сложностью. Слов "не готов" я не писал.
Пишешь код, а тебе сразу красным подчёркивается, где ты неправ
А что, бывает иначе?
Когда у вас там в сишарпе тайпчекер будет такой же, как в хаскеле
В шарпе не будет никогда такого же тайпчекера. Потому что шарп - не хаскель. Это не значит, что его там нет или что он хуже.
10 строк неподдерживаемого кода вместо одной.
Это сугубо ваше личное мнение, не совпадающее с реальностью. Потому что, во-первых, у меня не 10 строк обхода дерева. Во-вторых у вас не одна строка. В третих, узкую академическую задачу экстраполировать на весь проект идите пожалуйста на xkcd.
Если реализация A компилирует, скажем, 90% набора в правильно исполняемый код, а реализация B — 40%
То обе не годятся и сравнивать их бесполезно.
Возможно в варианте B намного более сложные задачи решены. Вот пусть и там и там будет 100%, тогда можно сравнивать.
Я тоже не люблю го.
Я не про то. Циркулярка может отпилить пальцы. Болгарка вообще может порвать лицо, если туда поставить диск по дереву. Ну ты же сам дурак, что туда диск поставил не тот. Сам дурак что пальцы сунул. Инструменты-то хорошие. Что самое странное (нет), чем мощнее инструмент, тем больше вреда он может долбоёбу нанести. Поэтому логика "инструмент, которым можно отрезать пальцы - плохой инструмент" - некорректная в самой своей основе. Некоторые люди умудряются стеклянный предмет разбить и пальцы порезать. Стекло плохое?
У меня всё больше впечатление, что вы не знаете, о чём говорите.
У меня впечатление, что вам тяжело не переходить на личности. Держитесь, я верю. Ghc очень долго компилирует и жрёт много памяти. Я такую информацию слышал. Может просто я привык к дотнету, где всё практически моментально. Может стоило сказать, что ghc нормальный, а компилятор в dotnet - отличный. Да?
Как в том анекдоте "а зачем нам весь этот тюнинг в зоопарке?". Ну серьёзно, вот посмотрите на уровень, за который то и то отвечает. Вот зачем нужна беготня по деревьям, когда нет гуя? Ну допустим, в паре мест бы пригодилось. Но я и так дерево обойду, чай не на брейнфаке. А без хорошего гуя... ой, всё
Мне скоро спать пора, а как я уснуть смогу, не зная, что там за объяснение такое?
Ну ок. Надо же человека отпустить спать. Ваше представление о сопоставимости результата может сильно отличаться от реального. Утверждать не буду, надо знать детали.
Если инструмент устроен так, что им легко отрезать себе пальцы, то это плохой инструмент.
Нет. Это ошибочная логика. Впрочем на вкус и цвет. Гугл создал Го, в котором не разгуляешься и не выстрелишь себе в ногу. Но в этом же его беда. Впрочем, гуглу виднее - наверное так быстрее набирать кодеров.
Потому что ведь нельзя, чтобы просто в типах всё было видно, да?
Инструментарий - это не только типы и конструкции языка. Это дебаггер, компилятор, это выбор гуя. Со всеми этими пунктами у хаскеля плохо. Например, авалонии там нет и скорее всего никогда не завезут. ВПФ, Блейзор - это тоже инструменты для всего того же. Хотрелоад не то же самое, что mvvm. Однако и то и другое - инструменты управления сложностью. Как тёплое и мягкое - это комфорт.
А я смотрю на свой проект, где 5к делало больше, чем несколько десятков к соседней команды. И? Какой вывод?
Пример худшего - плохой вариант. У меня есть ещё одно объяснение, но оно вам не понравится. Я промолчу, потому что не знаю деталей.
Если под «традиционным ООП» понимать «нафигачили паттернов по книжкам, в итоге вообще ничего не понятно», то да, с таким я встречался.
Пример худшего - плохой пример. ООП - инструмент. Им можно хорошо уметь пользоваться, можно пользоваться во вред себе.
Если чуть серьёзнее, то разгадка одна: на мейнстримных императивных языках можно быстрее выдать что-то, как-то более-менее работающее.
Говорите, как будто это что-то плохое. Впрочем, я понимаю, что подразумевается. Подразумевается, что с возрастанием сложности ФП будет в выигрыше. Отвечаю: нет, не будет. У чистого ФП гораздо хуже инструментарий управления сложностью.
Кстати, это больше подошло бы для языков вроде js, python, или даже php. Там низкий порог входа за счёт отсутствия ограничений по типам, необязательного структурирования данных. Что вижу - о том и пою. Шарп, java - это языки другой весовой категории, где есть продвинутый инструментарий для управления сложностью. С более высоким порогом входа. Кресты отдельно - их вообще никто до конца не понимает.
Почему? Практика показывает, что это достаточно точная оценка.
Потому что 5 и 50 - это цифры разного порядка. Я смотрю сейчас на свой проект. Вот основная часть, где 36к без тестов. Вы её никогда в жизни не уложите в 3600 строк. Никак. Ни на каком языке. Оговорка: без применения грязных хаков, вроде стекования операторов до двухтысячной позиции.
Там слишком много нюансов, слишком много всего, чего нужно предусмотреть. Это сложно объяснить на словах.
И нет, ФП - это не волшебная таблетка, которая может драматически снизить сложность проекта. Иначе мы бы видели засилие ФП в больших и сверхбольших проектах. А там традиционно ООП.
По причинам несоответствия этого утверждения объективной реальности, или потому, что звучит неприятно?
Потому что это характеристика личных качеств людей, работающих в парадигме ООП. Кстати, в принципе некорректная, вы никак не можете говорить про всех. Равно как и пример про кошечек и собачек. Вам откуда знать, по каким книгам я учился?
я вообще так-то матершинник, вырос на двач-adjacent-культуре
Если в тексте хуй пизда и джигурда, я тоже не буду оскорбляться. Хотя про джигурду я чот перегнул...
Мы начали с того, что 5к строк проекта - это маленький проект. Собственно, на этом и остановились.
То, что ваш проект на 5к строк хоть немного близок по объёму к моему на 50к - это, мягко говоря, неправда. А в контексте управления сложностью объём проекта - это ключевой параметр. Без объёма никакого управления сложностью и не нужно. Крохотные скрипты на 500 строк вполне обходятся и без ORM и без ООП и даже без статической типизации. Это всё инструменты, которые начинают работать позже.
Я вот читаю весь этот снисходительный пафос и не пойму... А где решение в 10 раз короче? То, что я написал - работает.
То, что там именно сообщения вылавливаются, без типов ошибки, так извините, это я так понял. Так объяснено было. Можно и с типом ошибки отлавливать, вообще никаких вопросов. Вместо string будет Exception. И что?
Я напомню, этот пример специально для haskell. У вас loadComments использует готовые структуры языка/библиотек и выдаёт данные, подогнанные к условиям задачи.
В ООП вообще не принято думать в терминах действий
Вот так говорить вообще не надо. Это в крайней степени некорректно. И говорит разве что о вас и вашем восприятии.
Делать выводы по оторванному от реальности куску кода - это какая-то специальная олимпиада. Нет, серьёзно. Это действительно похоже на какую-то олимпиаду, когда люди соревнуются в написании куска кода по условиям задачи.
Читать Func<int, List<int>, string> тем более легче, чем Int → [Int] → String — заодно глаза тренируются скобочки
Это тоже некрасивый приём. В моём коде таких конструкций нет. Вы её сами продумали.
Я вижу, что чьё-то самолюбие задето. Настолько, что потребовалось вот как-то доказать превосходство хаскеля над шарпом. Самоутвердиться так сказать. Причём не самыми адекватными способами.
книги по ООП учат разделять кошечек, собачек, квадратики и прямоугольнички
Вот это мне вообще не понравилось. Прямо какой-то дон в белом плаще смотрит, как там крестьяне палкой землю ковыряют.
Я сейчас вот что сделаю. Просто сверну разговор и на этом закончим. У меня нет никакого желания дальше его продолжать. Уж очень токсично получается.
Я вернусь в свой несовершенный мир, где есть гуй авалонии, есть разор пейджес и буду дальше писать свой несовершенный продукт. А вы пойдёте своим путём и будете писать свои небольшие, но совершенные проекты. Идёт?
Это чтобы потом вместо того, чтоб просто посмотреть на тип функции, ходить спрашивать «а что функция кидает?», как вы уже сделали выше?
Современные IDE показывают, какие эксепшены может кинуть та или иная функция. В каких-то языках в комментах пишут. В java принудительно нужно указывать в сигнатуре, какие эксепшены можешь кинуть.
А тут вам в условии дали фору: сигнатуру можете выбрать как вам удобнее.
Окей, я выбираю сигнатуру LoadComment(ref Node node). Тогда всё сведётся к одному рекурсивному вызову.
Окей, хорошо. Пусть там на входе айди, пусть на выходе коммент. Иногда эксепшен. Перехватываем только NotFound, оставльные прокидываем наверх. Допустим. Хотя нет. Тогда смысла нет сохранять текст ошибки. Будем все ловить.
class Node
{
public int id;
public string? comment;
public string? error;
public List<Node> children = new();
void LoadComments(Node node, Func<int, string> loadComment)
{
try { node.comment = loadComment(node.id); }
catch (Exception ex) { node.error = ex.Message; }
foreach (var child in node.children)
LoadComments(child, loadComment);
}
}
Вот собственно структура с рекурсивным методом загрузки
Всмысле перевести? Мне функцию дали. По условию. Где сигнатура?
Если по своему, то во-первых, возвращение NetworkError - чушь собачья. При живых эксепшенах.
Во-вторых, запрос коммента по сети по одному - чушь собачья. В реальных системах так не делается. Либо по айди объекта выгребают пачкой из базы, либо по "IN" в случае если нужно несколько объектов, где каждому нужен например последний коммент.
В третьих, эксепшены всегда разделяются на критичные и некритичные. Если критичный, то дальше смысла нет. Например ошибка кредов - вот зачем дальше выбирать эти комменты? Такие пробрасываются наверх, а не отдаются.
Как выражается «либо» в шарпе идиоматически
Никак. Это не хаскель.
И шарп статически типизированный. Там нельзя инт поменять на коммент.
Вы по кругу просто ходите, что ли? Сигнатуру я уже тоже выше писал:
Я на шарпе пишу, нахер мне сигнатура хаскеля?
Не понял. Кто запретил?
У шарпа есть тип возвращаемого значения. Входит в сигнатуру функции. Там ещё входные параметры, но допустим на входе int id. Какой тип возвращаемого значения?
Которая при этом была цветной. С ограничениями, но цветной. Что обеспечивало бюджет в 10,12 тактов на байт экрана в кадр. Для сравнения, у атари будет примерно 2,31 такта на байт экрана (с цветом). Или 4.6 для монохрома, но там у спектрума будет почти 15. Потому что тактов меньше, а экран в байтах больше.
Вот этот факт, вместе с неприлично низкой ценой спектрума и возможность грузиться с кассеты и сделали его популярным.
Нет. Я когда руководствовался принципом "джентельменам верят на слово", почему-то джентельменам сразу карта пёрла. А мне нет.
Опять ложь. "В данном случае" касалось аггрегирования списка и контекст был там.
Вот это я говорил.
А это - нет.
Я больше не хочу говорить с человеком, перевирающим мои слова на каждый аргумент. С человеком, который не понимает мои аргументы и продолжает настаивать на своём.
Исходный код ваш мне нужен был, чтобы понять, с кем я вообще спорю. Потому что в интернете много неопытных теоретиков, не видевших в глаза проектов больше 10к строк. Какой смысл мне с такими спорить о методах управления сложностью?
Ложь.
Ложь.
Ложь.
Ложь.
Я откровенно устал указывать на ложь. В каждом сообщении. Ложь, манипуляции, демагогия. Никакой конструктивности. Так что я сворачиваюсь. Мы похоже на разных языках говорим.
Ну и анекдот
Степени оптимизации, разворачивание циклов, поддержка разных типов архитектур, всяких версий наборов sse/avx, скорость компиляции, кроссплатформенность, логгирование. Я не разбираюсь в компиляторах, никогда не писал, но это список навскидку.
Разница в том, что проценты поддержки семантики нельзя сравнивать напрямую. Я, к примеру, могу написать компилятор, с поддержкой 90% семантики за месяц. С кучей нюансов, да. И говорить, что эти идиоты писали свой годами. Что тоже будет некорректно.
Впрочем, в том месте я имел в виду, что мне всё равно, что моя программа корректно скомпилится на 90% или на 40%. Она всё равно не запустится.
Нет, не бред. Только это работает только в одну сторону. Много строк не означает сложность проекта. Но сложный проект обязательно имеет много строк.
Не в 10 раз никак.
Определитесь.
Циркулярка может пилить доски вдоль. Торцовочная - только поперёк. Остальные ваши рассуждения про "пересекающиеся области" смысла не имеют.
Потому что мне надоела демагогия и манипуляция.
Нет. I said what I said. Я сказал, что ваше утверждение ошибочно.
Нет таких задач. У ПО есть всего две задачи: делать то, что требуется и не делать то, что не требуется. Выражать какую-либо семантику - это уже мой инструментарий, через который я делаю эти две задачи.
И у вас там в голове ничего не щёлкнуло, когда это писали, не? No bells ringing? Нормально вообще требовать семантики хаскеля от кода на шарпе?
И я не вижу ваших проектов. Ни гитхаба ни продуктов в паблике. И у меня возникает интересный вопрос.
"The"
И этот тоже. Я об этом прямо сказал.
Правильно. А ещё я объяснил, почему. Это я ещё не касался других параметров. Скажем так, одну и ту же работу можно сделать множеством способов и помимо очевидного процента разборки токенов есть ещё сотни нюансов.
Я устал от демагогии. Речь шла про, цитирую " 90% набора в правильно исполняемый код ".
Неопровержимих причин чтобы что? Не кажется, что уже далеко от изначальной темы отбились?
Возвращаю: я утверждал, что ООП нужен для управления сложностью. Вы утверждали, что ваш "большой" проект на 5к строк справляется без ООП. Я утверждаю, что проект на 5к строк не может считаться большим. Какая нахуй вера?
То, что я пишу - это вполне научные методы. Есть ваше утверждение, что ваш вариант лучше. Есть моё предположение, что возможно вы переоцениваете своё творение. Это ни разу не фантастика, а характерное когнитивное искажение разработчика. Мерить успешность в процентах ключевых слов - бред. При незаконченности обоих вариантов - тем более. Кстати, есть ещё третий вариант people forget exists. Но он вам тем более не понравится.
Мне опять придётся к теме возвращать? Речь была про то, что "инструмент, который может отпилить пальцы - плохой инструмет". Так чтож вы плохим инструментом-то пользуетесь?
Можно же, ну я не знаю, хлебным ножиком плинтуса пилить. Пальцы не пострадают.
Неправильно. Опять демагогия. Опять манипуляции. Ненавижу этот манипулятивный приём, когда собеседник берёт мои слова и начинает искажать, гиперболизируя. Или, например, инвертируя, как было с инструментами:
Отличный вывод, да? А я что, говорил, что следует?
Шарп - статически типизированный язык. У него всё нормально с типами. Они есть, они проверяются на этапе компиляции и всевозможные чекеры работают в реалтайме, пока пишешь код.
Решена. Метод вызывается? Ошибки ловятся? Дерево обходится? Чего ещё надо?
Хватит уже. Я не школьник и не на олимпиаде. Ваша сраная задачка вообще ничего не говорит ни об ФП, ни о том, что вы умеете делать. Что действительно может показать - ваш готовый продукт. Talk is cheap. Show me your code.
У нас сейчас давно контекст про шарп, который мультипарадигменный, с элементами функциональщины и без темплейтов. Это совсем не то же самое, что раздутые кресты.
Думать приходится везде и на любом этапе. Я видел много проектов, которые просто умирали под тяжестью техдолга в определённый этап своего развития. Просто не были готовы к взрывному росту сложности.
То, что в начале предпочитают из говна и палок собирать - это логично. Нужно обогнать конкурентов и проверить идею. В этом нет ничего странного.
Вот эта часть правильная. Делать выводы, что программисты - негодные неправильно. Делать выводы что компилятор не понимающий 100% - негодный правильно. В чём разница? Компилятор может быть дописан, программист - нет.
Это не вопрос веры. Я сказал "возможно в варианте В были решены более сложные задачи". Где здесь вера? Это за что меня в религию записывают?
То, о чём я говорю, называется допущение. Я его привёл, чтобы доказать, что вывод "90% поддержки конструкций всегда больше 40%". Это не так, области могут быть разными, вес у задач разный.
Торцовочная пила. У неё другие задачи, как видно из названия. Циркулярки тоже, кстати, современные с защитой. Они тоже бывают стационарными, как торцовочная и ручными.
Во-первых я так не делал. Я говорил про управление сложностью. Слов "не готов" я не писал.
А что, бывает иначе?
В шарпе не будет никогда такого же тайпчекера. Потому что шарп - не хаскель. Это не значит, что его там нет или что он хуже.
Это сугубо ваше личное мнение, не совпадающее с реальностью. Потому что, во-первых, у меня не 10 строк обхода дерева. Во-вторых у вас не одна строка. В третих, узкую академическую задачу экстраполировать на весь проект идите пожалуйста на xkcd.
То обе не годятся и сравнивать их бесполезно.
Возможно в варианте B намного более сложные задачи решены. Вот пусть и там и там будет 100%, тогда можно сравнивать.
Я не про то. Циркулярка может отпилить пальцы. Болгарка вообще может порвать лицо, если туда поставить диск по дереву. Ну ты же сам дурак, что туда диск поставил не тот. Сам дурак что пальцы сунул. Инструменты-то хорошие. Что самое странное (нет), чем мощнее инструмент, тем больше вреда он может долбоёбу нанести. Поэтому логика "инструмент, которым можно отрезать пальцы - плохой инструмент" - некорректная в самой своей основе. Некоторые люди умудряются стеклянный предмет разбить и пальцы порезать. Стекло плохое?
У меня впечатление, что вам тяжело не переходить на личности. Держитесь, я верю. Ghc очень долго компилирует и жрёт много памяти. Я такую информацию слышал. Может просто я привык к дотнету, где всё практически моментально. Может стоило сказать, что ghc нормальный, а компилятор в dotnet - отличный. Да?
Как в том анекдоте "а зачем нам весь этот тюнинг в зоопарке?". Ну серьёзно, вот посмотрите на уровень, за который то и то отвечает. Вот зачем нужна беготня по деревьям, когда нет гуя? Ну допустим, в паре мест бы пригодилось. Но я и так дерево обойду, чай не на брейнфаке. А без хорошего гуя... ой, всё
Ну ок. Надо же человека отпустить спать. Ваше представление о сопоставимости результата может сильно отличаться от реального. Утверждать не буду, надо знать детали.
Нет. Это ошибочная логика. Впрочем на вкус и цвет. Гугл создал Го, в котором не разгуляешься и не выстрелишь себе в ногу. Но в этом же его беда. Впрочем, гуглу виднее - наверное так быстрее набирать кодеров.
Инструментарий - это не только типы и конструкции языка. Это дебаггер, компилятор, это выбор гуя. Со всеми этими пунктами у хаскеля плохо. Например, авалонии там нет и скорее всего никогда не завезут. ВПФ, Блейзор - это тоже инструменты для всего того же. Хотрелоад не то же самое, что mvvm. Однако и то и другое - инструменты управления сложностью. Как тёплое и мягкое - это комфорт.
Пример худшего - плохой вариант. У меня есть ещё одно объяснение, но оно вам не понравится. Я промолчу, потому что не знаю деталей.
Пример худшего - плохой пример. ООП - инструмент. Им можно хорошо уметь пользоваться, можно пользоваться во вред себе.
Говорите, как будто это что-то плохое. Впрочем, я понимаю, что подразумевается. Подразумевается, что с возрастанием сложности ФП будет в выигрыше. Отвечаю: нет, не будет. У чистого ФП гораздо хуже инструментарий управления сложностью.
Кстати, это больше подошло бы для языков вроде js, python, или даже php. Там низкий порог входа за счёт отсутствия ограничений по типам, необязательного структурирования данных. Что вижу - о том и пою. Шарп, java - это языки другой весовой категории, где есть продвинутый инструментарий для управления сложностью. С более высоким порогом входа. Кресты отдельно - их вообще никто до конца не понимает.
Потому что 5 и 50 - это цифры разного порядка. Я смотрю сейчас на свой проект. Вот основная часть, где 36к без тестов. Вы её никогда в жизни не уложите в 3600 строк. Никак. Ни на каком языке. Оговорка: без применения грязных хаков, вроде стекования операторов до двухтысячной позиции.
Там слишком много нюансов, слишком много всего, чего нужно предусмотреть. Это сложно объяснить на словах.
И нет, ФП - это не волшебная таблетка, которая может драматически снизить сложность проекта. Иначе мы бы видели засилие ФП в больших и сверхбольших проектах. А там традиционно ООП.
Потому что это характеристика личных качеств людей, работающих в парадигме ООП. Кстати, в принципе некорректная, вы никак не можете говорить про всех. Равно как и пример про кошечек и собачек. Вам откуда знать, по каким книгам я учился?
Если в тексте хуй пизда и джигурда, я тоже не буду оскорбляться. Хотя про джигурду я чот перегнул...
Мы начали с того, что 5к строк проекта - это маленький проект. Собственно, на этом и остановились.
То, что ваш проект на 5к строк хоть немного близок по объёму к моему на 50к - это, мягко говоря, неправда. А в контексте управления сложностью объём проекта - это ключевой параметр. Без объёма никакого управления сложностью и не нужно. Крохотные скрипты на 500 строк вполне обходятся и без ORM и без ООП и даже без статической типизации. Это всё инструменты, которые начинают работать позже.
Я вот читаю весь этот снисходительный пафос и не пойму... А где решение в 10 раз короче? То, что я написал - работает.
То, что там именно сообщения вылавливаются, без типов ошибки, так извините, это я так понял. Так объяснено было. Можно и с типом ошибки отлавливать, вообще никаких вопросов. Вместо string будет Exception. И что?
Я напомню, этот пример специально для haskell. У вас loadComments использует готовые структуры языка/библиотек и выдаёт данные, подогнанные к условиям задачи.
Вот так говорить вообще не надо. Это в крайней степени некорректно. И говорит разве что о вас и вашем восприятии.
Делать выводы по оторванному от реальности куску кода - это какая-то специальная олимпиада. Нет, серьёзно. Это действительно похоже на какую-то олимпиаду, когда люди соревнуются в написании куска кода по условиям задачи.
Это тоже некрасивый приём. В моём коде таких конструкций нет. Вы её сами продумали.
Я вижу, что чьё-то самолюбие задето. Настолько, что потребовалось вот как-то доказать превосходство хаскеля над шарпом. Самоутвердиться так сказать. Причём не самыми адекватными способами.
Вот это мне вообще не понравилось. Прямо какой-то дон в белом плаще смотрит, как там крестьяне палкой землю ковыряют.
Я сейчас вот что сделаю. Просто сверну разговор и на этом закончим. У меня нет никакого желания дальше его продолжать. Уж очень токсично получается.
Я вернусь в свой несовершенный мир, где есть гуй авалонии, есть разор пейджес и буду дальше писать свой несовершенный продукт. А вы пойдёте своим путём и будете писать свои небольшие, но совершенные проекты. Идёт?
Современные IDE показывают, какие эксепшены может кинуть та или иная функция. В каких-то языках в комментах пишут. В java принудительно нужно указывать в сигнатуре, какие эксепшены можешь кинуть.
Окей, я выбираю сигнатуру LoadComment(ref Node node). Тогда всё сведётся к одному рекурсивному вызову.
Окей, хорошо. Пусть там на входе айди, пусть на выходе коммент. Иногда эксепшен. Перехватываем только NotFound, оставльные прокидываем наверх. Допустим. Хотя нет. Тогда смысла нет сохранять текст ошибки. Будем все ловить.
Вот собственно структура с рекурсивным методом загрузки
Всмысле перевести? Мне функцию дали. По условию. Где сигнатура?
Если по своему, то во-первых, возвращение NetworkError - чушь собачья. При живых эксепшенах.
Во-вторых, запрос коммента по сети по одному - чушь собачья. В реальных системах так не делается. Либо по айди объекта выгребают пачкой из базы, либо по "IN" в случае если нужно несколько объектов, где каждому нужен например последний коммент.
В третьих, эксепшены всегда разделяются на критичные и некритичные. Если критичный, то дальше смысла нет. Например ошибка кредов - вот зачем дальше выбирать эти комменты? Такие пробрасываются наверх, а не отдаются.
Никак. Это не хаскель.
И шарп статически типизированный. Там нельзя инт поменять на коммент.
Я на шарпе пишу, нахер мне сигнатура хаскеля?
У шарпа есть тип возвращаемого значения. Входит в сигнатуру функции. Там ещё входные параметры, но допустим на входе int id. Какой тип возвращаемого значения?
Сигнатура какая у функции?
Чтобы два раза не вставать. Int нельзя заменить на строку. И на Comment тоже.