Если бы всё в статье было правдой, то ёмкостей для перевозки газов под давлением не существовало бы (энергия связи там ещё меньше, чем в жидкости, а размер атома \ молекулы не больше).
Так что содержание поста не научпоп даже, а .... не знаю как назвать откровенно плохой научпоп? Анти-научпоп?
Я сравниваю один язык, при условии одинаковости написания: - полноценный фронтэнд && полноценный бэкэнд - неполноценный фронтэнд && неполноценный бэкэнд.
Рассмотрим С: если реализовывать полностью - ок отлично полностью реализуем фронт (судя по написанному вы аккуратно и полностью делали - честь вам и хвала), но тогда будте добры бэк тоже напишите как минимум полностью (оптимизации - желательно). И тут выплывет, что поддержать ELF && (частично) IA-32 это 5 книг K&R по объёму.
Рассмотрим Haskell: ghc-фронтэнд llvm-бэкэнд. LLVM - в 9 раз больше чем ghc. (там в LLVM много лишнего, но в репозитории ghc тоже много лишнего - например селф-хостед компилятор для сбора с 0, игрушечный бэкэнд вроде до сих пор лежи и ещё много чего)
ПС Мне вот кажется, что вы фронт делали аккуратно, полностью, а бэкэнд - всегда или игрушечный (неправильный неполный) или LLVM звали. Отсюда превратное отношение и кардинальная недооценка объёма и сложности задачи.
Терминологически: Бэкэнд (а в LLVM это вообще будет middle-end + back-end). Просто в игрушечных \ учебных проектах он может выродиться в в одну лишь кодогенерацию.
А кодогенерация становится очень сложной тогда, когда стоит задача оптимизировать код. Тупо нашлёпать машинных команд в духе макроассемблера – не представляет труда для си-подобного языка.
Если вы пишите правильный backend - вам надо учесть особенности архитектуры: переполнения, невыровненные обращения к памяти, поддержка FP-stack...
Если вы пишите полнофункциональный backend - вам надо учесть требования операционной системы: ELF, DWARF желательно (или что там в Win).
То есть более аккуратно ваше утверждение выглядит так: "сделать неправильный и неполный бэкэнд намного проще чем сделать корректный полноценный фронтэнд".
Ну ок. Только какой смысл в таком утверждении вообще? И к стати даже с ним я не согласен, если фронтэнд прям не индустриального качества.
Ну да натяпляпить бэкэнд с ошибками (см выше) - кажется не очень сложно. Но IA-32 машет вам ручкой - даже маленькое нужное вам подмножество IA-32 Intel Software Developer's manual потолще грамматики С или Pascal будет. В итоге мне кажется, что даже тяпляпный бэкэнд займёт у меня времени и LoC больше чем боле-менее аккуратный фронтэнд (при этом как писать бэкэнд я знаю, а фронтэнд - писал только игрушечный).
Но натяпляпить фронтэнд - тоже не rocket science, честно. Отделимый от парсера лексер (начиная с С++ плохо отделим но вы же сами C / Pascal задали), парсер рекурсивным спуском, типизатор паскалевского AST (без type coercion). Ну ок, а великая-то сложность в чём?
Помню, что нашли тогда одну синтаксическую неоднозначность в K&R C.
Круто. Вещь известная, но то, что вы её нашли - это говорит о том, что вы учились достаточно глубоко. { if (p1) if (p2) do_if(); else ... // is it "else" to outer if (p1) or to inner if (p2) ? }
Вообще, на мой взгляд, теория формальных грамматик – одна из самых сложных, если не самая сложная, вещь в теоретическом программировании. Наука о том, как цепочки символов порождают друг друга.
Это ваши философские воззрения (попытка объяснить на пальцах сложную тему, которая в результате приводит к оперированию неформальными и неизмеримыми величинами). Иметь личные философские воззрения часто субьективно полезно (позволяет как минимум "компактизировать" сложную тему в своей голове). Но объективная полезность - под вопросом.
В этом деле кодогенерация – фигня по сравнению с описанием порождающей грамматики и синтаксическим анализом, мы же не ставили целью получать глубоко оптимизированный код.
При хоть сколько-нибудь равных условиях кодогенерация сложнее. Мне совершенно непонятно как программист-практик (писавший ручками и то и другое в сравнимых условиях) может прийти к другому мнению.
Единственное объяснение - вы игнорируете объективные характеристики (например LoC) в угоду вашим филосовским воззрениям.
ПС (забавный факт: знаете что самое сложное в промышленном лексере-парсере, в терминах LoC? Сообщения об ошибках ).
Вообще то, что вы пишите - по-моему это ОЧЕНЬ круто для ВУЗа 20 лет назад. У нас, по моим воспоминаниям удавалось заставить работать студентов только по одному направлению (для нашей группы - программисты, для других - устройство ЭВМ, для третьих - ....). Потому, что мотивация основной массы, кроме гиков, была никакущей и ВУЗ был зажат между "вы обязаны отчитаться, что программа, вполне себе приличная и сложная программа, студентами пройдена" и "но отчислить хотя бы 50% вы не можете". Итог понятен - кратное опускание медианной планки, с попыткой держать её для предметов по специальности. У вас - видимо удалось "держать планку" в более широком диапазоне дисциплин, чем у нас.
Не я не хочу душнить, реально. По изначальному описанию - похоже на наше (нам тоже в универе давали намисать "глупый" игрушечный проект своими руками вместо пощупать модный фреймворк - но по прошествии лет оказалось, что это гораздо менее устаревающие и ИМХО более фундаментальные знания).
Но в этом кейсе - мы писали интерпретатор, а у вас (судя по *.com на выходе) задача намного сложнее. Прям интересно стало "как там у вас". Если помните и не влом - поясните пожалуйста.
1. На выходе *.com - значит не интерпретатор. 2. 20 лет назад - хм.. LLVM вроде бы ещё не было. 3. Единственное, что мне приходит в голову - это написать фронтэнд, а бэкэнд сделать на стэковой машине (вроде их выбирают в любительских проектах именно за простоту на начальных этапах).
э... планирование регистров и кодогенерация (очевидно, что это более трудоёмкая часть, фронтэнд для упрощённого подмножества паскаля - и ни о каком "средний студент за несколько дней справится тут и речи не идёт).
Или просто LLVM позвали? Но в случае вызова LLVM это же не "компилятор + линкер" это "парсер + фронтэнд".
курсовая... компилятор+линкер небольшого подмножества Паскаля, который на входе получал исходный код, а ны выходе давал исполнимый файл DOS.
...
про диплом даже писать нет смысла, ... я только на кодинг потратил часов 150.
Странно - выглядит так, будто курсовая была чуть не серьёзнее диплома. Не хочу придираться, но глаз зацепился. Задача выше - явно не меньше чем на 150 часов (тем более для студента) если делать хоть сколько-нибудь нормально.
Настолько неудачное сравнение насколько это вообще возможно. Любой конкретный инсталлер - прикладное знание.
В вашей аналогии - ВУЗ как раз даёт вам курс "как написать deployer", с написанием такового в конце в качестве курсовой. НО не знакомит ни с одной конкретной технологией.
IT-шника найти труднее. Цена замены IT-шника выше. ....
В итоге баланс "послать работника и уволить (для нас денежные затраты для него наука) / нянчиться с работником" - в IT смещён в сторону второго варианта.
"баланс спроса-предложения" - обычная бессмысленная в данном случае агитка. Неидеальные рынки, каковым является рынок рекламы и новостей в целом - могут быть улучшены при помощи регуляции. А иногда прямо требуют регуляции.
Есть эффективные (в идеале идеальные) рынки и неэффективные (неидеальные). На эффективных баланс спроса-предложения делает всем "хорошо" на неэффективных баланс спроса-предложения делаем потребителям "плохо".
Рынок рекламы - неидеальный. Источник неидеальности в нём - "third party effect", когда расходы несут не те кто учавствует в сделке, а те кто получил рекламу и не учавствует.
Неэффективные рынки можно улучшить извне (например регуляции) по заверениям самих же представителей Чикагской школы экономики. Хорошо или плохо повлияют изменения яндекса на неэффективный рынок новостей и рекламы - заранее неизвестно.
Сторонники "свободного рынка" - утверждают, что рынок достигает оптимума, если исключить некоторые факторы. Один из факторов - искажение или асимметрия информации.
В итоге пользователь не разбирается (почти ни в чём кроме 2-3 тем "работы" и "основного хобби") -- и издателю выгоднее гнать много низкокачественного контента.
Акт-2. Приходит яндекс, котоырый тоже не разбирается, но благодаря ML + большим данным может банить много низкокачественного контента. Т.е. "как бы" добавляет немного экспертизы каждому пользователю. После этого рынок остаётся, но становится ближе к неискажённому. (да одинаково квалифицированные покупатель и продавец - идеальный вариант. Но из неидеальных может статься что снабдить покупателя доп.машинкой для контроля качества будет хорошей идеей).
Он прямо ограничивает общую мощность, не трогая пиковую.
Но энергопотребление в современных процессорах пропорционально квадрату частоты. Следовательно если вы готовы к худшей производительности в пиковые моменты, то резать пиковую частоту разумно.
Я просто могу слушать аудиокниги (разумеется не особо сложные, желательно до 1000 lexile measure), но при попытке прослушать автосгенерированный по писанине текст - выпадаю в осадок.
Там где ухо ожидает "смысловой разметки паузами \ тонами" - её просто нет.
Я, наверное, неудачно выразился и взял слишком сложную задачу (т.е. мой запрос несравнимо сложнее чем "парсинг xml").
Вот смотрите@stvoid жалуется, что не может выбрать правильную библиотеку на Rust (не обладая достаточным опытом). Но это же не Rust-специфичная проблема. Пока не набрался опыта - подобрать правильную библиотеку одна из самых больших проблем в языке вообще.
Вот я, например, не обладаю опытом в Python, как мне выбрать библиотеку на Python (если в stdlib нет соответствующей библиотеке - тогда боле-менее понятно).
Если метод сделан достаточно аккуратно - то первое пересечение и есть оптимальный маршрут (эквилалентный тому, что ищет однонаправленный поиск).
Вероятно по каким-то техническим причинам - двунаправленный поиск сделан недостаточно аккуратно.
Если бы всё в статье было правдой, то ёмкостей для перевозки газов под давлением не существовало бы (энергия связи там ещё меньше, чем в жидкости, а размер атома \ молекулы не больше).
Так что содержание поста не научпоп даже, а .... не знаю как назвать откровенно плохой научпоп? Анти-научпоп?
Такого быть не должно, если алгоритм написан правильно.
Поиск от финиша проводится на обращённом графе.
Я сравниваю один язык, при условии одинаковости написания:
- полноценный фронтэнд && полноценный бэкэнд
- неполноценный фронтэнд && неполноценный бэкэнд.
Рассмотрим С: если реализовывать полностью - ок отлично полностью реализуем фронт (судя по написанному вы аккуратно и полностью делали - честь вам и хвала), но тогда будте добры бэк тоже напишите как минимум полностью (оптимизации - желательно). И тут выплывет, что поддержать ELF && (частично) IA-32 это 5 книг K&R по объёму.
Рассмотрим Haskell: ghc-фронтэнд llvm-бэкэнд. LLVM - в 9 раз больше чем ghc.
(там в LLVM много лишнего, но в репозитории ghc тоже много лишнего - например селф-хостед компилятор для сбора с 0, игрушечный бэкэнд вроде до сих пор лежи и ещё много чего)
ПС
Мне вот кажется, что вы фронт делали аккуратно, полностью, а бэкэнд - всегда или игрушечный (неправильный неполный) или LLVM звали. Отсюда превратное отношение и кардинальная недооценка объёма и сложности задачи.
Терминологически: Бэкэнд (а в LLVM это вообще будет middle-end + back-end). Просто в игрушечных \ учебных проектах он может выродиться в в одну лишь кодогенерацию.
Если вы пишите правильный backend - вам надо учесть особенности архитектуры: переполнения, невыровненные обращения к памяти, поддержка FP-stack...
Если вы пишите полнофункциональный backend - вам надо учесть требования операционной системы: ELF, DWARF желательно (или что там в Win).
То есть более аккуратно ваше утверждение выглядит так: "сделать неправильный и неполный бэкэнд намного проще чем сделать корректный полноценный фронтэнд".
Ну ок. Только какой смысл в таком утверждении вообще? И к стати даже с ним я не согласен, если фронтэнд прям не индустриального качества.
Ну да натяпляпить бэкэнд с ошибками (см выше) - кажется не очень сложно. Но IA-32 машет вам ручкой - даже маленькое нужное вам подмножество IA-32 Intel Software Developer's manual потолще грамматики С или Pascal будет. В итоге мне кажется, что даже тяпляпный бэкэнд займёт у меня времени и LoC больше чем боле-менее аккуратный фронтэнд (при этом как писать бэкэнд я знаю, а фронтэнд - писал только игрушечный).
Но натяпляпить фронтэнд - тоже не rocket science, честно. Отделимый от парсера лексер (начиная с С++ плохо отделим но вы же сами C / Pascal задали), парсер рекурсивным спуском, типизатор паскалевского AST (без type coercion). Ну ок, а великая-то сложность в чём?
Круто. Вещь известная, но то, что вы её нашли - это говорит о том, что вы учились достаточно глубоко.
{
if (p1)
if (p2) do_if();
else ... // is it "else" to outer if (p1) or to inner if (p2) ?}
Это ваши философские воззрения (попытка объяснить на пальцах сложную тему, которая в результате приводит к оперированию неформальными и неизмеримыми величинами). Иметь личные философские воззрения часто субьективно полезно (позволяет как минимум "компактизировать" сложную тему в своей голове). Но объективная полезность - под вопросом.
При хоть сколько-нибудь равных условиях кодогенерация сложнее. Мне совершенно непонятно как программист-практик (писавший ручками и то и другое в сравнимых условиях) может прийти к другому мнению.
Единственное объяснение - вы игнорируете объективные характеристики (например LoC) в угоду вашим филосовским воззрениям.
ПС
(забавный факт: знаете что самое сложное в промышленном лексере-парсере, в терминах LoC? Сообщения об ошибках ).
Спасибо.
Вообще то, что вы пишите - по-моему это ОЧЕНЬ круто для ВУЗа 20 лет назад. У нас, по моим воспоминаниям удавалось заставить работать студентов только по одному направлению (для нашей группы - программисты, для других - устройство ЭВМ, для третьих - ....).
Потому, что мотивация основной массы, кроме гиков, была никакущей и ВУЗ был зажат между "вы обязаны отчитаться, что программа, вполне себе приличная и сложная программа, студентами пройдена" и "но отчислить хотя бы 50% вы не можете". Итог понятен - кратное опускание медианной планки, с попыткой держать её для предметов по специальности. У вас - видимо удалось "держать планку" в более широком диапазоне дисциплин, чем у нас.
Если не секрет - что за ВУЗ?
Не я не хочу душнить, реально. По изначальному описанию - похоже на наше (нам тоже в универе давали намисать "глупый" игрушечный проект своими руками вместо пощупать модный фреймворк - но по прошествии лет оказалось, что это гораздо менее устаревающие и ИМХО более фундаментальные знания).
Но в этом кейсе - мы писали интерпретатор, а у вас (судя по *.com на выходе) задача намного сложнее. Прям интересно стало "как там у вас". Если помните и не влом - поясните пожалуйста.
1. На выходе *.com - значит не интерпретатор.
2. 20 лет назад - хм.. LLVM вроде бы ещё не было.
3. Единственное, что мне приходит в голову - это написать фронтэнд, а бэкэнд сделать на стэковой машине (вроде их выбирают в любительских проектах именно за простоту на начальных этапах).
э... планирование регистров и кодогенерация (очевидно, что это более трудоёмкая часть, фронтэнд для упрощённого подмножества паскаля - и ни о каком "средний студент за несколько дней справится тут и речи не идёт).
Или просто LLVM позвали?
Но в случае вызова LLVM это же не "компилятор + линкер" это "парсер + фронтэнд".
Странно - выглядит так, будто курсовая была чуть не серьёзнее диплома.
Не хочу придираться, но глаз зацепился.
Задача выше - явно не меньше чем на 150 часов (тем более для студента) если делать хоть сколько-нибудь нормально.
Настолько неудачное сравнение насколько это вообще возможно.
Любой конкретный инсталлер - прикладное знание.
В вашей аналогии - ВУЗ как раз даёт вам курс "как написать deployer", с написанием такового в конце в качестве курсовой.
НО не знакомит ни с одной конкретной технологией.
Мне кажется это называется "реактивный" с точки зрения задач проекта.
IT-шника найти труднее.
Цена замены IT-шника выше.
....
В итоге баланс "послать работника и уволить (для нас денежные затраты для него наука) / нянчиться с работником" - в IT смещён в сторону второго варианта.
"баланс спроса-предложения" - обычная бессмысленная в данном случае агитка.
Неидеальные рынки, каковым является рынок рекламы и новостей в целом - могут быть улучшены при помощи регуляции. А иногда прямо требуют регуляции.
Есть эффективные (в идеале идеальные) рынки и неэффективные (неидеальные). На эффективных баланс спроса-предложения делает всем "хорошо" на неэффективных баланс спроса-предложения делаем потребителям "плохо".
Рынок рекламы - неидеальный. Источник неидеальности в нём - "third party effect", когда расходы несут не те кто учавствует в сделке, а те кто получил рекламу и не учавствует.
Неэффективные рынки можно улучшить извне (например регуляции) по заверениям самих же представителей Чикагской школы экономики. Хорошо или плохо повлияют изменения яндекса на неэффективный рынок новостей и рекламы - заранее неизвестно.
Посмотрите на это с другой стороны.
Сторонники "свободного рынка" - утверждают, что рынок достигает оптимума, если исключить некоторые факторы. Один из факторов - искажение или асимметрия информации.
В итоге пользователь не разбирается (почти ни в чём кроме 2-3 тем "работы" и "основного хобби") -- и издателю выгоднее гнать много низкокачественного контента.
Акт-2.
Приходит яндекс, котоырый тоже не разбирается, но благодаря ML + большим данным может банить много низкокачественного контента. Т.е. "как бы" добавляет немного экспертизы каждому пользователю.
После этого рынок остаётся, но становится ближе к неискажённому. (да одинаково квалифицированные покупатель и продавец - идеальный вариант. Но из неидеальных может статься что снабдить покупателя доп.машинкой для контроля качества будет хорошей идеей).
3-5 лет назад заинтересовался и пришёл к следующим выводам:
Когда я ищу что-то по IT - выдача гугла лучше (помогает решить вопрос).
Когда я ищу что-то бытовое - выдача яндекса лучше.
Но энергопотребление в современных процессорах пропорционально квадрату частоты. Следовательно если вы готовы к худшей производительности в пиковые моменты, то резать пиковую частоту разумно.
Те термины, которые переведены в советских книгах уже стали классикой (термины обрусели).
Ну и качество перевода, в среднем, было куда выше. Больше тиражи, - а тиражи были выше на порядки, - постоянные издержки можно увеличить.
А какой тулзой озвучиваете?
Я просто могу слушать аудиокниги (разумеется не особо сложные, желательно до 1000 lexile measure), но при попытке прослушать автосгенерированный по писанине текст - выпадаю в осадок.
Там где ухо ожидает "смысловой разметки паузами \ тонами" - её просто нет.
Я, наверное, неудачно выразился и взял слишком сложную задачу (т.е. мой запрос несравнимо сложнее чем "парсинг xml").
Вот смотрите@stvoid жалуется, что не может выбрать правильную библиотеку на Rust (не обладая достаточным опытом).
Но это же не Rust-специфичная проблема. Пока не набрался опыта - подобрать правильную библиотеку одна из самых больших проблем в языке вообще.
Вот я, например, не обладаю опытом в Python, как мне выбрать библиотеку на Python (если в stdlib нет соответствующей библиотеке - тогда боле-менее понятно).