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?”

Ссылка

Краткое описание ключевых возможностей нового языка программирования Rust. Основной акцент делается на особенностях Rust, которых не хватает многим системным и сетевым разработчикам в других языках программирования.

Приятная новость: в Clang сделали полную поддержку C++1Y. Вообще, в компиляторе довольно много интересных изменений, начиная с поддержки дополнительных диагностических сообщений, заканчивая режимом совместимости с компилятором из Visual Studio. Подробности тут.

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

Начнем с рассмотрения принципа в книге Мейера "Объектно-ориентированное конструирование программных систем":

[q]Открыт-Закрыт

Любой метод модульной декомпозиции должен удовлетворять принципу семафора: Открыт-Закрыт:

Принцип Открыт-Закрыт

Модули должны иметь возможность быть как открытыми, так и закрытыми.

Противоречие является лишь кажущимся, поскольку термины соответствуют разным целевым установкам:
[list]

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

Модуль называют закрытым, если он доступен для использования другими модулями. Это означает...

http://adamralph.com/2013/12/06/ndc-diary-day-3/

//primary constructors - 
public class Point(int x, int y) { }
//read only auto-properties - 
public int X { get; } = x;
//static type using statements - 
using System.Math;
//property expressions - 
public double Distance => Sqrt(X * X + Y * Y);
//method expressions - 
public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
//params for enumerables - 
public Point Average(params IEnumerable<Point> points) { }
//monadic null checking - 
if (points?.FirstOrDefault()?.X ?? -1) { }
//constructor type parameter inference - 
var t = new Tuple(1,2); // infers Tuple<T1, T2>
//inline declarations for out params - 
public void Foo(out var x, out var y) { }

Имхо, какой то хоть и полезный но хлам.

Здравствуйте, Аноним, Вы писали:


А>Nunit
А>Есть вот такой метод для теста
А>Как лучше, оставить как есть или сделать через параметры и указывать все значения init1, do1, 0, 1 — через аттрибуты
А>Насколько это удобно будет отлаживать во 2м случае ?

Конечно здесь явно напрашиваются параметризованные тесты, ведь по сути, здесь не один тест, а два.

[TestCase("init1", "do1", Result = 0)]
[TestCase("init2", "do2", Result = 1)]
public int Test_That_Do_Produces_Expected_Result(string initData, string doData)
{
  // У нас же тут ООП, как никак, а раз так, то инварианты класса А
  // должны устанавливаться в конструкторе
  var a = new A(initData);

  return a.Do(doData);
}

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

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

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

IT>С точки зрения сложности, то функция в которой или для которой создается объект и работающая с ним без интерфейса — это ад и израиль. Это не гибко, не читаемо, трудно поддерживается.

Хм... Я понимаю, что мы здесь теряем контекст рассуждения, но все небезызвестные ОО товарищи (Мейер, Фаулер, Эванс, Сииман) считают, что вводить интерфейсы и полиморфное поведение нужно лишь тогда, когда это требуется. К тому же, "гибко" и "трудно поддерживается" всегда идут рука об руку; за гибкость всегда нужно платить сложностью, без этого ни как (см. Who Needs an Architect Файлера в качестве примера рассуждения на эту тему).

Очень интересно, что отсутствие побочных эффектов рьяно популяризируется сторонниками ФП мира...

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

D>Для меня загадка — современные алгоритмы шифрования (криптографии). Мат.аппарата не хватает

D>На практическом уровне — public key/private key понятно, но чо там внутри — чисто магия.

Да ладно, если говорить о принципах, то там же всё вообще тривиально.

Вот смотри, предположим у нас есть функция y=exp(x); и соответственно обратная ей x=ln(y); Причём (и это ключевой момент) ln вычисляется намного дольше, чем exp. Кстати, это и для обычных exp и ln справедливо, а в асимметричной криптографии используется спец. вариант, в котором ln вычисляется годами... Теперь, при наличие пары таких функций, мы можем тривиально наладить защищённый канал.

Вот предположим у нас есть два человека (1 и 2) с каждый стороны и ещё третий, прослушивающий канал. 1 и 2 генерируют по одному случайному числу k1 и k2. Затем считают от них p1=exp(k1) и p2=exp(k2). И отсылают друг другу. В итоге у первого есть k1 и p2, у второго k2 и p1, а у прослушивающего p1 и p2.

Сегодня Владимир Кочетков опубликовал на рсдн сообщение о смерти Макса Шеманарёва, ака McSeem2 http://www.rsdn.ru/forum/life/5377045.

В выходные мы успешно мигрировали RSDN@Home с BLToolkit на linq2db. Было поправлено несколько не очень серьезных, но неприятных ошибок. В итоге полет нормальный, так что всем рекомендую как минимум новые проекты начинать на linq2db, и, по возможности мигрировать старые.
Основные исправления заключаются в смене неймспейсов и переименовании части атрибутов для разметки маппинга.
Изменений в запросах не понадобилось.
На очереди rsdn.ru