Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.06.14 22:02
Оценка: 7 (1) -1 :))) :))
https://itunes.apple.com/gb/book/swift-programming-language/id881256329?mt=11

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


Вывод типов,
паттерн-матчинг,
толковые туплы и энумы,
замыкания,
дженерики,
экстеншны,
Единицы измерений,
Делегирование
Кастомные операторы, в т.ч. инфиксные,
'монадический' optional

Если будет внятный GC, то это лучше C#, Джавы и С++ вместе взятых. Но судя по набору фич язык сильно близко подобрался к Scala и F#

И самое главное — Сишный синтаксис !
Re: Swift
От: kleng  
Дата: 02.06.14 22:07
Оценка: 18 (1) +5 -2 :))) :)
Здравствуйте, Ikemefula, Вы писали:

I>И самое главное — Сишный синтаксис !


Смущает разработчик. Намордник и анальный зонд в комплекте?
Re: Swift
От: dimgel Россия http://dimgel.ru/
Дата: 02.06.14 22:10
Оценка: 5 (1) +2
Здравствуйте, Ikemefula, Вы писали:

I>Но судя по набору фич язык сильно близко подобрался к Scala и F#


Макросов нету.
Re: Swift
От: NeoCode  
Дата: 03.06.14 04:57
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>https://itunes.apple.com/gb/book/swift-programming-language/id881256329?mt=11

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

Странный подход, написано free, в фиг скачаешь без этого вашего тунца. Как они собираются привлекать разработчиков, не имевших до этого дела с эппл?

Вот, китайцы выложили в открытый доступ: http://pan.baidu.com/s/1hqvaIm4
Re: Swift
От: Qbit86 Кипр
Дата: 03.06.14 05:03
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>И самое главное — Сишный синтаксис ! :super:


Где ты там увидел сишный синтаксис? В официальном заявлении сказано: «Objective-C without C».
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Swift
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 06:24
Оценка:
NC>Странный подход, написано free, в фиг скачаешь без этого вашего тунца. Как они собираются привлекать разработчиков, не имевших до этого дела с эппл?

Можно просто на сайте почитать описания и т.п.: https://developer.apple.com/library/prerelease/ios/referencelibrary/GettingStarted/LandingPage/index.html

https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/TheBasics.html#//apple_ref/doc/uid/TP40014097-CH5


dmitriid.comGitHubLinkedIn
Re: Swift
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 06:27
Оценка: 7 (1)
I>https://itunes.apple.com/gb/book/swift-programming-language/id881256329?mt=11

I>Apple родила язык.



Автор Rust'а про Swift: http://graydon2.dreamwidth.org/5785.html


ЗЫ. Помнится, тут многие слбни пускали по поводу какого-то концепта IDE, где выполнение показывалось на ходу. А Apple взяли и реализовали не концепт


dmitriid.comGitHubLinkedIn
Re[2]: Swift
От: avpavlov  
Дата: 03.06.14 06:51
Оценка: 10 (2) +3
M>ЗЫ. Помнится, тут многие слбни пускали по поводу какого-то концепта IDE, где выполнение показывалось на ходу. А Apple взяли и реализовали не концепт

Мамут, очнись. Для Скалы это сделано в Scala IDE года 3 назад, а год (или чуть меньше) сделано и в ИДЕЕ.

Вот ИДЕЙное видео

http://blog.jetbrains.com/scala/2014/05/23/meet-the-new-scala-worksheets-in-intellij-idea/

M>


Ага, ага. Эппл снова что-то изобрёл на -3 года первее всех.
Re[2]: Swift
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 03.06.14 07:15
Оценка: +1 -2
Здравствуйте, kleng, Вы писали:

K>Смущает разработчик. Намордник и анальный зонд в комплекте?


Вот не неадо вываливать свои сексуальные фантазии на форум для программистов, их лучше постить на соответствующих ресурсах.
Если же говорить о разработках Apple, то компания является одним из основных (или даже основным) спонсором LLVM и Clang. А эти компиляторы, в отличие от VS бесплатны, а в отличие от GCC идут под куда более гуманной лицензией.
Так что если язык был разработан Apple – это скорее даже плюс. Разве что меня берут сомнения, что он где-либо за пределами Darwin + FreeBSD работать будет
Re[3]: Swift
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 07:16
Оценка: -1
M>>ЗЫ. Помнится, тут многие слбни пускали по поводу какого-то концепта IDE, где выполнение показывалось на ходу. А Apple взяли и реализовали не концепт

A>Мамут, очнись. Для Скалы это сделано в Scala IDE года 3 назад, а год (или чуть меньше) сделано и в ИДЕЕ.

A>Вот ИДЕЙное видео
A>http://blog.jetbrains.com/scala/2014/05/23/meet-the-new-scala-worksheets-in-intellij-idea/

Прикольно, не знал


M>>


A>Ага, ага. Эппл снова что-то изобрёл на -3 года первее всех.


ты придумал за меня какое-то утверждение


dmitriid.comGitHubLinkedIn
Re[2]: Swift
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 03.06.14 07:17
Оценка:
Здравствуйте, NeoCode, Вы писали:

NC>Странный подход, написано free, в фиг скачаешь без этого вашего тунца. Как они собираются привлекать разработчиков, не имевших до этого дела с эппл?


Скорей всего никак. Как минимум пока
Re[3]: Swift
От: Qbit86 Кипр
Дата: 03.06.14 07:18
Оценка: +4
Здравствуйте, kaa.python, Вы писали:

KP>Вот не неадо вываливать свои сексуальные фантазии на форум для программистов


Это не сексуальные фантазии, а вполне оправданные опасения.

KP>А эти компиляторы, в отличие от VS бесплатны


Компилятор C++ от Майкрософт тоже бесплатный.
Глаза у меня добрые, но рубашка — смирительная!
Re[4]: Swift
От: avpavlov  
Дата: 03.06.14 07:27
Оценка:
A>>Вот ИДЕЙное видео
A>>http://blog.jetbrains.com/scala/2014/05/23/meet-the-new-scala-worksheets-in-intellij-idea/

M>Прикольно, не знал


Ещё вот результат гугления по интерактивным ИДЕ, на этот раз LUA

https://www.youtube.com/watch?v=FpxIfCHKGpQ
Re[2]: Swift
От: avpavlov  
Дата: 03.06.14 07:28
Оценка: +1
M>ЗЫ. Помнится, тут многие слбни пускали по поводу какого-то концепта IDE, где выполнение показывалось на ходу.

На самом деле, это скорее ВАУ фича, чем что-либо полезное. Те примеры что есть, скорее всего масксимум возможностей и показывают, а именно простые однопоточные приложения с простой моделью данных.
Re[4]: Swift
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 07:29
Оценка: -1
KP>>Вот не неадо вываливать свои сексуальные фантазии на форум для программистов
Q>Это не сексуальные фантазии, а вполне оправданные опасения.

Чем гни оправданы? Правильно, ничем.


dmitriid.comGitHubLinkedIn
Re[4]: Swift
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 03.06.14 07:29
Оценка: -3
Здравствуйте, Qbit86, Вы писали:

Q>Это не сексуальные фантазии, а вполне оправданные опасения.


В каком месте они оправданны, если большинство низкоуровневого кода ядра и компиляторы у Apple выпущены под BSD лиензией? Оправданны в сексуальных фантазиях?
Re[3]: Swift
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 07:58
Оценка: +1
M>>ЗЫ. Помнится, тут многие слбни пускали по поводу какого-то концепта IDE, где выполнение показывалось на ходу.

A>На самом деле, это скорее ВАУ фича, чем что-либо полезное. Те примеры что есть, скорее всего масксимум возможностей и показывают, а именно простые однопоточные приложения с простой моделью данных.


Ну, на самом деле я на это дело смотрю, как на приятный расширенный REPL


dmitriid.comGitHubLinkedIn
Re[2]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.06.14 10:59
Оценка:
Здравствуйте, Qbit86, Вы писали:

I>>И самое главное — Сишный синтаксис !


Q>Где ты там увидел сишный синтаксис? В официальном заявлении сказано: «Objective-C without C».


На самом деле там Objective-С без Objective
Re[3]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.06.14 11:04
Оценка:
Здравствуйте, avpavlov, Вы писали:

A>Ага, ага. Эппл снова что-то изобрёл на -3 года первее всех.


Где ты увидел 'изобрёл' ?
Re[3]: Objective-С
От: Qbit86 Кипр
Дата: 03.06.14 11:10
Оценка: 1 (1) :)
Здравствуйте, Ikemefula, Вы писали:

Q>В официальном заявлении сказано: «Objective-C without C».

I>На самом деле там Objective-С без Objective

Objective-C такой язык, что от выбрасывания любой части хуже не станет.
Глаза у меня добрые, но рубашка — смирительная!
Re[4]: Swift
От: Cyberax Марс  
Дата: 03.06.14 11:25
Оценка:
Здравствуйте, Mamut, Вы писали:

A>>На самом деле, это скорее ВАУ фича, чем что-либо полезное. Те примеры что есть, скорее всего масксимум возможностей и показывают, а именно простые однопоточные приложения с простой моделью данных.

M>Ну, на самом деле я на это дело смотрю, как на приятный расширенный REPL
Мне вот всегда было интересно зачем REPL нужен...
Sapienti sat!
Re: Swift
От: Klapaucius  
Дата: 03.06.14 12:27
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Apple родила язык.


Спасибо, Эппл, что не iGO.

I>Вывод типов


Это скорее реконструкция типов.

I>паттерн-матчинг,


Насколько я понял, он "плоский", Т.е. [Just a,_] не сматчит. Привет 60-е, короче говоря.
Да и синтаксис у него, конечно, тот еще:
enum ServerResponse {
    case Result(String, String)
    case Error(String)
}
let success = ServerResponse.Result("6:00 am", "8:09 pm")
let failure = ServerResponse.Error("Out of cheese.")

switch success {
    case let .Result(sunrise, sunset):
        let serverResponse = "Sunrise is at \(sunrise) and sunset is at \(sunset)."
    case let .Error(error):
        let serverResponse = "Failure... \(error)"
}


I>замыкания,


Это без ГЦ на одном подсчете ссылок? Ну ну.

I>дженерики,


Только вот от конструктора абстрагироваться-то как обычно нельзя.

I>'монадический' optional


Который, как я понял, автораспаковывается.

I>Если будет внятный GC,


А его хотя-бы обещают?

I>то это лучше C#, Джавы и С++ вместе взятых.


Тоже мне бином Ньютона. Чтоб хуже сделать — это специально постараться нужно, как Гуглу.

I>Но судя по набору фич язык сильно близко подобрался к Scala и F#


Он объединяет в себе недостатки этих языков: убогую систему типов F#-а c убогим Scala-синтаксисом.

I>И самое главное — Сишный синтаксис !


Как будто это что-то хорошее! Синтаксис не сишный, немного получше, но не сильно.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[5]: Swift
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 12:28
Оценка:
A>>>На самом деле, это скорее ВАУ фича, чем что-либо полезное. Те примеры что есть, скорее всего масксимум возможностей и показывают, а именно простые однопоточные приложения с простой моделью данных.
M>>Ну, на самом деле я на это дело смотрю, как на приятный расширенный REPL
C>Мне вот всегда было интересно зачем REPL нужен...

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


dmitriid.comGitHubLinkedIn
Re[6]: Swift
От: Cyberax Марс  
Дата: 03.06.14 12:34
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>>Ну, на самом деле я на это дело смотрю, как на приятный расширенный REPL

C>>Мне вот всегда было интересно зачем REPL нужен...
M>Это очень удобный инструмент. Как для быстрого прототипирования и проверки некоторых идей, так и для быстрого тестирования некоторых вещей
Ну так берёшь, создаёшь файлик и туда записываешь (с автокомплитом и всеми прочими плюшками) нужный код. Потом с отладчиком выполняешь, они нынче умные и позволяют удобно инспектировать код.
Sapienti sat!
Re[5]: Swift
От: Klapaucius  
Дата: 03.06.14 12:34
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Мне вот всегда было интересно зачем REPL нужен...


Нужен для экспериментирования с кодом. Просто это подходит только для языков где небольшой снипет кода что-то нетривиальное делает без трудновоспроизводимого окружения, вроде функциональных языков, либо в тех, где это самое окружение легко сохранять, вроде лиспов и смолтоков.
Во всяких C/Java он в основном бесполезен. также очень легко сделать неюзабельный REPL "для галочки", как в F#.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[7]: Swift
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 12:46
Оценка:
M>>>>Ну, на самом деле я на это дело смотрю, как на приятный расширенный REPL
C>>>Мне вот всегда было интересно зачем REPL нужен...
M>>Это очень удобный инструмент. Как для быстрого прототипирования и проверки некоторых идей, так и для быстрого тестирования некоторых вещей
C>Ну так берёшь, создаёшь файлик и туда записываешь (с автокомплитом и всеми прочими плюшками) нужный код. Потом с отладчиком выполняешь, они нынче умные и позволяют удобно инспектировать код.

1. Зачем, если ты имеешь тот же автокомплит (и часто отладчик) прямо из REPL'а?
2. Для большинства языков, чтобы что-то выполнить, нужно написать толпу обвязки вокруг (все эти main'ы, вызовы и прочее), когда надо быстро проверить пару идей?


dmitriid.comGitHubLinkedIn
Re[2]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.06.14 13:07
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Насколько я понял, он "плоский", Т.е. [Just a,_] не сматчит. Привет 60-е, короче говоря.


90е и 2000 это Java и C#, в которых еще более примитивный switch

K>Да и синтаксис у него, конечно, тот еще:


Да, не такой, как в Хаскеле

I>>И самое главное — Сишный синтаксис !


K>Как будто это что-то хорошее! Синтаксис не сишный, немного получше, но не сильно.


Именно. Для 90% разрабов, которые только и имеют дело с сишным синтаксисом, это очень круто.
Re[8]: Swift
От: Cyberax Марс  
Дата: 03.06.14 14:27
Оценка:
Здравствуйте, Mamut, Вы писали:

C>>Ну так берёшь, создаёшь файлик и туда записываешь (с автокомплитом и всеми прочими плюшками) нужный код. Потом с отладчиком выполняешь, они нынче умные и позволяют удобно инспектировать код.

M>1. Зачем, если ты имеешь тот же автокомплит (и часто отладчик) прямо из REPL'а?
Не везде они есть.

M>2. Для большинства языков, чтобы что-то выполнить, нужно написать толпу обвязки вокруг (все эти main'ы, вызовы и прочее), когда надо быстро проверить пару идей?

А идеи без обвязки будут работать?
Sapienti sat!
Re[6]: Swift
От: Cyberax Марс  
Дата: 03.06.14 14:27
Оценка:
Здравствуйте, Klapaucius, Вы писали:

C>>Мне вот всегда было интересно зачем REPL нужен...

K>Нужен для экспериментирования с кодом. Просто это подходит только для языков где небольшой снипет кода что-то нетривиальное делает без трудновоспроизводимого окружения, вроде функциональных языков, либо в тех, где это самое окружение легко сохранять, вроде лиспов и смолтоков.
Ну то есть, как замена удобному отладчику.
Sapienti sat!
Re[2]: Swift
От: artelk  
Дата: 03.06.14 14:33
Оценка:
Здравствуйте, Klapaucius, Вы писали:

I>>паттерн-матчинг,


K>Насколько я понял, он "плоский", Т.е. [Just a,_] не сматчит. Привет 60-е, короче говоря.


https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Patterns.html#//apple_ref/swift/grammar

Там, вроде, рекурсивно в грамматике:

enum-case-pattern → type-identifier­ .­enum-case-name ­tuple-pattern­

tuple-pattern → (­tuple-pattern-element-list­)­
tuple-pattern-element-list → tuple-pattern-element­ tuple-pattern-element­,­tuple-pattern-element-list­
tuple-pattern-element → pattern
Re[9]: Swift
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 14:34
Оценка:
M>>2. Для большинства языков, чтобы что-то выполнить, нужно написать толпу обвязки вокруг (все эти main'ы, вызовы и прочее), когда надо быстро проверить пару идей?
C>А идеи без обвязки будут работать?

Зависит от идеи

В C/C++/Java/C# ты даже строчку кода не можешь запустить без main'а

А мне надо сейчас баг решать, с разными вводными данными (небольшим количеством). Прямо в шелле:

> restapi_test:init_mock_oauth().
> da_order_lib:setup_good_user([]).
> [da_order_lib:make_order() || _ <- lists:seq(1, 7)].


Все, во втором окне запускаю curl для проверки резульатов (проверяем выхлоп REST API на некотором наборе данных, не можем воспроизвести ситуацию из бага).

При этом я тут же могу сделать стопятьсот других полезных вещей


dmitriid.comGitHubLinkedIn
Re: Swift
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.14 15:59
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Вывод типов,

I>паттерн-матчинг,
I>толковые туплы и энумы,
I>замыкания,
I>дженерики,
I>экстеншны,
I>Единицы измерений,
I>Делегирование
I>Кастомные операторы, в т.ч. инфиксные,
I>'монадический' optional

http://rsdn.ru/forum/nemerle/5632578
Автор: VladD2
Дата: 03.06.14

Убило использование подсчета ссылок без автоматического разруливания за зацикливаний. В 21 веке это выглядит дико. Такому языку нужен GC или хотя бы автоматический поиск зацикливаний, как в Руби.

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

Чисто стилистически не понравилась утащенная из GO идея не писать круглые скобки, но всегда писать фигурные.

Плохо, что не поддерживается концепция "все является выражением".

Странно выглядит отсутствие приватных членов в классах (можно я чего-то не заметил?).

В остальном язык ничего. Во многом похож на Немерл.

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

Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Swift
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.14 16:04
Оценка:
Здравствуйте, Mamut, Вы писали:

M>многие слбни пускали по поводу какого-то концепта IDE, где выполнение показывалось на ходу. А Apple взяли и реализовали не концепт


О чем речь? Можно по подробнее?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Swift
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.14 16:15
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Ну, на самом деле я на это дело смотрю, как на приятный расширенный REPL


Только на практике репл годится только для поиграться. В больших приложениях нужны более серьёзные средства отладки и управления проектами. В Немерле репл сдох за ненадобностью.

Правильным подходом было бы встроить репл в отладчик. Остановился по точке останова и поигрался с данными с помощью локального репла. Ну, а еще правильнее чтобы можно было код править на лету, как в скриптах. У МС есть Edit & Continue, но слишком много ограничений.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Swift
От: kleng  
Дата: 03.06.14 16:43
Оценка: -1 :)
Здравствуйте, kaa.python, Вы писали:

KP>Если же говорить о разработках Apple, то компания является одним из основных (или даже основным) спонсором LLVM и Clang.


Ключевые слова — спонсор, и "один из". Не владельцы проекта.
Re[2]: Swift
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 03.06.14 16:46
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Убило использование подсчета ссылок без автоматического разруливания за зацикливаний. В 21 веке это выглядит дико. Такому языку нужен GC или хотя бы автоматический поиск зацикливаний, как в Руби.


Как в Питоне, наверное. В Руби испокон веков был честный mark & sweep, никакого RC.

В свифте они целились на рантайм-совместимость с Obj-C, а там тот же самый ARC. Трудно было бы добавить честный GC в один язык, не добавив в другой. Ну и скорее всего это дело принципа: обеспечить иллюзию детерминированности и какбы отсутствие тормозов GC, шоб андроид не получился.
Re[5]: Swift
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 17:31
Оценка: +1
M>>Ну, на самом деле я на это дело смотрю, как на приятный расширенный REPL

VD>Только на практике репл годится только для поиграться. В больших приложениях нужны более серьёзные средства отладки и управления проектами. В Немерле репл сдох за ненадобностью.


Правильно. Что надо сделать? Придумать за оппонента тезис, мол, REPL заменяет какие-то там средства отладки и т.п. И давай — шашку наголо и бороться с этим тезисом. Про Немерле смешно, да.

Вот у нас большое приложение. Общее количество кода около миллиона строчек. Ничего, в разработке и REPL применяется, и «более серьёзные средства отладки». Но да, но да, «В Немерле репл сдох за ненадобностью» ©


dmitriid.comGitHubLinkedIn
Re[6]: Swift
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.14 17:58
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Правильно. Что надо сделать? Придумать за оппонента тезис, мол, REPL заменяет какие-то там средства отладки и т.п. И давай — шашку наголо и бороться с этим тезисом. Про Немерле смешно, да.


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

M>Вот у нас большое приложение. Общее количество кода около миллиона строчек. Ничего, в разработке и REPL применяется, и «более серьёзные средства отладки».


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

M>Но да, но да, «В Немерле репл сдох за ненадобностью» ©


Да, сдох. И единственная причина — не нужен никому на практике. Был бы нужен давно реанимировали. За все время вопрос о нем поднимался ровно один раз и успешно заглох.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Swift
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 18:49
Оценка: 5 (1) +2
M>>Правильно. Что надо сделать? Придумать за оппонента тезис, мол, REPL заменяет какие-то там средства отладки и т.п. И давай — шашку наголо и бороться с этим тезисом. Про Немерле смешно, да.

VD>Я ничего не придумывал. Просто сказал, что он особо не нужен на практике.


Извини, но вот это:

Только на практике репл годится только для поиграться. В больших приложениях нужны более серьёзные средства отладки и управления проектами.

это именно придумывание.

M>>Вот у нас большое приложение. Общее количество кода около миллиона строчек. Ничего, в разработке и REPL применяется, и «более серьёзные средства отладки».


VD>Ну, расскажи как вы там репл в большом приложении применяете.


В этой ветке
Автор: Mamut
Дата: 03.06.14



M>>Но да, но да, «В Немерле репл сдох за ненадобностью» ©


VD>Да, сдох. И единственная причина — не нужен никому на практике. Был бы нужен давно реанимировали. За все время вопрос о нем поднимался ровно один раз и успешно заглох.


Немерл. И на практике. И «большие приложения». Извини, но количество взаимоисключений тут слишком велико.


dmitriid.comGitHubLinkedIn
Re[7]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.06.14 19:41
Оценка: +1
Здравствуйте, VladD2, Вы писали:

M>>Правильно. Что надо сделать? Придумать за оппонента тезис, мол, REPL заменяет какие-то там средства отладки и т.п. И давай — шашку наголо и бороться с этим тезисом. Про Немерле смешно, да.


VD>Я ничего не придумывал. Просто сказал, что он особо не нужен на практике.


M>>Вот у нас большое приложение. Общее количество кода около миллиона строчек. Ничего, в разработке и REPL применяется, и «более серьёзные средства отладки».


VD>Ну, расскажи как вы там репл в большом приложении применяете.


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

скажем, рестарт сервера занимает несколько минут. проверить вырианты одной функции, это на пару секунд на каждый. Без репл это превращается в часы отладки.

M>>Но да, но да, «В Немерле репл сдох за ненадобностью» ©


VD>Да, сдох. И единственная причина — не нужен никому на практике. Был бы нужен давно реанимировали. За все время вопрос о нем поднимался ровно один раз и успешно заглох.


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

Прикинь, как круто — на каждый мелкий бажок создаешь инсталяционный пекадж, инсталируешь, запускаешь, ждёшь, прогоняешь всю цепочку и все это для того, что бы выяснить ,что в путях потерялся один из компонетов.
Re[8]: Swift
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.06.14 19:43
Оценка:
Здравствуйте, Mamut, Вы писали:

M>2. Для большинства языков, чтобы что-то выполнить, нужно написать толпу обвязки вокруг (все эти main'ы, вызовы и прочее)


Большинство языков давно обзавелись фреймворками для юнит-тестирования и тест-раннерами в составе IDE.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[10]: Swift
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.06.14 19:43
Оценка:
Здравствуйте, Mamut, Вы писали:

M>В C/C++/Java/C# ты даже строчку кода не можешь запустить без main'а


Конечно конечно. Я вот проект уже несколько месяцев пишу, а в нем, прикинь, ни одного мейна.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[9]: Swift
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 19:46
Оценка:
M>>2. Для большинства языков, чтобы что-то выполнить, нужно написать толпу обвязки вокруг (все эти main'ы, вызовы и прочее)
AVK>Большинство языков давно обзавелись фреймворками для юнит-тестирования и тест-раннерами в составе IDE.

Еще один.


dmitriid.comGitHubLinkedIn
Re[11]: Swift
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 19:47
Оценка:
M>>В C/C++/Java/C# ты даже строчку кода не можешь запустить без main'а
AVK>Конечно конечно. Я вот проект уже несколько месяцев пишу, а в нем, прикинь, ни одного мейна.

Поздравляю


dmitriid.comGitHubLinkedIn
Re[10]: LinqPad
От: Qbit86 Кипр
Дата: 03.06.14 20:01
Оценка:
Здравствуйте, Mamut, Вы писали:

M>В C/C++/Java/C# ты даже строчку кода не можешь запустить без main'а :xz:


Для C# есть LinqPad.
Глаза у меня добрые, но рубашка — смирительная!
Re[11]: LinqPad
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 20:03
Оценка:
M>>В C/C++/Java/C# ты даже строчку кода не можешь запустить без main'а

Q>Для C# есть LinqPad.


Для C# еще и PowerShell есть


dmitriid.comGitHubLinkedIn
Re[10]: Разовью мысль
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 20:08
Оценка: 20 (2) +3
M>>>2. Для большинства языков, чтобы что-то выполнить, нужно написать толпу обвязки вокруг (все эти main'ы, вызовы и прочее)
AVK>>Большинство языков давно обзавелись фреймворками для юнит-тестирования и тест-раннерами в составе IDE.

M>Еще один.


Вы с Владом придумали себе два тезиса:

1. REPL не нужен, вместо него нужны более серьёзные средства отладки и управления проектами.
2. REPL не нужен, большинство языков давно обзавелись фреймворками для юнит-тестирования и тест-раннерами в составе IDE.

Самое смешное, никто нигде не говорит, что REPL заменяет средства отладки или средства для удобного юнит-тестирования. Но вы эти два тезиса придумали и пытаетесь с ними бороться


dmitriid.comGitHubLinkedIn
Re[7]: Swift
От: novitk США  
Дата: 03.06.14 20:15
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну то есть, как замена удобному отладчику.


Репл ортоганален отладчику. Выставляешь брейки, потом приходишь к ним из репла.
Re[8]: Swift
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.14 20:36
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Немерл. И на практике. И «большие приложения». Извини, но количество взаимоисключений тут слишком велико.


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

Мы пишем довольно большой проект на Немерле. И не один. Репл у нас был еще 6 лет назад. По мере развития компилятора его поломали. Но так как на практике от него нет толку, его никто не восстанавливает.

Это реальность. А то что ты там себе придумал — это твоя виртуальная реальность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Swift
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.14 20:49
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>ставишь бряк куда надо, а там тупо вызываешь функции как хочешь.


Это и функциями отладчика делается прекрасно. Репл тут не нужен.

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


В студии даже можно исправить код в C# и продолжить выполнение. Причем тут репл?

I>скажем, рестарт сервера занимает несколько минут. проверить вырианты одной функции, это на пару секунд на каждый. Без репл это превращается в часы отладки.


Это домыслы.

Я вот не видел еще репла с отладчиком связанного. Обычно это отдельная утилита. А функцию вызвать — это сколько угодно и без него.

I>Вероятно оттого, что всё кругом на макросах а ни серверных приложений, ни мобильных не пишется.


Очевидно ты мало понимаешь в предмете обсуждения. Вот погляди что народ делает в области того же веба http://nemerleweb.com
Как и очевидно, что сотф не сходится к серверному или мобильному.

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


Это все вещи не связанные с наличием или отсутствием репла.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.06.14 20:55
Оценка: +2
Здравствуйте, VladD2, Вы писали:

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


VD>В студии даже можно исправить код в C# и продолжить выполнение. Причем тут репл?


Исправление кода на многих системах недоступно, ты не знал про это ?

I>>скажем, рестарт сервера занимает несколько минут. проверить вырианты одной функции, это на пару секунд на каждый. Без репл это превращается в часы отладки.


VD>Это домыслы.


Это факты.

VD>Я вот не видел еще репла с отладчиком связанного. Обычно это отдельная утилита. А функцию вызвать — это сколько угодно и без него.


I>>Вероятно оттого, что всё кругом на макросах а ни серверных приложений, ни мобильных не пишется.


VD>Очевидно ты мало понимаешь в предмете обсуждения. Вот погляди что народ делает в области того же веба http://nemerleweb.com


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

Сколько лет этим примерам ? Чем они лучше N+1 других фремворков ? Похоже, ничем, только требуют намного больше кода.

Серверные это не всегда веб, кстати говоря.

VD>Как и очевидно, что сотф не сходится к серверному или мобильному.


это самый большие ниши на сегодняшний день.

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


VD>Это все вещи не связанные с наличием или отсутствием репла.


Это так кажется.
Re[9]: Swift
От: Mamut Швеция http://dmitriid.com
Дата: 04.06.14 04:28
Оценка:
VD>Мы пишем довольно большой проект на Немерле. И не один. Репл у нас был еще 6 лет назад. По мере развития компилятора его поломали. Но так как на практике от него нет толку, его никто не восстанавливает.

VD>Это реальность. А то что ты там себе придумал — это твоя виртуальная реальность.



Виртуальная реальность — это называть полтора проекта, которые пишут пять людей, реальностью и истиной, которая распространяется на всех.


dmitriid.comGitHubLinkedIn
Re[11]: Разовью мысль
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.06.14 06:38
Оценка: 1 (1)
Здравствуйте, Mamut, Вы писали:

M>Самое смешное, никто нигде не говорит, что REPL заменяет средства отладки или средства для удобного юнит-тестирования.


Самое смешное что ты не умеешь читать. Я отвечал исключительно на твою реплику о том, что нужно написать кучу обвязки. Так вот, это не так — достаточно написать один единственный метод и пометить его атрибутом [Test].
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[12]: Разовью мысль
От: Mamut Швеция http://dmitriid.com
Дата: 04.06.14 07:39
Оценка:
M>>Самое смешное, никто нигде не говорит, что REPL заменяет средства отладки или средства для удобного юнит-тестирования.

AVK>Самое смешное что ты не умеешь читать. Я отвечал исключительно на твою реплику о том, что нужно написать кучу обвязки. Так вот, это не так — достаточно написать один единственный метод и пометить его атрибутом [Test].


Действительно, ведь все абсолютно упирается в юнит тесты, и все можно решить юнит-тестами


dmitriid.comGitHubLinkedIn
Re[3]: Swift
От: Klapaucius  
Дата: 04.06.14 08:06
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>90е и 2000 это Java и C#, в которых еще более примитивный switch


Я имел в виду, что в 70-е уже "неплоский" изобрели. А на Java и C# чего равняться — в них (языках, не реализациях) фич, изобретенных после 1968-го раз два и обчелся.

I>Да, не такой, как в Хаскеле


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

I>Для 90% разрабов, которые только и имеют дело с сишным синтаксисом, это очень круто.


Тут неявное предположение, что если кто-то с чем-то имеет дело постоянно — он и дальше хотел бы продолжать иметь.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[7]: Swift
От: Klapaucius  
Дата: 04.06.14 08:56
Оценка: +4
Здравствуйте, Cyberax, Вы писали:

C>Ну то есть, как замена удобному отладчику.


Нет, это не замена отладчику, это скорее замена всяким приседаниям с "созданием файликов".

РЕПЛ можно использовать совместно с отладчиком — и тогда окружение на брейкпойнте можно "инспектировать" и обрабатывать результат прямо определенной на месте функцией на этом же самом языке.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[5]: Swift
От: Klapaucius  
Дата: 04.06.14 09:00
Оценка: +3
Здравствуйте, VladD2, Вы писали:

VD>В Немерле репл сдох за ненадобностью.


Nemerlish, насколько я помню, был с самыми зачаточным функционалом, так что пользы от него было немного и не удивительно, что он оказался никому не нужен. Нормальный доделанный РЕПЛ инструмент более серьезный, в нем доступен язык полностью, т.е. можно любые декларации делать, автокомплит есть, интеграция с отладчиком и т.д.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[4]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.06.14 10:18
Оценка: +1
Здравствуйте, Klapaucius, Вы писали:

I>>90е и 2000 это Java и C#, в которых еще более примитивный switch


K>Я имел в виду, что в 70-е уже "неплоский" изобрели. А на Java и C# чего равняться — в них (языках, не реализациях) фич, изобретенных после 1968-го раз два и обчелся.


Тебя не смущает, что самые популярные и востребованые языки, это те, в которых никаких особенных фич то и нет ?

K>Да, и не такой как в остальных языках с паттерн матчингом. Вообще, тяжело навскидку вспомнить, где бы он был такой же страшный. Даже в скале получше, а там заявка на самый страшный ПМ серьезная.


Нет задачи дать внятный ПМ тем, у кого он и так есть.

Есть другая задача — дать хоть какой то ПМ тем, у кого ничего нет.

I>>Для 90% разрабов, которые только и имеют дело с сишным синтаксисом, это очень круто.


K>Тут неявное предположение, что если кто-то с чем-то имеет дело постоянно — он и дальше хотел бы продолжать иметь.


Тут неявно указание на популярность сишного синтаксиса за последние 40 лет.

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

И вот пока что для императивного программирования сишный синтаксис самый сбалансированый. Скажем, идейка выравнивать код отступами интересная, но её массы как то не принимают.
Re[5]: Swift
От: Klapaucius  
Дата: 04.06.14 11:33
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Тебя не смущает, что самые популярные и востребованые языки, это те, в которых никаких особенных фич то и нет ?


Нет, не смущает. Эти языки востребованы не из-за фич языков, а фич инфраструктуры вообще и реализаций в частности, этих языков, которых как раз достаточно и вложить столько труда в инфраструктуру какого-то другого, более продвинутого языка просто никто не может себе позволить.
Там где требования к качеству реализации низкие (в случае всяких питонов-рубей) языки выглядят совсем иначе и с перечисленными "самыми востребованными" имеют мало общего. Короче говоря, был бы для JVM только интеркол — писали бы на интерколе, просто текучка кадров и заполняемость психлечебниц слегка подскочила бы.

I>Нет задачи дать внятный ПМ тем, у кого он и так есть.

I>Есть другая задача — дать хоть какой то ПМ тем, у кого ничего нет.

Непонятно только, зачем давать "хоть какой-то", если можно нормальный дать?

I>Есть факт — от императивного программирования отказа быть в принципе не может, в силу ряда причин, в частности слишком низком перформансе функциональных языков в низкоуровневых алгоритмах


Да нет, парформанс лапшевого низкоуровневого кода обычно нормальный (если компилировать LLVM/JVM/CLR, а не какими-нибудь студенческими кодогенераторами), проблема в том, что идиоматический код тормозит и многие даже проблемой это не считают, а значит в этом направлении не работают.

Это по другому нужно сформулировать: синтаксис в ФЯ лекгковесен для (и, следовательно, поощряет использование) лямбд, карринга и полиморфизма, все это связано с издержками в смысле перформанса. В сишном синтаксисе за все это обычно дают по рукам на ранних подступах, средствами карательного синтаксиса.
Поэтому вполне можно обосновать громоздкий синтаксис для лямбд, f(a,b,c) синтаксис и страшные аннотации параметрического полиморфизма. Но какая польза от убогого паттерн-матчинга? Компилятор паттерн-матчинга, как правило, дает код лучше того, который бы средний программист написал разбирая какую-то сложную структуру. Зачем за него наказывать?

I>И вот пока что для императивного программирования сишный синтаксис самый сбалансированый. Скажем, идейка выравнивать код отступами интересная, но её массы как то не принимают.


Для меня ужасы сишного синтаксиса — это, в первую очередь, адские типы ссылок на функции/массивов, префиксные аннотации типов и параметры типов с елочками и монструозные свитчи, которые как раз совсем не в духе общей тенденции сишного синтаксиса не злоупотреблять большим кол-вом ключевых слов на строку кода. Ничего этого для императивного программирования не нужно.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[6]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.06.14 13:33
Оценка:
Здравствуйте, Klapaucius, Вы писали:

I>>Тебя не смущает, что самые популярные и востребованые языки, это те, в которых никаких особенных фич то и нет ?


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


Ты плохо прочёл — в этих языках фич практически нет. Отсюда следствие — отсутствие фич не является препятствием, ни разу.

K>Там где требования к качеству реализации низкие (в случае всяких питонов-рубей) языки выглядят совсем иначе и с перечисленными "самыми востребованными" имеют мало общего. Короче говоря, был бы для JVM только интеркол — писали бы на интерколе, просто текучка кадров и заполняемость психлечебниц слегка подскочила бы.


Это голословно. Хорошо бы увидеть какие то жосткие данные на тему "в областях где цена ошибки высока (== цене бизнеса, цене жизни и тд) используется XXX"

Итого, от тебя требуется раскрыть XXX. Лично я сомневаюсь, что там будет доминировать пейтоны-руби-хаскели. Там даже эрланг не будет доминировать, хотя он там точно есть.

I>>Есть другая задача — дать хоть какой то ПМ тем, у кого ничего нет.


K>Непонятно только, зачем давать "хоть какой-то", если можно нормальный дать?


Уже наверное 50 лет дают и никак дать не могут. Функциональщина хронически не лезет в мейнстрим, ну никак.

K>Да нет, парформанс лапшевого низкоуровневого кода обычно нормальный (если компилировать LLVM/JVM/CLR, а не какими-нибудь студенческими кодогенераторами), проблема в том, что идиоматический код тормозит и многие даже проблемой это не считают, а значит в этом направлении не работают.


1 низкоуровневые алгоритмы, если они не на си или не на оптимизированых шаблонах С++ сосут не нагибаясь. Разница в перформансе-потреблении памяти минимум в разы. отсюда ясно, почему обработку изображений никто в своём уме не пишет на функциональных языках.
2 идиоматический код еще сильнее усугубляет проблемы

K>Это по другому нужно сформулировать: синтаксис в ФЯ лекгковесен для (и, следовательно, поощряет использование) лямбд, карринга и полиморфизма, все это связано с издержками в смысле перформанса. В сишном синтаксисе за все это обычно дают по рукам на ранних подступах, средствами карательного синтаксиса.


Сишный синтаксис очень хорош для структур данных, ООП и подобных вещей. Скажем, для описания данных лучше чем JSON не придумаешь.

K>Поэтому вполне можно обосновать громоздкий синтаксис для лямбд, f(a,b,c) синтаксис и страшные аннотации параметрического полиморфизма. Но какая польза от убогого паттерн-матчинга? Компилятор паттерн-матчинга, как правило, дает код лучше того, который бы средний программист написал разбирая какую-то сложную структуру. Зачем за него наказывать?


Убогий паттерн матчинг на порядок лучше его отсутствия.

I>>И вот пока что для императивного программирования сишный синтаксис самый сбалансированый. Скажем, идейка выравнивать код отступами интересная, но её массы как то не принимают.


K>Для меня ужасы сишного синтаксиса — это, в первую очередь, адские типы ссылок на функции/массивов, префиксные аннотации типов и параметры типов с елочками и монструозные свитчи, которые как раз совсем не в духе общей тенденции сишного синтаксиса не злоупотреблять большим кол-вом ключевых слов на строку кода. Ничего этого для императивного программирования не нужно.


"монструозные свитчи" это из за отстутствия даже убогого ПМ. Адские типы ссылок на функции-массивы из за слабого полиморфизма.
Re[8]: Swift
От: Cyberax Марс  
Дата: 04.06.14 14:19
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Нет, это не замена отладчику, это скорее замена всяким приседаниям с "созданием файликов".

А какие приседания? С REPL'ом меня ещё додалбывало то, что его потом сложно снова воспроизвести.

K>РЕПЛ можно использовать совместно с отладчиком — и тогда окружение на брейкпойнте можно "инспектировать" и обрабатывать результат прямо определенной на месте функцией на этом же самом языке.

Ну как бы, новые debugger'ы позволяют запускать код в контексте остановленного потока.
Sapienti sat!
Re[6]: Swift
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.14 14:39
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Nemerlish, насколько я помню, был с самыми зачаточным функционалом, так что пользы от него было немного и не удивительно, что он оказался никому не нужен. Нормальный доделанный РЕПЛ инструмент более серьезный, в нем доступен язык полностью, т.е. можно любые декларации делать, автокомплит есть, интеграция с отладчиком и т.д.


Что с этого всего толку в статически типизированном ООЯ?

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

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

Развивать нужно средства отладки, а не какие-то игрушки.

Оптимальный вариант когда, как в скриптовых языках, программу можно остановить, поправить и продолжить дальше. По объективным причинам для компилируемых статически-типизируемых ООЯ — это сделать крайне сложно. Но сложно не значит невозможно. Так что надо копать в эту сторону.

От репловских же функций нужно иметь возможность выполнить некий код в режиме интерпретатора. Этого более чем достаточно. Писать код в репле — это не лучшая идея. Хорошая IDE все равно будет в разы удобнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Swift
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.06.14 14:45
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Если будет внятный GC, то это лучше C#, Джавы и С++ вместе взятых. Но судя по набору фич язык сильно близко подобрался к Scala и F#


I>И самое главное — Сишный синтаксис !


По первым описаниям — смесь бейсика с Ruby, местами вдохновлённый Питоном и Go. На C никак не похож.
The God is real, unless declared integer.
Re[3]: Swift
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.06.14 15:38
Оценка:
Здравствуйте, D. Mon, Вы писали:

VD>>Убило использование подсчета ссылок без автоматического разруливания за зацикливаний. В 21 веке это выглядит дико. Такому языку нужен GC или хотя бы автоматический поиск зацикливаний, как в Руби.

DM>Как в Питоне, наверное. В Руби испокон веков был честный mark & sweep, никакого RC.

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

DM>В свифте они целились на рантайм-совместимость с Obj-C, а там тот же самый ARC. Трудно было бы добавить честный GC в один язык, не добавив в другой. Ну и скорее всего это дело принципа: обеспечить иллюзию детерминированности и какбы отсутствие тормозов GC, шоб андроид не получился.


Отсутствие концентрированных тормозов можно обеспечить множеством способов, но если их этот устраивает — почему бы и нет...
The God is real, unless declared integer.
Re[10]: Swift
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.14 15:38
Оценка: :)
Здравствуйте, Mamut, Вы писали:

M>Виртуальная реальность — это называть полтора проекта, которые пишут пять людей, реальностью и истиной, которая распространяется на всех.


Я не хочу спорить с твоим бредом. Мне на это жалко время тратить. Верь во что хочешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Swift
От: vdimas Россия  
Дата: 04.06.14 15:40
Оценка:
Здравствуйте, NeoCode, Вы писали:

NC>Странный подход, написано free, в фиг скачаешь без этого вашего тунца. Как они собираются привлекать разработчиков, не имевших до этого дела с эппл?


Создать акк бесплатно.
Re[2]: Swift
От: vdimas Россия  
Дата: 04.06.14 15:58
Оценка:
Здравствуйте, Klapaucius, Вы писали:

I>>замыкания,

K>Это без ГЦ на одном подсчете ссылок? Ну ну.

Это разве не особенность языка, а не реализации?
Re[4]: Swift
От: vdimas Россия  
Дата: 04.06.14 16:01
Оценка:
Здравствуйте, Klapaucius, Вы писали:

I>>90е и 2000 это Java и C#, в которых еще более примитивный switch


K>Я имел в виду, что в 70-е уже "неплоский" изобрели. А на Java и C# чего равняться — в них (языках, не реализациях) фич, изобретенных после 1968-го раз два и обчелся.


Для первой версии рабочего промышленного языка, а не экспериментального и это неплохо.
На редкость удачная первая версия такого, предназначенного для массового использования, языка.
Re[4]: Swift
От: vdimas Россия  
Дата: 04.06.14 16:04
Оценка:
Здравствуйте, netch80, Вы писали:

DM>>В свифте они целились на рантайм-совместимость с Obj-C, а там тот же самый ARC. Трудно было бы добавить честный GC в один язык, не добавив в другой. Ну и скорее всего это дело принципа: обеспечить иллюзию детерминированности и какбы отсутствие тормозов GC, шоб андроид не получился.


N>Отсутствие концентрированных тормозов можно обеспечить множеством способов, но если их этот устраивает — почему бы и нет...


Это дело реализации/компилятора, ИМХО.
Для системных вещей — конечно только подсчет ссылок (да и тот редкость).
А для всяких нетребовательных околоскриптовых — можно будет и ГЦ потом дать.
Re[2]: Swift
От: vdimas Россия  
Дата: 04.06.14 16:08
Оценка: -1 :)))
Здравствуйте, netch80, Вы писали:

I>>Если будет внятный GC, то это лучше C#, Джавы и С++ вместе взятых. Но судя по набору фич язык сильно близко подобрался к Scala и F#

I>>И самое главное — Сишный синтаксис !
N>По первым описаниям — смесь бейсика с Ruby, местами вдохновлённый Питоном и Go. На C никак не похож.

Точно! Эдакий современный продвинутый вариант Бейсика. Безопасный и провоцирующий на эксперименты.

Веселенький, кста. ))
Изучение Rust, к примеру, навевает скуку. А описание Swift хочется читать и читать. Оч положительные эмоции. Особенно, если помнить, что это лишь первая версия языка. Первый промышленный язык, который будет заведомо распространён, и который сходу утер нос C#. ))
Re[2]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.06.14 16:16
Оценка:
Здравствуйте, netch80, Вы писали:

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


I>>Если будет внятный GC, то это лучше C#, Джавы и С++ вместе взятых. Но судя по набору фич язык сильно близко подобрался к Scala и F#


I>>И самое главное — Сишный синтаксис !


N>По первым описаниям — смесь бейсика с Ruby, местами вдохновлённый Питоном и Go. На C никак не похож.


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

Типы указываются постфиксно, щас это модно, например тот же подход в TypeScript

struct FixedLengthRange {
    var firstValue: Int
    let length: Int
}



Наследование

class SomeClass: SomeSuperclass {
    // class definition goes here
}



Не ясно, что здесь от бейсика и руби

Или вот

struct Fahrenheit {
    var temperature: Double
    init() {
        temperature = 32.0
    }
}
var f = Fahrenheit()
println("The default temperature is \(f.temperature)° Fahrenheit")


Или так
var namesOfIntegers = Dictionary<Int, String>()


отсутствие new это радикальное отличие ?

Вот операторы
class Counter {
    var count = 0
    func increment() {
        count++
    }
    func incrementBy(amount: Int) {
        count += amount
    }
    func reset() {
        count = 0
    }
}



Вот всякие цыклы — там единственная вещь это отсутствие одной пары скобочек.
Re[3]: Swift
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 04.06.14 17:30
Оценка: +2 :)
Здравствуйте, vdimas, Вы писали:

V>Первый промышленный язык, который будет заведомо распространён, и который сходу утер нос C#. ))


Смишно. Распространенный язык, недоступный на линуксе и винде.
Что до носа C#, то вот простейший вопрос: напиши на свифте генерик-функцию, работающую с разными линейными контейнерами (массив, два вида списков, deque). Скажем, на входе контейнер с интами, найти минимум из первых 10 положительных чисел. Второй вопрос: добавить свой контейнер и чтобы эта функция без изменений с ним заработала.
Re[3]: Swift
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.06.14 17:40
Оценка: +1
Здравствуйте, vdimas, Вы писали:

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


V>Первый промышленный язык, который будет заведомо распространён, и который сходу утер нос C#. ))


У вас, сударь, на лицо apple головного мозга.
Re[4]: Swift
От: vdimas Россия  
Дата: 04.06.14 18:12
Оценка: :))
Здравствуйте, D. Mon, Вы писали:

V>>Первый промышленный язык, который будет заведомо распространён, и который сходу утер нос C#. ))

DM>Смишно. Распространенный язык, недоступный на линуксе и винде.

А какая разница разработчикам под семейство макосей на этот довод?
Он всё-равно сходу будет более распространён как инструмент написания коробочных продуктов, чем тот же C#.

DM>Что до носа C#, то вот простейший вопрос: напиши на свифте генерик-функцию, работающую с разными линейными контейнерами (массив, два вида списков, deque). Скажем, на входе контейнер с интами, найти минимум из первых 10 положительных чисел. Второй вопрос: добавить свой контейнер и чтобы эта функция без изменений с ним заработала.


Это намек на IEnumerable<IComparable>?
Самому не смишно?
Re[4]: Swift
От: vdimas Россия  
Дата: 04.06.14 18:22
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Что до носа C#, то вот простейший вопрос: напиши на свифте генерик-функцию, работающую с разными линейными контейнерами (массив, два вида списков, deque). Скажем, на входе контейнер с интами, найти минимум из первых 10 положительных чисел. Второй вопрос: добавить свой контейнер и чтобы эта функция без изменений с ним заработала.


Кароч, облом ждать очередной итерации пинг-понга в сообщениях.
Ты привел сценарий, когда дотнет генерит в рантайм код под value-type как аргументы генериков.

Теперь, если включить мозг (просто понять целевую платформу и её философию) — самому не смешно?
Ничего подобного в промышленном инструментарии под коробочные продукты под эту ось и под приложения для самой оси (и даже для написания запчастей этой оси) никогда не будет, ес-но.

Тут можно ожидать только подвижки в ту же сторону, в которую идет обобщенное программирование в С++.
Re[9]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.06.14 18:54
Оценка:
Здравствуйте, Cyberax, Вы писали:

K>>Нет, это не замена отладчику, это скорее замена всяким приседаниям с "созданием файликов".

C>А какие приседания? С REPL'ом меня ещё додалбывало то, что его потом сложно снова воспроизвести.

Repl сложно воспроизвести, если ты намодифицировал всего подряд и функции у тебя кругом модифицирующие.
Re[3]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.06.14 18:57
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Точно! Эдакий современный продвинутый вариант Бейсика. Безопасный и провоцирующий на эксперименты.


V>Веселенький, кста. ))

V>Изучение Rust, к примеру, навевает скуку. А описание Swift хочется читать и читать. Оч положительные эмоции. Особенно, если помнить, что это лишь первая версия языка. Первый промышленный язык, который будет заведомо распространён, и который сходу утер нос C#. ))

Ого, у тебя, оказывается, есть информация из будущего.

Свифт предлагает очень много фич разом. Есть большой шанс, что сообщество обжективных разрабов, которое консервативное донельзя, просто не примет. Так что вполне можно ожидать сценарий "с места и в лужу".
Re[5]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.06.14 19:01
Оценка:
Здравствуйте, vdimas, Вы писали:

V>А какая разница разработчикам под семейство макосей на этот довод?

V>Он всё-равно сходу будет более распространён как инструмент написания коробочных продуктов, чем тот же C#.

DM>>Что до носа C#, то вот простейший вопрос: напиши на свифте генерик-функцию, работающую с разными линейными контейнерами (массив, два вида списков, deque). Скажем, на входе контейнер с интами, найти минимум из первых 10 положительных чисел. Второй вопрос: добавить свой контейнер и чтобы эта функция без изменений с ним заработала.


V>Это намек на IEnumerable<IComparable>?

V>Самому не смишно?

Это намёк на экстеншны, предсказуемый полиморфизм, обобщенное программирование и особенности дизайна базовых классов. Вот скажем если в свифте контейнеры никто не задизайнит внятно, то от экстеншнов толку будет крайне мало.
Re[5]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.06.14 19:03
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Кароч, облом ждать очередной итерации пинг-понга в сообщениях.

V>Ты привел сценарий, когда дотнет генерит в рантайм код под value-type как аргументы генериков.

А в огороде бузина.

V>Теперь, если включить мозг (просто понять целевую платформу и её философию) — самому не смешно?

V>Ничего подобного в промышленном инструментарии под коробочные продукты под эту ось и под приложения для самой оси (и даже для написания запчастей этой оси) никогда не будет, ес-но.

Забудь про то, что и как делается в рантайме. Главное, что в компайл-тайм в C# у тебя есть определенные инструменты — полиморфизм, обобщенное программирование, внятный дизайн контейнеров и экстеншны. Как они работают в рантайме — никому не интересно. Вопрос не про это.
Re[3]: Типы постфиксно
От: Qbit86 Кипр
Дата: 04.06.14 20:18
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Типы указываются постфиксно, щас это модно, например тот же подход в TypeScript


Это сто лет как модно, и используется в большом количестве не Си-подобных языков: F#, OCaml, Scala, Nemerle, ActionScript, etc. Не говоря уже о теории типов и языков программирования.
Глаза у меня добрые, но рубашка — смирительная!
Re[6]: Swift
От: andyag  
Дата: 04.06.14 20:28
Оценка:
Здравствуйте, Mamut, Вы писали:

A>>>>На самом деле, это скорее ВАУ фича, чем что-либо полезное. Те примеры что есть, скорее всего масксимум возможностей и показывают, а именно простые однопоточные приложения с простой моделью данных.

M>>>Ну, на самом деле я на это дело смотрю, как на приятный расширенный REPL
C>>Мне вот всегда было интересно зачем REPL нужен...

M>Это очень удобный инструмент. Как для быстрого прототипирования и проверки некоторых идей, так и для быстрого тестирования некоторых вещей


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

Насчёт прототипирования вообще мысль не понял. ИМХО, единственное удачное применение REPL — это когда к запущенному приложению можно подключиться через какой-нибудь SSH и пощупать как у него дела дёргая всякие методы всяких объектов.
Re: Swift
От: andyag  
Дата: 04.06.14 20:40
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>https://itunes.apple.com/gb/book/swift-programming-language/id881256329?mt=11


I>Apple родила язык.


Я ненавижу Swift уже за то, что он у меня вчера в ньюсфиде встретился не менее 8 раз.

Ещё один язык, который работает на сильно ограниченном наборе платформ. Ещё один язык со своим уникальным и самым лучшим синтаксисом. Ещё один язык, который теперь в вакансиях сначала будет "крайне приветствуется", а потом "необходимо знать: Objective C, Objective C++, Swift". Ещё один язык, который будет иметь ненулевую популярность, просто потому что хипстеры.

1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два.
2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых.
3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии.
Re[2]: Swift
От: Cyberax Марс  
Дата: 04.06.14 20:51
Оценка:
Здравствуйте, andyag, Вы писали:

A>1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два.

Это Apple. Они могут — Carbon API они таки запретили, хотя им пользовались такие гиганты как Photoshop.

A>2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых.

A>3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии.
То есть? Рефлексию несложно добавить — это же LLVM. Аналогично, поддержка остальных платформ (в том числе Windows) скорее зависит от того, чтобы кто-то не поленился сделать сборку для них.
Sapienti sat!
Re[3]: Swift
От: Qbit86 Кипр
Дата: 04.06.14 20:56
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Аналогично, поддержка остальных платформ (в том числе Windows) скорее зависит от того, чтобы кто-то не поленился сделать сборку для них.


Сомневаюсь. Сборку не то, чтобы поленятся сделать, просто побоятся судебных преследований со стороны Apple. Вспомнят неприятную историю про преследование Гугла Ораклом.
Глаза у меня добрые, но рубашка — смирительная!
Re[4]: Swift
От: Cyberax Марс  
Дата: 04.06.14 21:03
Оценка:
Здравствуйте, Qbit86, Вы писали:

C>>Аналогично, поддержка остальных платформ (в том числе Windows) скорее зависит от того, чтобы кто-то не поленился сделать сборку для них.

Q>Сомневаюсь. Сборку не то, чтобы поленятся сделать, просто побоятся судебных преследований со стороны Apple. Вспомнят неприятную историю про преследование Гугла Ораклом.
Ну вообще-то, в том судебном процессе победил Гугл. И всё зависит от лицензии, под которой Apple сделает доступным компилятор.
Sapienti sat!
Re[5]: Swift
От: Qbit86 Кипр
Дата: 04.06.14 21:06
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну вообще-то, в том судебном процессе победил Гугл.


В последнем на данный момент раунде (насколько мне известно) побеждает Оракл: «Аппеляционный суд США постановил: Oracle обладает авторским правом на части языка программирования Java, использованные Google при разработке ОС Android».
Глаза у меня добрые, но рубашка — смирительная!
Re[6]: Swift
От: Cyberax Марс  
Дата: 04.06.14 21:08
Оценка: 9 (1)
Здравствуйте, Qbit86, Вы писали:

C>>Ну вообще-то, в том судебном процессе победил Гугл.

Q>В последнем на данный момент раунде (насколько мне известно) побеждает Оракл: «Аппеляционный суд США постановил: Oracle обладает авторским правом на части языка программирования Java, использованные Google при разработке ОС Android».
Нет, аппеляционный суд не согласился с некоторыми интерпретациями закона в решении. Теперь дело пойдёт по второму кругу, об окончательной победе Оракла пока речи нет.
Sapienti sat!
Re[7]: Некоторые интерпретации закона
От: Qbit86 Кипр
Дата: 04.06.14 21:12
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Аналогично, поддержка остальных платформ (в том числе Windows) скорее зависит от того, чтобы кто-то не поленился сделать сборку для них.

C>Нет, аппеляционный суд не согласился с некоторыми интерпретациями закона в решении.

А, ну тогда ок; «кто не поленился» может спокойно брать и реализовывать компилятор языка на Windows.
Глаза у меня добрые, но рубашка — смирительная!
Re[7]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.06.14 22:01
Оценка: +1
Здравствуйте, andyag, Вы писали:

A>"Для быстрого тестирования некоторых вещей" достаточно не бояться писать тесты в любых их вариациях: юнит тесты, интеграционные тесты, учебные тесты, воспроизводилки интересных сценариев. Ключевое слово — воспроизводимость.


И запускать эти тесты надо полагать, придется на боевой системе ?

A>Насчёт прототипирования вообще мысль не понял. ИМХО, единственное удачное применение REPL — это когда к запущенному приложению можно подключиться через какой-нибудь SSH и пощупать как у него дела дёргая всякие методы всяких объектов.


Эта хрень дает возможности сократить на прядок другой количество перезапусков приложения. Если для каждого перезапуска надо собирать пекадж или делать деплоймент, то разница просто сумасшедшая.
Re[2]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.06.14 22:06
Оценка:
Здравствуйте, andyag, Вы писали:

A>Ещё один язык, который работает на сильно ограниченном наборе платформ. Ещё один язык со своим уникальным и самым лучшим синтаксисом. Ещё один язык, который теперь в вакансиях сначала будет "крайне приветствуется", а потом "необходимо знать: Objective C, Objective C++, Swift". Ещё один язык, который будет иметь ненулевую популярность, просто потому что хипстеры.


И что с того ?

A>1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два.

A>2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых.
A>3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии.

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

Рефлексию легко добавить, и лучше если это будет чуть попозжа. Как вариант, всунуть компайл-тайм рефлексию, шоб сильнее отличиться от дотнета и джавы
Re[6]: Swift
От: vdimas Россия  
Дата: 04.06.14 23:18
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Это намёк на экстеншны, предсказуемый полиморфизм, обобщенное программирование и особенности дизайна базовых классов.


Если речь о принципиальной возможности запрошенного, то это всё не важно.

Система типов в дотнете нифига не предсказуемая. Все эти эффекты от "неожиданного" боксирования или наоборот, от бесполезности изменения полей составных value-объектов, возвращаемых как св-ва, т.е. разница в поведении полей и св-в, разница в поведении оператора [] у встроенных массивов и объектов/интерфейсов, это всё просто россыпь граблей на ровном месте. Причем, даже у С++ есть ср-ва этих граблей избегать, т.е. есть ср-ва приводить семантику обращения с элементами встроенных массивов и юзверских типов-коллекций к чему-то более-менее идентичному, то у дотнета — нет никаких. Нужно тупо помнить о граблях. По-настоящему смешно в либах дотнета становится внутри кода генериков, когда первой строчкой идет попытка динамического приведения аргумента-коллекции к массиву и затем ветвление алгоритма в зависимости от успешности приведения. Криво это всё до невозможности.
Re[6]: Swift
От: vdimas Россия  
Дата: 04.06.14 23:19
Оценка:
Здравствуйте, Ikemefula, Вы писали:

V>>Кароч, облом ждать очередной итерации пинг-понга в сообщениях.

V>>Ты привел сценарий, когда дотнет генерит в рантайм код под value-type как аргументы генериков.
I>А в огороде бузина.

ы?


V>>Теперь, если включить мозг (просто понять целевую платформу и её философию) — самому не смешно?

V>>Ничего подобного в промышленном инструментарии под коробочные продукты под эту ось и под приложения для самой оси (и даже для написания запчастей этой оси) никогда не будет, ес-но.

I>Забудь про то, что и как делается в рантайме. Главное, что в компайл-тайм в C# у тебя есть определенные инструменты — полиморфизм, обобщенное программирование, внятный дизайн контейнеров и экстеншны. Как они работают в рантайме — никому не интересно. Вопрос не про это.


Так ты не понял прикола с исходным вопросом? А чего тогда влез? ))
Re[4]: Swift
От: vdimas Россия  
Дата: 04.06.14 23:48
Оценка:
Здравствуйте, Ikemefula, Вы писали:

V>>Веселенький, кста. ))

V>>Изучение Rust, к примеру, навевает скуку. А описание Swift хочется читать и читать. Оч положительные эмоции. Особенно, если помнить, что это лишь первая версия языка. Первый промышленный язык, который будет заведомо распространён, и который сходу утер нос C#. ))

I>Ого, у тебя, оказывается, есть информация из будущего.


Конечно. Бывает такое будущее, которое результат прошлого и настоящего. Например, дав нам вменяемый интероп с нейтивом, COM и ActiveX дотнет когда-то предрек своё будущее уже в первой же бете. Вашему покорному слуге стало всё понятно еще тогда, кароч, поэтому взялся за него активно с первых же бет. До сих пор популярный для меня тул, не взирая на столь медленное выполнение других, более ожидаемых обещаний от технологии. Скажем так, я еще не списал насовсем дотнет со своих счетов, но у него уже нет той форы, что 12 лет назад... время упущено, нейтив по своим фишкам и выразительности начинает ощутимо поджимать, увы и ах. ))


I>Свифт предлагает очень много фич разом. Есть большой шанс, что сообщество обжективных разрабов, которое консервативное донельзя, просто не примет. Так что вполне можно ожидать сценарий "с места и в лужу".


А твоё "будущее" Swift выглядит так, буд-то у него не было ни прошлого, ни настоящего. Или есть большой шанс, что с объектным-С ты сталкивался не ближе, чем издалека. Кароч, всё там будет хорошо, просто поверь. Слишком долго расписывать "почему" для того, кто далек от темы. Представь, что это как дотнет для старого COM и OLE-автоматизации. Причем, в лучшем его виде, как это было в VB.Net изначально или в C# только после прикручивания dynamic. Только еще удобнее, бо никакого dynamic и совместимость по типам на порядки более гладкая, чем дотнетные типы и OLE (вернее, совместимость фактически бесшовная, в отличие от ограничений дотнетного маршаллинга). Да и сам язык на порядок мощнее, чем первый C#, который был калькой с тупейшей джавы. В некоторых местах удобнее даже, чем нынешний пятый C#. Некоторые фишки языка откровенно улыбнули. Всё-таки в яблоках работают романтики... налицо эдакие реализованные "мечты детства" в промышленном языке. Игрища вокруг for и swit/case доставляют. Но вышло всё-таки симпатично. Посмотрим на развитие языка, кароч. Повторюсь, для первой версии настоящего промышленного языка, который сходу начнут использовать сотни тыщ разрабов — это мега-круто, что бы тут кто ни говорил и не пытался замечать недостатки или тем более сравнивать с некими "чистыми"/маргинальными языками.

По-сути, на сегодня Swift должно сравнивать только с последней джавой, последним C# и последними С/С++, с натяжкой еще можно попробовать сравнить с семейством JavaScript (всё-таки там еще серьезнейшие бока даже в статически-компилируемых расширениях). Все остальные языки идут в сад не задерживаясь, бо не дотягивают до мейнстрима, т.е. сравнение с любым другим языком будет чистой воды спекуляцией ни о чем.
Re[13]: Разовью мысль
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.06.14 23:48
Оценка: 15 (1)
Здравствуйте, Mamut, Вы писали:

M>Действительно, ведь все абсолютно упирается в юнит тесты, и все можно решить юнит-тестами


Включай уже голову наконец вместо флеймогенератора. Тест-раннеры могут быть использованы и используются в том числе "как для быстрого прототипирования и проверки некоторых идей, так и для быстрого тестирования некоторых вещей".
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[5]: Swift
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 05.06.14 02:44
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Это намек на IEnumerable<IComparable>?


Да.

V>Самому не смишно?


Очень, потому что в свифте этого нет! Нет общего протокола у контейнеров, у массива только map/reduce/filter и все. Посему до C# уже не дотягивает, а если вспомнить уникальное(?) умение C# превращать внутренние итераторы во внешние, то свифт и вовсе рядом не валялся. Ни о чем похожем на LINQ iРазработчики могут и не мечтать. Так что расскажи еще раз, чем же он утер нос C#.
Re[5]: Swift
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 05.06.14 02:48
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Кароч, облом ждать очередной итерации пинг-понга в сообщениях.

V>Ты привел сценарий, когда дотнет генерит в рантайм код под value-type как аргументы генериков.
V>Теперь, если включить мозг (просто понять целевую платформу и её философию) — самому не смешно?
V>Ничего подобного в промышленном инструментарии под коробочные продукты под эту ось и под приложения для самой оси (и даже для написания запчастей этой оси) никогда не будет, ес-но.

Ээ. Что, банально работающего полиморфизма и генериков нельзя ждать в "в промышленном инструментарии под коробочные продукты"? Почему?

V>Тут можно ожидать только подвижки в ту же сторону, в которую идет обобщенное программирование в С++.


То, что я спросил, не имеет отношения к value типам и С++. Элементарно решается на куче языков же.
Re[5]: Swift
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 05.06.14 02:54
Оценка: +4 :)
Здравствуйте, vdimas, Вы писали:

V>Ничего подобного в промышленном инструментарии под коробочные продукты под эту ось и под приложения для самой оси (и даже для написания запчастей этой оси) никогда не будет, ес-но.


Хе, да свифт даже "for x in .." для произвольных контейнеров не умеет, лишь для парочки встроенных. Супер язык, чо. Промышленный. Утер. Да.
Re[6]: Swift
От: vdimas Россия  
Дата: 05.06.14 05:33
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Ээ. Что, банально работающего полиморфизма и генериков нельзя ждать в "в промышленном инструментарии под коробочные продукты"? Почему?


Можно, конечно. Но не в том виде, как в C#. У дотнета серьезные ограничения насчет семантики value-type (из-за невозможности обойтись без пина при получении адреса структуры в памяти), куча граблей вокруг всего этого. Вот даже для value-type надо генерить УНИКАЛЬНУЮ реализацию генерика в РАНТАЙМ.... брррр... Это всё далеко за пределами "банально работающего полиморфизма".

Развитие генериков будет идти, конечно, но лишь по пути максимально-эффективного рантайм решения. Думаю, будет помощнее на этапе компиляции. Собсно, повторяюсь.


V>>Тут можно ожидать только подвижки в ту же сторону, в которую идет обобщенное программирование в С++.

DM>То, что я спросил, не имеет отношения к value типам и С++. Элементарно решается на куче языков же.

Еще как имеет. Бо для ссылочных типов этот сценарий покрывается свифтом достаточно хорошо.
Re[6]: Swift
От: vdimas Россия  
Дата: 05.06.14 05:35
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Очень, потому что в свифте этого нет! Нет общего протокола у контейнеров, у массива только map/reduce/filter и все.


Ну тогда мне теперь смешно. Потому что для любой коллекции достаточно некоего foreach c ф-ным типом-аргументом.


DM>Посему до C# уже не дотягивает


У многих языков никаких итераторов в базовой либе нет и даже не требуется: map/fold и усё. ))


DM>а если вспомнить уникальное(?) умение C# превращать внутренние итераторы во внешние, то свифт и вовсе рядом не валялся. Ни о чем похожем на LINQ iРазработчики могут и не мечтать.


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


DM>Так что расскажи еще раз, чем же он утер нос C#.


Фактически всем тем, что есть в нем и нет в C#. Каждая из таких конструкций языка — сугубо утилитарная, сугубо для удобства.
Re[6]: Swift
От: AlexRK  
Дата: 05.06.14 05:59
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Хе, да свифт даже "for x in .." для произвольных контейнеров не умеет, лишь для парочки встроенных. Супер язык, чо. Промышленный. Утер. Да.


Это весьма странно, но ваще в свифте много всяких прикольных фич, он явно принадлежит к новой волне гибридных языков типа Rust, Ceylon, Kotlin, Xtend, а не к уже "старым" C#/Java/etc.
Думаю, с контейнерами все добавят, это же самая первая версия. В дотнете первой версии тоже много чего не было.
Re[6]: Swift
От: vdimas Россия  
Дата: 05.06.14 07:41
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Хе, да свифт даже "for x in .." для произвольных контейнеров не умеет, лишь для парочки встроенных. Супер язык, чо. Промышленный. Утер. Да.


Ты третий раз говоришь одно и то же. Мне трижды отвечать?
Re[4]: Swift
От: vdimas Россия  
Дата: 05.06.14 07:46
Оценка:
Здравствуйте, gandjustas, Вы писали:

V>>Первый промышленный язык, который будет заведомо распространён, и который сходу утер нос C#. ))

G>У вас, сударь, на лицо apple головного мозга.

Это у тебя проблемы с восприятием C#, очевидно.
Re[7]: Swift
От: Klapaucius  
Дата: 05.06.14 07:50
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Ты плохо прочёл — в этих языках фич практически нет. Отсюда следствие — отсутствие фич не является препятствием, ни разу.


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

I>Хорошо бы увидеть какие то жосткие данные на тему "в областях где цена ошибки высока (== цене бизнеса, цене жизни и тд) используется XXX"

I>Итого, от тебя требуется раскрыть XXX. Лично я сомневаюсь, что там будет доминировать пейтоны-руби-хаскели. Там даже эрланг не будет доминировать, хотя он там точно есть.

Не понял, как мы вдруг перешли к "областям, где цена ошибки высока"?

I>Уже наверное 50 лет дают и никак дать не могут. Функциональщина хронически не лезет в мейнстрим, ну никак.


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

K>>Да нет, парформанс лапшевого низкоуровневого кода обычно нормальный (если компилировать LLVM/JVM/CLR, а не какими-нибудь студенческими кодогенераторами), проблема в том, что идиоматический код тормозит и многие даже проблемой это не считают, а значит в этом направлении не работают.


I>1 низкоуровневые алгоритмы, если они не на си или не на оптимизированых шаблонах С++ сосут не нагибаясь. Разница в перформансе-потреблении памяти минимум в разы. отсюда ясно, почему обработку изображений никто в своём уме не пишет на функциональных языках.


Ну вот, вы же сами написали, что все, кроме C и C++. Остальные это ведь не только пара-тройка ФЯ но и бразиллион языков никакого отношения к ФП в основном не имеющих. Как видите, страшный синтаксис им никак не помог. При этом сабж явно не окажется в категории С/C++, а наоборот — в категории "остальные", в которой ФЯ часто смотрятся в смысле производительности очень хорошо.

I>2 идиоматический код еще сильнее усугубляет проблемы


Да, все верно.

I>Сишный синтаксис очень хорош для структур данных, ООП и подобных вещей. Скажем, для описания данных лучше чем JSON не придумаешь.


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

I>Убогий паттерн матчинг на порядок лучше его отсутствия.


Вопрос был в том, зачем делать убогим, если можно не убогим? Что мешает-то?

I>"монструозные свитчи" это из за отстутствия даже убогого ПМ. Адские типы ссылок на функции-массивы из за слабого полиморфизма.


Нет, я не про убогие возможности, а именно про навороченность синтаксиса.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[7]: Swift
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 05.06.14 07:57
Оценка:
Здравствуйте, vdimas, Вы писали:

DM>>Хе, да свифт даже "for x in .." для произвольных контейнеров не умеет, лишь для парочки встроенных. Супер язык, чо. Промышленный. Утер. Да.


V>Ты третий раз говоришь одно и то же.


Это просто дополнение было.

V> Мне трижды отвечать?


Не надо, садись уже, твой ответ услышан. Оказалось, что не сегодняшний свифт утер нос сегодняшнему шарпу, а "свифт через пять лет" вероятно утрет "шарпу 10 лет назад". Ну да, прогресс.
Re[9]: Swift
От: Klapaucius  
Дата: 05.06.14 08:57
Оценка: 18 (1) +3
Здравствуйте, Cyberax, Вы писали:

C>А какие приседания?


Представьте, что у вас интерактивной оболочки нет, всякий раз нужно создавать файл со скриптокодом и запускать его? Вот примерно так же чувствует себя пользователь репла, когда ему предлагают для экспериментирования с кодом "файлики создавать".

C>С REPL'ом меня ещё додалбывало то, что его потом сложно снова воспроизвести.


Да, такие сложности бывают.

C>Ну как бы, новые debugger'ы позволяют запускать код в контексте остановленного потока.


С этого места поподробнее, а то мало ли что кто-то может подразумевать под словами "новый дебаггер".
Возьмем, к примеру, отладчик VS 2013. Это, кстати, пример отладчика интегрированного с REPL-ом, только вот репл там крайне убогий.
В студийном репле есть с некоторых пор автокомплит, что хорошо, вот только пользователя ожидает нешуточный сюрприз.
Остановились на брейкпойнте, начинаем инспектировать код:
items.Last() // пока все хорошо. Кстати, а где приглашение?
5.0
items.Take(2)
{System.Linq.Enumerable.TakeIterator<double>}
    count: 0
    source: null
items.Take(2).ToArray()
{double[2]}
    [0]: 5.0
    [1]: 5.0
items.OrderByDescending(x => x).Take(5).ToArray() // без ToArray выдаст не то, что нужно в 99% случаев.
Expression cannot contain lambda expressions
// все, приехали
Invalid expression term ''
0 // все, приехали
0

"Expression cannot contain lambda expressions", серьезно? Мы в каменном веке что ли?
Как видите, целый букет проблем, как делающая этот репл совершенно неюзабельным, так и просто набор милых штришков.
И это коммерческий продукт, индус триальный флагман, не какая-то студенческая поделка.

Правда, не понятно, если вы вполне одобряете "запускание кода в контексте остановленного потока", то какие вопросы по нужности REPL? Что-то не сходится.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[7]: Swift
От: Klapaucius  
Дата: 05.06.14 11:18
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Что с этого всего толку в статически типизированном ООЯ?


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

Просто не нужно из невостребованности nemerlish-а делать какие-то космические выводы: то, чего обычно ожидают от репл он все равно не делал.

VD>Ну, а если репл интегрирован с отладчиком, то это уже и не репл как бы.


Довольно странное заявление.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[3]: Swift
От: Klapaucius  
Дата: 05.06.14 11:20
Оценка:
Здравствуйте, vdimas, Вы писали:

K>>Это без ГЦ на одном подсчете ссылок? Ну ну.


V>Это разве не особенность языка, а не реализации?


Это такая деталь реализации, которая делает многие фичи языка мало либо вовсе неприменимыми из-за проблемности и костыльности.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[5]: Swift
От: Klapaucius  
Дата: 05.06.14 11:27
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Для первой версии


Такого рода вещи нужно делать сразу, а перепрыгивание пропасти в три версии дает в итоге похожие на палеонтологический музей языки вроде C# в котором есть и лямбды и какое-нибудь недочудо типа анонимного метода.

V>рабочего промышленного языка, а не экспериментального и это неплохо.


Вот только результаты экспериментов в экспериментальных языках он никак не учитывает, т.е. готовит "эксперимент" по очередному ознакомлению лбов индустриальных разработчиков с граблями, обнаруженными десятилетия назад.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[7]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.06.14 11:51
Оценка:
Здравствуйте, vdimas, Вы писали:

I>>Это намёк на экстеншны, предсказуемый полиморфизм, обобщенное программирование и особенности дизайна базовых классов.


V>Если речь о принципиальной возможности запрошенного, то это всё не важно.


Именно это определяет, какой профит будет от языковых фич.

V>Система типов в дотнете нифига не предсказуемая.


Я скипнул, потому что к вопросу не относится.
Re[8]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.06.14 12:19
Оценка: -1
Здравствуйте, Klapaucius, Вы писали:

I>>Ты плохо прочёл — в этих языках фич практически нет. Отсюда следствие — отсутствие фич не является препятствием, ни разу.


K>Нет, вывести такое следствие не из чего. Вот если бы были языки с равными инфраструктурами и сильно различающиеся по фичам — тогда можно было бы какие-то выводы делать.


Хорошая инфраструктура почему то появляется только для самых убогих языков с твоей точки зреня. Тебе самому не смешно ?

I>>Хорошо бы увидеть какие то жосткие данные на тему "в областях где цена ошибки высока (== цене бизнеса, цене жизни и тд) используется XXX"

I>>Итого, от тебя требуется раскрыть XXX. Лично я сомневаюсь, что там будет доминировать пейтоны-руби-хаскели. Там даже эрланг не будет доминировать, хотя он там точно есть.

K>Не понял, как мы вдруг перешли к "областям, где цена ошибки высока"?


А что ты имел ввиду под требованием к качеству реализации ? Эти требования определяются исключительно ценой ошибки, а не применяемым языком.

Скажем, если ты начнешь писать для системы жизнеобеспечения, но это совершенно не значит, что "требования к качеству реализации низкие (в случае всяких питонов-рубей)" @ Klapaucius.

I>>Уже наверное 50 лет дают и никак дать не могут. Функциональщина хронически не лезет в мейнстрим, ну никак.


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


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

I>>1 низкоуровневые алгоритмы, если они не на си или не на оптимизированых шаблонах С++ сосут не нагибаясь. Разница в перформансе-потреблении памяти минимум в разы. отсюда ясно, почему обработку изображений никто в своём уме не пишет на функциональных языках.


K>Ну вот, вы же сами написали, что все, кроме C и C++. Остальные это ведь не только пара-тройка ФЯ но и бразиллион языков никакого отношения к ФП в основном не имеющих. Как видите, страшный синтаксис им никак не помог. При этом сабж явно не окажется в категории С/C++, а наоборот — в категории "остальные", в которой ФЯ часто смотрятся в смысле производительности очень хорошо.


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

I>>Сишный синтаксис очень хорош для структур данных, ООП и подобных вещей. Скажем, для описания данных лучше чем JSON не придумаешь.


K>Довольно странное утвеждение. Описание структур данных в С-подобных языках как раз часто очень многословное и навороченное.


JSON вот как раз из Си-подобного языка вырос.

I>>Убогий паттерн матчинг на порядок лучше его отсутствия.


K>Вопрос был в том, зачем делать убогим, если можно не убогим? Что мешает-то?


Полноценный ПМ можно всунуть только в полноценный ФЯ, со всеми его проблемами — перформансом и потреблением памяти. Это очень дорогая фича.

I>>"монструозные свитчи" это из за отстутствия даже убогого ПМ. Адские типы ссылок на функции-массивы из за слабого полиморфизма.


K>Нет, я не про убогие возможности, а именно про навороченность синтаксиса.


В мейнстриме в код лазят самые разные люди, с разными скилами. Сишный синтаксис это своего рода костыль для таких вот людей, снижает уровень вхождения.
Re[5]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.06.14 12:39
Оценка:
Здравствуйте, vdimas, Вы писали:

V>По-сути, на сегодня Swift должно сравнивать только с последней джавой, последним C# и последними С/С++, с натяжкой еще можно попробовать сравнить с семейством JavaScript (всё-таки там еще серьезнейшие бока даже в статически-компилируемых расширениях). Все остальные языки идут в сад не задерживаясь, бо не дотягивают до мейнстрима, т.е. сравнение с любым другим языком будет чистой воды спекуляцией ни о чем.


Так давай сравним с C# последним. Задачу тебе дали. Какие проблемы ? Ты же намекаешь, что знаком с платформой неиздалека. Какие проблемы написать одну функцию, которая выдаст среднее арифметической для первых 10 элементов и будет универсальна для всех контейнеров.

Это чисто языковая задача + особенности дизайна базовой либы.
Re[6]: Swift
От: vdimas Россия  
Дата: 05.06.14 18:01
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Так давай сравним с C# последним. Задачу тебе дали. Какие проблемы ? Ты же намекаешь, что знаком с платформой неиздалека. Какие проблемы написать одну функцию, которая выдаст среднее арифметической для первых 10 элементов и будет универсальна для всех контейнеров.


Покажешь как на генериках C# посчитать среднее арифметическое для первых 10 элементов типа System.Numerics.Complex?
Re[8]: Swift
От: vdimas Россия  
Дата: 05.06.14 18:03
Оценка:
Здравствуйте, Ikemefula, Вы писали:

V>>Если речь о принципиальной возможности запрошенного, то это всё не важно.

I>Именно это определяет, какой профит будет от языковых фич.

Профит в меньшем кол-ве граблей.

V>>Система типов в дотнете нифига не предсказуемая.

I>Я скипнул, потому что к вопросу не относится.

Наоборот. Я увидел язык без встроенных болезней дотнета. А эти болезни тоже не из космоса взялись, а получились как некий компромисс м/у наличием ГЦ и желанием сделать легковестные value-типы.
Re[6]: Swift
От: vdimas Россия  
Дата: 05.06.14 18:09
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Вот только результаты экспериментов в экспериментальных языках он никак не учитывает, т.е. готовит "эксперимент" по очередному ознакомлению лбов индустриальных разработчиков с граблями, обнаруженными десятилетия назад.


Прям юношеский максимализм какой-то сорри. ))

Конструкции Swift очевидны и легки для понимания. Средний уровень разработчиков современных аппликух — невысок. Разработчики аппликух редко пишут что-то фундаментальное. 90% работы — это завязать воедино библиотеки ГУИ, низлежащие сетевые и графические фреймворки, плюс 10% целевой логики.

В кач-ве подобного "клея" для ОО-фреймворков язык выглядит очень даже подходящим и недвусмысленным по своему синтаксису.
Re[4]: Swift
От: vdimas Россия  
Дата: 05.06.14 18:19
Оценка: -1
Здравствуйте, Klapaucius, Вы писали:

K>Это такая деталь реализации, которая делает многие фичи языка мало либо вовсе неприменимыми из-за проблемности и костыльности.


Ну так в дотнете ограничения на семантику value-type и вся сопутствующая россыпь граблей и непоследовательность семантики встроенных массивов и пользовательских контейнеров взялись, наоборот, от присутствия GC.

Простой пример: object.part1.Bounds.Left = 10;
Семантика зависит от типов part1 и Bounds, в зависимости от того, ссылочные типы или нет.

Характерно, что оптимизирующий компилятор, умеющий смотреть вглубь, такую конструкцию разрулил бы даже на value-типах, бо здесь можно обложить локальными пинами всю операцию присваивания. Но вот сохранить ссылку на структуру без сопутствующего пина объекта-владельца уже нельзя (в некоем другом сценарии, например даже в теле св-ва part1.Bounds при возврате значения). И это тянет за собой целую прорву ограничений семантики и популярных для начинающих разработчиков дотнета граблей вокруг value-типов.

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

========
Справделивости ради — кривизна в семантике не от присутствия только GC, ес-но, а в сочетании с мутабельностью, но это уже совсем другой разговор, не об ООП уж точно.
Re[8]: Swift
От: vdimas Россия  
Дата: 05.06.14 18:26
Оценка:
Здравствуйте, D. Mon, Вы писали:

V>> Мне трижды отвечать?

DM>Не надо, садись уже, твой ответ услышан.

Ты бы лучше ответил предметно там, где о подробностях речь. Я тебе предложил минимум пару вариантов, а ты испарился.


DM>Оказалось, что не сегодняшний свифт утер нос сегодняшнему шарпу, а "свифт через пять лет" вероятно утрет "шарпу 10 лет назад". Ну да, прогресс.


Хм, итераторы GoF vs map/fold, или подача функтора в некий foreach для произвольного контейнера... не факт что тебе вообще следует так сильно настаивать на своём. Реально, в 2014-м сие смешно, попахивает 90-ми годами. Это минус 20 лет в карму C#, если ты будешь настаивать именно на своём способе решения. Хорошо, что в C# уже доступны и другие способы, например, реактивные либы набирают популярность.
Re[7]: Swift
От: vdimas Россия  
Дата: 05.06.14 18:35
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Развивать нужно средства отладки, а не какие-то игрушки.


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

В этом смысле REPL банально удобнее, т.к. уже при установленном некоем окружении позволяет "играть" с ним.
Re[8]: Swift
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.06.14 20:53
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Бывает так, что запуск программы требует время (на всю установку некоего тяжеловесного окружения). Скажем, запуск вижуал-студии.


V>В этом смысле REPL банально удобнее, т.к. уже при установленном некоем окружении позволяет "играть" с ним.


В отладчике можно вызвать функцию, поменять значения и даже изменить код программы. Этого более чем достаточно для отладки. А вот писать большую программу из репла — это утопия.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.06.14 21:16
Оценка:
Здравствуйте, vdimas, Вы писали:

I>>Так давай сравним с C# последним. Задачу тебе дали. Какие проблемы ? Ты же намекаешь, что знаком с платформой неиздалека. Какие проблемы написать одну функцию, которая выдаст среднее арифметической для первых 10 элементов и будет универсальна для всех контейнеров.


V>Покажешь как на генериках C# посчитать среднее арифметическое для первых 10 элементов типа System.Numerics.Complex?


Complex это число, в ём всего две компоненты, действительная и мнимая часть. А речь шла про контейнеры.

если тебя смущает Complex, то для него перегружены операторы, ничего военнго в этом нет.
Re[9]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.06.14 21:17
Оценка:
Здравствуйте, vdimas, Вы писали:

V>>>Если речь о принципиальной возможности запрошенного, то это всё не важно.

I>>Именно это определяет, какой профит будет от языковых фич.

V>Профит в меньшем кол-ве граблей.


Показать это ты не можешь, правильно ? Ну, на задаче про 10 первых чисел в разных контейнерах

V>Наоборот. Я увидел язык без встроенных болезней дотнета. А эти болезни тоже не из космоса взялись, а получились как некий компромисс м/у наличием ГЦ и желанием сделать легковестные value-типы.


Покажи кодом, условие задачи напомнить ?
Re[9]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.06.14 21:28
Оценка:
Здравствуйте, VladD2, Вы писали:

V>>В этом смысле REPL банально удобнее, т.к. уже при установленном некоем окружении позволяет "играть" с ним.


VD>В отладчике можно вызвать функцию, поменять значения и даже изменить код программы. Этого более чем достаточно для отладки. А вот писать большую программу из репла — это утопия.


Отладчик сможет скомпилировать лямбду или макрос ? Крутой, значит, отладчик у Немерле.
Re[9]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.06.14 21:31
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Хм, итераторы GoF vs map/fold, или подача функтора в некий foreach для произвольного контейнера... не факт что тебе вообще следует так сильно настаивать на своём. Реально, в 2014-м сие смешно, попахивает 90-ми годами. Это минус 20 лет в карму C#, если ты будешь настаивать именно на своём способе решения. Хорошо, что в C# уже доступны и другие способы, например, реактивные либы набирают популярность.


Внезапно, в C# foreach может работать и с реактивной коллекцией.
Re[9]: Swift
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 06.06.14 03:25
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Ты бы лучше ответил предметно там, где о подробностях речь. Я тебе предложил минимум пару вариантов, а ты испарился.


Я код просил, а не руками махание. Пока ни строчки не получил.
Re[10]: Swift
От: vdimas Россия  
Дата: 06.06.14 09:00
Оценка: -1
Здравствуйте, D. Mon, Вы писали:

DM>Я код просил, а не руками махание. Пока ни строчки не получил.


Ты пока попросил решение, такое же как где-то. Известная демагогия. Давай задачу целиком.
Re[7]: Swift
От: Klapaucius  
Дата: 06.06.14 09:02
Оценка: -1
Здравствуйте, vdimas, Вы писали:

V>Покажешь как на генериках C# посчитать среднее арифметическое для первых 10 элементов типа System.Numerics.Complex?


using System;
using System.Collections.Generic;
using System.Numerics;
using System.Linq;

namespace DictionaryPassing
{
    public interface CNum<T>
    {
        T Add(T a, T b);
        T FromInt(int a);
    }

    public interface CReal<T> : CNum<T>
    {
        T Div(T a, T b);
    }

    public struct ComplexReal : CReal<Complex>
    {
        public Complex Div(Complex a, Complex b) { return a/b; }
        public Complex Add(Complex a, Complex b) { return a+b; }
        public Complex FromInt(int a) { return new Complex(a,0); }
    }

    static class Utils
    {
        public static T Avg<T, C>(this IEnumerable<T> xs) where C : CReal<T>, new()
        {
            var real = new C();
            var sum = real.FromInt(0);
            var i = 0;
            foreach (var x in xs) 
            {
                sum = real.Add(sum, x);
                i++;
            }
            return real.Div(sum, real.FromInt(i));
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(Enumerable.Repeat(new Complex(1, 1), 100).Take(10).Avg<Complex,ComplexReal>());
        }
    }
}
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[8]: Swift
От: vdimas Россия  
Дата: 06.06.14 09:03
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Так давай сравним с C# последним. Задачу тебе дали. Какие проблемы ? Ты же намекаешь, что знаком с платформой неиздалека. Какие проблемы написать одну функцию, которая выдаст среднее арифметической для первых 10 элементов и будет универсальна для всех контейнеров.


V>>Покажешь как на генериках C# посчитать среднее арифметическое для первых 10 элементов типа System.Numerics.Complex?


I>Complex это число, в ём всего две компоненты, действительная и мнимая часть. А речь шла про контейнеры.

I>если тебя смущает Complex, то для него перегружены операторы, ничего военнго в этом нет.

Ты поставил условие задачи? ОК. Я попросил сначала с тебя обобщенное её решение на генериках для произвольного контейнера. Заодно попросил проверить на аргументе-типе System.Numerics.Complex.

Думаю, ты этого не покажешь. Даже для int.
Re[8]: Swift
От: vdimas Россия  
Дата: 06.06.14 09:16
Оценка:
Здравствуйте, Klapaucius, Вы писали:

V>>Покажешь как на генериках C# посчитать среднее арифметическое для первых 10 элементов типа System.Numerics.Complex?


[известное еще в 2005-м году "решение" скипнуто]

Т.е. ни для типа int, ни для float, double, Complex твоё решение не работает, так?

Тут все заранее знали о чем речь, можно было не плодить YA ICalculator<T> или YA IArithmetic<T>, которым уже по 10 лет в обсуждениях на формах. ))
Я лишь демонстрирую оппонентам их демагогию. Тем более, в первоначальном условии попросили показать работоспособность на встроенном int.

Сразу было известно, что на генериках сие нерешаемо в общем виде для произвольных типов, имеющих переопределенные арифметические операторы.
Зато такая задача решается на шаблонах С++. Я лишь заметил оппонентам, что обобщенное программирование в Swift должно быть ближе к C++, чем к генерикам дотнета. Но они не поняли, похоже. Еще заметил, что для прохода по коллекции не нужны итераторы, если у нас имеется функциональный тип и некий метод коллекции foreach, принимающий функтор/делега в кач-ве аргумента. Этого они тоже не поняли. ))
Re[10]: Swift
От: vdimas Россия  
Дата: 06.06.14 09:16
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Я код просил, а не руками махание. Пока ни строчки не получил.


Кста! Для начала покажи сам.
Вот тебе задача: http://www.rsdn.ru/forum/philosophy/5636901.1
Автор: vdimas
Дата: 05.06.14


Re[9]: Swift
От: Klapaucius  
Дата: 06.06.14 09:26
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Т.е. ни для типа int, ни для float, double, Complex твоё решение не работает, так?


Для Complex работает, для int, float, double пишете имплементации CReal и тоже работать будет.

V>Я лишь демонстрирую оппонентам их демагогию. Тем более, в первоначальном условии попросили показать работоспособность на встроенном int.


В чем демогогия? Какая проблема со "встроенным" int?

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


Наоборот, решаемо и обычно именно так как я показал и решается, в GHC-хаскеле, например.

V>Зато такая задача решается на шаблонах С++. Я лишь заметил оппонентам, что обобщенное программирование в Swift должно быть ближе к C++, чем к генерикам дотнета. Но они не поняли, похоже.


Как что-то хорошее.

V>Еще заметил, что для прохода по коллекции не нужны итераторы, если у нас имеется функциональный тип и некий метод коллекции foreach, принимающий функтор/делега в кач-ве аргумента. Этого они тоже не поняли. ))


В ленивом языке foldr == итератор, все возможности покрываются. В строгом это не так.

Вы давайте, не увиливайте, а решайте задачу D.Mon — я вашу решил.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[11]: Swift
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 06.06.14 09:55
Оценка: 18 (1) :)
Здравствуйте, vdimas, Вы писали:

DM>>Я код просил, а не руками махание. Пока ни строчки не получил.

V>Ты пока попросил решение, такое же как где-то. Известная демагогия. Давай задачу целиком.

Не просил я "такое же как где-то", очнись. Задача уже сформулирована. Впрочем, можешь расслабиться. Похоже, аналог IEnumerable все же есть:
http://schani.wordpress.com/2014/06/03/playing-with-swift/
Re[9]: Swift
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 06.06.14 10:07
Оценка: :)
Здравствуйте, vdimas, Вы писали:

V>Я лишь демонстрирую оппонентам их демагогию. Тем более, в первоначальном условии попросили показать работоспособность на встроенном int.

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

Ты сам развел демагогию. Вопрос был простейший, с интами. Приплетать комплексные числа и обобщать обобщуемое никто не просил.
Кроме того, мне эта задача интересна не в сравнении с C#, а в сравнении с другими современными языками. Если попросить Клапауция решить ее на хаскеле, он тоже скажет "на генериках сие нерешаемо"? Смешно же.

V>Зато такая задача решается на шаблонах С++. Я лишь заметил оппонентам, что обобщенное программирование в Swift должно быть ближе к C++, чем к генерикам дотнета. Но они не поняли, похоже. Еще заметил, что для прохода по коллекции не нужны итераторы, если у нас имеется функциональный тип и некий метод коллекции foreach, принимающий функтор/делега в кач-ве аргумента. Этого они тоже не поняли. ))


Да все мы поняли. Только того метода у свифтовых коллекций нет(?), поэтому это не решение, а словоблудие.
Re[8]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.06.14 10:10
Оценка: +1 -1 :)
Здравствуйте, Klapaucius, Вы писали:

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


V>>Покажешь как на генериках C# посчитать среднее арифметическое для первых 10 элементов типа System.Numerics.Complex?


K>
K>


Ну ты и дал. А больше кода не мог нагнать ?

var items = new [] { new Complex(12, 6), дописать сколько надо, по желанию}; 

Console.Write(items.Take(10).Aggregate(new Complex(0,0), (acc,item) => acc + item));
Re[9]: Swift
От: Klapaucius  
Дата: 06.06.14 10:18
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Ну ты и дал. А больше кода не мог нагнать ?


I>
I>var items = new [] { new Complex(12, 6), дописать сколько надо, по желанию}; 

I>Console.Write(items.Take(10).Aggregate(new Complex(0,0), (acc,item) => acc + item));
I>


Я понял его задачу (и, судя по всему, правильно) как написание обобщенного кода для вычисления среднего. У вас же код — не обобщенный.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[10]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.06.14 10:24
Оценка: -1 :)
Здравствуйте, Klapaucius, Вы писали:

I>>Ну ты и дал. А больше кода не мог нагнать ?


I>>
I>>var items = new [] { new Complex(12, 6), дописать сколько надо, по желанию}; 

I>>Console.Write(items.Take(10).Aggregate(new Complex(0,0), (acc,item) => acc + item));
I>>


K>Я понял его задачу (и, судя по всему, правильно) как написание обобщенного кода для вычисления среднего. У вас же код — не обобщенный.


Мы говорили про контейнеры. Так что смотрия где код не обобщенный. Ты можешь взять любой контейнер, даже реактивный, и пускануть этот же код. Более того, даже если ты напишешь свой контейнер, он сам собой заработает, что очевидно.
Re[9]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.06.14 10:27
Оценка: -1 :)
Здравствуйте, vdimas, Вы писали:

V>Тут все заранее знали о чем речь, можно было не плодить YA ICalculator<T> или YA IArithmetic<T>, которым уже по 10 лет в обсуждениях на формах. ))

V>Я лишь демонстрирую оппонентам их демагогию. Тем более, в первоначальном условии попросили показать работоспособность на встроенном int.

В первоначальном условии было про контейнеры.

V>Зато такая задача решается на шаблонах С++. Я лишь заметил оппонентам, что обобщенное программирование в Swift должно быть ближе к C++, чем к генерикам дотнета. Но они не поняли, похоже. Еще заметил, что для прохода по коллекции не нужны итераторы, если у нас имеется функциональный тип и некий метод коллекции foreach, принимающий функтор/делега в кач-ве аргумента. Этого они тоже не поняли. ))


Все что надо знали и без тебя. Главное, что поняли, так это твою неспособность приводить код.
Re[9]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.06.14 10:29
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Ты поставил условие задачи? ОК. Я попросил сначала с тебя обобщенное её решение на генериках для произвольного контейнера. Заодно попросил проверить на аргументе-типе System.Numerics.Complex.


V>Думаю, ты этого не покажешь. Даже для int.


Я уже показал. Ты не забы, что речь про контейнеры ?

Либу в которой нет внятного дизайна контейнеров, не спасет даже самый лучший язык.
Re[11]: Swift
От: Klapaucius  
Дата: 06.06.14 10:30
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Мы говорили про контейнеры. Так что смотрия где код не обобщенный. Ты можешь взять любой контейнер, даже реактивный, и пускануть этот же код. Более того, даже если ты напишешь свой контейнер, он сам собой заработает, что очевидно.


Ну да, любой контейнер с Complex, а не любой контейнер с числами.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[12]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.06.14 10:34
Оценка: :)
Здравствуйте, Klapaucius, Вы писали:

I>>Мы говорили про контейнеры. Так что смотрия где код не обобщенный. Ты можешь взять любой контейнер, даже реактивный, и пускануть этот же код. Более того, даже если ты напишешь свой контейнер, он сам собой заработает, что очевидно.


K>Ну да, любой контейнер с Complex, а не любой контейнер с числами.


В том то и дело, что речь шла про контейнеры, т.е. IEnumerable и тд. Товарищ просто не знал, как это сделано в Swift и решил перепрыгнуть на проблемы рантайма и другие, которые только ухитрился углядеть.
Re[13]: Swift
От: Klapaucius  
Дата: 06.06.14 10:44
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>В том то и дело, что речь шла про контейнеры, т.е. IEnumerable и тд. Товарищ просто не знал, как это сделано в Swift и решил перепрыгнуть на проблемы рантайма и другие, которые только ухитрился углядеть.


Да я сразу понял, что он контратаковал на другом направлении. Какая разница, если все равно можно решение дать?
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[10]: Swift
От: vdimas Россия  
Дата: 06.06.14 10:47
Оценка:
Здравствуйте, Ikemefula, Вы писали:

V>>Ты поставил условие задачи? ОК. Я попросил сначала с тебя обобщенное её решение на генериках для произвольного контейнера. Заодно попросил проверить на аргументе-типе System.Numerics.Complex.


V>>Думаю, ты этого не покажешь. Даже для int.


I>Я уже показал.


Где?

I>Ты не забы, что речь про контейнеры ?


Речь о чьей-то упертости, а не о контейнерах.
Вы настаиваете на итераторах GoF, а я настаиваю на принятом в функциональном виде способа обхода контейнера. С т.з. подхода итераторов — классика IoC.
Следуя нынешней моде вы в пролете. ))


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


А что первично, либа или язык? ))
Да и вообще, дизайн там достаточный, просто ты не понимаешь как им пользоваться. Шаблонное мышление-с.

Кароч. Мне надоела ваша упертость. Мне прям сейчас некогда ставить виртуалку с новой макосью и разворачивать там среду (на досуге поиграюсь с этим).
Вот тебе аналог контейнера из С++. Использованы только те ср-ва языка, аналоги которых есть в Swift, из описания языка и примеров.
template<T>
class MyContainer {
  vector<T> items_;

public:
  typedef function<bool(T&)> ForEachDelegate;  // returns true to continue enumeration

  void foreach(ForEachDelegate d) {
    for(auto i = items_.begin(); i != items_.end(); ++i)
      if(!d(*i))
        break;
  }
};


Заметь, никакого дизайна контейнера нет. Есть лишь публичный foreach.
Мне расписывать далее решение исходного примера или уже стыдно? ))
Re[10]: Swift
От: Klapaucius  
Дата: 06.06.14 10:54
Оценка: +1 -1 :))
Здравствуйте, D. Mon, Вы писали:

DM>Кроме того, мне эта задача интересна не в сравнении с C#, а в сравнении с другими современными языками.


Откровенно говоря, не вижу особого смысла сравнивать Swift с "современными языками". Всякие Go-Swiftы — это подзадержавшиеся Явы-Шарпы, с ними и имеет смысл сравнивать. Языки вроде окамлов-хаскелей-идрисов — это другие поколения и эпохи, сравнивая с ними можно получить только один ответ: в госвифтах все плохо, ничего нет.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[10]: Swift
От: vdimas Россия  
Дата: 06.06.14 11:09
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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

V>>Т.е. ни для типа int, ни для float, double, Complex твоё решение не работает, так?
K>Для Complex работает, для int, float, double пишете имплементации CReal и тоже работать будет.

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


V>>Я лишь демонстрирую оппонентам их демагогию. Тем более, в первоначальном условии попросили показать работоспособность на встроенном int.

K>В чем демогогия? Какая проблема со "встроенным" int?

Такая же, как с Complex или любым другим типом, имеющим переопределенные операторы (не обязательно арифметические). Не работает "изкаробки". Признаюсь, я удивился, увидев твоё "решение". Т.е. до какой степени надо держать тут всех за дураков, чтобы не понять утверждение о том, почему в C# этого нельзя сделать. Сию тему подробно разжевали еще в первые дни после анонса генериков 10 лет назад. Предлагались разные способы, поболее универсальные, чем твой. Например, многие целевые алгоритмы будут быстрее при явной диспетчеризации по типу аргумента-генерика, например, встроенные типы поддерживают IConvertible, поэтому можно довольно быстро отсечь семейство нужных типов. Для остальных можно попытаться через рефлексию найти переопределенные операторы.

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

K>Наоборот, решаемо и обычно именно так как я показал и решается, в GHC-хаскеле, например.

В случае C# это НЕ обобщенное решение. Ведь для каждого типа, помимо переопределения операторов, надо определить явную специализацию класса-хелпера. Более того, тип класса-хелпера надо затем всегда указывать явно. В твоём Хаскеле ничего этого делать не надо, как и в С++ — всё подхватывается "само".


V>>Зато такая задача решается на шаблонах С++. Я лишь заметил оппонентам, что обобщенное программирование в Swift должно быть ближе к C++, чем к генерикам дотнета. Но они не поняли, похоже.


K>Как что-то хорошее.


??

V>>Еще заметил, что для прохода по коллекции не нужны итераторы, если у нас имеется функциональный тип и некий метод коллекции foreach, принимающий функтор/делега в кач-ве аргумента. Этого они тоже не поняли. ))


K>В ленивом языке foldr == итератор, все возможности покрываются. В строгом это не так.


Какая из возможностей не покрывается?


K>Вы давайте, не увиливайте, а решайте задачу D.Mon — я вашу решил.


1. Ты ничего не решил, готового к использованию изкаробки обобщенного решения так и не было. В дотнете автоматическое решение возможно только на рефлексии, увы.

2. Моё решение тут: http://www.rsdn.ru/forum/philosophy/5637904.1
Автор: vdimas
Дата: 06.06.14

По ссылке объявление типа-контейнера, на котором исходная задача решаема в обобщенном виде и будет работать изкаробки, в отличие от твоего решения.
Опущенную часть решения оставляю для самостоятельной работы, там несложно. ))
Re[12]: Swift
От: vdimas Россия  
Дата: 06.06.14 11:15
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>>>Я код просил, а не руками махание. Пока ни строчки не получил.

V>>Ты пока попросил решение, такое же как где-то. Известная демагогия. Давай задачу целиком.

DM>Не просил я "такое же как где-то", очнись. Задача уже сформулирована.


Очнись сам. Я словесное решение ответил сразу же. Твои проблемы, что ты не понимаешь простых вещей.
Вот тут код: http://www.rsdn.ru/forum/philosophy/5637904.1
Автор: vdimas
Дата: 06.06.14


DM>Впрочем, можешь расслабиться.


Сам с собой разговариваешь? ))

DM>Похоже, аналог IEnumerable все же есть:

DM>http://schani.wordpress.com/2014/06/03/playing-with-swift/

Да пофиг. Задача на Swift легко решаема и без них. И не решаема на C#, если вместо минимального числа попытаться найти среднее.
Re[10]: Swift
От: vdimas Россия  
Дата: 06.06.14 11:24
Оценка:
Здравствуйте, D. Mon, Вы писали:

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


V>>Я лишь демонстрирую оппонентам их демагогию. Тем более, в первоначальном условии попросили показать работоспособность на встроенном int.

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

DM>Ты сам развел демагогию. Вопрос был простейший, с интами. Приплетать комплексные числа и обобщать обобщуемое никто не просил.


Я просил. Тебя. А твой коллега показал, что твой пример — фикция, достаточно было сменить условие с поиска минимального на поиск среднего. И тут ты сел в разгона в лужу. ))) А на Swift решаемы в общем виде оба примера, в отличие от C#.


DM>Кроме того, мне эта задача интересна не в сравнении с C#,


Некрасиво так юлить. )))
Твои же слова были о "сравнении с C# десятилетней давности". Столько пафоса и так громко в лужу.
Че ты такой нервный вообще с этим Swift? Расслабься уже. Не хочешь писать на нём — не пиши. Не понимаешь описания языка — не читай. Не умеешь решать свою же задачу БЕЗ итераторов — не решай... используй только те языки, на которых сможешь решить... какие проблемы?

DM>а в сравнении с другими современными языками. Если попросить Клапауция решить ее на хаскеле, он тоже скажет "на генериках сие нерешаемо"? Смешно же.


На Хаскеле как раз решаемо даже более сложное условие (с арифметическими вычислениями которое). Причем, решаемо и работает изкаробки, в отличие от порнографии на C#.

V>>Зато такая задача решается на шаблонах С++. Я лишь заметил оппонентам, что обобщенное программирование в Swift должно быть ближе к C++, чем к генерикам дотнета. Но они не поняли, похоже. Еще заметил, что для прохода по коллекции не нужны итераторы, если у нас имеется функциональный тип и некий метод коллекции foreach, принимающий функтор/делега в кач-ве аргумента. Этого они тоже не поняли. ))


DM>Да все мы поняли. Только того метода у свифтовых коллекций нет(?), поэтому это не решение, а словоблудие.


В твоём условии речь была о именно о пользовательской коллекции. Ты по ссылке ходил или как? Не надоело в лужу падать-то?
Re[13]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.06.14 11:42
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Очнись сам. Я словесное решение ответил сразу же. Твои проблемы, что ты не понимаешь простых вещей.

V>Вот тут код: http://www.rsdn.ru/forum/philosophy/5637904.1
Автор: vdimas
Дата: 06.06.14


О, круто, в Swift появилась поддержка шаблонов С++. Любопытная идейка.
Re[14]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.06.14 11:45
Оценка:
Здравствуйте, Klapaucius, Вы писали:

I>>В том то и дело, что речь шла про контейнеры, т.е. IEnumerable и тд. Товарищ просто не знал, как это сделано в Swift и решил перепрыгнуть на проблемы рантайма и другие, которые только ухитрился углядеть.


K>Да я сразу понял, что он контратаковал на другом направлении. Какая разница, если все равно можно решение дать?


Представь себе, ты продавил банан на Химмельсдорфе и остаётся захватить базу. Противник пытается контратаковать на железной дороге. Ты предлагаешь бросить захват ?
Re[11]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.06.14 12:10
Оценка:
Здравствуйте, vdimas, Вы писали:

I>>Ты не забы, что речь про контейнеры ?


V>Речь о чьей-то упертости, а не о контейнерах.

V>Вы настаиваете на итераторах GoF, а я настаиваю на принятом в функциональном виде способа обхода контейнера. С т.з. подхода итераторов — классика IoC.
V>Следуя нынешней моде вы в пролете. ))

Ты предлагаешь игнорировать встроеные операторы ? А что еще ты предлагаешь игнорироват в таком классном языке ?

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


V>Кароч. Мне надоела ваша упертость. Мне прям сейчас некогда ставить виртуалку с новой макосью и разворачивать там среду (на досуге поиграюсь с этим).


Вот как поиграешь, так с кодом и приходи. За тобой, кстати , должок — два примера кода для демонстрации асинхронщины с прошлой осени, тех самых "студенту на пару часов".
Re[11]: Swift
От: Klapaucius  
Дата: 06.06.14 12:13
Оценка:
Здравствуйте, vdimas, Вы написали серию искрометных разоблачений.

V>Не работает обобщенное решение для Complex, как и для остальных типов. К каждому типу нужно сделать копипасту необобщенного аналога твоего ComplexReal. В итоге, сама обобщенность решения теряет смысл — точно такой же копипастой можно решать исходную задачу без всяких генериков.


Все пропало: ad-hoc полиморфизм не имеет смысла: оказывается, что зависимый от типа код — это просто копипаста и вместо написания всяких имплементаций тайпклассов можно просто копипастить — то на то и получится!

V>Такая же, как с Complex или любым другим типом, имеющим переопределенные операторы (не обязательно арифметические). Не работает "изкаробки". Признаюсь, я удивился, увидев твоё "решение". Т.е. до какой степени надо держать тут всех за дураков, чтобы не понять утверждение о том, почему в C# этого нельзя сделать. Сию тему подробно разжевали еще в первые дни после анонса генериков 10 лет назад.


Все пропало: параметрический полиморфизм не нужен — это разжевали еще 10 лет назад!

V>Предлагались разные способы, поболее универсальные, чем твой. Например, многие целевые алгоритмы будут быстрее при явной диспетчеризации по типу аргумента-генерика,


Что, разумеется невозможно при параметрическом полиморфизме, и не совместимо с параметричностью. т.е. либо динамическая безтипизация, либо недозавтипы (хотя-бы GADTы или "язык модулей"), либо шаблонизатор для кода с "текстовой" подстановкой.
Единственный способ "диспетчеризации" по типу при обычном параметрическом полиморфизме в моем примере и продемонстрирован.

V>В случае C# это НЕ обобщенное решение. Ведь для каждого типа, помимо переопределения операторов, надо определить явную специализацию класса-хелпера.


Решение обобщенное, что очевидно следует из типа Avg:

T Avg<T, C>(this IEnumerable<T> xs) where C : CReal<T>, new()


"Явную специализацию класса хелпера" написать конечно надо. Она и в том же хаскеле написана.

V>Более того, тип класса-хелпера надо затем всегда указывать явно.


Это точно, но автоподстановка словарей далеко не везде есть, шарп не один такой инвалид.

V>В твоём Хаскеле ничего этого делать не надо,


Подставлять словари самому не надо, а писать их конечно надо (если они сами не выводятся, но и дотнете можно словари генерировать всякими костыльными способами)

V>как и в С++ — всё подхватывается "само".


В С++ подхватываться нечему, там ни параметрического полиморфизма, ни передачи словаря нет.

K>>Как что-то хорошее.

V>??

Как будто то, "что обобщенное программирование в Swift должно быть ближе к C++" — это что-то хорошее.

V>Какая из возможностей не покрывается?


"Продуктивность" свертки, например. Ей нельзя управлять, просто потребляя результат (для чего итератор и нужен). Впрочем, с помощью континьюейшенов можно некий воркараунд накостылить.

V>1. Ты ничего не решил, готового к использованию изкаробки обобщенного решения так и не было. В дотнете автоматическое решение возможно только на рефлексии, увы.


Потому, что дотнетные разработчики (а точнее, принимающие решения) не читатели и не моргнув глазом пустили в свободное плаванье дизайнерское решение, которое целый фрактал проблем порождает. При этом то, что решение проблемное на тот момент было известно лет 30 и лет 25 как проблемы были решены. Разумеется, этого никто не заметил, пока ручка грабель не ознакомила с ними индустриального разработчика.
Проблема тут не в параметрическом полиморфизме, а в ограничении квантификации с помощью интерфейсов.
Причем в этих пресловутых спорах "10 лет назад" им противостояли сторонники аналогичного костыльного носолюшена, что могло бы быть даже смешным, если бы не было грустным.
Но нормальное решение можно закодировать таким вот костыльным образом. Собственно, всякие костыльные воркараунды — единственные способы писать обобщенный код в индус триальных языках, их разработчики же думают не о том, как обобщенный код писать, а о том, как притянуть за уши какой-нибудь треш-угар вроде "знакомого практикам" наследования или шаблонизирования/подстановки туда, где без них только лучше будет.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[8]: Swift
От: Нахлобуч Великобритания https://hglabhq.com
Дата: 06.06.14 12:25
Оценка: 23 (2) -1 :)
Здравствуйте, Klapaucius, Вы писали:

V>>Покажешь как на генериках C# посчитать среднее арифметическое для первых 10 элементов типа System.Numerics.Complex?


Кода-то сколько!

private static T Average<T>(IEnumerable<T> items, Func<T, T, T> add, Func<T, int, T> divide)
{
    var count = 0;
    var sum = items.Aggregate(default(T), (i, j) => { count++; return add(i, j); });
    
    return divide(sum, count);
}
        
[Test]
public void Test()
{
    var items = new [] { new Complex(1, 2), new Complex(2, 3) };
    var average = Average(items, (i, j) => i + j, (v, n) => v / n);
}
HgLab: Mercurial Server and Repository Management for Windows
Re[9]: Swift
От: Klapaucius  
Дата: 06.06.14 12:56
Оценка:
Здравствуйте, Нахлобуч, Вы писали:
Н>
Н>private static T Average<T>(IEnumerable<T> items, Func<T, T, T> add, Func<T, int, T> divide)
Н>{
Н>    var count = 0;
Н>    var sum = items.Aggregate(default(T), (i, j) => { count++; return add(i, j); });
    
Н>    return divide(sum, count);
Н>}
        
Н>[Test]
Н>public void Test()
Н>{
Н>    var items = new [] { new Complex(1, 2), new Complex(2, 3) };
Н>    var average = Average(items, (i, j) => i + j, (v, n) => v / n);
Н>}
Н>


Самое главное — словарь не используется повторно (по замыслу, это просто часть реализации Complex), а пишется по месту.
Кроме того: замучаетесь всю арифметику по одной функции передавать, да и лямбды не инлайнятся.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[10]: Swift
От: Нахлобуч Великобритания https://hglabhq.com
Дата: 06.06.14 13:03
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Самое главное — словарь не используется повторно (по замыслу, это просто часть реализации Complex), а пишется по месту.


Какой словарь?
HgLab: Mercurial Server and Repository Management for Windows
Re[12]: Swift
От: vdimas Россия  
Дата: 06.06.14 14:00
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Вот как поиграешь, так с кодом и приходи.


Использованы только те ср-ва языка, аналоги которых есть в Swift, из описания языка и примеров.



I>За тобой, кстати , должок — два примера кода для демонстрации асинхронщины с прошлой осени, тех самых "студенту на пару часов".


Чего-чего? Там были все демонстрации.

Просто ты так и не смог поставить условие задачи. А которое поставил — тебе показали минимум дважды. Тебе не понравилось? — твои проблемы.
Более того, так и не понял принципы работы разных диспетчеров аснхронщины и вообще как она работает. ))
Re[8]: Swift
От: andyag  
Дата: 06.06.14 14:24
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


A>>"Для быстрого тестирования некоторых вещей" достаточно не бояться писать тесты в любых их вариациях: юнит тесты, интеграционные тесты, учебные тесты, воспроизводилки интересных сценариев. Ключевое слово — воспроизводимость.


I>И запускать эти тесты надо полагать, придется на боевой системе ?


Там чуть выше по треду описан контекст. Ни про какие боевые системы и самоотверженных девопсов речи не было: "для быстрого тестирования некоторых вещей".

A>>Насчёт прототипирования вообще мысль не понял. ИМХО, единственное удачное применение REPL — это когда к запущенному приложению можно подключиться через какой-нибудь SSH и пощупать как у него дела дёргая всякие методы всяких объектов.


I>Эта хрень дает возможности сократить на прядок другой количество перезапусков приложения. Если для каждого перезапуска надо собирать пекадж или делать деплоймент, то разница просто сумасшедшая.


Расскажите пожалуйста какой-то юзкейз, отдалённо похожий на реальный мир.
Re[13]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.06.14 15:08
Оценка:
Здравствуйте, vdimas, Вы писали:

I>>За тобой, кстати , должок — два примера кода для демонстрации асинхронщины с прошлой осени, тех самых "студенту на пару часов".


V>Чего-чего? Там были все демонстрации.


Не было. Последняя твоя отписка была вот такой: "нициализируешь локальную переменную и вперед далее вниз по правилам процедурной/функциональной декомпозиции"

Здесь, судя по всему, такая же история
Re[4]: Swift
От: alex_public  
Дата: 06.06.14 15:15
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Смишно. Распространенный язык, недоступный на линуксе и винде.


Ну т.к. там llvm и есть возможность подключать библиотеки на C, то не вижу никаких проблем для кроссплатформенности, даже если Apple не захочет. Другое дело, что если они не захотят, то скорее всего не будет мощного развития инструментов на других платформах (т.е. будет расклад как у D на всех платформах), а наличие такой поддержки является одним из важных бонусов Swift'a...

DM>Что до носа C#, то вот простейший вопрос: напиши на свифте генерик-функцию, работающую с разными линейными контейнерами (массив, два вида списков, deque). Скажем, на входе контейнер с интами, найти минимум из первых 10 положительных чисел. Второй вопрос: добавить свой контейнер и чтобы эта функция без изменений с ним заработала.


Хгм, не ожидал от тебя такого вопроса. Ты же знаешь, что в том же D (да и в C++ и ещё много где) вопросы подобных контейнеров решаются в стандартной библиотеке (описание которой для Swift'a никто из нас тут ещё не видел), а не в конструкциях самого языка. От языка то собственно вообще практически ничего не требуется, максимум какой-то инструмент для поддержки foreach от произвольных коллекций (и такое есть — ты сам показал по ссылке ниже). Так что не вижу вообще никакого смысла обсуждать подобные вопросы, не держа перед глазами описание стандартной библиотеки Swift'a.

Кстати, а документация у них реально очень сомнительная. Я внимательно изучил все разделы здесь https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ и не нашёл ни слова про указатели. Я естественно подумал что их и нет (т.е. не очень хорошо для основного языка платформы). А потом неожиданно обнаружил их вообще здесь https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/ в разделе "взаимодействие с C кодом". Кстати, там же обнаружился и аналог version из D, правда при этом с синтаксисом макросов C++. )))

P.S. Eсли бы в Swift'е было мощное метапрограммирование (кстати, его ещё не поздно добавить с помощью макросов) и Apple дала бы обещание поддерживать его не только под свои платформы, то на мой вкус такой язык стал бы даже поинтереснее D... Ну а пока что D мне всё же нравится больше. Но это мой специфичный вкус (не боюсь сложного кода, бывающего в МП), а для очень многих Swift может выглядеть идеалом уже даже и такой.
Re[9]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.06.14 15:15
Оценка:
Здравствуйте, andyag, Вы писали:

A>>>"Для быстрого тестирования некоторых вещей" достаточно не бояться писать тесты в любых их вариациях: юнит тесты, интеграционные тесты, учебные тесты, воспроизводилки интересных сценариев. Ключевое слово — воспроизводимость.


I>>И запускать эти тесты надо полагать, придется на боевой системе ?


A>Там чуть выше по треду описан контекст. Ни про какие боевые системы и самоотверженных девопсов речи не было: "для быстрого тестирования некоторых вещей".


Как тестировать мой код, все понятно. А вот как тестировать интеграцию с системой, т.е. нативными решения, вот это поинтереснее.

I>>Эта хрень дает возможности сократить на прядок другой количество перезапусков приложения. Если для каждого перезапуска надо собирать пекадж или делать деплоймент, то разница просто сумасшедшая.


A>Расскажите пожалуйста какой-то юзкейз, отдалённо похожий на реальный мир.


Например меня есть мобильное приложение. Есть баг, который воспроизводится в релизной версии, но не воспроизводится в девелоперской. Я подключаю отладчик и если в нём внятный репл, собираю нужную мне информацию
Например : "А что вернет вон та функция, если перед этим я вызову то и это"
И здесь нужна возможность писать полноценный код. Например если я проверяю результаты запросов, в которых есть лямбды, я хочу что бы отладчик позволял эти лямбды.
Re[12]: Swift
От: vdimas Россия  
Дата: 06.06.14 15:44
Оценка:
Здравствуйте, Klapaucius, Вы писали:

V>>Не работает обобщенное решение для Complex, как и для остальных типов. К каждому типу нужно сделать копипасту необобщенного аналога твоего ComplexReal. В итоге, сама обобщенность решения теряет смысл — точно такой же копипастой можно решать исходную задачу без всяких генериков.


K>Все пропало: ad-hoc полиморфизм не имеет смысла: оказывается, что зависимый от типа код — это просто копипаста и вместо написания всяких имплементаций тайпклассов можно просто копипастить — то на то и получится!


Да нет. Оказывается, что ad-hoc полиморфизм не поддерживается в полной мере генериками дотнета, только и всего. Иначе бы он сам подхватывал переопределённые операторы. А тебя просто несет на ровном месте. Знаешь же прекрасно о чем речь, но "баба Яга против" )) Остаётся только язвить. ))


V>>Такая же, как с Complex или любым другим типом, имеющим переопределенные операторы (не обязательно арифметические). Не работает "изкаробки". Признаюсь, я удивился, увидев твоё "решение". Т.е. до какой степени надо держать тут всех за дураков, чтобы не понять утверждение о том, почему в C# этого нельзя сделать. Сию тему подробно разжевали еще в первые дни после анонса генериков 10 лет назад.


K>Все пропало: параметрический полиморфизм не нужен — это разжевали еще 10 лет назад!


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


V>>Предлагались разные способы, поболее универсальные, чем твой. Например, многие целевые алгоритмы будут быстрее при явной диспетчеризации по типу аргумента-генерика,


K>Что, разумеется невозможно при параметрическом полиморфизме, и не совместимо с параметричностью. т.е. либо динамическая безтипизация, либо недозавтипы (хотя-бы GADTы или "язык модулей"), либо шаблонизатор для кода с "текстовой" подстановкой.


Ну а что делать, если всё кривое? )))

K>Единственный способ "диспетчеризации" по типу при обычном параметрическом полиморфизме в моем примере и продемонстрирован.


Ты продемонстрировал костыль в условиях "недо-". Но это нахальство какое-то считать всех дураками... бо именно эти костыли обсуждали еще лет 10 назад. Предлагая нарисовать пример на C# я предполагал, что все прекрасно в курсе, о чем речь. Получается, ты один был не в курсе или считаешь всех дураками, "изобретя" сотый вариант одного и того же.

V>>В случае C# это НЕ обобщенное решение. Ведь для каждого типа, помимо переопределения операторов, надо определить явную специализацию класса-хелпера.


K>Решение обобщенное, что очевидно следует из типа Avg:

K>
K>T Avg<T, C>(this IEnumerable<T> xs) where C : CReal<T>, new()
K>


Нет. Зависимость конкретных типов T->C должна быть неявной. Явное её указание — избыточность, делает решение недо-обобщенным.
Можно так:
T Avg<T>(this IEnumerable<T> xs) where T : INumber<T>, new()

Как и в Хаскель, собсно. (только с той разницей, что в дотнете INumber<T>, сцуко, описывает контракт только по одному аргументу this... но и этого могло бы хватить для арифметики)


K>"Явную специализацию класса хелпера" написать конечно надо. Она и в том же хаскеле написана.


Я тебе уже показал абзацем выше аналог на C# того, как это есть в Хаскеле. Заканчивай уже спекулировать. Словами я сиё тоже сказал еще несколько постов назад. Не верю, что ты не понял, о чем речь.

Ес-но, реализация арифметических операторов для Complex должна быть где-то описана. Но не дважды же! В Хасклеле бери любую либу с каким-нить MegaComplex, да пользуйся. А в твоём решении на C# надо еще раз по операторам пройтись да продублировать их. Что-то не так в консерватории, не правда ли? ))

V>>Более того, тип класса-хелпера надо затем всегда указывать явно.

K>Это точно, но автоподстановка словарей далеко не везде есть, шарп не один такой инвалид.

V>>В твоём Хаскеле ничего этого делать не надо,

K>Подставлять словари самому не надо, а писать их конечно надо (если они сами не выводятся, но и дотнете можно словари генерировать всякими костыльными способами)

Ммм... ты действительно не понял пару постов выше намек на то, как это надо было сделать в C#? ))
Блин, ты же сам всё правильно говорил про Хаскель! Модель типов дотнета позволяет делать так же. Просто не сделано для встроенных типов. Но даже при этом можно было бы арифметические операторы подхватывать автоматом и на этапе генерации бинарников подставлять в тела генериков нужный код. Даже можно обойтись существующим стандартом на метаинформацию и байт-код, достаточно компилятором генерить фиктивный IOperators<> в байт-коде, а во время JIT-а просто знать этот интерфейс "в лицо" и при его фиктивной реализации просто подставлять статически-переопределенные операторы, тогда тебе не надо было бы ручками описывать свой ComplexReal.

V>>как и в С++ — всё подхватывается "само".

K>В С++ подхватываться нечему, там ни параметрического полиморфизма, ни передачи словаря нет.

А зачем параметрический полиморфизм в сценариях, где уточненные типы выводятся еще на этапе компиляции?
Эдак тебя несет. Мы обсуждали конкретный пример, где параметрический полиморфизм времени исполнения не нужен ни разу.

K>>>Как что-то хорошее.

V>>??

K>Как будто то, "что обобщенное программирование в Swift должно быть ближе к C++" — это что-то хорошее.


Насмешил. В Хаскеле не всегда параметрический полиморфизм нужен в рантайм. 99% сценариев разруливаются на этапе компиляции, т.е. обобщенное программирование в этих сценариях не далеко ушло от С++ — обычная "текстовая подстановка" в итоге. Собсно, даже формат библиотек Хаскеля — это упакованный и размеченный результат парсинга текста (считай тупо AST исходников либы), а не объектный код.


V>>Какая из возможностей не покрывается?


K>"Продуктивность" свертки, например. Ей нельзя управлять, просто потребляя результат (для чего итератор и нужен). Впрочем, с помощью континьюейшенов можно некий воркараунд накостылить.


Конечно, можно на продложениях или автоматах.
Есть еще способ: IoC, потреблять результат реактивным способом, управляя потреблением "где-то" в конце цепочки обработки (вызова). Непривычный для функциональщика подход, не? ))

V>>1. Ты ничего не решил, готового к использованию изкаробки обобщенного решения так и не было. В дотнете автоматическое решение возможно только на рефлексии, увы.


K>Потому, что дотнетные разработчики (а точнее, принимающие решения) не читатели и не моргнув глазом пустили в свободное плаванье дизайнерское решение, которое целый фрактал проблем порождает.


Воооот. Именно.
А конкретно в этой ветке мне постарались надавать по щщам именно из-за попытки сравнения со "священной коровой". Я лишь заметил, что многих проблем C# в Swift нет.

Я не спорю, что до "чистых" языков ему далеко. Это гибрид и как любой гибрид состоит из компромиссов. Но в C# есть даже такие компромиссы, увы, которые вовсе не требовались. И ты наглядно их показал в своей собственной реализации yet another IArithmetic<T>.

K>При этом то, что решение проблемное на тот момент было известно лет 30 и лет 25 как проблемы были решены. Разумеется, этого никто не заметил, пока ручка грабель не ознакомила с ними индустриального разработчика.


Ну дело еще в том, что это выдавалось на-гора бесплатно.
И всё-таки в джаве и дотнете не в языке гвоздь, а в миллионах строк библиотек со сложным, но достаточно надежно оттестированным функционалом. Всё вместе это "платформа" для современных сложных приложений. Сиё накладывает определенный отпечаток и на "порог вхождения" и на стоимость разработки инструментария (попробуй-ка прикрути полноценный рефакторинг в Хаскель? ) и т.д. и т.п.

Поэтому тут всё как раз понятно, если не становится в позу эдакого борца-пуриста. Ей богу облом просто сыпать тонной известных до банальности аргументов, ты их и сам прекрасно знаешь. Просто поза такая, походу.

K>Проблема тут не в параметрическом полиморфизме, а в ограничении квантификации с помощью интерфейсов.


Да!

Хотя для value-типов для тех же генереков JIT генерит код, который нигде по-факту методы интерфейсов не вызывает!

Т.е. сие ограничение интерфейсов только на экземплярные методы можно было бы обойти, добавив возможность задавать некий "интерфейс для статических методов", как раз арифметика туда попала бы, а связь T->C в твоём примере была однозначной и не требовала бы явного задания. (Это был бы, конечно не интерфейс в ООП-смысле, а чистый "контракт", бо интерфейс описывает лишь контракт на экземплярные методы).


K>Но нормальное решение можно закодировать таким вот костыльным образом.


Ну да. Иначе бы я не предлагал его показать. При всей демонстрируемой тобой годами грамотности мне с трудом удаётся убедить себя, что конкретно в этой ветке ты выступил простаком. Но, похоже, именно так и есть. Без обид. ))

Что касается по-делу. Параметрический полиформизм генериков C# показывает свою силу только в рекурсивных, относительно типов, сценариях, например:
    struct Test<T> where T : struct 
    {
        public void Func<T1>() where T1 : struct 
        {
            Func<Test<T1>>();
        }
    }

Что как бы на практике появляется с фактически нулевой вероятностью. Во всех остальных случаях, хоть JIT разворачивает генерики только в рантайм, но в обычном же коде мы вызываем генерики таким образом, что компилятор может ресолвить все типы + проверяет ограничения. Т.е. коль в обычном использовании мы имеем дело только с compile-time сценарием, то те же шаблоны С++ покрывают эти сценарии... ну и покрывают дополнительно еще статические методы, операторы, "видит" внутренние типы (сколь угодно рекурсивно), т.е. много еще чего, за счет чего чуток помощнее будут.

K>Собственно, всякие костыльные воркараунды — единственные способы писать обобщенный код в индус триальных языках, их разработчики же думают не о том, как обобщенный код писать, а о том, как притянуть за уши какой-нибудь треш-угар вроде "знакомого практикам" наследования или шаблонизирования/подстановки туда, где без них только лучше будет.


Ну вот мне сходу показалось, что в Swift таких воркараундов должно быть поменьше.
Re[10]: Swift
От: vdimas Россия  
Дата: 06.06.14 15:53
Оценка:
Здравствуйте, Klapaucius, Вы писали:

I>>
I>>var items = new [] { new Complex(12, 6), дописать сколько надо, по желанию}; 

I>>Console.Write(items.Take(10).Aggregate(new Complex(0,0), (acc,item) => acc + item));
I>>


K>Я понял его задачу (и, судя по всему, правильно) как написание обобщенного кода для вычисления среднего. У вас же код — не обобщенный.


Да!

Хотя я предлагал им примерно такой же подход — через вынесение тела {acc += item} во внешний функтор.

И тут Swift, если я правильно понял описание языка, заруливает C#, т.к. само тело этого функтора может быть обобщенным, в отличие от. ))
Re[13]: Swift
От: vdimas Россия  
Дата: 06.06.14 15:57
Оценка:
Здравствуйте, Ikemefula, Вы писали:

K>>Ну да, любой контейнер с Complex, а не любой контейнер с числами.


I>В том то и дело, что речь шла про контейнеры, т.е. IEnumerable и тд. Товарищ просто не знал, как это сделано в Swift и решил перепрыгнуть на проблемы рантайма и другие, которые только ухитрился углядеть.


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

В твоём стиле это прекрасно делается и в Swift, аналог контейнера на С++ я уже показал. Написать тело нужного функтора оставил для самостоятельной работы. Использовались только конструкции, которые имеют полный аналог в Swift, поэтому со своими спекуляциями идешь сразу лесом.
Re[5]: Swift
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 06.06.14 15:59
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ну т.к. там llvm и есть возможность подключать библиотеки на C, то не вижу никаких проблем для кроссплатформенности, даже если Apple не захочет.


А сам компилятор кто будет писать и портировать? Он разве открытый? License: proprietary

_>Хгм, не ожидал от тебя такого вопроса. Ты же знаешь, что в том же D (да и в C++ и ещё много где) вопросы подобных контейнеров решаются в стандартной библиотеке (описание которой для Swift'a никто из нас тут ещё не видел), а не в конструкциях самого языка.


Я просто увидел вот это:
http://www.weheartswift.com/higher-order-functions-map-filter-reduce-and-more/
Там говорилось, что у массивов есть map, filter, reduce и все.

_>P.S. Eсли бы в Swift'е было мощное метапрограммирование (кстати, его ещё не поздно добавить с помощью макросов) и Apple дала бы обещание поддерживать его не только под свои платформы, то на мой вкус такой язык стал бы даже поинтереснее D...


Мне он тоже в целом понравился, особенно null-safety, но на фоне Dивной интроспекции и МП — слабовато. Вот тут правильно сказал человек:
http://justy-tylor.livejournal.com/221988.html
Re[11]: Swift
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.06.14 16:43
Оценка: +1
Здравствуйте, Нахлобуч, Вы писали:

Н>Какой словарь?

"add" -> a + b;
"div" -> v / n;
Вы фактически вводите синонимы для op_Addition и op_Division.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.06.14 18:32
Оценка:
Здравствуйте, vdimas, Вы писали:

V>В твоём стиле это прекрасно делается и в Swift, аналог контейнера на С++ я уже показал. Написать тело нужного функтора оставил для самостоятельной работы. Использовались только конструкции, которые имеют полный аналог в Swift, поэтому со своими спекуляциями идешь сразу лесом.


У тебя только один вариант сохранить лицо — показать код.
Re[6]: Swift
От: AlexRK  
Дата: 06.06.14 19:17
Оценка: +1
Здравствуйте, D. Mon, Вы писали:

DM>Вот тут правильно сказал человек:

DM>http://justy-tylor.livejournal.com/221988.html

Да ну, это ерунда какая-то, извините. Я бы даже сказал, что бред написан. Вот буквально ни с одним предложением (кроме самого первого) не согласен.

На рынке доля Haskell, Scala и Clojure примерно в районе нуля, а автор с умным видом рассуждает на примере этой маргинальщины.
Re[7]: Swift
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 06.06.14 19:31
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>На рынке доля Haskell, Scala и Clojure примерно в районе нуля, а автор с умным видом рассуждает на примере этой маргинальщины.


Ну так человек в будущее смотрит, а не в прошлое.
Re[8]: Swift
От: AlexRK  
Дата: 06.06.14 19:34
Оценка:
Здравствуйте, D. Mon, Вы писали:

ARK>>На рынке доля Haskell, Scala и Clojure примерно в районе нуля, а автор с умным видом рассуждает на примере этой маргинальщины.

DM>Ну так человек в будущее смотрит, а не в прошлое.

Дык тут бабуля надвое сказала, за кем будущее.
Несколько десятков лет назад поклоннники Lisp, Forth и APL тоже, вероятно, смотрели в будущее.
Re[10]: Swift
От: andyag  
Дата: 06.06.14 19:39
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>>>И запускать эти тесты надо полагать, придется на боевой системе ?


A>>Там чуть выше по треду описан контекст. Ни про какие боевые системы и самоотверженных девопсов речи не было: "для быстрого тестирования некоторых вещей".


I>Как тестировать мой код, все понятно. А вот как тестировать интеграцию с системой, т.е. нативными решения, вот это поинтереснее.


Давайте разделять "тестировать" и "быстро протестировать". Первое — это бесконечный проектный процесс, который должен быть педантичным и воспроизводимым. Второе — это костыль для "я уже не помню как оно работает", либо "у стороннего сервиса плохая документация". Если вы про второй случай, то, ИМХО, все средства хороши. Не REPL нас спасёт, а именно абсолютно любое решение, в том числе и REPL.

I>>>Эта хрень дает возможности сократить на прядок другой количество перезапусков приложения. Если для каждого перезапуска надо собирать пекадж или делать деплоймент, то разница просто сумасшедшая.


A>>Расскажите пожалуйста какой-то юзкейз, отдалённо похожий на реальный мир.


I>Например меня есть мобильное приложение. Есть баг, который воспроизводится в релизной версии, но не воспроизводится в девелоперской. Я подключаю отладчик и если в нём внятный репл, собираю нужную мне информацию

I>Например : "А что вернет вон та функция, если перед этим я вызову то и это"

Это как раз второй сценарий из тех двух, что я описал сверху. Субъективно ящитаю, не должно быть ситуаций, когда возникает мотивация "дёрнуть вот это и это, прежде чем дёргать то". Это полное отчаяние, когда уже совсем не стыдно, лишь бы заработало. В мобильных приложениях (по опыту с Андроид) есть 2 основных категории проблем:
1. Неправильное понимание жизненного цикла приложения и его компонентов. Здесь достаточно тупо отладчика — просто чтобы увидеть, что какой-нибудь onDestroy() вызвался раньше, чем вы реально закончили транзакцию. Здесь просто нечего дёргать REPL'ом — есть ссылка на мёртвый ресурс и всё.
2. Синхронизация, многопоточность и всякое прочее. Конечно это не специфика чисто мобильных приложений. Есть у вас дедлок и REPL. Как оно поможет?
Обе группы невозможно нормально протестировать автотестами. Как тут поможет REPL — тоже не вижу.

I>И здесь нужна возможность писать полноценный код. Например если я проверяю результаты запросов, в которых есть лямбды, я хочу что бы отладчик позволял эти лямбды.


А что за запросы с лямбдами? Звучит как код, который легко покрывается тестами вдоль и поперёк. Чем меньше мобильной специфики, тем очевиднее покрывается тестами.
Re[6]: Swift
От: alex_public  
Дата: 06.06.14 20:04
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>А сам компилятор кто будет писать и портировать? Он разве открытый? License: proprietary


Ну так можно запускать его как front-end на билд сервере маковском (или виртуалке ). А потом уже у себя делать нормальные бинарники. Но опять же это в случае, если Apple будет против кроссплатформенности, а в этом случае не будет ещё и разработанных удобных библиотек (в смысле уже на Swift'e, даже если там внутри и обращение к C или OS API) под соответствующие платформы и надо будет обращаться напрямую к разным C библиотекам или OS API. А это практически убивает один из главных плюсов.

DM>Я просто увидел вот это:

DM>http://www.weheartswift.com/higher-order-functions-map-filter-reduce-and-more/
DM>Там говорилось, что у массивов есть map, filter, reduce и все.

Видимо имелось в виду "всё что есть из функциональщины". )

DM>Мне он тоже в целом понравился, особенно null-safety, но на фоне Dивной интроспекции и МП — слабовато.


О, да, точно, про интроспекцию времени компиляции я забыл. Кстати, очень странно что её нет в Swift'e. Тем более, что там есть атрибуты и т.п. Может снова где-то в документации потерялось? Но без неё реально печально будет со многими моментами. Уже даже в C++ планируют добавить её, а тут...

DM>Вот тут правильно сказал человек: http://justy-tylor.livejournal.com/221988.html


Не воспринимаю подобные высказывания, если автор не указывает предлагаемую им лучшую альтернативу. В данном случае ничего конкретного не указано...
Re[11]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.06.14 20:15
Оценка:
Здравствуйте, andyag, Вы писали:

I>>Как тестировать мой код, все понятно. А вот как тестировать интеграцию с системой, т.е. нативными решения, вот это поинтереснее.


A>Давайте разделять "тестировать" и "быстро протестировать". Первое — это бесконечный проектный процесс, который должен быть педантичным и воспроизводимым. Второе — это костыль для "я уже не помню как оно работает", либо "у стороннего сервиса плохая документация". Если вы про второй случай, то, ИМХО, все средства хороши. Не REPL нас спасёт, а именно абсолютно любое решение, в том числе и REPL.


Абсолютно любое не подойдет. Тесты из IDE в большинстве случаев ничего не дадут.
Вместо тестов проще держать под рукой вещи навроде LINQPad

I>>Например меня есть мобильное приложение. Есть баг, который воспроизводится в релизной версии, но не воспроизводится в девелоперской. Я подключаю отладчик и если в нём внятный репл, собираю нужную мне информацию

I>>Например : "А что вернет вон та функция, если перед этим я вызову то и это"

A>Это как раз второй сценарий из тех двух, что я описал сверху. Субъективно ящитаю, не должно быть ситуаций, когда возникает мотивация "дёрнуть вот это и это, прежде чем дёргать то". Это полное отчаяние, когда уже совсем не стыдно, лишь бы заработало. В мобильных приложениях (по опыту с Андроид) есть 2 основных категории проблем:

A>1. Неправильное понимание жизненного цикла приложения и его компонентов. Здесь достаточно тупо отладчика — просто чтобы увидеть, что какой-нибудь onDestroy() вызвался раньше, чем вы реально закончили транзакцию. Здесь просто нечего дёргать REPL'ом — есть ссылка на мёртвый ресурс и всё.

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

A>2. Синхронизация, многопоточность и всякое прочее. Конечно это не специфика чисто мобильных приложений. Есть у вас дедлок и REPL. Как оно поможет?

A>Обе группы невозможно нормально протестировать автотестами. Как тут поможет REPL — тоже не вижу.

Репл помогает собирать информацию о текущем состоянии процесса.

I>>И здесь нужна возможность писать полноценный код. Например если я проверяю результаты запросов, в которых есть лямбды, я хочу что бы отладчик позволял эти лямбды.


A>А что за запросы с лямбдами? Звучит как код, который легко покрывается тестами вдоль и поперёк. Чем меньше мобильной специфики, тем очевиднее покрывается тестами.


Любой запрос. Например у меня есть несколько агентов. Я хочу посмотреть состояние только нужных мне агентов. Решение

workers.Where(w => w.Task.Id.Contains('push-pull')).Select(w => w.Task.State).ToArray()

Это одноразовый код. Или, другой вариант, мне понадобится только 5 первых воркеров. Или, например, сумма объемов промежуточных результатов по некоторым воркерам.
Re[2]: Swift
От: dr. Acula Украина  
Дата: 06.06.14 20:26
Оценка:
D>Макросов нету.
макрОсов
Re[3]: Swift
От: andyag  
Дата: 06.06.14 20:48
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


A>>1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два.

C>Это Apple. Они могут — Carbon API они таки запретили, хотя им пользовались такие гиганты как Photoshop.

А давайте попробуем дать оценку количества кода, который зависел от Carbon API и количества кода, написанного на Objective C. Я плохо даю оценки, но наверное "в 10 раз" — это сильное занижение.

A>>2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых.

A>>3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии.
C>То есть? Рефлексию несложно добавить — это же LLVM. Аналогично, поддержка остальных платформ (в том числе Windows) скорее зависит от того, чтобы кто-то не поленился сделать сборку для них.

Да какая разница-то? На дворе 2014ый год, а появляется новый "альтернативно одарённый" язык, которому глубоко плевать на этот самый 2014ый год. Просто потому что.
Re[15]: Swift
От: alex_public  
Дата: 06.06.14 21:11
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>У тебя только один вариант сохранить лицо — показать код.


Эммм, очень странно добиваться от vdimas этого кода после того, как D. Mon кинул ту ссылку на определение интерфейса (к которoму кстати умеет цепляться foreach) для последовательностей в Swift'e. Имея подобное, эту вашу задачку решит любой начинающий. ))) Просто это дело находится (видимо) в стандартной библиотеке языка, а описания к ней в текущей документации на язык нет, так что не обладая установленной средой (и не полазив по исходникам) vdimas'у довольно проблематично было дать красивый ответ. Но теперь то, что вы продолжаете цепляться? Или всё ждёте этот пример школьного кода? )

Кстати, документация вообще кривая. Облазил всё описание языка и не увидел ничего про указатели вообще. Естественно подумал что и нет их. А в другом, совершенно "левом" месте (типа про доступ к Cocoa и т.п.) вижу работу с указателеми (представленными соответствующими классами), причём в коде видна инициализация такого указателя адресом разных структур языка (кстати, вот оно преимущество отсутствия GC типа jvm/.net!). Т.е. в языке есть операция взятия указателя "&", но нигде в описание языка про неё не сказано...
Re[3]: Swift
От: andyag  
Дата: 06.06.14 21:30
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


A>>Ещё один язык, который работает на сильно ограниченном наборе платформ. Ещё один язык со своим уникальным и самым лучшим синтаксисом. Ещё один язык, который теперь в вакансиях сначала будет "крайне приветствуется", а потом "необходимо знать: Objective C, Objective C++, Swift". Ещё один язык, который будет иметь ненулевую популярность, просто потому что хипстеры.


I>И что с того ?


У любого программиста, прочитавшего больше десятка книжек и написавшего больше несколько сотен килострок кода есть свои ценности, переживания и убеждения по поводу "что такое хорошо и что такое плохо". Ценности эти далеко не всегда относятся к любимому языку или любимой библиотеке, часто ценности находятся на более высоком уровне и описывают уже не любовь к инструментам, подходома и знаниям, а любовь к множествам инструментов, подходов и знаний. Все эти множества определяются через "что такое хорошо". А есть ещё "что такое плохо". Через этот критерий определяются всякие штуки, к которым не то что любви нет, а прямо порвать на куски хочется. Эти "хорошо" и "плохо" ни разу не объективны.

Теперь, отвечая на ваш вопрос: "сильно тошнит".

A>>1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два.

A>>2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых.
A>>3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии.

I>Если будет внятный перформанс и легкость интеграции с обжективси, то этот Обжектив си умрем сам собой, ибо переписать модуль заново будет много быстрее, чем фиксить старый. А где совсем туго, так и оставить обжектив.


А смысл? Для под-сообщества не-быдло-айфонщиков внутри сообщества всех айфонщиков он может и есть. Но вот для под-сообщества айфонщиков внутри сообщества всех программистов — это как была бестолковая хрень, так и осталась. Из-за отсуствия должных инструментов на уровне языка культура так и не будет расти. Так и будут продолжаться все эти глобальные синглтоно-сервис-локаторы и сериализация руками в NSDictionary — вместо IoC-контейнеров и сериализации из коробки. Так и будут эти люди писать костыли, чтобы проинициализировать ленивые синглтоны в правильном порядке, потому что язык (и рантайм, и сторонние решения) не дают ему вообще никакого намёка, что возможно что-то не так, и можно сделать как-то иначе. Это только абстрактные программисты знают ООП, признают штуки "dependency injection — это по умолчанию" и понимают, что вообще прочитать объект из JSON — это не 2 дня работы, а что-то нечаянно написанное между двумя глотками кофе. А неабстрактные программисты — это молодые коллеги, которые начали свой путь с Objective C. И существование этих самых ребят — это то самое, что мне не нравится в том, что делает Apple.

I>Рефлексию легко добавить, и лучше если это будет чуть попозжа. Как вариант, всунуть компайл-тайм рефлексию, шоб сильнее отличиться от дотнета и джавы


Не, это куда-то не туда ИМХО. Такими темпами будет ещё одно чудо с вычислением факториалов на этапе компиляции.
Re[12]: Swift
От: andyag  
Дата: 06.06.14 21:56
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

A>>Давайте разделять "тестировать" и "быстро протестировать". Первое — это бесконечный проектный процесс, который должен быть педантичным и воспроизводимым. Второе — это костыль для "я уже не помню как оно работает", либо "у стороннего сервиса плохая документация". Если вы про второй случай, то, ИМХО, все средства хороши. Не REPL нас спасёт, а именно абсолютно любое решение, в том числе и REPL.


I>Абсолютно любое не подойдет. Тесты из IDE в большинстве случаев ничего не дадут.

I>Вместо тестов проще держать под рукой вещи навроде LINQPad

Как так — ничего? Если контекст проблемы более-менее понятен, намного проще этот самый контекст накидать в виде теста и несколько раз прокрутить в разных вариациях, чем методом тыка сначала этот контекст ловить во время выполнения кода в продакшне, а потом судорожно писать в реальном времени какие-то команды с вероятностью написать не то, или тупо забыть что ж вы там такое написали в итоге, когда вроде всё уже понятно.

I>>>Например меня есть мобильное приложение. Есть баг, который воспроизводится в релизной версии, но не воспроизводится в девелоперской. Я подключаю отладчик и если в нём внятный репл, собираю нужную мне информацию

I>>>Например : "А что вернет вон та функция, если перед этим я вызову то и это"

A>>Это как раз второй сценарий из тех двух, что я описал сверху. Субъективно ящитаю, не должно быть ситуаций, когда возникает мотивация "дёрнуть вот это и это, прежде чем дёргать то". Это полное отчаяние, когда уже совсем не стыдно, лишь бы заработало. В мобильных приложениях (по опыту с Андроид) есть 2 основных категории проблем:

A>>1. Неправильное понимание жизненного цикла приложения и его компонентов. Здесь достаточно тупо отладчика — просто чтобы увидеть, что какой-нибудь onDestroy() вызвался раньше, чем вы реально закончили транзакцию. Здесь просто нечего дёргать REPL'ом — есть ссылка на мёртвый ресурс и всё.

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


А почему нет? В том же Андроиде оно падает с явными ошибками типа "эй! тут мёртвый ресурс".

A>>2. Синхронизация, многопоточность и всякое прочее. Конечно это не специфика чисто мобильных приложений. Есть у вас дедлок и REPL. Как оно поможет?

A>>Обе группы невозможно нормально протестировать автотестами. Как тут поможет REPL — тоже не вижу.

I>Репл помогает собирать информацию о текущем состоянии процесса.


Текущее состояния — всё хреново. Целостность нарушена. Часть ресурсов нормальные, часть уже разрушены. Предположения, сделанные в коде не сходятся с реальностью. При следующем прогоне ситуация может быть несколько иной. У вас есть REPL. Он подтверждает, что всё хреново. Как это помогает?

I>>>И здесь нужна возможность писать полноценный код. Например если я проверяю результаты запросов, в которых есть лямбды, я хочу что бы отладчик позволял эти лямбды.


A>>А что за запросы с лямбдами? Звучит как код, который легко покрывается тестами вдоль и поперёк. Чем меньше мобильной специфики, тем очевиднее покрывается тестами.


I>Любой запрос. Например у меня есть несколько агентов. Я хочу посмотреть состояние только нужных мне агентов. Решение


I>workers.Where(w => w.Task.Id.Contains('push-pull')).Select(w => w.Task.State).ToArray()


I>Это одноразовый код. Или, другой вариант, мне понадобится только 5 первых воркеров. Или, например, сумма объемов промежуточных результатов по некоторым воркерам.


Если их там "несколько", почему просто на всех не посмотреть? Если это критичная часть системы, почему не добавить какую-то мониторилку, которая периодически будет в лог писать их состояние? Важность таких компонентов сопоставима с важностью адекватной обработки исключений. Для мобильных приложений может и не популярно, но вон всякие серверные штуки поступают именно так: упало — присылай логи.
Re[4]: Swift
От: alex_public  
Дата: 06.06.14 22:44
Оценка:
Здравствуйте, andyag, Вы писали:

A>Теперь, отвечая на ваш вопрос: "сильно тошнит".


Хы, вы кажется первый, кого я вижу с такой реакцией на Swift. А можно тогда развернуть поподробнее? )))

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

A>Не, это куда-то не туда ИМХО. Такими темпами будет ещё одно чудо с вычислением факториалов на этапе компиляции.


Вообще то как раз только интроспекция времени компиляции (как в том же D) и имеет смысл для статически типизированных компилируемых языков. А убогие интроспекции времени исполнения, как в Java/C# — это только от недостатка умения. Ну и я вообще то очень удивлён, что в Swift'e нет нормальной интроспекции (а может всё же есть, просто снова не разглядели в документации?). Это серьёзный минус.

Да, и насчёт факториалов во время компиляции... Я бы сказал, что полное отсутствие метапрограммирования — это для меня как раз основной минус Swift'a, который не позволяет представить его основным языком для меня.
Re[13]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.06.14 06:13
Оценка:
Здравствуйте, andyag, Вы писали:

I>>Абсолютно любое не подойдет. Тесты из IDE в большинстве случаев ничего не дадут.

I>>Вместо тестов проще держать под рукой вещи навроде LINQPad

A>Как так — ничего? Если контекст проблемы более-менее понятен,


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

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


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

Нужно установить, что за проблема и как ее пофиксить. Задавай вопросы, Говори, какие будешь писать тесты, а я скажу тебе результаты. Т.е. Я показал тебе ровно то, что увидел в отладчике — место откуда летит исключение.

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


A>А почему нет? В том же Андроиде оно падает с явными ошибками типа "эй! тут мёртвый ресурс".


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

Вот еще вещь — вызываешь функцию, асинхронную, три раза с разными праметрами, не дожидаясь завершения. Функция нативная. Далее надо дождаться пока все колбеки завершатся и продолжить кое какие действия. Время от времени эта часть зависает.

I>>Репл помогает собирать информацию о текущем состоянии процесса.


A>Текущее состояния — всё хреново. Целостность нарушена. Часть ресурсов нормальные, часть уже разрушены. Предположения, сделанные в коде не сходятся с реальностью. При следующем прогоне ситуация может быть несколько иной. У вас есть REPL. Он подтверждает, что всё хреново. Как это помогает?


Я про ресурсы ничего не говорил. Смотри мои примеры

I>>workers.Where(w => w.Task.Id.Contains('push-pull')).Select(w => w.Task.State).ToArray()


I>>Это одноразовый код. Или, другой вариант, мне понадобится только 5 первых воркеров. Или, например, сумма объемов промежуточных результатов по некоторым воркерам.


A>Если их там "несколько", почему просто на всех не посмотреть? Если это критичная часть системы, почему не добавить какую-то мониторилку, которая периодически будет в лог писать их состояние? Важность таких компонентов сопоставима с важностью адекватной обработки исключений. Для мобильных приложений может и не популярно, но вон всякие серверные штуки поступают именно так: упало — присылай логи.


Я не знаю заранее, какаяя информация мне нужна. Может это наборы данных по воркерам, их тоже в логи пихать?
Я боюсь девайс не выдержит такой мониторинг
Re[4]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.06.14 06:24
Оценка:
Здравствуйте, andyag, Вы писали:

I>>Если будет внятный перформанс и легкость интеграции с обжективси, то этот Обжектив си умрем сам собой, ибо переписать модуль заново будет много быстрее, чем фиксить старый. А где совсем туго, так и оставить обжектив.


A>А смысл? Для под-сообщества не-быдло-айфонщиков внутри сообщества всех айфонщиков он может и есть. Но вот для под-сообщества айфонщиков внутри сообщества всех программистов — это как была бестолковая хрень, так и осталась. Из-за отсуствия должных инструментов на уровне языка культура так и не будет расти.


Культура растет не из за языка, а из за решаемых задач. Платформа все таки набирает вес и сообщество разработчиков пополняется, что очевидно. И так же очевидно, что пополняется не только студентами.
Re[2]: Swift
От: NeoCode  
Дата: 07.06.14 14:11
Оценка:
Здравствуйте, andyag, Вы писали:

A>1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два.

A>2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых.
A>3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии.

А вы что предлагаете взамен?
Конечно, не ошибается тот кто ничего не делает. Можно не изобретать ничего нового, юзать старые уродливые языки еще сотни лет и не пытаться ничего улучшить.
Re[3]: Swift
От: andyag  
Дата: 07.06.14 17:19
Оценка: -1
Здравствуйте, NeoCode, Вы писали:

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


A>>1. Уродливый Objective C всё равно не запретят. Потому что это нереализуемо. Их будет два.

A>>2. Прекрасный новый Swift идеологически не отличается от Objective C: это ЭКЗОТИКА. Прошлая экзотика была из глубоких 80-х, новая — из 2010ых.
A>>3. Этот НОВЫЙ язык будет работать на очень старой платформе "с большой историей" — со странноватыми API и отсутствием клёвых штук типа рефлексии.

NC>А вы что предлагаете взамен?

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

У вас любимая кошка сходила в туалет по-большому прямо в центре кухни. Предлагаются варианты:

1. Организовать на кухне музей альтернативного искусства
2. Убрать
3. Посыпать сахаром и оставить на потом

Ваши действия?
Re[4]: Swift
От: AlexRK  
Дата: 07.06.14 17:45
Оценка:
Здравствуйте, andyag, Вы писали:

A>На дворе 2014ый год, а появляется новый "альтернативно одарённый" язык, которому глубоко плевать на этот самый 2014ый год.


А что из 2014 года не хватает в Swift?
Re[4]: Swift
От: NeoCode  
Дата: 07.06.14 19:00
Оценка:
Здравствуйте, andyag, Вы писали:

A>У вас любимая кошка сходила в туалет по-большому прямо в центре кухни. Предлагаются варианты:


A>1. Организовать на кухне музей альтернативного искусства

A>2. Убрать
A>3. Посыпать сахаром и оставить на потом

A>Ваши действия?


Указать оппоненту на то, что сравнение нового языка программирования с продуктом жизнедеятельности кошки как минимум нужно еще обосновать, и весьма серьезно обосновать.
Re: А вот и сравнения скорости Swift с Objective-C подоспели
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 08.06.14 05:35
Оценка:
В лучшем случае Swift в 7.9x раз медленнее чем Objective-C. Результат, конечно, не ахти, но то что язык находится на стадии бета-тестирования, оставляет надежды а оптимизацию по скорости.

http://www.splasmata.com/?p=2798

P.S. тесты ну ооочень синтетические.
Re: Swift
От: NeoCode  
Дата: 08.06.14 08:16
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>https://itunes.apple.com/gb/book/swift-programming-language/id881256329?mt=11

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

А кстати, исходники компилятора я так понимаю недоступны?
Re[11]: Swift
От: vdimas Россия  
Дата: 08.06.14 09:35
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Откровенно говоря, не вижу особого смысла сравнивать Swift с "современными языками". Всякие Go-Swiftы — это подзадержавшиеся Явы-Шарпы, с ними и имеет смысл сравнивать. Языки вроде окамлов-хаскелей-идрисов — это другие поколения и эпохи, сравнивая с ними можно получить только один ответ: в госвифтах все плохо, ничего нет.


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

Зачем опять и снова игнорить реальность? Ну не может на сегодня взлететь "настоящее ФП", типа Хаскеля, без самой настоящей суперкомпиляции. Дай этим технологиям еще лет 20 (и это еще оптимистично).

Да и не самый лучший этот Хаскель даже для ФП. Одни лишь name conventions, вшитые в язык, с разбегу делают его не более, чем исследовательским. Конечно, когда мощщи компов и соответствующие компиляторы созреют, то сразу появятся более вменяемые ФП-языки и займут своё вполне заслуженное место.
Re[2]: А вот и сравнения скорости Swift с Objective-C подоспели
От: alex_public  
Дата: 08.06.14 10:38
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>В лучшем случае Swift в 7.9x раз медленнее чем Objective-C. Результат, конечно, не ахти, но то что язык находится на стадии бета-тестирования, оставляет надежды а оптимизацию по скорости.


KP>http://www.splasmata.com/?p=2798


KP>P.S. тесты ну ооочень синтетические.


Очень любопытно) Похоже, что этот их Sequence интерфейс почему-то абсолютно не инлайнится...
Re[12]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.06.14 18:06
Оценка:
Здравствуйте, vdimas, Вы писали:

K>>Откровенно говоря, не вижу особого смысла сравнивать Swift с "современными языками". Всякие Go-Swiftы — это подзадержавшиеся Явы-Шарпы, с ними и имеет смысл сравнивать. Языки вроде окамлов-хаскелей-идрисов — это другие поколения и эпохи, сравнивая с ними можно получить только один ответ: в госвифтах все плохо, ничего нет.


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


А где эта хорошая производительность бинарника ? По тестам на одном уровне с динамическими, до джавы как до небес, не говоря про c#
Re[13]: Swift
От: vdimas Россия  
Дата: 08.06.14 19:31
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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

I>А где эта хорошая производительность бинарника ? По тестам на одном уровне с динамическими, до джавы как до небес, не говоря про c#

Ты тестировал?
Re[14]: Swift
От: vdimas Россия  
Дата: 08.06.14 19:43
Оценка:
Здравствуйте, Klapaucius, Вы писали:

I>>В том то и дело, что речь шла про контейнеры, т.е. IEnumerable и тд. Товарищ просто не знал, как это сделано в Swift и решил перепрыгнуть на проблемы рантайма и другие, которые только ухитрился углядеть.


K>Да я сразу понял, что он контратаковал на другом направлении. Какая разница, если все равно можно решение дать?


Ниче я не контратаковал. Сам же Ikemefula по-невнимательности "допилил" исходное условие до, фактически, тупикового в версии C#.
Поймать я хотел именно его, он же сам напросился. )))
Но, видать, зря старался, судя по: http://www.rsdn.ru/forum/philosophy/5637841.1
Автор: Ikemefula
Дата: 06.06.14

Он так и не понял, за какое место был пойман.

===========
И да. Сравнивать языки можно, действительно, по разным прикладным сценариям, а не только по тем, которые тщательно выбирает лишь одна сторона. Но они уже пытаются и это оспорить. Давно я в этом дурдоме не участвовал. )))
Re[14]: Swift
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 08.06.14 19:46
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Ты тестировал?


Это не так-то просто, Эпл позаботился:
http://migmit.livejournal.com/54465.html
Re[14]: Swift
От: vdimas Россия  
Дата: 08.06.14 20:05
Оценка:
Здравствуйте, Ikemefula, Вы писали:

V>>Чего-чего? Там были все демонстрации.

I>Не было. Последняя твоя отписка была вот такой: "нициализируешь локальную переменную и вперед далее вниз по правилам процедурной/функциональной декомпозиции"

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


I>Здесь, судя по всему, такая же история


Здесь ты случайно изменил условие задачи так, что оно резко стало не в пользу C#. Медвежью услугу оказал своей священной корове, кароч. ))
Ну и всерьез воспринимать сие обсуждение после такого: http://www.rsdn.ru/forum/philosophy/5637841.1
Автор: Ikemefula
Дата: 06.06.14

не имеет смысла.

Ты не в состоянии отличить обобщенное решение от частного.
Re[15]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.06.14 20:28
Оценка: :)
Здравствуйте, vdimas, Вы писали:

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


V>>>Чего-чего? Там были все демонстрации.

I>>Не было. Последняя твоя отписка была вот такой: "нициализируешь локальную переменную и вперед далее вниз по правилам процедурной/функциональной декомпозиции"

V>Ты меня с кем-то путаешь. Я тебе даже код давал, демонстрирующий работу двух разных диспетчеров и показывающих, что кооперативная многозадачность не имеет проблем с конкурентным доступом к ресурсам. И что модель асинхронщины меньше всего зависит от твоего кода и больше всего от диспетчера, который дергает за нитки автоматы-продолжения.


Ничего не путаю, ты показал код который использует очередь для синхронизации.

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

I>>Здесь, судя по всему, такая же история


V>Ты не в состоянии отличить обобщенное решение от частного.


Ты всего лишь нашел способ увильнуть от ответа, вместо обсуждения контейнеров перескочил на другие вопросы
Re[15]: Swift
От: vdimas Россия  
Дата: 08.06.14 20:33
Оценка:
Здравствуйте, D. Mon, Вы писали:

V>>Ты тестировал?

DM>Это не так-то просто

А почему не просто?

DM>Эпл позаботился:

http://migmit.livejournal.com/54465.html

Поржал. Ты хоть читал ссылку-то?

Если подробно — нужно написать две функции (или что-то в таком роде): scalarProduct и, скажем, main. Функция scalarProduct должна принимать две последовательности (это могут быть массивы, связные списки, или ещё что-то — не важно) целых чисел и вычислять их скалярное произведение. При этом она должна падать, если длины этих последовательностей различны. Важное (критически) уточнение: это должно происходить НА СТАДИИ КОМПИЛЯЦИИ!!!


Сию задачу разбирали здесь минимум дважды. Она про тот самый параметрический полиморфизм времени исполнения, который ни разу не нужен в ваших примерах.
Так в чем твои-то трудности?

Ну и вообще парень там нагнал пурги:

Дальше ещё веселее. Вы запускаете XCode заново, он восстанавливает тот же файл, снова прогоняет его через компилятор, тот снова сегфолтится, и XCode снова вылетает.

Я не смог запилить такой код, который проверял бы мой тест и при этом не сегфолтился.

А в блокноте не судьба была? ))

Скорее всего компилятор в режиме максимально-глубокого вывода типов для интелисенса пытается рекурсивно выводить типы, но конца этому процессу для конкретно этой задачи НЕТ. ))

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

У меня и 10-я студия нет, нет, да упадёт иногда как раз во время парсинга изменений файла при пошаговой отладке.

А по-существу той задачи, там же по ссылке правильно заметили (и здесь когда-то говорили аналогичное):

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

Т.е. исходную задачу можно отрефакторить в эквивалентную, не требующую параметрического полиморфизма времени исполнения. В любом случае, в том же Хаскеле, компилятор способен пропустить через тайп-чек эту задачу только тогда, когда он формирует эти вектора ОДНОВРЕМЕННО. Если же попытаться сформировать их раздельно, то тайпчек навернется даже в Хаскеле, бо нет возможности сформировать эти вектора раздельно и проверить одинаковость их типов.

Кароч, по-настоящему эту задачу способны решить только языки с полной поддержкой зависимых типов, а к ним ни C#, ни Swift, ни Хаскель не относятся.

Но что характерно, что текущая система шаблонов С++ ПОЗВОЛЯЕТ в будущем добавить поддержку зависимых типов без какой-либо переделки синтаксиса (правда, с текущим ограничением на целочисленный аргумент зависимого значения). Т.е. система типов Swift тоже в будущем сможет быть развита до аналогичного. А вот в C# — никогда и ни при каких обстоятельствах. Принципиально невозможно. Вот так по-дебильному (C) дизайн генериков сделан. Так шта, накося выкуси. )))

========
Более того, при полноценной поддержке зависимых типов в этой задаче исчезает надобность рекурсивного определения типов, за "глубину" будет отвечать целочисленное значение, определяющее точный тип. Так шта, XCode падать не будет. ))
Re[15]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.06.14 20:34
Оценка: +1
Здравствуйте, vdimas, Вы писали:

K>>Да я сразу понял, что он контратаковал на другом направлении. Какая разница, если все равно можно решение дать?


V>Ниче я не контратаковал. Сам же Ikemefula по-невнимательности "допилил" исходное условие до, фактически, тупикового в версии C#.

V>Поймать я хотел именно его, он же сам напросился. )))
V>Но, видать, зря старался, судя по: http://www.rsdn.ru/forum/philosophy/5637841.1
Автор: Ikemefula
Дата: 06.06.14

V>Он так и не понял, за какое место был пойман.

Ты, вероятно, не понял, но тебя просили показать аналог IEnumerable. Смотри внимательно — автор вопроса дважды явно тебе сообщил и дал решение ВМЕСТО тебя

Вместо того, чтобы хотя бы намекнуть на протоколы, ты понес какую то галиматью про функции, подкрепив это кодом на сиплюсе
Re[16]: Swift
От: vdimas Россия  
Дата: 08.06.14 20:39
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Эммм, очень странно добиваться от vdimas этого кода после того, как D. Mon кинул ту ссылку на определение интерфейса (к которoму кстати умеет цепляться foreach) для последовательностей в Swift'e. Имея подобное, эту вашу задачку решит любой начинающий. ))) Просто это дело находится (видимо) в стандартной библиотеке языка, а описания к ней в текущей документации на язык нет, так что не обладая установленной средой (и не полазив по исходникам) vdimas'у довольно проблематично было дать красивый ответ. Но теперь то, что вы продолжаете цепляться? Или всё ждёте этот пример школьного кода? )


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

Всё намного проще. Я пока тупо тянул время, бо в эти выходные ни с какой виртуалкой макоси возиться не собирался.
ЮБК, море, солнце, местное вино... и пускай злопыхатели подождут.
Re[14]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.06.14 20:40
Оценка:
Здравствуйте, vdimas, Вы писали:

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

I>>А где эта хорошая производительность бинарника ? По тестам на одном уровне с динамическими, до джавы как до небес, не говоря про c#

V>Ты тестировал?


Если ты не заметил, то результаты тестирования уже выложили прямо в этом треде. Про них и речь, а именно, про отставание от 7 до 49 раз относительно сиплюса
Re[17]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.06.14 20:48
Оценка:
Здравствуйте, vdimas, Вы писали:

_>>Эммм, очень странно добиваться от vdimas этого кода после того, как D. Mon кинул ту ссылку на определение интерфейса (к которoму кстати умеет цепляться foreach) для последовательностей в Swift'e. Имея подобное, эту вашу задачку решит любой начинающий. ))) Просто это дело находится (видимо) в стандартной библиотеке языка, а описания к ней в текущей документации на язык нет, так что не обладая установленной средой (и не полазив по исходникам) vdimas'у довольно проблематично было дать красивый ответ. Но теперь то, что вы продолжаете цепляться? Или всё ждёте этот пример школьного кода? )


V>Красиво ответить можно было и без этих базовых интерфейсов на основе того решения, которое я уже описал словесно раз пять — через подачу делегата в стиле IoC...


V>Всё намного проще. Я пока тупо тянул время, бо в эти выходные ни с какой виртуалкой макоси возиться не собирался.


Все почти верно, кроме одной детали — тянуть время ты можешь годами, или выдать "пфф любой студент за два часа, мы не в детсаде"
Вспомнишь сам или ссылкой дать ?
Re[2]: А вот и сравнения скорости Swift с Objective-C подоспели
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.06.14 21:15
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>В лучшем случае Swift в 7.9x раз медленнее чем Objective-C. Результат, конечно, не ахти, но то что язык находится на стадии бета-тестирования, оставляет надежды а оптимизацию по скорости.


KP>P.S. тесты ну ооочень синтетические.


Даже по этим синтетическим тестам видно, что язык пока что конкурирует с динамическими языками. С учетом того, что objective c отстаёт от модных компилеров С++, то разница между свифтом и objective от 7 до 49 раз это мягко говоря отстой. Шота выглядит как "с места и в лужу"
Re[16]: Swift
От: alex_public  
Дата: 08.06.14 23:22
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Скорее всего компилятор в режиме максимально-глубокого вывода типов для интелисенса пытается рекурсивно выводить типы, но конца этому процессу для конкретно этой задачи НЕТ. ))


Т.е. ты предполагаешь, что при работе с IDE компилятор Swift'a работает в особом режиме, а из консоли его примеры компилировались бы?

V>Кароч, по-настоящему эту задачу способны решить только языки с полной поддержкой зависимых типов, а к ним ни C#, ни Swift, ни Хаскель не относятся.


V>Но что характерно, что текущая система шаблонов С++ ПОЗВОЛЯЕТ в будущем добавить поддержку зависимых типов без какой-либо переделки синтаксиса (правда, с текущим ограничением на целочисленный аргумент зависимого значения). Т.е. система типов Swift тоже в будущем сможет быть развита до аналогичного. А вот в C# — никогда и ни при каких обстоятельствах. Принципиально невозможно. Вот так по-дебильному (C) дизайн генериков сделан. Так шта, накося выкуси. )))


Ну так я же уже давно показывал решение этой задачки и на текущем C++: http://www.rsdn.ru/forum/philosophy/5513403
Автор: alex_public
Дата: 13.03.14
.

V>Более того, при полноценной поддержке зависимых типов в этой задаче исчезает надобность рекурсивного определения типов, за "глубину" будет отвечать целочисленное значение, определяющее точный тип. Так шта, XCode падать не будет. ))


Да, да, у меня именно так и вышло. )
Re[16]: Swift
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 09.06.14 03:23
Оценка:
Здравствуйте, vdimas, Вы писали:

V>А почему не просто?


Ты хоть читал ссылку-то?

V>http://migmit.livejournal.com/54465.html

V>Сию задачу разбирали здесь минимум дважды.

При чем тут сама задача? Ты совсем не умеешь отвлекаться от деталей и видеть смысл?
Смысл простой: компилятор очень падучий, и XCode вместе с ним. Потому тестировать сложно. Про задачу забудь, не о ней речь.
Даже проще примеры были: при попытке описать рекурсивный алгебраик компилятор сегфолтится.
Re[3]: А вот и сравнения скорости Swift с Objective-C подоспели
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 09.06.14 04:22
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Даже по этим синтетическим тестам видно, что язык пока что конкурирует с динамическими языками. С учетом того, что objective c отстаёт от модных компилеров С++, то разница между свифтом и objective от 7 до 49 раз это мягко говоря отстой. Шота выглядит как "с места и в лужу"


КОгда говоришь о Бета-версии какого-либо языка, стоит обсуждать предлагаемую им концепцию, но никак не производительность или стабильность сгенерированного кода. Это я не к тому, что Swift – это круто, я его еще даже не смотрел, а к тому, что другие составляющие куда как важнее
Re[2]: А вот и сравнения скорости Swift с Objective-C подоспели
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 09.06.14 07:05
Оценка: 7 (1)
Здравствуйте, kaa.python, Вы писали:

KP>http://www.splasmata.com/?p=2798

KP>P.S. тесты ну ооочень синтетические.

Вот тут еще жыр:
http://stackoverflow.com/questions/24101718/swift-performance-sorting-arrays
Re[3]: А вот и сравнения скорости Swift с Objective-C подоспели
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 09.06.14 07:18
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Вот тут еще жыр:

DM>http://stackoverflow.com/questions/24101718/swift-performance-sorting-arrays

Да, интересно. Если почитать ответы, то получается что скорость Swift не уступает скорости Си, что приколько, я считаю
Re[4]: А вот и сравнения скорости Swift с Objective-C подоспели
От: MxMsk Португалия  
Дата: 09.06.14 07:32
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Да, интересно. Если почитать ответы, то получается что скорость Swift не уступает скорости Си, что приколько, я считаю

Он же вроде не уступает, если там отключить рантайм проверки. Это.. гм.. как бы не safe, что декларируется, как фича. Кстати, тебя не смущает, что язык проприетарный, да еще и заточенный под одну платформу?
Re[5]: Язык проприетарный
От: Qbit86 Кипр
Дата: 09.06.14 07:37
Оценка:
Здравствуйте, MxMsk, Вы писали:

MM>Кстати, тебя не смущает, что язык проприетарный, да еще и заточенный под одну платформу? :)


О, так ты всё пропустил. Эту тему уже размусолили до состояния отпочковывания кусками в КСВ и прочий Мусор.
Глаза у меня добрые, но рубашка — смирительная!
Re[5]: А вот и сравнения скорости Swift с Objective-C подосп
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 09.06.14 07:41
Оценка:
Здравствуйте, MxMsk, Вы писали:

MM>Кстати, тебя не смущает, что язык проприетарный, да еще и заточенный под одну платформу?


Я пока не смотрел по нему доки, но если это именно что "замена Objective-C", т.е. язык для работы с Cocoa которой ни на каких платформах кроме как от Apple не существует, то нет, не смущает. Если же говорить о проприетарности, то исходя из политики Apple по отношению к другим низкоуровневым разработкам (LLVM, Clang, Darwin) я думаю что его откроют вскоре после релиза.

P.S. но я с UI дела практически не имею, так что у меня к языку разве что чисто академический интерес может проснуться (пока мне на него пофигу).
Re[4]: А вот и сравнения скорости Swift с Objective-C подоспели
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.06.14 08:00
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>КОгда говоришь о Бета-версии какого-либо языка, стоит обсуждать предлагаемую им концепцию, но никак не производительность или стабильность сгенерированного кода. Это я не к тому, что Swift – это круто, я его еще даже не смотрел, а к тому, что другие составляющие куда как важнее


Судя по SO все еще хуже, чем по твоей ссылке — разница на порядок даже если сравнивать с питоном. Не понимаю как можно было прикрутить проверки тиа выход за границу массива и тд, что бы это работало хуже чем питоне
Re[11]: Swift
От: Klapaucius  
Дата: 09.06.14 09:07
Оценка:
Здравствуйте, Нахлобуч, Вы писали:

Н>Какой словарь?


Набор функций. В данном случае арифметических. Эта техника называется "dictionary passing".
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[13]: Swift
От: Klapaucius  
Дата: 09.06.14 10:18
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Да нет. Оказывается, что ad-hoc полиморфизм не поддерживается в полной мере генериками дотнета, только и всего. Иначе бы он сам подхватывал переопределённые операторы.


Дженерики — это параметрический полиморфизм. Никакой ad-hoc полиморфизм они поддерживать и не должны. И никакого "подхватывания операторов" не нужно. Нужно делать как в моем примере реализовано, только с автоподстановкой словарей и подправленным синтаксисом, чтоб ограничения квантификации нормально выглядели, можно было операторы использовать и т.д.
Ну и классы типов/имплементации должны в стандартной библиотеке быть.

V>Если в полноценной реализации, то нужен, ес-но. Но для привычного ООП он почти всегда "недо-", бо идет только по первому аргументу this.


Продемонстрированная мной техника это ограничение обходит.

V>Ну а что делать, если всё кривое? )))


Делать прямым там, где возможно. Обсуждаемое сделать прямым можно одними средствами компилятора, все что для этого нужно (более-менее нормальный полиморфизм, инлайн методов структур и т.д.) CLR уже поддерживает.

V>Ты продемонстрировал костыль в условиях "недо-".


Это менее костыльно чем всякие "подхватывания". Недоделанность дотнетных дженериков совсем не в этом, а в том, что от конструктора типа нельзя абстрагироваться, нету higher-kinded полиморфизма. Ну так с этим и в сабже проблемы.

V>Нет. Зависимость конкретных типов T->C должна быть неявной. Явное её указание — избыточность, делает решение недо-обобщенным.


Явное указание — это, конечно, избыточность, но "недообобщенным" оно решение не делает.

V>Можно так:

V>
V>T Avg<T>(this IEnumerable<T> xs) where T : INumber<T>, new()
V>

V>Как и в Хаскель, собсно. (только с той разницей, что в дотнете INumber<T>, сцуко, описывает контракт только по одному аргументу this... но и этого могло бы хватить для арифметики)

Нет, ключевое отличие тут в том, что ":" задает отношение подтипирования, которого в хаскеле нет. В моем решении его (между T и C) также нет и не должно быть.

V>Я тебе уже показал абзацем выше аналог на C# того, как это есть в Хаскеле. Заканчивай уже спекулировать.


Нет, это не аналог того, что есть в хаскеле. Аналог того, что есть в хаскеле показал я.

V>Ес-но, реализация арифметических операторов для Complex должна быть где-то описана. Но не дважды же!


Ну так она и не описана дважды:
public struct ComplexReal : CReal<Complex>
{
    public Complex Div(Complex a, Complex b) { return a/b; }
    public Complex Add(Complex a, Complex b) { return a+b; }
    public Complex FromInt(int a) { return new Complex(a,0); }
}

вызываются библиотечные реализации сложения и деления. Если бы мы сами определеяли Complex — могли бы не описывать операции только для Complex, а определить их прямо в имплементации класса. И тот и другой подход используются в хаскеле.

V>В Хасклеле бери любую либу с каким-нить MegaComplex, да пользуйся. А в твоём решении на C# надо еще раз по операторам пройтись да продублировать их. Что-то не так в консерватории, не правда ли? ))


Очевидно, что надо просто положить инстансы в библиотеку и все, как в хаскеле обычно и делается.
Но нередко бывает и так, когда библиотека нужных инстансов не содержит. Тогда пользователь сам описывает инстансы-"сироты". Что собственно я и зделал в своем примере на C#.

V>Ммм... ты действительно не понял пару постов выше намек на то, как это надо было сделать в C#? ))


Понял, но я не согласен с тем, что в C# надо так делать. Надо было делать именно как я показал.

V>Блин, ты же сам всё правильно говорил про Хаскель! Модель типов дотнета позволяет делать так же. Просто не сделано для встроенных типов.


Продемонстрированная мной техника позволяет определять инстансы для любых типов.
В хаскеле, кстати, для "встроенных" типов полиморфизм вообще не поддерживается.

V>Но даже при этом можно было бы арифметические операторы подхватывать автоматом и на этапе генерации бинарников подставлять в тела генериков нужный код. Даже можно обойтись существующим стандартом на метаинформацию и байт-код, достаточно компилятором генерить фиктивный IOperators<> в байт-коде, а во время JIT-а просто знать этот интерфейс "в лицо" и при его фиктивной реализации просто подставлять статически-переопределенные операторы, тогда тебе не надо было бы ручками описывать свой ComplexReal.


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

V>А зачем параметрический полиморфизм в сценариях, где уточненные типы выводятся еще на этапе компиляции?

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

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

V>Насмешил. В Хаскеле не всегда параметрический полиморфизм нужен в рантайм. 99% сценариев разруливаются на этапе компиляции, т.е. обобщенное программирование в этих сценариях не далеко ушло от С++ — обычная "текстовая подстановка" в итоге. Собсно, даже формат библиотек Хаскеля — это упакованный и размеченный результат парсинга текста (считай тупо AST исходников либы), а не объектный код.


Нет, это код, с которым могут поставляются, а могут и не поставляться "развертки", т.е. результат парсинга части кода. Развертки могут использоваться для оптимизации, но все работает и без них — просто медленнее. Это техническая деталь реализации межмодульной оптимизации, реализация параметрического полиморфизма от этого не зависит.
Упомянутый 1% сценариев — это экзистенциальные типы, там словарь действительно не может быть подставлен в комайл-тайм и ссылка на него хранится в объекте, как в ООП.

V>>>1. Ты ничего не решил, готового к использованию изкаробки обобщенного решения так и не было. В дотнете автоматическое решение возможно только на рефлексии, увы.


K>>Потому, что дотнетные разработчики (а точнее, принимающие решения) не читатели и не моргнув глазом пустили в свободное плаванье дизайнерское решение, которое целый фрактал проблем порождает.


V>А конкретно в этой ветке мне постарались надавать по щщам именно из-за попытки сравнения со "священной коровой". Я лишь заметил, что многих проблем C# в Swift нет.


Я сильно сомневаюсь, что обсуждаемая проблема в сабже решена нормально, а не в стиле C++.

V>Я не спорю, что до "чистых" языков ему далеко. Это гибрид и как любой гибрид состоит из компромиссов. Но в C# есть даже такие компромиссы, увы, которые вовсе не требовались. И ты наглядно их показал в своей собственной реализации yet another IArithmetic<T>.


Похоже на то, что и в сабже таких "компромиссов", которые не требовались, хватает.

V>И всё-таки в джаве и дотнете не в языке гвоздь, а в миллионах строк библиотек со сложным, но достаточно надежно оттестированным функционалом.


Ну да, правильно.

V>Хотя для value-типов для тех же генереков JIT генерит код, который нигде по-факту методы интерфейсов не вызывает!


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

V>Т.е. сие ограничение интерфейсов только на экземплярные методы можно было бы обойти, добавив возможность задавать некий "интерфейс для статических методов", как раз арифметика туда попала бы, а связь T->C в твоём примере была однозначной и не требовала бы явного задания. (Это был бы, конечно не интерфейс в ООП-смысле, а чистый "контракт", бо интерфейс описывает лишь контракт на экземплярные методы).


Зачем какие-то загадочные "интерфейсы для стат.методов" придумывать, если можно просто красиво оформить передачу словаря, т.е. описанную мной технику?

V>Что касается по-делу. Параметрический полиформизм генериков C# показывает свою силу только в рекурсивных, относительно типов, сценариях


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

K>>Собственно, всякие костыльные воркараунды — единственные способы писать обобщенный код в индус триальных языках

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

Что-то не похоже. Вон https://github.com/maxpow4h/swiftz уже какие-то бедолаги мучаются.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[12]: Swift
От: Klapaucius  
Дата: 09.06.14 10:49
Оценка:
Здравствуйте, vdimas, Вы писали:

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


"Детерминированные требования к памяти" — это красиво звучит, но на практике означает только, что менеджер памяти там выигрывает по латентности у нормального ГЦ ценой проигрывания throughput и чуть менее чем всех языковых фич. ничего интересного в этом аспекте сабж не предлагает.
Хорошей производительности бинарника в сабже, я думаю, не будет, никто не станет ее до уровня плюсов доводить, останется на уровне "языков, использующих LLVM".
Т.е. код а ля лапшефортран будет работать со скоростью не сильно больше той, которую аналогичный код в лапшефортранном стиле на хаскеле показывает, а в случае сколько-нибудь высокоуровневого кода он хаскелю вообще проиграет.

По поводу суперкомпиляций и настоящего ФП.
1) На производительность низкоуровневого кода "настоящего ФП" она никак не повлияет, а проблема производительности высокоуровневого кода нигде не решена.
2) Я не особо верю в перспективы суперкомпиляции для языков без проверки завершимости, хотя я особо не разбираюсь в суперкомпиляии, я интересуюсь больше более простыми и практичными техниками, которые под это определение не подпадают.
3) Проблемы с производительностью низкоуровневого кода в "настоящем ФП" худо-бедно решаются использованием готовых бэкендов, на которые тратятся значительные (по сравнению с теми, что на ФП тратятся) человекочасы вроде LLVM. Остаются проблемы, которые рантаймом обусловлены, вроде дороговизны изменяемых массивов ссылок и т.д., в случае которых компилятор ничем не поможет.
4) Производительность вообще не главная проблема "настоящего ФП", многие популярные языки никаких успехов по части производительности кода никогда не показывали и не покажут.
Да и от сабжа я их не жду.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[9]: Swift
От: Klapaucius  
Дата: 09.06.14 11:02
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

K>>Нет, вывести такое следствие не из чего. Вот если бы были языки с равными инфраструктурами и сильно различающиеся по фичам — тогда можно было бы какие-то выводы делать.

I>Хорошая инфраструктура почему то появляется только для самых убогих языков с твоей точки зреня. Тебе самому не смешно ?

Ну конечно не самых убогих. Но не далеко от этого. Посмотрите на список ваших "наиболее востребованных". Много ли языков более убогих чем они? Вот то-то и оно.

I>А что ты имел ввиду под требованием к качеству реализации ? Эти требования определяются исключительно ценой ошибки, а не применяемым языком.


Под требованием к качеству реализации я имел в виду хороший оптимизирующий компилятор или, например, продвинутый рантайм с нормальным сборщиком мусора (точным, перемещающим, с поколениями, параллельным и т.д.), поддержкой SMP. У 90% языков какой-нибудь Боэм, или треш-угар с подсчетом ссылок, если язык "академиеский" — может еще быть Чейни на страницу кода, написанный студентом за вечер. Никакого SMP, конечно.

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


Для паттерн-матчинга?

I>ФЯ смотрятся хорошо только в высокоуровневых алгоритмах, если их тяжело перевести в императивный вид. В низковровневых вещах разница любого ФЯ с простецким Си минимум в несколько раз.


ну так а я о чем? "Ну вот, вы же сами написали, что все, кроме C и C++. Остальные это ведь не только пара-тройка ФЯ но и бразиллион языков никакого отношения к ФП в основном не имеющих. Как видите, страшный синтаксис им никак не помог. При этом сабж явно не окажется в категории С/C++, а наоборот — в категории "остальные", в которой ФЯ часто смотрятся в смысле производительности очень хорошо. "

K>>Вопрос был в том, зачем делать убогим, если можно не убогим? Что мешает-то?


I>Полноценный ПМ можно всунуть только в полноценный ФЯ, со всеми его проблемами — перформансом и потреблением памяти. Это очень дорогая фича.


Не согласен, в отличие от комбинирования комбинаторов, которое если попытаться сделать нормально — целый "полноценный ФЯ" за собой притянут, паттерн-матчинг — фича достаточно консервативная.

K>>Нет, я не про убогие возможности, а именно про навороченность синтаксиса.

I>В мейнстриме в код лазят самые разные люди, с разными скилами. Сишный синтаксис это своего рода костыль для таких вот людей, снижает уровень вхождения.

Вообще-то речь про всякие ужасы, которые читаются "по спирали" и т.д. Это уровень вхождения снижает? Серьезно?
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[10]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.06.14 12:13
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


K>Для паттерн-матчинга?


Именно.

I>>Полноценный ПМ можно всунуть только в полноценный ФЯ, со всеми его проблемами — перформансом и потреблением памяти. Это очень дорогая фича.


K>Не согласен, в отличие от комбинирования комбинаторов, которое если попытаться сделать нормально — целый "полноценный ФЯ" за собой притянут, паттерн-матчинг — фича достаточно консервативная.


Тем не менее фича очень дорогая в использовании. Скажем в менеджед языках после декомпиляции получается какой то тихий ужас. В том же F# небольшая программа на страницу текста даёт восемь страниц генеренного кода.

I>>В мейнстриме в код лазят самые разные люди, с разными скилами. Сишный синтаксис это своего рода костыль для таких вот людей, снижает уровень вхождения.


K>Вообще-то речь про всякие ужасы, которые читаются "по спирали" и т.д. Это уровень вхождения снижает? Серьезно?


Что значит 'читаются "по спирали"' ?
Re[11]: Swift
От: Klapaucius  
Дата: 09.06.14 12:41
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Тем не менее фича очень дорогая в использовании. Скажем в менеджед языках после декомпиляции получается какой то тихий ужас. В том же F# небольшая программа на страницу текста даёт восемь страниц генеренного кода.


Да, я видел, что F# плохо компилирует ПМ, но это проблема конкретной реализации, ПМ можно и хорошо компилировать. Там проблема не в объемах кода — написание разбора вручную тоже даст существенно больше кода, там проблема в том, что проверки, которые уже сделаны делаются снова и снова.

I>Что значит 'читаются "по спирали"' ?


Вторая картинка в гугле по запросу "clockwise spiral rule"
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[10]: Swift
От: AlexRK  
Дата: 09.06.14 13:34
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Не согласен, в отличие от комбинирования комбинаторов, которое если попытаться сделать нормально — целый "полноценный ФЯ" за собой притянут


Ради интереса: можно в двух словах, зачем нужно комбинирование комбинаторов и что это вообще такое?
Нечто типа порождения функций из неких примитивов? Если да, то в чем преимущество перед простым вызовом одной функции из другой?
Re[3]: А вот и сравнения скорости Swift с Objective-C подоспели
От: alex_public  
Дата: 09.06.14 13:52
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Вот тут еще жыр:

DM>http://stackoverflow.com/questions/24101718/swift-performance-sorting-arrays

Ого, при соответствующей опции компилятора получаем быстродействие как у C++? Похоже я был прав в предположение об отличном дизайне (в стиле D) языка.

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

P.S. И откуда ты постоянно такие полезные достаёшь? )))
Re[4]: А вот и сравнения скорости Swift с Objective-C подоспели
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 09.06.14 14:24
Оценка:
Здравствуйте, alex_public, Вы писали:

_>P.S. И откуда ты постоянно такие полезные достаёшь? )))


C reddit'a обычно.
Re[12]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.06.14 15:00