Т.е. через объявление 2х временных переменных получается только.

Ну вместо приведения в одну строчку (как ты себе представляешь синтаксис для этого?) тебе придётся написать аж три.

a, b := superFunction()
c = float32(a)
d = float32(b)

Да, хотя пока нет смысла.

Через что? Через fork/clone? Или я могу навесить любой корос на любое ядро как это позволяет pthread_affinity ? Задачи бывают разные, если что.

Илитка в треде.

макака-правдоруб?

как уровень вхождения связан с «господством в будущем»?

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

это когда макакам давали решать на основе их интеллектуального уровня что лучше, а что хуже?

Чем выше уровень, тем больше вероятность господства в будущем.

И это хреново.

Чем выше уровень

тем круче должны быть cpu, хранилища данных и тп.
Вообщем тупик.
На сегодняшний день уже через СЕТЬ прокачиваются огромные объемы не нужной инфы. Что будет через лет 5 - не представляю.

Не внести новое, а причесать старое.

не взлетит, как не взлетит и D, по тем же самым причинам

Причем программеры ложат большой болт на оптимизацию кода.

не взлетит, как не взлетит и D, по тем же самым причинам

Языки — не самолёты, чтобы говорить про взлёт/не взлёт. Компилятор можно скачать, без геморроя можно поставить в ближайшую убунточку, можно найти подсветку кода на редактор и можно выполнять определённые задачи? Если да, то язык жив и актуален.

объявление переменных через := (в компилируемых языках я такого особо не видел)

C++11 auto

А что в С++ будет, если в пределах одной области видимости через auto два раза объявить переменную?

Ada 2012

«according to Debian's Popularity Contest, the installed base of GNAT now surpasses that of the FreePascal compiler»

http://coding.derkeiler.com/Archive/Ada/comp.lang.ada/2009-10/msg00216.html

Erlang взлетел из-за того, что внесли более простой подход, чем предлагает openMP, MPI и т.п.

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

Ну вот. Это раз. Есть ещё и другие претензии у меня, но их долго описывать :)

как ты себе представляешь синтаксис для этого?

Ну как нибудь. Вот допустим если бы эта функция возращала 1 флоат, можно было бы так:
a := float32(superFunction()), значит как-то подобно этому и для нескольких:
a,b := (float32,float32)(superFunction())

Еггог будет наверно.

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

ну согласно Вашим криетриям «брейнфак» актуален более чем, я так не считаю

ну согласно Вашим криетриям «брейнфак» актуален более чем, я так не считаю

Ну если брейнфак подходит для определённых задач, то да, он актуален.

А что в С++ будет, если в пределах одной области видимости через auto два раза объявить переменную?

ничего не будет - компилятор выведет типы

Ну если брейнфак подходит для определённых задач, то да, он актуален.

назови хотя бы 3

Еггог будет наверно.

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

http://search.cpan.org/perldoc?AnyEvent::MP

Почти в самом конце идет сравнение и ссылки по докам erlang'а. В двух словах используется tcp и стандартизированный протокол с сериализацией данных. В совокупности все это может выльеться в супер-навороченное приложение, которые масштабируется по вертикали и горизонтали. В отличие от openMP не требуется специфичных требований к написанию программы, просто меняется слегка логика, террабайт данных можно кусками раскидать по запущенным процессам, которые «прощелкают» их и запишут результаты через протокол в аналогичные процессы.

назови хотя бы 3

Ты обозвал брейнфак актуальным, ты и называй.

1С ☺

Ибо есть де-факто стандарты, которые уже прошли временем и Go ничего нового не внес.

Назови мне более-менее распространенный язык, основанный на CSP. Я, кроме Occam, так сразу ничего и не вспомню.

уверен, что тот же message proccessing сделан через фьютексы в определенных случаях.

Ты _это_ называешь «встроенными фютексами»? facepalm.jpg

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

  auto x = 13;
  auto x = 666;

сам догадаешься?

Ты обозвал брейнфак актуальным,

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

сам догадаешься?

А в го можно x := 13, x := 666 и даже сразу после этого x := «hello world».

1. http://en.wikipedia.org/wiki/Communicating_sequential_processes#See_also

Ты _это_ называешь «встроенными фютексами»? facepalm.jpg

Выхода только три: либо мне надо качать го и самому все тестить, что мне очень не хочется; либо ты даешь мне ответ как это реализовано в го, убедившись в этом сам и я верю тебе на слово; либо мы закрываем этот вопрос на неопределенный срок :)

Нет.

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

Я представил критерий актуальности. Брейнфак под него подходит совсем не очень.

1С ☺

Причём, во всём мире. Даже в Китае.

А в го можно x := 13, x := 666 и даже сразу после этого x := «hello world».

а ещё можно в «голубую устрицу» ходить отдыхать, и что?

Брейнфак под него подходит совсем не очень.

по какому критерию не подходит?

сам догадаешься?

Нет.

ну значит и объяснять тебе бесполезно

1. http://en.wikipedia.org/wiki/Communicating_sequential_processes#See_also

Кроме Ады - всё маргинальщина.

Ты _это_ называешь «встроенными фютексами»? facepalm.jpg

Выхода только два: либо мне надо качать го и самому все тестить

Просто скажи, что такое «встроенныые мютексы и фютексы».

по какому критерию не подходит?

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

Синтаксис теряет монотонность

ути пути. А то что переменные сокращённо можно объявлять только внутри функций — от этого монотонность не теряется? Ну пофиг, пусть будет бес скобок там
float32, float32 (superFunction())

Выполнение определённых задач.

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

ещё?

Даже в Китае

Иероглифами, да еще и без всяких хороших методик ввода. Только полноценная китайская клавиатура с (ЕМНИП) 40000 клавиш, только хардкор! ☺

Ну ты поставил выражение в кавычки, так что я не знаю что ты имеешь в виду. Семафоры это. В перле используется: pthread_mutex_unlock, pthread_mutex_lock. А что используется в го ты мне так и не ответил.

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

Я имею в виду цитату. А вот что ты имел в виду в том сообщении: Язык программирования будущего (комментарий)

Семафоры это

Я знаю, что такое фютексы (а так же мютексы, критические секции и прочее). Теперь ответь, что же значит твое выражение «встроенные мьютексы, фьютексы»? Интересует именно «встроенные», кавычки означают цитату.

В перле используется: pthread_mutex_unlock, pthread_mutex_lock.

Ты хочешь сказать, что pthread_mutex_unlock и pthread_mutex_lock встроены в Перл?

А что используется в го ты мне так и не ответил.

Язык программирования будущего (комментарий)

Естественно, что вместе со стандартными нитями используются стандартные синхронизационные объекты.

Это будет JavaScript почти везде, C для низкоуровневых\встраевыемых решений.

функциональные язычки программирования в 2010 году вытеснят Джаву

функциональные язычки

вытеснят Джаву

Казалось бы, при чём тут Scala.

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

Вызовы, которые я указал выше это экстерны и не являются вызовами из glibc.

Джве!

a, b := superFunction()
c, d := float32(a), float32(b)

Это будет JavaScript почти везде

Всё, с понедельника вплотную приступаю к изучению JavaScript. Всё остальное — в помойку.

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

Опять двадцать пять... причем тут, в обход или не в обход? Короутины - это принципиально непараллельно, by design. А в Go - CSP, которые принципиально параллельны.

коросы в glibc

Что это вообще такое - swapconext/setcontext?

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

...и этот участок памяти - буфер канала. _Только_ он.

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

запилили ли до конца? по производительности он сливал ещё полгода назад всему, чему мог, сам гугл в этом и признался, ЕМНИП

А в Go - CSP, которые принципиально параллельны.

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

Ну так бы и сказал, что в го используется clone_thread

Как только ты спросил - я так и сказал.

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

Странные у тебя представления о прорывах. Если в Go и есть прорыв - это возвращение CSP.