На каком языке вы программируете?

[Ильич]

В Unity3D в самый раз. Легко и красиво.

Спасибо, попробую.

[sasza]

Программирую на всякой фигне. Иногда даже не помню, как предыдущая фигня называлась. Серьёзно.

[Robert Dunwell]

Любой байт-код — тоже.

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

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

[Ильич]

Ассемблер — это просто способ записи аппаратных команд, а не язык программирования.

Ну всё-таки память расписывать не нужно, как мы делали в 1963 году на М20 (это ЭВМ была такая - ламповая!).

[Robert Dunwell]

APL

Всегда интересовал вопрос, как эти ихние закорючки вводятся и в какой кодировке хранятся.

Язык APL (a programming language) составлен моим дальним родственником, Стивеном Данвеллом, так что я должен был его знать.... Я даже в свое время составил на нем программу для учета программных разработок для программной лаборатории ИБМ в Бёблингене. Была особая 256-значная кодовая таблица для APL. Коды вводились с клавиатуры терминала-пишущей машинки типа Селектрик с помощью особого шрифтового шарика.

[Ильич]

Раньше программировал на машинном языке, RPG, COBOL, Fortran, PL/I, Ассемблере (IBM 370, Intel), APL, Pascal, QBASIC, С, С++, и т.д.

Минус APL, плюс Algol и кое-что специфическое вроде языка 1С.
Последняя машина, которая была полностью понятна СМ-4, она же PDP-11.

[yeggo]

У меня зависит от задачи. Если надо для телефона, то Java. Когда на линуксе, то bash и perl (ну и C иногда). Если надо настроить сайт, то PHP или Javascript, в зависимости от задачи. Если хочу что-нибудь скачать из интернета, то программирую на Perl, даже если на виндоусе. Для обработки текста часто использую VBA, так как он встроен в опенофис и в ворд с экселями.

[Ильич]

А вот захотел показать ребёнку, что Луна вокруг земли не вращается, написал на Delphi картинку .

Срочно пишите другую картинку, чтобы показать ребёнку, что Луна вокруг Земли таки вращается

Это только с Земли так кажется. Ну или в системе координат, где Земля неподвижна. А она движется. С Земли кажется, что и Солнце вокруг Земли вращается. И так оно и есть в системе координат, где Земля неподвижна. Так что система координат, где Солнце неподвижно, а Земля движется больше соответствует реальности.

Вот скрин-шот той программульки. Картинка, конечно, упрощена по сравнению  с реальным движением. Неточно заданы лунный месяц и солнечный год, движения по кругам, а не по эллипсам. Масштаб искажен сознательно, чтобы был виден характер движения, а то на экране Луна слилась бы с Землей.

Земля вокруг Солнца катится, и Луна тоже вокруг Солнца крутится. Болтается немного Луна около эллипса (в программе - круга) с фокусом на Солнце, но никакого круга, хоть деформированного, внутри которого была бы Земля, нет.
В реальности центр Земли, конечно, тоже чуть-чуть болтается.

[Hellerick]

А я совсем не имею делать ничего с динамической графикой. 
Со времен паскаля ничего такого не писал.

Если надо сделать какую-то картинку, я обычно генерирую SVG-код.

[RawonaM]

Земля вокруг Солнца катится, и Луна тоже вокруг Солнца крутится. Болтается немного Луна около эллипса (в программе - круга) с фокусом на Солнце, но никакого круга, хоть деформированного, внутри которого была бы Земля, нет.

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

[macropisec]

Здравствуйте!

В институте нас учили пользоваться C/C++, но с тех пор я ими не пользовался. Сейчас я применяю VBA и Fortran-90: на первом обкатываю отдельные алгоритмы, а на втором пишу окончательный вариант с целью получить исполняемый файл. Впрочем, иногда я оставляю программы только на VBA.

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

Одобряю, очень удобная связка, особенно если фортран вызывать из VBA.

[Ильич]

Земля вокруг Солнца катится, и Луна тоже вокруг Солнца крутится. Болтается немного Луна около эллипса (в программе - круга) с фокусом на Солнце, но никакого круга, хоть деформированного, внутри которого была бы Земля, нет.

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

В каком таком случае? В какой системе координат?
А если в системе координат привязанной к Солнцу, то Земля немного покачивается только. Центр тяжести системы Земля - Луна внутри Земли, как я помню.

[Triton]

В какой системе координат?

В инерциальной.

[Даниэль]

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

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

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

[arseniiv]

Так практически во всех функциональных языках присутствует элемент императивности. Из чистых ФП-языков разве что Haskell вспоминается.

Да и там этот элемент в виде синтаксиса do ... end присутствует, хотя формально это не императивность, а всего лишь удобный сахар для операций с монадами. Вся императивность заключена вне языка в том, что выполняет функцию main, отбрасывая результат её выполнения типа IO ().

+100500
Не знаю пока, что такое Скала, но Джаву менять надо срочно.

Вынужден согласиться. Если только интерфейсы, названные так же как классы (List — это класс? Ан нет!), туда не просочатся. Иначе тоже зря.

и нередко prolog

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

Причем на идеологическом уровне C#, скорее, не конкурент, а что-то вроде клона - "ответ" Microsoft.

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

Хороший язык программирования, как и хорошая математическая теория, не устаревает.

Неуместное сравнение. Если бы CS и технологии не развивались — всё было бы так, но увы, всё не так. Хороший раньше язык может устареть, и не надо придумывать отговорки типа «его считали хорошим для тех времён» — никакой абсолютной хорошести не существует. То, что считается хорошим, практически и есть хорошее.

[Robert Dunwell]

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

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

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

Научные и математические расчеты всегда являлись исключением - В ИБМ мы решали проблемы, где даже скорость света была мала.
К счастью, научные расчеты - очень маленький процент применений. Бывает, что подобные проблемы даже ассемблер не решит.  Для этого нужны принципиально новые технологии.
Я боюсь, что иногда решение подобных задач будет ждать разработки квантовых компьютеров, решающих задачи в мультиверсе...

[arseniiv]

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

Дааа?

Объективно можно будет судить о нем, когда Microsoft либо разорится, либо перестанет его поддерживать.

В .NET и C#, по-моему, достаточно есть, чтобы они могли уйти в свободное плавание и не утонуть.

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

Средства разработки не отменяют языки. Код пишется на языке, а не на средстве разработки, и компилятор понимает язык, а не средство разработки.

[sasza]

А вот захотел показать ребёнку, что Луна вокруг земли не вращается, написал на Delphi картинку .

Срочно пишите другую картинку, чтобы показать ребёнку, что Луна вокруг Земли таки вращается

Это только с Земли так кажется. Ну или в системе координат, где Земля неподвижна. А она движется. С Земли кажется, что и Солнце вокруг Земли вращается. И так оно и есть в системе координат, где Земля неподвижна. Так что система координат, где Солнце неподвижно, а Земля движется больше соответствует реальности.

Вот скрин-шот той программульки. Картинка, конечно, упрощена по сравнению  с реальным движением. Неточно заданы лунный месяц и солнечный год, движения по кругам, а не по эллипсам. Масштаб искажен сознательно, чтобы был виден характер движения, а то на экране Луна слилась бы с Землей.

Земля вокруг Солнца катится, и Луна тоже вокруг Солнца крутится. Болтается немного Луна около эллипса (в программе - круга) с фокусом на Солнце, но никакого круга, хоть деформированного, внутри которого была бы Земля, нет.
В реальности центр Земли, конечно, тоже чуть-чуть болтается.

С чего это вдруг траектория движения Луны относительно Солнца доказывает, что она не вращается вокруг Земли? Сядьте в самолёт, покрутите вокруг себя какой-нибудь предмет на верёвочке, потом рисуйте траектории относительно Земли, Солнца или любого другого небесного тела, и доказывайте, что "на самом деле" этот предмет вокруг вас не вращается. Или наоборот, наблюдайте из окна самолёта такого же человека с верёвочкой на земле, и доказывайте, что предмет не вращается вокруг него.

[arseniiv]

«Вращается», действительно, не абсолютное понятие. Конечно, в одной системе координат вращается, а в другой не вращается. Можно выбрать кучу систем, где Луна вообще стоит на месте. Но физика от этого не меняется!

Нет никакой системы отсчёта, которая была бы лучше другой. Это в пределах применимости ОТО, а они весьма широки. Там же, где она не применима, остаётся часто применима СТО, а выбор инерциальных систем отсчёта тоже довольно большой.

[Robert Dunwell]

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

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

[Марбол]

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

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

[Марбол]

Одобряю, очень удобная связка, особенно если фортран вызывать из VBA.

А вот это интересно! Я возьму на заметку.

[Robert Dunwell]

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

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

Я программировал на ассемблере в течение 10 лет. Я тоже руководил крупными проектами по разработке программных систем.
Я программировал на ассемблере и как системный программист, и как прикладной.
Я программировал на ассемблере как на крупных мейнфреймах, так и для микропроцессоров Интела и Моторолы.
Могу сказать, что, для того, чтобы программировать на ассемблере, должны быть очень веские причины.
Ни один проектный руководитель не даст программисту написать модуль на ассемблере, если это не АБСОЛЮТНО необходимо.
Ассемблер увеличивает сроки разработки на порядок.
Использование ассемблера сильно увеличивает стоимость разработки.
Ассемблер дает больше программных ошибок из-за недружелюбности и объемов письменных кодов.
Ассемблер намного труднее отладить и обслуживать.

[Ильич]

С чего это вдруг траектория движения Луны относительно Солнца доказывает, что она не вращается вокруг Земли?

А вы прочитайте то, что я написал. Тогда и вопрос отпадёт.

[Даниэль]

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

Дааа?

Собственно, во многих случаях Java дает оптимальное быстродействие, которое мог бы дать ассемблер. Но - все-таки не всегда. У JIT-компилятора есть временные ограничения, не позволяющие ему быть чересчур интеллектуальным.

В .NET и C#, по-моему, достаточно есть, чтобы они могли уйти в свободное плавание и не утонуть.

Вот тогда и посмотрим.