C# for Systems Programming
От: Nikkk2010  
Дата: 29.12.13 04:03
Оценка: 34 (6)

Joe Duffy's team has been designing and implementing a set of “systems programming” extensions to C# over the past 4 years.
At long last, I’ll begin sharing our experiences in a series of blog posts.

The first question is, “Why a new language?”


Ссылка
I do all my own stunts
Re: C# for Systems Programming
От: Artem Korneev США https://www.linkedin.com/in/artemkorneev/
Дата: 30.12.13 23:32
Оценка: +11
Здравствуйте, Nikkk2010, Вы писали:

Наткнулся на вот эту диаграмму в блоге.



Коллеги, скажите, а что вы думаете о ней? Меня интересует положение JavaScript. Часто вот в таких статьях как-то к слову говорится, что писать на JavaScript легко и просто и разработчики просто спят и видят как бы использовать JavaScript вместо всех остальных языков.
Но сколько я с ним ни сталкивался — боль и ужас. По параметрам "Safety & Productivity" я бы убрал его в левый нижний угол.

Вообще я грешил на своё плохое знание JavaScript и по возможности стараюсь это исправить — вот буквально два дня назад на распродаже
Автор: Lonely Dog
Дата: 27.12.13
купил десяток книг, из них две — по jQuery. По работе частенько приходится сталкиваться с JS, допиливая какие-нибудь веб-интерфейсы.

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

Куда бы вы поместили JavaScript на этой диаграмме?
С уважением, Artem Korneev.
Re[2]: C# for Systems Programming
От: dsorokin Россия  
Дата: 01.01.14 16:12
Оценка: :))
Здравствуйте, Artem Korneev, Вы писали:

AK>Наткнулся на вот эту диаграмму в блоге.


Надо понимать, что "X" — это сокращение от слова "Хаскель"?
Re[3]: C# for Systems Programming
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.01.14 19:22
Оценка:
Здравствуйте, dsorokin, Вы писали:

D>Надо понимать, что "X" — это сокращение от слова "Хаскель"?


Хаскель уже без ГЦ обходится?
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[2]: C# for Systems Programming
От: Sharov Россия  
Дата: 01.01.14 20:58
Оценка:
Здравствуйте, Artem Korneev, Вы писали:

AK>Коллеги, скажите, а что вы думаете о ней? Меня интересует положение JavaScript. Часто вот в таких статьях как-то к слову говорится, что писать на JavaScript легко и просто и разработчики просто спят и видят как бы использовать JavaScript вместо всех остальных языков.

AK>Но сколько я с ним ни сталкивался — боль и ужас. По параметрам "Safety & Productivity" я бы убрал его в левый нижний угол.

JS действительно довольно простой и мощный язык. Ну, допустим факт, что там нет встроенной поддержки, например, ООП (классического ООП).
Ну так там практически всю ООПшную инфраструктуру можно воссоздать(эмулировать), и писать вполне себе в ОО стиле. То же и с ФП.
Что касается безопасности, то тут согласен -- язык динамический, со всеми последствиями...
Так что js я поставил бы ниже шарпа и явы, но оставил бы в том же квадранте.
Кодом людям нужно помогать!
Re[2]: C# for Systems Programming
От: DreamMaker  
Дата: 01.01.14 23:02
Оценка: +2
Здравствуйте, Artem Korneev, Вы писали:

AK>Куда бы вы поместили JavaScript на этой диаграмме?


js за гранью добра и зла...
ужас ужасный, хуже только пхп
In P=NP we trust.
Re[2]: C# for Systems Programming
От: Tom Россия http://www.RSDN.ru
Дата: 01.01.14 23:12
Оценка:
Здравствуйте, Artem Korneev, Вы писали:

AK>Коллеги, скажите, а что вы думаете о ней? Меня интересует положение JavaScript.

Я тоже когда увидел где находится жаба скрипт долго ржал. Оказывается это у нас самый безопасный язык (ага, слаботипизированный, бугага)
Народная мудрось
всем все никому ничего(с).
Re[2]: C# for Systems Programming
От: Аноним  
Дата: 02.01.14 01:24
Оценка: +6 -1
Да это вообще странная идея о том, что-де на джаваскрипт проще программировать, чем на Java или C#.

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

Набирать код в Javascript нужно внимательно и напряженно, чтобы не дай бог не опечататься и ничего не перепутать, и набирать вручную приходится гораздо больше, чем в C# и подобных, из-за отсутствия подсказок, компиляции, рефакторинга и статической типизации. Ну и в Javascript есть набор совершенно диких нелогичностей в преобразованиях типов и синтаксисе, которых в C# нет, при этом в джаваскрипт ты ошибку не найдешь, пока выполнение не дойдет до этого места с нужными предварительными шагами (для получения тех данных, при которых проявляется ошибка). Ну или нужно строго 100% покрытие тестами.

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

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

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

Если все это суммировать, утверждения о более высокой производительности разработки на Javascript по сравнению, например, с C# — смехотворный бред, вызванный чьим-то больным воображением, либо какой-то миф, оставшийся от устаревших представлений. Непонятно, почему этот дурацкий миф так широко распространен и всеми так легко принимается на веру.
Re[3]: C# for Systems Programming
От: Аноним  
Дата: 02.01.14 02:14
Оценка:
Здравствуйте, dsorokin, Вы писали:

D>Надо понимать, что "X" — это сокращение от слова "Хаскель"?


Нет, это от слов "Хрен вам".
Re[3]: C# for Systems Programming
От: Sharov Россия  
Дата: 02.01.14 10:31
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Набирать код в Javascript нужно внимательно и напряженно, чтобы не дай бог не опечататься и ничего не перепутать, и набирать вручную приходится гораздо больше, чем в C# и подобных, из-за отсутствия подсказок, компиляции, рефакторинга и статической типизации. Ну и в Javascript есть набор совершенно диких нелогичностей в преобразованиях типов и синтаксисе, которых в C# нет, при этом в джаваскрипт ты ошибку не найдешь, пока выполнение не дойдет до этого места с нужными предварительными шагами (для получения тех данных, при которых проявляется ошибка). Ну или нужно строго 100% покрытие тестами.


Ну например в продуктах JB, которые поддерживают js имеются разнообразные code quality tools
такие как jslint, jshint, Closure linter. Т.е. выстрелить себе в ногу не дадут.
Code completion тоже имеется.

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


http://www.adequatelygood.com/JavaScript-Module-Pattern-In-Depth.html
Кодом людям нужно помогать!
Re[2]: C# for Systems Programming
От: Evgeny.Panasyuk Россия  
Дата: 02.01.14 11:04
Оценка:
Здравствуйте, Artem Korneev, Вы писали:

AK>Наткнулся на вот эту диаграмму в блоге.

AK> http://joeduffyblog.com/images/2013_LangQuad.jpg
AK>Коллеги, скажите, а что вы думаете о ней?

1. Почему Java правее C#? В Java даже структур нету. Или это обусловлено только текущим качеством оптимизаторов?
2. C++11 должен быть и выше и правее C++98 — быстрый код стало легче писать.
3. Что вообще сравнивается? Только языки или ещё и окружающая среда? Если только языки — то Java самый дубовый и непродуктивный.
4. JavaScript можно считать более продуктивным потому, что это язык с динамической типизацией. Это позволяет легко писать обобщённый код. Но safety — это крайне спорный момент (опять таки — что конкретно подразумевается).
Re[4]: C# for Systems Programming
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 02.01.14 11:28
Оценка: -3 :)
Здравствуйте, AndrewVK, Вы писали:

D>>Надо понимать, что "X" — это сокращение от слова "Хаскель"?

AVK>Хаскель уже без ГЦ обходится?

Полагаю, в умелых руках всякие критичные к скорости циклы там можно делать без лишних аллокаций и вызова GC.
А если в целом, то согласно Страуструпу современный С++ — язык со сборкой мусора (причем плохой: на подсчете ссылок, т.е. медленной, ненадежной и небезопасной).
Re[5]: C# for Systems Programming
От: Evgeny.Panasyuk Россия  
Дата: 02.01.14 11:49
Оценка:
Здравствуйте, D. Mon, Вы писали:

D>>>Надо понимать, что "X" — это сокращение от слова "Хаскель"?

AVK>>Хаскель уже без ГЦ обходится?
DM>Полагаю, в умелых руках всякие критичные к скорости циклы там можно делать без лишних аллокаций и вызова GC.

Как ни крути, когда в языках с GC-by-default требуется performance — от этого GC в той или иной мере пытаются избавиться.

DM>А если в целом, то согласно Страуструпу современный С++ — язык со сборкой мусора (причем плохой: на подсчете ссылок, т.е. медленной, ненадежной и небезопасной).


1. Есть интерфейс для консервативного GC.
2. Некоторые смарт-поинтеры используют подсчёт ссылок. Но они требуются только при наличии shared семантики, которая встречается крайне редко — в большинстве кода никакой ref-counting не нужен.

DM>(причем плохой: на подсчете ссылок, т.е. медленной,


Почему медленной?

DM>ненадежной


У неё есть свои предусловия, точно также как и у других GC. Утечки могут быть хоть в C#/Java/Haskell

DM>и небезопасной).


Почему небезопасной?
Re[4]: C# for Systems Programming
От: Аноним  
Дата: 02.01.14 12:32
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Ну например в продуктах JB, которые поддерживают js имеются разнообразные code quality tools

S>такие как jslint, jshint, Closure linter. Т.е. выстрелить себе в ногу не дадут.
S>Code completion тоже имеется.

Спасибо за информацию. И как, добавление этих средств делает разработку на Javascript более эффективной, чем на C# c ReSharper?
Re[5]: C# for Systems Programming
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.01.14 14:39
Оценка: +1
Здравствуйте, D. Mon, Вы писали:

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


В умелях руках это можно сделать и на шарпе.

DM>А если в целом, то согласно Страуструпу современный С++ — язык со сборкой мусора (причем плохой: на подсчете ссылок, т.е. медленной, ненадежной и небезопасной).


Ты саму статью то прочти — там вполне отчетливо намекается, что основная причина отнесения JS и дотнетов с джавами к левому краю — наличие GC.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[3]: C# for Systems Programming
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.01.14 14:46
Оценка:
Здравствуйте, Sharov, Вы писали:

S>JS действительно довольно простой и мощный язык.


JS может и простой и мощный, но он принципиально динамический, так что о safety точно говорить не приходится.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[3]: C# for Systems Programming
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.01.14 14:46
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>1. Почему Java правее C#? В Java даже структур нету. Или это обусловлено только текущим качеством оптимизаторов?


Я так понимаю мало кто удосужился прочесть многабукав статьи. А в ней есть ответ:

Java is closer than C# thanks to the excellent work in HotSpot-like VMs which employ code pitching and stack allocation.


EP>4. JavaScript можно считать более продуктивным потому, что это язык с динамической типизацией.


Практика показывает, что, начиная с некоторого, достаточно скромного размера проекта, JS становится существенно менее продуктивным, потому всякие TypeScript и появляются.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[4]: C# for Systems Programming
От: Evgeny.Panasyuk Россия  
Дата: 02.01.14 15:11
Оценка:
Здравствуйте, AndrewVK, Вы писали:

EP>>1. Почему Java правее C#? В Java даже структур нету. Или это обусловлено только текущим качеством оптимизаторов?

AVK>Я так понимаю мало кто удосужился прочесть многабукав статьи. А в ней есть ответ:

Статью не читал. Из-за вот такой пропаганды она совершенна не интересна:

I’ve seen many people run away from garbage collection back to C++, with a sour taste permeating their mouths. (To be fair, this is only partly due to garbage collection itself; it’s largely due to poor design patterns, frameworks, and a lost opportunity to do better in the language.)


Поэтому и спросил что же там подразумевалось.

AVK>

AVK>Java is closer than C# thanks to the excellent work in HotSpot-like VMs which employ code pitching and stack allocation.


И как это поможет восполнить отсутствие массивов структур? Правильный memory layout данных очень важен для производительности.
Там где на Java нужна скорость — структуры вручную раскладывают по массиву байт.
Re[6]: C# for Systems Programming
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 02.01.14 15:34
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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

AVK>В умелях руках это можно сделать и на шарпе.

И? Как именно это мешает хаскелю быть быстрым?
Re[2]: C# for Systems Programming
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 02.01.14 15:43
Оценка: :)
Здравствуйте, Artem Korneev, Вы писали:

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


AK>Наткнулся на вот эту диаграмму в блоге.


AK>Коллеги, скажите, а что вы думаете о ней?


Все верно. Через 1, максимум 2 года вместо красной и загадочной X можно будет вписать Rust
Re[6]: C# for Systems Programming
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 02.01.14 15:47
Оценка: +1
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Как ни крути, когда в языках с GC-by-default требуется performance — от этого GC в той или иной мере пытаются избавиться.


Это неполное видение: как ни крути, в любых языках когда требуется performance — пытаются избавиться от лишних аллокаций. Но в целом согласен. Например, в С++ пытаются избавиться от shared указателей.

DM>>А если в целом, то согласно Страуструпу современный С++ — язык со сборкой мусора (причем плохой: на подсчете ссылок, т.е. медленной, ненадежной и небезопасной).

EP>1. Есть интерфейс для консервативного GC.

Это тоже медленно и ненадежно.

EP>2. Некоторые смарт-поинтеры используют подсчёт ссылок. Но они требуются только при наличии shared семантики, которая встречается крайне редко — в большинстве кода никакой ref-counting не нужен.


Это уже детали и спекуляции.

DM>>(причем плохой: на подсчете ссылок, т.е. медленной,


EP>Почему медленной?


http://research.microsoft.com/pubs/202163/rcix-oopsla-2013.pdf
http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf

DM>>и небезопасной).

EP>Почему небезопасной?

Потому что система типов слишком легко позволяет поиметь указатель на мертвый объект, например. Или перепутать виды указателей, использовать shared там где нужен weak или наоборот. Нет никаких гарантий, все управление памятью на честном слове держится.
Re[7]: C# for Systems Programming
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.01.14 15:49
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>И? Как именно это мешает хаскелю быть быстрым?


Потерял нить разговора?
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[8]: C# for Systems Programming
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 02.01.14 16:31
Оценка: :)))
Здравствуйте, AndrewVK, Вы писали:

DM>>И? Как именно это мешает хаскелю быть быстрым?

AVK>Потерял нить разговора?

Себя спрашиваешь?
Смотри:
В C# есть GC, но в критичных местах можно писать код без его участия, тем не менее язык все равно в секторе "медленных". Почему? Например, потому что кодогенератор у него так себе.
В Хаскеле есть GC, но в критичных местах можно писать код без аллокаций, при этом кодогенератор у него другой, поэтому записывать его в сектор "медленных" пока нет причин.
Re[7]: C# for Systems Programming
От: Evgeny.Panasyuk Россия  
Дата: 02.01.14 16:55
Оценка:
Здравствуйте, D. Mon, Вы писали:

EP>>Как ни крути, когда в языках с GC-by-default требуется performance — от этого GC в той или иной мере пытаются избавиться.

DM>Это неполное видение: как ни крути, в любых языках когда требуется performance — пытаются избавиться от лишних аллокаций.

Согласен, но в C++ это достигается легко, без потери абстракций. А в языках с GC переходят на уровень даже ниже чем C — играют массивами байт.

EP>>2. Некоторые смарт-поинтеры используют подсчёт ссылок. Но они требуются только при наличии shared семантики, которая встречается крайне редко — в большинстве кода никакой ref-counting не нужен.

DM>Это уже детали и спекуляции.

Это факт — ref counting в C++ нужен редко.

DM>>>(причем плохой: на подсчете ссылок, т.е. медленной,

EP>>Почему медленной?
DM>http://research.microsoft.com/pubs/202163/rcix-oopsla-2013.pdf

RC divides execution into three distinct phases: mutation, reference counting collection, and cycle collection.


DM>http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf


We have implemented both types of collector: a multiprocessor concurrent reference counting collector with cycle collection

В обоих случаях говорится про ref-counted GC со сборкой циклов. Это принципиально отличается от того что даёт std::shared_ptr — никакого cycle collection там нет

DM>>>и небезопасной).

EP>>Почему небезопасной?
DM>Потому что система типов слишком легко позволяет поиметь указатель на мертвый объект, например. Или перепутать виды указателей, использовать shared там где нужен weak или наоборот. Нет никаких гарантий, все управление памятью на честном слове держится.

При раскладывании объектов по массивам байт в управляемых языках возникают те же проблемы.
Re[8]: C# for Systems Programming
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 02.01.14 18:10
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>В обоих случаях говорится про ref-counted GC со сборкой циклов. Это принципиально отличается от того что даёт std::shared_ptr — никакого cycle collection там нет


Это к вопросу о ненадежности. Но даже без cycle collection временные характеристики не менее печальные. Даже такая важная оптимизация как deferred reference counting, как я подозреваю, на С++ не делается.

EP>>>Почему небезопасной?

DM>>Потому что система типов слишком легко позволяет поиметь указатель на мертвый объект, например. Или перепутать виды указателей, использовать shared там где нужен weak или наоборот. Нет никаких гарантий, все управление памятью на честном слове держится.

EP>При раскладывании объектов по массивам байт в управляемых языках возникают те же проблемы.


Поэтому не надо раскладывать.
Re[9]: C# for Systems Programming
От: Evgeny.Panasyuk Россия  
Дата: 02.01.14 19:43
Оценка:
Здравствуйте, D. Mon, Вы писали:

EP>>В обоих случаях говорится про ref-counted GC со сборкой циклов. Это принципиально отличается от того что даёт std::shared_ptr — никакого cycle collection там нет

DM>Это к вопросу о ненадежности.

К вопросу о надёжности — кроме памяти есть и другие ресурсы, причём для которых необходимо детерминированное время жизни. В управляемых языках только половинчатые решения: using/try-with-resources/with.

DM>Но даже без cycle collection временные характеристики не менее печальные.


Почему?

DM>Даже такая важная оптимизация как deferred reference counting, как я подозреваю, на С++ не делается.


Чем же она так важна, особенно в контексте C++?

EP>>При раскладывании объектов по массивам байт в управляемых языках возникают те же проблемы.

DM>Поэтому не надо раскладывать.

Когда нужна производительность, например на Java — вынужденны раскладывать и отказываться от GC
Re[9]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.01.14 20:51
Оценка: +1
Здравствуйте, D. Mon, Вы писали:

EP>>При раскладывании объектов по массивам байт в управляемых языках возникают те же проблемы.

надо расклад
DM>Поэтому неывать.

Надо. смотри off heap cache
Re[2]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.01.14 21:02
Оценка:
Здравствуйте, Artem Korneev, Вы писали:

AK>Но сколько я с ним ни сталкивался — боль и ужас. По параметрам "Safety & Productivity" я бы убрал его в левый нижний угол.


Боль и ужас это DOM и css. Хочешь смотреть серьезные вещи — смотри node.js , внятный АПИ большей частью и довольно предсказуемое поведение.

AK>Вообще я грешил на своё плохое знание JavaScript и по возможности стараюсь это исправить — вот буквально два дня назад на распродаже
Автор: Lonely Dog
Дата: 27.12.13
купил десяток книг, из них две — по jQuery. По работе частенько приходится сталкиваться с JS, допиливая какие-нибудь веб-интерфейсы.


Не надо путать джаваскрипт с DOM, Css и поделками навроде jQuery.

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


AK>Куда бы вы поместили JavaScript на этой диаграмме?


Примерно там, где он сейчас стоит, может быть даже чуток правее Скажем, отрисовка в канвас будет не хуже, чем мега сервелат на С#

И не совсем понятно, почему по перформансу джава правее C#, низкоуровневый перформанс в C# намного лучше, там честные оптимизации на дженериках и прочих вещах, навроде строк и типов-значений. Серверный перформанс выше в джаве и исключительно благодаря библиотекам, которым уже 20 скоро будет.
Re[3]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.01.14 21:20
Оценка: 5 (1) :)
Здравствуйте, Аноним, Вы писали:

А>Да это вообще странная идея о том, что-де на джаваскрипт проще программировать, чем на Java или C#.


А что странного, я вот пишу и отдыхаю после C# Вот первых, отладка намного мощнее, многие вещи можно попробовать прямо в отладочной консоли, в джаве и дотнете это недостижимый предел.

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


Все так, правда это особенности динамических языков, а не джаваскрипта. Обычно частично решается тулами, частично — внятным подходом к дизайну.
Если заводить на каждый чих сущности и методы, то это будет ад.

А>Набирать код в Javascript нужно внимательно и напряженно, чтобы не дай бог не опечататься и ничего не перепутать, и набирать вручную приходится гораздо больше, чем в C# и подобных, из-за отсутствия подсказок, компиляции,


Наоборот — набирать нужно намного _меньше_. А вот если на джаваскрипте писать "как на C#" то гораздо больше.

>рефакторинга и статической типизации. Ну и в Javascript есть набор совершенно диких нелогичностей в преобразованиях типов и синтаксисе, которых в C# нет, при этом в джаваскрипт ты ошибку не найдешь, пока выполнение не дойдет до этого места с нужными предварительными шагами (для получения тех данных, при которых проявляется ошибка). Ну или нужно строго 100% покрытие тестами.


Есть много нелогичностей, но в целом кривая вхождения довольно пологая.

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


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

Взять браузер — там одни ограничения. Серверные приложения — другие. Десктоп — третьи. Мобайл — четвертые. На кой ляд там одна библиотека, если скажем работа с файлами принципиально отличается во всех четырех случаях ?

Вместо этого можно подобрать библиотеку под конкретный случай.

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


1. в языках навроде C# слабоватый вывод типов и через это возможности ООП и ФП довольно хилые.
2. юниттесты нужны и в C#, при чем ровно там же, где и в джаваскрипте
3. запуск программы на JS большей частью ничего не стоит и да и запускать можно не программу, а один файл

А>Я не так много программировал на Javascript, так что, уверен, список недостатков можно пополнить. Хотя на Javascript можно делать веселые штуки благодаря динамике, и в отдельно взятых конкретных случаях они могут здорово сократить решение, да. Но не думаю, что таких случаев достаточно, чтобы это было существенно.


Динамика дает возможности, которых в C# нет и никогда не будет

А>Если все это суммировать, утверждения о более высокой производительности разработки на Javascript по сравнению, например, с C# — смехотворный бред, вызванный чьим-то больным воображением, либо какой-то миф, оставшийся от устаревших представлений. Непонятно, почему этот дурацкий миф так широко распространен и всеми так легко принимается на веру.


Хочешь, простой тест сделаем — регэкспы. Сильно удивишься. Или рисование в канвас.

Ну или совсем чит — правильный пайпинг на сервере, т.е. читаешь поток , обрабатываешь и одновременно отдаёшь. Выпилить такое на WCF мало кто сможет, стандартная либа первым делом пытается закачать весь стрим а уже потом разрешить процессить.
Re[3]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.01.14 21:22
Оценка: :))) :)
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>4. JavaScript можно считать более продуктивным потому, что это язык с динамической типизацией. Это позволяет легко писать обобщённый код. Но safety — это крайне спорный момент (опять таки — что конкретно подразумевается).


джаваскрипт исполняется в песочнице, что дает сафети.
Re[4]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.01.14 21:26
Оценка:
Здравствуйте, AndrewVK, Вы писали:

EP>>1. Почему Java правее C#? В Java даже структур нету. Или это обусловлено только текущим качеством оптимизаторов?


AVK>Я так понимаю мало кто удосужился прочесть многабукав статьи. А в ней есть ответ:

AVK>

AVK>Java is closer than C# thanks to the excellent work in HotSpot-like VMs which employ code pitching and stack allocation.


А что это значит ? Что это за VM такие и что такое питчинг и тд ?
Re[4]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.14 01:39
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Хаскель уже без ГЦ обходится?


Жабаскрип без ЖЦ обходится. Но это ему не шибко помогает.

Что до Хаскеля, то не сказал бы, что писать на нем так уж продуктивно. Так что даже если он не будет отличатья от Си по скорости, один фиг его вряд ли ждет повсеместное применение. Это язык не для всех.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.14 01:46
Оценка:
Здравствуйте, Sharov, Вы писали:

S>http://www.adequatelygood.com/JavaScript-Module-Pattern-In-Depth.html


Вот это форменный набор приседаний. Вообще, паттерны — это список недоработок в языке. Чем меньше нужно знать паттернов при программировании на языке, тем лучше этот язык.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.14 01:48
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>4. JavaScript можно считать более продуктивным потому, что это язык с динамической типизацией. Это позволяет легко писать обобщённый код. Но safety — это крайне спорный момент (опять таки — что конкретно подразумевается).


Лично для меня и скорость кодирования на скриптах очень спорный вопрос. Но тут на любителя. Есть люди которым динамика надет преимущество, а есть те для кого это недостаток. Я предпочитают статические проверки типов и качественный интеллисес.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.14 01:51
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>2. Некоторые смарт-поинтеры используют подсчёт ссылок. Но они требуются только при наличии shared семантики, которая встречается крайне редко — в большинстве кода никакой ref-counting не нужен.


Это ты расскажи тем кто Хорм в Гуле пилит. Они в итоге замаялись с тормозным и глючным посчетом ссылок и запилили ЖЦ для плюсов. Убогий конечно, но для их задач все равно лучше чем то что можно сделать в плюсах без него.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.14 01:56
Оценка: +2
Здравствуйте, AndrewVK, Вы писали:

AVK>Я так понимаю мало кто удосужился прочесть многабукав статьи. А в ней есть ответ:

AVK>

AVK>Java is closer than C# thanks to the excellent work in HotSpot-like VMs which employ code pitching and stack allocation.


Что на практике скорее желаемое, нежели действительное. В то же Скале это ни хрена не помогает сделать for таким же быстрым как в Яве, так как он реализован как функция высшего порядка. Казалось бы мощные оптимизации явовского рантайма должны были бы нивелировать разницу, но на практике они только лишь сокращают отставание. Но оно все равно огромно.

В дотнете же оптимизации можно делать за счет использования вэйлью-типов. Так что на практике, в лучшем случае Ява стоит на одном месте по производительности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: C# for Systems Programming
От: Andir Россия
Дата: 03.01.14 04:15
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Жабаскрип без ЖЦ обходится. Но это ему не шибко помогает.


А как же тогда в JavaScript менеджится память?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management
https://developers.google.com/v8/design?hl=ru#garb_coll

--
С Уважением, Andir!
using(<< RSDN@Home 1.2.0 alpha 5 rev. 74>>) { /* Работаем */ }
Re[4]: C# for Systems Programming
От: Andir Россия
Дата: 03.01.14 04:25
Оценка: +3
Здравствуйте, Ikemefula, Вы писали:

I>Ну или совсем чит — правильный пайпинг на сервере, т.е. читаешь поток , обрабатываешь и одновременно отдаёшь. Выпилить такое на WCF мало кто сможет, стандартная либа первым делом пытается закачать весь стрим а уже потом разрешить процессить.


см. WCF Streaming

--
С Уважением, Andir!
using(<< RSDN@Home 1.2.0 alpha 5 rev. 74>>) { /* Работаем */ }
Re[4]: C# for Systems Programming
От: Евгений Акиньшин grapholite.com
Дата: 03.01.14 05:20
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>Взять браузер — там одни ограничения. Серверные приложения — другие. Десктоп — третьи. Мобайл — четвертые. На кой ляд там одна библиотека, если скажем работа с файлами принципиально отличается во всех четырех случаях ?


А работа с потоками обычно везде одинаковая — практически везде есть базовый IStream (никогда не видел, чтобы с этим были проблемы).

Или, возьмем для примера, хотя бы коллекции и нотификации о изменениях. В том же .net все используют одни и те же IEnumerable, IList, INotifyPropertyChanged и т.д.

А на jscript каждый придумывает свою базовую библиотеку ни с чем не совместимую. В результате нельзя например написать логическую часть независимо, а потом выбрать GUI библиотеку для отображения — в каждой гуи библиотеке свой не визуальный фреймворк, со своими требованиями ко всем базовым объектам и все завязано на узел по самое ни хочу. И так во всем.

I>Вместо этого можно подобрать библиотеку под конкретный случай.


Вот только если нужно 2 библиотеки, то придется слой взаимодействия между ними писать самому, так как никаких стандартов ни на что нет.

И как вы там выкручиваетесь без элементарных типов, вроде decimal?

I>Динамика дает возможности, которых в C# нет и никогда не будет


Например?
Не шалю, никого не трогаю, починяю примус Diagrams Designer for iPad and Windows 10
Re[5]: C# for Systems Programming
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 03.01.14 06:27
Оценка:
Здравствуйте, VladD2, Вы писали:

VD> В то же Скале это ни хрена не помогает сделать for таким же быстрым как в Яве, так как он реализован как функция высшего порядка.


Давно проверял?
Эта проблема была очень давно, и мне казалось, ее уже давно исправили.
Re[5]: C# for Systems Programming
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 03.01.14 06:27
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Жабаскрип без ЖЦ обходится.


Это где такой?
Re[5]: C# for Systems Programming
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 03.01.14 06:39
Оценка:
Здравствуйте, Ikemefula, Вы писали:

AVK>>Java is closer than C# thanks to the excellent work in HotSpot-like VMs which employ code pitching and stack allocation.

I>А что это значит ? Что это за VM такие и что такое питчинг и тд ?

Питчинг там не к месту упомянут, имхо. Это про освобождение из памяти неиспользуемого скомпиленного нативного кода.
Вот скажи, CLR умеет перекомпилировать горячие циклы в рантайме? А делать так, чтобы локальное значение reference-типа было создано не в управляемой куче, а на стеке? Вроде как HotSpot (Oracle JVM) это все делает.
Re[10]: C# for Systems Programming
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 03.01.14 06:43
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, D. Mon, Вы писали:


EP>>>В обоих случаях говорится про ref-counted GC со сборкой циклов. Это принципиально отличается от того что даёт std::shared_ptr — никакого cycle collection там нет

DM>>Это к вопросу о ненадежности.

EP>К вопросу о надёжности — кроме памяти есть и другие ресурсы, причём для которых необходимо детерминированное время жизни. В управляемых языках только половинчатые решения: using/try-with-resources/with.


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

DM>>Но даже без cycle collection временные характеристики не менее печальные.

EP>Почему?

Попробуй почитать статьи выше дальше первой страницы.

EP>Когда нужна производительность, например на Java — вынужденны раскладывать и отказываться от GC


Это потому что Java. Разве я о ней в этой ветке говорил?
Re[3]: C# for Systems Programming
От: Artem Korneev США https://www.linkedin.com/in/artemkorneev/
Дата: 03.01.14 07:12
Оценка:
Здравствуйте, Ikemefula, Вы писали:

AK>>Но сколько я с ним ни сталкивался — боль и ужас. По параметрам "Safety & Productivity" я бы убрал его в левый нижний угол.

I>Боль и ужас это DOM и css. Хочешь смотреть серьезные вещи — смотри node.js , внятный АПИ большей частью и довольно предсказуемое поведение.

А вот там где DOM и CSS — для вас там тоже боль и ужас? Я, в общем-то, эту сферу и имел в виду. Как-то вылетело из головы, что на JS нынче и серверные части пишут.
Я с node.js не сталкивался пока, мне с JS приходится работать, в основном, для обработки ввода пользователя на HTML-страничках. А год назад довелось поучаствовать в разработке Android-приложения на HTML5+JS. Если я правильно понимаю, в этих случаях node.js неприменим? Он вроде для серверной части.

I>Не надо путать джаваскрипт с DOM, Css и поделками навроде jQuery.


Ну так для браузерной части других поделок нет.

I>И не совсем понятно, почему по перформансу джава правее C#

...
I>Серверный перформанс выше в джаве

Вероятно, как раз поэтому.

I>и исключительно благодаря библиотекам, которым уже 20 скоро будет.


Пусть, благодаря библиотекам. Важен результат.
Хотя мне и то и другое кажется медленным..
С уважением, Artem Korneev.
Re[3]: C# for Systems Programming
От: Artem Korneev США https://www.linkedin.com/in/artemkorneev/
Дата: 03.01.14 07:28
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>2. C++11 должен быть и выше и правее C++98 — быстрый код стало легче писать.


Он и так выше. А почему он должен быть правее-то?
С++11 позволяет выжать из железа тоже самое, что и С++98, просто облегчает процесс написания кода.

EP>4. JavaScript можно считать более продуктивным потому, что это язык с динамической типизацией. Это позволяет легко писать обобщённый код.


Вы пробовали? У вас получалось легко писать код на JavaScript?
Я про практическую часть спрашивал. У меня JS-код шёл с большим скрипом. Забытая скобочка или, хуже того, опечатка в имени элемента — проявлялись лишь после запуска приложения. А мне нужно было писать часть, которая делает снимки фото-камерой и заливает результат на сервер. Отлаживать приходилось в эмуляторе — "сохранить, скомпилить, перезапустить, ввести все параметры.." И только после этого увидеть в консоли сообщение, что оно не нашло такого элемента.

Отсутствие автокомплита тоже огорчило. Вкупе с моим смутным пониманием самого JS, это заставляло просто искать готовые решения в интернете. Сам я не мог понять, как написать что-то более-менее сложное.

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

Тут в треде упомянули инструменты от JetBrains — нужно спросить у менеджера, есть ли у нас лицензии. Может быть, чем-то улучшит ситуацию. Пока я пользовался лишь Visual Studio & Notepad++
С уважением, Artem Korneev.
Re[5]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 09:24
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Хаскель уже без ГЦ обходится?


VD>Жабаскрип без ЖЦ обходится. Но это ему не шибко помогает.


И давно ?
Re[5]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 09:25
Оценка:
Здравствуйте, VladD2, Вы писали:

S>>http://www.adequatelygood.com/JavaScript-Module-Pattern-In-Depth.html


VD>Вот это форменный набор приседаний. Вообще, паттерны — это список недоработок в языке. Чем меньше нужно знать паттернов при программировании на языке, тем лучше этот язык.


Очень интересно, особенно с учетом того, что "паттерны" есть даже в естественном языке.
Re[5]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 09:26
Оценка: -2
Здравствуйте, Andir, Вы писали:

I>>Ну или совсем чит — правильный пайпинг на сервере, т.е. читаешь поток , обрабатываешь и одновременно отдаёшь. Выпилить такое на WCF мало кто сможет, стандартная либа первым делом пытается закачать весь стрим а уже потом разрешить процессить.


A>см. WCF Streaming


Да-да, это он так и работает.
Re[4]: C# for Systems Programming
От: Философ Ад http://vk.com/id10256428
Дата: 03.01.14 09:34
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Динамика дает возможности, которых в C# нет и никогда не будет


Какие?
Всё сказанное выше — личное мнение, если не указано обратное.
Re[4]: C# for Systems Programming
От: Evgeny.Panasyuk Россия  
Дата: 03.01.14 09:41
Оценка:
Здравствуйте, VladD2, Вы писали:

EP>>4. JavaScript можно считать более продуктивным потому, что это язык с динамической типизацией. Это позволяет легко писать обобщённый код. Но safety — это крайне спорный момент (опять таки — что конкретно подразумевается).

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

На C#/Java обобщённый код особо не получается
Автор: Evgeny.Panasyuk
Дата: 04.11.13
. На C++ с этим всё нормально, но приходится то тут, то там подсказывать компилятору (auto, decltype, template, etc).
На языках с динамической типизацией этот обобщённый код получается легко и непринуждённо, но приносятся в жертву compile-time проверки.
Собственно код на языках со статической типизацией с каждым годом становится похож на код языков с динамической типизацией (например полиморфные лямбды в C++14, или те же лямбды в C# — удобно ведь). Но динамические языки — это то что доступно здесь и сейчас.

VD>Я предпочитают статические проверки типов и качественный интеллисес.


Я думаю все предпочитают статические проверки.
Re[7]: C# for Systems Programming
От: Evgeny.Panasyuk Россия  
Дата: 03.01.14 09:48
Оценка:
Здравствуйте, VladD2, Вы писали:

EP>>2. Некоторые смарт-поинтеры используют подсчёт ссылок. Но они требуются только при наличии shared семантики, которая встречается крайне редко — в большинстве кода никакой ref-counting не нужен.

VD>Это ты расскажи тем кто Хорм в Гуле пилит. Они в итоге замаялись с тормозным и глючным посчетом ссылок и запилили ЖЦ для плюсов. Убогий конечно, но для их задач все равно лучше чем то что можно сделать в плюсах без него.

А есть ссылка?
Re[5]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 09:55
Оценка:
Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>Здравствуйте, Ikemefula, Вы писали:


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


I>>Взять браузер — там одни ограничения. Серверные приложения — другие. Десктоп — третьи. Мобайл — четвертые. На кой ляд там одна библиотека, если скажем работа с файлами принципиально отличается во всех четырех случаях ?


ЕА>А работа с потоками обычно везде одинаковая — практически везде есть базовый IStream (никогда не видел, чтобы с этим были проблемы).


В браузер тащить такие либы это мягко говоря преступление. В мобайле такая хрень требует поддержки нативных плагинов. В десктоп и сервере все более менее шоколадно, и вот, что удивтельно, есть либа которая используется и там и там — node.js.

Вообще эта хрень пролазит уже в мобайл, не сильно в курсе какие успехи.

ЕА>Или, возьмем для примера, хотя бы коллекции и нотификации о изменениях. В том же .net все используют одни и те же IEnumerable, IList, INotifyPropertyChanged и т.д.


Я про это говорил — незачем в джаваскрипте писать как в дотнете. Вместо, скажем, INotifyPropertyChanged используется key-value observer, это более мощная вещь. IList не нужен. IEnumerable помог бы, но для этого уже есть кое что в
следующем стандарте. INotifyPropertyChanged при желании реализуется очень просто — где надо, берёшь и файришь эвент

ЕА>А на jscript каждый придумывает свою базовую библиотеку ни с чем не совместимую. В результате нельзя например написать логическую часть независимо, а потом выбрать GUI библиотеку для отображения — в каждой гуи библиотеке свой не визуальный фреймворк, со своими требованиями ко всем базовым объектам и все завязано на узел по самое ни хочу. И так во всем.


I>>Вместо этого можно подобрать библиотеку под конкретный случай.


ЕА>Вот только если нужно 2 библиотеки, то придется слой взаимодействия между ними писать самому, так как никаких стандартов ни на что нет.


А мне из за этого не нравится C# и особенно — С++. Взял, например, либу где есть деревья выражений, в С++, и никуда не уедешь, потому что в другой либе всё по другому. В C# это уже не проблема, здесь C# порвёт С++ как тузик грелку, но вот мелочи всякие остаются, например мелкие структуры каждый старается сам написать, интерфейсов.
В js нет монстро-библиотек, но вот парадокс — с интеграцией возни меньше. На самом деле есть несколько стеков в джаваскрипте, и в каждом всё более менее согласовано + готовые точки расширения.


ЕА>И как вы там выкручиваетесь без элементарных типов, вроде decimal?


А зачем они нужны ?

I>>Динамика дает возможности, которых в C# нет и никогда не будет


ЕА>Например?


метапрограммирование в рантайме. На этом сделана целая куча либ.
Re[7]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 10:37
Оценка:
Здравствуйте, VladD2, Вы писали:

EP>>2. Некоторые смарт-поинтеры используют подсчёт ссылок. Но они требуются только при наличии shared семантики, которая встречается крайне редко — в большинстве кода никакой ref-counting не нужен.


VD>Это ты расскажи тем кто Хорм в Гуле пилит. Они в итоге замаялись с тормозным и глючным посчетом ссылок и запилили ЖЦ для плюсов. Убогий конечно, но для их задач все равно лучше чем то что можно сделать в плюсах без него.


Похоже этот ЖЦ настолько убог, что нет никакой возможности даже проверить его работоспособности, ибо DOM ведёт себя так, как будто этот ЖЦ сделан целиком и полностью на счетчиках ссылок.
Re[5]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 10:45
Оценка: +1
Здравствуйте, Философ, Вы писали:

I>>Динамика дает возможности, которых в C# нет и никогда не будет


Ф>Какие?


Метапрограммирование в рантайме и плюшки динамики — православный полиморфизм.
Re[5]: C# for Systems Programming
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.01.14 10:50
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Жабаскрип без ЖЦ обходится.


Оно и видно:
https://developers.google.com/v8/design#garb_coll
http://blogs.msdn.com/b/ericlippert/archive/2003/09/17/53038.aspx
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[6]: C# for Systems Programming
От: Евгений Акиньшин grapholite.com
Дата: 03.01.14 11:30
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Евгений Акиньшин, Вы писали:


ЕА>>Здравствуйте, Ikemefula, Вы писали:


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


I>>>Взять браузер — там одни ограничения. Серверные приложения — другие. Десктоп — третьи. Мобайл — четвертые. На кой ляд там одна библиотека, если скажем работа с файлами принципиально отличается во всех четырех случаях ?


ЕА>>А работа с потоками обычно везде одинаковая — практически везде есть базовый IStream (никогда не видел, чтобы с этим были проблемы).


I>В браузер тащить такие либы это мягко говоря преступление. В мобайле такая хрень требует поддержки нативных плагинов. В десктоп и сервере все более менее шоколадно, и вот, что удивтельно, есть либа которая используется и там и там — node.js.


I>Вообще эта хрень пролазит уже в мобайл, не сильно в курсе какие успехи.


Ничего не понял — чем бы помешал единый способ работы с потоками везде, включая браузер и какая поддержка им нужна?


ЕА>>Или, возьмем для примера, хотя бы коллекции и нотификации о изменениях. В том же .net все используют одни и те же IEnumerable, IList, INotifyPropertyChanged и т.д.


I>Я про это говорил — незачем в джаваскрипте писать как в дотнете. Вместо, скажем, INotifyPropertyChanged используется key-value observer, это более мощная вещь. IList не нужен. IEnumerable помог бы, но для этого уже есть кое что в

I>следующем стандарте. INotifyPropertyChanged при желании реализуется очень просто — где надо, берёшь и файришь эвент

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

ЕА>>И как вы там выкручиваетесь без элементарных типов, вроде decimal?


I>А зачем они нужны ?


Деньги считать

I>>>Динамика дает возможности, которых в C# нет и никогда не будет


ЕА>>Например?


I>метапрограммирование в рантайме. На этом сделана целая куча либ.


Ну так в си-шарпе это тоже частенько используется — начиная от компиляции лямбд и кончая полноценной кодогенерацией с запуском компилятора. Понятно, что в динамике это будет удобнее делать, но "нет и никогда не будет" это перебор.
Не шалю, никого не трогаю, починяю примус Diagrams Designer for iPad and Windows 10
Re[6]: C# for Systems Programming
От: Философ Ад http://vk.com/id10256428
Дата: 03.01.14 11:32
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Философ, Вы писали:


I>>>Динамика дает возможности, которых в C# нет и никогда не будет


Ф>>Какие?


I>....плюшки динамики — православный полиморфизм.


Можно подробнее?
Я полиморфизм понимаю с точки зрения классического определения, т.е. например вот так: различное поведение экземпляров производных классов.
или вот так:

Полиморфи́зм — возможность объектов с одинаковой спецификацией иметь различную реализацию. Язык программирования поддерживает полиморфизм, если классы с одинаковой спецификацией могут иметь различную реализацию — например, реализация класса может быть изменена в процессе наследования[1]. Кратко смысл полиморфизма можно выразить фразой: «Один интерфейс, множество реализаций».


Кстати, мы тут вообще об ООП говорим, или о чём?

I>Метапрограммирование в рантайме...


Что мешает метапрограммировать в рантайме на шарпе? CodeDOM отменили?
Всё сказанное выше — личное мнение, если не указано обратное.
Re[6]: C# for Systems Programming
От: Аноним  
Дата: 03.01.14 11:42
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Очень интересно, особенно с учетом того, что "паттерны" есть даже в естественном языке.


Ха, отличный пример — естественный язык! Естественные языки гораздо хуже, избыточнее и непоследовательнее, чем самые плохие из формальных искусственных языков.
Re[5]: C# for Systems Programming
От: Аноним  
Дата: 03.01.14 12:10
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>На C#/Java обобщённый код особо не получается
Автор: Evgeny.Panasyuk
Дата: 04.11.13
. На C++ с этим всё нормально, но приходится то тут, то там подсказывать компилятору (auto, decltype, template, etc).


Чтобы проверить корректность типизации, нужно ввести ограничения, а, точнее, объяснить компилятору свои намерения формально, чтобы он и мог выполнить проверки. Ничего удивительного, что не получается написать нонсенс вроде "обобщенная функция с непонятно какой сигнатурой".

EP>На языках с динамической типизацией этот обобщённый код получается легко и непринуждённо, но приносятся в жертву compile-time проверки.


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

Да и вообще, программа с тотальным отсутствием типов и читается-то хуже, потому что программисту, читающему код, нужно тоже выводить типы, чтобы понять, что код делает.

Например, что делает данная фукнция:

function concatenate(a, b);


А если так:

Matrix3x3 concatenate(Matrix3x3 a, Matrix3x3 b);


Я не знаю, каким изощренным и неземным мышлением надо обладать, чтобы сказать, что с кодом в стиле первого фрагмента работать проще?

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

EP>Собственно код на языках со статической типизацией с каждым годом становится похож на код языков с динамической типизацией (например полиморфные лямбды в C++14, или те же лямбды в C# — удобно ведь). Но динамические языки — это то что доступно здесь и сейчас.


Просто некорректное сравнение. Статическая типизация все равно остается статической, так что динамические языки — это не то, "что доступно здесь и сейчас", а скорее "не хотите ли вы из кареты пересесть в телегу". Для тебя это привлекательно звучит по какой-то причине, для других — не уверен, например, для меня — не особо.
Re[7]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 12:12
Оценка: +1
Здравствуйте, Философ, Вы писали:

Ф>Можно подробнее?

Ф>Я полиморфизм понимаю с точки зрения классического определения, т.е. например вот так: различное поведение экземпляров производных классов.
Ф>или вот так:
Ф>

Ф>Полиморфи́зм — возможность объектов с одинаковой спецификацией иметь различную реализацию. Язык программирования поддерживает полиморфизм, если классы с одинаковой спецификацией могут иметь различную реализацию — например, реализация класса может быть изменена в процессе наследования[1]. Кратко смысл полиморфизма можно выразить фразой: «Один интерфейс, множество реализаций».


Ф>Кстати, мы тут вообще об ООП говорим, или о чём?


Мы про полиморфизм. Не совсем ясно, почему ты ООП вспомнил

Полиморфизмы они разные бывают. В C# система типов очень сильно ограничивает этот самый полиморфизм.
Пример

var f = (int x) => x * 2;




Я понимаю, что у разрабов были основания пойти по такому пути, но сути это не меняет.


I>>Метапрограммирование в рантайме...


Ф>Что мешает метапрограммировать в рантайме на шарпе? CodeDOM отменили?


Вот есть у тебя метод
void Write(string data) {}


Покажи код на CodeDom, который пропатчит метод нужного экземпляр или класс и будет дополнительно файрить эвент. Для простоты возьмём Console.Write.
Re[7]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 12:14
Оценка:
Здравствуйте, Аноним, Вы писали:

I>>Очень интересно, особенно с учетом того, что "паттерны" есть даже в естественном языке.


А>Ха, отличный пример — естественный язык! Естественные языки гораздо хуже, избыточнее и непоследовательнее, чем самые плохие из формальных искусственных языков.


Шо, в самом деле ?

Смотри: "рейз на флопе" — сразу ясно, что к чему. Куда ты собираешься бежать от таких паттернов ?
Re[8]: C# for Systems Programming
От: Аноним  
Дата: 03.01.14 12:18
Оценка:
Здравствуйте, Ikemefula, Вы писали:

А>>Ха, отличный пример — естественный язык! Естественные языки гораздо хуже, избыточнее и непоследовательнее, чем самые плохие из формальных искусственных языков.


I>Шо, в самом деле ?

I>Смотри: "рейз на флопе" — сразу ясно, что к чему. Куда ты собираешься бежать от таких паттернов ?

Нечего возразить? Предлагаю революционную идею: признать, что оппонент прав. Надо бы учиться уже культурно дискутировать в XXI веке.
Re[4]: C# for Systems Programming
От: Evgeny.Panasyuk Россия  
Дата: 03.01.14 12:46
Оценка:
Здравствуйте, Artem Korneev, Вы писали:

EP>>2. C++11 должен быть и выше и правее C++98 — быстрый код стало легче писать.

AK>Он и так выше. А почему он должен быть правее-то?
AK>С++11 позволяет выжать из железа тоже самое, что и С++98

Язык C позволяет выжать из железа тоже самое, но это потребовало бы целое болото кода. По факту же на C в основном используют runtime полиморфизм, там где в C++ легко обходятся статикой.
На Java/C# тоже можно писать очень быстрый код — для этого нужно отказаться практически от всего, и использовать один большой массив байт как кучу и стэк, всё вручную.

AK>, просто облегчает процесс написания кода.


Это "облегчает" дорогого стоит. Именно из-за отсутствия "облегчает" многие языки являются тормозными.

C++11 (а тем более C++14) как раз сильно облегчает написание быстрого кода:
1. auto/decltype — раньше вывод типов был доступен только при вызове шаблонов функций, а сейчас везде. Раньше нужно было либо использовать type-erasure (что дорого в runtime), либо добавлять дополнительные вызовы (что неудобно).
2. Лямбды — если раньше boost::bind на member function был распространён, то сейчас его заменяют лямбды — что более производительно.
3. rvalue references — есть возможность просто скомпилировать старый код новым компилятором получить и ускорение.
4. Появился perfect forwarding, который раньше использовался редко через эмуляцию. Это позволяет легко писать штуки типа vector::emplace_back

EP>>4. JavaScript можно считать более продуктивным потому, что это язык с динамической типизацией. Это позволяет легко писать обобщённый код.

AK>Вы пробовали? У вас получалось легко писать код на JavaScript?

Пробовал. Часто использую Python, иногда JavaScript — и там и там вижу преимущества динамики.

AK>Я про практическую часть спрашивал. У меня JS-код шёл с большим скрипом. Забытая скобочка или, хуже того, опечатка в имени элемента — проявлялись лишь после запуска приложения. А мне нужно было писать часть, которая делает снимки фото-камерой и заливает результат на сервер. Отлаживать приходилось в эмуляторе — "сохранить, скомпилить, перезапустить, ввести все параметры.." И только после этого увидеть в консоли сообщение, что оно не нашло такого элемента.


Unit test'ы и покрытие для динамики более критичны чем для статики.
Re[6]: C# for Systems Programming
От: Evgeny.Panasyuk Россия  
Дата: 03.01.14 13:47
Оценка: +1
Здравствуйте, Аноним, Вы писали:

EP>>На C#/Java обобщённый код особо не получается
Автор: Evgeny.Panasyuk
Дата: 04.11.13
. На C++ с этим всё нормально, но приходится то тут, то там подсказывать компилятору (auto, decltype, template, etc).

А>Чтобы проверить корректность типизации, нужно ввести ограничения, а, точнее, объяснить компилятору свои намерения формально, чтобы он и мог выполнить проверки. Ничего удивительного, что не получается написать нонсенс вроде "обобщенная функция с непонятно какой сигнатурой".

На C++ я спокойно могу написать функцию которая получает на вход функциональный объект, произвольный набор аргументов, применяет аргументы к функциональному объекту и возвращает результат, <b>со всеми статическими проверками</b>:
#include <iostream>

template<typename F, typename ...Args>
auto apply(F f, Args... args)
{
    return f(args...);
}

double foo(int x, double y)
{
    return x + y;
}

int main()
{
    std::cout << apply(foo, 1, 0.1);
}

Тоже самое возможно и в динамике, только менее многословно (сравни apply):
def apply(f, *args):
    return f(*args)

def foo(x, y):
    return x + y

print apply(foo, 1, 0.1)


EP>>На языках с динамической типизацией этот обобщённый код получается легко и непринуждённо, но приносятся в жертву compile-time проверки.

А>Здесь, собственно, нет никакого противопоставления: указываешь типы — получаешь проверки, не указываешь — не получаешь.

В примере выше на C++ типы не указанны, при этом все проверки происходят compile-time
Да и вообще, в большинстве кода явные типы не обязательны — и это отнюдь не означает потерю статических проверок.

А>Я предпочитаю проверки,


Я думаю все предпочитают compile-time проверки.

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


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

А>После статически типизированного языка программировать на динамическим как-то неуютно из-за невозможно проверить даже базовую корректность без запуска.


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

А>Код не только пишется, но еще и читается, меняется, исполняется и отлаживается.

А>Да и вообще, программа с тотальным отсутствием типов и читается-то хуже, потому что программисту, читающему код, нужно тоже выводить типы, чтобы понять, что код делает.
А>Например, что делает данная фукнция:
А>
А>function concatenate(a, b);
А>

А>А если так:
А>
А>Matrix3x3 concatenate(Matrix3x3 a, Matrix3x3 b);
А>

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

Если у тебя concatenate работает с одним единственным типом — то лучше со вторым.
Если же это намного более мощная обобщённая функция, которая работает с разными типами, не прибитыми наследованием к конкретному интерфейсу, то второй вариант никак не получится.
Лучше всего его описать на концепциях C++:
template<SemiGroupElement T>
T concatenate(T a, T b);
А пока нет концепций, используем первый вариант:
template<typename SemiGroupElement>
SemiGroupElement concatenate(SemiGroupElement a, SemiGroupElement b);


А>Ну и про обобщенный код: что, кто-то хочет сказать, что раз функция в первом фрагменте такая вся из себя обобщенная, не должна ли она тогда конкатенировать все подряд: и строки, и матрицы, и списки, и массивы, и звуковые файлы, и еще черт знает что? Слабо написать такую обобщенную функцию?


Не слабо, вот конкретный пример:
template <class T, class Integer, class MonoidOperation>
T power(T x, Integer n, MonoidOperation op);
Это функция возводит x в заданную целую степень n, причём делает это достаточно оптимальным способом.
Ах да, и работает она и с целыми, и с матрицами, и со строками, и списками, и звуковыми файлами.

EP>>Собственно код на языках со статической типизацией с каждым годом становится похож на код языков с динамической типизацией (например полиморфные лямбды в C++14, или те же лямбды в C# — удобно ведь). Но динамические языки — это то что доступно здесь и сейчас.

А>Просто некорректное сравнение. Статическая типизация все равно остается статической, так что динамические языки — это не то, "что доступно здесь и сейчас", а скорее "не хотите ли вы из кареты пересесть в телегу".

Чем же оно некорректное?
Вот Python'ская лябмда:
foo(lambda x: bar(x, 1))
Вот C#:
foo(x => bar(x, 1));
C++:
foo([](auto x){ return bar(x, 1); });

Вопрос — какой тип у параметра лямбды?

А>Для тебя это привлекательно звучит по какой-то причине, для других — не уверен, например, для меня — не особо.


Да мне если честно параллельно кому это привлекательно, а кому нет.
Но факт остаётся фактом — обобщённый код на языках со статической типизацией сильно похож (отсутствием конкретных типов) на код в динамических языках.
Re[6]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.14 13:57
Оценка:
Здравствуйте, Andir, Вы писали:

VD>>Жабаскрип без ЖЦ обходится. Но это ему не шибко помогает.


A>А как же тогда в JavaScript менеджится память?


На подсчете ссылок, вестимо. До недавнего времени многие реализации так были сделаны.

Я это к тому говорил, что Жабахрип он тормозом родился, тормозом и помрет. Наличие или отсутствие ЖЦ на это не сильно влияет. Главные источники тормозов в нем — это динамическая типизация и динамическая природа хранения информации. Это ограничивает оптимизации примитивными вычислениями.

У дотнета, с точки зрения оптимизаций, архитектура самая правильная. Жаль только этому делу мало внимания уделяют. Плюс есть ряд врожденных косяков. Но они не столь фатальны как Жабоскрипные.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.14 13:59
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Давно проверял?

DM>Эта проблема была очень давно, и мне казалось, ее уже давно исправили.

Вообще не проверял. Слышал год назад от тех кто плотно использует Скалу. Уверен, что ничего не изменится пока они for на макросах не перепишут. Но они вроде как пока только в тестовом режиме идут. Или я отстал от жизни?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.14 14:00
Оценка:
Здравствуйте, D. Mon, Вы писали:

VD>>Жабаскрип без ЖЦ обходится.


DM>Это где такой?


Сейчас уже редко где, но раньше был везде. Все первые версии использовали подсчет ссылок. Тормозов это только прибавляло. А главное геморроя.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.14 14:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>И давно ?


С самого своего существования, если конечно, не считать подсчет ссылок видом ЖЦ.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.14 14:14
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>На C#/Java обобщённый код особо не получается
Автор: Evgeny.Panasyuk
Дата: 04.11.13
.


Там речь о небольшой недоработке языка. В Nemerle с этим проблем нет.

Что до обобщенного кода, то это палка о двух концах. Простота написания обобщенного кода в динамических языках это как плюс, так и минус, так как любой код получается обобщенным, что требует больше контроля со стороны разработчиков. В итоге из-за этого разработка больших сильно связанных проектов почти невозможны на динамических языках. Сайты живут за счет слабой связанности (каждая страница как отдельное приложение контачащее с другими через интерфейс).

EP>На C++ с этим всё нормально, но приходится то тут, то там подсказывать компилятору (auto, decltype, template, etc).


На С++ как раз все совсем не нормально. У него присутствуют некоторые плохие черты динамики — типы не всегда проверяются в момент их описания. Шаблоны проверяются только при раскрытии. А это усложняет диагностику ошибок, ухудшает интеллисенс (усложняет его реализацию) и создает прочие проблемы.

EP>Собственно код на языках со статической типизацией с каждым годом становится похож на код языков с динамической типизацией (например полиморфные лямбды в C++14, или те же лямбды в C# — удобно ведь). Но динамические языки — это то что доступно здесь и сейчас.


Лябды не имеют отношения к стаике или динамике. Как и полиморфизм. К динамике имеет отношение исключительно динамическая интерпретация типа "объектов". Весь полиморфизм в динамических языках на ней основан. Но как я уже сказа выше, это палка о двух конца. И мне ее второй конец не нравится сильно больше чем первый.

VD>>Я предпочитают статические проверки типов и качественный интеллисес.


EP>Я думаю все предпочитают статические проверки.


Нет. Я видел не мало людей которые думают иначе. Иначе не было бы столько поклонников Руби, Питона, ПХП, Лиспа.

В динамике намного проще использовать метапрограммирование, например. Хорошее МП в статических языках пока что есть только Немерле. И то там есть что дорабатывать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.14 14:17
Оценка: 4 (2)
Здравствуйте, Evgeny.Panasyuk, Вы писали:

VD>>Это ты расскажи тем кто Хорм в Гуле пилит. Они в итоге замаялись с тормозным и глючным посчетом ссылок и запилили ЖЦ для плюсов. Убогий конечно, но для их задач все равно лучше чем то что можно сделать в плюсах без него.


EP>А есть ссылка?


здесь
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.14 14:18
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Похоже этот ЖЦ настолько убог, что нет никакой возможности даже проверить его работоспособности, ибо DOM ведёт себя так, как будто этот ЖЦ сделан целиком и полностью на счетчиках ссылок.


Его просто еще нет в релизном Хроме. Но обещают в скором времени это исправить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.14 14:19
Оценка:
Здравствуйте, AndrewVK, Вы писали:

VD>>Жабаскрип без ЖЦ обходится.


AVK>Оно и видно:

AVK>https://developers.google.com/v8/design#garb_coll
AVK>http://blogs.msdn.com/b/ericlippert/archive/2003/09/17/53038.aspx

Это последние версии. А на протяжении 10 лет он жил на подсчете ссылок и не чавкал.

Короче, его тормоза далеко не в ЖЦ кроются. Там база гнилая.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 14:31
Оценка:
Здравствуйте, Евгений Акиньшин, Вы писали:

I>>Вообще эта хрень пролазит уже в мобайл, не сильно в курсе какие успехи.


ЕА>Ничего не понял — чем бы помешал единый способ работы с потоками везде, включая браузер и какая поддержка им нужна?


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

Идея простая — в приложение идёт только то, что реально используется. Незачем создавать аналог флеша или сильверлайта но на джаваскрипте.

I>>следующем стандарте. INotifyPropertyChanged при желании реализуется очень просто — где надо, берёшь и файришь эвент


ЕА>Ну так я о том же: каждый у кого возникает желание, придумывает свой, ни с чем не совместимый евент\листенер и потом сиди пиши переходники между ними.


Это больше домыслы. В основном эвенты и листенеры хорошо совместимы.

I>>А зачем они нужны ?


ЕА>Деньги считать


И указателей и всякого другого мусора тоже нет.

I>>>>Динамика дает возможности, которых в C# нет и никогда не будет


ЕА>>>Например?


I>>метапрограммирование в рантайме. На этом сделана целая куча либ.


ЕА>Ну так в си-шарпе это тоже частенько используется — начиная от компиляции лямбд и кончая полноценной кодогенерацией с запуском компилятора. Понятно, что в динамике это будет удобнее делать, но "нет и никогда не будет" это перебор.


Покажи как на C# пропатчить Console.Write
Re[9]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 14:32
Оценка:
Здравствуйте, Аноним, Вы писали:

А>>>Ха, отличный пример — естественный язык! Естественные языки гораздо хуже, избыточнее и непоследовательнее, чем самые плохие из формальных искусственных языков.


I>>Шо, в самом деле ?

I>>Смотри: "рейз на флопе" — сразу ясно, что к чему. Куда ты собираешься бежать от таких паттернов ?

А>Нечего возразить? Предлагаю революционную идею: признать, что оппонент прав. Надо бы учиться уже культурно дискутировать в XXI веке.


Я привел пример паттерна. Покажи каким языком ты собираешься его искоренить.
Re[6]: C# for Systems Programming
От: Evgeny.Panasyuk Россия  
Дата: 03.01.14 14:43
Оценка:
Здравствуйте, VladD2, Вы писали:

EP>>На C#/Java обобщённый код особо не получается
Автор: Evgeny.Panasyuk
Дата: 04.11.13
.

VD>Там речь о небольшой недоработке языка. В Nemerle с этим проблем нет.

На C#/Java получится ли сделать нечто похожее на apply:
template<typename F, typename ...Args>
auto apply(F f, Args... args)
{
    return f(args...);
}
без сильного ухода в динамику?
А во многих динамических языках это доступно уже десятки лет.

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


Согласен — это недостаток.

VD>В итоге из-за этого разработка больших сильно связанных проектов почти невозможны на динамических языках.


А вот это неясно откуда следует.

EP>>На C++ с этим всё нормально, но приходится то тут, то там подсказывать компилятору (auto, decltype, template, etc).

VD>На С++ как раз все совсем не нормально.

Это контр-пример того, что отсутствие явного указания типов обязательно ведёт к ошибкам в runtime.

VD>У него присутствуют некоторые плохие черты динамики — типы не всегда проверяются в момент их описания. Шаблоны проверяются только при раскрытии. А это усложняет диагностику ошибок, ухудшает интеллисенс (усложняет его реализацию) и создает прочие проблемы.


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

EP>>Собственно код на языках со статической типизацией с каждым годом становится похож на код языков с динамической типизацией (например полиморфные лямбды в C++14, или те же лямбды в C# — удобно ведь). Но динамические языки — это то что доступно здесь и сейчас.

VD>Лябды не имеют отношения к стаике или динамике. Как и полиморфизм. К динамике имеет отношение исключительно динамическая интерпретация типа "объектов". Весь полиморфизм в динамических языках на ней основан.

Ты про содержание, а я же говорю про форму (то с чем работает программист):
foo([](auto x){ return bar(x, 1); });

foo(lambda x: bar(x, 1))

Разве не видно что статика по форме, становится похожа на динамику? Конкретные типы указываются всё реже и реже.

VD>>>Я предпочитают статические проверки типов и качественный интеллисес.

EP>>Я думаю все предпочитают статические проверки.
VD>Нет. Я видел не мало людей которые думают иначе. Иначе не было бы столько поклонников Руби, Питона, ПХП, Лиспа.

А из-за чего они думают иначе?
Они действительно против статической проверки (и принципиально не гоняют свой код по статическим анализаторам типа pylint)?
Или же они просто за те возможности которые дают динамические языки здесь и сейчас?
Это разные вещи.

VD>В динамике намного проще использовать метапрограммирование, например. Хорошее МП в статических языках пока что есть только Немерле. И то там есть что дорабатывать.


О том и речь — многие возможности динамических языков могут быть реализованы в статических, но это требует более детальной проработки синтаксиса, компиляторов и т.п.
Re[7]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 14:55
Оценка:
Здравствуйте, VladD2, Вы писали:

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


I>>И давно ?


VD>С самого своего существования, если конечно, не считать подсчет ссылок видом ЖЦ.


У тебя сведения из середины 90х

http://lmgtfy.com/?q=javascript+garbage+collection
Re[7]: C# for Systems Programming
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.01.14 15:24
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Это последние версии.


Последние? Ты по ссылкам то сходи — статья про JScript от 2003 года. Да и V8 релизнули в 2008 году.


VD>Короче, его тормоза далеко не в ЖЦ кроются. Там база гнилая.


Ну, Даффи довольно много спорных утверждений там сделал. Бог с ним, с тормозами, тем более что он таки там самый тормозной на графике, но вот как у него safety оказалась выше и шарпа и джавы — вот это куда интереснее. И ответа на этот вопрос в его статье нет.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[8]: C# for Systems Programming
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.01.14 15:36
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Покажи как на C# пропатчить Console.Write


А зачем?
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[8]: C# for Systems Programming
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.01.14 15:36
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Пример


I>
I>var f = (int x) => x * 2;
I>


I>


И что этот пример должен показать?

I>Вот есть у тебя метод

I>
I>void Write(string data) {}
I>


I>Покажи код на CodeDom, который пропатчит метод нужного экземпляр или класс и будет дополнительно файрить эвент.


http://msdn.microsoft.com/en-us/library/hh549175.aspx
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[5]: C# for Systems Programming
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.01.14 15:36
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Язык C позволяет выжать из железа тоже самое, но это потребовало бы целое болото кода.


На графике это вертикальная ось, а не горизонтальная
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[7]: C# for Systems Programming
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.01.14 15:36
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>На C#/Java получится ли сделать нечто похожее на apply:

EP>
EP>template<typename F, typename ...Args>
EP>auto apply(F f, Args... args)
EP>{
EP>    return f(args...);
EP>}
EP>
без сильного ухода в динамику?


А нафига оно вообще надо такое?

EP>О том и речь — многие возможности динамических языков могут быть реализованы в статических


Ровно как и наоборот. Вопрос не в абстрактных возможностях, а в балансе плюсов и минусов.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[8]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 15:43
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ну, Даффи довольно много спорных утверждений там сделал. Бог с ним, с тормозами, тем более что он таки там самый тормозной на графике, но вот как у него safety оказалась выше и шарпа и джавы — вот это куда интереснее. И ответа на этот вопрос в его статье нет.


У него safety это больше Memory safety чем Type Safety, что очевидно, т.к. неясно чего он упоминает сайд эффекты и прочую хрень.
Re[6]: C# for Systems Programming
От: Evgeny.Panasyuk Россия  
Дата: 03.01.14 15:45
Оценка:
Здравствуйте, AndrewVK, Вы писали:

EP>>Язык C позволяет выжать из железа тоже самое, но это потребовало бы целое болото кода.

AVK>На графике это вертикальная ось, а не горизонтальная

Если performance на графике это теоретический максимум который можно достичь сколько угодно огромным количеством неудобного кода, то Java, C# и JavaScript (за счёт типизированных массивов через asm.js) будут примерно на одной вертикальной оси.
Re[9]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 15:48
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

I>>Покажи как на C# пропатчить Console.Write


AVK>А зачем?


Шоб продемонстрировать заявленое.
Re[7]: C# for Systems Programming
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 03.01.14 15:50
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Жабаскрип без ЖЦ обходится.

DM>>Это где такой?
VD>Сейчас уже редко где, но раньше был везде. Все первые версии использовали подсчет ссылок.

А, ну все ж подсчет ссылок (особенно когда он спрятан под капот) — это один из видов GC. В куче языков до сих пор используется.
Re[9]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 15:55
Оценка:
Здравствуйте, AndrewVK, Вы писали:

I>>
I>>var f = (int x) => x * 2;
I>>


I>>


AVK>И что этот пример должен показать?


Хилый вывод типа и все вытекающие проблемы.

I>>Вот есть у тебя метод

I>>
I>>void Write(string data) {}
I>>


I>>Покажи код на CodeDom, который пропатчит метод нужного экземпляр или класс и будет дополнительно файрить эвент.


AVK>http://msdn.microsoft.com/en-us/library/hh549175.aspx


Покажешь, как выполнить шаг Add Fake Assembly в рантайме и как заставить скомпилироваться код ?

var old = obj.method;

obj.method = function() { me.fireSomeEvent(arguments); old.apply(this, arguments); }


Вот и весь рокетсаенс
Re[8]: C# for Systems Programming
От: Евгений Акиньшин grapholite.com
Дата: 03.01.14 16:13
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Евгений Акиньшин, Вы писали:


I>>>Вообще эта хрень пролазит уже в мобайл, не сильно в курсе какие успехи.


ЕА>>Ничего не понял — чем бы помешал единый способ работы с потоками везде, включая браузер и какая поддержка им нужна?


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


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


I>Идея простая — в приложение идёт только то, что реально используется. Незачем создавать аналог флеша или сильверлайта но на джаваскрипте.


I>>>следующем стандарте. INotifyPropertyChanged при желании реализуется очень просто — где надо, берёшь и файришь эвент


ЕА>>Ну так я о том же: каждый у кого возникает желание, придумывает свой, ни с чем не совместимый евент\листенер и потом сиди пиши переходники между ними.


I>Это больше домыслы. В основном эвенты и листенеры хорошо совместимы.


Да ладно — каждый mvvm-подобный фреймворк типа knockoutjs, kendoui требует все отнаследовать от определенного типа модели, со своими сигнатурами листенеров — нигде такого бардака больше не видел.


I>>>А зачем они нужны ?


ЕА>>Деньги считать


I>И указателей и всякого другого мусора тоже нет.


Т.е. типы с фиксированной точкой это мусор

I>>>>>Динамика дает возможности, которых в C# нет и никогда не будет


ЕА>>>>Например?


I>>>метапрограммирование в рантайме. На этом сделана целая куча либ.


ЕА>>Ну так в си-шарпе это тоже частенько используется — начиная от компиляции лямбд и кончая полноценной кодогенерацией с запуском компилятора. Понятно, что в динамике это будет удобнее делать, но "нет и никогда не будет" это перебор.


I>Покажи как на C# пропатчить Console.Write


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

Чтобы патчить пользовательские типы есть несколько библиотек для аспектно-ориентированного программирования, ну я бы это тоже очень осторожно использовал.
Не шалю, никого не трогаю, починяю примус Diagrams Designer for iPad and Windows 10
Re[9]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 16:42
Оценка:
Здравствуйте, Евгений Акиньшин, Вы писали:

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


ЕА>Так я вроде ничего не говорил про файловые операции. Просто во всех средах с которыми я сталкивался, любая библиотека обработки данных написана в общем виде с использованием потоков и только в jscript каждый раз придумывают несовместимый велосипед.


Что за обработка данных или какие велосипеды придумывают в джаваскрипте ?

I>>Это больше домыслы. В основном эвенты и листенеры хорошо совместимы.


ЕА>Да ладно — каждый mvvm-подобный фреймворк типа knockoutjs, kendoui требует все отнаследовать от определенного типа модели, со своими сигнатурами листенеров — нигде такого бардака больше не видел.


Это специфика mvvm похоже. Разрабов нокаута я бы бил в каптёрке каждые 15 минут.

I>>И указателей и всякого другого мусора тоже нет.


ЕА>Т.е. типы с фиксированной точкой это мусор


И это очевидно. Тебя ведь не расстраивает, что С++ искаропки не может посчитать sinus(Some(1.2)) или Sinus(Nullable(1)) или Sinus([1,2,3,4,5,6]) ?

I>>Покажи как на C# пропатчить Console.Write


ЕА>Не, этого нам не надо — каждая библиотека пропатчит половину базовых типов и потом эту кашу отлаживать


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

ЕА>Чтобы патчить пользовательские типы есть несколько библиотек для аспектно-ориентированного программирования, ну я бы это тоже очень осторожно использовал.


Патчить много чего можно
Re[8]: C# for Systems Programming
От: Sharov Россия  
Дата: 03.01.14 17:12
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ну, Даффи довольно много спорных утверждений там сделал. Бог с ним, с тормозами, тем более что он таки там самый тормозной на графике, но вот как у него safety оказалась выше и шарпа и джавы — вот это куда интереснее. И ответа на этот вопрос в его статье нет.


Там народ уже возмутился. И да, все же safety&productivity, а не просто safety.
Кодом людям нужно помогать!
Re[8]: C# for Systems Programming
От: Философ Ад http://vk.com/id10256428
Дата: 03.01.14 17:55
Оценка:
Здравствуйте, Ikemefula, Вы писали:


Ф>>Кстати, мы тут вообще об ООП говорим, или о чём?


I>Мы про полиморфизм. Не совсем ясно, почему ты ООП вспомнил


I>Полиморфизмы они разные бывают.


Какие, например? Что ты подразумеваешь под этим понятием, определи понятие — походу мы на разных языках разговариваем.


I>В C# система типов очень сильно ограничивает этот самый полиморфизм.

I>Пример
I>
I>var f = (int x) => x * 2;
I>


В каком месте в этом примере должен быть полиморфизм?


I>>>Метапрограммирование в рантайме...


Ф>>Что мешает метапрограммировать в рантайме на шарпе? CodeDOM отменили?


I>Вот есть у тебя метод

I>
I>void Write(string data) {}
I>


I>Покажи код на CodeDom, который пропатчит метод нужного экземпляр или класс и будет дополнительно файрить эвент.


Чего делать с ивентом?
Зачем это делать именно в рантайме, почему нельзя тоже самое, например в компайл тайме?
Всё сказанное выше — личное мнение, если не указано обратное.
Re[10]: C# for Systems Programming
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.01.14 18:52
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Хилый вывод типа и все вытекающие проблемы.


Какая связь между выводом типов и динамическим полиморфизмом?

AVK>>http://msdn.microsoft.com/en-us/library/hh549175.aspx

I>Покажешь, как выполнить шаг Add Fake Assembly в рантайме и как заставить скомпилироваться код ?

А что, думаешь что это невозможно?
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[7]: C# for Systems Programming
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.01.14 18:52
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Если performance на графике это теоретический максимум который можно достичь сколько угодно огромным количеством неудобного кода, то Java, C# и JavaScript (за счёт типизированных массивов через asm.js) будут примерно на одной вертикальной оси.


Не будут.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[11]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 19:14
Оценка:
Здравствуйте, AndrewVK, Вы писали:

I>>Хилый вывод типа и все вытекающие проблемы.


AVK>Какая связь между выводом типов и динамическим полиморфизмом?


Пудозреваю, связь такая — ты увидел лямбду, которая не скомпилится и решил, что я говорю про динамический полиморфизм. Годится ?

AVK>>>http://msdn.microsoft.com/en-us/library/hh549175.aspx

I>>Покажешь, как выполнить шаг Add Fake Assembly в рантайме и как заставить скомпилироваться код ?

AVK>А что, думаешь что это невозможно?


Ты для начала покажи, а потом уже будем выяснять, о чем я думаю. Желательно как у меня — в три строки и что бы это _работало_.
Re[9]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 19:17
Оценка:
Здравствуйте, Философ, Вы писали:

Ф>Какие, например? Что ты подразумеваешь под этим понятием, определи понятие — походу мы на разных языках разговариваем.


Да вроде об одном и том же.

I>>В C# система типов очень сильно ограничивает этот самый полиморфизм.

I>>Пример
I>>
I>>var f = (int x) => x * 2;
I>>


Ф>В каком месте в этом примере должен быть полиморфизм?


В этом месте полиморфизма вообще нет, зато это место мешает применять полиморфизм и вынуждает тебя заниматься подсказками компилятору.

I>>Вот есть у тебя метод

I>>
I>>void Write(string data) {}
I>>


I>>Покажи код на CodeDom, который пропатчит метод нужного экземпляр или класс и будет дополнительно файрить эвент.


Ф>Чего делать с ивентом?


Файрить.

Ф>Зачем это делать именно в рантайме, почему нельзя тоже самое, например в компайл тайме?


Можно и в компайлтайм, но ты ведь утверждаешь, что в C# не хуже. Вот и покажи это.
Re[12]: C# for Systems Programming
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.01.14 20:29
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Пудозреваю, связь такая — ты увидел лямбду, которая не скомпилится и решил, что я говорю про динамический полиморфизм. Годится ?


Все ходы записаны:

I>....плюшки динамики — православный полиморфизм.

Ф>Можно подробнее?

I>Полиморфизмы они разные бывают. В C# система типов очень сильно ограничивает этот самый полиморфизм.
I>Пример

AVK>И что этот пример должен показать?

I>Хилый вывод типа и все вытекающие проблемы.

AVK>Какая связь между выводом типов и динамическим полиморфизмом?

I>Пудозреваю, связь такая — ты увидел лямбду, которая не скомпилится и решил, что я говорю про динамический полиморфизм. Годится ?


Так что нет, не годится.

AVK>>А что, думаешь что это невозможно?

I>Ты для начала покажи, а потом уже будем выяснять, о чем я думаю. Желательно как у меня — в три строки и что бы это _работало_.

Ну началось. Принципиальная возможность есть? Есть. А показывать тебе я буду только по предоплате.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[8]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.14 20:40
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>А, ну все ж подсчет ссылок (особенно когда он спрятан под капот) — это один из видов GC.


Это если уж очень за уши притянуть. Подсчет ссылок все же к ЖЦ отношения не имеет и бы известен когда о ЖЦ еще и речи не шло. Подсчет ссылок это единственный более менее автоматический способ управления памятью в языках не рассчитанных на ЖЦ (читаем С/С++).

DM>В куче языков до сих пор используется.


Я говорил о том, что не ЖЦ дело. Когда ЖЦ не было, производительность была еще хуже.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 20:56
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Все ходы записаны:

AVK>

I>>....плюшки динамики — православный полиморфизм.

Ф>>Можно подробнее?

I>>Полиморфизмы они разные бывают. В C# система типов очень сильно ограничивает этот самый полиморфизм.
I>>Пример

AVK>>И что этот пример должен показать?

I>>Хилый вывод типа и все вытекающие проблемы.

AVK>>Какая связь между выводом типов и динамическим полиморфизмом?

I>>Пудозреваю, связь такая — ты увидел лямбду, которая не скомпилится и решил, что я говорю про динамический полиморфизм. Годится ?


AVK>Так что нет, не годится.


Православный ты прочитал как динамический ? Бывает. Я то сравниваю позможности полиморфизма в джаваскрипте и возможностями полимормизма в C#, а тебе хочется непойми чего, динамический с динамическим сравнить наверное Сравнивай сам.

Из лямбды понятно, что вопрос никакого от

AVK>Ну началось. Принципиальная возможность есть? Есть. А показывать тебе я буду только по предоплате.


Принципиальная возможность это не интересно. Нет никакого значения сколько ты напишешь неудобного кода, а в джаваскприте это искаропки.
Re[14]: C# for Systems Programming
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.01.14 21:14
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Православный ты прочитал как динамический ?


Нет, просто в JS ничего статического нет, так что полиморфизм там может быть исключительно динамическим.

AVK>>Ну началось. Принципиальная возможность есть? Есть. А показывать тебе я буду только по предоплате.

I>Принципиальная возможность это не интересно.

А практическая определяется потребностями. На вопрос зачем тебе понадобилось заменять Console.Write ты нормально ответить не смог.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[15]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.01.14 21:29
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Нет, просто в JS ничего статического нет, так что полиморфизм там может быть исключительно динамическим.


Спасибо, капитан. Каким законом запрещено сравнивать возможности, скажем, того полиморфизма, что был в C# до динамиков с возможностями джаваскриптового динамического полиморфизма ?

AVK>>>Ну началось. Принципиальная возможность есть? Есть. А показывать тебе я буду только по предоплате.

I>>Принципиальная возможность это не интересно.

AVK>А практическая определяется потребностями. На вопрос зачем тебе понадобилось заменять Console.Write ты нормально ответить не смог.


Я ж сказал — для демонстрации сказаного. Если можно пропатчить один метод, можно пропатчить любой другой.
Re[16]: C# for Systems Programming
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.01.14 23:23
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Каким законом запрещено сравнивать возможности, скажем, того полиморфизма, что был в C# до динамиков с возможностями джаваскриптового динамического полиморфизма ?


Повторяю вопрос: "Какая связь между выводом типов и динамическим полиморфизмом?".

AVK>>А практическая определяется потребностями. На вопрос зачем тебе понадобилось заменять Console.Write ты нормально ответить не смог.

I>Я ж сказал — для демонстрации сказаного.

То есть нафик не нужно. ЧТД.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[10]: C# for Systems Programming
От: Евгений Акиньшин grapholite.com
Дата: 04.01.14 04:40
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Евгений Акиньшин, Вы писали:


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


ЕА>>Так я вроде ничего не говорил про файловые операции. Просто во всех средах с которыми я сталкивался, любая библиотека обработки данных написана в общем виде с использованием потоков и только в jscript каждый раз придумывают несовместимый велосипед.


I>Что за обработка данных или какие велосипеды придумывают в джаваскрипте ?


Любая обработка данных: архивация, кодеры\декоры графических форматов, вывод текста. Потоки позволяют легко делать композицию из таких вещей.

I>>>Это больше домыслы. В основном эвенты и листенеры хорошо совместимы.


ЕА>>Да ладно — каждый mvvm-подобный фреймворк типа knockoutjs, kendoui требует все отнаследовать от определенного типа модели, со своими сигнатурами листенеров — нигде такого бардака больше не видел.


I>Это специфика mvvm похоже. Разрабов нокаута я бы бил в каптёрке каждые 15 минут.


Почему-то это специфика только в jscript проявляется Может все-таки специфика jscript.


I>>>И указателей и всякого другого мусора тоже нет.


ЕА>>Т.е. типы с фиксированной точкой это мусор


I>И это очевидно. Тебя ведь не расстраивает, что С++ искаропки не может посчитать sinus(Some(1.2)) или Sinus(Nullable(1)) или Sinus([1,2,3,4,5,6]) ?


А как одно с другим связано?
Не шалю, никого не трогаю, починяю примус Diagrams Designer for iPad and Windows 10
Re[9]: C# for Systems Programming
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 04.01.14 07:35
Оценка:
Здравствуйте, VladD2, Вы писали:

DM>>А, ну все ж подсчет ссылок (особенно когда он спрятан под капот) — это один из видов GC.

VD>Это если уж очень за уши притянуть.

Это вопрос терминологии, и большая часть литературы по этому вопросу с тобой не согласна. Да и пролетариат тоже: вон Питон и РНР до сих пор подсчет ссылок используют.

VD>Подсчет ссылок все же к ЖЦ отношения не имеет и бы известен когда о ЖЦ еще и речи не шло.


А ты в курсе, что сборка мусора подсчетом ссылок была изобретена (или по крайней мере описана) позже, чем tracing GC?

In 1960, researchers introduced the two main branches of automatic garbage collection: tracing and reference counting [14, 24].
* G. E. Collins. A method for overlapping and erasure of lists. Commun. ACM, 3(12):655–657, December 1960.
* J. McCarthy. Recursive functions of symbolic expressions and their computation by machine, part I. Commun. ACM, 3(4):184–195, April 1960.


VD>Я говорил о том, что не ЖЦ дело. Когда ЖЦ не было, производительность была еще хуже.


Если речь по JS, то там рост производительности за последнюю декаду вызван в основном изменением подхода к реализации интерпретаторов: от примитивных интерпретаторов через JIT к более полноценному компилятору, перекомпилирующему код с учетом получаемой в динамиеке информации о типах. См. первую часть тут, например:
http://www.infoq.com/presentations/dart-compiler
Re[11]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.01.14 08:34
Оценка:
Здравствуйте, Евгений Акиньшин, Вы писали:

I>>Что за обработка данных или какие велосипеды придумывают в джаваскрипте ?


ЕА>Любая обработка данных: архивация, кодеры\декоры графических форматов, вывод текста. Потоки позволяют легко делать композицию из таких вещей.


Из всего этого JS может позволить только вывод текста, и то смотря куда. Все остальное требует нативного кода.

I>>>>Это больше домыслы. В основном эвенты и листенеры хорошо совместимы.


I>>Это специфика mvvm похоже. Разрабов нокаута я бы бил в каптёрке каждые 15 минут.

ЕА>Почему-то это специфика только в jscript проявляется Может все-таки специфика jscript.

Другие то либы нормальные

ЕА>>>Т.е. типы с фиксированной точкой это мусор


I>>И это очевидно. Тебя ведь не расстраивает, что С++ искаропки не может посчитать sinus(Some(1.2)) или Sinus(Nullable(1)) или Sinus([1,2,3,4,5,6]) ?


ЕА>А как одно с другим связано?


Фича X отсутствует в языке Y
Re[17]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.01.14 10:34
Оценка: -1
Здравствуйте, AndrewVK, Вы писали:

I>>Каким законом запрещено сравнивать возможности, скажем, того полиморфизма, что был в C# до динамиков с возможностями джаваскриптового динамического полиморфизма ?


AVK>Повторяю вопрос: "Какая связь между выводом типов и динамическим полиморфизмом?".


Попробуй еще раз.

AVK>>>А практическая определяется потребностями. На вопрос зачем тебе понадобилось заменять Console.Write ты нормально ответить не смог.

I>>Я ж сказал — для демонстрации сказаного.

AVK>То есть нафик не нужно. ЧТД.


Пудозреваю ты хочешь сказать чтото навроде "а в дотнете мы такое не используем". Так и говори, а то в джаваскрипте указаная техника используется практически везде.
Re[10]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.01.14 12:04
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Это вопрос терминологии, и большая часть литературы по этому вопросу с тобой не согласна. Да и пролетариат тоже: вон Питон и РНР до сих пор подсчет ссылок используют.


Вот и не превращай этот вопрос в вопрос терминологии.

Здесь речь идет о производительности. Подразумевается (и не безосновательно), что ЖЦ создает огромные накладные расходы. Подсчет ссылок этих проблем не имеет и, если бы проблемы языков были только в ЖЦ, мог бы сделать язык супер быстрым. Но, увы.

DM>А ты в курсе, что сборка мусора подсчетом ссылок была изобретена (или по крайней мере описана) позже, чем tracing GC?


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

DM>* J. McCarthy. Recursive functions of symbolic expressions and their computation by machine, part I. Commun. ACM, 3(4):184–195, April 1960.[/q]


Ты в курсе кто такой McCarthy? Это изобретатель лиспа, а Лисп — это из другой вселенной. Многие до стих пор не знают, что это такое и зачем оно нужно.

И вообще, это разговор не о чем.

VD>>Я говорил о том, что не ЖЦ дело. Когда ЖЦ не было, производительность была еще хуже.


DM>Если речь по JS, то там рост производительности за последнюю декаду вызван в основном изменением подхода к реализации интерпретаторов: от примитивных интерпретаторов через JIT к более полноценному компилятору, перекомпилирующему код с учетом получаемой в динамиеке информации о типах.


Понятно. Кому-то тут хочется поспорить ради спора.

Рост скорости JS — это нечто вроде лечения гомеопатией, то есть самообман.

DM>См. первую часть тут, например:

DM>http://www.infoq.com/presentations/dart-compiler

Ага, ага. Все почти так с двумя небольшими уточнениями.

1. Dart это совершенно другой язык, мало похожий на JS.
2. На сегодня. Dart тормоз даже по сравнению с явой и дотнетом.

Так что ты меньше верь в сказки. Динамика и производительность две несовместимые вещи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: C# for Systems Programming
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 04.01.14 12:18
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здесь речь идет о производительности. Подразумевается (и не безосновательно), что ЖЦ создает огромные накладные расходы. Подсчет ссылок этих проблем не имеет и, если бы проблемы языков были только в ЖЦ, мог бы сделать язык супер быстрым. Но, увы.


Глупости пишешь, reference counting GC медленнее tracing GC. Cм. ссылки выше.

VD>Ты в курсе кто такой McCarthy? Это изобретатель лиспа, а Лисп — это из другой вселенной. Многие до стих пор не знают, что это такое и зачем оно нужно.




VD>Рост скорости JS — это нечто вроде лечения гомеопатией, то есть самообман.


Это банальное сравнение бенчмарков.

DM>>См. первую часть тут, например:

DM>>http://www.infoq.com/presentations/dart-compiler
VD>Ага, ага. Все почти так с двумя небольшими уточнениями.
VD>1. Dart это ...

Дядь, там первая половина рассказа — не про Dart совсем, а именно про устройство V8 и то, как они JavaScript ускоряли.
Re[11]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.01.14 12:22
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Понятно. Кому-то тут хочется поспорить ради спора.


Вероятно тебе

VD>Рост скорости JS — это нечто вроде лечения гомеопатией, то есть самообман.

VD>Так что ты меньше верь в сказки. Динамика и производительность две несовместимые вещи.

Ты определись чего ты хочешь сказать. Если "JS медленнее С++" то это очень интересно, но как то без тебя все это знают.
Если "Рост скорости JS — ... самообман" то мягко говоря у тебя сведения конца 90х

Скажем, в конце 90х писать десктоп, мобайл на JS никто в своём уме даже не пробовал, перформанса было около одной строчки в секунду, даже веб считай был без джаваскрипта, на страницу было до десяти строчек js.
В середине нулевых все изменилось
1 гуглмапс
2 гуглдокс
3 офис онлайн
4 OWA — последняя версия не хуже десктопа

Где то 2009м появился серверный джаваскрипт и снова благодаря увеличению перформанса движка V8

В начала 10х появляется
1 десктопный джаваскрипт
2 мобильный джаваскрипт

И все это благодаря росту перформанса V8

Гугл готовит внятный ЖЦ для V8, что увеличит перформанс, что очень, очень критично для десктопа и мобильных приложений.
Re[12]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.01.14 13:03
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Дядь, там первая половина рассказа — не про Dart совсем, а именно про устройство V8 и то, как они JavaScript ускоряли.


И где результаты? Жабахрип сравнился хотя бы с дотнетом по производительности?

Там борьба идет за проценты. Выбор между очень плохой производительностью и просто плохой. Сравнивать Жабавсхлип с С++ просто смешно.

ЗЫ

Короче, мне этот разговор не интересен. Верь сказкам в одиночестве.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.01.14 13:22
Оценка:
Здравствуйте, Ikemefula, Вы писали:

VD>>Рост скорости JS — это нечто вроде лечения гомеопатией, то есть самообман.

VD>>Так что ты меньше верь в сказки. Динамика и производительность две несовместимые вещи.

I>Ты определись чего ты хочешь сказать. Если "JS медленнее С++" то это очень интересно, но как то без тебя все это знают.


Я что хотел, то и сказал — тормоза Жабакрипта заключаются отнюдь не в ЖЦ. Они в архитектуре языка. В его динамической основе. Никакие оптимизации этого факта не устранят. Именно по этому в Гугле решили придумать Datr.

I>Если "Рост скорости JS — ... самообман" то мягко говоря у тебя сведения конца 90х


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

I>Скажем, в конце 90х писать десктоп, мобайл на JS никто в своём уме даже не пробовал,


Я пробовал. Проблема была только одна — броузеры еще только начинали поддерживать программируемость. Первый броузер поддерживающий DHTML появился в 1997-м году.

До этого много лет создавали GUI на VB, мало чем отличавшемся по производительности от Жабахрипа. И это не странно, так как отзывчивость гуя скорее определяется используемыми компонентами и разумностью автора.

I>перформанса было около одной строчки в секунду,


Бред.

I>даже веб считай был без джаваскрипта, на страницу было до десяти строчек js.


А что ему было делать на странице, броузеров позволяющих что-то делать с конетнтом не было?

I>В середине нулевых все изменилось


Все изменилось в начале нулевых.

I>Где то 2009м появился серверный джаваскрипт и снова благодаря увеличению перформанса движка V8


Гы-гы.

I>В начала 10х появляется

I>1 десктопный джаваскрипт
I>2 мобильный джаваскрипт

Гы-гы.

I>И все это благодаря росту перформанса V8


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

I>Гугл готовит внятный ЖЦ для V8, что увеличит перформанс, что очень, очень критично для десктопа и мобильных приложений.


Ага. В очередной раз. Кстати, у V8 давно уже точный ЖЦ. Ты видимо путаешь его с ЖЦ для АПИ Хрома.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.01.14 14:22
Оценка:
Здравствуйте, VladD2, Вы писали:

I>>Если "Рост скорости JS — ... самообман" то мягко говоря у тебя сведения конца 90х


VD>Это фундаментальные принципы. Они не могут устареть. Динамический язык, да еще и с прототипным ООП нельзя эффективно компилировать в процессорые инструкции. В нем всегда будет огромный оверхэд. Его можно сократить, но нельзя устранить. Для его устранения нужно менять язык.


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

I>>Скажем, в конце 90х писать десктоп, мобайл на JS никто в своём уме даже не пробовал,


VD>Я пробовал. Проблема была только одна — броузеры еще только начинали поддерживать программируемость. Первый броузер поддерживающий DHTML появился в 1997-м году.


Вот я и говорю — у тебя сведения аккурат с тех пор.

VD>До этого много лет создавали GUI на VB, мало чем отличавшемся по производительности от Жабахрипа. И это не странно, так как отзывчивость гуя скорее определяется используемыми компонентами и разумностью автора.


С учетом того, что VB был быстрее того JS где то в 100 раз, всё верно. У нас тогда были плагины на js, vb, пейтоне и кое каких других вещах, так что извини, тебе не поверю.

I>>перформанса было около одной строчки в секунду,


I>>даже веб считай был без джаваскрипта, на страницу было до десяти строчек js.


VD>А что ему было делать на странице, броузеров позволяющих что-то делать с конетнтом не было?


ie4 — 97й год. XHR появился в 99м.

I>>В середине нулевых все изменилось


VD>Все изменилось в начале нулевых.


В середине. До того были просто приседания с dhtml, стилями и всякими сабмитами. Все это возможно было и в конце 90х

I>>И все это благодаря росту перформанса V8


VD>До него все это было. То что ты в то время в школу ходил, не значит, что тогда не было жизни.


Назови серверный фремворк на джаваскрипте, либы разумеется, до 2009го, который массово применялся. Серверный, это хотя бы самый минимум — можно с нуля накидать внятный http сервер.
Re[13]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.01.14 14:25
Оценка:
Здравствуйте, VladD2, Вы писали:

DM>>Дядь, там первая половина рассказа — не про Dart совсем, а именно про устройство V8 и то, как они JavaScript ускоряли.


VD>И где результаты? Жабахрип сравнился хотя бы с дотнетом по производительности?


Конечно. Хочешь, напишем вместе тест отрисовки в канвас или тест регэкспов, узнаешь много нового.

VD>Там борьба идет за проценты. Выбор между очень плохой производительностью и просто плохой. Сравнивать Жабавсхлип с С++ просто смешно.


Смотри, аналогичный аргумент — дотнет сравнивать с оптимизироваными числодробилками на С++ смешно, следовательно прогресса в дотнет не было
Re[13]: C# for Systems Programming
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 04.01.14 15:53
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>И где результаты? Жабахрип сравнился хотя бы с дотнетом по производительности?

VD>Короче, мне этот разговор не интересен. Верь сказкам в одиночестве.

Каким сказкам? Разве кто-то сравнивает его по скорости с С++ или C#? Ты сам себе что-то придумываешь. Но если сравнивать с другими динамическими языками, что логично, то результаты очень даже.
Re[12]: C# for Systems Programming
От: Sharov Россия  
Дата: 04.01.14 19:16
Оценка:
Здравствуйте, Ikemefula, Вы писали:


I>В середине нулевых все изменилось

I>1 гуглмапс
I>2 гуглдокс
I>3 офис онлайн
I>4 OWA — последняя версия не хуже десктопа

Это все благодаря закону Мура.


I>Где то 2009м появился серверный джаваскрипт и снова благодаря увеличению перформанса движка V8


I>В начала 10х появляется

I>1 десктопный джаваскрипт
I>2 мобильный джаваскрипт

Поскольку уперлись в рост производительности одного ядра, серьезно взялись за софт.

Процитирую Джефа Атвуда:

I found that the performance of JavaScript improved a hundredfold between 1996 and 2006.
If Web 2.0 is built on a backbone of JavaScript, it’s largely possible only because
of those crucial Moore’s Law performance improvements.


Цитата взята из этого поста(который в свою очередь цитируют оригинальную запись Атвуда).Очень и очень рекомендую ознакомится с блогозаписью -- на злобу дня, как говорится. Извините, если баян...
Кодом людям нужно помогать!
Re[13]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.01.14 20:39
Оценка:
Здравствуйте, Sharov, Вы писали:

I>>В середине нулевых все изменилось

I>>1 гуглмапс
I>>2 гуглдокс
I>>3 офис онлайн
I>>4 OWA — последняя версия не хуже десктопа

S>Это все благодаря закону Мура.


ля-ля-ля

I>>2 мобильный джаваскрипт


S>Процитирую Джефа Атвуда:


Ты лучше на сегодняшнем железе запусти JS старого образца и нового. Закон Мура к этой разнице не имеет никакого отношения, т.к. перформанс одного и того же ядра вырастает более чем в 1000 раз в зависимости от версии JS.


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

Движок джаваскрипта раньше был тупым интерпретатором, а сейчас это фактически компилятор, вот тебе и разница.
Re[14]: C# for Systems Programming
От: Sharov Россия  
Дата: 04.01.14 21:17
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Ты лучше на сегодняшнем железе запусти JS старого образца и нового. Закон Мура к этой разнице не имеет никакого отношения, т.к. перформанс одного и того же ядра вырастает более чем в 1000 раз в зависимости от версии JS.


Охохошуньки! Ага, в тыщи раз...


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


Вы вообще внимательно прочитали мой комментарий? То что он раньше был "тупым интерпретатором", но
тем не менее использовался ( и на ура!), вытягивало железо. Когда уперлись в железный рост, превратили
в компилятор.
Кодом людям нужно помогать!
Re[14]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.01.14 22:21
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Каким сказкам? Разве кто-то сравнивает его по скорости с С++ или C#? Ты сам себе что-то придумываешь. Но если сравнивать с другими динамическими языками, что логично, то результаты очень даже.


Ты статью в теме то читал?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.01.14 22:41
Оценка:
Здравствуйте, Sharov, Вы писали:

I>>Ты лучше на сегодняшнем железе запусти JS старого образца и нового. Закон Мура к этой разнице не имеет никакого отношения, т.к. перформанс одного и того же ядра вырастает более чем в 1000 раз в зависимости от версии JS.


S>Охохошуньки! Ага, в тыщи раз...


А тебе религия запрещает инсталировать старый нетскейп и пускануть в ём тестовый джаваскрипт ? Этот браузер можно найти в инете. Если это сложно, можно взять мозиллу версии 1.0 или 1.5, тоже неплохо сгодится для замеров.

Собтсвенно при желании можно IE6 найти и пускануть на современном железе, но он уже намного быстрее неткапа .

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


S>Вы вообще внимательно прочитали мой комментарий? То что он раньше был "тупым интерпретатором", но

S>тем не менее использовался ( и на ура!), вытягивало железо. Когда уперлись в железный рост, превратили
S>в компилятор.

Не использовался и железо не вытягивало. Не было его ни в мбайле, ни в десктопе, ни, тем более, в сервере.

Джаваскрипт ускорять начали задолго до того, как уперлись в железо. Разуй глаза — рост частоты остановился во второй половине нулевых, а мега-приложения на джаваскрипте появилисьс в первой половине нулевых.
Re[15]: C# for Systems Programming
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 05.01.14 08:01
Оценка:
Здравствуйте, VladD2, Вы писали:

DM>>Каким сказкам? Разве кто-то сравнивает его по скорости с С++ или C#? Ты сам себе что-то придумываешь. Но если сравнивать с другими динамическими языками, что логично, то результаты очень даже.

VD>Ты статью в теме то читал?

Читал, еще до того, как ее здесь запостили.
А ты сам-то читал? Где там говорится, что JS стал сравним по скорости с С++ или C#? Там он даже нарисован слева, как самый тормоз.
Re[16]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.01.14 17:09
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>А ты сам-то читал? Где там говорится, что JS стал сравним по скорости с С++ или C#? Там он даже нарисован слева, как самый тормоз.


Вообще-то там на графие жабоскрип запихали в один квадрат с шарпом и жабой, что намекает на то, что их в одной весовой категории держат. А уж по уровню языка так и вообще смешно получается.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.01.14 18:37
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Вообще-то там на графие жабоскрип запихали в один квадрат с шарпом и жабой, что намекает на то, что их в одной весовой категории держат. А уж по уровню языка так и вообще смешно получается.


По уровню он намного выше чем C# и джава. В ём даже rank-2 полиморфизм есть.
Re[17]: C# for Systems Programming
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 07.01.14 03:41
Оценка: :))
Здравствуйте, VladD2, Вы писали:

VD>Вообще-то там на графие жабоскрип запихали в один квадрат с шарпом и жабой,


Так более тормозного квадрата там уже не было.
Re[7]: C# for Systems Programming
От: Аноним  
Дата: 07.01.14 10:13
Оценка:
Здравствуйте, VladD2, Вы писали:

DM>>Давно проверял?

DM>>Эта проблема была очень давно, и мне казалось, ее уже давно исправили.
VD>Вообще не проверял. Слышал год назад от тех кто плотно использует Скалу. Уверен, что ничего не изменится пока они for на макросах не перепишут. Но они вроде как пока только в тестовом режиме идут. Или я отстал от жизни?

только вчера лазил посмотреть во что превращается простой for по списку и массиву. Там полиморфизм, специфичный для каждого контейнера.
Вот такой код

val A = List(1 to 10 : _*)
A foreach println

превращается в
  @inline override final
  def foreach[B](f: A => B) {
    var these = this
    while (!these.isEmpty) {
      f(these.head)
      these = these.tail
    }
  }

а для массивов в
  override /*IterableLike*/
  def foreach[U](f: A => U): Unit = {
    var i = 0
    val len = length
    while (i < len) { f(this(i)); i += 1 }
  }


Ни в одном, ни во втором случае я не вижу проблем для оптимизатора.
Re[8]: C# for Systems Programming
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.01.14 12:15
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Ни в одном, ни во втором случае я не вижу проблем для оптимизатора.


Я очень рад за тебя. Жаль только что оптимизатором работаешь не ты, потому что люди испльзующие Скалу на практике говорят о замедлении в несколько раз (точную цифру не помню, то ли 5, то ли 10).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: C# for Systems Programming
От: alexzz  
Дата: 09.01.14 16:51
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>>>
I>>>var f = (int x) => x * 2;
I>>>

AVK>>И что этот пример должен показать?
I>Хилый вывод типа и все вытекающие проблемы.

Какой же у f должен быть тип?
Re[11]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.01.14 21:21
Оценка: -1
Здравствуйте, alexzz, Вы писали:

I>>>>
I>>>>var f = (int x) => x * 2;
I>>>>

AVK>>>И что этот пример должен показать?
I>>Хилый вывод типа и все вытекающие проблемы.

A>Какой же у f должен быть тип?


int x = ...;

var r = x*2;


Какой будет тип у r? Почему функция должна возвращать какой то другой тип ?
Re[12]: C# for Systems Programming
От: alexzz  
Дата: 09.01.14 22:33
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>>>>>
I>>>>>var f = (int x) => x * 2;
I>>>>>

AVK>>>>И что этот пример должен показать?
I>>>Хилый вывод типа и все вытекающие проблемы.

A>>Какой же у f должен быть тип?


I>
I>int x = ...;
I>var r = x*2;
I>


I>Какой будет тип у r? Почему функция должна возвращать какой то другой тип ?


То что тип аргумента int и тип результата int — это понятно, компилятор это знает. Но какой тип должен быть у f?
Re[13]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.01.14 23:10
Оценка: 5 (1) -1
Здравствуйте, alexzz, Вы писали:

I>>
I>>int x = ...;
I>>var r = x*2;
I>>


I>>Какой будет тип у r? Почему функция должна возвращать какой то другой тип ?


A>То что тип аргумента int и тип результата int — это понятно, компилятор это знает. Но какой тип должен быть у f?


Func<> разумеется. Мулька в том, что C# не умеет вот такой тип Func<void>, вместо этого есть Action, что совершенно идиотская идея и причина в ограничениях CLR. Теоретически, можно на уровне языка устранить эту разницу, но в C# этого не стали делать, ибо основная идея C# это прозрачность и принцип наименьшего удивления.
Дальше вот такая хрень — Func<int, int> нельзя присвоить Action, итого — получается отстой. Все методы приходится дублировать для Action или требовать писать необязательный return.

Итого — одна хрень в наличии. Вторая хрень:

Func<M<X>,M<Y>> Lift<M, X, Y>(Func<X,Y> f) where ля ля ля {

    return (mx) => mx.Bind(x => M.Return(f(x)));
}


Вот такое надо писать для каждого типа M + расставлять подсказки компилятору

Все вместе это означает следующее — каждый раз, когда возникат необходимость в высокоуровневых средтсвах, надо ждать модификации компилятора, это было c
1 yield
2 async/await
3 Nullable
и тд
Re[14]: C# for Systems Programming
От: alexzz  
Дата: 10.01.14 00:38
Оценка:
Здравствуйте, Ikemefula, Вы писали:

A>>То что тип аргумента int и тип результата int — это понятно, компилятор это знает. Но какой тип должен быть у f?

I>Func<> разумеется.

#1
Вопрос на засыпку: какой в таком случае должен быть тип у f, если
var f = (int x1, int x2, ... int x20) => x1 + x2 + ... + x20;

#2
System.Func<T, TResult> ― это просто тип делегата. Он ничем не лучше любого другого типа делегата с той же сигнатурой, например:
delegate TResult Func<T, TResult>(T arg);
delegate TResult МамаМылаРаму<T, TResult>(T arg);

Func<int, int> f1 = x => x * 2;
МамаМылаРаму<int, int> f2 = x => x * 2;
// типы разные

I>Мулька в том, что C# не умеет вот такой тип Func<void>, вместо этого есть Action, что совершенно идиотская идея и причина в ограничениях CLR. Теоретически, можно на уровне языка устранить эту разницу, но в C# этого не стали делать, ибо основная идея C# это прозрачность и принцип наименьшего удивления.

#3
Не знаю ни про какие ограничения CLR. Хочешь тип делегата без параметров и возвращаемого значения и чтобы назывался Func?
delegate void Func();

Func f = Console.WriteLine;

I>Дальше вот такая хрень — Func<int, int> нельзя присвоить Action, итого — получается отстой. Все методы приходится дублировать для Action или требовать писать необязательный return.

Так между ними ничего общего. Как их можно присваивать?
delegate void AAA();

AAA a = Console.WriteLine;
a = x => x * 2; // это должно быть разрешено?
// как потом вызывать?
a(); // так
a(1); // или так?


#4
var f = (int x) => x * 2;

Почему лямбда должна стать именно делегатом? Она с таким же успехом может стать выражением:
Expression<Func<int, int>> f = (int x) => x * 2;
Re[15]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.01.14 02:39
Оценка:
Здравствуйте, alexzz, Вы писали:

A>#1

A>Вопрос на засыпку: какой в таком случае должен быть тип у f, если
A>
A>var f = (int x1, int x2, ... int x20) => x1 + x2 + ... + x20;
A>


Аналогичные рассуждения, выводится чз Func и x1 + x2 + ... + x20

A>#2

A>System.Func<T, TResult> ― это просто тип делегата. Он ничем не лучше любого другого типа делегата с той же сигнатурой, например:
A>

А в Киеве дядька.

A>#3
A>Не знаю ни про какие ограничения CLR. 

Это, похоже и есть основная причина. Щас это устраним - void на самом деле никакой не тип, а прямое указание, какой код будет сгенерирован, то есть, для void нет никакого типа или аналога типа.

Отсюда ясно, что не-тип нельзя использовать как тип.

>Хочешь тип делегата без параметров и возвращаемого значения и чтобы назывался Func?

Я хочу
1. параметризовать Func и любой дженерик с помощью void
2. объявить переменную с типом void

Допустим C# убог - сделай это в IL, там нет ограничений раз ты про них не знаешь  :))) 

Как только у тебя будет это готово, приходи  :)) дам тебе 100(сто) американских долларов одной купюрой. :))) 


I>>Дальше вот такая хрень - Func<int, int> нельзя присвоить Action, итого - получается отстой. Все методы приходится дублировать для Action или требовать писать необязательный return.

A>Так между ними ничего общего. Как их можно присваивать?

Очень легко - если void сделать типом, то внезапно окажется, что можно генерировать одинаковый код и можно Func<int, int> использовать вместо Func<int, void>

А отсюда ясно, что костыль Action<T> не нужен или его можно сделать совместимым с Func<T, void> по присваиванию

A>[c#]
A>delegate void AAA();

A>AAA a = Console.WriteLine;
A>a = x => x * 2; // это должно быть разрешено?
A>// как потом вызывать?
A>a(); // так
A>a(1); // или так?
A>


Ни то ни другое.
x => x * 2 это, если x будет int, Func<int, int>, соответсвенно его можно было бы использовать вместо Action<int> или Func<int, void>

A>#4

A>
A>var f = (int x) => x * 2;
A>

A>Почему лямбда должна стать именно делегатом? Она с таким же успехом может стать выражением:

Мы говорим не о том, кто кому должен, а про варианты дизайна языка. Это понятно ? Отсюда правильно использовать сослагательное наклонение.

Использование синтаксиса лямбды для экспрешнов было плохой идеей. Первое это функция, второе это цитирование.
Лямбда-делегат и лямбда-экспрешн это две большие разницы — это пол-беды. Всё гораздо хуже

вот это компилируется
Func<int> a = () => while(true) return 1;


а вот это — нет
Expression<Func<int>> a = () => while(true) return 1;


Даже в текущем дизайне, по принципу меньшего удивления стоило бы сделать лямбду именно функцией, ибо экспрешны не поддерживают полный синтаксис в лямбдах.
Т.е. экспрешны это такой костылёк. Для чего его ввели — для того, что бы умельцы не написали сотню ни с чем не совместимых Linq- и прочих провайдеров.
Re[16]: C# for Systems Programming
От: alexzz  
Дата: 10.01.14 09:33
Оценка:
Здравствуйте, Ikemefula, Вы писали:

A>>#1

A>>Вопрос на засыпку: какой в таком случае должен быть тип у f, если
A>>
A>>var f = (int x1, int x2, ... int x20) => x1 + x2 + ... + x20;
A>>

I>Аналогичные рассуждения, выводится чз Func и x1 + x2 + ... + x20

Такого делегата Func<...> с 21 параметром не существует.

A>>#2

A>>System.Func<T, TResult> ― это просто тип делегата. Он ничем не лучше любого другого типа делегата с той же сигнатурой, например:
A>>[c#]
I>А в Киеве дядька.

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

I>Мы говорим не о том, кто кому должен, а про варианты дизайна языка. Это понятно ? Отсюда правильно использовать сослагательное наклонение.

Теперь понятно. Я думал, ты серьёзно, а оказалось, фантазируешь.
Re[17]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.01.14 09:51
Оценка:
Здравствуйте, alexzz, Вы писали:

I>>Аналогичные рассуждения, выводится чз Func и x1 + x2 + ... + x20


A>Такого делегата Func<...> с 21 параметром не существует.


Это принципиальная проблема ?

A>>>#2

A>>>System.Func<T, TResult> ― это просто тип делегата. Он ничем не лучше любого другого типа делегата с той же сигнатурой, например:
A>>>[c#]
I>>А в Киеве дядька.

A>Ты почему-то привязался именно к группе типов делегатов System.Func. Но Func — это же не какой-то особенный тип делегатов. Почему компилятор должен приводить лямдбу именно одному из типов System.Func, а не к любому другому с подходящей сигнатурой?


Именно так.

I>>Мы говорим не о том, кто кому должен, а про варианты дизайна языка. Это понятно ? Отсюда правильно использовать сослагательное наклонение.

A>Теперь понятно. Я думал, ты серьёзно, а оказалось, фантазируешь.

Ты не отвлекайся, торопись всё разоблачить и опровергнуть
Re[18]: C# for Systems Programming
От: alexzz  
Дата: 10.01.14 12:00
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Аналогичные рассуждения, выводится чз Func и x1 + x2 + ... + x20

A>>Такого делегата Func<...> с 21 параметром не существует.
I>Это принципиальная проблема ?

Три:
1. Компилятор не будет угадывать тип делегата, к которому нужно привести лямбду. Может и иногда делает, но в данном случае не будет.
2. Если бы стал, такого типа делегата всё равно нет.
3. Если бы компилятор придумал новый подходящий тип делегата, ты бы мог пользоваться полученным экземпляром только локально, так же как экземплярами анонимных типов.

Пока ты кардинально не перепишешь спецификацию в нескольких местах и не напишешь свой компилятор, это принципиальные проблемы.

A>>Ты почему-то привязался именно к группе типов делегатов System.Func. Но Func — это же не какой-то особенный тип делегатов. Почему компилятор должен приводить лямдбу именно одному из типов System.Func, а не к любому другому с подходящей сигнатурой?

I>Именно так.

Что именно так? Я тупой, не понимаю ответа.

I>>>Мы говорим не о том, кто кому должен, а про варианты дизайна языка. Это понятно ? Отсюда правильно использовать сослагательное наклонение.

A>>Теперь понятно. Я думал, ты серьёзно, а оказалось, фантазируешь.
I>Ты не отвлекайся, торопись всё разоблачить и опровергнуть

Ты хочешь, чтобы компилятор или рантайм сделали что-то, что они делать не будут. Хоть прыгай с бубном, хоть свечку ставь — не будут. Что мне тут опровергать или разоблачать?
Re[19]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.01.14 12:16
Оценка: +1
Здравствуйте, alexzz, Вы писали:

A>Три:

A>1. Компилятор не будет угадывать тип делегата, к которому нужно привести лямбду. Может и иногда делает, но в данном случае не будет.

Спасибо, капитан — развитие С# уже давно пошло по другому пути

A>2. Если бы стал, такого типа делегата всё равно нет.


Надо полагать "если бы", то были бы принципиальные сложности ввести такой тип предопределенным или генеренным компилером ?

Обосновать можешь ?

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


Если делегаты совместимы по присваиванию, как я показал, то нет никаких проблем

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

A>Пока ты кардинально не перепишешь спецификацию в нескольких местах и не напишешь свой компилятор, это принципиальные проблемы.


Ужос ! В других язык сделали,а в C# — "нивазможна, патамушта это нивазможна ваапще"

A>>>Ты почему-то привязался именно к группе типов делегатов System.Func. Но Func — это же не какой-то особенный тип делегатов. Почему компилятор должен приводить лямдбу именно одному из типов System.Func, а не к любому другому с подходящей сигнатурой?

I>>Именно так.

A>Что именно так? Я тупой, не понимаю ответа.


Если делегаты совместимы по присваиванию, то не ясно, зачем тебе какой то другой тип

A>>>Теперь понятно. Я думал, ты серьёзно, а оказалось, фантазируешь.

I>>Ты не отвлекайся, торопись всё разоблачить и опровергнуть

A>Ты хочешь, чтобы компилятор или рантайм сделали что-то, что они делать не будут. Хоть прыгай с бубном, хоть свечку ставь — не будут. Что мне тут опровергать или разоблачать?


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

Разговор начался с того, что я показал, какая из фич в C# сильно ограничивает возможности разработчика.

Неразрешимых проблем нет, но кодить в сложных случаях придется намного больше, при чем местами получишь комбинаторный взрыв и никуда от этого не денешься.
Re[20]: C# for Systems Programming
От: alexzz  
Дата: 10.01.14 13:29
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Если делегаты совместимы по присваиванию, как я показал, то нет никаких проблем

Но делегаты разных типов не совместимы по присваиванию, даже если сигнатуры одинаковые.

I>Если делегаты совместимы по присваиванию, то не ясно, зачем тебе какой то другой тип

Делегаты разных типов не совместимы по присваиванию.

A>>Ты хочешь, чтобы компилятор или рантайм сделали что-то, что они делать не будут. Хоть прыгай с бубном, хоть свечку ставь — не будут. Что мне тут опровергать или разоблачать?

I>Чего они не будут делать это я сам тебе рассказал. Ты поначалу говорил что никаких проблем-ограничений нет.

Это был кто-то другой.

I>Разговор начался с того, что я показал, какая из фич в C# сильно ограничивает возможности разработчика.


Наш разговор начался, когда ты сказал, что у c# хилый вывод типов, а я спросил, какой же тип должен вывести компилятор для f
var f = (int x) => x * 2;
Re[21]: C# for Systems Programming
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.01.14 14:54
Оценка:
Здравствуйте, alexzz, Вы писали:

I>>Если делегаты совместимы по присваиванию, как я показал, то нет никаких проблем

A>Но делегаты разных типов не совместимы по присваиванию, даже если сигнатуры одинаковые.

Я в курсе, принципиальных ограничений для этого нет, это искусственное ограничение "мы решили вот так"

I>>Если делегаты совместимы по присваиванию, то не ясно, зачем тебе какой то другой тип

A>Делегаты разных типов не совместимы по присваиванию.

Спасибо, капитан, Func<string> нельзя присвоить в Func<int>. А если ты про Action и Func<int>, то проблема в CLR. Все остальные случаи это искусственные ограничения.

A>>>Ты хочешь, чтобы компилятор или рантайм сделали что-то, что они делать не будут. Хоть прыгай с бубном, хоть свечку ставь — не будут. Что мне тут опровергать или разоблачать?

I>>Чего они не будут делать это я сам тебе рассказал. Ты поначалу говорил что никаких проблем-ограничений нет.

A>Это был кто-то другой.


Значит ктото с твоего аккаунта пишет

I>>Разговор начался с того, что я показал, какая из фич в C# сильно ограничивает возможности разработчика.


A>Наш разговор начался, когда ты сказал, что у c# хилый вывод типов, а я спросил, какой же тип должен вывести компилятор для f

A>
A>var f = (int x) => x * 2;
A>


Именно так, это и есть хилый вывод типа.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.