Все ЯП одинаково бесперспективны: нейросети всех зарулят.

Твоя информация уже устарела, мой толстый друг. Сейчас самое модное направление в науке о псевдоинтеллекте Liquid State Machines.

>Сейчас самое модное направление в науке о псевдоинтеллекте Liquid State Machines.

Кстати, на этом движке анонимусы на лоре работают.

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

Что касается самого IDisposable, то это - более общая штука нежели RAII. Посмотри на то, что позволяет делать Observable в F#. Я уж не говорю про Async.AwaitObservable, если ты понимаешь о чем это.

> И да, как замена C D или vala подходят существенно лучше, как по концепции, так и по дизайну и реализации, не говоря о наборе библиотек (но это дело наживное).

vala — как замена C? эээээээээ... по-моему, vala — это такой местечковый язычок, пригодный для написания gtk/gobject гуя. в этой роли мне он ах как нравится.

Спасибо, начал ознакомление с книжкой.

В рамках моих текущих знаний, отвечу на некоторые поднятые вопросы.

Системный ли язык, на infoq выложено интервью с создателем языка, он ясно дал понять, что Go не позиционируется как системный язык для написания ОC. Там же как основное достоинство языка (помимо безопасности), названы быстрая компиляция и потенциальная возможность «допилить» скорость исполнения до скорости близкой к C/C++. Еще одной чертой названа предсказуемость поведения - GC будет работать, но ваши знания по работе с управляемой памятью пригодятся и здесь, минимизируете количество создаваемых объектов для быстрого исполнения программы и т.д... (значит не такой умный GC)

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

По скорости можно сравнить go с C#/mono, http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=go&lang2=cs...

как видно рантам Go занимает значительно меньше памяти чем mono, правда в скорости Go отстает на столько же, в процентном соотношении. Считаю Go вполне можно рассматривать как перспективный язык для написания десктопных приложений.

http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=c...

тут результаты получше

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

>Почему нет? IDisposable.

Афтар, ты сам писал на С# или чисто теоретически говоришь? Я просто с c# 3.0-4.0 дело имел до 10 февраля сего года и RAII там не работало(msvs10+.net4.0+сервелат4). Если появилось - скажи, а то мне из под линуха не проверить.

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

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

Ок.
http://9fans.net/archive/2000/06/543
«I tend to think the drawbacks of dynamic linking outweigh the advantages for many (most?) applications.» — John Carmack

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

>но можно ли создавать ОС/процессоро-независимые бинарники, если пишешь на Vala?

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

>Не совсем понял, чем помогли бы плюсы в такой ситуации.

Не понимаешь, что если я в плюсовом классе заменяю мембер T array[][][] на my_cool_array< T > array, то мне больше ничего и нигде править не нужно - деструктор автоматом выполнится? А если я в шарповом классе так делаю и (MyCoolArray is IDisposable), то мне надо этот класс тоже сделать IDisposable и реализовать 3(!) метода. Потом рекурсивно повторить тоже самое с полученным классом. Дальше я должен посмотреть по коду, как используются полученные классы. Раньше за меня их удалял GC, а теперь мне надо грамотно расставить using'и. Не знаю, как можно понятнее написать.

И мне все же кажется, что ты склонен к преувеличению.

Уверен, это следствие первого пункта.

Что касается самого IDisposable, то это - более общая штука нежели RAII.

Мне кажется, в C++ можно перенести модель IDisposable из шарпа. А RAII из плюсов в шарп перенести нельзя.

Посмотри на то, что позволяет делать Observable в F#. Я уж не говорю про Async.AwaitObservable, если ты понимаешь о чем это.

Как все это доказывает преимущества IDisposable? Про невообразимые новые возможности фреймворка, евангелисты твердят каждый релиз, при этом базовые вещи работают через ж*пу и в святая святых FCL годами висят баги.

Да, про WPF забыл. Хороший пример. Если хочется завязаться на компанию с нехорошей репутацией, забыть про кроссплатформенность, любую простейшую задачу решать через любовный треугольник MVVM/XAML/???, получить тормоза в отрисовке контролов на офисных карточках, мыло при прорисовке шрифтов, тянуть под гиг(!) зависимостей. Если без всего этого в проекте не обойтись, то WPF - оптимальный выбор.

Кармак спятил

Я еще пойму, когда пишут какой-нибудь регистро-прожорливый код для i386, которому надо дергать много-много статических переменных. Да, жалко регистр ebx или ecx отдавать для pic-адресации, и делать

call __i686.get_pc_thunk.bx[br]
...[br]
__i686.get_pc_thunk.bx:[br]
     mov (%esp), %ebx[br]
     retn

> Не понимаешь, что если я...

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

> Мне кажется, в C++ можно перенести модель IDisposable из шарпа.

Упомянутый мною Observable перенести нельзя. Нужны замыкания.

> Как все это доказывает преимущества IDisposable?

Почему обязательно что-то должно одержать верх? IDisposable и RAII хороши по своему. Первое - дитя дотнета. Второе - порождение Си++. Все зависит от того, с каким инструментом работаешь.

Ну там ещё есть проблема с fork, например:
http://9fans.net/archive/2009/02/422

Это конечно хорошо, но зачем??? Как уже достали эти создатели 100500-ых языков программирования, которые никому кроме этих создателей не нужны. Имхо они впустую тратят время, лучше бы занялись чем-то полезным, например допиливанием существующих проектов на С/С++. Так нет же, не только свое время убивают, так и другим стараются навязать изучение своего никому не нужного поделия.

Тут очень подробно:

http://harmful.cat-v.org/software/dynamic-linking/

http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols

А в чём плюсы?

А в чём плюсы?

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

2) В Vala есть смысл и предназначение, в Go он отсутствует

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

Первая часть имхо удалась, а вторую они обещают допилить — он ещё в активной разработке.

http://www.linux.org.ru/jump-message.jsp?msgid=5976068&cid=5984688
И в конце-концов, и ЯП должны развиваться.

RAII там нет. Там есть using, IDisposable и Dispose. Плюсы и минусы обсосан выше.

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

Думаю, это в майкрософт была неправильная постановка задачи, не учитывающая возможного роста, раз мне пришлось их косяк обходить. Или вы считаете, что ограничение в 2Гб - это нормально для массива в 64-битной системе? Хотя, там и похлеще косяки есть.

Но дело не в них, а в том, что любое нелокальное использование IDisposable вызывает лавинообразные изменения в коде, вследствии своей вирусной природы (все, что содержит IDisposable тоже становится IDisposable).

Упомянутый мною Observable перенести нельзя.

Непонимаю, откуда взялся Observable. Речь была про IDisposable. Нельзя же рассчитывать, что я по окончаниям слова распознаю.

Нужны замыкания.

С++0x lambda? boost::function?

Почему обязательно что-то должно одержать верх?

Я не о верхе веду речь, C++ и дотнет на разных полях играют. Просто встретив утверждение, что IDisposable/using адекватная замена RAII - не мог не отреагировать, как честный человек.

Чаще сообщайте другим людям, как им нужно потратить своё время, и вас все будут любить и уважать!

По-моему оно вполне адекватное, если сразу признать, что все ваши классы должны реализовывать IDisposable, и вписать это в code style. %)

> При портировании на 64 бита выяснилось, что шарповые массивы ограничены 2Gb

А нельзя пояснить, это ограничение .NET или CLR/CIL? То есть в моно тоже самое? Из msdn я не понял причину этого ограничения.

Да, реакция была адекватной. А Observable - это одно из применений IDisposable. Очень заметное и важное. Для тех, кто не ограничивает себя сишарпом в дотнете.

> С++0x lambda? boost::function?

Лучше не надо об этом ;)

>По-моему оно вполне адекватное, если сразу признать, что все ваши классы должны реализовывать IDisposable, и вписать это в code style. %)

Если все наши классы реализуют IDisposable - это означает переход на полностью ручное управление памятью. Забыл где-то поставить Dispose или using - получил утечку. NET-программисты не привыкли к подобным жестокостям и не готовы отказываться от GC. И потом много повторяющегося кода утомляет и раздражает. Вот каноничная реализация IDispose: http://msdn.microsoft.com/en-us/library/system.idisposable.aspx#Y882 Dispose + Dispose(bool) + Finalizer. Представь, что это в каждом классе. Еще остается проблема того, что Dispose - обычный в общем-то метод, который любой дурак может дернуть. В результате, если ты получаешь на вход ссылку на IDisposable, ты не можешь быть уверен, что это не зомби уже какой-нибудь. С целью защиты от потусторонних сил, в Control даже ввели костыль в виде IsDisposed. Пишешь предусловие (еще один костыль) " Contract.Requires<ArgumentException>(!foo.IsDisposed)" и немного легче на душе, хотя по сути лучше не стало.

> Если все наши классы реализуют IDisposable - это означает переход на полностью ручное управление памятью.

Это как это? Без using GC объекты IDisposable не удаляет? Вроде удаляет.

>А нельзя пояснить, это ограничение .NET или CLR/CIL? То есть в моно тоже самое? Из msdn я не понял причину этого ограничения.

По-моему, это детали реализации от майкрософт. В спецификации вообще не нашел упоминаний об этом ограничении, на него намекает только this[ Int32 ]. При этом наличествует LongLength и GetValue(Int64). Какое-то наркоманство, на мой взгляд. В некоторых случаях можно конечно ломаным массивом эмулировать.

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

>Это как это? Без using GC объекты IDisposable не удаляет? Вроде удаляет.

IDisposable же для того и введен, что нужно удалить не когда-нибудь, когда GC посчитает нужным, а сейчас, иначе будет плохо. Ресуры != память != управляемая память.

добро пожаловать в реальный мир, нео.

это накладные расходы на создание внутренних таблиц в линуксе.

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

>Да, реакция была адекватной.

Что не так, по твоему мнению? Готов исправиться.

А Observable - это одно из применений IDisposable.

Речь об IObservable из Rx? Его нельзя в шарпе использовать?

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

Да. Следующий шаг - дотнетом себя не ограничивать.

>Она обещают неблокирующий сборщик мусора

В деревне Виллариба всё еще пользуются GC, а в Виллабаджо пользуются slabом.

>допиливанием существующих проектов на С/С++

Милейший, жрите это говно сами. Приятного аппетита.

> В деревне Виллариба всё еще пользуются GC, а в Виллабаджо пользуются slabом.

офф: ариба это верх, абахо это низ, так что идеологически: в Виллариба живут хорошо, а в виллабаджо плохо.

> В деревне Виллариба всё еще пользуются GC, а в Виллабаджо пользуются slabом.

«slab» - это slab allocator? Причем он к сборке мусора?

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

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

Вот неандертальцы тоже утверждали, что «будущее за каменными топорами, так как ими пользуется большинство», но неожиданно вымерли.

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

ничего не имею против языка D и даже как в последствии выяснилось ничего против vala - они привносят нововведения и инновации, и не стремятся лепить горбатого на пустом месте, где это не нужно, так как это делает Go

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

позвольте не согласиться, чем вас GTK# не устроил? не наблюдаю трагедии

>позвольте не согласиться, чем вас GTK# не устроил? не наблюдаю трагедии

Трагедия в том, что GTK# выглядит в Windows так же страшно, как WinForms в Linux. О маке что уж и говорить. Т.е. приемлимый кроссплатформенный гуй на нем не построишь.

>Ещё одни любители комбайнов?

Разумеется. Я вообще предпочту использование техники изнурительному ручному труду и это не только к сельскому хозяйству относится.

а что писать еще на go? это ж даже не замена пхп.

> Разработчику не надо заботится о расшаривании кода.

А при статической линковке надо, что ли?

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

Какую проблему?

Если ты об использовании файловых серверов вместо библиотек, то это вовсе не для экономии памяти (такая задача не стоит), а для распределения сложности и масштабирования. Ты можешь использовать некоторый сервис прямо из шелла, и можешь делать это прозрачно по сети. ОС не просто управляет аппаратными ресурсами - она помогает пользователю решать задачи. И нет нужды в монструозных фреймворках, DE и т.п.

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

Какую проблему?

Кстати да, какую проблему решает статическая линковка? %)

> Кстати да, какую проблему решает статическая линковка? %)

Это вопрос ко мне?

Да.

Решает задачу получения готовой к запуску программы из прекомпилированных модулей. А что?