>Перестаньте уже витать в розовых облаках революционного пыла.
Перестаньте верить в теории заговора и всемогущество «корпораций». «Корпорации» состоят в конечном счёте из обычных людей, которые в большинстве своём распиздяи частью своей души. Такова природа человека. Поэтому от обычных факапов и проёбов «корпорации» (ещё скажите с пафосом «мафия», ага) не застрахованы. Сегодня она «корпорация», а завтра продаётся с молотка за ящик пива.
>Почему кавычка — не кавычка, а апостроф — не апостроф?
По историческим причинам. Во времена телетайпов кодировки были маленькими, клавиатурные раскладки бедными. Один и тот же символ заменял открывающую английскую двойную кавычку, закрывающую английскую двойную кавычку, дюймы, etc. При переходе к Юникоду обратную совместимость не стали ломать, и клавиша рядом с Enter'ом по прежнему печатает этот «усреднённый» символ. А для правильных знаков введены самостоятельные code points. Популярность старого «искусственного» недосимвола вызвана тем, что он есть на клавиатурной раскладке, а правильных знаков — нет. Поэтому в быту (в аське, в постах, в SMS) используется «программистская кавычка». Но серьёзная типографика должна учитывать различия этих знаков — как разницу в семантике, так и во внешнем виде.
Например, в гарнитуре Times New Roman эти символы имеют совершенно разное начертание:
открывающая английская двойная кавычка: «две-шестёрки-вверху»
закрывающая английская двойная кавычка: «две-девятки-вверху»
дюймы: два наклонных штриха в виде клина (не закорючки)
«программистская кавычка»: два прямых клина, утолщённых сверху.
Что касается статьи — в целом здравая, вполне согласуется с моим опытом (верстал книжки в LaTeX'е для одной типографии).
Модули и сборки не при чём. Вопрос в неоднозначности выбора варианта перегрузки и в неоднозначности выбора перегруженная-функция/каррированная-функция.
Предположим, есть две перегрузки некоторой функции:
SomeFunc: (int) → SomeClass
SomeFunc: (string → int) → SomeClass
let i = test «Hello» // Тип int или string → int, если был бы «вывод типов шиворот навыворот».
let j = SomeFunc i // Какая перегрузка должна вызваться?
Обычно в современных языках тип выражения слева от «=» определяется по типу выражения справа от «=». Ты же предлагаешь наоборот — значение типа справа от «=» выбирать по будущему типу выражения слева от «=».
Не противоречит, если статический тип выражения выводится на основе типов входящих в него подвыражений. Но противоречит, если тип должен определяться контекстом будущего использования.
>… если обязать программиста фиксировать тип интерфейса глобальных публичных объектов.
Это противоречит твоему желанию «[определить тип] по дальнейшему использованию=)»
>Если дальше в коде написано let j = i + 5, то тип i — int, а если написано let j = i «qwerty», то string → int.
Дальнейшее использование может быть слишком «дальнейшим». Например, использование может быть в клиентском коде, т. е. в момент компиляции test «Hello» ничего не известно о том, как результат такого вызова будет использоваться. Грубо говоря, библиотечная функция, возвращающая test «Hello» может быть в одной dll'ке, а твой let j = i + 5 — в другой. Первая dll'ка ничего не должна знать о второй.
>можно было бы использовать вывод типов для разруливания таких проблем.
Как?
let i = test «Hello»
Как определить, i должно иметь тип int или string → int?
>Кажется, что «Размеченное объединение» принято называть алгебраическим типом данных.
Алг. типы данных — более общее понятие. Можно сказать так: алг. типы данных в F# реализованы в терминах размеченных объединений (discriminated unions).
Бросается в глаза чётность букв в каждом слове. Генерируй лучше не парами букв, а выбирай слоги из словаря, это позволит избежать невозможных комбинаций типа «жы».
>Если это не так, то приведенная Вами аналогия — неверна, не полна, либо не применима для обсуждаемой ситуации (обсуждается не стыривание/копирование имущества из квартир, а стыривание/копирование товара).
>Из этой «аналогии»… следует, что Вы не признаете ценности интеллектуальной собственности.
Не следует. Я лишь говорю, что могут быть случаи, когда интеллектуальная собственность как дороже, так и дешевле материальной. Причём эта разница может быть не только количественной, но и качественной (материальный ущерб по разному меняется в зависимости от изменения некоторых параметров модели — асимптотики разные).
Я не говорил, что пиратство — это хорошо. Я не говорил, что пиратство — это плохо. Я говорил, что сравнение копирования информации и физического изъятия предметов материального мира — некорректно. Сравнение, понимаете? Притянутые за хвост аналогии, и всё такое. А-а-а, хрен с ним, чего объяснять, только время тратить. Вы всё равно в любых словах прочтёте не то, что в них закладывал автор, а то, с чем удобнее спорить.
А ещё полуркайте по запросу «аналогия». Что это за приём, для чего и в каких случаях он используется. Скажите честно, вы всерьёз считаете многословные «логические» построения про чудо-холодильники на полэкрана удачной аналогией? Прочитавший должен хлопнуть себя по лбу: «Ай-да Fiery_Ice, как же я сам до такого примера не додумался»? Скажу по секрету: любая параллель (призванная прояснить ситуацию в сравнении) необходимо должна занимать меньший объём в описании, чем исходный предмет обсуждения. Она должна отсеивать несущественные детали, а не привносить новый шум.
Ламерам, ставящим минус, предлагается для начала Саттера хоть почитать, что ли.
А ещё лучше написать свой тестовый класс-обёртку над int. Определить оператор присваивания и постинкремент с обычной семантикой, которые печатают лог в консоль. И выяснить, что присваивание раньше инкремента вызвано никак не будет.
Это здесь вы мне сейчас минус ставите, вместо того, чтобы разобраться с вопросом. А попадёте мне на собеседование — я вам минусы буду ставить.
Стандарта можешь ты не знать, но книжки Саттера чтить обязан.
И правильно делают. См. хотя бы «Защищённый код».
Перестаньте верить в теории заговора и всемогущество «корпораций». «Корпорации» состоят в конечном счёте из обычных людей, которые в большинстве своём распиздяи частью своей души. Такова природа человека. Поэтому от обычных факапов и проёбов «корпорации» (ещё скажите с пафосом «мафия», ага) не застрахованы. Сегодня она «корпорация», а завтра продаётся с молотка за ящик пива.
По историческим причинам. Во времена телетайпов кодировки были маленькими, клавиатурные раскладки бедными. Один и тот же символ заменял открывающую английскую двойную кавычку, закрывающую английскую двойную кавычку, дюймы, etc. При переходе к Юникоду обратную совместимость не стали ломать, и клавиша рядом с Enter'ом по прежнему печатает этот «усреднённый» символ. А для правильных знаков введены самостоятельные code points. Популярность старого «искусственного» недосимвола вызвана тем, что он есть на клавиатурной раскладке, а правильных знаков — нет. Поэтому в быту (в аське, в постах, в SMS) используется «программистская кавычка». Но серьёзная типографика должна учитывать различия этих знаков — как разницу в семантике, так и во внешнем виде.
Например, в гарнитуре Times New Roman эти символы имеют совершенно разное начертание:
открывающая английская двойная кавычка: «две-шестёрки-вверху»
закрывающая английская двойная кавычка: «две-девятки-вверху»
дюймы: два наклонных штриха в виде клина (не закорючки)
«программистская кавычка»: два прямых клина, утолщённых сверху.
Что касается статьи — в целом здравая, вполне согласуется с моим опытом (верстал книжки в LaTeX'е для одной типографии).
Есть GAC.
Предположим, есть две перегрузки некоторой функции:
SomeFunc: (int) → SomeClass
SomeFunc: (string → int) → SomeClass
let i = test «Hello» // Тип int или string → int, если был бы «вывод типов шиворот навыворот».
let j = SomeFunc i // Какая перегрузка должна вызваться?
Обычно в современных языках тип выражения слева от «=» определяется по типу выражения справа от «=». Ты же предлагаешь наоборот — значение типа справа от «=» выбирать по будущему типу выражения слева от «=».
Не противоречит, если статический тип выражения выводится на основе типов входящих в него подвыражений. Но противоречит, если тип должен определяться контекстом будущего использования.
>… если обязать программиста фиксировать тип интерфейса глобальных публичных объектов.
Это противоречит твоему желанию «[определить тип] по дальнейшему использованию=)»
F# строго типизированный язык.
>Если дальше в коде написано let j = i + 5, то тип i — int, а если написано let j = i «qwerty», то string → int.
Дальнейшее использование может быть слишком «дальнейшим». Например, использование может быть в клиентском коде, т. е. в момент компиляции test «Hello» ничего не известно о том, как результат такого вызова будет использоваться. Грубо говоря, библиотечная функция, возвращающая test «Hello» может быть в одной dll'ке, а твой let j = i + 5 — в другой. Первая dll'ка ничего не должна знать о второй.
Как?
let i = test «Hello»
Как определить, i должно иметь тип int или string → int?
>Кажется, что «Размеченное объединение» принято называть алгебраическим типом данных.
Алг. типы данных — более общее понятие. Можно сказать так: алг. типы данных в F# реализованы в терминах размеченных объединений (discriminated unions).
Смотреть видеоролики не так напряжно, как идти чего-то ресерчить. Начни с презентации на PDC 2008, 300 Мб: channel9.msdn.com/pdc2008/TL11/
>А теперь у нас есть F# и решить эту задачу можно вот так-то.
В этом докладе есть подобные наглядные примеры.
Впрочем, в моём ЖЖ тоже пара слов о сабже есть: bik-top.livejournal.com/31134.html
Это он на «КРИ 2008» очень здорово жёг про MMORPG?
Проверка: должен быть на той же высоте и той же ширины, что и плюс.
Это не моя аналогия, а создателя ветки: habrahabr.ru/blogs/copyright/38248/#comment_904532
>Из этой «аналогии»… следует, что Вы не признаете ценности интеллектуальной собственности.
Не следует. Я лишь говорю, что могут быть случаи, когда интеллектуальная собственность как дороже, так и дешевле материальной. Причём эта разница может быть не только количественной, но и качественной (материальный ущерб по разному меняется в зависимости от изменения некоторых параметров модели — асимптотики разные).
А ещё полуркайте по запросу «аналогия». Что это за приём, для чего и в каких случаях он используется. Скажите честно, вы всерьёз считаете многословные «логические» построения про чудо-холодильники на полэкрана удачной аналогией? Прочитавший должен хлопнуть себя по лбу: «Ай-да Fiery_Ice, как же я сам до такого примера не додумался»? Скажу по секрету: любая параллель (призванная прояснить ситуацию в сравнении) необходимо должна занимать меньший объём в описании, чем исходный предмет обсуждения. Она должна отсеивать несущественные детали, а не привносить новый шум.
А ещё лучше написать свой тестовый класс-обёртку над int. Определить оператор присваивания и постинкремент с обычной семантикой, которые печатают лог в консоль. И выяснить, что присваивание раньше инкремента вызвано никак не будет.
Это здесь вы мне сейчас минус ставите, вместо того, чтобы разобраться с вопросом. А попадёте мне на собеседование — я вам минусы буду ставить.