Фреймворк вроде бы позволяет ускорить процесс разработки в n раз. Но при этом:

1. Сначала нужно постичь все его тонкости и костыли. Обычно это происходит в процессе работы и даже одна фигня может занять легко пол дня. Но утешаешь себя мыслью что это только на первом проекте (на самом деле см. п. 2).
2. Фреймворки быстро устаревают. Новые версии объявляют депрекейтед привычные вам подходы и вводят новые. Фактически вам придется возвращаться к п. 1 снова и снова, в связи с чем экономия времени сомнительна.
3. Фреймворки часто избыточны для ваших задач и вам придется мириться с тормозами — пока оно загрузит 100500 общих библиотек или подобного.

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

Какое решение?

Здравствуйте, Shmj, Вы писали:

S>Какое решение?

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

Здравствуйте, Shmj, Вы писали:

S>Фреймворк вроде бы позволяет....
S>В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.

Даже без фрэймворков 99% времени — чтение чужого кода и чужих продуктов жизнедеятельности, а иногда даже своего кода. Пример: у меня есть крохотный проектик, который я написал примерно 3 года назад. Чтобы допилить туда небольшую фичу мне пришлось просидеть больше половины дня, разбираясь что там и как. Только после того как я разобрался и вспомнил, мне удалось написать туда вожделенные 100 строчек кода — до этого не понятно куда их там надо было писать и какие именно они должны быть.
Так вот, фрэймворки тебе позволяют быстрее разбираться в чужом коде (и в своём тоже) хотя-бы просто потому что тебе придётся читать в 10 и то дажи и 100 раз меньше кода, чем если бы фрэймворка не было. Фрэймворки уменьшают кол-во хаоса в проекте и значительно облегчают тебе жизнь при подходе к чужим (и своим тоже) творениям.

Здравствуйте, Kolesiki, Вы писали:

K>Никогда вот не слышал, чтобы ругали .NET WF — нормальня такая платформа с шикарным C#.

Вспомнилось: есть два типа языков программирования — те, кто все ругают, и те, которыми никто не пользуется.

Здравствуйте, Shmj, Вы писали:

S>Какое решение?

Проходил этот этап. Основное соображение — фреймворки ускоряют/удешевляют разработку и снижают требования к квалификации разработчиков. Почему это не золотая пуля, хорошо описано в вопросе.

Если же из тройки скорость-цена-качество упор требуется сделать на качество и немного на скорость, то берут команду сеньоров, которая собирает собственный "фреймворк" из готовых библиотек: выбираются либы отдельно для DI, конфигурации, HTTP сервера и клиента, сериализации, логгирования, мониторинга и т.д. И всё это увязывается в скелет приложения. Я считаю, что будущее именно за этим подходом, но есть ньюанс — нужен человек, знакомый с этим набором либ и обладающий достаточной квалификацией, чтобы писать приложения хорошо с нуля.

Один из ужасных типажей, который мне попадается на собеседованиях — квадратно-гнездовой фреймворщик: может рассказать про конфигурацию хибернейта, но не способен написать программу, сортирующую текстовый файл.

Здравствуйте, vsb, Вы писали:

vsb>>>Я давно мечтаю написать для жавы эдакое переосмысление всей экосистемы.

А я себе написал для Scala. Перевел команду (уже не одну). Все успешно работает в production. Теперь потихоньку пишу open source на Scala 3.

vsb>Парсинг json делается в несколько сотен строк.

Json — это сложно. Не в смысле "как-то распарсить", а в смысле сделать правильно и модульно. И так, чтобы в модулях было минимум функциональности и ничего лишнего? Например, тот же парсер Json должен только уметь парсить Json. И не делать ничего лишнего вроде создания Object Model (может, я валидатор пишу?). При этом нужно решить, что делать для опциональных фичей вроде комментариев. Потом к этому всему прикрутить ввод (не парсерское это дело — заниматься вводом). А еще, наверное, нужно строить какую-то модель. Только не совсем понятно, какую. Потому-что требования разные.

Например, реальный список, от которого хочется абстрагироваться в парсере:

• Построение любой объектной модели. Хотя бы просто потому, что сложно сделать универсальную. Например, для обработки всяких конфигов (и прочих подобных штук) мне очень бы хотелось иметь позицию элемента в исходном файле. Я хочу уметь выводить "значение параметра равно 42, потому что он определен в файле XYZ (и переопределяет значение 12, определенное в ZYX)". В других случаях будет достаточно только самих данных.
  
• Примерно по тем-же причинам хотелось бы абстрагироваться от конкретных сообщений об ошибках. В ряде случаев это может быть location + code (для компьютеров), в других — просто текст. В третих — вообще подробностей не надо.
  
• Ввод-вывод. Я хочу не только рекурсивный pull-парсер. Я хочу нерекурсивный pull-парсер. Или даже нет, я хочу парсер, в который можно кормить ввод блоками! И это даже не полностью абстрактная задача. Это можно использовать в асинхронных сервлетах Jetty. Не накапливать весь ввод, а парсить прямо на ходу.
  
• Ну и опциональные комментарии в json. Фича бесполезная, но с точки зрения задачи дизайна — интересная.

И обратите внимание — все вышеперечисленное ничего к синтаксису json не имеет! Хочется везде использовать один и тот же проверенный парсер.

Я вроде придумал границы, теперь собираю кирпичики. Теперь парсер как в анекдоте — может парсить в объекты. А может не парсить (тесты парсера как раз упал/не упал). И я себе сделал кирпичик для "push-парсера".

>> Можешь вкратце описать, как ты видишь дивный новый мир
vsb>1. Общее видение: максимальная простота. ... Если ради удобного маппинга объектов на БД нужна библиотека на сто тысяч строк кода, значит разработчик будет сам писать маппинги, руками.

Это хорошо. Но для маппингов нужна очень хорошая машинерия. Тоже из реальных сценариев. Нам пришел JSON. Он валиден (с точки зрения грамматики) но не ложится в схему объектов. Хотелось-бы не упасть на первой ошибке (а может, хотелось бы!), а собрать и выдасть сразу несколько. Сколько — сложно сказать. Может — все, может — часть. Я такое тоже умею, это несложно. Но там аппликативы в полный рост (и еще немного монад).

vsb>2. Использование native (graal). Всё должно быть оптимизировано под эту технологию. Рефлекшна не должно быть (ну по крайней мере там, где без него можно, а можно практически везде).

Ну... Смысла оптимизироваться под грааль для своих проектов я не видел. Но рефлексии нет (и макросы тоже не используются) — не люблю. Так что можно было бы и в грааль собирать.


vsb>3. Сборка. Для сборки проекта пишется отдельная программа-сборщик.
vsb>4. Для отладки инструментарий для автоматической перекомпиляции изменённых файлов, перезагрузки классов и тд. В целом это есть для других фреймворков, тут ничего нового.

sbt

vsb>5. Для типовых веб-сервисов набор минималистичных библиотек, реализующих ровно то, что реализовывать самому скучно. HTTP, JSON тот же.

Для транспорта я взял embedded Jetty, даже без сервлетов. Маршрутизация — тупой pattern-matching с парой утилит (например, чтобы списки поддерживаемых глаголов генерировать в ответах). Туда же по ситуации дописывается то, что нужно. Например, маршрутизация/парсинг по заголовку Accept. В зависимости от него могут вытаскиваться "плоские" объекты, а могут — с делатями. Желаемые форматы данных в параметрах запроса — вчерашний день. Json — свой. HTTP — пока не свой. Интересно, но много и приоритеты совсем другие. В целом ничего плохого про Jetty Http сказать не могу.

vsb> Также обёртка вокруг JDBC, текущий API не очень хорош.

Тоже сделал. Позволяет писать код в виде

case class Something(id: Long, a: Int, b: String)

def getSomething(a: Int): Option[Something] =
  sql"""
    SELECT *
    FROM somethings
    WHERE a = ${a}
  """ select optional(something)

def something(rs: ResultRow): Something = 
  Something(rs.id, rs.a, rs.b)

Безопасно (без SQL Injection). Она не конкатенирует строки а использует JDBC. Если скормите в интерполяцию что-нибудь неудобоваримое (например, Thread), ругнется во время компиляции. Хотя если напишете адаптер — не ругнется (никаких глобальных переменных! Все адаптеры должны быть видны в лексическом контексте). Вроде бы последняя версия даже умеет во время компиляции (на системе типов) проверять уровень изоляции транзакции. Т.е. если метод требует Serializable-изоляции, то в контексте RepeatableRead вы его не вызовете.

vsb> Причём очень важно, чтобы реализация этих библиотек была простая, чтобы всегда можно было провалиться в реализацию и легко прочитать её.

Sql (но без нормальной документации) Можете оценить сами. Нужно знать Scala (как минимум — implicits и интерполяции). Вроде там больше ничего не используется. Могу поделиться JSON, но там нужно немножко (ну ладно, множко) уметь монады и тайпклассы. Но в целом тоже ничего сложного (хотя низкоуровневое API парсеров мне пока самому не нравится).

vsb> К примеру асинхронность не нужна, что убирает уйму сложности.

В реальных задачах — нужна. Иначе все совсем грустно масштабируется. И есть вторая проблема. Если вы не можете универсально асинхронность, то будут и большие проблемы с мониторингом. Те же метрики собирать вручную. И еще параллельно протаскивать контекст для распределенной трассировки. И не забывать его обновлять на "внутренних границах" (потокоглобальные переменные — это не круто же!). Вот если все на тайпклассах, можно уровни достаточно прозрачно менять. Я недавно добавлял distributed tracing к набору библиотек. Для большинства прикладного кода это выражалось просто в замене сервера (точнее, небольшой интеграции обработчиков) на тот, который поддерживает интеграцию с трассировкой. И еще пару реализаций монад в коде приложения сменить (это тоже в main). Остальное — само. Оно еще метрики (можно и performance включить если надо) там же на автомате собриает. "Интересные места" тоже расставляются вручную, но более-менее простым API.

vsb>В целом моя проблема с популярными подходами в том, что 20% их кода решает 80% проблем, но они не останавливаются, а пишут ещё 80% кода, чтобы решить оставшиеся 20% проблем.

Вы еще забыли про дополнительные 30% проблем, которые создаются 20% кода, решающего 80% проблем. Просто потому, что какие-то места во фреймворке оказались прибиты шурупами, а мне очень-очень надо

Здравствуйте, vsb, Вы писали:

vsb>>> К примеру асинхронность не нужна, что убирает уйму сложности.

M>>В реальных задачах — нужна. Иначе все совсем грустно масштабируется.

vsb>Не нужна в контексте того, что в жаву скоро привезут зелёные потоки и обычный код станет работать так же, как асинхронный (ну плюс-минус).

Вот как раз зеленые потоки решают узкую задачу и добавляют кучу сложностей по управлению. Плюс требуют большой работы в JVM (например, весь I/O блокирующий переписать внутри). И в результате получается тот же фреймворк, с которым приходится дальше бороться. И вот совершенно не понятно, чем эти зеленые потоки принципиально лучше тех же Scala Future (примерно равно Java CompletableFuture).

Давайте в контексте темы колхозить аутентификацию пользователей в веб-приложении. Что у нас там по-умолначию? Прочитать соль и верификатор из базы, посчитать хэш, проверить. Крутиться это все будет в K8S, выделено ему будет 1-2 CPU Cores. По самой задаче у нас два этапа. Первый — ввод/вывод в базу данных (вокруг JDBC). Там блокирующие операции, CPU не нужен. И есть хэш/валидания. Вот она как раз требует CPU. Более того, очень хотелось бы избежать вытеснения задачи вычисления с процессора. Вытеснение не снижает работу а только отсрочивает время, когда может быть дан ответ. Такеже оно увеличивает количество запросов в обработке, что далее увеличивает contention. На Futures все просто. База данных получает свой пул потоков. Допустим, 5 потоков на IO (количество потоков будет совпадать с максимальным размером пула соединений, больше или меньше нет смысла делать). Все остальное (включая вычисление хешей) идет в основной вычислительный пул. Там 1-2 потока (по числу CPU). Вычислительные задачи друг с другом не конкурируют (они в очереди стоят и вытеснять друг друга не могут). Есть немного конкуренции с IO, но именно что немного. Конфигурируется это все элементарно. В DB Infra идет выделенный ExecutionContext с пулом в 5 потоков. Во все остальные места в приложении идет "CPU-bound" ExecutionContext с (системным) потоком на процессор. Как все это будет разруливаться на зеленых потоках?

Но это еще цветочки. Ягодки начинаются, когда у нас "потоки выполнения" могут склеиваться и иметь общий участок. Допустим, прошло три месяца. Выяснилось, что фронтенд присылает очень много запросов и слишком много времени тратится именно на авторизацию. Мы решили прикрутить кэширование. Например, успешная авторизация кэшируется на 5 минут. Внимание, вопрос — что вы будете делать, когда вам "одновременно" приходит много запросов авторизации для сессии, которой нет в кэше? Будете запускать кучу запросов в базу данных и потом считать кучу одинаковых хэшей? Или будете делать greenSleep/greenNotify? Изменится ли интерфейс аутентификатора? На Future кэширование делается практически бесплатно в части реализации:

final class CachingAuth(peer: Auth, sched: Scheduler)(implicit ec: ExecutionContext) extends Auth {
  private val lock = new Object()
  private val cache = new HashMap[String, Future[AuthResult]]()

  override def auth(sessionId: String): Future[AuthResult] = 
    lock synchronized {
       cache.getOrElseUpdate(sessionId, startAuth(sessionId))
    }

  private def startAuth(sessionId: String): Future[AuthResult] =
    peer.auth(sessionId).andThen {
      case Failure(e) | Success(AuthFailure(_)) => lock synchronized { cache.remove(sessionId) }
      case Success(AuthSuccess(_)) => sched.schedule(5.minutes) { lock synchronized { cache.remove(sessionId) } }
    }
}

Все. Успехи кэшируются. Ошибки — нет. Если во время вычисления авторизации пришел новый запрос, он спокойно присоединится к ожиданию текущего вычисления (он не на блокировке будет, а на Future.flatMap, т.е. где-то в очереди слушателей). Я практически бесплатно сэкономил немного CPU. Интерфейс аутентификатора не менялся, для прикладного кода все прозрачно. Как там это все на зеленых потоках будет?

Или еще пример. Я вот недавно копался с Монгой (не люблю ее, но для задач очень хорошо подходит). И была задача "писать много и надежно". После замеров победил асинхронный интерфейс (на вызовах слушателей операций). Я более мнее даже представляют почему — оно позволяет серверу записывать на диск операции большими пачками и потом такими же пачками все подтверждать. Batch-запросы в некоторых условиях приближались, но они чувствительны к размеру батча. А у меня "входные" данные могут приходить пакетами совершенно разного объема. Так что либо все медленно, либо нужно писать кучу кода по построению "оптимальных" батчей. В то же время преобразование из Publisher[T] во Future[T] пишется за две минуты (Publisher[T] в Publisher[Seq[T]] — примерно столько же, нужно только определиться, что мы в памяти строим). Т.е. "асинхронная" монга прекрасно интегрируется с остальным приложением. И для драйвера это удобно — там внутри запросы мультиплексируются в одно соединение, ответы — тоже обрабатываются в выделенном пуле и маршрутизируются по слушателям. Как это все будет интегрироваться с зелеными потоками? И сколько приседаний нужно будет делать в драйвере, чтобы корректно общаться с планировщиком этих потоков?

При этом Futures при необходимости колхозятся часа за 4. Это будет эквивалент по API и удобству использования. Может быть, будут проигрывать на микробенчмарках. Но в целом по соотношениею "усилия/результат" Futures выглядят гораздо более выигрышно, чем зеленые потоки.

Я вообще разделяю позицию о том, что асинхронность (как конструкция языка) не нужна. И зеленые потоки (как конструкция языка или рантайма) тоже не нужна. Нужны возможности, через которые программисты могут реализовать эти возможности в виде библиотеки. И эти возможности сводятся по сути к Scala for comprehension/Haskell do notation. Т.е. немного синтаксического сахара для поддержки монад. И да, поддержка монад нужна! В том числе — пользовательских монад. Потому что без них жизнь превращается в боль. Давайте дальше наш колхозный обработчик http-запроса писать. Нам нужно авторизовать пользователя. Затем распарсить запрос. Затем выполнить операцию. На каждом из этих шагов могут возникнуть условия, в которых обработку нужно завершить с каким-то специфическим ответом. Ну и как вы это предлагаете делать? В go-стиле?

def doSomething(req: HttpRequest): HttpResponse = {
  val user =
    auth.doAuth(req, Roles.SuperUser) match {
      case Left(resp) => return resp
      case Right(succ) => succ
    }

  val requestEntity =
    Route.parseJsonEntity(req, myJsonParser) {
      case Left(resp) => return resp
      case Right(entity) => entity
    }

  val dbData =
    storage.findEntity(requestEntity) match {
      case None => return HttpResonse(404)("Entity was not found")
      case Some(data) => data
    }

  // ...
}

Так что ли? Это вообще негуманно. Или предлагаете бросать исключения "HttpResultException"? Мне кажется, это дурной тон (а еще исключения кто-то может перехватить, так что оно еще и ненадежно). Или бросать специальные исключения и потом настраивать маппинг? Так это черная магия и совершенно непрозрачно. А в монадах получается нормально:

val doSomething: M[HttpResponse] =
  for {
    user <- auth.auth(Roles.SuperUser)
    requestEntity <- Route.parseJsonEntity(myJsonParser)
    data <- (liftWeb { storage.findEntity(requestEntity) }.flatMap {
      case None => ServerProcess.abort(HttpResponse(404)("Enitity was not found")
      case Some(x) => Monad.pure(x)
    })
    ...
  } yield { 
    ... 
  }

Эта наша Http-монада позволяет делать нелокальный переход из глубин библиотек. Причем "переход" обязательно требует, чтобы был предоставлен HttpResponse — (это не исключение!). "Глубины библиотек" тоже не используют особой магии а просто делают ServerProcess.abort(...). В качестве бонуса там еще везде протаскивается Http-запрос, не нужно его ручками передавать. Ну и в асинхронность это все можно запросто переключить, вы ведь не знаете, синхронная или асинхронная M у вас (да и зачем это знание вам нужно в прикладном коде?).

Здравствуйте, Pzz, Вы писали:

Pzz>У Пайка это где-то уже примерно 6-й язык. И C был создан тоже примерно этими людьми.

К сожалению, идеологически уровень Go недалеко от С и Лимбо ушел. Как будто не было лиспа, кучи экспериментов в Хаскеле, языков поколения java/c#/scala/kotlin.

Здравствуйте, Pzz, Вы писали:

Pzz>Я видел написанный на JS эмулятор 80486, в котором, прямо в бровсере, запускалось настоящее ядро линуха с настоящим шелом, и все это работало с какой-то более-менее сносной скоростью.

https://copy.sh/v86/?profile=windows2000

Здравствуйте, Shmj, Вы писали:

S>Какое решение?

Постигнуть очевидную истину — фреймворк фреймворку рознь.

Здравствуйте, Shmj, Вы писали:

НС>>Постигнуть очевидную истину — фреймворк фреймворку рознь.
S>Давайте примеры правильных фреймворков.

linq2db

Здравствуйте, Shmj, Вы писали:

S>В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.

S>Какое решение?

Я от всех этих красивостей отказался в 2000 году.

Здравствуйте, Shmj, Вы писали:

S>Фреймворк вроде бы позволяет ускорить процесс разработки в n раз. Но при этом:

S>В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.

S>Какое решение?

А в любом случае придется изучать "продукта жизнедеятельности",
даже если один работаешь. Можно только сдвинуть чуть-чуть границу
твой код, чужой, но все равно большая часть того, что твоя программа
запустится и заработает зависит не от тебя (ОС, компилятор/интерпретатор,
стандартная библиотека твоего языка программирования и т.д. и т.п.).

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

Здравствуйте, Shmj, Вы писали:

S>Какое решение?

Отказаться от фреймворков.

1. Пишем всё приложение с нуля (в уме).

2. Постепенно заменяем отдельные части приложения на библиотеки. Оцениваем плюсы-минусы каждой замены. Если минусов больше, то не заменяем.

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

Я давно мечтаю написать для жавы эдакое переосмысление всей экосистемы. Начиная от инструмента сборки и заканчивая переписыванием всей стандартной мишуры — http, json и тд. Но вряд ли возьмусь, слишком много времени и практически гарантированно в ящик. Но думал много над этим.

S>1. Сначала нужно постичь все его тонкости и костыли
S>2. Фреймворки быстро устаревают
S>3. Фреймворки часто избыточны

JS — не язык, жабоскриптер — обычная веб-макака с клавиатурой, так что они должны страдать! Какое ещё тут "решение"??

Никогда вот не слышал, чтобы ругали .NET WF — нормальня такая платформа с шикарным C#. Может, всё же "инструменты имеют значение"? А то слышал от одних макак "инструменты под задачу", "хороший программист может писать на любом языке"! Маразм и тупость молодцеватых джунов. Язык имеет значение, ФВ тоже.

Здравствуйте, scf, Вы писали:

vsb>>Я давно мечтаю написать для жавы эдакое переосмысление всей экосистемы. Начиная от инструмента сборки и заканчивая переписыванием всей стандартной мишуры — http, json и тд. Но вряд ли возьмусь, слишком много времени и практически гарантированно в ящик. Но думал много над этим.

scf>А надо? jdk-http — это отличный http клиент

Против jdk ничего против не имею (ну если не считать старых классов из 90-х, но почти всему уже есть современная замена).

> jackson тоже близок к идеалу

Он неимоверно далёк от моего идеала. Парсинг json делается в несколько сотен строк. Форматирование жсон делается ещё короче. Это несколько килобайтов байткода. Сколько мегабайтов и десятков тысяч строк написано в жаксоне я не знаю, и знать не хочу.

> mvn при всех своих недостатках отлично выполняет свою задачу

А мне не нравятся недостатки.

> Можешь вкратце описать, как ты видишь дивный новый мир

1. Общее видение: максимальная простота. В том числе простота реализации Скорость там, где это не мешает простоте. Всё максимально же модуляризировано. Многие концепции вроде маппингов не нужны. Если ради простоты надо написать немного скучного кода, это нормально. Если ради удобного маппинга объектов на БД нужна библиотека на сто тысяч строк кода, значит разработчик будет сам писать маппинги, руками. А библиотека на несколько сотен строк даст ему удобный апи для этого, не более. В целом мне импонирует подход го. Можно это моё видение считать натягиванием мира го на жаву.

2. Использование native (graal). Всё должно быть оптимизировано под эту технологию. Рефлекшна не должно быть (ну по крайней мере там, где без него можно, а можно практически везде). JVM используется только во время разработки, чтобы не ждать компиляции.

3. Сборка. Для сборки проекта пишется отдельная программа-сборщик. С нуля её писать долго, поэтому предоставляется библиотека, которая делает удобным написание этой программы-сборщика. Что-то вроде build.gradle, только на жаве и попроще. Ну и какой-то cli, который автоматически компилирует этот скрипт, опционально делает его native (когда мы уже закончили писать скрипт и хотим просто его запускать). Конечная цель — чтобы с одной стороны написание скрипта не требовало изучение чего-либо кроме Java (ну и этой библиотеки, но опять же библиотека должна быть максимально неинтрузивной), с другой стороны чтобы сборка работала миллисекунды, а не десятки секунд.

4. Для отладки инструментарий для автоматической перекомпиляции изменённых файлов, перезагрузки классов и тд. В целом это есть для других фреймворков, тут ничего нового.

5. Для типовых веб-сервисов набор минималистичных библиотек, реализующих ровно то, что реализовывать самому скучно. HTTP, JSON тот же. Также обёртка вокруг JDBC, текущий API не очень хорош. Причём очень важно, чтобы реализация этих библиотек была простая, чтобы всегда можно было провалиться в реализацию и легко прочитать её. К примеру асинхронность не нужна, что убирает уйму сложности. В целом каждая отдельная библиотека должна занимать несколько тысяч строк от силы.

6. Ненужное — не нужно. HTTPS не нужен, все ставят реверс-прокси. Какие-то мегасуперпупер оптимизации не нужны, быстрей netty всё равно не сделаешь.

7. Использование последних стандартов, к примеру records и тд. В этом плане я жду некоторые фичи вроде string interpolation, которые могут очень круто сочетаться с тем же SQL.

Попробую свою идею выразить по-другому. Представь, что у тебя есть компилятор жавы и всё. Мавена нет. Спринга нет. Тебя заперли на год и тебе надо написать веб-сервис. Ты сначала пишешь тулзу для сборки на коленке, потом пишешь реализацию HTTP на коленке, потом неминуемо напишешь обёртку вокруг JDBC, вручную сериализацию и парсинг JSON. Потом ты напишешь второй проект, третий. Потом из этих трёх проектов попробуешь вытащить какие-то общие куски кода. Вот эти общие куски кода это и есть моё видение. Для типовых проектов, которые обрабатывают HTTP запросы и лезут в реляционную СУБД. По крайней мере для таких, с которыми я сталкиваюсь.

> Возможно, это уже запилено для более "продвинутых" языков.

Как я уже написал, в Го в целом это запилено. К сборке там другой подход, но мне любопытен именно мой вариант, мне он кажется интересным для исследования.

В целом моя проблема с популярными подходами в том, что 20% их кода решает 80% проблем, но они не останавливаются, а пишут ещё 80% кода, чтобы решить оставшиеся 20% проблем. Вот мне хотелось бы остановиться на первых 20%. Мне кажется, что это было бы в итоге лучше.

Здравствуйте, Shmj, Вы писали:

S>Фреймворк вроде бы позволяет ускорить процесс разработки в n раз. Но при этом:

S>1. Сначала нужно постичь все его тонкости и костыли. Обычно это происходит в процессе работы и даже одна фигня может занять легко пол дня. Но утешаешь себя мыслью что это только на первом проекте (на самом деле см. п. 2).
S>2. Фреймворки быстро устаревают. Новые версии объявляют депрекейтед привычные вам подходы и вводят новые. Фактически вам придется возвращаться к п. 1 снова и снова, в связи с чем экономия времени сомнительна.
S>3. Фреймворки часто избыточны для ваших задач и вам придется мириться с тормозами — пока оно загрузит 100500 общих библиотек или подобного.

S>В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.

S>Какое решение?

Проблема есть. Миллионы человеко-дней по всему миру тратятся на то, чтобы разобраться с очередным фреймворком, люди по сути делают одно и то же, многократно дублируя свои усилия, наступают на одинаковые грабли.
Решение — кодогенерация. Фреймворки должны сами генерировать результирующий код, опираясь на некую базовую информацию о решаемой задаче. Гораздо эффективнее потратить ресурсы однократно при разработке "фреймворка", чтобы сделать его "умнее", чем заставлять его пользователей многократно повторять рутину. Структурированные данные о задаче во главе угла.

[Прикладные] Программисты должны заниматься тем, что невозможно автоматизировать без привлечения всего массива человеческих знаний о реальном мире: алгоритмами и структурами данных. А кишки фреймворков равно как и детали реализации платформ должны быть надежно спрятаны от человека.

Это же, кстати, должно решить проблему с устареванием фреймворков и поддержкой новых платформ — достаточно будет перегенерировать код с помощью нового "фреймворка" по имеющимся данным, описывающим задачу. (Ну это же полная нелепица, когда целый софтверный гигант не в состоянии найти ресурсы чтобы переделать диалоговые окошки, чтобы они выглядели единообразно в новой винде)

Здравствуйте, Shmj, Вы писали:

S>1. Сначала нужно постичь все его тонкости и костыли. Обычно это происходит в процессе работы и даже одна фигня может занять легко пол дня. Но утешаешь себя мыслью что это только на первом проекте (на самом деле см. п. 2).
Нет, не нужно. Ибо тонкости ты постигнешь только в процессе применения, в случае если наткнешься на какие грабли. Если не будешь отклоняться от
границы применимости фреймворка и тебе не требуется выжимать максимум производительности — скорее всего на грабли ты не наткнешься и у тебя сразу все будет работать из коробки. Вот если наткнешься на проблемы — да, будет весьма весело, но времени потратишь один хрен меньше чем писать все с нуля.
S>2. Фреймворки быстро устаревают. Новые версии объявляют депрекейтед привычные вам подходы и вводят новые. Фактически вам придется возвращаться к п. 1 снова и снова, в связи с чем экономия времени сомнительна.
Более новые фреймворки чаще всего проще и легче в использовании, если какая то концепция устарела, это означает что ей на смену пришла более легкая концепция, с которой грабель будет меньше и код писать будет приятнее.

S>3. Фреймворки часто избыточны для ваших задач и вам придется мириться с тормозами — пока оно загрузит 100500 общих библиотек или подобного.
Лучше когда они избыточны. Хуже, когда внезапно тебе понадобилась определенная фича, а ее нет и проблематично прикрутить. И придется тебе лисапедить и хреначить нужную логику ручками, зачастую написав половину фреймворка.

S>В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.
Все с точностью до наоборот. Без фреймворков ты будешь тратить большинство времени на примитивнийшие шаблоннейшие тривиальные вещи. И будешь либо лепить жутчайший копипаст и спагетти, либо писать по существу собственный фреймворк.

S>Какое решение?
Использовать максимум стандартных решений, смотреть на задачи, пытаться предугадать требования наперед и брать фреймворки с запасом по фичам. Если же требуется максимальная производительность и готового фреймворка нет — придется писать свой.

Здравствуйте, vaa, Вы писали:

M>>Решение — не использовать никакие фреймворки. Это мусор и зависимость от автора . помню бурления на хабре, как автор реакта или чего что-то не так сделал. Надо везде использовать чистый код, ну или (если прям край как надо) библиотеку под конкретное дело (хттп запрос или еще что).

vaa>Кстати, как отличить фрэймворк от библиотеки, по каким критериям?

Фреймворк привносит/диктует архитектуру, библиотека — нет.

Здравствуйте, Pzz, Вы писали:

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

Все так. Но есть нюанс — разбираться надо не во всем фреймворке, а только в его кусочке. Понятно, что для языков типа С++ это все равно суровая проблема, но в джаве/шарпе/етц ситуация иная, если фреймворк написан хотя бы минимально аккуратно — задача вполне посильная, и даже, зачастую, проще чем ковыряние в доке/примерах/тестах.

Здравствуйте, Pzz, Вы писали:

Pzz>Если ты текст фреймворка наизусть знаешь, это, наверное, самая плохая характеристика для этого фреймворка.

Текст не надо. Надо основные архитектурные принципы. Ну и нормальную IDE, которая в любой момент позволит поскакать по чужим исходникам, а, при необходимости, еще и воткнуть в них бряку.

Здравствуйте, vaa, Вы писали:

vaa>что насчет этой библиотеки http://www.gpars.org/ ?

Полистал доки — модель акторов, интрузивный код, заброшена с 2018 года. CompletableFuture лучше, не говоря уже о projectreactor.

Здравствуйте, scf, Вы писали:

scf>В том-то и дело, что 99% кода не нужно знать ни про параллелизм, ни про асинхронность. А проблема фьюч, монад и корутин в том, что если где-то внизу есть асинхронный вызов, то фьючи, как раковая опухоль, расползаются по всему приложению. И в итоге приложение набито for comprehensions-ами тогда как собственно асинхронных вызовов в нем штук 10.

Не расползаются. Оно сразу в for-comprehension идет. И с полиморфизмом высшего порядка:

class MyWebHandler[M[_]: HttpRoute: HttpProcess: Monad]() {
  val handle: M[HttpResponse] =
    for {
      body <- HttpRoute.parseJson(maxSize=10000, bodyParser)
      ...
    } yield ...
}

Обычно у веба два полиморфных конструктора и один лифт между ними, в бизнес-сервисах — только один, низкоуровневые реализуются под конкретный тип. И монада — это не только синхронность/асинхронность. Там еще неявные контексты таскаются. Я прошел путь самурая от протаскивания http request и tracing context через implicits по дереву вызовов к передаче их через монады. Помимо http request (который от клиента) я еще обычно неразобранную часть пути таскаю (потому что маршрутизация кодом и без всяких глобальных настроек). Кроме того, в монадах можно и нелокальные переходы делать (с определенным типом результата, как в http). Или там в тестах монаду на синхронную поменять (и без distributed tracing, чтобы писать заглушки зависимостей было проще).

Да и вне контекста монад for comprehension удобны. Например, jwt разбор (мы же всё велосипедим):

def checkJwt(token: String): Option[Whatever] = 
  for {
    (head, body, tail) <- chopToken(token)
    _ <- checkSignature(head, body)
    claims <- parseClaims(body)
    _ <- validateIssuedAt(claims)
    _ <- validateExpiryTime(claims)
  } yield whatever(claims)


def chopToken(tok: String): Option[(String, String, String)] =
  tok.split(":") match {
    case Array(a, b, c) => Some((a, b, c))
    case _ => None
  }

def parseClaims(body: String): Option[String] =
  for {
    raw <- decodeBase64(body)
    json <- parseAsJson(raw)
  } yield json.as[Map[String, JsonValue]]

Без for comprehension будет грустная простыня с исключениями. Обычно с исключениями совершенно разных типов. В общем, при небольшой привычке for comprehension читается так же хорошо, как и синхронный код (потому что монада — это абстракция последовательного выполнения). И вот из моей практики монады решают гораздо более широкий класс задач (и более удобно), чем решения, прибитые к конкретному механизму вроде асинхронности или там генераторов (привет python и javascript).

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Постигнуть очевидную истину — фреймворк фреймворку рознь.

Давайте примеры правильных фреймворков.

Здравствуйте, vsb, Вы писали:

vsb>Я давно мечтаю написать для жавы эдакое переосмысление всей экосистемы. Начиная от инструмента сборки и заканчивая переписыванием всей стандартной мишуры — http, json и тд. Но вряд ли возьмусь, слишком много времени и практически гарантированно в ящик.

А самое главное — результат будет еще хуже чем то что есть сейчас.

Здравствуйте, vsb, Вы писали:

vsb>В целом моя проблема с популярными подходами в том, что 20% их кода решает 80% проблем, но они не останавливаются, а пишут ещё 80% кода, чтобы решить оставшиеся 20% проблем. Вот мне хотелось бы остановиться на первых 20%. Мне кажется, что это было бы в итоге лучше.
Похоже ты хочешь просто сделать "не как у всех", а на выходе получится новый супер "кул-фреймворк" для стороннего наблюдателя (почти)ничем не отличающийся от spring/micronaut/whatever

Здравствуйте, vsb, Вы писали:

vsb>1. Общее видение: максимальная простота. В том числе простота реализации Скорость там, где это не мешает простоте. Всё максимально же модуляризировано. Многие концепции вроде маппингов не нужны. Если ради простоты надо написать немного скучного кода, это нормально. Если ради удобного маппинга объектов на БД нужна библиотека на сто тысяч строк кода, значит разработчик будет сам писать маппинги, руками. А библиотека на несколько сотен строк даст ему удобный апи для этого, не более. В целом мне импонирует подход го. Можно это моё видение считать натягиванием мира го на жаву.

В целом jvm мир дрейфует в эту сторону. На острие прогресса находится Scala — и атомарные библиотеки, и простота (местами). Даже до джавистов начинает доходить, что зачем нужны аннотации, если можно описать тот же функционал несколькими строками кода.

vsb>2. Использование native (graal). Всё должно быть оптимизировано под эту технологию. Рефлекшна не должно быть (ну по крайней мере там, где без него можно, а можно практически везде). JVM используется только во время разработки, чтобы не ждать компиляции.

А зачем? быстрее работать оно от этого не будет, разве что быстрее запускаться. Что важно разве что в aws lambda, но там JVM редко используют.

vsb>3. Сборка. Для сборки проекта пишется отдельная программа-сборщик. С нуля её писать долго, поэтому предоставляется библиотека, которая делает удобным написание этой программы-сборщика. Что-то вроде build.gradle, только на жаве и попроще. Ну и какой-то cli, который автоматически компилирует этот скрипт, опционально делает его native (когда мы уже закончили писать скрипт и хотим просто его запускать). Конечная цель — чтобы с одной стороны написание скрипта не требовало изучение чего-либо кроме Java (ну и этой библиотеки, но опять же библиотека должна быть максимально неинтрузивной), с другой стороны чтобы сборка работала миллисекунды, а не десятки секунд.

Тоже думал об этом, но, смотря на весь зоопарк билд тулов для самых разных языков, никто не смог осилить такой сборщик. Одна из причин — IDE нужно уметь извлекать метаданные из скрипта сборки для правильной работы intellisense. Может быть, получится у тебя.

vsb>4. Для отладки инструментарий для автоматической перекомпиляции изменённых файлов, перезагрузки классов и тд. В целом это есть для других фреймворков, тут ничего нового.

Это сложная и глючная штука. Сейчас популярен другой подход — писать приложения с минимальным временем старта и автоматически пересобирать/перезапускать их при изменении исходников.

vsb>5. Для типовых веб-сервисов набор минималистичных библиотек, реализующих ровно то, что реализовывать самому скучно. HTTP, JSON тот же. Также обёртка вокруг JDBC, текущий API не очень хорош. Причём очень важно, чтобы реализация этих библиотек была простая, чтобы всегда можно было провалиться в реализацию и легко прочитать её. К примеру асинхронность не нужна, что убирает уйму сложности. В целом каждая отдельная библиотека должна занимать несколько тысяч строк от силы.

Не все ли равно, сколько строк в библиотеке, если у неё минималистичный API и она работает? Например, HTTP очень объемный стандарт и даже JSON, при всей своей простоте, не так уж прост. Парсер JSON на токены и в jackson мог бы занимать несколько сотен строк, но дальше появляются ньюансы. Валидация с нормальным текстом ошибки (строка-колонка-описание), разнообразные фичи, не входящие в стандарт, но нужные людям (а-ля разрешить ключи без кавычек). Потом еще отдельная огромная механизация по десериализации в объект.

Тот же JDBC — он, на самом-то деле, неплох, если исплользовать его не из джавы, а из той же скалы или котлина.

vsb>В целом моя проблема с популярными подходами в том, что 20% их кода решает 80% проблем, но они не останавливаются, а пишут ещё 80% кода, чтобы решить оставшиеся 20% проблем. Вот мне хотелось бы остановиться на первых 20%. Мне кажется, что это было бы в итоге лучше.

Да, всё так и есть, минималистичные атомарные библиотеки, уже в Scala, когда-нибудь мода доберется и до джавы. Но вовсе не обязательно всё самому писать с нуля. Например, когда мне нужен HTTP клиент, я пишу к нему своё API ровно в том объеме, который мне нужен (паттерн фасад), и подключаю какую-нибудь реализацию. В итоге в моём коде нет избыточного API, я всегда свободен заменить реализацию (в том числе на фейковую для тестов), мне не нужно всё делать самому с нуля и при этом у меня остается такая опция.

Проблема в том, что язык формирует мышление. Без поддержки лямбд сложно объяснить, что map/flatMap — это хорошая идея. Если нельзя в одном классе объявить всю доменную модель, то тяжко писать фасады для стороннего кода. Если язык не поддерживает именнованных параметров методов и конструкторов, то сложно заставить себя писать модели и конверторы между ними.
Я бы посоветовал посмотреть на Scala и их библиотеки. Там хватает своих проблем, но направление правильное.

Здравствуйте, so5team, Вы писали:

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

Девиз многих плюсников. Особенно тех, кто не может рвзвернуть строку in place.

Здравствуйте, scf, Вы писали:

S>>Да, тоже слышал про чувака, который на любой практически вопрос приводил пример, какой метод из какой либы надо взять Тоже конечно важный скилл...

scf>Важный и полезный, но не заменяет умение программировать.

Можно такого человека держать на позиции "библиотекаря", отвечать на вопросы программирующих программистов и помогать им решать проблемы с библиотеками. А самому код писать не давать.

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

Очень был полезный человек, надо сказать.

Здравствуйте, Философ, Вы писали:

Ф>Так вот, фрэймворки тебе позволяют быстрее разбираться в чужом коде (и в своём тоже) хотя-бы просто потому что тебе придётся читать в 10 и то дажи и 100 раз меньше кода, чем если бы фрэймворка не было. Фрэймворки уменьшают кол-во хаоса в проекте и значительно облегчают тебе жизнь при подходе к чужим (и своим тоже) творениям.

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

Здравствуйте, vsb, Вы писали:

vsb>Я давно мечтаю написать для жавы эдакое переосмысление всей экосистемы. Начиная от инструмента сборки и заканчивая переписыванием всей стандартной мишуры — http, json и тд. Но вряд ли возьмусь, слишком много времени и практически гарантированно в ящик. Но думал много над этим.

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

Здравствуйте, Shmj, Вы писали:

S>Давайте примеры правильных фреймворков.

.NET Framework — каждая версия ходит достаточно долго, какие-то breaking changes достаточно редки

Здравствуйте, Shmj, Вы писали:

S>Какое решение?

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

Здравствуйте, scf, Вы писали:

scf>В том-то и дело, что 99% кода не нужно знать ни про параллелизм, ни про асинхронность. А проблема фьюч, монад и корутин в том, что если где-то внизу есть асинхронный вызов, то фьючи, как раковая опухоль, расползаются по всему приложению.

Плохая аналогия. В отличие от опухоли, фьючерсы после окончательного расползания не приводят к смерти. А если приложение пишется с нуля в таком стиле, то никто никуда и не расползается, оно изначально все такое, включая не только твой код, но и используемые либы и фреймворки. Тут скорее наоборот — всякие древние неасинхронные либы вызывают изрядный геморой.
Еще, кстати, подумай как ты в своих green threads будешь делать cancellation чтобы не разломать нафик весь стейт у кода, который про асинхронность не в курсе.

Здравствуйте, LaptevVV, Вы писали:

Аё>>>Девиз многих плюсников. Особенно тех, кто не может рвзвернуть строку in place.
Pzz>>Ты вот две "половинки" строки поменяй меж собой местами in place, при том, что "половинки" могут быть разного размера. Потом поговорим.
LVV>Книжки надо читать.
LVV>Там все написано...

А ты не подсказывай!

Здравствуйте, Pzz, Вы писали:

Pzz>>>И C был создан тоже примерно этими людьми.

S>>Как будто Си это что-то хорошее.

Pzz>Хорошее оно или плохое, но

но если авторы Си не смогли лучше тогда, то несколько наивно ожидать, что потом они стали выдавать что-то принципиально лучшее.

Pzz>прочие языки

проблемы больших фреймворков касаются не только наследников C (хотя те же Java и C# от C унаследовали разве что некоторые элементы синтаксиса). Скажем, для Python, Ruby или F# это не менее актуально, но к C они относятся практически никак.

Здравствуйте, Pzz, Вы писали:
Pzz>Если ты текст фреймворка наизусть знаешь, это, наверное, самая плохая характеристика для этого фреймворка.
А по-моему — наоборот. Когда я программил на дельфи, возможность потрассироваться по исходникам VCL была бесценна. Потому, что на все случаи жизни учебников не напишешь.
Если кто-то разбирается в потрохах фреймворка, это означает, что
1. Исходники как минимум доступны
2. Фреймворк на рынке достаточно давно для того, чтобы кто-то смог пройти всю лестницу от полного нуба и до эксперта
3. Есть настолько высокий спрос на решения на основе этого фреймворка, что есть мотивация не просто использовать его в готовом виде, но и расширять и улучшать.

Здравствуйте, Ikemefula, Вы писали:

I>Именно так. Фремворк понижает стомость входа для большинства типовых задач. Соответсвенно, снижаются требования к квалификации. Отсюда ясно, что будет скучно, если тебе нравятся сложные задачи.
I>Что делать — нужно идти в новые области.

Или так: Фреймворк избавляет от написания boilerplate code.
И позволяют быстрее решать сложные задачи.
Новые области и фреймворки — ортогональны.

Здравствуйте, Буравчик, Вы писали:

Б>Новые области и фреймворки — ортогональны.

А что за новая область, что там для тебя фремворки заготовлены? Можно пример?

Здравствуйте, scf, Вы писали:

scf>Один из ужасных типажей, который мне попадается на собеседованиях — квадратно-гнездовой фреймворщик: может рассказать про конфигурацию хибернейта, но не способен написать программу, сортирующую текстовый файл.

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

Здравствуйте, sambl74, Вы писали:

S>Да, тоже слышал про чувака, который на любой практически вопрос приводил пример, какой метод из какой либы надо взять Тоже конечно важный скилл...

Важный и полезный, но не заменяет умение программировать.

Здравствуйте, vsb, Вы писали:

vsb>Я давно мечтаю написать для жавы эдакое переосмысление всей экосистемы. Начиная от инструмента сборки и заканчивая переписыванием всей стандартной мишуры — http, json и тд. Но вряд ли возьмусь, слишком много времени и практически гарантированно в ящик. Но думал много над этим.

А надо? jdk-http — это отличный http клиент, jackson тоже близок к идеалу, mvn при всех своих недостатках отлично выполняет свою задачу. Можешь вкратце описать, как ты видишь дивный новый мир? Возможно, это уже запилено для более "продвинутых" языков.

Имхо, в java-мире всё уже изобретено, настоящие прорывы возможны только вместе с изменением языка. В Котлине и, особенно, в Скале много интересных инноваций и библиотек.

Здравствуйте, Shmj, Вы писали:

Заколеблешься мультиплатыорменность поддерживать без фреймворков и движков

Здравствуйте, scf, Вы писали:

vsb>>2. Использование native (graal). Всё должно быть оптимизировано под эту технологию. Рефлекшна не должно быть (ну по крайней мере там, где без него можно, а можно практически везде). JVM используется только во время разработки, чтобы не ждать компиляции.

scf>А зачем? быстрее работать оно от этого не будет, разве что быстрее запускаться. Что важно разве что в aws lambda, но там JVM редко используют.

Памяти ощутимо меньше будет жрать, это второй плюс. Кому не надо — жвм никто не запрещает.

scf>Тоже думал об этом, но, смотря на весь зоопарк билд тулов для самых разных языков, никто не смог осилить такой сборщик. Одна из причин — IDE нужно уметь извлекать метаданные из скрипта сборки для правильной работы intellisense. Может быть, получится у тебя.

Грэдл и мавен давным давно тупо генерировали xml-ку проекта для идеи. По-мне это самый простой и правильный подход. Там файл проекта по сути довольно простой — прописать пути к каталогам и зависимостям. Ну понятно, что для простых проектов.

vsb>>4. Для отладки инструментарий для автоматической перекомпиляции изменённых файлов, перезагрузки классов и тд. В целом это есть для других фреймворков, тут ничего нового.

scf>Это сложная и глючная штука.

Да вроде не особо. В JVM этот функционал встроен. Работает для ограниченных случаев (по сути только когда тело метода меняется), но для разработки в 90% оно срабатывает, в 10% пускай перезапускается.

scf>Не все ли равно, сколько строк в библиотеке, если у неё минималистичный API и она работает?

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

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

> Например, HTTP очень объемный стандарт

Если ограничиться HTTP/1.1, то для библиотеки его объём не такой и большой. Я его подробно не реализовывал, но читал. Парсинг структуры простой. Нюансы там со всякими connection keep-alive, но их не так уж много. А остальное это уже дело приложения.

>и даже JSON, при всей своей простоте, не так уж прост. Парсер JSON на токены и в jackson мог бы занимать несколько сотен строк, но дальше появляются ньюансы. Валидация с нормальным текстом ошибки (строка-колонка-описание), разнообразные фичи, не входящие в стандарт, но нужные людям (а-ля разрешить ключи без кавычек).

Ну вот это уже нетипичные требования. Как раз то, о чём я говорю — 80% работы ради 20% требований. Кому нужны ключи без кавычек — жаксон никто не запрещал. Мне никогда не были нужны.

> Потом еще отдельная огромная механизация по десериализации в объект.

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

scf>Проблема в том, что язык формирует мышление. Без поддержки лямбд сложно объяснить, что map/flatMap — это хорошая идея. Если нельзя в одном классе объявить всю доменную модель, то тяжко писать фасады для стороннего кода. Если язык не поддерживает именнованных параметров методов и конструкторов, то сложно заставить себя писать модели и конверторы между ними.
scf>Я бы посоветовал посмотреть на Scala и их библиотеки. Там хватает своих проблем, но направление правильное.

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

vsb>> К примеру асинхронность не нужна, что убирает уйму сложности.

M>В реальных задачах — нужна. Иначе все совсем грустно масштабируется.

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

scf>Один из ужасных типажей, который мне попадается на собеседованиях — квадратно-гнездовой фреймворщик: может рассказать про конфигурацию хибернейта, но не способен написать программу, сортирующую текстовый файл.

Нет, ужасный типаж на этом собеседовании это Вы.
У вас не проработано методическое обеспечение, полная профессиональная несостоятельность.
Так бы дали ему собственноручно написанный учебный курс и новый сотрудник втянулся бы.

Здравствуйте, Shmj, Вы писали:

S>Фреймворк вроде бы позволяет ускорить процесс разработки в n раз. Но при этом:

S>1. Сначала нужно постичь все его тонкости и костыли. Обычно это происходит в процессе работы и даже одна фигня может занять легко пол дня. Но утешаешь себя мыслью что это только на первом проекте (на самом деле см. п. 2).
S>2. Фреймворки быстро устаревают. Новые версии объявляют депрекейтед привычные вам подходы и вводят новые. Фактически вам придется возвращаться к п. 1 снова и снова, в связи с чем экономия времени сомнительна.
S>3. Фреймворки часто избыточны для ваших задач и вам придется мириться с тормозами — пока оно загрузит 100500 общих библиотек или подобного.

S>В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.

S>Какое решение?

нужны две странички на сайте ЯП:
awesome & cookbook

вот как пример https://lispcookbook.github.io/cl-cookbook/

и еще пара вещей
1) ЯП это культура
2) чем лучше владеешь инструментом тем проще и эффективней использование
3) да, библиотеки лучше фрэймворков

Фреймворк/библиотека не только ускоряет процесс разработки,
это банально продукт общественного разума, который в 99% случаев будет качественнее
велосипеда одиночки. Нет, есть конечно люди выдающихся способностей, но большинство программистов это люди средних способностей
и что-то хорошее может родится только в большом коллективе.
Хоть у меня и скромный опыт, но на велосипеды насмотрелся.

Здравствуйте, Артём, Вы писали:

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

Аё>Девиз многих плюсников. Особенно тех, кто не может рвзвернуть строку in place.

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

Здравствуйте, scf, Вы писали:

scf>Один из ужасных типажей, который мне попадается на собеседованиях — квадратно-гнездовой фреймворщик: может рассказать про конфигурацию хибернейта, но не способен написать программу, сортирующую текстовый файл.

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

Так вот, более старательного и аккуратного тестировщика надо было еще поискать. Для обычного тестера его позиция — промежуточная ступень на высокой и заманчивой карьерной лестнице, и ему наплевать на такую работу, если что, он другую найдет. А для нее это был прямо социальный лифт из подвала на вершину Эвереста. Как же, думала, так всю жизнь свою проведет со шваброй в руках, а тут прям белые люди взяли в настоящую команду настоящих инженеров. Она эту работу очень ценила, любила и вкладывала в нее все свои силы и старание.

Наверное, и с программистами можно так поступать.

Здравствуйте, vsb, Вы писали:

vsb>1. Общее видение: максимальная простота. В том числе простота реализации Скорость там, где это не мешает простоте. Всё максимально же модуляризировано. Многие концепции вроде маппингов не нужны. Если ради простоты надо написать немного скучного кода, это нормально. Если ради удобного маппинга объектов на БД нужна библиотека на сто тысяч строк кода, значит разработчик будет сам писать маппинги, руками. А библиотека на несколько сотен строк даст ему удобный апи для этого, не более. В целом мне импонирует подход го. Можно это моё видение считать натягиванием мира го на жаву.

Так не лучше ли не тащить Go в Яву, а наоборот, все хорошее из Явы в Go перенести?

Ты учти, кстати, что ценой внешней простоты Go является неимоверная сложность под капотом. Видно, что настоящие олдовые хакеры писали, не нонешнее племя.

vsb>3. Сборка. Для сборки проекта пишется отдельная программа-сборщик. С нуля её писать долго, поэтому предоставляется библиотека, которая делает удобным написание этой программы-сборщика. Что-то вроде build.gradle, только на жаве и попроще. Ну и какой-то cli, который автоматически компилирует этот скрипт, опционально делает его native (когда мы уже закончили писать скрипт и хотим просто его запускать). Конечная цель — чтобы с одной стороны написание скрипта не требовало изучение чего-либо кроме Java (ну и этой библиотеки, но опять же библиотека должна быть максимально неинтрузивной), с другой стороны чтобы сборка работала миллисекунды, а не десятки секунд.

По-моему, ничего лучше, чем go build, для сборки пока не придумано.

То, что там есть единственно верный путь и вообще никакой гибкости — огромное достоинство, а не недостаток.

Кстати, все запчасти go build'я являются частью стандартной библиотеки Go с публичным API.

Единственное, чего лично мне не хватает в go build — это возможность ровно таким же способом собирать программы не на Go. А, например, на C/C++. Причем "для себя" он так умеет, но хоть один файл на go должен быть, и в итоге получается go package, а не произвольная библиотека или исполняемый файл.

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

vsb>Попробую свою идею выразить по-другому. Представь, что у тебя есть компилятор жавы и всё. Мавена нет. Спринга нет. Тебя заперли на год и тебе надо написать веб-сервис. Ты сначала пишешь тулзу для сборки на коленке, потом пишешь реализацию HTTP на коленке, потом неминуемо напишешь обёртку вокруг JDBC, вручную сериализацию и парсинг JSON. Потом ты напишешь второй проект, третий. Потом из этих трёх проектов попробуешь вытащить какие-то общие куски кода. Вот эти общие куски кода это и есть моё видение. Для типовых проектов, которые обрабатывают HTTP запросы и лезут в реляционную СУБД. По крайней мере для таких, с которыми я сталкиваюсь.

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

Здравствуйте, maxkar, Вы писали:

M>* Ввод-вывод. Я хочу не только рекурсивный pull-парсер. Я хочу нерекурсивный pull-парсер. Или даже нет, я хочу парсер, в который можно кормить ввод блоками! И это даже не полностью абстрактная задача. Это можно использовать в асинхронных сервлетах Jetty. Не накапливать весь ввод, а парсить прямо на ходу.

Бывает иногда нужно. Например, передаем по сети поток, представляющий собой последовательность JSON-объектов (или бесконечный массив объектов), и парсим по мере поступления.

Для языков с "сишной" моделью ввода-вывода удобнее не pull, а push. Ну или как в Go, пусть читает из io.Reader'а.

M>* Ну и опциональные комментарии в json. Фича бесполезная, но с точки зрения задачи дизайна — интересная.

Фича очень полезная, если предполагается хранить конфиги в JSON'е, и чтобы человек мог их редактировать. Хотя я лично все равно предпочитаю для конфигов синтаксис .INI-файлов, он гораздо более человеческий.

Здравствуйте, Kolesiki, Вы писали:

K>JS — не язык, жабоскриптер — обычная веб-макака с клавиатурой, так что они должны страдать! Какое ещё тут "решение"??

Я видел написанный на JS эмулятор 80486, в котором, прямо в бровсере, запускалось настоящее ядро линуха с настоящим шелом, и все это работало с какой-то более-менее сносной скоростью.

Человек, написавший такое — настоящий хакер. Уважаю непомерно!

Здравствуйте, Homunculus, Вы писали:

H>Заколеблешься мультиплатыорменность поддерживать без фреймворков и движков

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

Под стандартом я имею ввиду именно спецификацию языка/библиотеки, а не то, что на сайте MSDN (или в man'ах линукса) написано.

Здравствуйте, Артём, Вы писали:

Аё>Девиз многих плюсников. Особенно тех, кто не может рвзвернуть строку in place.

Ты вот две "половинки" строки поменяй меж собой местами in place, при том, что "половинки" могут быть разного размера. Потом поговорим.

Здравствуйте, Pzz, Вы писали:

Ага, случай из жизни. Заказ на прогу под iOS. Писал, писал. На Obj-C. Потом бац, заказчику под Винду захотелось. И дальше идет траходром с перепиской на MSVC и поддержкой двух версий. Не-не. Наелся.

Здравствуйте, Homunculus, Вы писали:

H>Ага, случай из жизни. Заказ на прогу под iOS. Писал, писал. На Obj-C. Потом бац, заказчику под Винду захотелось. И дальше идет траходром с перепиской на MSVC и поддержкой двух версий. Не-не. Наелся.

А можно было взять mingw'ный компилятор Obj-C под венду, и просто перекомпилировать.

Но вообще, Эппл специально так сделал, чтобы программы, написанные под ихнюю платформу, трудно было бы куда-то еще применить. Просто не надо было на эту уловку попадаться.

Здравствуйте, Pzz, Вы писали:

Pzz>А можно было взять mingw'ный компилятор Obj-C под венду, и просто перекомпилировать.

Нельзя. Работа с графикой. Очень платформо-зависима

Здравствуйте, maxkar, Вы писали:


M>Вот как раз зеленые потоки решают узкую задачу и добавляют кучу сложностей по управлению. Плюс требуют большой работы в JVM (например, весь I/O блокирующий переписать внутри). И в результате получается тот же фреймворк, с которым приходится дальше бороться. И вот совершенно не понятно, чем эти зеленые потоки принципиально лучше тех же Scala Future (примерно равно Java CompletableFuture).

В том-то и дело, что 99% кода не нужно знать ни про параллелизм, ни про асинхронность. А проблема фьюч, монад и корутин в том, что если где-то внизу есть асинхронный вызов, то фьючи, как раковая опухоль, расползаются по всему приложению. И в итоге приложение набито for comprehensions-ами тогда как собственно асинхронных вызовов в нем штук 10. Решения именно этой проблемы я жду от project loom. Нужно сделать кеш на фьюче? без проблем. Нужно получить её значение и вернуть вызывающей стороне? Делаешь future.get() и не заставляешь вызывающую сторону флетмаппить монады.

Здравствуйте, Homunculus, Вы писали:

Pzz>>А можно было взять mingw'ный компилятор Obj-C под венду, и просто перекомпилировать.

H>Нельзя. Работа с графикой. Очень платформо-зависима

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

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

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

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

Здравствуйте, Pzz, Вы писали:

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

Здравствуйте, Homunculus, Вы писали:

H>Ну так именно из-за такого подхода изначально я и взялся за переписывание на Винду. Но все равно гемора было много, так как мультиплатфоремнность изначально вообще не имелась ввиду. Сейчас имею ввиду ее всегда

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

Я лично вообще всегда писал с оглядкой на портабабельность. Знаю, многие считают, что так делать не надо, потому, что "кроме windows и x86 все равно ничего не бывает". А я всегда так делал, и мой код легко переносится.

Кроме всего прочего, портабельный подход приучает задумываться, а что вообще, в принципе, твоей программе надо от платформы. А задумываться, оно завсегда полезно.

Здравствуйте, Pzz, Вы писали:

Ф>>Так вот, фрэймворки тебе позволяют быстрее разбираться в чужом коде (и в своём тоже) хотя-бы просто потому что тебе придётся читать в 10 и то дажи и 100 раз меньше кода, чем если бы фрэймворка не было. Фрэймворки уменьшают кол-во хаоса в проекте и значительно облегчают тебе жизнь при подходе к чужим (и своим тоже) творениям.

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

Нет не разрушается. Слава богу, одни и теже фрэймворки часто используются во многих проектах: читать и расследовать приходится один раз.

Здравствуйте, scf, Вы писали:

scf>Один из ужасных типажей, который мне попадается на собеседованиях — квадратно-гнездовой фреймворщик: может рассказать про конфигурацию хибернейта, но не способен написать программу, сортирующую текстовый файл.

Хм, полная противоположность меня.
Могу с нуля выдумать ядрёную дичь, но впадаю в глубокий ступор как только требуется изучать чьё-то мутное АПИ.

Здравствуйте, Философ, Вы писали:

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

Ф>Нет не разрушается. Слава богу, одни и теже фрэймворки часто используются во многих проектах: читать и расследовать приходится один раз.

Если ты текст фреймворка наизусть знаешь, это, наверное, самая плохая характеристика для этого фреймворка.

Здравствуйте, scf, Вы писали:

scf> Решения именно этой проблемы я жду от project loom.

что насчет этой библиотеки http://www.gpars.org/ ?

Здравствуйте, maxkar, Вы писали:

M> private val cache = new HashMap[String, Future[AuthResult]]()

M> lock synchronized {
M> cache.getOrElseUpdate(sessionId, startAuth(sessionId))
M> }
А чем ConcurrentHashMap с computeIfAbsent не устраивает?

Здравствуйте, morgot, Вы писали:

M>Здравствуйте, Shmj, Вы писали:

S>>Какое решение?

M>Решение — не использовать никакие фреймворки. Это мусор и зависимость от автора . помню бурления на хабре, как автор реакта или чего что-то не так сделал. Надо везде использовать чистый код, ну или (если прям край как надо) библиотеку под конкретное дело (хттп запрос или еще что).

Кстати, как отличить фрэймворк от библиотеки, по каким критериям?

Аё>>Девиз многих плюсников. Особенно тех, кто не может рвзвернуть строку in place.
Pzz>Ты вот две "половинки" строки поменяй меж собой местами in place, при том, что "половинки" могут быть разного размера. Потом поговорим.
Книжки надо читать.
Там все написано...

Здравствуйте, TG, Вы писали:

TG>Здравствуйте, vaa, Вы писали:

M>>>Решение — не использовать никакие фреймворки. Это мусор и зависимость от автора . помню бурления на хабре, как автор реакта или чего что-то не так сделал. Надо везде использовать чистый код, ну или (если прям край как надо) библиотеку под конкретное дело (хттп запрос или еще что).

vaa>>Кстати, как отличить фрэймворк от библиотеки, по каким критериям?

TG>Фреймворк привносит/диктует архитектуру, библиотека — нет.

Нашел более простое объяснение:
В случае с библиотекой вы решаете где и как использовать ее функционал.
И наоборот, не вы подключаете фреймворк к своему коду, а он подключает ваш код к себе.

Именно наличие инверсии управления – основная разница между библиотекой и фреймворком.

Даже стало как-то понятней откуда столько боли от них.

Здравствуйте, Pzz, Вы писали:

Pzz>Ты учти, кстати, что ценой внешней простоты Go является неимоверная сложность под капотом. Видно, что настоящие олдовые хакеры писали, не нонешнее племя.

Вот именно хакеры. Что больше всего бесит в Go — создатели проигнорили почти все, что долго и больно нарабатывалось разработчиками языков десятилетиями. И с завидным энтузиазмом зашагали по старым, давно пройденным граблям. Что то они потом фиксили, но большая часть останется с Go навсегда.

Pzz>По-моему, ничего лучше, чем go build, для сборки пока не придумано.

Как определил?

Pzz>Я даже в одном своем личном проекте сделал над ним "обертку", которая, как раз, позволяла собирать сишные библиотеки и программы. Но не довел до состояния, когда можно другим показывать.

Очередное "с блэкджеком и шлюхами" от создателей.

Здравствуйте, Ночной Смотрящий, Вы писали:

Pzz>>Ты учти, кстати, что ценой внешней простоты Go является неимоверная сложность под капотом. Видно, что настоящие олдовые хакеры писали, не нонешнее племя.

НС>Вот именно хакеры. Что больше всего бесит в Go — создатели проигнорили почти все, что долго и больно нарабатывалось разработчиками языков десятилетиями. И с завидным энтузиазмом зашагали по старым, давно пройденным граблям. Что то они потом фиксили, но большая часть останется с Go навсегда.

Создатели Go предполагают, что они в силах протоптать новую тропинку в индустрии.

Если учесть, что из их прошлых созданий, типа UNIX и Plan9 куча полезных идей перешла в mainstream, часто без понимания mainstream'ом, откуда та или иная идея взялась, их предположение не так уж безосновательно.

Pzz>>По-моему, ничего лучше, чем go build, для сборки пока не придумано.

НС>Как определил?

Сошлюсь на субЪективный опыт.

Здравствуйте, Pzz, Вы писали:

Pzz>Создатели Go предполагают, что они в силах протоптать новую тропинку в индустрии.

Сомневаюсь. Скорее огни страдают недостатком специфического бекграунда (создание ЯВУ это очень специфический бекграунд).

Pzz>>>По-моему, ничего лучше, чем go build, для сборки пока не придумано.
НС>>Как определил?
Pzz>Сошлюсь на субЪективный опыт.

Это не ответ на вопрос. Вообще непонятно о чем ты.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Еще, кстати, подумай как ты в своих green threads будешь делать cancellation чтобы не разломать нафик весь стейт у кода, который про асинхронность не в курсе.

как обычно — через interrupt? Не понимаю, почему оно должно разломаться, у зеленых потоков точки отмены те же самые, что и у обычных: блокирующие вызовы.

Здравствуйте, Ночной Смотрящий, Вы писали:

Pzz>>Создатели Go предполагают, что они в силах протоптать новую тропинку в индустрии.

НС>Сомневаюсь. Скорее огни страдают недостатком специфического бекграунда (создание ЯВУ это очень специфический бекграунд).

У Пайка это где-то уже примерно 6-й язык. И C был создан тоже примерно этими людьми.

Здравствуйте, Pzz, Вы писали:

Pzz>И C был создан тоже примерно этими людьми.

Как будто Си это что-то хорошее.

Здравствуйте, so5team, Вы писали:

Pzz>>И C был создан тоже примерно этими людьми.

S>Как будто Си это что-то хорошее.

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

Здравствуйте, scf, Вы писали:

scf>как обычно — через interrupt? Не понимаю, почему оно должно разломаться, у зеленых потоков точки отмены те же самые, что и у обычных: блокирующие вызовы.

Нет конечно. В дотнете, к примеру, есть такой CancellationToken, который, как правило, передается явно во все асинхронные методы. И ты волен реализовать любую стратегию отмены и реакции на него. А вот с green threads все плохо.

Здравствуйте, vaa, Вы писали:

vaa>Кстати, как отличить фрэймворк от библиотеки, по каким критериям?

Библиотека не меняет логику всей программы. Просто для каких-то целей можно использовать функции оттуда. Фреймворк же полностью замыкает всю логику на себя. могу привести пример, допустим jquery в моем понимании — библиотека, потому что можно смешивать с чистым жс; в то время как Vue/React — фреймворки.

Здравствуйте, Ночной Смотрящий, Вы писали:

Pzz>>У Пайка это где-то уже примерно 6-й язык. И C был создан тоже примерно этими людьми.

НС>К сожалению, идеологически уровень Go недалеко от С и Лимбо ушел. Как будто не было лиспа, кучи экспериментов в Хаскеле, языков поколения java/c#/scala/kotlin.

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

Некоторым это нравится, некоторым — нет. У той и ы другой стороны есть свои аргументы, которые много раз приводились, думаю, смысла повторять еще раз их нет.

Думаю, мы тут с тобой стоим на разных сторонах.

С нами — великий Дейкстра, с вами — великий Страуструп!

Здравствуйте, Pzz, Вы писали:

Pzz>Идея, которая стоит за языком Go, заключается не в том, чтобы добавить в язык все возможные фичи, а в том, чтобы выкинуть из него все, что может быть выкинуто.

Да я то не спорю. Только проигнорировав весь накопленный опыт мы получили старые грабли.

Здравствуйте, so5team, Вы писали:

Pzz>>Хорошее оно или плохое, но

S>но если авторы Си не смогли лучше тогда, то несколько наивно ожидать, что потом они стали выдавать что-то принципиально лучшее.

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

Здравствуйте, Pzz, Вы писали:

S>>но если авторы Си не смогли лучше тогда, то несколько наивно ожидать, что потом они стали выдавать что-то принципиально лучшее.

Pzz>А что значит, "лучше"?

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

Ну как к сегодняшним. Актуально это уж лет 25 точно.

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

Сам Си никаких языков не производил.
Си оказался достаточно хорош для того, чтобы на нем написали огромное количество софта, от которого уже никто и никогда не откажется. Вот это да.

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

Здравствуйте, ltc, Вы писали:

ltc>Проблема есть. Миллионы человеко-дней по всему миру тратятся на то, чтобы разобраться с очередным фреймворком, люди по сути делают одно и то же, многократно дублируя свои усилия, наступают на одинаковые грабли.

Подожди. Освободившихся людей куда ты денешь ?

scf>В целом jvm мир дрейфует в эту сторону. На острие прогресса находится Scala — и атомарные библиотеки, и простота (местами). Даже до джавистов начинает доходить, что зачем нужны аннотации, если можно описать тот же функционал несколькими строками кода.
<...>
scf>Проблема в том, что язык формирует мышление. Без поддержки лямбд сложно объяснить, что map/flatMap — это хорошая идея.

Еще лет 10, и может доберется до простоты функциональных языков (Erlang, Haskell).

M>Вот как раз зеленые потоки решают узкую задачу и добавляют кучу сложностей по управлению.

Согласен! Уже не впервые вижу, как попытки добавить massive concurrency не очень хорошо получаются в силу изначальной заточенности языка под последовательное исполнение.

На мой взгляд, чтобы это взлетело, концепция языка (а значит и его синтаксис, и семантика) должны существенным образом измениться. Примерно так же, как добавление асинхронности через всякие там continuations и coroutines выглядит неэлегантно в сравнении с языковой поддержкой message passing.

scf> Решения именно этой проблемы я жду от project loom.

Как по мне так отличный повод взглянуть на Elixir/Erlang/LFE.

НС>Что больше всего бесит в Go — создатели проигнорили почти все, что долго и больно нарабатывалось разработчиками языков десятилетиями. И с завидным энтузиазмом зашагали по старым, давно пройденным граблям. Что то они потом фиксили, но большая часть останется с Go навсегда.

Это называется "organic growth". Язык на начальной стадии своего создания должен был решать вполне конкретные проблемы — уйти от Питоно-ужаса, но при этом сохранить очень низкие требования к квалификации программиста. А дальше — стандартная ловушка, как с JavaScript, если с самого начала расчет на "низкий входной барьер", то в какой-то момент таки придется вернуть "взятую в долг" сложность (complexity).

НС>Нет конечно. В дотнете, к примеру, есть такой CancellationToken, который, как правило, передается явно во все асинхронные методы. И ты волен реализовать любую стратегию отмены и реакции на него. А вот с green threads все плохо.

Что именно плохо? Идентификатор того самого green thread и есть cancellation token. Если нужно "отменить" асинхронный вызов, просто терминируешь этот green thread, и все (внутри он может реализовать "реакцию отмены", хотя обычно это может сделать VM — освободить память, файловые дескрипторы и т.п.)

Здравствуйте, Sinclair, Вы писали:

Pzz>>Если ты текст фреймворка наизусть знаешь, это, наверное, самая плохая характеристика для этого фреймворка.
S>А по-моему — наоборот. Когда я программил на дельфи, возможность потрассироваться по исходникам VCL была бесценна. Потому, что на все случаи жизни учебников не напишешь.

Возможность почитать тексты — это хорошо, но вот необходимость — такое себе.

Что до образовательных целей, есть тексты и поинтереснее какого-то там фреймворка. То же ядро BSD, например.

Здравствуйте, SkyDance, Вы писали:

SD>Идентификатор того самого green thread и есть cancellation token. Если нужно "отменить" асинхронный вызов, просто терминируешь этот green thread

А с кодом, который там выполняется что происходит? Там исключение вылазит?

Здравствуйте, SkyDance, Вы писали:

SD>Это называется "organic growth". Язык на начальной стадии своего создания должен был решать вполне конкретные проблемы — уйти от Питоно-ужаса, но при этом сохранить очень низкие требования к квалификации программиста. А дальше — стандартная ловушка, как с JavaScript, если с самого начала расчет на "низкий входной барьер", то в какой-то момент таки придется вернуть "взятую в долг" сложность (complexity).

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

Здравствуйте, Pzz, Вы писали:

Pzz>Возможность почитать тексты — это хорошо, но вот необходимость — такое себе.

Исходник — лучшая документация. Возможность работать со сложным фреймворком без подробной документации — миф. А рассчитывать что с современной скоростью развития и сложностью фреймворков ты получишь подробную документацию, заменяющую исходный код — крайне наивно. Так что таки да, необходимость.

Здравствуйте, Pzz, Вы писали:

Pzz>А что значит, "лучше"? Си, видимо, "достаточно хорош", раз смог произвести такое количество практически используемых языков, созданных с большой оглядкой на него.

Во-первых, заимствование базового синтаксиса не означает, что это С произвел язык. Во-вторых причина не в том, что он как то особенно хорош, а в том что все привыкли к нему. По большому счету, от этого базового синтаксиса мало что зависит.

Здравствуйте, Pzz, Вы писали:
Pzz>Возможность почитать тексты — это хорошо, но вот необходимость — такое себе.
Тут я, конечно же, согласен. Но я так понял, что речь-то шла вовсе не о необходимости.
Pzz>Что до образовательных целей, есть тексты и поинтереснее какого-то там фреймворка. То же ядро BSD, например.
Ну, в каком-то смысле ядро BSD — это и есть фреймворк

Здравствуйте, Sinclair, Вы писали:

Pzz>>Что до образовательных целей, есть тексты и поинтереснее какого-то там фреймворка. То же ядро BSD, например.
S>Ну, в каком-то смысле ядро BSD — это и есть фреймворк

И что прекрасно, им можно пользоваться, не читая его текстов

Здравствуйте, ·, Вы писали:

·>А чем ConcurrentHashMap с computeIfAbsent не устраивает?

Только тем что я им редко пользуюсь и он мне в голову не пришел . Я скорее про TrieMap вспомню, там нет подобного (getOrElseUpdate может операцию запускать но не сохранять результат). Спасибо за напоминание, у меня есть тут пара ситуаций, где именно ConcurrentHashMap с computeIfAbsent будет наиболее уместным.

Здравствуйте, maxkar, Вы писали:

M>Не расползаются. Оно сразу в for-comprehension идет. И с полиморфизмом высшего порядка:

Не спорю, монады и for-comprehension полезны и удобны, когда применяются по делу. Я имел в виду, что если мы имеем цепочку вызовов:
def handleRequest: Response
def checkJwt: Option[Whatever]
def parseClaims: Option[String]
def sendAudit: Unit

если вдруг захотелось сделать отправку аудита асинхронной, и чтобы код дожидался её окончания, то придется всю эту цепочку оборачивать в эффект:
def handleRequest: F[Response]
def checkJwt: F[Option[Whatever]]
def parseClaims: F[Option[String]]
def sendAudit: F[Unit]

Хотя всему этому коду совершенно не нужно знать, что где-то глубоко внизу кто-то что-то сделал асинхронно. Но придется всё переписывать на for comprehension.
Конечно, можно сказать "мы весь код пишем на эффектах" и из бага это превратится в фичу, но for comprehension при всех его преимуществах куда менее удобен, чем примитивный код с вызовами методов и if-ами.

Здравствуйте, Shmj, Вы писали:

S>В итоге вместо изучения вещей базовых — тратится время на изучение продукта жизнедеятельности тех или иных авторов. Надоело вкрай.

Именно так. Фремворк понижает стомость входа для большинства типовых задач. Соответсвенно, снижаются требования к квалификации. Отсюда ясно, что будет скучно, если тебе нравятся сложные задачи.

Что делать — нужно идти в новые области.

Здравствуйте, sambl74, Вы писали:

ltc>>Проблема есть. Миллионы человеко-дней по всему миру тратятся на то, чтобы разобраться с очередным фреймворком, люди по сути делают одно и то же, многократно дублируя свои усилия, наступают на одинаковые грабли.

S>Подожди. Освободившихся людей куда ты денешь ?

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