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

C>Аналогично с динамикой. К примеру, скрипты миграции БД на динамику ложатся очумительно красиво. Скажем, добавление полей в таблицу выглядит как операция с метаклассом.

Это ты рассказывай тем, кто вот этого не видел.

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

C>>Аналогично с динамикой. К примеру, скрипты миграции БД на динамику ложатся очумительно красиво. Скажем, добавление полей в таблицу выглядит как операция с метаклассом.
VD>Это ты рассказывай тем, кто вот этого не видел.
LOL. Ну представили DML в виде макросов. И что?

Как мне загрузить объекты, сменить у части из них тип, добавить к оставшимся новое поле и заполнить его вычисленным значением? Причём так, чтобы это не отличалось от обычной работы с ORM?

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

C>LOL. Ну представили DML в виде макросов. И что?

И все. Задача решена и еще к тому же статически проверяется при компиляции.

C>Как мне загрузить объекты, сменить у части из них тип, добавить к оставшимся новое поле и заполнить его вычисленным значением? Причём так, чтобы это не отличалось от обычной работы с ORM?

Твой мозг поражен извращениями. Зачем менять какие то там объекты когда можно описать ДСЛ и на нем описать свои намерения?

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

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

G>>Опишу более подробно: если есть "конкурентное преимущество в скорости работы", то полюбому напишут не +=, а Concat или Join в .NET
G>>Полных дебилов не рассматриваем.
_>Осталось ввести полный контроль на производстве, чтоб никто не подумал даже а простом и приятном +=, а писал все генерации строк только через регэкс, тк это оптимизировано и работает нативно. И указкой по пальцам "преступивших", в угол и на горох. Как-то не мотивирует.
_>В век перепроизводства преимущество имеет тот кто раньше сделает достаточно удобный продукт. += — короче, понятнее и быстрее кодится. stringbuilder нервно курит в сторонке.
Ты снова передергиваешь. Ведь ты можешь писать += на C# и в цикле. Нормальные программисты поправят твой код, никто не пострадает. Если нету тех кто может поправить, то видимо эта группа программистов зря взялась за .NET и им стоит писать на js.

G>>Да пусть пишут, что с того? Твои "тесты" от этого правильнее не становятся.
_>А какой код для js правильный?
_>1) с join, который дико тормозит/тормозил на ie (на последних версиях не проверял, может оптимизировали этот костыль для конкатенации строк)
_>2) или с +=, более стабильный и предсказуемый по скорости на разных реализациях.

Во-первых ты привел тесты где код разный по семантике. Во-вторых ты привел код, который далек от оптимального. В-третьих ты привел сценарий, который крайне редко встречается. Миллионы строк таким образом очень мало кто клеит тупо в циклах.
Теперь вопрос, что ты хотел сравнить? И что ты хотел этим показать?

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

W>>>Ок. Твой вариант кода. Цель вывести фильтр по списку элементов в строку.


W>>>

W>>>СтрокаФильтра = "";
W>>>Для Каждого Стр из СписокФильтра Цикл
W>>>    СтрокаФильтра = СтрокаФильтра  + ?(СтрокаФильтра = "", "", ", ") + Стр.Представление;
W>>>КонецЦикла;
W>>>

W>>>СписокФильтра — аналог TList.
W>>>В 1С нет +=, по этому написал его аналог.

G>>string.Concat, string.Join. выбирай что больше нравится.

W>Чем это будет отличаться от += ?
По результату нет, по скорости — да.

W>Это разве не склейка строк?
Склейка строк разная бывает. Ботай как работают управляемые среды (1C кстати тоже).

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

C>>LOL. Ну представили DML в виде макросов. И что?
VD>И все. Задача решена и еще к тому же статически проверяется при компиляции.
Она решена примерно на 10%. Точнее, вообще не решена, так как DML банально удобнее.

C>>Как мне загрузить объекты, сменить у части из них тип, добавить к оставшимся новое поле и заполнить его вычисленным значением? Причём так, чтобы это не отличалось от обычной работы с ORM?
VD>Твой мозг поражен извращениями. Зачем менять какие то там объекты когда можно описать ДСЛ и на нем описать свои намерения?
Затем, что я хочу работать с объектами, а не записями в БД.

Ура! мы выполнили задачу минимум!

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

G>Ты снова передергиваешь.
Да, я такой.

G>Ведь ты можешь писать += на C# и в цикле. Нормальные программисты поправят твой код, никто не пострадает. Если нету тех кто может поправить, то видимо эта группа программистов зря взялась за .NET и им стоит писать на js.
Я и пишу +=. И не надо мои мечтания затенять стрингбилдерами. Я верю в то, что += работает в с, с++, java, js, c# и работает достаточно эффективно чтоб не разбились мои мечты. Но когда _компилируемый_ ОО язык ведет себя странно с _объектами_ и проигрывает по скорости скриптовому языку это заставляет задуматься. То есть приходится думать не над логикой, а над тем как правильно писать элементарные операции. И без этого проблем хватает.
А на "нормальных" программистов ресурсов не хватило, проект еще не начал приносить деньги. Вот когда проект заматереет, тогда и пригласят "нормальных" для удержания рынка, переманят у конкурента, зацикленного на нормальности

G>>>Да пусть пишут, что с того? Твои "тесты" от этого правильнее не становятся.
_>>А какой код для js правильный?
_>>1) с join, который дико тормозит/тормозил на ie (на последних версиях не проверял, может оптимизировали этот костыль для конкатенации строк)
_>>2) или с +=, более стабильный и предсказуемый по скорости на разных реализациях.

G>Во-первых ты привел тесты где код разный по семантике. Во-вторых ты привел код, который далек от оптимального. В-третьих ты привел сценарий, который крайне редко встречается. Миллионы строк таким образом очень мало кто клеит тупо в циклах.
1) Я не юрист, поэтому не вижу разной семантики в приведенных тестах.
2) Это тест не про то как надо правильно оптимизировать код, а про то как два языка работают с объектами в частности со строками.
3) Я привел код, который в цикле выполняет наиболее часто встречающуюся строковую операцию в моем и не только в моем коде. Пока меня не приспичит показать свою крутость — собирать строки через формат или регекспы. Крайне _часто_ встречается

G>Теперь вопрос, что ты хотел сравнить? И что ты хотел этим показать?
Повторюсь.
Когда _компилируемый_ ОО язык ведет себя странно с _объектами_ и проигрывает по скорости скриптовому языку это заставляет задуматься. C# медленнее, Java еще медленнее. А зачем такие компиляторы (для меня), если они плохо работают с родными для языка и платформы абстракциями. Это проблемы языка/платформы. Не мои проблемы.
Это я хотел сперва проверить, посмотрел, удивился и решил поделится. Вот весь мой мотив.

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

G>>Ведь ты можешь писать += на C# и в цикле. Нормальные программисты поправят твой код, никто не пострадает. Если нету тех кто может поправить, то видимо эта группа программистов зря взялась за .NET и им стоит писать на js.
_>Я и пишу +=. И не надо мои мечтания затенять стрингбилдерами. Я верю в то, что += работает в с, с++, java, js, c# и работает достаточно эффективно чтоб не разбились мои мечты. Но когда _компилируемый_ ОО язык ведет себя странно с _объектами_ и проигрывает по скорости скриптовому языку это заставляет задуматься. То есть приходится думать не над логикой, а над тем как правильно писать элементарные операции. И без этого проблем хватает.
Ну правильно, += почти везде работает. Не работает только в "тесте" который ты привел.

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


Некогда пилу точить — пилить надо.


G>>>>Да пусть пишут, что с того? Твои "тесты" от этого правильнее не становятся.
_>>>А какой код для js правильный?
_>>>1) с join, который дико тормозит/тормозил на ie (на последних версиях не проверял, может оптимизировали этот костыль для конкатенации строк)
_>>>2) или с +=, более стабильный и предсказуемый по скорости на разных реализациях.

G>>Во-первых ты привел тесты где код разный по семантике. Во-вторых ты привел код, который далек от оптимального. В-третьих ты привел сценарий, который крайне редко встречается. Миллионы строк таким образом очень мало кто клеит тупо в циклах.
_>1) Я не юрист, поэтому не вижу разной семантики в приведенных тестах.
Для C++ — mutable строка, для C# и JS — immutable

_>2) Это тест не про то как надо правильно оптимизировать код, а про то как два языка работают с объектами в частности со строками.
Ну ты показал что js не освобождает память, а .NET освобождает... А нахрена ты время привел, для очевидно неоптимального кода?

_>3) Я привел код, который в цикле выполняет наиболее часто встречающуюся строковую операцию в моем и не только в моем коде.
"В цикле" — уже совершенно другая операция.



_>Когда _компилируемый_ ОО язык ведет себя странно с _объектами_ и проигрывает по скорости скриптовому языку это заставляет задуматься.
В первую очередь стоит задуматься что это твой косяк (в данном случае очевидно, тебе сразу привели нормальный пример). Во вторых ты как-то упустил из виду память, js не стесняясь выжрал вообще все.

_>C# медленнее, Java еще медленнее.
Тебе привели пример где C# быстрее, ты продолжаешь повторять чушь.


_>А зачем такие компиляторы (для меня), если они плохо работают с родными для языка и платформы абстракциями. Это проблемы языка/платформы. Не мои проблемы.
Нет это именно твои проблемы, потому что ты не знаешь как использовать язык и платформу. Язык и платформа позволяют тебе сделать код быстрым и надежным, если ты этим не пользуешься, то ты баран, а не создатели языка.

_>Это я хотел сперва проверить, посмотрел, удивился и решил поделится. Вот весь мой мотив.
Все чем ты поделился — своим незнанием C#, и все.
Ты сел в лужу по самую макушку, а теперь пытаешься выкрутиться, причем совершенно неумело.

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

C>сменить у части из них тип, добавить к оставшимся новое поле и заполнить его вычисленным значением?

Ну и где тут необходима динамическая типизация?

{-# LANGUAGE TypeFamilies #-}

import Data.Has

-- Объявляем поля, которые будем объединять в записи:
data Foo = Foo; type instance TypeOf Foo = Integer
data Bar = Bar; type instance TypeOf Bar = Double

-- Конструируем из объявленных полей запись:
record = Foo ^- 2 & Bar ^- 2
-- Тип полученной записи - FieldOf Foo :&: FieldOf Bar

-- Читаем поля записи и вычисляем новое значение:
foobar r = (Bar ^. r) ** fromIntegral (Foo ^. r) 

-- Объявляем еще одно поле.
data Baz = Baz; type instance TypeOf Baz = Double

-- Добавляем поле Baz с вычисленным значением
record' = record & Baz ^- foobar record
-- Тип новой записи будет FieldOf Foo :&: FieldOf Bar :&: FieldOf Baz 

-- foobar работает и с записью типа FieldOf Foo :&: FieldOf Bar :&: FieldOf Baz,
-- потому что поля Foo и Bar у этой записи есть. 
x = foobar record'

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

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

G>Ну правильно, += почти везде работает. Не работает только в "тесте" который ты привел.
В тесте он работает. На то что не работает я не жаловался. Я жаловался, на то что с чего это вдруг компилируемый язык работает с объектами в том же временном порядке, даже чуть медленнее, что и скриптовый/интерпретируемый. То есть у языка проблемы. Я не сравнивал присутствие/отсутствие/оптимизацию отдельных классов. Потому что тема не про реализацию стрингбилдеров в разных языках, это тема про сами языки.

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

G>
G>Некогда пилу точить — пилить надо.
Пилу точат когда она тупая, а (внимание наезд) если пила изначально "тупая", точи, не точи, много леса не навалишь.

_>>1) Я не юрист, поэтому не вижу разной семантики в приведенных тестах.
G>Для C++ — mutable строка, для C# и JS — immutable
И где разница семантики между c# и js. C++ шел отдельным пунктом, вне сравнения.

_>>2) Это тест не про то как надо правильно оптимизировать код, а про то как два языка работают с объектами в частности со строками.
G>Ну ты показал что js не освобождает память, а .NET освобождает... А нахрена ты время привел, для очевидно неоптимального кода?
Тогда более "тяжелый" вариант с движком spidermonkey http://ideone.com/hl6ad
в 3 быстрее, 10 раз меньше памяти по сравнению c#(mono).

_>>3) Я привел код, который в цикле выполняет наиболее часто встречающуюся строковую операцию в моем и не только в моем коде.
G>"В цикле" — уже совершенно другая операция.
Цикл нужен для создания тестовых условий. Проверяется код s += "a". И тест заставляет задуматься над скоростью работы с immutable объектами. Ибо с такими объектами "проще" работать.

_>>А зачем такие компиляторы (для меня), если они плохо работают с родными для языка и платформы абстракциями. Это проблемы языка/платформы. Не мои проблемы.
G>Нет это именно твои проблемы, потому что ты не знаешь как использовать язык и платформу. Язык и платформа позволяют тебе сделать код быстрым и надежным, если ты этим не пользуешься, то ты баран, а не создатели языка.

_>>Это я хотел сперва проверить, посмотрел, удивился и решил поделится. Вот весь мой мотив.
G>Все чем ты поделился — своим незнанием C#, и все.
G>Ты сел в лужу по самую макушку, а теперь пытаешься выкрутиться, причем совершенно неумело.

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

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

Всем спасибо.
Извиняюсь за все негативные эмоции которые я вызвал в ваших сердцах.

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

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

G>>Ну правильно, += почти везде работает. Не работает только в "тесте" который ты привел.
_>В тесте он работает. На то что не работает я не жаловался. Я жаловался, на то что с чего это вдруг компилируемый язык работает с объектами в том же временном порядке, даже чуть медленнее, что и скриптовый/интерпретируемый. То есть у языка проблемы. Я не сравнивал присутствие/отсутствие/оптимизацию отдельных классов. Потому что тема не про реализацию стрингбилдеров в разных языках, это тема про сами языки.
Ты ведешь себя как дите. Ну сравни память, которую отожрал JS и .NET. Подумай головой что освобождение памяти небесплатно и поймешь разницу. Вот только ты про это не заикнулся когда тесты приводил, а когда тебя неоднократно ткнули носом в то где ты неправ ты уже целую философию выдумал про сравнение языков.

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

G>>
G>>Некогда пилу точить — пилить надо.
_>Пилу точат когда она тупая, а (внимание наезд) если пила изначально "тупая", точи, не точи, много леса не навалишь.
Пила — это твои способности писать на каком-то языке. Ну если тупая — значит тупая.

_>>>1) Я не юрист, поэтому не вижу разной семантики в приведенных тестах.
G>>Для C++ — mutable строка, для C# и JS — immutable
_>И где разница семантики между c# и js. C++ шел отдельным пунктом, вне сравнения.
Разница в освобождении памяти.

_>>>2) Это тест не про то как надо правильно оптимизировать код, а про то как два языка работают с объектами в частности со строками.
G>>Ну ты показал что js не освобождает память, а .NET освобождает... А нахрена ты время привел, для очевидно неоптимального кода?
_>Тогда более "тяжелый" вариант с движком spidermonkey http://ideone.com/hl6ad
_>в 3 быстрее, 10 раз меньше памяти по сравнению c#(mono).
А нормальный вариант кода на C# рвет любой код на JS в какашки. Только ты его в упор не видишь. У тебя какая-то избирательная слепота, наверное чтобы оправдать собственную глупость. Ну ниче, бывает.

_>>>3) Я привел код, который в цикле выполняет наиболее часто встречающуюся строковую операцию в моем и не только в моем коде.
G>>"В цикле" — уже совершенно другая операция.
_>Цикл нужен для создания тестовых условий. Проверяется код s += "a". И тест заставляет задуматься над скоростью работы с immutable объектами. Ибо с такими объектами "проще" работать.
Я не про внешний, а про внутренний цикл.

G>>Ты сел в лужу по самую макушку, а теперь пытаешься выкрутиться, причем совершенно неумело.
_>Спасибо, ты тоже кудрявый.
_>Признаю свою некомпетентность и короткошерстность.
Гы, в чем? В том что я знаю как заставить код на C# работать быстрее?

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

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

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

O>>>Никаких шуток. Только не эмуляцию Linux, а собственно, Linux, на жаваскриптовом эмуляторе x86 железа.
V>>Не взлетело. Тормозило несколько минут, а потом предложило прибить скрпт, бо он тормозит весь компьютер. Дал ему еще немного времени, но картинка так и осталась черным квадратом, так что пришлось таки прибить.
A>Пока что не всякий браузер такое умеет.
Скриптовый язык, который работает только по желанию левой пятки быдлокодера -- не нужен.

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

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

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

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

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

Вот ведь как! По немецки — "цацки-пецки", а по-русски — "бутерброд"!
То есть по твоему мнению языки так и разрабатываются, да? Ну чтобы думать и знать надо было меньше и писать почти на С?
Это же целое поле для троллинга, взять конструкцию языка А и пойти к ребятам языка Б.
Есть такое мнение чтобы что-то сравнивать надо а) понимать основы сравниваемых объектов, б) принимать критику и поправки к аргументам.

>Почему я должен на одном языке заниматься premature optimization и вводить в программу другие сущности, чтобы догнать по скорости? Многие проекты не доходят до стадии вылизывания кода "бодибилдерами" . Они уже приносят деньги. И некоторое конкурентное преимущество в скорости работы += может сыграть большую роль.

Берём человека, который не знает как работает .net и даём ему деньги чтобы он сделал работу. Он выбирает .net и пишет плохой код потому, что он так писал на JS.
Какая фатальная череда несчастий. Невезучий его работодатель/заказчик.
Во-вторых:
>Многие проекты не доходят до стадии вылизывания кода "бодибилдерами"
В 90% случаев хватает даже одного прохода профайлером. Если кто-то заплатил деньги можно и потратить 5 минут.
В-третьих: использование StringBuilder'а — это не premature optimization, а common sense. Вспомни Маяковского с "Нате".
В-чётвёртых:
>И некоторое конкурентное преимущество в скорости работы += может сыграть большую роль.
Эта фраза особенно доставила! Ещё скажу, что *= может порой играть такую большую роль, что Гамлет нервно курит.

Как можно требовать от одного языка работать как и другой, даже если они похожи. Как можно приводить аргумент, что это "может сыграть большую роль" в случае когда код писать будет человек не знающий основ используемого языка (и в тот момент ещё свет Венеры отразится от перисто-кучевых облаков и попадёт к нему на монитор).
И кстати, а как насчёт javascript pitfalls тогда?

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

C>Затем, что я хочу работать с объектами, а не записями в БД.

Тебя мы обсуждать не будем потому как п. 5. Больше тут обсуждать не чего.

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

C>>Затем, что я хочу работать с объектами, а не записями в БД.
VD>Тебя мы обсуждать не будем потому как п. 5. Больше тут обсуждать не чего.
Дальше что? Статическое решение, позволяющее это сделать красиво, будет?

Если нет, то я смело на любое возражение Немерлистов могу говорить ровно теми же словами.

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

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

C>>>Затем, что я хочу работать с объектами, а не записями в БД.
VD>>Тебя мы обсуждать не будем потому как п. 5. Больше тут обсуждать не чего.
C>Дальше что? Статическое решение, позволяющее это сделать красиво, будет?

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

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

C>>Дальше что? Статическое решение, позволяющее это сделать красиво, будет?
VD>Там все что нужно и так генерируется. Ты что думаешь, там люди запросы в текстовом виде пишут?
VD>То что ты не в силах даже почитать вики никто не виноват.
Мне неинтересно как генерируются запросы, это я и сам знаю. Мне интересно как статически выражается изменение модели данных.

Вариант Klapaucius'а показывает как примерно это будет выглядеть на статике — не особо красиво. Если нужно менять топологию модели, то вообще всё плохо становится.

А на динамике всё ОК.

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

C>Мне интересно как статически выражается изменение модели данных.

Операциями над типами.

C>Вариант Klapaucius'а показывает как примерно это будет выглядеть на статике — не особо красиво.

Давайте предметно обсудим, что именно не устраивает.

C>Если нужно менять топологию модели, то вообще всё плохо становится.

Что именно плохо становится? Какие проблемы с изменением топологии?

C>А на динамике всё ОК.

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

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

C>>Мне интересно как статически выражается изменение модели данных.
K>Операциями над типами.
Я понял.

C>>Вариант Klapaucius'а показывает как примерно это будет выглядеть на статике — не особо красиво.
K>Давайте предметно обсудим, что именно не устраивает.
Насколько я понял, у тебя просто создаются новые типы, а именованый тип изменить после создания нельзя.

C>>А на динамике всё ОК.
K>Ну, это пока ничем не обоснованное заявление, которое неплохо бы подтвердить.
Ну как бы, в динамике нет проблем с типами.