Ceylon 1.0.0

У С++ не было маркетинга. Вообще. И нет. Как и какого-либо «хозяина».

Case классы убоги, Tuple1, Tuple2...TupleN убоги.

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

Всё это попало на благодатную почву массового помешательства на почве ООП (как, впрочем, и жаба). И теперь все жрут эти кактусы, потому что их жрут все.

Кстати, изначально маркетинг Сана был направлен на раскрутку жабы для веб-браузеров, т.е. апплетов, которые благополучно загнулись.

Чем убоги, малыш? Дай угадаю - нельзя обращаться по индексу. А сути это не меняет.

Ну и философский вопрос: почему на ЛОРе половина комментаторов не включают мозг вообще?

Специально для глупого анонимуса

http://en.wikipedia.org/wiki/Tuple#Definitions

Union types это вообще офигенчик, избавляющий от всяких verbose непотребств вроде Either, а уж если вариантов больше чем два то вообще сказка.

Но тебе, мой дорогой диванный теоретик, этого не понять.

То что в скобках к тому что за скобками отношения не имеет никакого.

То что в скобках это, по ходу, обобщение того что за скобками.

Ну ты уж снизайди до нас глупцов со своего Олимпа. Покажи пример кода там и там. Ну чтоб соснули и вся фигня.

http://ceylon-lang.org/documentation/1.0/tour/types/

http://www.scala-lang.org/api/current/index.html#scala.util.Either

Мне кажется, что при наличии нормальных алгебраических типов именно union'ы будут не нужны.

а они есть в scala? case classes там есть, а написать class IntStrng = Int | String там нельзя. Тут анон прав, только не стоит забывать, что скалисты таки хотят совместимости, а эти все ломают и бибикают

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

А вот с Java все наоборот. Основные причины - маркетинг, низкий порог вхождения, ограничения на технические возможности, чтобы больше кодить и меньше косячить, легкая заменяемость кадров... В этом нет ничего плохого, если что=)

Мне кажется, что при наличии нормальных алгебраических типов именно union'ы будут не нужны.

ADT не нужны, union-ы тоже не нужны, нужны tagged структуры как в Паскале.

А есть ли смысл в типе Int|String? Может и есть, но мне вроде никогда ничего похожего.

ну конечно, не умеет, значит не нужно.

Я учился программированию достаточно давно, потому ADT для меня это Abstract Data Type=)

Ceylon же умеет.

Ты до 1978 года учился? Потому как с конца 70х ADT это algebraic data types.

Врубаешь компилятор а он тебе «Чувак, вот тут у тебя может проскочить null в функцию в которую такое проскакиват не должно, чини!».

Примеры в альтернативных языках можете предложить для оценки?

Примеров нет потому что этого нет ни в одном используемом языке. Делается всё ручками. Почитать можно в гугле про data oriented design.

Врубаешь компилятор а он тебе «Чувак, вот тут у тебя может проскочить null в функцию в которую такое проскакиват не должно, чини!».

В Ceylon всё хитрее. Там null - это объект специального типа Null, а объекты любого другого типа не могут быть null. Например, если параметр функции объявлен как String, то он не может быть null (и это проверяется на этапе компиляции), а если как String? - то может (String? - это псевдоним для типа-пересечения String|Null).

Примеров нет потому что этого нет ни в одном используемом языке. Делается всё ручками. Почитать можно в гугле про data oriented design.

Понятно. Ну да, было бы неплохо. Но видимо не в этой жизни.

Видимо, смотря где. Я учился в 90е. Алгебраические типы данных я проходил позднее, чем ADT, а никакого заметного следа функциональное программирование во мне тогда не оставило и моды на него не было. В отличие от темы ADT=)

Массовое помешательство на почве ООП во многом благодаря плюсам и произошло.

Не, сначала было помешательство, а потом популярность плюсов.

В 2.10.3 добавили произвольное n для кортежей. А чем кейс-классы не нравятся?

It's time for some bad news: Ceylon doesn't have method or constructor overloading (the truth is that overloading is the source of various problems in Java, especially when generics come into play). However we can emulate most non-harmful uses of constructor or method overloading using:

• defaulted parameters,
• variadic parameters (varargs), and
• union types or enumerated type constraints.

В таких условиях union'ы действительно полезны...

А что массово использовали до C++?

сишечку

А что массово использовали до C++?

Ты будешь смеяться, но Си. До сих пор помню, как году в 1992 прочитал результат опроса в США, что из программистских групп, использовавших ООП, 52% использовали Си (и вроде 12% - Аду).

А первым более-менее массовым продуктом для разработчиков был NeXT Interface Builder для Objective C.

А это чем-то лучше case-классов

abstract class Suit(String name)
        of hearts | diamonds | clubs | spades {}
 
object hearts extends Suit("hearts") {}
object diamonds extends Suit("diamonds") {}
object clubs extends Suit("clubs") {}
object spades extends Suit("spades") {}

Ты будешь смеяться, но Си. До сих пор помню, как году в 1992 прочитал результат опроса в США, что из программистских групп, использовавших ООП, 52% использовали Си (и вроде 12% - Аду).

Я имею в виду из ООП. Если помешательство на ООП было раньше, то значит его массово использовали до С++. Я вроде бы о таком массовом использовании не слышал.

Вот именно, что сишечку, а не языки с поддержкой ООП.

Вернее вот это:

]abstract class Node() of Leaf | Branch {}
 
class Leaf(shared Object element) 
        extends Node() {}
 
class Branch(shared Node left, shared Node right) 
        extends Node() {}

А каков был процент программистских групп, использующих ООП?

В 2.10.3 добавили произвольное n для кортежей.

Welcome to Scala version 2.10.3 (OpenJDK Server VM, Java 1.7.0_45).

Type in expressions to have them evaluated.

Type :help for more information.

scala> val t = (1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,12,3,4,5,6,7,8,9,0)

<console>:7: error: object Tuple29 is not a member of package scala

А чем кейс-классы не нравятся?

Выше написали уже.

Ой, это я напутал чото. Во-первых, в 2.11, а во-вторых, не кортежи, а как раз кейс-классы:

Case classes with > 22 parameters are now supported SI-7296

И нащот кортежей тоже что-то там обсуждают: https://issues.scala-lang.org/browse/SI-7099 (в ссылках на группы). Правда, пока не договорились, как именно будут фиксить :/

Выше написали уже.

Я весь тред прочел, но так и не понял.

в те времена ООП было рокет сайнсом, примерно как ФП сейчас. Да и не было необходимости в ООП в те времена. Слишком мало памяти и вследствии этого вынужденное байтоебство. Был смоллталк, но в чисто академическом виде.

А кресты давали возможность и байтоебствовать, и понемножечку использовать ООП в ограниченной функциональности. Это и было причиной восхождения и падения плюсов. Сейчас нет необходимости байтоебствовать при реализации бизнес-приложений. И соответственно эта помесь бульдога с носорогом должна отправиться на свалку истории.

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

Вот и я про то же.

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

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

Да, без «sealed» выглядит аккуратнее.

Что-то около половины, но точной цифры не помню

Ну это уже детали. Я бы вообще предпочел явные алгебраические типы(пусть и реализованные внутри на классах).

Ну это уже детали.

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

Ладно ладно.

чем больше я знаю, тем лучше понимаю что ничего не знаю.

За то я ту ночь так и не поспал. Ковырял эти нововведения 8-ки. Грустно стало. Слишком давно ни строчки не кропал. Мозги киснут.

Html html = Html ...

Say more. (c) Ceylon

Можно написать value html = Html. Type inference же.