Re[5]: Отказаться от кул-фреймворков и вернуться к истокам -
От: vsb Казахстан  
Дата: 02.06.22 22:18
Оценка:
Здравствуйте, 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 и их библиотеки. Там хватает своих проблем, но направление правильное.

Ну если руки таки дойдут до чего-то большего, чем сотрясание воздуха, то гляну, конечно. В жаве тоже есть определенное развитие, хотя и не такое быстрое, как хотелось бы. Например когда завезут именованную инициализацию записей, ей можно заменить именованные параметры.
Re[5]: Отказаться от кул-фреймворков и вернуться к истокам -
От: vsb Казахстан  
Дата: 02.06.22 22:21
Оценка:
vsb>> К примеру асинхронность не нужна, что убирает уйму сложности.

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


Не нужна в контексте того, что в жаву скоро привезут зелёные потоки и обычный код станет работать так же, как асинхронный (ну плюс-минус).
Re[2]: Отказаться от кул-фреймворков и вернуться к истокам - плюсы и минусы
От: Эйнсток Файр Мухосранск Странный реагент
Дата: 03.06.22 00:29
Оценка:
scf>Один из ужасных типажей, который мне попадается на собеседованиях — квадратно-гнездовой фреймворщик: может рассказать про конфигурацию хибернейта, но не способен написать программу, сортирующую текстовый файл.

Нет, ужасный типаж на этом собеседовании это Вы.
У вас не проработано методическое обеспечение, полная профессиональная несостоятельность.
Так бы дали ему собственноручно написанный учебный курс и новый сотрудник втянулся бы.
Re: Отказаться от кул-фреймворков и вернуться к истокам - плюсы и минусы
От: so5team https://stiffstream.com
Дата: 03.06.22 05:05
Оценка: +3 :)))
Здравствуйте, Shmj, Вы писали:

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


Быть мужиком, сделать свое по большому, пусть другие тратят время на изучение продукта вашей жизнедеятельности.
Re: Отказаться от кул-фреймворков и вернуться к истокам - плюсы и минусы
От: ltc  
Дата: 03.06.22 18:58
Оценка: :))
Здравствуйте, Shmj, Вы писали:

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


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

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

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


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


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

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

Это же, кстати, должно решить проблему с устареванием фреймворков и поддержкой новых платформ — достаточно будет перегенерировать код с помощью нового "фреймворка" по имеющимся данным, описывающим задачу. (Ну это же полная нелепица, когда целый софтверный гигант не в состоянии найти ресурсы чтобы переделать диалоговые окошки, чтобы они выглядели единообразно в новой винде)
Re: Отказаться от кул-фреймворков и вернуться к истокам - плюсы и минусы
От: vaa  
Дата: 03.06.22 23:43
Оценка:
Здравствуйте, 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% случаев будет качественнее
велосипеда одиночки. Нет, есть конечно люди выдающихся способностей, но большинство программистов это люди средних способностей
и что-то хорошее может родится только в большом коллективе.
Хоть у меня и скромный опыт, но на велосипеды насмотрелся.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[2]: Отказаться от кул-фреймворков и вернуться к истокам - плюсы и минусы
От: Артём Австралия жж
Дата: 04.06.22 06:55
Оценка: :)
Здравствуйте, so5team, Вы писали:

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


Девиз многих плюсников. Особенно тех, кто не может рвзвернуть строку in place.
Re[3]: Отказаться от кул-фреймворков и вернуться к истокам - плюсы и минусы
От: so5team https://stiffstream.com
Дата: 04.06.22 08:02
Оценка:
Здравствуйте, Артём, Вы писали:

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


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


Тёмчик, алгоритмическая подготовка не сможет компенсировать тебе отсутствие чувства юмора.
Re[6]: Отказаться от кул-фреймворков и вернуться к истокам -
От: maxkar  
Дата: 04.06.22 11:31
Оценка: 3 (2) +1
Здравствуйте, 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 у вас (да и зачем это знание вам нужно в прикладном коде?).
Re[2]: Отказаться от кул-фреймворков и вернуться к истокам - плюсы и минусы
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.06.22 11:52
Оценка:
Здравствуйте, scf, Вы писали:

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


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

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

Наверное, и с программистами можно так поступать.
Re[4]: Отказаться от кул-фреймворков и вернуться к истокам - плюсы и минусы
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.06.22 11:56
Оценка: +1
Здравствуйте, scf, Вы писали:

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


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


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

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

Очень был полезный человек, надо сказать.
Re[2]: Отказаться от кул-фреймворков и вернуться к истокам - плюсы и минусы
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.06.22 11:57
Оценка: +1
Здравствуйте, Философ, Вы писали:

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


К сожалению, эта иддилия разрушается тем фактом, что когда что-то неработает вокруг фреймворка, нередко приходится читать текст самого фреймворка.
Re[2]: Отказаться от кул-фреймворков и вернуться к истокам - пл
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.06.22 11:59
Оценка: +1
Здравствуйте, vsb, Вы писали:

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


Короче, когда я ложусь в кровать, то чтобы быстрее заснуть, я делаю в уме революцию
Re[4]: Отказаться от кул-фреймворков и вернуться к истокам -
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.06.22 12:14
Оценка:
Здравствуйте, 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-клиента и промерно столько же серверов. Все они очень хорошо и удачно сидели в том месте, для которого были написаны, но как-то обобщить и вынести их в отдельную библиотеку не очень-то получается.
Re[5]: Отказаться от кул-фреймворков и вернуться к истокам -
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.06.22 12:20
Оценка:
Здравствуйте, maxkar, Вы писали:

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


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

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

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


Фича очень полезная, если предполагается хранить конфиги в JSON'е, и чтобы человек мог их редактировать. Хотя я лично все равно предпочитаю для конфигов синтаксис .INI-файлов, он гораздо более человеческий.
Re[2]: Отказаться от кул-фреймворков и вернуться к истокам - плюсы и минусы
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.06.22 12:26
Оценка:
Здравствуйте, Kolesiki, Вы писали:

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


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

Человек, написавший такое — настоящий хакер. Уважаю непомерно!
Re[2]: Отказаться от кул-фреймворков и вернуться к истокам - плюсы и минусы
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.06.22 12:29
Оценка:
Здравствуйте, Homunculus, Вы писали:

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


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

Под стандартом я имею ввиду именно спецификацию языка/библиотеки, а не то, что на сайте MSDN (или в man'ах линукса) написано.
Re[3]: Отказаться от кул-фреймворков и вернуться к истокам - плюсы и минусы
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.06.22 12:31
Оценка:
Здравствуйте, Артём, Вы писали:

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


Ты вот две "половинки" строки поменяй меж собой местами in place, при том, что "половинки" могут быть разного размера. Потом поговорим.
Re[3]: Отказаться от кул-фреймворков и вернуться к истокам - плюсы и минусы
От: Homunculus Россия  
Дата: 04.06.22 12:41
Оценка:
Здравствуйте, Pzz, Вы писали:

Ага, случай из жизни. Заказ на прогу под iOS. Писал, писал. На Obj-C. Потом бац, заказчику под Винду захотелось. И дальше идет траходром с перепиской на MSVC и поддержкой двух версий. Не-не. Наелся.
Re[4]: Отказаться от кул-фреймворков и вернуться к истокам - плюсы и минусы
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.06.22 12:46
Оценка:
Здравствуйте, Homunculus, Вы писали:

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


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

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