LINUX.ORG.RU

Oxdeadbeef нахуй отсюда, срочно

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

например, FastParse в скале

Этот FastParse будет работать в compile-time в Scala?

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

Там тоже есть проверка выхода за границу

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

у вас ошибка в тесте по первой ссылке: вы myvector.reserve(9999999) забыли написать

Тогда надо сделать аналогично и для кода на Си

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

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

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

Данная конкретная либа — нет. Множество других — да.

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

Спасиб. Все время забываю, что в Scala макросы добавили.

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

Это как так? В динамически выделяемой памяти, оператором malloc, никаких проверок нет и быть не может. Ты можешь выделить массив в 3 элемента, а обратиться к 33-му. Само по себе это не вызовит ошибки.

hotpil ★★★ ()

Всегда подозревал, что в google много разных какашко подъедателей.

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

тут дело не в самих плюсах, а в STL.

Где-то я даже читал, что само по себе программирование в ООП стиле дает в итоге ХУДШУЮ производительность, чем если все делать процедурно-императивно. Ну а если в плюсах писать как в Си и отключить все ненужности, связанные с обработками исключений, RTTI и прочее, скорость должна быть такая же

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

Я рекомендую посмотреть в сторону Scala.

В скале нет низкоуровневщины, которая есть в Си, плюсах, да даже в том же расте или в obj-c каком-нибудь. Для скалы требуется жирный рантайм (JVM) отчего его не впихнуть в микроконтроллеры, повышенное потребление ОЗУ. В скале есть обязательный GC, обязательный GC - плохо. Если б как в D можно было GC при желании вышвырнуть нафик и перейти на malloc-free и прочие подобные вещи - я не против, но я категорически против, когда мне этот GC навязывают.

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

Недостатков скалы, связанных с JVM и отсутствием первоклассной поддержки низкого уровня и других моделей памяти, я не отрицаю. С другой стороны, язык, который не навязывает модель памяти в итоге останется с экосистемой, раздробленной на сторонников различных моделей. «Ой, я хотел использовать либу X, но там модель памяти не той системы!» Понятно, что хочется всего и сразу, но скала является разумным решением для многих задач, для которых нужно метапрограммирование.

А принципиальных преград использовать другой рантайм для скалы нет. До недавнего времени скала поддерживала .NET-таргет, но он оказался никому не нужен, Scala.JS сейчас хорошо поддерживается и компилируется в JS. А при помощи вышеупомянутого LMS можно генерировать код хоть на C, хоть на JS, хоть на VHDL.

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

Ты можешь выделить массив в 3 элемента, а обратиться к 33-му.

А какие проверки будут при обращении к элементу вектора?

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

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

Только вот у самой Scala и раньше была репутация слишком сложного языка, а теперь эта репутация, боюсь, только усиливается. Взять, хотя бы пример со стартовой страницы упомянутого вами LMS:

class Vector[T:Numeric:Manifest](val data: Rep[Array[T]]) {
  def foreach(f: Rep[T] => Rep[Unit]): Rep[Unit] =
    for (i <- 0 until data.length) f(data(i))
  def sumIf(f: Rep[T] => Rep[Boolean]) = { 
    var n = zero[T]; foreach(x => if (f(x)) n += x); n }
}

val v: Vector[Double] = ...
println(v.sumIf(_ > 0))
Для многих разработчиков это ничуть не лучше хардкорного C++ с шаблонами и Boost.

А при помощи вышеупомянутого LMS можно генерировать код хоть на C, хоть на JS, хоть на VHDL.

Вопрос только в стоимости этого удовольствия.

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

Недостатков скалы, связанных с JVM

С++ не является инструментом моделирования ООП/ООД в отличие от Скалы/Явы. Классы C++ используются как форма записи низкоуровневых c-style структур.

А при помощи вышеупомянутого LMS можно

Можно всё. Вон на хаскеле можно через квазицитирование встраивать C. Это поможет? Нет.

У сверхвысокоуровневых языков типа скалы или хаскеля есть серьёзная проблема работы с низкоуровневыми объектами. И дело даже не столько в принципиальных тормозах FFI (их можно самортизировать), а в фундаментальной разнице между «мирами».

Даже в Go, эта разница уже существена.

Если отставить в сторону математическую (весьма нетривиальную) теорию, то мы получаем *сложнейший* языковой рантайм. В случае Скалы гвоздями прибитый к JVM, в случае хаскеля написанный на чистом C.

В C++ такого нет. Наоборот, в C++11 были ослаблены некоторые вещи, мешавшие взаимодействию.

Рантайм C++ даже с учётом изменений в C++11/C++14 и близко не приближается по сложности.

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

А при помощи вышеупомянутого LMS можно генерировать код хоть на C, хоть на JS, хоть на VHDL

на VHDL

Chisel или что-то другое?

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

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

Можно несколько примеров?

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

инструментом моделирования ООП/ООД

А что такое «моделирование объектно ориентированного дизайна»?

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

Для многих разработчиков это ничуть не лучше хардкорного C++ с шаблонами и Boost.

Ага, но в С++, со всей его сложностью, потребность есть. Опять же, в новых стандартах многое стало наоборот удобнее/проще, но очень распространено мнение, что "теперь язык целиком не знает никто". Сюда же нытьё про «раздутый стандарт».

Это я к тому, что скала чем хуже?

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

С другой стороны, язык, который не навязывает модель памяти в итоге останется с экосистемой, раздробленной на сторонников различных моделей. «Ой, я хотел использовать либу X, но там модель памяти не той системы!»

Выдуманная проблема. Одна из причин нужности того же С++ как раз в том, что он позволяет совмещать код с RAII, умными указателями, GC (в inkscape, например) и пр. с полностью ручным подходом как в С. И никому в голову не приходит на это жаловаться. Наоборот, многие к этому приходят. Microsoft запилила новый WinRT на С++, а C++/CLI заменила на C++/CX, где используется RC вместо GC. Apple тоже отказывается от GC в пользу ARC. В Rust отказались от GC. Александреску признал, что упор на GC в D был большой ошибкой. Сборка мусора как универсальное и навязываемое решение на все случаи жизни не прокатила. Это отличная идея, отлично работающая в большинстве задач, но есть много других задач, где нужен «язык, который не навязывает модель памяти».

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

нет низкоуровневщины
его не впихнуть в микроконтроллеры
обязательный GC - плохо

Я что-то пропустил, у тебя есть реальная (промышленная) задача, для которой это все имеет значение?

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

Взять, хотя бы пример со стартовой страницы упомянутого вами LMS

Отформатировано хреново конечно, а сложного-то там чего?

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

Есть реальные промышленные задачи писать RTOS для микроконтроллеров без MMU. Не важно, моя эта задача, или нет, но там эти скалы и прочие жабы идут лесом

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

Если использовать для доступа at(), то проверяется выход за границы. Если использовать оператор [], то вроде нет никаких.

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

Отформатировано хреново конечно, а сложного-то там чего?

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

Так же и здесь.

Проблемы языков вроде C++, Scala или Haskell в том, что программированием занимаются очень разные люди. Для кого-то потроха Boost-а — это открытая книга. А для кого-то шаблонная функция вроде accumulate — это сложно, распухание кода, непонятно во что раскрывается и т.д. При том, что вторые могут быть большими спецами в предметной области для которой они и пишут софт. И, как следствие, приносят больше пользы, чем первые.

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

Это я к тому, что скала чем хуже?

Насколько я могу судить, у Scala в рядах Java разработчика репутация такая же, как у C++ в рядах C-шников. Т.е. какому-нибудь махровому Java-программисту начать использовать преимущества Scala будет не проще, чем махровому C-шнику преимущества C++.

Да и менять C++ на Scala, без оглядки на специфику предметной области — это может быть тот еще совет :)

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

С++ не является инструментом моделирования ООП/ООД

Это вы мощно задвинули. Внушаить.

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

Сборка мусора как универсальное и навязываемое решение на все случаи жизни не прокатила.

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

Проблема в том, что любая реальная программа взаимодействует как минимум с операционной системой через c-style интерфейсы. В сверхвысокоуровневом языке приходится нести затраты на реализацию такого взаимодействия, как на уровне рантайма, так и на уровне апи. Это не всегда приемлемо.

Отюда, и определённый «возврат к истокам» у основных вендоров.

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

но там эти скалы и прочие жабы идут лесом

Прошу заметить, жаба прекрасно живёт в смарт-картах. А там MMU и не пахло.

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

Прошу заметить, жаба прекрасно живёт в смарт-картах

Сразу видно теоретика. То, что живет на смарт-картах - это терминально убогий огрызок Java.

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

Там Java Card, она даже на уровне байткода с нормальной жабой не совместима

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

concepts lite завезут только может быть в 1z, и то не факт. Доклад Александра Фокина рассказывает неплохо

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

Отлично прокатила.
Просто сборка мусора ставит крест на интероперабельности с детерминизмом.

/0

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

Тут нет никакой проблемы. Вообще.

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

Чушь.

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

Есть реальные промышленные задачи писать RTOS для микроконтроллеров без MMU

Понятно, с метапрограммирования математических алгоритмов лихо съехал на RTOS для микроконтроллеров :)

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

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

Так у тебя требования очень противоречивые. То «нормальное метапрограммирование» подавай, то «RTOS для микроконтроллеров». Ну нет «сейчас» одного языка, который бы удачно для всех задач подошёл. Так что придётся или разные инструменты использовать, ну или создавать «свой язык». Хотя можно и ограничиться жалобами на лоре на «несовершенство мира».

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

Там Java Card, она даже на уровне байткода с нормальной жабой не совместима

Шашечки или ехать? И не нужно мне пенять: я и так прекрасно знаю с чем она совместима, а с чем — нет. Факт остаётся фактом: ява с самого начала жила на весьма аппаратно ограниченных платформах.

Другое дело, что если Сану это было нужно (хотя в последнее время у них катастрофически не хватало ресурсов), то Ораклу уже нафиг не нужно.

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

Если использовать для доступа at(), то проверяется выход за границы.

Дык, в обсуждаемом коде нет at?

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

ну или создавать «свой язык»

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

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

На C++ подобную штуку можно было бы написать с таким же количеством закорючек.

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

Но нашлась бы куча народу, для которых это было бы сложно.

Так точно так же найдется и куча народу, для которой «угадай число» на бейсике - это ппц неподъемно. Я не вижу, как можно было бы упростить приведенный фрагмент (не выясняя даже, что такое Rep), сохраняя при этом все используемые в нем детали. Напиши хоть на псевдокоде, что ли.

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

Что же здесь сложного? Если не считать того, что авторы пустых строк пожалели, это простой идиоматический код, точно такой же будет на C# или на чем угодно. За двумя исключениями — вместо T используется обертка Rep[T], ну в этом и состоит сам фреймворк LMS, операции производятся не над объектами, а над их обертками, чтобы потом деревья можно было исполнять произвольным интерпретатором. Очень распространенный паттерн, см., например, http://underscore.io/blog/posts/2015/04/14/free-monads-are-simple.html И во-вторых, Manifest — это просто инструмент для интроспекции.

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

Насколько я могу судить, у Scala в рядах Java разработчика репутация такая же, как у C++ в рядах C-шников.

У меня такое же впечатление. Только, кажется, что мы делаем противоположные выводы.

Да и менять C++ на Scala, без оглядки на специфику предметной области — это может быть тот еще совет :)

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

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

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

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

Да зачем на псевдокоде? Там же есть пример, во что эта хрень раскрывается благодаря LMS:

var n: Double = 0.0
var i: Int = 0
val end = data.length
while (i < end) {
  val x = data(i)
  val c = x > 0
  if (c) n += x
}
println(n)
Собственно, многие разработчики, заточенные под конкретную предметку, вместо обобщенного кода будут вот такие циклы вручную писать и больше ничего не хотеть.

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

на все случаи жизни не прокатила.
Отлично прокатила.
Это не всегда приемлемо.

...

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

Но если я это на лор вброшу, отнесутся как к очередной «кодице» скорее всего, лол.

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

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

У меня такое же впечатление. Только, кажется, что мы делаем противоположные выводы.

Давайте сверим, что ли?

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

Правда, команду большего размера было бы проще собрать и проще сохранить (в том числе за счет более простой замены отдельных ее участников). Т.е. риски были бы меньше.

Так что, имхо, выбор Scala вместо Java, как и C++ вместо C (и даже C++14 вместо C++03) в большей степени определяется организационными проблемами, нежели техническими.

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

О том и речь :)

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