Мексика — это из разряда ОБС, но от людей, которых я знаю лично. Насколько я понимаю, помимо федеральных законов, ряд штатов тоже что-то свое мутил. Скорее всего, Калифорния как обычно впереди планеты всей по градусу маразма? Там это имеет больший смысл, наверное.
Вообще-то, соответствующий закон был принят еще в 2007-м, и некоторые ограничения на лампы накаливания вступили в силу еще год назад. Но, во-первых, они ограничивают только лампы в диапазоне от 40 до 150 Вт (поэтому купить 300 Вт — не проблема, как ни странно), а во-вторых, ограничивать начали со 100-ваттных ламп. Вот их как раз и возят из Мексики.
В США уже возят из Мексики. Плюс, из европейского опыта, есть некоторые креативные способы обойти проблему.
Тут, однако, надо заметить одну вещь. Запретили не лампы накаливания вообще, а ввели определенный порог эффективности для них. Точнее, подняли — он был и раньше. С новым порогом ни одна лампа накаливания в продакшне его не проходит, но чисто теоретически можно попробовать чего-нибудь такое сынженерить.
Можно, но сам факт того, что это шаблон — будет виден пользователям API. Чтобы его спрятать (потому что в данном случае это хак — деталь реализации), нужно будет писать еще обертку сверху.
Можно, да не совсем. Как вы в коде выше будете проверять на ошибку в new MyClass? Можно, конечно, нагородить фабрики, но они-то все равно в итоге будут звать конструктор, у которого нет возможности вернуть ошибку вместо объекта.
Таки к динамической. В свое время я тоже намучался от того, что в метод мой передавали объект другого типа с теми же методами
Если семантика этих методов сохранена — то какая вам разница? Если нет, то на эти грабли можно точно так же наступить и при статической типизации, некорректно реализовав интерфейс.
Более того, то, что вы описали — это на самом деле даже не уникальная для динамической типизации вещь. Абсолютно такую же ситуацию можно получить в языке со статической но структурной типизацией — например, Objective Caml.
Так может говорить только тот, кто не пробовал. Изменения в рантайме — жуткая не тестируемая лапша. Жизнь на бомбе. Как вы правильно заметили это не используется.
Я, как раз, пробовал (мне по работе приходится писать на шарпе, плюсах и питоне, примерно в равных дозах). Тестируется это все вполне тривиально обычными юниттестами.
И я не говорил, что это не используется. Я говорил о том, что это зачастую используется не там, где надо. Но это как обычно — чем мощнее инструмент, тем больше желающих его использовать не по назначению.
Ну и да, в JS, Ruby и других просто нет тех же инструментов метапрограммирования. Элементарный пример: как вы на этих языках реалиуете что-то вроде scalikejdbc:
sql"select id from members where name = ${name}"
В смысле, чтобы name брался из текущей области видимости? Это, все-таки, достаточно специфичная возможность, которой действительно много где нет. Про Ruby не скажу — не специалист; в JS метапрограммирование убогое, но там и сам язык кривой; в Питоне это вполне можно реализовать через inspect.
Все компиляторы уже очень, очень давно забивают на inline (что явный, что неявный). Во-первых, потому, что все шаблоны неизбежно получаются авто-inline, что на практике далеко не всегда отражает желаемое, а во-вторых, потому что компилятор все равно почти всегда знает лучше. Бесполезнее inline — только register.
У вас претензии, кажется, не столько к динамической типизации, сколько к слабой — т.е. когда числа легким движением руки превращаются в строки, и наоборот. Откуда и идет все это мракобесие с == vs === в PHP и JS, и тому подобные вещи.
Для сравнения, в Питоне тип значения не меняется после создания, а автоприведения нет в мало-мальски сомнительных случаях. Т.е. сложить int и float еще можно, а вот int и str — уже никак, нужно явно конвертировать либо одно, либо другое.
Ну и метапрограммирование в динамических языках все-таки на порядки мощнее, чем в Scala, и даже в D. Потому что там метапрограммирование неизбежно ограничено временем компиляции, а в динамическом языке могут на лету определяться новые классы etc. Другой вопрос, насколько это реально полезно.
>> То, что на привычных технологиях пишется на автомате, на менее привычных требует некоторого времени на раздумия и планирование дальнейших шагов.
Это очевидно. Когда говорят о том, что «на X это делается быстрее, чем на Y», то имеется в виду — при прочих равных. Т.е. программисты с равным уровнем знания и опытом обеих технологий.
В этом случае мне очень сложно представить себе, как десктопный гуй на плюсах можно писать быстрее, чем на Питоне.
Кстати, WPF, например, тоже все свои виджеты рисует сам. Хотя, казалось бы, фреймворк только под винду и от самого MS. Просто это реально дает куда больше гибкости.
Да и производительность нативных Win32-виджетов хромает. Рэймонд Чен когда-то написал об этом пост — что, если вам нужно, например, несколько тысяч виджетов, и вы создаете под них несколько тысяч HWND, то это все будет тормозить by design — а если надо, чтобы не тормозило, то рисуйте все сами. Но нативные виндовые виджеты — те же кнопки и комбобоксы — требуют по оконному хэндлу на виджет, они не умеют по-другому.
DOS Shell же вышел на год позже Windows 2.0.
«A HEATBALL® is not a light bulb, but fits into the same socket!»
Тут, однако, надо заметить одну вещь. Запретили не лампы накаливания вообще, а ввели определенный порог эффективности для них. Точнее, подняли — он был и раньше. С новым порогом ни одна лампа накаливания в продакшне его не проходит, но чисто теоретически можно попробовать чего-нибудь такое сынженерить.
Вопрос в том, чтобы раскидать код выше по двум хедерам…
А написать так, как я сказал, можно практически где угодно. В C# все можно вообще в один файл засунуть:
new MyClass? Можно, конечно, нагородить фабрики, но они-то все равно в итоге будут звать конструктор, у которого нет возможности вернуть ошибку вместо объекта.Если семантика этих методов сохранена — то какая вам разница? Если нет, то на эти грабли можно точно так же наступить и при статической типизации, некорректно реализовав интерфейс.
Более того, то, что вы описали — это на самом деле даже не уникальная для динамической типизации вещь. Абсолютно такую же ситуацию можно получить в языке со статической но структурной типизацией — например, Objective Caml.
Я, как раз, пробовал (мне по работе приходится писать на шарпе, плюсах и питоне, примерно в равных дозах). Тестируется это все вполне тривиально обычными юниттестами.
И я не говорил, что это не используется. Я говорил о том, что это зачастую используется не там, где надо. Но это как обычно — чем мощнее инструмент, тем больше желающих его использовать не по назначению.
В смысле, чтобы name брался из текущей области видимости? Это, все-таки, достаточно специфичная возможность, которой действительно много где нет. Про Ruby не скажу — не специалист; в JS метапрограммирование убогое, но там и сам язык кривой; в Питоне это вполне можно реализовать через inspect.
Для сравнения, в Питоне тип значения не меняется после создания, а автоприведения нет в мало-мальски сомнительных случаях. Т.е. сложить int и float еще можно, а вот int и str — уже никак, нужно явно конвертировать либо одно, либо другое.
Ну и метапрограммирование в динамических языках все-таки на порядки мощнее, чем в Scala, и даже в D. Потому что там метапрограммирование неизбежно ограничено временем компиляции, а в динамическом языке могут на лету определяться новые классы etc. Другой вопрос, насколько это реально полезно.
Это очевидно. Когда говорят о том, что «на X это делается быстрее, чем на Y», то имеется в виду — при прочих равных. Т.е. программисты с равным уровнем знания и опытом обеих технологий.
В этом случае мне очень сложно представить себе, как десктопный гуй на плюсах можно писать быстрее, чем на Питоне.
Кстати, WPF, например, тоже все свои виджеты рисует сам. Хотя, казалось бы, фреймворк только под винду и от самого MS. Просто это реально дает куда больше гибкости.
Да и производительность нативных Win32-виджетов хромает. Рэймонд Чен когда-то написал об этом пост — что, если вам нужно, например, несколько тысяч виджетов, и вы создаете под них несколько тысяч HWND, то это все будет тормозить by design — а если надо, чтобы не тормозило, то рисуйте все сами. Но нативные виндовые виджеты — те же кнопки и комбобоксы — требуют по оконному хэндлу на виджет, они не умеют по-другому.