Re[2]: О перспективах F#
От: skeptik_  
Дата: 14.04.10 19:47
Оценка: +1
Здравствуйте, BulatZiganshin, Вы писали:

BZ>сейчас идёт хорошо заметный ФП hype, в связи с тем что это более высокоуровневый подход к программированию вообще и его хорошей приспособленностью к многопоточности в частности. я несколько лет назад предполагал, что 2010-е станут десятилетием ФП, но ошибся. так же, как и в прошлый раз, переход идёт в два этапа. на первом чистые ООП языки бкдкт сменены смешанными, включая F# и вероятно Скалу. и только на втором этапе, в следующем десятилетии, я думаю, программисты уже достаточно привыкнут к ФП чтобы перейти к чистым ФП языкам


Я думаю, что чистый ФП никогда не будет массовым. Искусственные ограничения никому не нужны, чтобы потом мужественно их преодолевать, выдумывая всякие монады и т.п.. За смешанными языками будущее.
Re[3]: О перспективах F#
От: batu Украина  
Дата: 14.04.10 20:16
Оценка: :))) :))
Здравствуйте, QrystaL, Вы писали:

QL>Есть новые мысли по теме? =)

Есть. Нужен единый и простой язык реализующий преимущества как императивного, функционального и логических языков. Почему про логические забыли? Есть очень удачные решения. И вообще нужен свежий взгляд на проблемы языка. Их стало слишком много, функционально разница нулевая, только синтаксическая мозговздрочь. Ну, и понты..Я на Ruby а тот на питоне.. Бейсик это позор.. А фукциональные возможности одинаковые. Чуть в стороне java. Удачно подмечены и реализованы общие подходы к классам, свойствам и объектам и плюс апплеты. А в остальном тот же хрен. Ассемблеры и С плюсы обсуждать не буду. У них свои задачи. Необсуждаемые. Да.. Есть еще графические для микроконтроллеров..Это к ассемблерам.. с макросами удобренные макросами с визуальным представлением. Принципиально нового нет ничего. Движение в сторону усложения приведет к упрощению и выработке единых концепций. Я так думаю.
Есть еще куча специализированых языков.. Для технологов, бухгалтеров и т.п. ну, это жалкое подобие левой руки.. Нет смысла даже обсуждать
Re[3]: О перспективах F#
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 15.04.10 13:51
Оценка: 1 (1) +2 -1 :))
Здравствуйте, skeptik_, Вы писали:

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


BZ>>сейчас идёт хорошо заметный ФП hype, в связи с тем что это более высокоуровневый подход к программированию вообще и его хорошей приспособленностью к многопоточности в частности. я несколько лет назад предполагал, что 2010-е станут десятилетием ФП, но ошибся. так же, как и в прошлый раз, переход идёт в два этапа. на первом чистые ООП языки бкдкт сменены смешанными, включая F# и вероятно Скалу. и только на втором этапе, в следующем десятилетии, я думаю, программисты уже достаточно привыкнут к ФП чтобы перейти к чистым ФП языкам


_>Я думаю, что чистый ФП никогда не будет массовым. Искусственные ограничения никому не нужны, чтобы потом мужественно их преодолевать, выдумывая всякие монады и т.п.. За смешанными языками будущее.


Интересно, ограничение адресной арифметики в языках с GC — естественное или искусственное ограничение?
А что что я не могу просто написать return new X() в языке без GC, а должен вернуть обертку, считающую ссылки или (о ужас) договориться с вызывающим о том кто и как будет освобождать память, это не искусственное ограничение?

То что в большинстве языков нельзя написать fibs = 1 : 1 : zipWith (+) fibs (tail fibs) без того чтобы создавать итераторы\генераторы, кешировать результаты каким-то образом, это естественное или искусственное ограничение?

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

Сейчас наступает такой момент когда уровень абстракции, предоставляемый мейнстримовыми языками, оказывается недостаточным для эффективного решения задач. Поэтому становятся все более популярными функциональные языки. Но уровень абстракции мышления среднего программиста растет не так быстро, вот и возникают мнения что "чистый ФП никогда не будет массовым".

Не задерживайте свое мышление на низком уровне абстракции и будет вам счастье.
Re[4]: О перспективах F#
От: skeptik_  
Дата: 15.04.10 14:39
Оценка: +1 -3
Здравствуйте, gandjustas, Вы писали:

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


Минус за флейм и дурацкие сравнения.
Re[4]: О перспективах F#
От: Mazay Россия  
Дата: 19.04.10 12:02
Оценка: +4
Здравствуйте, gandjustas, Вы писали:

G>Почему какое-то ограничение языка естественное или искусственное? Наверное это зависит от уровня абстракции.

Искусственое ограничение языка — это ограничение отсутствующее на уровне платформы. Например, возможность изменять значение в ячейках памяти. Средства обеспечения локальности доступа к памяти (возможность размещать объекты в памяти с требуемым выравниванием и в требуемом порядке).

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

Ну вот. Явное управление памятью это плохо, а явные побочные эффекты это хорошо?

G>Сейчас наступает такой момент когда уровень абстракции, предоставляемый мейнстримовыми языками, оказывается недостаточным для эффективного решения задач. Поэтому становятся все более популярными функциональные языки. Но уровень абстракции мышления среднего программиста растет не так быстро, вот и возникают мнения что "чистый ФП никогда не будет массовым".

G>Не задерживайте свое мышление на низком уровне абстракции и будет вам счастье.
Вот только не надо думать, что люди не используют функциональные языки, потому что у них мышление низкоуровневое. Просто функциональные языки ещё имеют критические недостатки в ряде задач, а людям нужно решать именно эти задачи.
Главное гармония ...
Re[5]: О перспективах F#
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.04.10 14:25
Оценка: -2 :))
Здравствуйте, Mazay, Вы писали:

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


G>>Почему какое-то ограничение языка естественное или искусственное? Наверное это зависит от уровня абстракции.

M>Искусственое ограничение языка — это ограничение отсутствующее на уровне платформы.
Платформа у всех одна — x86 (x64)
Не надо начинать разговор о том что считать платформой. Это бесконечный разговор.

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

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

G>>Сейчас наступает такой момент когда уровень абстракции, предоставляемый мейнстримовыми языками, оказывается недостаточным для эффективного решения задач. Поэтому становятся все более популярными функциональные языки. Но уровень абстракции мышления среднего программиста растет не так быстро, вот и возникают мнения что "чистый ФП никогда не будет массовым".

G>>Не задерживайте свое мышление на низком уровне абстракции и будет вам счастье.
M>Вот только не надо думать, что люди не используют функциональные языки, потому что у них мышление низкоуровневое. Просто функциональные языки ещё имеют критические недостатки в ряде задач, а людям нужно решать именно эти задачи.
Ну да, а примеры можно?
Re[6]: О перспективах F#
От: Курилка Россия http://kirya.narod.ru/
Дата: 19.04.10 14:29
Оценка:
Здравствуйте, gandjustas, Вы писали:

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

M>>Искусственое ограничение языка — это ограничение отсутствующее на уровне платформы.
G>Платформа у всех одна — x86 (x64)

Ты уверен, что у всех?
Re[7]: О перспективах F#
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.04.10 15:00
Оценка: -4 :)
Здравствуйте, Курилка, Вы писали:

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


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

M>>>Искусственое ограничение языка — это ограничение отсутствующее на уровне платформы.
G>>Платформа у всех одна — x86 (x64)

К>Ты уверен, что у всех?


Не 100% конечно, но подавляющее большинство.
Re[8]: О перспективах F#
От: Nik_1 Россия  
Дата: 19.04.10 15:33
Оценка: +1
Здравствуйте, gandjustas, Вы писали:
G>Не 100% конечно, но подавляющее большинство.

Мобильные устройства сейчас занели довольно существенную ддолю рынка разработки ПО, а АРМ не имеет ничего общего с х86
Re[9]: О перспективах F#
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.04.10 16:24
Оценка: -2
Здравствуйте, Nik_1, Вы писали:

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

G>>Не 100% конечно, но подавляющее большинство.

N_>Мобильные устройства сейчас занели довольно существенную ддолю рынка разработки ПО, а АРМ не имеет ничего общего с х86

Какое отношение это имеет к функциональным языкам?
Просто захотелось эрудицией блеснуть?
Re[10]: О перспективах F#
От: NikeByNike Россия  
Дата: 19.04.10 16:33
Оценка: 10 (2) +7 :)))
Здравствуйте, gandjustas, Вы писали:

G>Просто захотелось эрудицией блеснуть?


А ты не мог бы уменьшить подпись, а то глаа ломает.
Нужно разобрать угил.
Re[6]: О перспективах F#
От: Mazay Россия  
Дата: 20.04.10 08:04
Оценка: 3 (1) +1
Здравствуйте, gandjustas, Вы писали:

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


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


G>>>Почему какое-то ограничение языка естественное или искусственное? Наверное это зависит от уровня абстракции.

M>>Искусственое ограничение языка — это ограничение отсутствующее на уровне платформы.
G>Платформа у всех одна — x86 (x64)
G>Не надо начинать разговор о том что считать платформой. Это бесконечный разговор.
По крайней мере RAM с кэшем есть везде. Причём read-write. По крайней мере для определённых задач.

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

M>>Ну вот. Явное управление памятью это плохо, а явные побочные эффекты это хорошо?
G>Да, неявное управление памятью, как и явное управление побочными эффектами хорошо так как и то и другое позволяет меньше ошибаться.
Неявное управление памятью помогает, потому что оно упрощает работу и делает её безопасной. Явное управление побочными эффектами усложняет работу и я не вижу, каким образом монада может избавить меня от неправильного формата выходных данных.
Кроме того, иногда явное управление памятью необходимо, так почему в большинстве ФЯП нет средств для этого? На OCaml можно будет кивать, когда у него появятся нормальные библиотеки, средства для работы с shared-memory и когда он станет быстрым не только при императивном стиле программирования.

G>>>Сейчас наступает такой момент когда уровень абстракции, предоставляемый мейнстримовыми языками, оказывается недостаточным для эффективного решения задач. Поэтому становятся все более популярными функциональные языки. Но уровень абстракции мышления среднего программиста растет не так быстро, вот и возникают мнения что "чистый ФП никогда не будет массовым".

G>>>Не задерживайте свое мышление на низком уровне абстракции и будет вам счастье.
M>>Вот только не надо думать, что люди не используют функциональные языки, потому что у них мышление низкоуровневое. Просто функциональные языки ещё имеют критические недостатки в ряде задач, а людям нужно решать именно эти задачи.
G>Ну да, а примеры можно?
Я уже привёл:

Средства обеспечения локальности доступа к памяти (возможность размещать объекты в памяти с требуемым выравниванием и в требуемом порядке)

Это очень важно для HPC при активной работе с памятью. Есть у меня бааальшой массив данных,только-только в память влезает, И мне нужно часто менять значения случайных его элементов (точнее случайных цепочек элементов). Причём из нескольких потоков. Как это сделать, если у меня неизменяемая память?

Также нет средств для явного ограничения выделения памяти. Я хочу явно выделять память, а не гадать как себя поведёт GC или механизм отвечающий за работу со списками. Та же быстрая сортировка — как мне на Хаскеле выполнить её in-place, без дополнительных выделений памяти?
Главное гармония ...
Re[7]: О перспективах F#
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.04.10 08:24
Оценка: +1 -2
Здравствуйте, Mazay, Вы писали:

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

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

M>Кроме того, иногда явное управление памятью необходимо, так почему в большинстве ФЯП нет средств для этого?

Явное управление памятью почти во всех языках доступно через вызов низкоуровневых функций ОС.
Запрещено только ручное управление managed-памятью.

M>На OCaml можно будет кивать, когда у него появятся нормальные библиотеки, средства для работы с shared-memory и когда он станет быстрым не только при императивном стиле программирования.

Тот же .NET умудряется выделять-освобождать память быстрее стандартных аллокаторов для неуправляемых языков.

G>>>>Сейчас наступает такой момент когда уровень абстракции, предоставляемый мейнстримовыми языками, оказывается недостаточным для эффективного решения задач. Поэтому становятся все более популярными функциональные языки. Но уровень абстракции мышления среднего программиста растет не так быстро, вот и возникают мнения что "чистый ФП никогда не будет массовым".

G>>>>Не задерживайте свое мышление на низком уровне абстракции и будет вам счастье.
M>>>Вот только не надо думать, что люди не используют функциональные языки, потому что у них мышление низкоуровневое. Просто функциональные языки ещё имеют критические недостатки в ряде задач, а людям нужно решать именно эти задачи.
G>>Ну да, а примеры можно?
M>Я уже привёл:
M>

M>Средства обеспечения локальности доступа к памяти (возможность размещать объекты в памяти с требуемым выравниванием и в требуемом порядке)

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

M>Это очень важно для HPC при активной работе с памятью. Есть у меня бааальшой массив данных,только-только в память влезает, И мне нужно часто менять значения случайных его элементов (точнее случайных цепочек элементов). Причём из нескольких потоков. Как это сделать, если у меня неизменяемая память?

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

M>Также нет средств для явного ограничения выделения памяти. Я хочу явно выделять память, а не гадать как себя поведёт GC или механизм отвечающий за работу со списками. Та же быстрая сортировка — как мне на Хаскеле выполнить её in-place, без дополнительных выделений памяти?

Если ты будешь писать на хаскеле, то тебе не понадобится inplace сортировка.

Ты себя загоняешь в рамки императивных алгоритмов, а потом пытаешься эти алгоритмы на чистые языки натянуть.
Re[8]: О перспективах F#
От: Mazay Россия  
Дата: 20.04.10 11:12
Оценка: +1
Здравствуйте, gandjustas, Вы писали:


M>>Это очень важно для HPC при активной работе с памятью. Есть у меня бааальшой массив данных,только-только в память влезает, И мне нужно часто менять значения случайных его элементов (точнее случайных цепочек элементов). Причём из нескольких потоков. Как это сделать, если у меня неизменяемая память?

G>А ты придумай скачала адекватную задачу для чего такое понадобится.
Это собственно и есть задача. Модель Изинга называется. Есть множество более сложных модификаций, но геморрой там один — вероятностное изменение большой структуры данных в малопредсказуемых местах. Реализуешь на Хаскеле?

M>>Также нет средств для явного ограничения выделения памяти. Я хочу явно выделять память, а не гадать как себя поведёт GC или механизм отвечающий за работу со списками. Та же быстрая сортировка — как мне на Хаскеле выполнить её in-place, без дополнительных выделений памяти?

G>Если ты будешь писать на хаскеле, то тебе не понадобится inplace сортировка.
Ну вот есть у меня большущий набор структур типа "пользователь", едва влезающий в память (контейнер любой, лишь бы памяти требовал не сильно больше массива). Он прилетает из сети цельным куском и отдать его надо цельным куском. Как мне его упорядочить по какому-нибудь компаратору?

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

Я себя загоняю в рамки той архитектуры ЭВМ которой располагаю. И я хочу использовать эту архитектуру на всю катушку. А алгоритмы пишутся не для языков, а для компьютеров. А чистые языки почему-то упорно не хотят использовать весь потенциал имеющегося железа.
Главное гармония ...
Re[8]: О перспективах F#
От: Mazay Россия  
Дата: 20.04.10 11:42
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


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

G>Явные побочные эффекты сильно упрощают композицию кода и отладку.
G>От неправильно написанных побочных эффектов не спасет компилятор, но он вполне может спасти от побочных эффектов написанных не в том месте.

M>>Кроме того, иногда явное управление памятью необходимо, так почему в большинстве ФЯП нет средств для этого?

G>Явное управление памятью почти во всех языках доступно через вызов низкоуровневых функций ОС.
G>Запрещено только ручное управление managed-памятью.
То есть если мне понадобилось вручную выровнять одну структуру данных, то весь код, который от неё зависит, становится неуправляемым?

M>>На OCaml можно будет кивать, когда у него появятся нормальные библиотеки, средства для работы с shared-memory и когда он станет быстрым не только при императивном стиле программирования.

G>Тот же .NET умудряется выделять-освобождать память быстрее стандартных аллокаторов для неуправляемых языков.
Во-первых я не про .NET, а про ФП. Во-вторых, дело не в "быстрее". Быстроту всегда можно обеспечить ручной аллокацией там где укажет профилировщик. Дело в локальности данных.

G>>>>>Сейчас наступает такой момент когда уровень абстракции, предоставляемый мейнстримовыми языками, оказывается недостаточным для эффективного решения задач. Поэтому становятся все более популярными функциональные языки. Но уровень абстракции мышления среднего программиста растет не так быстро, вот и возникают мнения что "чистый ФП никогда не будет массовым".

G>>>>>Не задерживайте свое мышление на низком уровне абстракции и будет вам счастье.
M>>>>Вот только не надо думать, что люди не используют функциональные языки, потому что у них мышление низкоуровневое. Просто функциональные языки ещё имеют критические недостатки в ряде задач, а людям нужно решать именно эти задачи.
G>>>Ну да, а примеры можно?
M>>Я уже привёл:
M>>

M>>Средства обеспечения локальности доступа к памяти (возможность размещать объекты в памяти с требуемым выравниванием и в требуемом порядке)

G>А причем тут функциональные языки? Это прерогатива компилятора и рантайма. В .NET для структуры это возможно, в другом языке можно будет сделать такое и для других объектов.
AFAIK с этим в .NET как-то можно работать, я, опять же, говорю про ФП. Только не надо расказывать сказки про офигенно умные компиляторы и рантаймы, которые сами знают как размещать объекты в памяти. Разумеется, они заточены под 90% стандартных кейсов, но зачем отбирать возможность самостоятельно управлять такими вещами? Делают же изменяемые переменные в ФЯП, так почему не дать возможность ручного управления памятью? Мне в этом смысле нравится подход Немерла и C++ — есть низкоуровневый язык, хорошо управляющий платформой (императивное подмножество типа С# и C) и есть высокоуровневые средства, реализованые на базе низкоуровневых. Вторые создаются и допиливаются с помощью первых и проблемы интреопа вообше нет.
Главное гармония ...
Re[9]: О перспективах F#
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 21.04.10 06:21
Оценка: -1 :))
Здравствуйте, Mazay, Вы писали:

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



M>>>Это очень важно для HPC при активной работе с памятью. Есть у меня бааальшой массив данных,только-только в память влезает, И мне нужно часто менять значения случайных его элементов (точнее случайных цепочек элементов). Причём из нескольких потоков. Как это сделать, если у меня неизменяемая память?

G>>А ты придумай скачала адекватную задачу для чего такое понадобится.
M>Это собственно и есть задача. Модель Изинга называется. Есть множество более сложных модификаций, но геморрой там один — вероятностное изменение большой структуры данных в малопредсказуемых местах. Реализуешь на Хаскеле?

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

M>>>Также нет средств для явного ограничения выделения памяти. Я хочу явно выделять память, а не гадать как себя поведёт GC или механизм отвечающий за работу со списками. Та же быстрая сортировка — как мне на Хаскеле выполнить её in-place, без дополнительных выделений памяти?

G>>Если ты будешь писать на хаскеле, то тебе не понадобится inplace сортировка.
M>Ну вот есть у меня большущий набор структур типа "пользователь", едва влезающий в память (контейнер любой, лишь бы памяти требовал не сильно больше массива). Он прилетает из сети цельным куском и отдать его надо цельным куском. Как мне его упорядочить по какому-нибудь компаратору?
Индексная сортировка.

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

M>Я себя загоняю в рамки той архитектуры ЭВМ которой располагаю. И я хочу использовать эту архитектуру на всю катушку. А алгоритмы пишутся не для языков, а для компьютеров. А чистые языки почему-то упорно не хотят использовать весь потенциал имеющегося железа.
Функциональные языки пытаются использовать весь потенциал программиста, а железо при необходимости докупить можно.
Re[9]: О перспективах F#
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 21.04.10 06:25
Оценка:
Здравствуйте, Mazay, Вы писали:

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


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


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

G>>Явные побочные эффекты сильно упрощают композицию кода и отладку.
G>>От неправильно написанных побочных эффектов не спасет компилятор, но он вполне может спасти от побочных эффектов написанных не в том месте.

M>>>Кроме того, иногда явное управление памятью необходимо, так почему в большинстве ФЯП нет средств для этого?

G>>Явное управление памятью почти во всех языках доступно через вызов низкоуровневых функций ОС.
G>>Запрещено только ручное управление managed-памятью.
M>То есть если мне понадобилось вручную выровнять одну структуру данных, то весь код, который от неё зависит, становится неуправляемым?
Конечно нет.

M>>>На OCaml можно будет кивать, когда у него появятся нормальные библиотеки, средства для работы с shared-memory и когда он станет быстрым не только при императивном стиле программирования.

G>>Тот же .NET умудряется выделять-освобождать память быстрее стандартных аллокаторов для неуправляемых языков.
M>Во-первых я не про .NET, а про ФП.
А тема то про f#

M>Во-вторых, дело не в "быстрее". Быстроту всегда можно обеспечить ручной аллокацией там где укажет профилировщик. Дело в локальности данных.

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


M>AFAIK с этим в .NET как-то можно работать, я, опять же, говорю про ФП.

Тема то про f#
Re[10]: О перспективах F#
От: Nik_1 Россия  
Дата: 21.04.10 06:39
Оценка:
Здравствуйте, gandjustas, Вы писали:
G>Функциональные языки пытаются использовать весь потенциал программиста, а железо при необходимости докупить можно.

Это если ты пишешь прогу которой пользуется 1 человек, если же прогой пользуются милионы — то дешевле какраз прогеру потратить несколько лишних месяцев на разработку
Re[11]: О перспективах F#
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 21.04.10 08:12
Оценка:
Здравствуйте, Nik_1, Вы писали:

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

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

N_>Это если ты пишешь прогу которой пользуется 1 человек, если же прогой пользуются милионы — то дешевле какраз прогеру потратить несколько лишних месяцев на разработку


Этот разговор уже миллионы раз поднимался. Если быстродействия для миллионов пользователей достаточно, то не нужно тратить эти самые месяцы. Но чтобы узнать это — надо сначала выпустить программу, а потом уже тратить время на оптимизацию. В этом как раз более высокоуровневые языки помогают.
Re[12]: О перспективах F#
От: Nik_1 Россия  
Дата: 21.04.10 09:19
Оценка:
Здравствуйте, gandjustas, Вы писали:
G>Этот разговор уже миллионы раз поднимался. Если быстродействия для миллионов пользователей достаточно, то не нужно тратить эти самые месяцы. Но чтобы узнать это — надо сначала выпустить программу, а потом уже тратить время на оптимизацию. В этом как раз более высокоуровневые языки помогают.
Ага, только если программа написана на чемнить типа шарпа, то когда упрутся в то что производительность недостаточная, придется выкинуть все написанное и переписать программу с нуля на плюсах. Так что зарание подумать тоже не лишне
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.