Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 72
Меня это постоянно смущает. Несколько примеров уже видел о том как можно удобно использовать тип dynamic. (Тут уже предлагали с элементами Dictionary работать как со свойствами) Но везде есть приписка «И это далеко не лучшее решение в данном случае».
Да, dynamic делает код намного более читабельным, облегчает разработку, но производительность… Стоит ли это того?
Да, dynamic делает код намного более читабельным, облегчает разработку, но производительность… Стоит ли это того?
Авторы в первую очередь разрабатывали dynamic для интеропа и рефлексии, об этом упоминаеться в статье. Эта иллюстрация — очередной простой пример, который не может полностью показать мощь динамика. Для работы с XML существует множество более удобных инструментов, но, представте себе, что завтра вам придется работать с другим иерархическим форматом, для которого не существует XDocument или LINQ. Вот тогда этот исскуственный пример поможет решить вполне реальную задачу.
На мой взгляд, современное программирование вообще не парится о производительности…
в 90% случаев меня более всего интересует именно: «делает код намного более читабельным, облегчает разработку»
Он уже вышел? А то после питона немного не по-себе от строгой типизации…
Уже есть Visual Studio 2010 Beta 2, на которой вполне можно писать. Релиз должен состоятся в марте следующего года.
Напомню, кстати, что благодаря DLR в .Net 4.0 будут полноценные динамические языки — IronPython и IronRuby.
Напомню, кстати, что благодаря DLR в .Net 4.0 будут полноценные динамические языки — IronPython и IronRuby.
Про вижуал студию новую читал, не знал что там будет новая версия шарпа. Спасибо!
на март уже не рассчитывайте:)
май, я думаю
май, я думаю
откуда сведения?
weblogs.asp.net/scottgu/archive/2009/12/17/visual-studio-2010-and-net-4-0-update.aspx
если добавить к 22 марта few weeks, я думаю будет как раз май:)
если добавить к 22 марта few weeks, я думаю будет как раз май:)
C# всё равно типизирован, никуда вам от этого не убежать :)
Динамик — это просто объект, тип которого становится известным только на этапе выполнения. То есть к вам приходит экземпляр определенного класса, и вы можете попробовать обратится к любому его члену. Если такового не существует — будет выброшено исключение. Логично предположить, что если экземпляр уже существует, то вряд ли динамик поможет вам вызывать конструкторы. Вот отличная ссылка, как можно динамически создавать дженерик объекты: geekswithblogs.net/marcel/archive/2007/03/24/109722.aspx
Возможно, я не совсем правильно понял ваш вопрос?
Возможно, я не совсем правильно понял ваш вопрос?
Если вы об этом:
var list = new List<dynamic>();
list.Add(1);
list.Add("Hello!");
И нормально отработало?
А в чем сермяжная правда? List
Хотел спросить, чем 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, а объявляешь как конкретный тип — используется статическая типизация.
объявляешь переменную как Object, работает late binding, а объявляешь как конкретный тип — используется статическая типизация.
Откровенно говоря, я на бейсике никогда не писал, так что не знал об этом. И все же возражу: во-первых, в C# late binding имеет более явную форму, а во-вторых добавлена возможность переопределять его поведение с помощью DynamicObject — так, как показано в статье. В VB.Net так можно?
Честно говоря, насчет переопределения не уверен, что настолько же просто это можно было сделать. В Шарпе отлично это реализовали, согласен на 100%.
Безусловно, dynamic — это шаг вперед. Другое дело, что почему-то никто не признает, что MS многие клевые фишки сначала на Бейсике опробует, а потом уже в более «взрослые» языки вставляет. Многие ли сейчас помнят, что такое QLB (Quick Library, которые использовались в Quick Basic 4.5 и Microsoft Basic) и как оно связано с DLL =)
Безусловно, dynamic — это шаг вперед. Другое дело, что почему-то никто не признает, что MS многие клевые фишки сначала на Бейсике опробует, а потом уже в более «взрослые» языки вставляет. Многие ли сейчас помнят, что такое QLB (Quick Library, которые использовались в Quick Basic 4.5 и Microsoft Basic) и как оно связано с DLL =)
Я не верю, что вы считаете, что нужно опробовать фичи во взрослых языках, а потом вставлять их в бейсик. :) Просто в шарпе все эти фичи реализовывают на более высоком и серьезном уровне, когда понимают, что их реально не хватает в некоторых ситуациях.
А еще они иногда клевые фишки на C# пробуют, а потом уже в VB.Net вставляют…
МС параллельно работает над языками C# и VB.NET и в планах у них как раз унификация возможностей языков. Т.е. код будет одинаково работать что в шарпе, что в бейсике. Как тамошние дядьки говорят — выбор разработчика будет между look and feel шарпа и бейсика.
vb.net так можно
в Vs2010 они стали практически равными по фичам
в Vs2010 они стали практически равными по фичам
компилируется.
vb 2010 поддерживает новые фичи DLR ровно в той же степени что и C#
Мало того еще в vb6 был такой тип, как Variant, который очень похож на новый dynamic. В vb.net его правда убили, но вот теперь он снова возродился.
Вообще, смешно читать все эти нападки на vb
к релизу 2010 комманды, делающие vb и c# были объеденены в одну, соотвественно языки полностью обменялись недостающими фичами. например c# получил option parameters, а vb — multiline lambdas.
Далее все фичи будут добавлятся в языки одновременно.
Так что предпочтения могут быть только на уровне вкуса и привычки.
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 любой версии
Баллмер кричал: «Developers! Developers! Developers!», а не «Users! Users! Users!» ))))))))
Тормозов она добавляет только тогда, когда вместо нее можно воспользоватся статической типизацией — а она дает программисту возможность использовать фичи вроде IntelliSense и находить ошибки во время компиляции. Удобство динамика проявляется тогда, когда вместо простого вызова метода или свойства нужно написать кучу кода с помощью рефлексии или какого-нибуть P/Invoke, тогда как динамик просто автоматически згенерирует ту же кучу кода.
С++ не адекватен большинству бизнес-задач. Разработка просто медленнее и дороже. Я и сам люблю С++, но вести реальную работу на нём мне финансово невыгодно :)
По вашему, хорошие программисты редко сядятся за бизнес-приложения?) Хе-хе.
По вашему, хорошие программисты редко сядятся за бизнес-приложения?) Хе-хе.
Это бессмысленная дискуссия без указания границ применения. Для моих работ — это так. Я хорошо понимаю и чуствую «фичи» C# и они меня ни разу не тормозят, относительно С++, а наоборот. Если у вас — по другому, значит либо задачи весьма специфические, либо нет нужного понимания C#.
А я встречал, причем на вполне реальном проекте. Тогда все пришлось разруливать с помощью рефлексии. Попытаюсь в близжайшем будущем проилюстрировать тот пример в статье для хабра — судя по всему тема интересна читателям.
А что касается плохих/хороших программистов, то, мне кажется, вы слишком обобщаете — там, где плохой программист на шарпе добъется тормозов, плохой плюсер будет иметь кучу проблем с утечками памяти или крешами программы. А вот хорошие программисты есть там и там, просто нужно понимать, когда какой инструмент и когда нужно использовать. Если производительность критична в определенном месте, это место всегда можно переписать с помощью С++ или unsafe mode. Если вы пишете софт, который должен работать в режиме реального времени, наверное шарп вам не подойдет. Ежели ваша цель — создать большую корпоративную web-систему электронного документооборота, то компании-заказчику дешевле поставить два дополнительных сервера, чем оплачивать дополнительных пол года разработки этой системы на С++.
А что касается плохих/хороших программистов, то, мне кажется, вы слишком обобщаете — там, где плохой программист на шарпе добъется тормозов, плохой плюсер будет иметь кучу проблем с утечками памяти или крешами программы. А вот хорошие программисты есть там и там, просто нужно понимать, когда какой инструмент и когда нужно использовать. Если производительность критична в определенном месте, это место всегда можно переписать с помощью С++ или unsafe mode. Если вы пишете софт, который должен работать в режиме реального времени, наверное шарп вам не подойдет. Ежели ваша цель — создать большую корпоративную web-систему электронного документооборота, то компании-заказчику дешевле поставить два дополнительных сервера, чем оплачивать дополнительных пол года разработки этой системы на С++.
Скорее, хороший программист «сядет» за тот язык, который более подходит задаче.
За C# и Delphi (забыли упомянуть еще php для веба) садятся потому что порог вхождения маленький и можно «программировать» в monkey-style. С++ не располагает к этому. Если напишут среду + framework, которые будут располагать к такому стилю на c++, добавим пиар, то будут и так писать, будут медленные и глючные программы на с++.
Дело в людях, а не в языках. Нет лучших или худших языков в принципе.
За C# и Delphi (забыли упомянуть еще php для веба) садятся потому что порог вхождения маленький и можно «программировать» в monkey-style. С++ не располагает к этому. Если напишут среду + framework, которые будут располагать к такому стилю на c++, добавим пиар, то будут и так писать, будут медленные и глючные программы на с++.
Дело в людях, а не в языках. Нет лучших или худших языков в принципе.
Кто-то из умных дядек говорил, что языки должны быть прежде всего удобны. И это понятно, ведь производительность систем всё ещё растёт по Муру и ПО едва поспевает за мощностями железа. Языки так быстро не развиваются, как развивается вычислительная мощность аппаратных систем. Так что если где-то будет задействован dynamic вместо пачки классов-обёрток — никому от этого очень плохо не будет.
Языки так быстро не развиваются, как развивается вычислительная мощность аппаратных систем.
Вроде, развивать вычислительную мощность уже некуда дальше (пока), а многопоточность не для всех задач подходит.
По крайней мере для серверного софта, можно наращивать количество компов.
Не все можно распараллелить. Попробуйте распараллелить подсчет числа Фибоначи.
Я про реальные задачи. Все что я сейчас пишу можно распаралелить.
Я тоже про реальные и к сожалению не все удается вынести в отдельный поток даже, я уже не говорю об отдельной машине. Например, обработать видео с помощью ffmpeg.
Давайте я проиллюстрирую мысль.
а) У меня есть 1000 видео клипов. Есть ферма из 100 машин. Каждая из этих 100 мишин будет обрабатывать по 10ть клипов.
б) У меня есть 10 видео клипов. Есть ферма из 100 машин. Я хочу чтобы 10 машин обрабатывали одно видео. Тут я не готов что-то сказать, так как у меня отсутвует опыт с ffmpeg. Быстрее всего можно покрамсать на кусочки (там же есть точки синхронизации?). Может быть что-то еще. Технически задача выполнима.
а) У меня есть 1000 видео клипов. Есть ферма из 100 машин. Каждая из этих 100 мишин будет обрабатывать по 10ть клипов.
б) У меня есть 10 видео клипов. Есть ферма из 100 машин. Я хочу чтобы 10 машин обрабатывали одно видео. Тут я не готов что-то сказать, так как у меня отсутвует опыт с ffmpeg. Быстрее всего можно покрамсать на кусочки (там же есть точки синхронизации?). Может быть что-то еще. Технически задача выполнима.
Сразу вспомнил ролик 2007-го года про C# (.Net) и Ruby railsenvy.com/2007/10/9/ruby-on-rails-vs-net-2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интересные вещи, которые можно делать с dynamic в .NET 4.0