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

JavaScript

В те дикие времена матмодели писали на бумаге ваще то :)

А графический интерфейс эмулировался элементами псевдографики :)

Я помница чудные такие осцилограммы ими рисовал на ДВК-2 :)

Почему нет 1С?! Очень популярный язык же.

Судя по ТОП 3, не ЛОР, а сборище зануд.

> Судя по ТОП 3, не ЛОР, а сборище зануд.

бери сразу ТОП 12

А почему ответ «не программирую» есть, а «не работаю» нет?
На ЛОРе же не только рабочие.

А так, если из этих то C и Perl мне ближе. lisp немного юзал.

Чепуху? Не зря говорят - побеждает сильнейший. С++ сильнейший язык :)

Ruby. Раньше ещё и bash, но потом оказалось, что мои башевые скрипты можно прекрасно переписать на руби, попутно улучшив и добавив читабельности/понятности/функциональности.

С++, немного гуя на C# под оффтопик

Сейчас наверное плюсовые хейтеры срут кирпичами. Ждем постов, полные жопной боли, про три вида лжи и т. п.

> тут то и необходимо хоть и на скорую руку, но всё же думать как сделать наиболее понятно и расширяемо

Это всё достаточно легко делается после первой реализации. Когда код написан проще оценить всю работу в целом и сделать ту же «расширяемость» правильнее. В результате - меньше костылей будет. Первый рефакторинг можно успеть сделать до показа заказчику. Но на этом этапе на код мало кто смотрит :)
Если проект длительный и на него выделяются ресурсы, то рефакторинг можно делать регулярно, доводя до определенного совершенства.

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

Как я уже говорил - со временем ваш говнокод будет более качественным прямо со старта.
Во вторых - чтобы вы не писали, всегда можно написать лучше. Просто с вашей колокольни этого ещё не видно. Т.е. идеальный код всеравно не написать.
В третьих - это и называется работа. За любое «дольше» должны платить деньги. Если задача - бюджетное говно, она автоматом заслуживает говнокода. Сделал и забыл.
В четвертых - заказчики любят получать первые результаты максимально быстро, аж руки чешутся. Хочешь чтоб тебя ценили - оправдывай ожидания. Такие вот они люди :)

Да, поистене творческая работа тогда будет)

Вполне творческая улучшать работающий проект и наглядно видеть результаты улучшений на живой системе. Опыт накапливается гораздо быстрее чем если бесконечно пытаться написать идеальный hello world.
И хорошие идеи приходят внезапно. Внедрить их в несуществующий код трудно. В результате идеи забываются и остаются нереализованными. А впихнуть в тестовую врсию живого проекта и посмотреть что да как - вполне можно.
А сколько удовольствия от ощущения что твой код кем-то используется и полезен!

Первое место у «C++ на работе»... знатный бред, прямо так хлебом не корми, дай классы порасписывать - дела подождут

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

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

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

просто у меня отвращение к этому языку:-)

давай свой топ 3 предлагай!

Глупый холивар, но выражение «более изящное ООП и динамика» заинтересовало меня.

ну вот игрушечный пример, что мешает писать в таком стиле(я думаю вполне привычном для многих) -

(defclass person ()
  ((name :initarg :name
	 :accessor name)
   (family :initarg :family
	   :accessor family)
   (parents :initarg :parents
	    :initform nil
	    :accessor parents)
   (sex :initform 'm 
	:initarg :sex
	:accessor sex)
   (like-names-m :initarg :like-names-m
		 :accessor like-names-m)
   (like-names-f :initarg :like-names-f
		 :accessor like-names-f)))

(defgeneric create-children (a b))
(defgeneric like-name (a &optional sex))
(defgeneric say (a))

(defmethod say ((a person))
  (format t "~&Привет, я - ~a ~a" (name a) (family a))
  (cond ((parents a)
	 (format t " и у меня есть родители:")
	 (loop :for parent :in (parents a)
	       :do (format t "~&~a ~a" 
			     (name parent) (family parent))))
	(t nil)))

(defmethod like-name ((a person) &optional (sex 'm))
  (labels ((rand-name (names)
	     (nth (random (length names)) names)))
    (case sex 
      (m (rand-name (like-names-m a)))
      (f (rand-name (like-names-f a)))
      (else (error "like name")))))

(defmethod create-children ((a person) (b person))
  (cond ((equal (sex a) (sex b))
	 (error "WTF?"))
	(t (let ((sex (nth (random 2) '(m f))))
	     (make-instance 'person 
			    :name (or (like-name a sex)
				      (like-name b sex))
			    :family (cond ((equal (sex a) 'm)
					   (family a))
					  (t (family b)))
			    :parents (list a b)
			    :sex sex)))))
  
;; Using
(defun make-family ()
  (let* ((father (make-instance 'person :name "Рома" :family "Ковалёв"))
	 (mother (make-instance 'person :name "Лена" :family "" :sex 'f
				:like-names-m '("Артём" "Александр")
				:like-names-f '("Оля" "Даздраперма")))
	 (children (create-children mother father)))
    (say father)
    (say mother)
    (say children)
    (values father mother children)))
    
(make-family)
;;Привет, я - Рома Ковалёв
;;Привет, я - Лена 
;;Привет, я - Даздраперма Ковалёв и у меня есть родители:
;;Лена 
;;Рома Ковалёв
;;#<PERSON {BEBF439}>
;;#<PERSON {AAAD1B1}>
;;#<PERSON {AB1A541}>

> вы предлагает слишком крайние меры - практически не думать в общем

Я предлагаю решать задачи наиболее быстрым и удобным вам путём.
Если взяли на работу, значит уровень вашего программирования их уже устраивает.
Так что нечего комплексовать.

Я бы сделал настраиваемую абстракцию этого алгоритма, вынес бы её в отдельный модуль, подключал его в тех местах, где он нужен

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

У меня сейчас есть рабочий проект, бизнес-логику которого стоило бы рефакторить в таком же русле как вы предлагаете. Так уже с пол года не могу решить как лучше реализовать абстракцию, т.к. всё время ловлю себя на мысли, что код становится только сложнее.
Жали бы сроки + убеждения - сделал бы абстракцию на тяп-ляп. Чем не тот же говнокод? 8)
ЗАТО АБСТРАКЦИЯ!! Я ЖЕ КРУТОЙ!! ВСЁ ПО ПОНЯТИЯМ! Да? :)

Keep it simple.

И помните:
1. Рано или поздно ваш код всеравно выкинут. Даже идеальный.
2. Вы всего лишь переводчик с языка человеческого в понятный компьютеру. Всё.
3. Ах да, на вашем коде наверняка зарабатывают деньги. Так что выжмите из этого максимум минимумом усилий.

До псевдографики на ДВКашке руки не дошли.

Ты путаешь качественный код с наворачиванием абстракций. Качественный код можно и нужно писать сразу. При условии что квалификации хватает конечно. А вот абстракции городить по мере надобности, это да.

А разве Питон не раньше появился, чем Руби?

столько спорных утверждений высказываете что даже спорить лень)

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

у меня сейчас есть проект, написанный именно в таком стиле

А на этапе реализации поняли бы, что не учли ряд нюансов, абстракция обросла кучей костылей и стала сложней в понимании чем «реализация в лоб»

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

3. Ах да, на вашем коде наверняка зарабатывают деньги. Так что выжмите из этого максимум минимумом усилий.

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

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

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

Конечно, если вы даже не представляте, как решать задачу, то тут имеет смысл писать попутно разбираясь, а когда стоит привести код в поддерживаемое состояние - дело каждого, но опыт показывает - если вам через какое-то время приходится существенно долго разбираться в своём же коде, то здесь что-то не так:)

perl в основном :)

Интересно почему же столько С++. Неужели до сих пор на нем столько много проектов?

На РСДН тоже С и С++ больше всего в голосовании.

У нас есть 12 хаскельщиков!

Упс. 11.

Просто личная неприязнь? Чем же он так плох?

не думал что на паскале столько программеров. Таки хорошо.

> не думал что на паскале столько программеров.
Ничего удивительного, учитывая кол-во школоты на ЛОРе.

>Ничего удивительного, учитывая кол-во школоты на ЛОРе.

теперь ясно почему С/C++ лидирует.