Скользкая тема. А что если по одному IP стоит роутер, который раздает на квартиру/дом? Один юзер отключил блок, другой увидел контент и с чистой совестью заявляет, что он никуда не звонил и никакую блокировку не снимал, платите мне, ребята, за показ запрещенного контента…
Я помню, у меня был несложный, но монструозный проект, построенный по всем паттернам ООП (ага, пек хлеб), в функциональном языке он получался намного короче. Но когда мне попозже понадобилось сделать что-то более приближенное к практике, то иммутабельность переменных и пр. заставляли меня писать такие костыли, что все эти фортраны с отутствием поддержки IEEE754 и записями а-ля «X=(X-X)+X» нервно курят в сторонке. А вот на шарпе с анонимками это было легко и приятно.
Я сам с математикой на «ты» и функциональные языки нравятся мне своей элегантнностю и лаконичностью, но в терминах ООП мне мыслить все же проще. А тот же шарп имеет практически те же функциональные возможности, что и какой-нибудь хаскель. Даже монады прикрутили :)
Во всех этих ваших шарпах спокойно существуют все эти функции первого класса. Так что если бы это было возможно, это было бы реализовано. Умение фукнциональщиков видеть функциональщину везде неудивительно, равно как и умение ООПщиков видеть одни только объекты.
Очень сложно, хотя и интересно. СМО, Матанализ, Музыка, еще и Статдинамику приплели (буквально на днях была лекция про спектральный анализ с использованием оконной функции, без которой половину бы не понял). Не знаю, можно ли написать проще, но проделана очень большая работа. Спасибо за статью.
Пришел, посидел. Что сказать, большинство интересных фич только для 8.1. Господи, функция определения значения функции без введения временной переменной доступна только в 8.1. Что за бред?
Но организация на уровне, кофе/обед/персонал очень вежливый, чисто. Футболки, опять же (правда размер пока не смотрел — сразу на работу поехал). Но минусы тоже есть: сначала не компилировалось у человека приложение (потом стало ясно, что старый SearchContract не дружит с SearchBox), затем мониторы на 20 минут отключились, это сильно сдвинуло все.
Последняя презентация с XAML (зеленый зал, 3 презентация) была уже намного интереснее и без косяков. Но на мой животрепещущий вопрос насчет введения простейших операций вместо написания конвертеров на каждый чих ответ был «Да нафиг они нужны»…
Статья неплохая, но некоторые места откровенно косячные. Например такие:
«Async методы могут возвращать void, Task или Task. Void применим только для обработчиков событий. Если ваш метод возвращает значение используйте Task, иначе — просто Task. Если вы используйте Task просто возвращайте значение как из обычного метода, компилятор сделает остальное.»
Все же в рускоязычной литературе managed обычно переводится как «Управляемый». На примере того же .Net — managed language — управляемый язык, managed code — управляемый код. По аналогии unmanaged — неуправляемый.
«В своём предыдущем посте я говорил о конфликте между IQueryable и LSP, но даже ограничивая дискуссию рамками LINQ to Objects, выясняется, что LINQ содержит множество встроенных нарушений LSP.
Вспомним смысл LSP: вы должны иметь возможность передать любую реализацию интерфейса клиенту без изменения корректности системы. В то время как «корректность» является специфичной для приложения, наименьшим общим кратным должно являться то, что если метод работает корректно для одной реализации интерфейса, то он не должен выбрасывать исключения для другой. Впрочем, рассмотрим две реализации IEnumerable:»
С тем же успехом мы можем написать такую структуру:
class A {}
class B: A
{
public B()
{
throw new Exception()
}
}
и говорить, что видите ли наследование нарушает LSP. Мы же не можем подставить B вместо A!
А может дело не в нем, а в том, как мы используем? LINQ ничего не нарушает, если вы хотите сделать бесконечный массив, он попробует его для вас сделать и выпадет и исключением. Как говорится «Машина дура, что ей скажешь, то она и сделает». А если я буду писать код и не буду уверен, что он в точности будет исполняться, то…
Да, давайте добавим еще один ряд клавиш специально для русских + поддержку со стороны софта всего этого безобразия… А заодно нужно (нужно же, чтобы все было честно?) также клавиатуру со всеми китайскими иероглифами и тумблеры переключения между различными диалектами, а то что получается, им, бедняжкам, из 80тысяч оставили какую-то ничтожную мелочь…
Ну и хорошо, что подрезали. Совместимость всегда означает тащит старые костыли, а хотя бы в этой( habrahabr.ru/post/145932/ ) статье рассказывается, что они ввели и нормальные структуры, и настоящие дженерики, и пр…
(Бесит невозможность использовать теги форматирования...)
Я сам с математикой на «ты» и функциональные языки нравятся мне своей элегантнностю и лаконичностью, но в терминах ООП мне мыслить все же проще. А тот же шарп имеет практически те же функциональные возможности, что и какой-нибудь хаскель. Даже монады прикрутили :)
Но организация на уровне, кофе/обед/персонал очень вежливый, чисто. Футболки, опять же (правда размер пока не смотрел — сразу на работу поехал). Но минусы тоже есть: сначала не компилировалось у человека приложение (потом стало ясно, что старый SearchContract не дружит с SearchBox), затем мониторы на 20 минут отключились, это сильно сдвинуло все.
Последняя презентация с XAML (зеленый зал, 3 презентация) была уже намного интереснее и без косяков. Но на мой животрепещущий вопрос насчет введения простейших операций вместо написания конвертеров на каждый чих ответ был «Да нафиг они нужны»…
Но имхо переводить вообще не стоит, фразу из трех предложение освоит даже гугл, а тут дураков вроде не держат
«Async методы могут возвращать void, Task или Task. Void применим только для обработчиков событий. Если ваш метод возвращает значение используйте Task, иначе — просто Task. Если вы используйте Task просто возвращайте значение как из обычного метода, компилятор сделает остальное.»
В целом твердая «4», думаю.
habrahabr.ru/post/191636/
Все же в рускоязычной литературе managed обычно переводится как «Управляемый». На примере того же .Net — managed language — управляемый язык, managed code — управляемый код. По аналогии unmanaged — неуправляемый.
Вспомним смысл LSP: вы должны иметь возможность передать любую реализацию интерфейса клиенту без изменения корректности системы. В то время как «корректность» является специфичной для приложения, наименьшим общим кратным должно являться то, что если метод работает корректно для одной реализации интерфейса, то он не должен выбрасывать исключения для другой. Впрочем, рассмотрим две реализации IEnumerable:»
С тем же успехом мы можем написать такую структуру:
class A {}
class B: A
{
public B()
{
throw new Exception()
}
}
и говорить, что видите ли наследование нарушает LSP. Мы же не можем подставить B вместо A!
А может дело не в нем, а в том, как мы используем? LINQ ничего не нарушает, если вы хотите сделать бесконечный массив, он попробует его для вас сделать и выпадет и исключением. Как говорится «Машина дура, что ей скажешь, то она и сделает». А если я буду писать код и не буду уверен, что он в точности будет исполняться, то…
int GetRandomNumber()
{
return 4; // Chosen by a fair dice roll
// Guaranteed to be a random
}
(Бесит невозможность использовать теги форматирования...)