Каждому иногда приходится размышлять над тем, что же происходит в ИТ, как оно будет дальше развиваться, и как потом с этим жить. Хотелось бы этим постом ответить на статью «Мысли об идеальном языке программирования».

Что мы видим в оригинальной статье? Осведомленный о современных тенденциях языкостроения автор оценивает один из флагманских языков системного программирования, рассуждая, каких еще положительных концепций и архитектурных решений можно воткнуть в современный язык методом наращивания фич силами огромного общемирового сообщества.

Эта статья — продолжение статьи C#: коллекции только для чтения и LSP. Сегодня мы посмотрим на интерфейс IEnumerable с точки зрения принципа подстановки Барбары Лисков (LSP), а также разберемся, нарушает ли этот принцип код, имплементирующий IEnumerable.

Вопрос о том, что такое класс объектов, существует ли он в природе, обсуждается мной вот уже на протяжении двух статей: Класс объектов или объекты класса? , Особенности концептуального моделирования предметной области . Я задаюсь вопросом: можно ли, описывая предметную область, связать семантической связью объект и класс объектов?

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

Моделирование при помощи UML подливает масла в огонь, потому что во-первых, не позволяет моделировать классы объектов (Моделирование функциональных и физических событий в логической парадигме), а во-вторых, не позволяет связать семантикой класс объектов и объект. Таким образом, в области моделирования предметных областей наблюдается пока не изученное пустое пространство. Я позволю себе немного порезвиться на этом поле, чтобы показать, как на самом деле это забавно. Сегодня я расскажу про то, как мой вопрос связан с понятием исчисляемости и неисчисляемости существительного.

Big Data глазами разных индустрий — это очередная мечта о Граале, который решит, спасет и защитит! В жизни всё точностью до наоборот: Big Data — это совершенно новые задачи, свертывания застойных проектов и увольнения неперестроившихся специалистов. Предлагаем цикл статей по практике реального применения неструктурированных Big Data в разных индустриях, становлении новых специальностей, которым еще только придумываются названия — аналитик и социолог Big Data, HiLoad-лингвист, журналист-трендист (от слова трЕнд, а не трЫндеть), — и, надеемся, плодотворных обсуждений куда должна привести новая большая дорога.

На конференции connect(), мы объявили, что .NET Core будет выпущен полностью как программное обеспечение с открытым исходным кодом. В этой статье мы сделаем обзор .NET Core, расскажем, как мы собираемся его выпускать, как он соотносится с .NET Framework и что это все означает для кросс-платформенной разработки и разработки с открытым кодом.

Добрый день, коллеги!

Я предлагаю вам прочитать статью, которая является логическим продолжением начатой мной серии статей, посвященных моделированию предметных областей.



В этой статье я продолжаю давать определения терминам в рамках логической парадигмы. Я развиваю мысль о том, что такое реальность и о том, как мы ее моделируем. Я подчеркиваю тот факт, что мир, в котором мы живем, — это иллюзия. Мы даже не знаем, есть ли мы на самом деле, или наше существование — тоже иллюзия. Наше «Я» думает, что существует, но существует оно в мире иллюзий. Все, что мы видим, и что моделируем, — мы видим иллюзию и моделируем иллюзию.

В качестве реакции на мой предыдущий пост о защитном программировании, один из моих читателей прислал мне такой вопрос:

[Один] очень известный сценарий защитного программирования встречается, когда входным параметром является

IEnumerable




public class Publisher
{
    public Publisher(IEnumerable<Subscriber> subscribers)
    {
        // defensive copy -> good or bad?
        this.subscribers = subscribers.ToArray();
    }
    //  …
}

В этой статье я хочу рассказать о проблемах использования интерфейса IEnumerable. Мы рассмотрим, какие проблемы может принести использование этого интерфейса, когда его на самом деле нужно использовать, и чем его заменить.

А начать статью я хотел с пары примеров кода, а точнее с пары багов, встречавшихся мне в реальных проектах.

Для начала несколько вещей о которых вы могли не слышать:

• Идентификаторы в C# могут включать в себя escape-последовательности Unicode символов (как например \u1234).
• Идентификаторы в C# могут включать в себя Unicode символы категории Cf (other, format), но при сравнении идентификаторов на идентичность эти символы игнорируются.
• Символ «Монгольский разделитель гласных» (U+180E) в зависимости от версии Unicode принадлежит либо категории Cf (other, format), либо категории Zs (separator, space).
• В .NET хранится свой собственный список Unicode категорий, независимый от оных в Win32.
• Roslyn является .NET приложением, и поэтому использует Unicode категории, прописанные в файлах .NET. Нативный компилятор (csc.exe) использует либо системные (Win32) категории, либо хранит в себе копию таблиц Unicode.
• Никакая из таблиц Unicode символов (ни .NET, ни Win32) точно следует какой-либо из версий стандарта Unicode.
• Компиляторы могут иметь баги.

Из всего этого вытекают некоторые проблемы…

Во всём виноват Владимир

Все началось с обсуждения на собрании технической группы ECMA на прошлой неделе. Мы рассматривали «нормативные ссылки», и в частности какую версию стандарта Unicode мы будем использовать. На тот момент спецификация ECMA-335 (4-ое издание) использует Unicode 4.0, а спецификация C# 5 от Microsoft использует Unicode 3.0. Я точно не знаю, учитывают ли разработчики компиляторов такие особенности. На мой взгляд было бы лучше, если ECMA и Microsoft не указывали конкретную версию Unicode в своих спецификациях. Пусть разработчики компиляторов используют самую свежую версию Unicode, доступную на текущий момент. Однако тогда компиляторы должны будут поставляться со своей личной копией таблицы Unicode, что немного странно, на мой взгляд.

В рамках моей «работы» над стандартизацией C# 5 в технической группе ECMA-334 TC49-TG2 мне посчастливилось увидеть несколько интересных способов, которыми Владимир Решетников проверял C# на прочность. В данной статье описана одна из проблем, которые он поднял. Разумеется, она, скорее всего, никак не затронет 99.999% C#-разработчиков… но разобраться все равно любопытно.

Спецификации, используемые в статье:

• Стандарт Unicode 7.0.0 – в особенности, глава 3
• C# 5 (Документ Word)
• ECMA-335 (Спецификация CLI)

Что такое строка?

Как бы вы объявили тип string (или System.String)? Я могу предположить несколько вариантов ответа на данный вопрос, от расплывчатых до довольно конкретных:

• «Какой-нибудь текст в кавычках»
• Последовательность символов
• Последовательность символов Юникода
• Последовательность 16-битных символов
• Последовательность слов UTF-16

Только последнее утверждение полностью верно. Спецификация C# 5 (раздел 1.3) гласит:

Обработка строк и символов в C# использует UTF-16. Тип char представляет слово UTF-16, а тип string – последовательность слов UTF-16.

Пока всё в порядке. Но это C#. А как насчет IL? Что используется там, и имеет ли это значение? Оказывается, что имеет… Строки должны быть объявлены в IL как константы, и природа этого способа представления важна – не только кодировка, но и интерпретация этих закодированных данных. В частности, последовательность слов UTF-16 не всегда может быть представлена в виде последовательности слов UTF-8.

Мы продолжаем наши еженедельные публикации учебных материалов Технопарка. Предыдущие лекции были посвящены web-технологиям в целом, а также алгоритмам и структурам данных. В третьем блоке лекций рассказывается о языках С и С++.

Лекция 1. Язык С. Основы организации и использования оперативной и сверхоперативной памяти

Лекция начинается с введения в язык С: рассказывается об истории его появления, особенностях, преимуществах и недостатках, о сферах применения. Описываются основы препроцессорной обработки, рассматриваются вопросы управления памятью (модели управления памятью, области видимости объектов хранения) и производительность программ на языке С. Обсуждается связывание объектов хранения и их инициализация. Затем рассказывается о классах памяти в языке С. Следующая часть лекции посвящена проблематике указателей, а также работе с одномерными массивами. В заключение рассматривается стандарт POSIX и вопросы переносимости.

Вслед за Банком Англии, американский технический гигант IBM планирует создать аналог биткоин для традиционных валют, используя блокчейн-технологию, сообщает агентство Рейтер.

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

В статье объясняется: ”Все сделки будут находится в блокчейн (открытой бухгалтерской книге) в валюте определенной страны, например, в долларе или евро.



Источник, личность которого не раскрывается в связи с политикой IBM, называет проект “биткоином, но без биткоина”, добавляя при этом, что проект все еще находится на ранних стадиях развития. Далее, он положительно отозвался о целях, которые проект стремится достичь, предполагая, что блокчейн может помочь осуществлять платежи, тем самым, сделав их более удобными и легкими в использовании.

«Сейчас идет переломный момент по этому проекту», продолжает источник. «Этот проект несет большой смысл для цифровой валюты биткоин, так как это не только экономит бюджеты государств, но эта форма расчетов намного удобнее и безопаснее в использовании для людей».

Довелось как-то раз отлаживать вот такой код на C#, который «на ровном месте» падал с NullReferenceException:

	public class Tester {
		public string Property { get; set; }
		public void Foo() {
			this.Property = "Some string"; // NullReferenceException
		}
	}

Да, вот на этой самой строчке с присвоением свойства падал NullReferenceException. Что за дела, думаю — неужели рантайм перестал проверять наличие экземпляра перед вызовом экземплярных методов?

Как оказалось — в некотором роде да, перестал. Правда, и компилятор оказался не тем, за кого себя выдаёт, да и проверки вовсе не гарантированы рантаймом… Подробнее — под катом.

Предлагаю читателям «Хабрахабра» перевод публикации «100 Prisoners Escape Puzzle», которую я нашел на сайте компании DataGenetics. Все ошибки по данной статье присылайте, пожалуйста, в личные сообщения.

По условию задачи в тюрьме находится 100 заключенных, каждый из которых имеет личный номер от 1 до 100. Тюремщик решает дать заключенным шанс на освобождение и предлагает пройти придуманное им испытание. Если все заключенные справятся, то они свободны, если хотя бы один провалится — все умрут.

Что такое фильтры исключений?

Фильтры исключений (Exception Filters) — новая фича C# 6, которая позволяет устанавливать специфические условия для блока catch. Этот блок будет исполнятся только в случае, если указанные условия выполнены. Проиллюстрируем синтаксис небольшим фрагментом кода:

public void Main()
{
  try
  { 
    throw new Exception("E2");
  }
  catch(Exception ex) when(ex.Message == "E1")
  {
    Console.WriteLine("caught E1");
  }
  catch(Exception ex) when(ex.Message == "E2")
  {
    Console.WriteLine("caught E2");
  }
}

Устраиваясь на новую работу, я придумал новый вопрос для собеседования. Хочу задать его и вам.

Пусть у нас есть конкретная машина. КОНКРЕТНАЯ! Не тип и не класс машин, А именно конкретная машина, на которую я указываю своим указательным пальцем. Хозяин этой машины утверждает, что его машина состоит из множества компонентов, в том числе из колес. Он говорит, что его машина состоит из пяти колес (одно запасное). Замечу сразу, что хозяин говорит: «состоит из», а не «включает в себя».

Вопрос: слушая хозяина машины, что мы себе представляем: то, что машина состоит из колес одного класса?



Или то, что машина состоит из класса колес?

Привет, Хабр!

Взявшись за работу над образовательным проектом Хекслет, мы понимали, что на нас ложится большая ответственность. К нам приходит огромное количество новичков с вопросами и комментариями, такими как:

• С чего начать обучение программированию?
• У вас есть курс по Java для новичков, но я слышал, что нужно изучать Python, правда ли это?
• На других сайтах все просто и понятно, а у вас какие-то компиляции и тесты!
• Непонятно зачем нужен этот ваш курс по алгоритмам, в реальной жизни все алгоритмы уже реализованы в стандартных библиотеках

Но сложнее всего объяснить новичку, грубо говоря, во что он ввязывается. Благодаря очень простым, игровым образовательным проектам многие считают, что программирование это очень легко, а наши виртуальные машины, где нужно запускать тесты и компилировать код – это надуманная сложность. Давно хотелось найти такой материал, который бы подготовил новичка к длинному и сложному пути к карьере программиста. И недавно наши коллеги из Viking Code School такой материал написали! А мы его перевели для вас.



Квинси Ларсон был просто “офисным парнем в костюме”. Он решил научиться программировать. Начал спрашивать людей вокруг. Изучил немного Руби, потом быстренько посмотрел на другие языки вроде Scala, Clojure и Go. Он изучил Emacs, а потом Vim, а потом раскладку Dvorak. Он втыкал в Линукс, копался с Лиспом и кодил на Питоне, и жил при этом в командной строке больше полутора лет.

Его швыряло туда-сюда как листочек в торнадо. Каждый совет, который он слышал, тащил его то в одну, то в другую сторону, до тех пор пока он не прошел “каждый онлайн-курс по программированию во вселенной”. В конце концов, не смотря на то, что он получил работу разработчика ПО, Квинси:

… был уверен, что на первый взгляд нормальные программисты, с которыми я общался, были на самом деле социопатами, которые получили, а потом подавили в себе, травму при изучении программирования.

Ох. Звучит знакомо?

Недавний перевод статьи «Пора заменить Python как язык для обучения» спровоцировал большую дискуссию. Очевидно, что программисты считают эту тему очень важной. К сожалению, большинство споров были об императивных языках, и мало кто предлагал функциональные языки в качестве инструмента обучения программированию.

Мы в Хекслете недавно запустили новую версию, ключевой особенностью которой стали практические упражнения по программированию в браузере. В связи с этим мы стали получать еще больше писем от начинающих программистов с вопросами вроде «с чего начать». С одной стороны, они хотят выложить бета-версию приложения в app store через неделю. С другой стороны, мы понимаем, что за такой короткий срок, наверное, можно научиться кодить приложения, но нельзя научиться программировать. И сложно решить, что лучше: как можно быстрее научить созданию простых приложений без реального понимания программирования, алгоритмов и их вычислительной сложности, а потом начать знакомство с этими важными темами, или начать «с начала», и органично придти к созданию приложений и продуктов после освоения фундамента.

В 2001 году, Эдсгер Дейкстра написал письмо экономическому совету университета Техаса. В нем знаменитый ученый призывает членов совета задуматься о смене языка программирования для вводного курса. К сожалению, язык был заменен на Java. Примерно в то же время MIT сменили язык курса «Структура и интерпретация компьютерных программ» с функционального Scheme (диалекта LISP) на Python.

Сегодня мы публикуем перевод этого письма.

Членам Экономического Совета

Я пишу вам по поводу слуха о замене языка во вводном курсе по программированию с функционального языка Haskell на императивный язык Java. Я считаю, что Совет должен взять на себя ответственность, чтобы решение не было принято на неправильном уровне.

После более чем годовой подготовки начался эпохальный матч, который стал важной вехой в истории шахмат.

Ни до, ни после 1997 года поединки между компьютером и человеком не привлекали к себе такого общественного внимания.

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

Примечание переводчика: я заменил оригинальные обозначения сторон монеты head/tail на аверс/реверс, чтобы не вносить путаницу русскоязычными орёл/решка. На иллюстрации выше слева аверс (head), справа реверс (tail).

Спасение невозможно?

Это одна из тех типичных загадок о заключённых, в которых вы приговорены к смерти и можете спастись, только если докажете свои умственные способности тюремщику. Вы и ваш друг были заключены в тюрьму. Ваш тюремщик предлагает вам испытание. Если вы его выполните, вы оба будете освобождены.