ScalaQL, ассиметричный ответ на LINQ

> ХЗ, как дело обстоит в Склале

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

>тормозы и не поняли, что такое LINQ >А что такое LINQ?

>Language Integrated Query Совсем не SQL, как эти тормозы подумали. >Предложения выглядят несколько SQL подобно, но это побочный эфект. >Более того, так как SQL какправило в хранимых процедурах, то толку от >linq2sql почти никакого. Разве что nhibernate переписать чтобы >поприкольнее выглядело. >Благодаря LINQ можно писать нормальный лямбда выражения.

Видно ты не знаком со Scala. For-выражения дают возможность делать то же самое, что и linq + списки. ScalaQL просто даёт возможность использовать эти выражения для работы с БД. Причем (и это главная тема работы - main point) используя только возможности Scala без каких-либо препроцессоров и плугинов к компилятору.

> EJB - это вообще самое гадкое, что есть в J2EE, и история мутации спецификации на них это подтверждает.

Пока что только одна серьёзная мутация произошла: EJB 2.0 -> EJB 3.0

> Не надо с них брать пример. :)

Вообще, не надо ни с чего брать пример, а делать собственную/предметную domain driven architecture в каждом конкретном случае.

>> Они хороши только в одном случае

> Они хороши везде. Вы не умеете их готовить.

Реляционные СУБД вообще не нужны. Это — прошлый век.

> О еще один жабщичек че

> я когда пять лет назат тут писал че питон е то будущее тоже громче всех жабщики > орали че недоезычок и без фигурных скобачек не нужин. и че? време идет мир меняется вот уже гуголь за петон взялсе а жабщики все те же

>та дурни своево ума нету хоть на тот же гуголь смотрите где тамо sql где тамо ваши рдбмс? на амазон посмотри где тамо sql? вы головой хоть из окопа вертите иногда

PERL, JavaScript, Python, PHP — это всё "мусорные языки", "еда быстрого приготовления", fast food. На них пишут только write-only код. Почитайте в браузере, что шлёт вам GMail. Не зря Столлман рвал на себе бороду, захлёбываясь слюною: "как инспектировать этот код и нужно ли это делать?"

> Пока что только одна серьёзная мутация произошла: EJB 2.0 -> EJB 3.0

Добавление home интерфейсов - тоже мутация - архитектурная.

Добавим сахарку, а почему в Netweaver используют совместно ABAP и JAVA

кстати посмотрите на ABAP

Упс, local интерфейсов.

>ScalaQL просто даёт возможность использовать эти выражения для работы с БД.
Видимо вы не знакомы с Linq и моим предыдущим сообщением, смысл которого был в том, что ScalaQL реализует только Linq2sql, который, по моему, самый бесполезный.

>>ScalaQL просто даёт возможность использовать эти выражения для работы с БД. >Видимо вы не знакомы с Linq и моим предыдущим сообщением, смысл >которого был в том, что ScalaQL реализует только Linq2sql, который, по >моему, самый бесполезный.

Так в том-то и дело, что синтаксическая поддержка монадическх вычислений (linq + списки) уже реализованы vanilla scala в виде for-выражений. А в том, что авторы работы проводят параллели между своим DSL (for-expression2sql) и linq2sql, не затрагивая более широкого спектра возможностей linq/for-выражений, я не вижу ничего, позволяющего называть их тормозами.

Видимо вы не знакомы с Linq и моим предыдущим сообщением, смысл которого был в том, что ScalaQL реализует только Linq2sql, который, по моему, самый бесполезный.

Это ты по ходу не понял о чем речь:

scala> object LOR {
     |   val l = "LOR" :: "is" :: "full" :: "of" :: "whores" :: "playing" :: "blackjack" :: Nil
     |   def map[B](f : String => B) = l.map(f)
     | }
defined module LOR

scala> for(x <- LOR) yield x
res6: List[String] = List(LOR, is, full, of, whores, playing, blackjack)

Нету никакого SQL.

Это вы по ходу не поняли о чем речь. Как и составители новости. При чём здесь списки, не понятно. Если вы хотите продемонстрировать Скалу, то оно мне не интересно, так как по моему личному мнению является тупиком развития Java.

>Нету никакого SQL.
Действительно! А мы про Linq2sql :)
А ещё это можно реализовать на паре сотен живых языков
Так-же обратите внимание, что вам пришлось вставлять промежуточные костыли-мапы

На досуге попробйте смоделировать Linq2xml
например
IEnumerable<XElement> elements =
from e in xDocument.Descendants("BookParticipant")
where ((string)e.Attribute("type")) != "Illustrator"
orderby ((string)e.Element("LastName"))
select e;
Оратите внимание, на то, что это понятно даже человеку не знакомоу с С#

> На досуге попробйте смоделировать Linq2xml
> например
> IEnumerable<XElement> elements =
> from e in xDocument.Descendants("BookParticipant")
> where ((string)e.Attribute("type")) != "Illustrator"
> orderby ((string)e.Element("LastName"))
> select e;

Компилируемая программа вместе с XML фрагментом:

import scala.xml._

object XML {
val data =
<BookParticipants>
<Person type="illustrator">
<LastName>John</LastName>
</Person>
<Person type="troll">
<LastName>grim</LastName>
</Person>
</BookParticipants>

def compareText(a: Node, b: Node) =
(a \ "LastName").text < (b \ "LastName").text

def main(args: Array[String]) = {
(for (
el <- data \ "Person"
if el \ "@type" != "illustrator") yield el
).toList.sort(compareText)
}
}

Должно быть понятно человеку, знакомому с Xpath )

Это добавление локальных интерфейсов имеется в виду? Если да, то это не мутация, а узаконивание общей практики.

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

Так-же обратите внимание, что вам пришлось вставлять промежуточные костыли-мапы

Это не костыли, а демонстрация того что к for-comprehensions можно привести что угодно.

По вашему в linq это реализовано с помощью черной магии?

Все с точностью до точно так же только хуже это extension-методы к IEnumerable, в результате чего linq работает только с реализациями этого интерфеса. Вот реализация where.

public static IEnumerable<TSource> Where<TSource> (this IEnumerable<TSource> source, Func<TSource, bool>
 predicate)
{
    Check.SourceAndPredicate (source, predicate);
    return CreateWhereIterator (source, predicate);
}

В скале же есть структурные типы - поэтому я в этот синтаксис могу запихнуть вообще что угодно. Для того чтобы реализовать мой пример на шарпе пришлось бы сделать class LOR : IEnumerable<String> и вперед по методам.

PS: И откуда берется эта вера в черную магию у людей которые претендующих на звание технических специалистов?

Чуть поформатировал:

import scala.xml._

object XML {
  val data =
  <BookParticipants>
    <Person type="illustrator">
      <LastName>John</LastName>
    </Person>
    <Person type="troll">
      <LastName>grim</LastName>
    </Person>
  </BookParticipants>
}

object XScalinq extends Application {
  def compareText(a: Node, b: Node) = (a \ "LastName").text < (b \ "LastName").text

  println(
    (for (
      el <- XML.data \ "Person"
      if el \ "@type" != "illustrator"
    ) yield el).toList sort compareText)
}

Да, в 3 раза больше кода.
Подсказка- Речь не о том, что это нельзя сделать в других языках.

>Да, в 3 раза больше кода.

Ты шо скрипачь - буквы считать разучился? Или не умел?

Вот еще развлекалово:

object Scalainq {
  implicit def from[A](s: Seq[A]) = new Scalainq(s);
}

class Scalainq[A](seq: Seq[A]) {
  def where(p: A => Boolean) = seq filter p
  def select[B](p: A => B) = seq map p
  def orderby[B <% Ordered[B]](f: A => B) = seq.toList sort ((a, b) => f(a) < f(b))
}

object Main extends Application {
  import Scalainq._
  val list = 1 :: 6 :: 3 :: 2 :: 5 :: Nil
  val result =  from (list) where (_ % 2 == 1) select (_ * 2) orderby (x => x)
  println(result)

==============
List(2, 6, 10)

Вы о чём спорите?
И с кем?
Вы хотте доказать что приведённые выше примеры можно реализовать на Скала? Так разве я вам возражаю?

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

Если вы напряжёте мозг, то поймёте что linq это набор интерфейсов, extentions и препроцессор, которые позволяют БЫСТРО и НАГЛЯДНО без закгромождения кода никому ненужными вспомогадельными объектами и кодом(как вы это сделали на Скала). При этом есть Linq2object, Linq2SQL, Linq2xml.

ps
И откуда берётся эта вера в собственную непогрешимость у людей претендующих на наличие мозгов?

Вы хотте доказать что приведённые выше примеры можно реализовать на Скала? Так разве я вам возражаю?

Ты возражаешь в том плане что С# LINQ мол божий дар а нигде так нельзя сделать. Тебе показывают что можно.

Если вы напряжёте мозг, то поймёте что linq это набор интерфейсов, extentions и препроцессор, которые позволяют БЫСТРО и НАГЛЯДНО без закгромождения кода никому ненужными вспомогадельными объектами и кодом(как вы это сделали на Скала).

Ты сильно болен. Ищи тут загромождение объектами:

val xresult =  from (XML.data \ "Person") where (_ \ "@type" != "illustrator") select (x => x) orderby (_.text)
println(xresult)
=========
List(<Person type="troll">
        <LastName>grim</LastName>
      </Person>)

Все это работает с предыдущим определением Scalainq и XML который привел коллега. А теперь сравни это со своим ужасом который ты назвал быстро и без загромождения.

И это без модификации компилятора.

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

Мы буквы считать умеем.

Маленькая модификация - отсутствие неободимости определять идентити и направление сортировки.

object Scalainq {
  implicit def from[A](s: Seq[A]) = new Scalainq(s);
  def self[A] = (x:A) => x
}

class Scalainq[A](seq: Seq[A]) {
  def where(p: A => Boolean) = seq filter p
  def select[B](p: A => B) = seq map p
  def orderby[B <% Ordered[B]](f: A => B) = seq.toList sort ((a, b) => f(a) < f(b))
  def ascending = seq
  def descending = seq reverse
}


object Main extends Application {
  import Scalainq._
  val list = 1 :: 6 :: 3 :: 2 :: 5 :: Nil
  var result: Seq[Int] =  from (list) where (_ % 2 == 1) select (_ * 2) orderby self ascending;
  println(result)
  result =  from (list) where (_ % 2 == 1) select (_ * 2) orderby self descending;
  println(result)
}

==========

List(2, 6, 10)
List(10, 6, 2)

>Ты возражаешь в том плане что С# LINQ мол божий дар а нигде так нельзя сделать. Тебе показывают что можно.
Почитайте мои предыдущие высказывания. http://www.linux.org.ru/view-message.jsp?msgid=3993411&page=3&lastmod...
Я всего-то писал, что Скалакл это ответ не на Linq а на Linq2xml

>Ты сильно болен. Ищи тут загромождение объектами:
Вы, передергиваете. В принципе начистопротность ваших методов была заметна и раньше, но теперь вы переходите на осколбления, чтож, буду называть выс Быдлом.

Так вот, неважаемое Быдло, думаете вы поните, что разговор о лишних объектах относился к
object LOR {
| val l = "LOR" :: "is" :: "full" :: "of" :: "whores" :: "playing" :: "blackjack" :: Nil
| def map[B](f : String => B) = l.map(f)
| }
defined module LOR

scala> for(x <- LOR) yield x

>Мы буквы считать умеем.
Ну, обезьяны тоже считать умеют, вам бы ущё думать научиться.

>ScalaQL реализует только Linq2sql, который, по моему, самый бесполезный.

/me грустно посмотрел на проект с 4-мя способами выполения запросов: HQL, Criteria API, Hibernate Native SQL и plain JDBC.

>/me грустно посмотрел на проект с 4-мя способами выполения запросов: HQL, Criteria API, Hibernate Native SQL и plain JDBC.
Это, кстати, одна из причин, я лет 7 назад начал с Java на .Net/mono перебираться.
На более-менее крупном проекте обнаруживается такое количество фрэймворков, что просто устаёшь с этим разбираться. Хотя сечас этим уже начали бороться, но на проектах, где всё хорошо, хватает и постоянных сотрудников.

>Это, кстати, одна из причин, я лет 7 назад начал с Java на .Net/mono перебираться. >На более-менее крупном проекте обнаруживается такое количество фрэймворков, что просто устаёшь с этим разбираться. Хотя сечас этим уже начали бороться, но на проектах, где всё хорошо, хватает и постоянных сотрудников.

Проблема не в множестве фреймворков, а в отсутсвие одного, который бы покрыл все задачи на 100%. В нашем конкретном случае — это мог бы быть LINQ. Увы.

>Я всего-то писал, что Скалакл это ответ не на Linq а на Linq2xml

На что тебе ответили что ты просто ничего не понял. Но тебе не помогло.

> Так вот, неважаемое Быдло, думаете вы поните, что разговор о лишних объектах относился к


Ох какой кретин. Ты вообще не понял что я сделал. Я тебе реализовал с помощью for comprehensions по методу а налогичному представленному в топичной работе для простого объекта, чтобы продемострировать мощь скальных компрехеншенов. Но ты слишком туп по ходу чтобы это понять.

>Ну, обезьяны тоже считать умеют, вам бы ущё думать научиться.

Да куда уж мне достич широт ваших вершин тупизны.

Linq2sql + Linq2dataset не сможет заменить ORM(imho)

>Linq2sql + Linq2dataset не сможет заменить ORM(imho)

В том-то и дело, что ORM на самом деле нам нафиг не сдался :) Зло это, хотя местами удобно начинать с ним.

Эээ... Я как бы то-же насмотрелся на проекты погибшие по вине не к месту применённых ORM, но в комплекте с тем-же Spring, бывает удобно.
Мне вообще-то обычно выбора не оставляют, так как обычно я попадаю на проект где "всё пропало!", поэтому я могу много рассказывать о плохом примененнеии той или иной технологии и поврьте, я ещё не видел ничего, что нельзя было-бы испортить, приложив достаточно усилий.

Год назад приводил в чуство проект, где разработчик не только умудрился применить все возможные антипатерны но и изобрёл несколько своих.
Особо повеселил способ обмена данными. Javascript генерировал xml, котрый затем через hidden input передавался на сервер, парсился SQL в таблицу, которая потом обрабатывалась тригером, потом бакенд закружал всё это и возвращалось через javascript, котрый генерировался inline вставками между HTML и asp.net тагов

Т.е. набор удобных технологий был использован неправльно, но это не говорит, что технологии неправильные.

>
Особо повеселил способ обмена данными. Javascript генерировал xml, котрый затем через hidden input передавался на сервер, парсился SQL в таблицу, которая потом обрабатывалась тригером, потом бакенд закружал всё это и возвращалось через javascript, котрый генерировался inline вставками между HTML и asp.net тагов

Интересно как же ты это вылечил.

Быдло зажигает :) Я ещё раз убедился в верности причисления вас к этой категории.

>Я тебе реализовал с помощью for comprehensions по методу а налогичному представленному в топичной работе для простого объекта, чтобы продемострировать мощь скальных компрехеншенов.
Зачем мне ваш быдлячий код? Я сделал простое замечание, что Скалакл это не ответ на Linq а на Linq2sql вы же понеслись приводить примеры на мёртвом никем не используемом языке, о которых никто вас не просил, более того, я открытым текстом писал, что Скала мне не интересен. Для JVM есть больше сотни таких мёртвых языков. Вы никого не удивили.

>В том-то и дело, что ORM на самом деле нам нафиг не сдался :) Зло это, хотя местами удобно начинать с ним.

Ну ёпрст. ORM нужен что бы описывать бизнес-логику с помощью модели предметной области. Если вы используете ORM просто как дергалку БД (а не как mapper), извлекая "худые" модели (тупо аттрибуты с геттерами сеттерами) с помощью DAO, то скорее всего бизенес-логика будет в Service Layer, хотя в нем не должно быть БЛ (только appication logic), а это есть процедурный подход. Я в общем на практике так и поступаю (ибо CRUD сплошной%) ), только что бы дергать БД обхожусть pure-jdbc.

Что вы предлагаете в замен? Ну пусть ScalaQL, Linq2SQL ... дергает некий набор данных по сложному запросу. А как моделируем БЛ? Опять старый добрый процедурный подход? Это скрорее вопрос поклонникам Scala и его ФП возможностей. Как в бизнес-приложениях использовать ФП? Ведь на DAL все не заканчивается, ибо не CRUD-ом единым живем=)

Давайте рассмотри на примере фаулеровского примера вычисления зачтенного дохода. Примеры на чем хотите, но что бы это было лучше ОО решения с применением ORM.

http://books.google.ru/books?id=FyWZt5DdvFkC&pg=PT140&lpg=PT140&d...

>Интересно как же ты это вылечил.
Никак. Это как и переход человека в категрию быдла, не лечится.

Тебе намек - если несколько человек по топику говорят что ты _не понял_ о чем эта статья - начни уже подозревать что что-то тут нечисто.

>Я сделал простое замечание, что Скалакл это не ответ на Linq а на Linq2sql

О боже какой же ты идиот. Ты _нихера не понял_ о чем эта статья.

>я открытым текстом писал, что Скала мне не интересен.

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

>Никак.

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

К твоему сведению все что ты перечислил может иметь объективные основания (может не всегда самый лучший вариант был выбран) - но основания под эти решения подобрать можно. Но ты как пресловутый канадский программист нихера не задумавыешься почему разработчик принял то или иное решение. Твоя риторика наполнена аморфными выражениями вроде "НАГЛЯДНО" ... "без закгромождения кода никому ненужными вспомогадельными объектами и кодом", и безосновательными утверждениями "в 3 раза больше кода" что выдает в тебе пионера, который нихрена не может подвести грамотные технических обоснования или провести сравнительный анализ - потому что сравнивать не с чем, дальше MSDN для c'n'p не ходившего, и как оно работает не задумывающегося.

Поздравляю. Ты типичный микрософтовский быдлокодер. Наверное даже сертифицированный.

> Зачем мне ваш быдлячий код? Я сделал простое замечание, что Скалакл это не ответ на Linq

Я вообще Scala не знаю, но даже мне понятно, что ответ на LINQ - это встроенные for-comprehensions. А ScalaQL - это DSL, построенный на их основе. Заголовок новости правда малость запутывающий.

Лень отвечать продуманно, отвечу лозунгами :)

Я сторонник Anemic Domain Model и считаю, что данные, вообще говоря, не обладают поведением, а значит и не надо его туда пихать.

Какое может быть поведение у кассового чека? Да миллион можно придумать. При этом структура чека, вообще говоря, может не меняться годами. Они как были 20 лет, так и сейчас по сути такие же. 20 лет назад можно было по ним считать план на следующую пятилетку, сегодня — наиболее выгодный день для рекламы пива.

>Давайте рассмотри на примере фаулеровского примера вычисления зачтенного дохода. Примеры на чем хотите, но что бы это было лучше ОО решения с применением ORM.

К сожалению, в реальности дрочение на ООП не приносит профита. Мне всё равно, будет ли это ОО-подход, структурный, функциональный, whatever. Главное, уложиться в требуемый треугольник качество-срок-бюджет.

Чисто с практической точки зрения, ORM порой приводит к таким проблемам, которые без него и не существовали. Борьба с тормознутостью из-за навигационного доступа путём кешей, которые вызывают ещё больше головной боли.

Хотя в простых случаях — да, может быть оправдано.

>http://books.google.ru/books?id=FyWZt5DdvFkC&pg=PT140&lpg=PT140&d...

Оооо. Да это же звездец полный. Навигационный доступ по реляционным данным.

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

Заодно поимеем модель, замусоренную всякими левыми методами. Ну то есть вот метод расчёта какой-то там revenue в продукте — он там зачем? Зачем приложению, которое занимается учётом продуктов на складе, этот метод?

Что мешает формулировать отчеты декларативно, отдельно от самих данных? Не хватает выразительной мощи языка, а SQL неудобен для динамического построения? Так с этим и надо бороться, а не пытаться натянуть жопу на глаз^W^W^Wреляционные данные на объекты.

К сожалению, с DML в LINQ не всё так радужно, хотя это проблема реализации, а не принципа.

Вы, Быдло, как всегда на высоте. Молодец! Прямо-таки образец того каким должен быть настоящий быдлован!

Вот статья:
Даниэл Спевак и Тьян Жао представили библиотеку ScalaQL для языка Scala, предоставляющую возможность заменять ORM на SQL-подобные конструкции языка запросов, подобного LINQ.

Уврав имена и мусор получим
ScalaQL заменять ORM на SQL-подобные конструкции языка запросов, подобного LINQ
Укажите, неуважаемое Быдло, фразу о том, что Скалакл, это что-то из того, что вы пытались демонстрировать в своих испражнениях.

>Да нихто и не сомневается что С# для тебя предел возможностей.
А вы сильны, в быдлячем способе ведения дискуссии! Это уже становится забавным, спасибо за развлечение :)

>Если вы хотите продемонстрировать Скалу, то оно мне не интересно, так как по моему личному мнению является тупиком развития Java.

Смотрите в новом сезоне. "grim против всего человечества"

Scala уже всеми признана логическим наследием и продолжением Java и только grim считает, что Java должна развиваться в другом направлении. Интересно, в каком?

> А вы сильны, в быдлячем способе ведения дискуссии! Это уже становится забавным, спасибо за развлечение :)

Привет, клоун. Это же ты ниасилил в Chrome сделать поле disabled/enabled ?

Ну я в целом согласен. Я тоже противник ORM=). Просто видел у фаулера на мой взгляд аргументированные утверждения в пользу ORM (читай ООП подхода в БД ориентированных приложениях) на задачах со сложной БЛ, а в жизни так этого самого ООП и не нюхал.

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

>К твоему сведению все что ты перечислил может иметь объективные основания (может не всегда самый лучший вариант был выбран) - но основания под эти решения подобрать можно.
Так вы, Быдло, тоже так пишете?! Класс! Чем больше вас таких разведётся, тем больше спрос и рэйт для нормальных программистов.
Опать таки, ресурс Быдла, для развлечения окружающих, просто неисчерпаем.

>Но ты как пресловутый канадский программист нихера не задумавыешься почему разработчик принял то или иное решение.
А зачем? Достаточно того, что вам подобный "специалист" стал легендой и ему пришлось уволиться, так как он сам не смог разобраться в собственном проекте :)
После этого последовательно с него сбежало 2 человека, и им пришлось искать контрактора, чтобы исправить то, что навояли такие как вы.

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

>Это же ты ниасилил в Chrome сделать поле disabled/enabled ?
Идёте на помощь коллеге по хамству? Кроме оскорблений аргументов нет.

Вы хоть суть проблемы с Chrome, поняли?
Могу ещё раз объяснить, так как из той дисскуссии только до вас похоже не дошло.

> Идёте на помощь коллеге по хамству? Кроме оскорблений аргументов нет.

в связях сексуального характера с тем субъектом замечен не был.

> Вы хоть суть проблемы с Chrome, поняли?
> Могу ещё раз объяснить, так как из той дисскуссии только до вас похоже не дошло.

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

>в связях сексуального характера с тем субъектом замечен не был.
И?
зачем было хамить?

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

Так вам обхяснить суть проблемы с Chrome? Или вы это написали только чтобы поругаться?

>ассимметричный неучи ёпта

Это расшифровывается как «ass симметричный», что ли?

...

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

>предоставляющую возможность заменять ORM на SQL-подобные конструкции языка запросов

Ужас. А если я захочу бэкенд с SQL на что-то другое сменить? Все классы переписывать? Фтопку...

>Я лучше налабаю на коленке быдло-код с sql-ем и пойду пить пиво.

Через год, когда понадобится вносить правки в код, ты будешь ковыряться и переделывать, а мы - будем пить пиво :)