Эти исследования либо некорректны, либо врут, либо не существуют. В больших проектах код приходится чаще читать, чем писать. Буквально, на одну написанную строчку приходятся десятки, а то и сотни прочитанных строк. И чем больше проект - тем больше нужно читать, прежде чем что-то дописывать. А вот тут как раз все языки разные. У парадигм разные уровни абстракции.
Если брать целиком цикл "прочитать, подумать, дописать, отладить, написать тесты", то ни о каком равенстве речи быть не может. Тут даже c# и c# - это две большие разницы. ООП даёт инструменты для работы на верхних уровнях логики, чтобы не было необходимости читать каждую реализацию. Но это только инструменты, они сами по себе не работают. Нужно ими пользоваться.
А по каким критериям мне тогда можно отличать умных и опытных разработчиков вроде вас от обыкновенных интернет-пиздаболов?
Стоит ли мне верить на слово, что ваш компилятор в 5к строк оказался лучше компилятора на цпп в 10-15к строк (я ничего не перепутал?) и при этом написан всего одним человеком и быстрее?
Я вот что думаю. Есть такой инструмент - dBeaver. Там по осторожным прикидкам, не менее полумиллиона строк кода (лень считать, да). А у меня ormfactory - приложение того же класса с сопоставимой функциональностью, что и dbeaver. Могу ли я говорить, что шарп в десять раз компактнее джавы? Ой, у меня же 37к строк, значит в тринадцать с половиной.
Бред? Бред. Конечно, не могу. Тут каждый пункт "с натяжкой". Шарп "в целом по больнице" компактнее джавы, да. Возможно раза в полтора. Но не в разы.
С хаскелем также. С вашим примером также. Я готов поверить, что на больших проектах хаскель будет компактнее шарпа на процентов 10. 20 уже вряд ли. А потом я уже могу поговорить о том, что компактность ну вот ни разу не бесплатная. В данном случае компактность может легко привести к повышенным когнитивным расходам при работе с кодом. Что в данном случае лучше - я оставляю за рамками. Обычно ищут какую-то точку баланса исходя из своих обстоятельств. У Го баланс смещён в сторону недоверия разрабу, что явно выгодно при большой текучке.
Тем временем разговор скатился в говно и я даже не успеваю аргументировать каждую попытку манипуляции, не то, что даже добраться до реально полезной дискуссии. У вас нет необходимости пилить плинтуса вдоль, а про то, что циркулярка - это реально хороший инструмент и широко используется, вы не вспомнили. Я рад за вас. Но говорить надо по делу.
Ну как-бы атари не очень-то конкурировала со спектрумом. В той нише были Oric-1 и Atmos например. С тем же 6502 и без отдельного видеочипа, да. Только там с бюджетом тактов на экран ещё хуже.
Про видеочип согласен, он иногда вытягивает. Но только в скролле. Перерисовка экрана на 6502 - долго, мучительно, больно. Собственно, если не ошибаюсь, "элита" появилась только на atari st, которая на 68к. Совсем другой класс.
Так что я уверен, что такты сыграли свою роль. Спектрум просто быстрее может перерисовать графику на экране, может больше держать подвижных объектов. Собственно, характерная черта спектрумовских игр - переход от экрана к экрану вместо скролла. Вот так избавлялись от необходимости скроллить.
В демомейкинге бюджет тактов на кадр - это вот прямо очень важно было. И вот спектрум позволял делать 50fps анимации, правда с дикими ухищрениями, вроде использования push-команды (самый быстрый способ записать память - 11 тактов на слово, что давало 5,5 тактов на байт). Собственно, предгенерировали машкод, делали алгоритмы динамического вызова этих пушей, оставляли бюджет на музыку и вот получалась 50fps анимация на весь экран.
Что мне в 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 строк. Никак. Ни на каком языке. Оговорка: без применения грязных хаков, вроде стекования операторов до двухтысячной позиции.
Там слишком много нюансов, слишком много всего, чего нужно предусмотреть. Это сложно объяснить на словах.
И нет, ФП - это не волшебная таблетка, которая может драматически снизить сложность проекта. Иначе мы бы видели засилие ФП в больших и сверхбольших проектах. А там традиционно ООП.
Эти исследования либо некорректны, либо врут, либо не существуют. В больших проектах код приходится чаще читать, чем писать. Буквально, на одну написанную строчку приходятся десятки, а то и сотни прочитанных строк. И чем больше проект - тем больше нужно читать, прежде чем что-то дописывать. А вот тут как раз все языки разные. У парадигм разные уровни абстракции.
Если брать целиком цикл "прочитать, подумать, дописать, отладить, написать тесты", то ни о каком равенстве речи быть не может. Тут даже c# и c# - это две большие разницы. ООП даёт инструменты для работы на верхних уровнях логики, чтобы не было необходимости читать каждую реализацию. Но это только инструменты, они сами по себе не работают. Нужно ими пользоваться.
Речь о том, что данное утверждение было подтверждено только "собственным проектом", в мощь которого предлагается поверить на слово.
Мне ваши обороты не нравятся. Поэтому ещё минус в карму и мне вы больше не интересны.
Я начинаю понимать, почему у вас ноль кармы при двадцати плюсовых публикациях. Не надо так. Это очень агрессивно. Я и не утверждал, что
я прямо много знаю. Я знаю, что там 6502 и что там элиту не выпустили.
Я про атари говорил. Сначала выпустили на спектруме, потом - на атари ст.
На любителя или нет - это очень сильно сокращает работу с экраном. При недостатке процессорной мощности того времени это было важно.
Окей, но плюс отсутствия видеочипа на спекки - его отсутствие.
А по каким критериям мне тогда можно отличать умных и опытных разработчиков вроде вас от обыкновенных интернет-пиздаболов?
Стоит ли мне верить на слово, что ваш компилятор в 5к строк оказался лучше компилятора на цпп в 10-15к строк (я ничего не перепутал?) и при этом написан всего одним человеком и быстрее?
Я вот что думаю. Есть такой инструмент - dBeaver. Там по осторожным прикидкам, не менее полумиллиона строк кода (лень считать, да). А у меня ormfactory - приложение того же класса с сопоставимой функциональностью, что и dbeaver. Могу ли я говорить, что шарп в десять раз компактнее джавы? Ой, у меня же 37к строк, значит в тринадцать с половиной.
Бред? Бред. Конечно, не могу. Тут каждый пункт "с натяжкой". Шарп "в целом по больнице" компактнее джавы, да. Возможно раза в полтора. Но не в разы.
С хаскелем также. С вашим примером также. Я готов поверить, что на больших проектах хаскель будет компактнее шарпа на процентов 10. 20 уже вряд ли. А потом я уже могу поговорить о том, что компактность ну вот ни разу не бесплатная. В данном случае компактность может легко привести к повышенным когнитивным расходам при работе с кодом. Что в данном случае лучше - я оставляю за рамками. Обычно ищут какую-то точку баланса исходя из своих обстоятельств. У Го баланс смещён в сторону недоверия разрабу, что явно выгодно при большой текучке.
Тем временем разговор скатился в говно и я даже не успеваю аргументировать каждую попытку манипуляции, не то, что даже добраться до реально полезной дискуссии. У вас нет необходимости пилить плинтуса вдоль, а про то, что циркулярка - это реально хороший инструмент и широко используется, вы не вспомнили. Я рад за вас. Но говорить надо по делу.
Ну как-бы атари не очень-то конкурировала со спектрумом. В той нише были Oric-1 и Atmos например. С тем же 6502 и без отдельного видеочипа, да. Только там с бюджетом тактов на экран ещё хуже.
Про видеочип согласен, он иногда вытягивает. Но только в скролле. Перерисовка экрана на 6502 - долго, мучительно, больно. Собственно, если не ошибаюсь, "элита" появилась только на atari st, которая на 68к. Совсем другой класс.
Так что я уверен, что такты сыграли свою роль. Спектрум просто быстрее может перерисовать графику на экране, может больше держать подвижных объектов. Собственно, характерная черта спектрумовских игр - переход от экрана к экрану вместо скролла. Вот так избавлялись от необходимости скроллить.
В демомейкинге бюджет тактов на кадр - это вот прямо очень важно было. И вот спектрум позволял делать 50fps анимации, правда с дикими ухищрениями, вроде использования push-команды (самый быстрый способ записать память - 11 тактов на слово, что давало 5,5 тактов на байт). Собственно, предгенерировали машкод, делали алгоритмы динамического вызова этих пушей, оставляли бюджет на музыку и вот получалась 50fps анимация на весь экран.
Которая при этом была цветной. С ограничениями, но цветной. Что обеспечивало бюджет в 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 строк. Никак. Ни на каком языке. Оговорка: без применения грязных хаков, вроде стекования операторов до двухтысячной позиции.
Там слишком много нюансов, слишком много всего, чего нужно предусмотреть. Это сложно объяснить на словах.
И нет, ФП - это не волшебная таблетка, которая может драматически снизить сложность проекта. Иначе мы бы видели засилие ФП в больших и сверхбольших проектах. А там традиционно ООП.