В разных модулях можно, в рамках одного — один статический импорт. Ну и в принципе instance не first class value, хотя подозреваю что есть расширения на эту тему.
В скале нет классвов типов, они эмулируются с помощью неявных параметров. Context bounds — синтаксический сахар для этого, причём не всегда применимый.
С точки зрения решаемых задач — ничем не отличаются. С точки зрения реализации — по разному выражаются классы, типы и инстансы классов для типов. В хаскеле это делается отдельными языковыми конструкциями, выбор инстанса — статический. В скале всё описывается классами (в ОО-значении этого слова), выбор инстанса можно осуществлять динамически.
Если кратко в хаскеле можно описывать сложные классы, но нельзя манипулировать несколькими инстансами. В скале _очень_ сложно описывать сложные классы, но инстансы являются first-class values, со всеми вытекающими.
У меня винда при каждой загрузке 20 мин в бсоде проводит. 5 мин качает обновления, 5 мин накатывает, перезагружается, 10 мин втыкает что накатила. Всё это время работать невозможно. Опции показать оценку времени и отменить нах нет. Если невовремя отойдёшь от компа, может сотворить такую хрень прямо среди дня.
Про ублюдочность их ПО с точки зрения программиста даже думать не хочется. От неотключаемых брекпойинтов в VS до утекания лупбэк сокетов. Такое ощущение что при приёме на работу у них мозг ампутируют.
Любая статья литературна по определению, не? Или вы о чём?
Это всё замечательно, и грамотность, и литературный стиль, и русские классики, полностью согласен (хотя и немного хреново представляю что такое литературный стиль). Но я высказывался о совершенно других свойствах данной статьи.
Понятия не имею кто такой Найпол. Ссылки выше сформированы гуглением и отсеиванием неадекватного.
Нет, я бы предложил ограничить вложенность сложных предложений, длину предложений в принципе, не повторять сложные конструкции внутри одного предложения, избегать примечаний в скобках.
Тут мне всё понятно, но после 3 прочтений. Мне кажется это недопустимо много для столь простой мысли.
Правда, ну прочитайте хотя бы базовые гайды по написанию технических текстов. Это нереальное что-то. Я статью в ПФП бросил через 4 абзаца. Легче целую главу sicp или «Концепций и Моделей» прочитать и понять чем страницу вашего текста.
Другой важной причиной, почему руководители проектов с опаской и недоверием относятся к «эзотерическим» языкам программирования и нестандартным (не «мейнстримным») парадигмам, является то, что для получения серьёзного специалиста в таких языках и парадигмах необходимо вложить в него несравненно больше знаний, чем при использовании обыденных инструментов вроде объектно-ориентированного программирования.
Вы специально текст через обфускатор пропускаете? Чтобы пехапе-было-кодеры случайно не поняли о чём речь.
Можно, но захочет меньше. Не будет веской материальной причины — сосбвенно откоса от армии. И в 20 лет маме труднее продавить своё мнение о развитии чада, чем в 18.
С того, что 80% проблем с высшим образованием проистекают из невменяемо большого количества народу которое его получает. Не скажу, что армия является единственным источником этой проблемы, но процентов скажем на 20% это снизило бы загрузку ВУЗов.
> Здесь имеется ввиду то, что если вы программируете JSP/JSF или ASP.Net, или PHP (а именно на них в большинстве случаев идёт разработка), то как правило все веб-запросы выполняются независимо друг от друга. Поэтому, если вы специально не блокировали такую возможность, вы можете к одной базе данных подключить несколько веб серверов с серверами приложений.
Независимые друг от друга запросы мало кому нужны, обычно хочется чтобы после обновления баланса одной тётенькой-бухгалтером его и остальные увидели обновлённым. Все эти JSF, MVC, Rails и прочие по умолчанию переносят все проблемы синхронизации и межпроцессного взаимодействия на БД. Соответственно они и всплывают все и сразу на этом уровне.
> В ней автор с седьмой попытки выжал «1000» запросов в секунду из FireBird-а.
Автор занимался не тестированием РДБ, тем более что выборка ведётся из служебной таблицы содержимое которой даже ен приведено в статье, а запись даже не рассматривалась. Статья посвящена исследованию взаимодействия конкретного фреймворка с БД.
Взгляните ещё раз внимательно проблему которую пытаетесь рассмотреть в статье — она состоит из нескольких очень ортогональных частей. Вы пытаетесь свалить всё в кучу и решить оптом, это очень-очень сложно.
> поскольку мы всегда можем поставить рядом ещё один сервер и распараллелить сервера приложений и веб-сервера.
Вы научились распараллельвать произвольный алгоритм на произвольное число узлов? ACM в курсе?
> даже если сервер приложений и база данных находятся на одном компьютере, то из-за накладных расходов времени, мы не можем рассчитывать на выполнение более 8000 SQL-запросов за секунду
> сетевом взаимодействии задействовано ещё больше процессов, соответственно и число запросов уменьшается практически до 1000.
Очень интересно узнать: как измеряли/считали?
Моё любимое: github.com/scalaz/scalaz/blob/v7.0.0/core/src/main/scala/scalaz/std/Either.scala#L74 Я это пробовал читать частями, по 10ку лексем за вечер, на 3й забил (:
С точки зрения решаемых задач — ничем не отличаются. С точки зрения реализации — по разному выражаются классы, типы и инстансы классов для типов. В хаскеле это делается отдельными языковыми конструкциями, выбор инстанса — статический. В скале всё описывается классами (в ОО-значении этого слова), выбор инстанса можно осуществлять динамически.
Если кратко в хаскеле можно описывать сложные классы, но нельзя манипулировать несколькими инстансами. В скале _очень_ сложно описывать сложные классы, но инстансы являются first-class values, со всеми вытекающими.
Про ублюдочность их ПО с точки зрения программиста даже думать не хочется. От неотключаемых брекпойинтов в VS до утекания лупбэк сокетов. Такое ощущение что при приёме на работу у них мозг ампутируют.
Это всё замечательно, и грамотность, и литературный стиль, и русские классики, полностью согласен (хотя и немного хреново представляю что такое литературный стиль). Но я высказывался о совершенно других свойствах данной статьи.
Понятия не имею кто такой Найпол. Ссылки выше сформированы гуглением и отсеиванием неадекватного.
Нет, я бы предложил ограничить вложенность сложных предложений, длину предложений в принципе, не повторять сложные конструкции внутри одного предложения, избегать примечаний в скобках.
www.oup.com/us/samplechapters/0841234620/
www.e-education.psu.edu/styleforstudents/c10_p6.html
К сожалению там приходится отделять специфичные для английской грамматики вещи от общих идей, но в принципе понятно.
Видел подобные руководства на русском, но поисковая выдача по «текстам» и «написанию» забита CEOшниками :(
Правда, ну прочитайте хотя бы базовые гайды по написанию технических текстов. Это нереальное что-то. Я статью в ПФП бросил через 4 абзаца. Легче целую главу sicp или «Концепций и Моделей» прочитать и понять чем страницу вашего текста.
Вы специально текст через обфускатор пропускаете? Чтобы пехапе-было-кодеры случайно не поняли о чём речь.
Значит нужен не список, а массив или словарь, не?
Независимые друг от друга запросы мало кому нужны, обычно хочется чтобы после обновления баланса одной тётенькой-бухгалтером его и остальные увидели обновлённым. Все эти JSF, MVC, Rails и прочие по умолчанию переносят все проблемы синхронизации и межпроцессного взаимодействия на БД. Соответственно они и всплывают все и сразу на этом уровне.
> В ней автор с седьмой попытки выжал «1000» запросов в секунду из FireBird-а.
Автор занимался не тестированием РДБ, тем более что выборка ведётся из служебной таблицы содержимое которой даже ен приведено в статье, а запись даже не рассматривалась. Статья посвящена исследованию взаимодействия конкретного фреймворка с БД.
Взгляните ещё раз внимательно проблему которую пытаетесь рассмотреть в статье — она состоит из нескольких очень ортогональных частей. Вы пытаетесь свалить всё в кучу и решить оптом, это очень-очень сложно.
Вы научились распараллельвать произвольный алгоритм на произвольное число узлов? ACM в курсе?
> даже если сервер приложений и база данных находятся на одном компьютере, то из-за накладных расходов времени, мы не можем рассчитывать на выполнение более 8000 SQL-запросов за секунду
> сетевом взаимодействии задействовано ещё больше процессов, соответственно и число запросов уменьшается практически до 1000.
Очень интересно узнать: как измеряли/считали?