nemyax
Много чем. Компактность, простота, нормальный синтаксис (правда, первое, что я делал - заменил комментарии на С-стайл, так что моя лува не совсем канонiчная), отсутствие маразма с отступами, легкая встраиваемость в любую систему, отсутствие процедуры инсталляции. Лува это именно скриптовый язык для частных целей, а петон - разросшийся монстр, активно лоббируемый "уч0ными", которым проще отгавкаться фразой "ну напиши скрипт", чем оторвать задницу, разморозить мозги и таки сделать свой софт юзабельным.
Но разве я сказал, что петон надо вытеснять лувой? Все эти конструкторы а ля "сделай сам" надо вытеснять продуманными архитектурами на плюсах. А в качестве довеска "для любознательных" (т.е. кому функционала не хватило) лува подходит куда лучше.
а можешь вот такой же дем про фортран сделать, интересно, что именно в нём не нравится как в узкоспециализированном яп.
ну а на python уже давно у меня выбор пал, из за того что на нём вот эта штука есть -- её и графики рисую и из результатов счёта мультфильмы делаю. она и с LaTeXом прексрано связывается.потому и думал, может и управление на него повесить, хотя я сегодня, внезапно обнаружил, что некоторые параметры можно менять не плавно, а скачком и разряд прекрасно к этому адаптируется, никаких нефизичных разбалтываний не возникает, так что может слишком большие заморочки на тему управления мне и не понадобятся.
thambs писал: а можешь вот такой же дем про фортран сделать, интересно, что именно в нём не нравится как в узкоспециализированном яп.
Не нравится главным образом морально устаревший синтаксис. С одной стороны - не язык ассемблера, но с другой - и не язык высокого уровня. Что-то среднее.
Все остальные беды проистекают из этого.
Скоро все маститые фортранщики умрут (от старости), и все забудут про этот ЯП, как про кошмарный сон. Все библиотеки/функции давно реализованы на С (те же Numeric Recipes).
Цитата:
thambs писал: ну а на python уже давно у меня выбор пал, из за того что на нём вот эта штука есть -- её и графики рисую и из результатов счёта мультфильмы делаю
Ну вот а я как раз и пишу свой софт для этих целей.
Мне не совсем понятно, зачем там петон вообще. Вроде ничего не мешало сделать на плюсах. Ан нет. Есть два вивера, например, VMD и PyMol, первый труъ-сишный (с прикрученным Tcl как скриптовым языком), второй на петоне, и второй по функционалу (именно как гуй) куда удобнее. Причём видно, что это не петона достоинство, а людей, писавших софт. Что это, какое-то глобальное умственное помешательство? Или они скажут, что петон легче плюсов? Это не так, синтаксис можно освоить любой при желании, а приёмы программирования везде одинаковые. Под петон больше чужих библиотек? И это не так. Петон кроссплатформенный? Qt. На си надо следить за освобождением памяти и нулевыми указателями? Ну, с быдлокодерами мне вообще говорить не о чем.
>С одной стороны - не язык ассемблера, но с другой - и не язык высокого уровня. Что-то среднее.
ээ, а можно пример. у меня совершенно противоположное впечатление сложилось. ну когда в том же фортране что бы получить, например, целочисленный логарифм по основанию 2 я просто вызываю функцию exponent, а в ц для этого надо вручную выковыривать нужные байты floatного представления (в 11м стандарте вроде уже добавили такую функцию).
ну или то что нельзя красиво бреакнуть цикл на несколько уровней вверх -- думал я не нашёл чего то, но спросил у xawari, так оказывается действительно нельзя.
thambs писал: ну когда в том же фортране что бы получить, например, целочисленный логарифм по основанию 2 я просто вызываю функцию exponent, а в ц для этого надо вручную выковыривать нужные байты floatного представления
Я не знаю, что тут сказать.
Фортран - это язык для компов с магнитными лентами и перфокартами.
С задачами тех лет он справлялся.
Сейчас его пытаются довести до уровня си и даже си++, но я не понимаю, кому это надо. Видимо, такие же фанаты, как и мы со своими ксашами и волатилами.
Перечислять достоинства С перед фортраном - это всё равно что объяснять, чем мерседес S600 лучше мопеда на 49 кубиков. Т.е. список преимуществ составить можно, а нужно ли?
Цитата:
thambs писал: в 11м стандарте вроде уже добавили такую функцию
Может, авторы стандарта С и посходили с ума (всё возможно), но изначально в стандарте какие-либо функции отсутствовали в принципе. Как таковые. Это в фортране "в новой версии введены функции...", а в С - есть ЯП и есть функции. Их либо надо писать самому, либо заюзать библиотеку типа CRT. А можно не юзать стандартные функции вообще, и будет рабочая программа (например, запуск-вызов функции винапи-завершение).
В этом смысле не вижу препятствий написать функцию, выдирающую нужные байты флоат-представления. Один раз написал и юзай на здоровье. Кстати, это будет логарифм по основанию 10, разве нет? а логарифм по основанию 2 легко вычисляется двоичным сдвигом.
Добавлено 13-11-2013 в 19:39:
Цитата:
thambs писал: ну или то что нельзя красиво бреакнуть цикл на несколько уровней вверх
Зачем красиво бреакнуть некрасивую конструкцию?
Есть же goto для таких случаев, даже Кармак юзал такой способ.
А вообще глубоко вложенных циклов лучше избегать.
>некрасивую конструкцию
поясни что с ними не так, мне этот момент не понятен. ну, например, 4 уровня -- это плохо?
>С задачами тех лет он справлялся. Сейчас его пытаются довести до уровня си и даже си++, но я не понимаю, кому это надо
так задачи для моделистов с тёх лет качественно, разьве изменились? параллельность добавилась и всё.
thambs
Считается, что высокий уровень вложения циклов - это признак плохого стиля программирования. Как правило, это можно решить созданием отдельных функций. Тогда и проблем с брейками не будет.
Пример:
C++ Source Code:
1
Vector a[100];
2
Vector b[100];
3
for ( int i = 0; i < 100; ++i )
4
for ( int j = 0; j < 3; ++j )
5
b[ i ][ j ] += a[ i ][ j ];
Легко решается перегрузкой оператора += у класса Vector, и имеем:
C++ Source Code:
Vector a[100];
Vector b[100];
for ( int i = 0; i < 100; ++i )
b[ i ] += a[ i ];
Проще и нагляднее.
Конечно, перегрузку операторов нежелательно использовать у классов, где значение оператора будет не очевидно интуитивно, но это уже другая история.
Если же красота кода мало заботит, то goto - прекрасный оператор для выхода из цикла любой вложенности. При этом этот оператор соответствует нативным машинным командам, т.е. не является сколько-нибудь вычислительно затратным.
Добавлено 15-11-2013 в 16:44:
Цитата:
thambs писал: так задачи для моделистов с тёх лет качественно, разьве изменились? параллельность добавилась и всё.
Приёмы программирования изменились. Сейчас важно не только писать быстрый код, но и писать его быстро. Для этого и пригождаются всякие классы, шаблоны, операторы и прочие изыски плюсов.
мм, а для чего вектора оборачивают в отдельный класс, а не используют обычный массив. типа защита от дурака, чтоб кто ни будь не додумался сложить его со скаляром? вот, кстати даже интересно стало, а есть библиотеки классов, реализующие размерности величин, так чтоб аж компилятор матерился, когда сантиметры с граммами сложить пытаешься?
thambs писал: а есть библиотеки классов, реализующие размерности величин, так чтоб аж компилятор матерился, когда сантиметры с граммами сложить пытаешься?
1> error C2679: binary '+' : no operator found which takes a right-hand operand of type 'main::weight_t' (or there is no acceptable conversion)
1> could be 'main::distance_t main::distance_t::operator +(main::distance_t &)'
1> while trying to match the argument list '(main::distance_t, main::weight_t)'
Т.е. компилятор намекает, что надо бы distance_t складывать с distance_t, а не с чем-то другим.
XaeroX писал: Считается, что высокий уровень вложения циклов - это признак плохого стиля программирования. Как правило, это можно решить созданием отдельных функций.
эт, ясно, а так что бы размерности умножались друг на друга и возводились в степень? это, вроде, тогда надо в каждый класс вводить член хранящий степень длины, массы и времени. что то заморочено получается. ну или, по крайней мере, для всех производных величин. или там можно всё выкинуть сразу на этапе компиляции?
thambs
Проще определить новый класс, скажем, area_t или squareDistance_t.
И возвращать его как результат умножения двух distance_t (релизовав так же через оператор).
Да, получается весьма геморно, ну так это потому, что компьютеру ещё со времен фон Неймана глубоко плевать, расстояние у тебя во флоате хранится или площадь.
XaeroX
ну не то что геморно а в общем виде нереализуемо. хотя, в виде некоторого препроцессинга, ещё до передачи компилятору, такую проверку, вроде можно сделать. может уже и есть где ни будь.
| IP: 
13-11-2013 11:54
