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

[jola]

Что сообщество скажет про язык Rubi.
Говорят, простой для освоения.

[Dusty]

BABBAGE - ЯЗЫК ПРОГРАММИРОВАНИЯ БУДУЩЕГо http://jtsoftik.narod.ru/pricol/umor/babbage.html

[CADengee]

опрос говорит сам за себя
ругайтесь матом, господа )))

[zamtmn]

Meknotek
>>Пример 1: Экспорт...
Задача довольно серьезная, я бы использовал с/срр - еслиб знал, а так как незнаю - написал бы на паскале))

>>Предлагаете писать в Экселе?
Нет, предлагаю писать на том, на чем знаеш и умееш. Большинство "инженеров-конструкторов" слишком много внимяния уделяют поиску перспективных средств и слишком мало времени и сил остается на решение задачи.

[Meknotek]

Сообщение от zamtmn Meknotek >>Пример 1: Экспорт... Задача довольно серьезная, я бы использовал с/срр - еслиб знал, а так как незнаю - написал бы на паскале))

Вот и тот и другой язык я бы использовать не стал )))) Для профессионала-программиста может и не проблема, но мне удобней в Python оперировать простыми и понятными конструкциями и функциями, чем вымудряться в C/C++. Например, "импорт" 24-мб текстового файла Лиры (монолитка 18 этажей) в альфа-версии моего "конвертера Лира-СКАД") занимал у меня секунд 8, вместе с "переработкой" во внутренние форматы данных (удобные для меня). Может и много, на С++ наверняка быстрее было бы. Только зачем? На Python я написал программу, попробовал результат, перекинул в СКАД геометрию (узлы, основные типы элементов), АЖТ, объединение перемещений. Обдумал куда двигаться дальше, как лучше сделать импорт других важных вещей (нагрузок, проката и т.п.), какие структуры данных применить и т.п. Задумчиво повертел в 3Д графике СКАДа. А на С++? дописывал бы программу сейчас может быть или вообще забил бы на нее.

Сообщение от zamtmn >>Предлагаете писать в Экселе? Нет, предлагаю писать на том, на чем знаеш и умееш. Большинство "инженеров-конструкторов" слишком много внимяния уделяют поиску перспективных средств и слишком мало времени и сил остается на решение задачи.

Другая крайность - использовать только то, что изучил 20 лет назад, не обращая внимания на новые, гораздо более эффективные методы и инструменты.

[zamtmn]

>>Вот и тот и другой язык я бы использовать не стал
я писал про себя

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

>>Другая крайность - использовать только то, что изучил 20 лет назад, не обращая внимания на новые, гораздо более эффективные методы и инструменты.
Крайности есть всегда, истина - гдето посередине))

[Meknotek]

Сообщение от zamtmn >>Вот и тот и другой язык я бы использовать не стал я писал про себя

ну так прозвучала мысль об использовании конкретно С/С++, "если б знал". Не знаете, а уже склоняетесь к нему. Странно

Сообщение от zamtmn >>но мне удобней в Python оперировать простыми и понятными конструкциями и функциями Это ни значит что питон для этой задачи чемто лучше любых других актуальных средств. Лишнее подтверждение что каждый хвалит свои привычные инструменты))

Чем "не лучше/не хуже" других "актуальных средств"? того же "актуального" С++? Python по скорости - однозначно хуже. По удобству и скорости написания программ - однозначно лучше. Человеку, который на изучение программирования и написание программ не может тратить много времени, а скорость работы программы, запускаемой максимум раз в неделю (ну пусть несколько раз в день), не имеет значения - что важней? Инженер - это не профессиональный программист, который должен ориентироваться на миллионы копий программ и "экономить" каждую миллисекунду работы и каждый килобайт памяти, даже тратя на тот же алгоритм в 2-3 раза больше времени, т.к. это его работа. Инженеру главное - простота изучения "неосновного" инструмента и скорость разработки готовой программы. Все то, что важно для проф.программиста - для инженера не имеет никакого значения!

Сообщение от zamtmn >>Другая крайность - использовать только то, что изучил 20 лет назад, не обращая внимания на новые, гораздо более эффективные методы и инструменты. Крайности есть всегда, истина - гдето посередине))

О чем и речь.

[zamtmn]

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

но мне удобней оперировать простыми и понятными конструкциями и функциями

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


Мне от среды разработки надо: доступность, наличие обновлений, удобные средства написания-отладки, кроссплатформенность, скорость как компиляции так и программы. Наличие большого количества библиотек на все случаи жизни для меня не критично (всё люблю дклать сам), а для когото этот фактор на первом месте. Я использую lazarus\fpc - полностью перекрывает мои потребности, смысла бросаться на изучение чегото более "перспективного" не вижу

[Meknotek]

Сообщение от zamtmn >>По удобству и скорости написания программ - однозначно лучше Я не хочу спорить лучше-хуже... На с (как и любом нормальном языке) можно писать всяко, в том числе и а можно заворачивать конструкции что до всех, включая автора суть дойдет с большим трудом. Это больше от человека зависит, чем от языка.

Не обижайтесь, но Вы явно не пробовали писать на "чистом" С что-то сложнее Hello world

Сообщение от zamtmn Напиши такое на какомнибудь форуме сишников - не согласятся))

Я с фанатиками не разговариваю

Сообщение от zamtmn Наличие большого количества библиотек на все случаи жизни для меня не критично (всё люблю дклать сам)

У нас с Вами разные понятия "библиотек" тот же NumPy, написанный на С (для скорости) - тоже сами делали бы? Я понимаю что Вам скорее всего это не критично, а вот Chardash спрашивал про сравнение Python с Fortran с точки зрения "научных вычислений". Я думаю не стоит сравнивать Lazarus с Fortran в части научных вычислений или искать библиотеку для операций с матрицами и многомерными массивами для Lazarus (подсказка - матрицы и операции с ними нужны для МКЭ например). Даже если Вы и "напишите сами" такую библиотеку, потратите несколько недель/месяцев, то она явно не будет соревноваться по скорости и функциональности с написанной профессионалами.

Сообщение от zamtmn Я использую lazarus\fpc - полностью перекрывает мои потребности, смысла бросаться на изучение чегото более "перспективного" не вижу

Ну лично Вас я и не призывал что-то новое изучать но советовать Lazarus инженеру, который выбирает что-то изучения, особенно с "прицелом" на научные вычисления, я бы не стал.

P.S.: Для примера: список модулей/пакетов/библиотек для науки/вычислений с использованием Python - http://wiki.python.org/moin/NumericAndScientific

[zamtmn]

>>Не обижайтесь, но Вы явно не пробовали писать на "чистом" С что-то сложнее Hello world
Нет, но переодически приходится поковыряться в "чужих" опенсурсных исходниках

Откуда уверенность что в Lazarus нельзя использовать теже сишные библиотеки? То что меня не интересуют сторониие библиотеки, не значит что их нет для Lazarus`а

[Meknotek]

Сообщение от zamtmn >>Не обижайтесь, но Вы явно не пробовали писать на "чистом" С что-то сложнее Hello world Нет, но переодически приходится поковыряться в "чужих" опенсурсных исходниках

Тогда скажу по-другому: Вы явно не пробовали писать на Python даже "Hello, world!" (и сравнить с тем же C)

Сообщение от zamtmn Откуда уверенность что в Lazarus нельзя использовать теже сишные библиотеки? То что меня не интересуют сторониие библиотеки, не значит что их нет для Lazarus`а

Насколько я знаю, сейчас с большим или меньшим успехом "приделать" можно все ко всему. Вопрос, каких сил и времени это будет стОить? Тем более я говорил не об абстрактных "сишных" библотеках, а о конкретных библиотеках для Python, которые для скорости написаны на С. У Python есть определенные средства для расширения, т.к. как он изначально задумывался в т.ч. и для работы в паре с низкоуровневым языком.

[metod]

имея 10 летний опыт с/с++, поменьше стажа с matlab и Mathematica, понял, что для меня важнее сейчас скорость разработки и наглядность. Поэтому я за Python с его библиотеками. К моему сожалению с++ последней редакции стал еще более трудно перевариваемым.

[zamtmn]

>>Тогда скажу по-другому: Вы явно не пробовали писать на Python даже "Hello, world!" (в сравнении с тем же C)
Это да. Но думаю и Вы не пробовали "m=qL^2/8" на Lazarus

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

>> Тем более я говорил не об абстрактных "сишных" библотеках, а о конкретных библиотеках для Python, которые для скорости написаны на С
Вообщето это "враперы" для использования этих библиотек в питоне. Специально для питона писать математические библиотеки на С - по меньшей мере странно, они пишится универсально, для использования в как можно большем количестве языков

>>но советовать Lazarus инженеру, который выбирает что-то изучения, особенно с "прицелом" на научные вычисления, я бы не стал.
Я ничего никому не советовал. В том числе и питон с прицелом на научные вычисления не советую))

[Meknotek]

Сообщение от zamtmn Это да. Но думаю и Вы не пробовали "m=qL^2/8" на Lazarus

И не собираюсь пробовать. Pascal лично для меня - "мертвый" язык, в любой форме и под любым "соусом" (Delphi, Lazarus, да хоть Turbo Pascal...). Уж извините.

Сообщение от zamtmn >>Насколько я знаю, сейчас с большим или меньшим успехом "приделать" можно все ко всему "приделать" тут не подходит, это называется использовать динамическую библиотеку. А вот использование в скриптовом языке нативных функций из динамических библиотек больше подходит к термину "приделать", не смотря на "определенные средства"

Вы немного не поняли о чем идет речь. Естественно в Python можно тем или иным образом использовать дин.библиотеки, как и в любом другом скриптовом или компилируемом языке. Речь шла о написании на С расширений для интерпретатора Python, чтобы использовать этот "быстрый" код напрямую в Python-программе, определять новые объекты/функции/типы данных. А не возиться с вызовом функций из дин. библиотек неизвестного происхождения и пытаться потом "разгрести" возвращаемые значения (речь не идет о "простых" функциях вроде sin(x) и подобных, где и так все предельно ясно).

Сообщение от zamtmn >> Тем более я говорил не об абстрактных "сишных" библотеках, а о конкретных библиотеках для Python, которые для скорости написаны на С Вообщето это "враперы" для использования этих библиотек в питоне. Специально для питона писать математические библиотеки на - по меньшей мере странно

Да нет, это не wrappers. Я вот про тот же NumPy говорю (см. выше про "расширения") - это специально для Python написанный "математический пакет". В основе используется LAPACK. Но пакет изначально ориентирован на Python. Замечу, "Основан на N" или "обертка для N" - это немножко совсем разные вещи А "wrappers" - это например PyQt, как раз Qt + "обертка" для использования в Python. (хотя в принципе в таком синтаксически простом языке как Python различия для пользователя могут быть не видны).

Сообщение от zamtmn Я ничего никому не советовал. В том числе и питон с прицелом на научные вычисления не советую))

Конечно не советуете ))) Вы-то его не использовали ))) А я вот советую.

[bargool]

вот веселятся..

[zamtmn]

>>В основе используется LAPACK
Не пробовал, но думаю что ничто не помешает использовать его в лазаре.

Да нет, всё я правильно понял, просто для меня странно звучит

а о конкретных библиотеках для Python, которые для скорости написаны на С

Вот например BLENDER написан примерно так: C 59%, C++ 29%, Python 10%, Other 2%. Питон там какраз для описаной вами "склейки" сишного кода и в качестве скриптового языка. Будем считать что он написан на питоне?

[Meknotek]

Сообщение от zamtmn >>В основе используется LAPACK Не пробовал, но думаю что ничто не помешает использовать его в лазаре.

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

Сообщение от zamtmn Да нет, всё я правильно понял, просто для меня странно звучит >>а о конкретных библиотеках для Python, которые для скорости написаны на С

Привыкайте, Python популярный язык, многие вещи делают специально для него

Сообщение от zamtmn Вот например BLENDER написан примерно так: C 59%, C++ 29%, Python 10%, Other 2%. Питон там какраз для описаной вами "склейки" сишного кода и в качестве скриптового языка. Будем считать что он написан на питоне?

Открою Вам мааааленький секрет: Кроме возможности использовать С/С++ для расширения возможностей Python, можно наоборот использовать Python для расширения возможностей C/C++ программ (aka "скриптовыя язык для расширений/плагинов"), Blender как раз типичный пример. Множество других примеров - GIMP, NotePad++, Cinema 4D... (все перечислять не буду - можно в интернете посмотреть кому интересно). И да, в таких случаях все же пишут - "Written in C, C++ and Python"

[zamtmn]

Ага, вот и выходит - от С/С++ никуда не дется. Удалось реализовать задуманное в рамках NumPy и далее по списку - хорошо, нет - вперед и с песней.

[Meknotek]

Сообщение от zamtmn Ага, вот и выходит - от С/С++ никуда не дется. Удалось реализовать задуманное в рамках NumPy и далее по списку - хорошо, нет - вперед и с песней.

Я думаю "для научных вычислений" NumPy более чем достаточно "Привязка" к С/С++ интересна в первую очередь разработчикам таких библиотек, результатами работы которых я и предлагаю воспользоваться - об эффективности такой "связки" говорит огромное число библиотек к Python (пусть даже часть из них просто Wrappers, но число этих "оберток" не стоит переоценивать, да и для пользователя обычно нет никакой разницы) А вот интересно, что будет, если не удастся реализовать задуманное в рамках Lazarus? писать самому библиотеки? не смешите уж

Давайте прекратим этот бессмысленный спор "Python vs. Lazarus", т.к. Chardash спросил про "сравнение Python и Fortran" - ответ был дан, Lazarus тут уж никаким боком

[Dyuk]

Самый перспективный язык - английский.
Для инженерных задач вполне хватает MathCAD - там всё очень интуитивно - через пару дней изучения уже можно решать большинство инженерных задач - а далее изучать уже можно по мере возникновения потребностей.