LINUX.ORG.RU
ФорумTalks

Какая г.. эти ваша идеология рельсов

 


0

3

Разбираюсь с мегапоиложением - посмотрел там даже cron апдейтится через отдельную команду. Разработчик просто описывает необходимые крон задачи в виде красивого псевдокода - после командой генерится crontab файл. Причем я бы понял если бы ненерили отдельные cron файлы - но тут просто добавляется фактически в системный файл. Это нормально ?



Последнее исправление: Jopich1 (всего исправлений: 2)

Это обратная сторона DSL. Если DSL пишет псих, то остальным будет плохо.

dem ★★
()

В рельсах нет такой функциональности, это какая-то сторонняя библиотека.

Что мешает добавлять в крон что и как ты хочешь, а не использовать сторонюю библиотеку, которая предоставляет свой DSL и методы для описания крон-задач?

С таким же успехом можно называть GNU/Linux говном, ведь там есть systemd с бинарными логами и ZFS с кривой лицензией.

Предыдущему разработчику значит было так удобней почему-то. Можешь у него спросить почему.

Не нравится – не используй, отключи библиотеку и пиши задачи в крон руками.

Неосилятора-нытика тред детектед.

OSBuster
()
Последнее исправление: OSBuster (всего исправлений: 1)

Причем я бы понял если бы ненерили отдельные cron файлы - но тут просто добавляется фактически в системный файл. Это нормально ?

Нет, но рельсы тут ни при чём :-)

sT331h0rs3 ★★★★★
()
Ответ на: комментарий от ilinsky

должен же быть какой-то козел отпущения

RoR на эту роль отлично подходит:

  • Здесь нет рубистов, поэтому никто не вступится

  • Язык, который нигде вне RoR не используют

  • Фреймворк на идеологии предыдущего поколения, сейчас идеология фулл JS-фронтенда с серверным JSON API, максимум там есть прозрачный сервер сайд рендеринг и статик сайт генерация

  • Огромное количество шизиков, которые пользуются технологией которую нужно знать так, как будто этого не нужно (опять же несовпадение поколений - большинство мусора с npm знать не нужно).

  • Также огромное количество шизиков, для которые кроме руби ничего не видели и на любую критику устраивают религиозную истерику

  • Очень неудобно жить на Windows. Напоминаю, Windows все еще основная операционная система в мире

  • Тотальная нелюбовь к документированию чего-либо. Вместо этого рубисты пишут тесты из предположения, что кто-то их читает и понимает. Это не так.

  • Куча рубистов, которые не только не пишут документацию, но и тесты тоже не пишут. Это совсем финиш.

Продолжать?

Мы однажды переписывали на Java огромную ынтерпрайз систему после команды рубистов, которая дальше не могла ее поддерживать. Задача была - переписать все фичи один в один, только на джаве, чтобы это можно было поддерживать. Моя первая задача была сделать систему бронирования слотов (как в самолете) с таймаутом резервирования 30 минут (если за 30 минут слот не выкупается, то резерв отменяется и надо выбирать заново). Предыдущий рубист разрабатывал ее месяц (!) и закрыл тикет как не поддающийся реализации. Я написал ее за день. Может быть, знал подводные камни, но в тикете об этом ничего сказано не было.

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от Jopich1

Я хоть и не ярый машинист, но реализация по ссылке выше конечно говно. И тут скорее не в идеологии дело, а в серой массе в черепной коробке.

ilinsky ★★★★★
()
Ответ на: комментарий от stevejobs

Опять подмена понятий.

На джава-фреймворках невозможно написать говно, неподдерживаемое говно и неподдерживаемое говно с сервер-сайд рендерингом?

Зачем травить байки про какие-то конкретные проекты, которых никто, кроме вас, не видел и непонятно кем написанные и на личном анализе их, с подмешиванием собственных привычек, делать какие-то громкие выводы?

А вот у меня был один знакомый у которого кум брата тестя писал проект на джаве и там кровь, кишки, распидарасило.

Использование Django, Rails, Laravel и т.п. абсолютно никак не гарантирует, что все приложения написанные на них являются говном.

OSBuster
()
Ответ на: комментарий от Jopich1

Ну да вроде сторонняя но все равно написано с использованием идеологии рельсов ( все в одном )

Ты сейчас на ноль поделил. Если идеология всё в одном, то почему библиотека сторонняя?

Для начала логику предикатов стоит осилить прежде чем гадкие идеологии выкрывать.

OSBuster
()

Будь толерантнее! Дружная команда рубистов тебя всему научит. И баттплаг подарит

TooPar
()
Ответ на: комментарий от Jopich1

Рельсы ничего не игнорируют, все вопросы к разработчику твоего приложения и тому как он проектировал модели и миграции.

Ничто не мешает работать и проектировать одновременно и на уровне activerecord и на уровне БД. Наоборот, такое дублирование является хорошим тоном и позволяет на ранних этапах выловить возможные ошибки.

OSBuster
()
Ответ на: комментарий от OSBuster

На джава-фреймворках невозможно написать говно, неподдерживаемое говно и неподдерживаемое говно с сервер-сайд рендерингом?

думаю, что разработка сайтов на Java - это очень плохо. Если кто-то так сделал, то это уже говнокод просто по факту

разрабатывать на Java стоит микросервисы на сервере, которые будут заниматься вычислениями и хранением, и отдавать наружу результирующие данные с помощью JSON API и GraphQL. (это точно)

причем фронт-сервером к ним, кажется, стоит ставить Node.js, чтобы отдавать совместимый с фронтендом формат. (это уже не точно)

весь веб стоит разрабатывать только на JS фреймворках вроде Angular, React и Vue.

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 2)
Ответ на: комментарий от stevejobs

Предыдущий рубист разрабатывал ее месяц (!) и закрыл тикет как не поддающийся реализации. Я написал ее за день.

Это, конечно, 100% из-за того, что он на Ruby писал, а ты - нет.

sT331h0rs3 ★★★★★
()
Ответ на: комментарий от stevejobs

причем фронт-сервером к ним, кажется, стоит ставить Node.js, чтобы отдавать совместимый с фронтендом формат. (это уже не точно)

Какая разница чем отдавать фронту сериализованные данные, т.е. JSON, если мы говорим про веб в 2020? Ничто не мешает писать бэкенд хоть на OCaml, если есть разработчики всё это потом поддерживать.

Почему на бэкэнд стоит ставить исключительно Node.js? Кроме как «один язык для фронтенда и бэкенда», но это весьма сомнительное преимущество и маркетинговая агитка начала десятых годов, и сейчас вроде бизнес уже как давно понял, что у других вариантов на бэкенде могут быть свои преимущества, часто куда более весомые, и хайп с нодой давно утих.

весь веб стоит разрабатывать только на JS фреймворках вроде Angular, React и Vue.

В Rails ещё пять лет назад из коробки идёт API mode, где сервер-сайд рендеринг отключен. И большинство новых проектов именно его и используют. Но. Не всегда приложение это толстое SPA. Часто быстрее и проще и старые сервер-сайд вьюхи, если на клиенте не предполагается ничего серьёзного городить, а просто набор маршрутов и формочки заполнять (как, к примеру, LOR). И микросервисы тоже все давно используют на полную катушку.

думаю, что разработка сайтов на Java - это очень плохо. Если кто-то так сделал, то это уже говнокод просто по факту

Почему бэкенд веб-приложения на Java это очень плохо? Не помешало бы подробное пояснение.

OSBuster
()
Последнее исправление: OSBuster (всего исправлений: 1)
Ответ на: комментарий от OSBuster

вот ты написал что-то на React или Angular. Но теперь ты хочешь, чтобы оно искалось в гугле. Значит тебе нужен React на сервере теперь, чтобы он генерил там. Значит тебе нужен JS на сервере, все-таки React ни на Java ни на Ruby не написан

теперь, у тебя react-router. Зачем тебе роутер еще и в джава-коде? Роутинг на стороне джавы оказываевается не нужен

теперь, страницы у тебя все равно генерит React. Значит такие штуки как Spring MVC не нужны. Да они и несовместимы между собой, тупо потому что смешать код на Java и JavaScript сложно (хоть и можно с помощью Nashorn или GraalVM). Еще один кусок отпал.

теперь, в старых веб-фреймворках был инструментарий для генерации страниц, в том числе крудов из моделей. Но дело в том, что если у тебя доменно-ориентированная микросервисная архитектура, то со стороны микросервисов у тебя нет таких понятий как «страница» - у тебя есть объекты доменной модели типа «пользователь» или «документ». Весь инструментарий про модели идет псу под хвост, т.к. у тебя может теперь и есть «модели», но в мире Domain Driven Design они значат другое

у тебя был ORM вроде Hibernate (кажется, лучший ORM из всех популярных языков вообще), но все больше и больше людей начинают писать тупо SQL, или всякие генераторы запросов. Hibernate - это слишком сложно. Все эти модные когда-то фичи, которые имели идею про то, что вот у тебя есть виджет, и у него есть нижележащая модель, которая является объектом в ORM - они больше не работают.

и так кирпичик за кирпичиком, всё что составляло сущность «веб-фреймворка» исчезает.

его всё еще, конечно, можно использовать, если ОЧЕНЬ изголяться - пихать туда GraalVM-ы, генерить из Hibernate схему для GraphQL и всё в таком духе, но это больно и жутко, и непонятно зачем нужно.

я знаю только один кейс - это нгужно для старичков, которые хотят что-то написать, но не могут, потому что пропустили изменения парадигмы. То, что сейчас происходит в мире - это не появление «еще одного чуть лучшего SpringMVC, который умеет еще лучше отдавать JSON», это прямо фундаментальные изменения в том, как должна выглядеть архитектура веба

тут еще конечно нужно написать огромный текст про Flutter, Kotlin.js, Progressive Web Apps и изоморфные мобильно-десктопные приложения но я пока не осмыслил эту тему, плюс надо ехать в Икею пока не закрылась и покупать матрас ;)

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от OSBuster

Почему бэкенд веб-приложения на Java это очень плохо?

Потому что сайты написанные на java становятся рассадниками безумцев. Посмотри на ЛОР, посмотри на стивджобса (:

MrClon ★★★★★
()
Ответ на: комментарий от stevejobs

вот ты написал что-то на React или Angular. Но теперь ты хочешь, чтобы оно искалось в гугле. Значит тебе нужен React на сервере теперь

Чегоо?

и так кирпичик за кирпичиком, всё что составляло сущность «веб-фреймворка» исчезает.

Вопрос был не почему нужен фреймворк X (хотя это довольно условный и многозначный термин), а почему нужен именно Node.js на бэкэнде. Можно пилить что угодно и без фреймворков, но непонятно почему исключительно на ноде и джаваскрипте.

у тебя был ORM вроде Hibernate (кажется, лучший ORM из всех популярных языков вообще), но все больше и больше людей начинают писать тупо SQL

На Java нельзя писать «тупо SQL», если захочется? Только из ноды можно дёргать?

OSBuster
()
Последнее исправление: OSBuster (всего исправлений: 1)
Ответ на: комментарий от OSBuster

На Java нельзя писать «тупо SQL», если захочется? Только из ноды можно дёргать?

Если ты модный IT евангелист, то нельзя. :)

Правда он жава евангелистом был вроде как, а тут получается жава не нужна - фронт на реакте, бек на ноде, микросервисы с «вычислениями» уровня достать из базы и отдать в json.

Как так получилось - загадка.

Midael ★★★★★
()
Ответ на: комментарий от stevejobs

Язык, который нигде вне RoR не используют

Кто тебе такую глупость сказал?

TheKnight ★★★
()
Ответ на: комментарий от stevejobs

Моя первая задача была сделать систему бронирования слотов (как в самолете) с таймаутом резервирования 30 минут (если за 30 минут слот не выкупается, то резерв отменяется и надо выбирать заново). Предыдущий рубист разрабатывал ее месяц (!) и закрыл тикет как не поддающийся реализации. Я написал ее за день.

Удивительно, но мой опыт работы с командой рубистов был примерно таким же. На какие-то банальные задачи уходило чудовищное количество времени.

С другой стороны, я до сих пор не уверен, какая проблема первична здесь. То ли Ruby просто паршивый язык, то ли культура вокруг Ruby плодит и привлекает конченых дебилов. Непонятно!

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

С другой стороны, я до сих пор не уверен, какая проблема первична здесь. То ли Ruby просто паршивый язык, то ли культура вокруг Ruby плодит и привлекает конченых дебилов. Непонятно!

Такое кто угодно может сказать и про Haskell и про С и про Prolog. Любую неверифицируемую байку.

Про Haskell я сам знаю забавную историю, когда хаскелист писал проект три недели и его решение не проходило все acceptance-тесты и он так и не смог за дополнительную неделю исправить проект до полного прохождения тестов, и в итоге решение на OCaml разработчиком из французского филиала было написано за 8 рабочих дней и работало идеально.

Репрезентативный ли это показатель? Думаю, что нет. И мне и голову не приходит считать любителей Haskell тупицами и русских программистов идиотами (а хаскелист был русским).

Учитывая, что Ruby и Python очень часто компании и стартапы выбирают в вебе для быстрого прототипирования и демонстрации концепта, то байки про чудовищное количество времени на банальные задачи читать смешно.

OSBuster
()
Последнее исправление: OSBuster (всего исправлений: 2)
Ответ на: комментарий от OSBuster

Репрезентативный ли это показатель? Думаю, что нет. И мне и голову не приходит считать любителей Haskell тупицами.

А конкретно этого любителя хацкелла?

Учитывая, что Ruby и Python очень часто компании и стартапы выбирают в вебе для быстрого прототипирования и демонстрации концепта, то байки про чудовищное количество времени на банальные задачи читать смешно.

Почему? Никто же не говорит, что на руби или пистоне невозможно быстро писать прототипы. И никто не говорит, что все разработчики на руби – поголовно дебилы. Но многие жалуются, что при работе с жирной кодовой базой на этих языках накладные расходы на разработку возрастают до небес. Что, заметь, к разработке прототипов отношения вообще не имеет.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Почему? Никто же не говорит, что на руби или пистоне невозможно быстро писать прототипы. И никто не говорит, что все разработчики на руби – поголовно дебилы. Но многие жалуются, что при работе с жирной кодовой базой на этих языках накладные расходы на разработку возрастают до небес. Что, заметь, к разработке прототипов отношения вообще не имеет.

Если не использовать метапрограмирование на метапрограммировании, не забивать на документацию и неистово блюсти KISS, то разработка ничем не отличается от других динамических языков. Т.е. «жирная кодовая база» одинаково замедлит внесение существенных изменений в проект написанный на любом динамическом языке, будь то Ruby, Python, PHP, JS и т.п.

Что не мешает существовать всяким Электронам и Дискурсам с Гитлабами и Гитхабами.

Хотя если использовать TDD/BDD и соблюдать SOLID и DRY, то не так уж и катастрофично всё. Не у каждого и не каждая задача это «фейсбуки» писать по пять раз на день.

И именно ради этого и в Пайтоне и в Руби запиливают аннотации типов, чтобы можно было сильно упростить себе жизнь на больших проектах. А в Руби в след. версии ещё и полностью иммутабельные строки.

И всё же всё зависит больше, от культуры и соглашений в команде, нежели от языка. Команды использующие разные техники и привычки, а также идиоты и совсем неопытные новички будут писать говнокод на чём угодно.

Вот ТС типичный этому пример – видит что-то, что сделано не так как он привык (синдром утёнка) – бежит и кричит, что всё говно и всё не так. Хотя говном, скорее всего, будут смотреться его собственные правки в этом проекте.

OSBuster
()
Ответ на: комментарий от hateyoufeel

А конкретно этого любителя хацкелла?

Он просто поверил, что существует серебряная пуля и она у него в обойме. А оказалось, что объектность OCaml пришлась в конкретной задаче как нельзя лучше к месту. Хотя и тот и тот это ML-языки, которые непосвящённый условный Вася Пупкин с виду, может, и не различит.

OSBuster
()
Ответ на: комментарий от OSBuster

Что не мешает существовать всяким Электронам и Дискурсам с Гитлабами и Гитхабами.

Это не то чтобы аргумент. Мегамонстрам на коболе тоже ничего существовать не мешало. К счастью, они сдохли вместе с коболом.

И именно ради этого и в Пайтоне и в Руби запиливают аннотации типов, чтобы можно было сильно упростить себе жизнь на больших проектах.

То есть, статическая типизация таки победила? Впрочем, я не уверен, что это поможет. По опыту Erlang, где аннотации есть давно, очень часто, особенно при работе с неаннотированными сторонними библиотеками, вся эта шняга скорее мешает. Так что, исходя из моего опыта, лучше полностью переходить на статическую типизацию.

Хотя если использовать TDD/BDD и соблюдать SOLID и DRY, то не так уж и катастрофично всё

Ну да, всего-то нужно весь код дважды писать: сам код и тесты для него.

И всё же всё зависит больше, от культуры и соглашений в команде, нежели от языка. Команды использующие разные техники и привычки, а также идиоты и совсем неопытные новички будут писать говнокод на чём угодно.

Т.е. хорошие программисты с хорошим менеджментом пишут хороший код, плохие – плохой код. Кто бы мог подумать?

Хотя говном, скорее всего, будут смотреться его собственные правки в этом проекте.

Или нет.

hateyoufeel ★★★★★
()
Ответ на: комментарий от stevejobs

Парадоксальная вообще штука. Язык неплохой, а все приложения - говнокод.

Полная противоположность питону, который сам по себе то ещё поделие, но качественного кода на нем очень много.

Мне очень нравится руби по концепции. Но поддерживать на нем существующий код - извините….

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от stevejobs

Потрясающий коммент с неожиданным финалом :D

Спасибо, прямо от души)

Deleted
()
Ответ на: комментарий от hateyoufeel

Имхо, культура какая-то такая. Язык-то вполне себе язык, мудьтипарадигменный, с читабельным синтаксисом, с неплохой по скорости реализацией (неплохой для скриптухи).

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от OSBuster

React на сервере теперь

Чегоо?

когда ты на урл щелкаешь в браузере, тебе страничку рендерит JS на клиенте. Но гугл у тебя при переходе на тот же урл не сможет запустить настолько сложный JS, у него движок JS примитивный и ограниченный по времени. Кроме того, юзер может перейти на этот урл по внешней ссылке с ЛОР-а, и будет крайне огорчен, если ему страничка будет рендериться не сразу, а с промежуточными этапами. Поэтому у тебя два сценария: в браузере JS, а при прямом переходе тебе совершенно идентичную страничку нужно отрендерить на сервере.

так как UI у тебя весь написан на Angular / React / Vue / …, то если коротко, это означает, что и в браузере и на сервере у тебя должен быть один и тот же реакт (чтобы не перечислять их все, пусть здесь и далее героем будет реакт). Но так как реакт - это никакой не стандарт и не спецификация, то существует ровно один способ заиметь реакт - запустить его единственную на свете джаваскрипт реализацию прямо на сервере, и вот она будет тебе рендерить странички по прямой ссылке. Способности Джавы запускать JS даже с учётом GraalVM - крайне слабые, поэтому по сути, тебе нужно иметь на сервере Node.js в качестве генератора страниц по-любому. Куда ты уж его впендюришь - вопрос второй, но самый простой способ - поставить её фронт-сервером

заметь, что речь тут шла именно о server side rendering, а не о static site generation. Именно о случае, когда сгенерированный результат может варьироваться в зависимости от текущего состояния пользователя, параметров урла и других глобальных обстоятельств - то есть, заранее отрендерить это всё как статический сайт и вложить на nginx нельзя

а почему нужен именно Node.js на бэкэнде

на каком из бэкендов? Напоминаю, у тебя микросервисная архитектура, значит серверов (микросервисов) будет херова гора. Ноду я предлагал использовать в качестве фронт-сервера (то есть, того сервера, к которому напрямую обращается браузерный фронтенд, и дальше фронт-сервер передает вычислительные запросы сети микросервисов например на Java… или на Ruby?).

Почему нода удобна в качестве фронт-сервера: потому что это упрощает утилитарные вопросы вроде пресловутого протокола общения между браузером и фронт-сервером, у тебя на сервере протокол разбирает тот же код, что и в браузере, и это уменьшает количество ошибок в этом коде, и сами протоколы становятся все более навороченными потому что не нужно описывать «протокол» - достаточно написать какой-то код, который делает дело.

Упрощаются разные элементарные штуки вроде того, что всё равно тебе весь браузерный фронтенд нужно собирать Webpack-ом и Babel-ем, то есть нода уже используется в процессе сборки любой HTML страницы, и можно упростить процесс выкладки, заставив ноду же и отрабатывать простейшие запросы.

Всеми этими вопросами вроде провязки браузер-серверного API, выкладкой, управлением зависимостями, итп могут заняться фронтендеры без помощи бэкендеров. Каждый наконец находится на своём месте. Тем более, что джава-бэкендеры как правило срать хотели на богомерзкий JS и наоборот, а фронтендеры о том как работает бэк имеют самое смутное представление и SQL в последний раз видели в голливудских хоррор фильмах. У всех у них совершенно разыне пайплайны сборки, CI/CD, дистрибуции, итп, и это дополнительно развязывает руки.

Там есть более умные способы вроде GraphQL, который позволяет наладить диалог между фронтендерами и бэкендерами, но это еще один пласт истории.

Конечно, надо не забывать про Flutter, который может теоретически убить весь современный веб и мобайл, переведя всё на совершенно новый гибридный фронтенд, общий для мобилы и веба. Туда же Kotlin Native. И там везде будут свои нюансы. Не надо забывать про Progressive Web Apps, у которых пайплайн разработки и дистрибуции несколько другой.

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 2)
Ответ на: комментарий от stevejobs

Но теперь ты хочешь, чтобы оно искалось в гугле

Если пишешь веб-приложение (без статичного контента), то тебе пофиг гугль (кроме лендинг-страницы), серверсайд-рендеринг становится ненужным и вся часть про ноду на сервере отпадает.

x3al ★★★★★
()
Ответ на: комментарий от OSBuster

Что мешает добавлять в крон что и как ты хочешь, а не использовать сторонюю библиотеку, которая предоставляет свой DSL и методы для описания крон-задач?

Тонкий намёк на системдэ таймеры?

deep-purple ★★★★★
()
Ответ на: комментарий от Deleted

Полная противоположность питону, который сам по себе то ещё поделие, но качественного кода на нем очень много.

Только в манямирке утят и воображаемой вселенной.

OSBuster
()
Ответ на: комментарий от hateyoufeel

То есть, статическая типизация таки победила?

На огромных проектах – да. На неогромных и не пишущихся годами особого смысла в ней нет, хотя опционально и в отдельных местах была бы и не лишней.

OSBuster
()
Ответ на: комментарий от stevejobs

думаю, что разработка сайтов на Java - это очень плохо. Если кто-то так сделал, то это уже говнокод просто по факту

смотря какой сайт. Работать с базой из явы несколько приятнее чем из пистона или js. Или ты про фронт?

весь веб стоит разрабатывать только на JS фреймворках вроде Angular, React и Vue

вот так веб в говно и катится

upcFrost ★★★★★
()
Ответ на: комментарий от OSBuster

Только в манямирке утят и воображаемой вселенной.

Программист на Ruby не палится с лексикой недоразвитого.

Deleted
()
Ответ на: комментарий от Deleted

Программист на Ruby не палится с лексикой недоразвитого.

А что на счёт твоего паления с примерами недоразвитых?

Или это не из этих?

Ты писал:

Все приложения на Ruby - говнокод.
Полная противоположность питону, который сам по себе то ещё поделие, но качественного кода на нем очень много.

Это не балабольство недоразвитого?

Чтобы это не было религиозными установками, нужен какой-то объективный и верифицируемый способ оценки.

А пока это выглядит словно утверждение «все приложения с лицензией GPL шикарны, а с BSD - написанные людьми с задержками в развитии и когнитивными дисфункциями». «Все приложения на Си – говнокод, а на Паскале качественного кода очень много.»

Какими критериями это доказывать и опровергать – непонятно. Забежал, ляпнул что-то с умным видом и всё.

OSBuster
()
Последнее исправление: OSBuster (всего исправлений: 3)
Ответ на: комментарий от OSBuster

Припекает, панемаю.

Кстати, как раз размышлял сейчас.

Вот взять, например, PHP. Язык — просто свалка из фич и функций, которые вводились без всякой логики и соответствия друг другу. Помойка, а не язык.

Но я встречал много грамотных программистов и просто вменяемых людей, в том числе и здесь на ЛОР, которые этим языком пользуются и успешно решают задачи. Ну, наверное потому что бизнес требует, так почему бы не писать код. Какая разница на чем, если клиент доволен?

С другой стороны, Ruby действительно во многом первоклассный язык. Но вот сообщество вокруг него подобралось… гм. Своеобразное. Вот взять тебя, брызжащего слюной. Всё нормально, продолжай в том же духе.

Deleted
()
Ответ на: комментарий от Deleted

все приложения - говнокод

Вот взять тебя, брызжащего слюной.

Ага-ага.

OSBuster
()
Ответ на: комментарий от OSBuster

вроде бизнес уже как давно понял Да комон, что там этот бизнес понял)

ЗЫ давно я тут не холиварил..

special-k ★★★★
()
Ответ на: комментарий от OSBuster

Чтобы это не было религиозными установками, нужен какой-то объективный и верифицируемый способ оценки.

Есть неплохой способ оценки, и это сравнение времени перехода с ruby 1.8 на ruby 2.0 и с python 2.x на python 3.0. Когда рубисты все переписали махом, а питонщики еще не закончили миграцию.

Но вообще, трудно не признать, что js побеждает, а бэк становится все тоньше. А если смотреть в корень, то, наверное, меняется само назначение веб-приложений.

special-k ★★★★
()
Ответ на: комментарий от special-k

Есть неплохой способ оценки, и это сравнение времени перехода с ruby 1.8 на ruby 2.0 и с python 2.x на python 3.0. Когда рубисты все переписали махом, а питонщики еще не закончили миграцию.

Я не думаю, что тут причина в неком эфемерном «говнокоде», который мерещится всякого рода сектантам и утятам с их синдромом. Я слабо представляю себе объём изменений между Python 2 и 3, только наслышан, но изменения между Ruby 1.8 и 2.0 (для конечного разработчика, если не брать то, что под капотом) не такие уж и разительные, чтобы все написанные библиотеки и приложения легли мёртвым грузом. Возможно между пайтонами изменения были более радикальными и уж точно совсем никак не следует, что все приложения на нём – это говнокод.

Можно было бы поступить ещё проще и дать балаболу выше пару ссылок на репозитории с популярными и открытыми приложениями с просьбой хотя бы в паре мест сплошного говнокода указать на самый лютейший говнокод и сделать пару показательных и поучительных пул-реквестов исправляющих говнокод на красоту. Но он же бы сразу слился с самыми примитивными отмазками.

OSBuster
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.