Rust? Какой нафиг шраст-мраст, Эппол открывает Swift позже в этом году!

да у тебя и юникод-то, небось, вместо НОРМАЛЬНОЙ кодировки (ну там, КОИ, например).

Чем он мощный? Какой-то гибрид крестов с бедоном. Ничего нового нет.

Тебе же сказали, там есть «классы»! А всем известно, без «классов» ничего серьезного разработать нельзя.

Впрочем, ООП и так уже почти умерло.

И какие есть альтернативы?

Та нееее. Скобочек завезли.

От автора:

I started work on the Swift Programming Language in July of 2010. I implemented much of the basic language structure, with only a few people knowing of its existence. A few other (amazing) people started contributing in earnest late in 2011, and it became a major focus for the Apple Developer Tools group in July 2013 [...] drawing ideas from Objective-C, Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list.

Chris Lattner. Retrieved June 3, 2014.

Я скорее о таких штуках:

var shoppingList = ["Eggs", "Milk"]

shoppingList.append("Flour")

shoppingList += ["Baking Powder"]
// shoppingList now contains 4 items
shoppingList += ["Chocolate Spread", "Cheese", "Butter"]
// shoppingList now contains 7 items

shoppingList.insert("Maple Syrup", atIndex: 0)

for item in shoppingList {
    println(item)
}
// Six eggs
// Milk
// Flour
// Baking Powder
// Bananas

var airports = ["YYZ": "Toronto Pearson", "DUB": "Dublin"]

airports["LHR"] = "London"
// the airports dictionary now contains 3 items

for (airportCode, airportName) in airports {
    println("\(airportCode): \(airportName)")
}
// YYZ: Toronto Pearson
// LHR: London Heathrow

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

Для ООП наследование совершенно необязательно.

Функции, монады и модель типов Хинди-Милнера же.

Если на objective-c можно писать операционку, то почему на swift'e нельзя. Swift в итоге компилируется в аналог сишки с умной статической либой. По типу:
https://github.com/orangeduck/Cello

C, ява, питон уже есть. Все три активно развиваются. Всё остальное можно смело утилизировать.

Тащемт наследование - одно из основных свойств ООП-языка. Наследование обеспечивает в ООП полиморфизм и абстракцию данных.

Тащемто читай Алана Кэя, ООП не обязано включать наследование:

http://www.smalltalk.ru/articles/smalltalk.html

Инкапсуляция/полиморфизм/наследование - лишь одна из возможных реализаций ООП. И классов тоже может не быть. Например, есть такой объектно-ориентированный язык - Lua, где нет ни классов, ни наследования.

То строки скопировать не могут, то соревнуются в количестве и качестве багов при реализации стека

Можно подумать, у таких рукожопов в "расте" будет лучше... Та же фигня будет, только с бóльшим количеством глюков, т.к. синтаксис идиотский.

А если макросов много?

А нефиг!

А если структуры с запутанными указателями?

ССЗБ!

Все подряд на си делать нерационально с точки зрения трудозатрат...

Ну, не знаю. Для тех же веб-приложений по-моему С проще. Тем паче, что у меня либо вычислялки/рисовалки (а на чем их кроме С делать?), либо управлялки (скажем, открыть сокет и читать/писать).

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

С другой стороны, узнал вот вчера про библиотеку clutter — в будущем, возможно, вместо прямых вызовов openGL буду ее использовать.

Ява - виртуальная машина, питон - вообще интерпретируемая скриптодрисня. Ты еще JavaScript вспомни.

Это регресс, а не прогресс!

Рискнёшь летать на А380 с выкинутыми нафиг компьютерами? Чё, грамотный пилот же круче любых автопилотов... И в автомобили с компьютерами не садись: карбюратор - твоё ФСЁ.

Начать нужно с того, что неформализуемое искусство — это управление регистрами процессора.

В одном очень старом языке вот одна дивчина собралась добавить «раскраску регистров». Но тсссс... А то опять борщём начнут кормить насильно )

Та же фигня будет, только с бóльшим количеством глюков, т.к. синтаксис идиотский.

не будет, программа на Rust с такими багами просто не скомпилируется.

Тем паче, что у меня либо вычислялки/рисовалки (а на чем их кроме С делать?), либо управлялки (скажем, открыть сокет и читать/писать).

Вычислялки/рисовалки - на любом ЯП, в котором есть подходящие библиотеки, тот же питон, мне почему-то кажется что у тебя там не нужно выжимать 146% производительности из железа, так что C - не нужен
Управлялки - вообще лучше с C не связываться, как ни странно. Нужно написать нормальную библиотеку, занимающуюся байтодрочерством у себя внутри, а снаружи каким-нибудь нормальным ЯП пользоваться с человеческим интерфейсом.

те же CGI вполне легко реализуются теперь

существующих либ (в том числе на C) мало, нужно свои сниппеты понаделать? К тому же использовать в 21 веке CGI вместо хотя бы FastCGI - полнейшая дикость (впрочем зная про твою любовь к КОИ - ничего удивительного)

И тут сборка мусора скорее мешает и приводит к костылям finaly, try-with-resources(using, with, etc.) и пр.

Т.е. неявный вызов деструктора хз где (мы же не о хеловорде со всеми локальными объектами) - это не костыль, а finaly и with- - костыли?

Но согласен, что в идеале должны быть доступны все возможности, а кодеру уже решать, что в данный конкретный момент надо. Выпилили бы jvm-ный GC отдельной либой... Но это всё равно что пилить сук, на котором сидишь.

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

Вот кстати в OCaml для SMP, который планируют зарелизить в конце этого года, GC будет плагинным и можно будет свою реализацию втыкать, где это необходимо. Хочу такую же фичу для старого борщевого языка.

не будет, программа на Rust...

Будет будет. Эдик тут все верно сказал. 99% ошибок это ошибки в логике и невнимательность. Если ты вычитал 50 байт, а обратился к 51, то тебе даже руст не поможет, потому что индекс будет явно валидный, а вот данные - какая-то каша.

Ява - виртуальная машина

ява может существовать и без вм, на андроид5 вполне успешно реализовали AOT-компиляцию.

вообще интерпретируемая скриптодрисня

и? хочешь сказать, что скриптовые языки не нужны?

Ты еще JavaScript вспомни

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

99% ошибок это ошибки в логике и невнимательность.

Встроена удобная поддержка тестирования. https://doc.rust-lang.org/nightly/book/testing.html

Если ты вычитал 50 байт, а обратился к 51, то тебе даже руст не поможет, потому что индекс будет явно валидный, а вот данные - какая-то каша.

Пользуются срезами. https://doc.rust-lang.org/nightly/src/core/slice.rs.html#519-538

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

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

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

C, ява, питон уже есть. Все три активно развиваются. Всё остальное можно смело утилизировать.

Главный кандидат на утилизацию - Си, за ним - Java. Python пусть живет.

Ну, раз диванные ыксперты говорят, то ... океей.

Одобрение анонимных экспертов очень важно для всех нас.

Главный кандидат на утилизацию - Си, за ним - Java. Python пусть живет.

то что интерпретатор будона написан на сях чукчу не волнует?

Главный кандидат на утилизацию - Си, за ним - Java. Python пусть живет.

то что интерпретатор будона написан на сях чукчу не волнует?

Спроси чукчу. Заодно объясни ему, что такое будон.

Т.е. неявный вызов деструктора хз где (мы же не о хеловорде со всеми локальными объектами) - это не костыль, а finaly и with- - костыли?

У with- проблема как раз в том, что кишки реализации торчат наружу. Например, есть у нас класс, ресурсами он не владеет, соответственно в with- его использование оборачивать не надо было. А потом захотелось всё-таки иметь какие-то ресурсы внутри класса. По идее, это деталь реализации и клиентскому код про неё знать не надо - у нас ведь инкапсуляция и всё такое. С деструкторами как раз клиентский код модифицировать не надо. А с with- придётся.

Если ты вычитал 50 байт, а обратился к 51, то тебе даже руст не поможет, потому что индекс будет явно валидный, а вот данные - какая-то каша.

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

Такой тред, а анонимуса-смайлофага всё нет и нет. Непорядок.

а анонимуса-смайлофага

Кто таков? лиспер?

С деструкторами как раз клиентский код модифицировать не надо.

опять же, если мы не про «локальные переменные» (где и with всунуть нетрудно), а громадьё всякого булшита, типа фабрик, пулов и прочего содома, то может захотеться детерминировать освобождение ресурса, а не полагаться на «нагромождение фреймворков», и неявный деструктор ни чем не поможет, а явный ни чем не лучше иных костылей. Я к тому, что это такой малозначащий плюс, что вспоминать о нём можно только в последнюю очередь.

Да. Ты случайно не знаешь куда он пропал? Ведь он был участником каждого подобного треда.

Без сообщений или наследования слово «ООП» вообще перестаёт иметь какой-либо смысл. С тем же успехом и хаскель — ОО-язык.
http://loup-vaillant.fr/articles/deaths-of-oop

Насчет нормальной поддержки кросс-компиляции пока ничего не слышно?

А чего бы его не вспомнить? Если он в реализации на node.js медленнее сишки в 1.5 раза, зато мощнее раз в 5. Крути-верти что хочешь на нём, куча языков компилится в javascript - есть из чего выбрать.

Чем классы лучше модулей и библиотек?

Насчет нормальной поддержки кросс-компиляции пока ничего не слышно?

Не интересовался еще этим :)

Без сообщений или наследования слово «ООП» вообще перестаёт иметь какой-либо смысл.

В широком смысле, слово «ООП» уместно до тех пор, пока ты думаешь о программе как о совокупности объектов. Плюс на сегодняшний день в мире ООП есть некие best practices, в частности, лично я восторженно мастурбирую на SOLID. Так вот, ничто не мешает писать на Rust именно в таком ООП-ключе.

Чем классы лучше модулей и библиотек?

тащемта, классы их не заменяют, а дополняют.

а дальше, зависит от того какие классы. такие как в C++, очевидно, нахрен не нужны.

В широком смысле, слово «ООП» уместно до тех пор, пока ты думаешь о программе как о совокупности объектов.

Очень зыбко.

SOLID

Ну давай рассмотрим.

Программные сущности должны быть открыты для расширения, но закрыты для изменения.

Так как наследование отсутствует, выбора, собственно говоря, нет: мы не можем менять сущности.

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

Опять же наследование отсутствует, и этот принцип не имеет смысла.

Зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

С типажами сложнее сделать наоборот.

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

«Не клади все яйца в одну корзину».

такие как в C++, очевидно, нахрен не нужны.

Очень глупое заявление.

Программные сущности должны быть открыты для расширения, но закрыты для изменения.

Так как наследование отсутствует, выбора, собственно говоря, нет: мы не можем менять сущности.

Отсутствует наследование реализаций, точнее сахар для оного. Оно и не нужно. Под «сущностью» в формулировке open-closed следует понимать абстракции (т.е. интерфейсы, трейты, контракты), от которых (в правильно спроектированной программе) должен зависеть наш код. Эти самые трейты и нельзя менять (а можно только расширять), иначе значительные объемы кода окажутся разломаны. Что касается реализаций трейтов, то нет ничего дурного в том, что они меняются: остальная программа должна этого попросту не замечать. «Using the principles of object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction». http://www.objectmentor.com/resources/articles/ocp.pdf

Sometimes, implementing a trait requires implementing another trait:

trait Foo {
    fn foo(&self);
}

trait FooBar : Foo {
    fn foobar(&self);
}

Implementors of FooBar must also implement Foo, like this:

struct Baz;

impl Foo for Baz {
    fn foo(&self) { println!("foo"); }
}

impl FooBar for Baz {
    fn foobar(&self) { println!("foobar"); }
}
⇱

If we forget to implement Foo, Rust will tell us:

error: the trait `main::Foo` is not implemented for the type `main::Baz` [E0277]

«++», «x?y:z» и прочие pdp-артефакты

А чем тебе инкремент не нравится? А уж тернарный оператор вполне сокращает количество нажатий на клавиши. Главное — не вспоминать про (забыл как называются), когда сочетание трех символов позволяют один какой-либо символ заменить.

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

Опять же наследование отсутствует, и этот принцип не имеет смысла.

Заблуждение. Liskov substitution нужно иметь ввиду всякий раз, как ты реализуешь какой-либо трейт. Дело в том, что контракт, на который полагаются клиенты этого трейта, включает в себя (помимо сигнатур методов) ещё и определенное поведение этих методов. Скажем, если ты у некоего контейнера вызвал метод Clear(), то ты ожидаешь, что последующий вызов метода IsEmpty() вернет True (в однопоточной программе). Реализация контейнера должна не только предоставлять методы Clear() и IsEmpty() с подходящими сигнатурами, но и обеспечивать соответствующее поведение. Liskov substitution — именно об этом.

К сожалению, известные мне мейнстримные языки (и Rust, увы, тоже) не позволяют формально специфицировать поведенческую часть контракта, поэтому приходится фиксировать ее в юнит-тестах. Убого и ненадежно, ну да видно для лучших инструментов время еще не пришло. Baby steps.

опять же, если мы не про «локальные переменные» (где и with всунуть нетрудно)

Оно-то может и не трудно. Вот только класс может начать владеть ресурсом в результате рефакторинга. Потом бегать изменять код не слишком удобно, ведь компиляция не сломается. Опять же, если библиотеку пишем, то в этом плане ещё веселее.

Понятное дело, что далеко не всегда такое нужно, но неудобства случаются.

и неявный деструктор ни чем не поможет, а явный ни чем не лучше иных костылей.

Но и хуже не сделает. Я к тому, что минусов у деструкторов так и не увидел. Ну если мы не говорим о языках с ГЦ.

Скажем, если ты у некоего контейнера вызвал метод Clear(), то ты ожидаешь, что последующий вызов метода IsEmpty() вернет True (в однопоточной программе).

Такие инварианты должны быть частью типажа/класса типов. В Idris так и сделано, например, но это чистый функциональный язык с зависимыми типами.

Удобней при программировании. Человечней. Нет лишнего повтора кода как при фп. Можно реализовать мета-программинг, упростив создание классов на лету. Короче, гибкость.

Ты еще JavaScript вспомни.

А чё и не вспомнить? Node.js-жи есть ;)

Такие инварианты должны быть частью типажа/класса типов.
чистый функциональный язык

Сейчас абстракции чаще всего специфицируют как набор сигнатур методов. Иными словами, описывают список сообщений, которые умеет принимать объект.

А мне кажется, что в идеальном мире абстракция должна описываться чем-то вроде (обобщенного/факторизованного) конечного автомата, у которого смена состояния происходит при вызове метода / получении сообщения. На этапе компиляции должна доказываться теорема о том, что реализация на самом деле ведет себя в соответствии со спецификацией. Это даст zero overhead в рантайме и оставит нам низкоуровневый императивный контроль над императивным железом.