Маргинальщина во все поля

Почему никто не просит(?

Конфиг емакса в студию:)!

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

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

И чем он перспективней? Чем erlang? :-)

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

Дебиан и так маргинальный на десктопах:-)

а шрифт в дебиане дефолтный Sans без хинтинга?

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

Мощь. И что, это сильно помогает? Он что, в силу этой своей особенности самодоказывает код? :)

Может быть ты вообще не понимаешь что значит «доказать код»?

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

Ну и чем Go перспективней Ocaml?

Может не понимаю, почему-то подумал про математически доказанный код, как в хаскеле. Подумал что окамл требует этого.

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

Ну и чем Go перспективней Ocaml?

За Go стоит гугл.

Может не понимаю, почему-то подумал про математически доказанный код, как в хаскеле. Подумал что окамл требует этого.

Ocaml как и любой другой язык этого не требует. Доказательства требуют требования к системе. Это вообще-то азбука.

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

Sun продвигала Java. Microsoft продвигала С#. Вот и Google типа продвигает Go. И что с того?

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

За Go стоит гугл.

Я в курсе.

И что? Это как-то позитивно влияет на качества языка?

Ну и чем Go перспективней Ocaml?

За Go стоит гугл.

Это как-то позитивно влияет на качества языка?

А кто-то говорил о качестве языка?

Sun продвигала Java. Microsoft продвигала С#. Вот и Google типа продвигает Go. И что с того?

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

А кто-то говорил о качестве языка?

Косвенно - да.

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

Вот это новость.. И что с того? Вон для крестов сколько всего наплодили. А что в результате? Мерзостное зрелище. Реактивные самолёты на конской тяге.

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

Если для Вас эталоном качества являются inferno, haskell и LISP, то уж лучше чтобы реальность была такова, как она есть сейчас.

Ну а возвращаясь к Вашей изначальной рекоммендации, что стоит рассмотреть Go как альтернативу доказанному Ocaml, то наиболее прямой аналогией будет такая: инженерам Ferrari заявили, что нечего им париться с композитными материалами и поиском оптимальной формы кузова, ведь простая коробка из чугуна не располагает заморачиваться такой ерундой. Ну и материал безусловно популярнее и ближе к народу. Стало быть можно легко найти чуваков, что за бутылку выточат корпус.

А кто-то говорил о качестве языка?

Косвенно - да.

Вспоминается старая шутка «Любую проблему CS можно решить, введя дополнительный уровень косвенности».

Если для Вас эталоном качества являются inferno, haskell и LISP, то уж лучше чтобы реальность была такова, как она есть сейчас.

Приведете пример более качественных решений?

инженерам Ferrari ... коробка из чугуна

И чем же окамл настолько лучше го?

Приведете пример более качественных решений?

У каждого - своё представление о качестве.

Идеальных языков нет. У каждого есть сильные и слабые стороны.

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

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

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

У крестов система типов более-менее близкая к железу обычных компьютеров, неплохая скорость (если писать код не через пень-колоду), инструментарий не идеален, но и не ужасен. При этом совершенно перегруженный фичами язык (особенно С++11), где одно лишь сообщение об ошибке может занимать пять экранов. Ну и почти нереально доказать корректность кода.

И чем же окамл настолько лучше го?

Попробуй мыслить логично.

Я не утверждал, что окамл лучше чем го. Я утверждал, что го НЕ лучше окамл. Видишь неэквивалетность утверждений?

А уж в контексте доказанного кода тем более не лучше. Ты можешь написать или сгенерить на Go код скажем для реализации trie так, чтобы он был гарантированно 100% корректен? Нет. В Go ты будешь колбасить unit тесты, ловить баги и возиться с дебагерром. А ymn на это время тратить не будет. :-)

Вспоминается старая шутка «Любую проблему CS можно решить, введя дополнительный уровень косвенности».

Вспоминается один советский юморист на букву П.

Я не утверждал, что окамл лучше чем го. Я утверждал, что го НЕ лучше окамл. Видишь неэквивалетность утверждений?

Да. Ты утверждаешь, что Окамл лучше Го или на его уровне.

Вспоминается один советский юморист на букву П.

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

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

А в окамле я навскидку не вижу средств для concurrent программирования.

А в окамле я навскидку не вижу средств для concurrent программирования.

Я тоже не вижу. И?

У нас учитель информатики точно так же объясняет всегда. Руками машет, глаза закатывает, какие-то байки вспоминает. Ни разу ещё ничего не угадал.

Вот такая история
!

подскажите какой у gds'а ник здесь

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

Ну это, считай, как C++: баланс понтов и скорости. Так-то «Приус» и весит меньше, и по коэффициенту лобового сопротивления или даже дальше ушёл, или где-то близко, но не едет, да и выглядит, как кусок гогна. А инженеры Феррари бьются за секси лук и попутно борются с проблемами, которые этот лук создаёт.

А если расширить аналогию, то Коммон Лисп, значит, это Бентли Континенталь.

У нас учитель информатики точно так же объясняет всегда. Руками машет, глаза закатывает, какие-то байки вспоминает. Ни разу ещё ничего не угадал.

Ты и не представляешь себе, насколько всем ценно твое мнение, о Великий Писатель Хеллоуорлдов.

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

Великий Писатель Хеллоуорлдов

Чёрт, а ведь обидно.

Чёрт, а ведь обидно.

В международной политике это называется «симметричный ответ».

Зато имакс недефолтный

Дефолтный имакс? Ну если он установлен, только чтобы понтоваться.

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

* IDE, понимающее контекст и на основе этого предлагающее автодополнение, рефакторинги, поиск в документации и т.д. А не убожества вроде тех, что построены вокруг СTAGS.

* Инструментирование запущенной программы. Причем чем больше оно позволяет увидеть и чем меньше у него побочных эффектов - тем лучше.

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

Ну вот хотя бы эти три штуки должны быть.

А вообще, всё началось с того, что один фанбой гугла не знал, что такое «доказательство кода». Так что дискуссия свалилась в скучный офтоп.

На сим откланяюсь.

IDE, понимающее контекст и на основе этого предлагающее автодополнение, рефакторинги, поиск в документации и т.д. А не убожества вроде тех, что построены вокруг СTAGS.

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

* Инструментирование запущенной программы. Причем чем больше оно позволяет увидеть и чем меньше у него побочных эффектов - тем лучше.

сможешь подробнее рассказать требования

* Минимум проблем с зависимостями между пакетами. Пакеты совместимы, если совместим их API.

сложный вопрос, но пожелание вполне логично.

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

так сейчас и есть, хэш считается по интерфейсу.

А вообще, всё началось с того, что один фанбой гугла не знал, что такое «доказательство кода». Так что дискуссия свалилась в скучный офтоп.

оригинальная дискуссия и её подветвь тут не сильно мне интересна, поэтому я уточнил только интересные мне вопросы (причем доказывать что в haskell все не так я не собираюсь), в целом если не хочется продолжать я не против, мне честно просто интересно.

один фанбой гугла

Упомянул про порт го для эрланга - уже фанбой, кроме черного и белого то что-то видите?

а за C|C++ AT&T - и где теперь эта ваша?

а за FORTRAN IBM - и где теперь эта ваша?

а за COBOL ...

....

go вполне «современный» C

уважаемый любитель «prof"ed кода - вы по определению в курсе , что интересные задачи тем и интересны , что в данный момент не имеют доказанных решений .

Ты что-то хочешь этим сказать по-делу?

уважаемый любитель «prof"ed кода - вы по определению в курсе , что интересные задачи тем и интересны , что в данный момент не имеют доказанных решений .

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

Во-первых с чего ты взял что я - «любитель proofed кода»?

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

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

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

сможешь подробнее рассказать требования

Ну например, есть ли что-либо подобное по функциональности к jvisualvm?

так сейчас и есть, хэш считается по интерфейсу.

Может он так и считается. Но переустановка одного лишь пакета (на точно такой же, такой же самой версии) часто вводит cabal в феерический затуп и он считает, что надо пересобрать все зависимости. И зависимости зависимостей тоже. Это то, что вижу в haskell.

И хотя уверен, что всегда можно найти (или написать свой) через-пень-колодный метод, который как-то с этим поможет, но это время. А время - деньги.

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

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

языковой снобизм это маркер стадии зрелости

языковой снобизм это маркер стадии зрелости

Странный маркер. Я этим снобизмом страдал лет так в 12. Через пару лет попустило.

А я вот пользуюсь. И отказываться от элементарных удобств у меня желания нет.

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

Может он так и считается. Но переустановка одного лишь пакета (на точно такой же, такой же самой версии) часто вводит cabal в феерический затуп и он считает, что надо пересобрать все зависимости. И зависимости зависимостей тоже. Это то, что вижу в haskell.

интерфейс либы зависит от интерфейса зависимостей, соотв при изменении одного интерфейса в dep-graph нужно пересобрать все ниже. Естественно можно использовать динамическую линковку, там проблемы нет. Итого: есть выбор между сильным инлайнингом и пересборкой reversed deps или динамической линковкой. Метод, если что, официально поддерживаемый и не костыль. Ну и сборки в песочнице, с запланированным обновлением зависимостей тоже никто не отменял.

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

мой jabber в профиле, соотв. он равен мылу ну или мой ник (at) генту орг. Права online активно я только в рабочие дни.

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

здравствуй путишественнек во времени

go вполне «современный» C

Go даже и близко не Си. «Современным Си» был Cyclone и, возможно, будет Rust.

«современным С"я называю язык который в момент своего появление повторяет ситуацию появления С в 70-х - язык из которого целенаправленно выкинули кучу того , что было общим местом (pl-cpl-b-c) - а потом вернули часть ( не польностью - а про типы которые проницаемы друг в друга)

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

ведь даже арифметика указателей из b если не раньше.

а текущая ситуация в всё больше требует императивного описания взаимодействющих нодов .

«современным С"я называю язык который в момент своего появление повторяет ситуацию появления С в 70-х

А, ну да... «Когда _я_ беру слово, оно означает то, что я хочу, не больше и не меньше» (ц)

поэтому скажИ , что для тебя быть «современным С»?

годнота

А почему не haskell?

Где-то тут я уже отвечал на этот вопрос, но отвечу еще раз. Причин несколько:

• Синдром утенка во все поля. Начинал изучатать функциональное программирование с книги Introduction to Functional Programming. В этой книге в качестве рабочего языка использовался ML.
• Haskell кажется мне какой-то большой кучей а-ля Си++: ленивость и чистота осложняют оценку производительности; монады куда ни плюнь; есть стандарт языка, а есть ghc (де-факто стандартная реализация) который приносит кучу своих нововведений; Haskell слишком динамично развивается, иногда ломая обратную совместимость.

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

Мой вопрос не подразумевал, что «круче». Просто у хаскеля, больше батареек. Спасибо за развернутый ответ.

Просто у хаскеля, больше батареек

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

Я правильно понимаю, что терды в ocaml не используешь, а для этой задачи у тебя erlang?