Pull to refresh

Comments 72

Меня это постоянно смущает. Несколько примеров уже видел о том как можно удобно использовать тип dynamic. (Тут уже предлагали с элементами Dictionary работать как со свойствами) Но везде есть приписка «И это далеко не лучшее решение в данном случае».
Да, dynamic делает код намного более читабельным, облегчает разработку, но производительность… Стоит ли это того?
Авторы в первую очередь разрабатывали dynamic для интеропа и рефлексии, об этом упоминаеться в статье. Эта иллюстрация — очередной простой пример, который не может полностью показать мощь динамика. Для работы с XML существует множество более удобных инструментов, но, представте себе, что завтра вам придется работать с другим иерархическим форматом, для которого не существует XDocument или LINQ. Вот тогда этот исскуственный пример поможет решить вполне реальную задачу.
На мой взгляд, современное программирование вообще не парится о производительности…
в 90% случаев меня более всего интересует именно: «делает код намного более читабельным, облегчает разработку»
Он уже вышел? А то после питона немного не по-себе от строгой типизации…
Уже есть Visual Studio 2010 Beta 2, на которой вполне можно писать. Релиз должен состоятся в марте следующего года.
Напомню, кстати, что благодаря DLR в .Net 4.0 будут полноценные динамические языки — IronPython и IronRuby.
Про вижуал студию новую читал, не знал что там будет новая версия шарпа. Спасибо!
на март уже не рассчитывайте:)
май, я думаю
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
C# всё равно типизирован, никуда вам от этого не убежать :)
UFO landed and left these words here
Динамик — это просто объект, тип которого становится известным только на этапе выполнения. То есть к вам приходит экземпляр определенного класса, и вы можете попробовать обратится к любому его члену. Если такового не существует — будет выброшено исключение. Логично предположить, что если экземпляр уже существует, то вряд ли динамик поможет вам вызывать конструкторы. Вот отличная ссылка, как можно динамически создавать дженерик объекты: geekswithblogs.net/marcel/archive/2007/03/24/109722.aspx
Возможно, я не совсем правильно понял ваш вопрос?
UFO landed and left these words here
Если вы об этом:
var list = new List<dynamic>();
list.Add(1);
list.Add("Hello!");

Да можно, самому интересно стало, проверил — скомпилилось.
Хотел спросить, чем List<object> плох в данном случае?
Может тем, что лист динамиков больше похож на кортеж (tuple) из ФП?
Тут надо понимать, что когда в объявляете переменную класса dynamic, вы фактически объявляете object.
То есть если вы вызовете: list.GetType().FullName, то тип переменной list будет List<object>. Просто когда вы явно объявляете List<dynamic>, то к элементам списка можно применить все прелести dynamic`а. Вот и всё.
самое интересное, что то, что в VB и VB.NET ругали почем свет стоит — late binding, в C# 4.0 преподносится, как супер крутая фича.
Но язык ведь остался статически типизированным. Динамик — фича, которую можно использовать только когда она действительно нужна, в остальном используя преимущества статической типизации. Это альтернатива, а альтернатива — всегда хорошо.
в vb.net с первой его версии тоже был выбор =)
объявляешь переменную как Object, работает late binding, а объявляешь как конкретный тип — используется статическая типизация.
Откровенно говоря, я на бейсике никогда не писал, так что не знал об этом. И все же возражу: во-первых, в C# late binding имеет более явную форму, а во-вторых добавлена возможность переопределять его поведение с помощью DynamicObject — так, как показано в статье. В VB.Net так можно?
Честно говоря, насчет переопределения не уверен, что настолько же просто это можно было сделать. В Шарпе отлично это реализовали, согласен на 100%.

Безусловно, dynamic — это шаг вперед. Другое дело, что почему-то никто не признает, что MS многие клевые фишки сначала на Бейсике опробует, а потом уже в более «взрослые» языки вставляет. Многие ли сейчас помнят, что такое QLB (Quick Library, которые использовались в Quick Basic 4.5 и Microsoft Basic) и как оно связано с DLL =)
Я не верю, что вы считаете, что нужно опробовать фичи во взрослых языках, а потом вставлять их в бейсик. :) Просто в шарпе все эти фичи реализовывают на более высоком и серьезном уровне, когда понимают, что их реально не хватает в некоторых ситуациях.
А еще они иногда клевые фишки на C# пробуют, а потом уже в VB.Net вставляют…
МС параллельно работает над языками C# и VB.NET и в планах у них как раз унификация возможностей языков. Т.е. код будет одинаково работать что в шарпе, что в бейсике. Как тамошние дядьки говорят — выбор разработчика будет между look and feel шарпа и бейсика.
vb.net так можно
в Vs2010 они стали практически равными по фичам
Я имел ввиду старый VB.Net. То что в четвертой версии фреймворка они стали равноправными — это только плюс, ИМХО.
UFO landed and left these words here
UFO landed and left these words here
компилируется.
vb 2010 поддерживает новые фичи DLR ровно в той же степени что и C#

Мало того еще в vb6 был такой тип, как Variant, который очень похож на новый dynamic. В vb.net его правда убили, но вот теперь он снова возродился.

Вообще, смешно читать все эти нападки на vb

к релизу 2010 комманды, делающие vb и c# были объеденены в одну, соотвественно языки полностью обменялись недостающими фичами. например c# получил option parameters, а vb — multiline lambdas.

Далее все фичи будут добавлятся в языки одновременно.

Так что предпочтения могут быть только на уровне вкуса и привычки.
Чисто из спортивного интереса: в чем отличие между dynamic и late binding?
Даже исключение, которое выбрасывается в случае ошибки, очень похоже ;-)
Компилируется и в VB Classic, и в VB.Net любой версии
UFO landed and left these words here
Баллмер кричал: «Developers! Developers! Developers!», а не «Users! Users! Users!» ))))))))
Тормозов она добавляет только тогда, когда вместо нее можно воспользоватся статической типизацией — а она дает программисту возможность использовать фичи вроде IntelliSense и находить ошибки во время компиляции. Удобство динамика проявляется тогда, когда вместо простого вызова метода или свойства нужно написать кучу кода с помощью рефлексии или какого-нибуть P/Invoke, тогда как динамик просто автоматически згенерирует ту же кучу кода.
UFO landed and left these words here
С++ не адекватен большинству бизнес-задач. Разработка просто медленнее и дороже. Я и сам люблю С++, но вести реальную работу на нём мне финансово невыгодно :)

По вашему, хорошие программисты редко сядятся за бизнес-приложения?) Хе-хе.
UFO landed and left these words here
Это бессмысленная дискуссия без указания границ применения. Для моих работ — это так. Я хорошо понимаю и чуствую «фичи» C# и они меня ни разу не тормозят, относительно С++, а наоборот. Если у вас — по другому, значит либо задачи весьма специфические, либо нет нужного понимания C#.
UFO landed and left these words here
что такое "алгоритмические программы"?
UFO landed and left these words here
UFO landed and left these words here
Html — это язык разметки, а php — нормальный язык программирования, на нём можно реализовать алгоритмы любой сложности.
А вы бы не могли уточнить какая такая тонкая работа с памятью нужна на web сервере?
UFO landed and left these words here
А я встречал, причем на вполне реальном проекте. Тогда все пришлось разруливать с помощью рефлексии. Попытаюсь в близжайшем будущем проилюстрировать тот пример в статье для хабра — судя по всему тема интересна читателям.
А что касается плохих/хороших программистов, то, мне кажется, вы слишком обобщаете — там, где плохой программист на шарпе добъется тормозов, плохой плюсер будет иметь кучу проблем с утечками памяти или крешами программы. А вот хорошие программисты есть там и там, просто нужно понимать, когда какой инструмент и когда нужно использовать. Если производительность критична в определенном месте, это место всегда можно переписать с помощью С++ или unsafe mode. Если вы пишете софт, который должен работать в режиме реального времени, наверное шарп вам не подойдет. Ежели ваша цель — создать большую корпоративную web-систему электронного документооборота, то компании-заказчику дешевле поставить два дополнительных сервера, чем оплачивать дополнительных пол года разработки этой системы на С++.
UFO landed and left these words here
Скорее, хороший программист «сядет» за тот язык, который более подходит задаче.
За C# и Delphi (забыли упомянуть еще php для веба) садятся потому что порог вхождения маленький и можно «программировать» в monkey-style. С++ не располагает к этому. Если напишут среду + framework, которые будут располагать к такому стилю на c++, добавим пиар, то будут и так писать, будут медленные и глючные программы на с++.
Дело в людях, а не в языках. Нет лучших или худших языков в принципе.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Кто-то из умных дядек говорил, что языки должны быть прежде всего удобны. И это понятно, ведь производительность систем всё ещё растёт по Муру и ПО едва поспевает за мощностями железа. Языки так быстро не развиваются, как развивается вычислительная мощность аппаратных систем. Так что если где-то будет задействован dynamic вместо пачки классов-обёрток — никому от этого очень плохо не будет.
Языки так быстро не развиваются, как развивается вычислительная мощность аппаратных систем.

Вроде, развивать вычислительную мощность уже некуда дальше (пока), а многопоточность не для всех задач подходит.
По крайней мере для серверного софта, можно наращивать количество компов.
Не все можно распараллелить. Попробуйте распараллелить подсчет числа Фибоначи.
Я про реальные задачи. Все что я сейчас пишу можно распаралелить.
Я тоже про реальные и к сожалению не все удается вынести в отдельный поток даже, я уже не говорю об отдельной машине. Например, обработать видео с помощью ffmpeg.
Давайте я проиллюстрирую мысль.

а) У меня есть 1000 видео клипов. Есть ферма из 100 машин. Каждая из этих 100 мишин будет обрабатывать по 10ть клипов.

б) У меня есть 10 видео клипов. Есть ферма из 100 машин. Я хочу чтобы 10 машин обрабатывали одно видео. Тут я не готов что-то сказать, так как у меня отсутвует опыт с ffmpeg. Быстрее всего можно покрамсать на кусочки (там же есть точки синхронизации?). Может быть что-то еще. Технически задача выполнима.
Проблема в том когда есть один БОЛЬШОЙ клип.
Если задачу можно разбить на относительно независимые куски, то ее можно распаралелить. Но далеко не все так можно разбить. Примерно это я пытаюсь донести.
Ролик начался с того что вывод типов обозвали «динамической типизпцией». Так держать.
Согласен. Но если в толика заменить слова «3.0» на «4.0» и «var» на «dynamic», то ролик опять актуален
Only those users with full accounts are able to leave comments. Log in, please.