Fortress - замена Fortran от Sun, становится Open Source

Совет. Посмотри кто автор этого фортреса и чем он раньше занимался.

И как это мне поможет и главное в чем?

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

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

3. Язык это прежде всего синтаксис. А вот скорость исполнения программ на нем совсем другой вопрос.

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

Ты увидешь, что этим "новшествам" сто лет в обед и существуют языки, в которых это давно есть и отлично работает.

> Moжнo лeгкo нaпиcaть интeпpeтaтop C, кoтopый бyдeт тopмoзить xyжe Питoнa.

Не, это будет не леко. Ибо:

а) Тяжело написать интерпретатор С;

б) Тяжело написать что-либо тормознее питона. (хотя некоторым удаётся)

>> а что, в фортране все хреново с параллелизацией ?

>Как раз с этим всё хорошо, - её там просто нет :)

Чушь! Power Fortran например:

http://docs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0640&db=bks&s...

http://www.ibm.com/servers/eserver/linux/power/features/hpc.html

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

Действительно актуально? Для численного кода задачу как правило обезразмеривают сначала... И в этом есть большой смысл. Например чтобы избежать under(over)flow.

Ну а если по теме. То попытка будет интересная если java выкинут. Однако,чем оно в итоге будет лучше матлаб/python+extensions/octave/scilab?

Кроме того сейчас достаточное количество OSS приложений для решения направленных на вычислительные задачи, PETSC, Sundials, etc

>> а что, в фортране все хреново с параллелизацией ?
> Как раз с этим всё хорошо, - её там просто нет :)
Ну нифига, там то она как раз очень хороша, особенно в версии 90 и 95

хаха как мне смешно с этих людей. Покажи как ты механически вот этот код переташишь на c++ например:
primes = eratosthenes [2..]
where
eratosthenes (x:xs) = x:eratosthenes (filter ((/= 0).(`mod` x)) xs)

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

Да действительно актуально.

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

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

1. A = 10 км/ч 2. B = 5 м/s 3. C(mil/h) = A + B

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

Мало того при нормальной реализации подобный язык в состянии проверять формулы на соблюдение размерности.

Например:

1. A = 10 км/ч 2. B = 5 m2/Vs 3. C(mil/h) = A + B

Данный вариант должен выдать ошибку. Хотя согласно только компьютерным правилам сложить 10 и 5 можно без всяких проблем.

Кроме того замечено, что некоторые деятели очень тянутся извлекать логарифмы из размерных величин. Если человек пишет в программе log(10), то его никто не остановит, даже если он под 10 понимает 10 метров. А вот если он выдаст log(10 m), то компилятор выдаст ошибку.

В этом смысле язык должен всячески помогать программирующему избавляться от ошибок еще в момент написания программы, а не когда она будет отлажена и при этом выдавать неправильный результат. Ведь хорошо еще результат будет нереален. По типу полученная скорость Паровоза равна 10000 км/s И у кого-то хватит ума это заметить. Но не ко всем величинам у нас есть чувство реальности и не у всех. А ведь бывает так, что ошибки накладываются одна на другую и величина может оказаться вполне разумной, хотя и неправильной.

P.S. Никогда не забуду как на одном сайте со списком proxy серверов стояло - скорость proxy сервера это секунды....

А Вы не смейтейсь. Вы прежде читать научитесь. Я лично Вам ничего не предлагал перетаскивать...

Как научитесь - обращайтесь. Посмеемся вместе.

>б) Тяжело написать что-либо тормознее питона. (хотя некоторым удаётся)

на каждый приведённый тобой скриптовый язык, более быстрый, чем Питон, отвечу десятком более тормозных :D

>Временами у меня складывается впечатления, что на ЛОРе сидят практически только сисадмины-бездельники, которые от нечего делать проводят полдня на этом сайте.

У хорошего админа - дохрена свободного времени. Так что не надо тут :-) Это вы, вендузятники, бегаете весь день ошпаренные от одного юзера к другому :) (да и вендовый нормальный админ тоже сидит 98% своего рабочего времени на жопе ровно и не бегает и не чинит)

Следить за размерностями надо всё-таки самому. Т.к. иначе это лишние накладные расходы. Проще иметь маленькую програмку, которая перед работой пересчитает данные из предоставленных единиц измерения в нужные. Это гораздо ближе к Unix-way, да и более правильно, как мне кажется.

Каждый должен заниматься своим делом. Язык программирования обеспечивать скорость и достаточную лёгкость написаня программ (в этом смысле я поклонник С, и вообще рекционная личность ;-) ). Остальное - не его забота.

Да, необходимое добавление. Это всё ИМХО. Научными вычислениями занимаюсь по-работе.

рекционная=реакционная

> Cлeдить зa paзмepнocтями нaдo вcё-тaки caмoмy.

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

З.Ы. Язык получается замечательный, бо Стиль других не делает. Будет хорошо, если солнцепоклонники протащат его в продакшн.

> Язык получается замечательный, бо Стиль других не делает

Java - так себе язычок.

А разве Стиль занимался разработакой жабы?

> А разве Стиль занимался разработакой жабы?

Да. Он один из авторов "Java Language Specification" (Joy, Gosling, Steele). В одном из своих интервью сказал (о C++-программистах, перешедших на Java), что "[Java] dragged those people halfway to Lisp" 8)

Господи, прости меня атеиста, но тут 70 идиотов отпостились, и никто не понял что на жабе этот язык сейчас только для целей бутстрапа и отладки спецификации. Это 100% прототип, потому что эффективная реализация такого языка невозможна на JVM(). Хотя может так произойти что эффективную реализацию они ДАРПЕ отдадут, или за деньги продавать будут.

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

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

A po-moemu, poslednia 'speka' -- fortran 2000.

> Да действительно актуально. Данные были и всегда будут в размерной форме. Обезразмеривание это точно такой же труд, как и приведение данных к одной размерности. Именно от этого труда избавляет данный язык. Я бы даже сказал правильно обезразмерить гораздо труднее.

Преодолевать трудности, что может быть интереснее.. Намек был на:

>>Например чтобы избежать under(over)flow.

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

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

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

>В этом смысле тот же Boo лучше Python для программирования реальных задач на порядок, но факт что он станет массовым спорны

ну чэм, чэм лучше !!!???

>Хотя MS пошла по очень верному пути делая ставку не на язык, а на платформу.

бугога!!! санки уже давно идут по этому пути (будь хоть гамно гамно но! чтобы под жвм!).

>Ее ждет большое будущее.

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

> Следить за размерностями надо всё-таки самому. Т.к. иначе это лишние накладные расходы.

Это надо делать на этапе компиляции. Common Lisp, Haskell такое позволяют. Думаю, и на плюсах можно шаблонами сделать (только вот выглядеть это будет чудовищно)...

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

Это не может быть реализовано никакими либами, так как работает только на этапе компиляции! Во время исполнения программ смысла в размерностях нет!

>> В этом смысле тот же Boo лучше Python для программирования реальных задач на порядок, но факт что он станет массовым спорны > ну чэм, чэм лучше !!!???

Тем что он позволяет делать определение типов и поэтому отлаживать ошибки на этапе компиляции, а не во время исполнения.

>> Хотя MS пошла по очень верному пути делая ставку не на язык, а на платформу. > бугога!!! санки уже давно идут по этому пути (будь хоть гамно гамно но! чтобы под жвм!).

Вы что лошадь, что так ржете? Культурнее себя вести можно. У Сан один язык одна платформа. У dotNet язык может быть любой.

И последнее речь dotNet, а не как ни о Jave.

Не вижу никакой проблемы почему за размерностью не может следить компьютер?

Никаких накладных расходов на это быть в принципе не может!

Разве что разработка станет быстрее...

Не проще иметь никакую программку и ничего не надо пересчитывать.

Вы похоже вообще не поняли о чем речь!

По поводу Unix-way обращайтесь в ближайшую церковь. Либо у Вас есть аргументы, либо нет. Заклятия и причитания на меня не действуют.

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

Тот же Python заткнет С в этом смысле по самые уши.

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

>По поводу Unix-way обращайтесь в ближайшую церковь. Либо у Вас есть аргументы, либо нет. Заклятия и причитания на меня не действуют.
>lefsha

Вона как :) Ну вот вам мой аргумент за Unix-way в целом:
Это не про церковь, а про сборники "The Best Business Practices" ... ну или даже про того старшину что учил салажат в Соетской Армии : "Учите устав сыки! Он - кровью писан!"
Впрочем люди считаюшие хождение по граблям нормальным путем встречаются сплошь и рядом ... и я никогда не мешаю им идти, не мессионер я :)

>> если бы вы после того как много думали, немного бы поискали, то >нашли бы туеву хучу либ для С++ или Ada, которые именно реализуют >прозрачную, статически контролируемую работу с размерностями. >Это не может быть реализовано никакими либами, так как работает >только на этапе компиляции! Во время исполнения программ смысла в >размерностях нет! А где автор тех строк говорил про время исполнения? Почитайте хотя бы http://aspn.activestate.com/ASPN/Mail/Message/boost/1619671

>Это не может быть реализовано никакими либами, так как работает >только на этапе компиляции! С шаблонами на С++ Вы, видимо, не работали. Так вот, сюрприз, с помощью шаблонов такая проверка осуществима как раз на этапе компиляции.

Сэр! Так в чем же проблемы!

Сделайте так чтобы компилятор в подобном по смыслу коде нашел ошибку!

M = 10 kg L = 5 m T = 10 s

P(kW) = M*L/(T*T*T)

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

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

Так что Вы не миссионер, Вы просто очередной безграмотный anonymous.

Так что в следующий раз придержите свой язык.