Муки выбора первого юзабельного языка (pascal за язык не считается). Есть два ООП ЯП: лиспы точеные и питоны золоченые...

А то что без .Net он «нинужын» — это вендорлокин :)

Я-то не то, чтобы сильно спорил, но авторы OpenSim, например, считают иначе - оно написано на Mono и вполне обходится без .Net.

Ну да, плакале-кололыс-грызли

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

В качестве альтернативы когда-то называли Worldforge, но это, скорее, ворох библиотек и протоколов для создания альтернативы, чем собственно целостая альтернатива.

для дельфи до сих пор, вроде, под онтопик ничего вменяемого нет.

Уже нет. А был кроссплатформенный CLX искаропки, прикинь да? :) Только они заигрались в умные и красивые... Не смогли определиться.

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

Ничо-ничо... Щас Мигелька вкурит свежих сорцов .Net — вообще будет полный ажур, ЕВПОЧЯ :)

Особенно для тех вещей, которых раньше в С++ сильнее всего не хватало.

Я с нетерпением жду, когда ж модули стандартизуют. Это едва ли не единственный пункт, по которому Object Pascal, он же Delphi Language, начисто переигрывает C++. Причём как переиграл в начале 90-х, так и остался впереди в 2015-м.

начисто переигрывает C++

Ну, некоторые восприняли это настолько некритично, что завязывались на порядок инициализации модулей, хотя в описании языка еще в Delphi 3 был черным по белому прописан АТАТАТ на этот счет. А привело это к чему? «Пересобери еще раз, может запустится» :)

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

Если в паскале забыть нужный uses - с вероятностью, близкой к 100% компилятор тут же ругнётся. Если в плюсах забыть #include - результат зависит от ОС, версий компилятора и применяемых библиотек и разумеется, фазы Луны. Я уж молчу про ошибку undefined referenced to vtable, у которой может быть полдесятка разных причин. Очень весёлые и труднообнаруживаемые ошибки могут произойти из-за неправильного написания стража компиляции - к счастью, во всех нормальных IDE они генерятся автоматом. Ну и скорость сборки тоже страдает, хотя на современных компах это наконец-то стало не так критично.

В плюсах этого «Пересобери, может запустится» в разы больше.

Это потому что плюсы и используются больше :) Хотя в моей практике ни разу не было, чтоб на отличненько собралось что-то в принципе не запускабельное на одних и тех же сорцах, для исправления чего требуется только пересборка, а не правка именно ошибок в #include или линковании зависимостей :) В Delphi фанатами модулей, не понимающими для чего модули и чего в них делать прямо запрещено описанием языка, легко допускалась ситуация, что результат конпеляции... не зависит от ничего кроме фазы луны, т.е. «формально» ошибок нет — потому что они в... голове пользователя языка — и по его мнению исправлять ничего не надо «потому что за это не заплатят, и вообще мы переписываем все на Delphi XE, просто пересобери еще раз».

Пожалуй, PicoLisp больше лисп чем CL или Ракет. Во всяком случае, по духу он ближе к первоисточнику.

Поддерживаю. Более того, CL и Racket вообще лиспами назвать можно с натяжкой. Все что делало лиспы лиспами — runtime instectable/modifible, dynamic binding, fexprs — ничего этого нет.

У set!-values есть возможность откатить/повторить транзакцию?

А зачем это может быть надо? Он просто атомарен. В каких случаях транзакцию может потребоваться повторить?

Практики по книгам приводят к цитатам из книг в продукшын коди

Что в этом плохого? Цитата в книге, как правило, обосновывается.

Пока пишут хеловорды. А когда начинается магия с метаклассами, декораторами, кастомными аксессорами и прямом ковырянии в dict класса - нихера не легко.

Это верно для любого ЯП. Когда ты начинаешь делать что-то сложное, это ВНЕЗАПНО становится сложным.

JS

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

pyston - An open-source Python implementation using JIT techniques.

Ты наркоман штоле, сука?

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

Узнаю ЛОР...

Питон: Достоинства: интуитивно-понятный синтаксис

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

буст и Qt с плюсами автоматически в комплекте не идут

В gentoo идут.

У если «буст и Qt ... не всегда идут в комплекте», то Racket тоже на самом деле состоит из Minimal Racket (ядра) и дополнительных пакетов.

С# дефакто

Это верно для любого ЯП. Когда ты начинаешь делать что-то сложное, это ВНЕЗАПНО становится сложным

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

JS - это раковая опухоль

Шта? js - божественен, es6 вообще мана небесная.

что-то я ничего вменяемого под онтоп на дельфях не припомню, видимо этот CLX был также как с#

Все что делало лиспы лиспами — runtime instectable/modifible, dynamic binding, fexprs — ничего этого нет.

Можно пример в виде кода? Возможность смотреть/редактировать код из REPL?

cl-user> (in-package :ibcl-user)
#<Package "COM.INFORMATIMAGO.COMMON-LISP.LISP.IMAGE-BASED-COMMON-LISP-USER">
image-based-common-lisp-user> (defun f (x)
                                (if (zerop x)
                                  1
                                  (* x (f (1- x)))))

f
image-based-common-lisp-user> (source 'f :function)
(defun f (x) (if (zerop x) 1 (* x (f (1- x)))))

dynamic binding

http://clhs.lisp.se/Body/m_defpar.htm

fexpr

Можно пример? Я не очень помню, как оно должно работать

видимо этот CLX был также как с#

Нет. Он просто был проприетарный. Соответственно, единственное использование — перенос уже написанного с виндовса.

но потом мне дали попробовать Python...

Можно пример трудночитаемого кода?

Ракету (И СБКЛ) надо собирать самому, в репах одна тухлятина. И Иметь под рукой Emacs.

никаких нагромождений скобок.

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

Открываешь любой репозиторий с питоном на гитхабе и читаешь.

Если конкретнее, вот с этим проектом пришлось столкнуться: https://github.com/ProgVal/Limnoria/blob/master/src/registry.py

Регулярные выражения, очевидно, не считаются, они везде одинаковы (и не так уж и нечитаемы ИМХО).

Лисп: элитарность.

Да никакой там нет элитарности. Просто хороший инструмент.

Годная обвязка над процессингом. Поваял на нём немного говнеца.

Но для того, чтобы в нём не потеряться нужно пользоваться плагинами, которые подсвечивают уровни вложенности скобок

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

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

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

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

В CL куда большая проблема – многословность и длиннословность.

Можно пример трудночитаемого кода?

На питоне? Ну хотя бы вот

from inspect import Signature, Parameter

def make_sig(*names):
   parms = [Parameter(name, Parameter.POSITIONAL_OR_KEYWORD) for name in names]
   return Signature(parms)

class Structure:
   __signature__ = make_sig()
   def __init__(self, *args, **kwargs):
      bound_values = self.__signature__.bind(*args, **kwargs)
      for name, value in bound_values.arguments.items():
         setattr(self, name, value)

class Stock(Structure):
   __signature__ = make_sig('name', 'shares', 'price')

class Point(Structure):
   __signature__ = make_sig('x', 'y')

На питоне? Ну хотя бы вот

Вообще-то всё понятно. Не сложнее, чем аналогичный код с CLOS/MOP. Немножко странно, что такой __init__ автоматически не делается (там же просто заполнение слотов переданными аргументами).

Если конкретнее, вот с этим проектом пришлось столкнуться: https://github.com/ProgVal/Limnoria/blob/master/src/registry.py

Видимо «читаемость» очень субъективная характеристика. Большинство кода на Java мне читать гораздо труднее, чем то, что по ссылке.

Типичное блабла, скопипащеное от других «недоспециалистов» с лора по принципу «бабка бабке сказала».

Причём как переиграл в начале 90-х, так и остался на свалке в 2015-м.

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

APL, J, Sendmail.cf. Скорее всего, Forth.

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

Мне фактически одновременно дали попробовать Erlang и Python, и, хоть я большой противник использования отступов как части языка, считаю, что с точки зрения синтаксиса Erlang кошмарен, наверное это самый ужасный язык, на котором мне приходилось много писать. Но в целом Erlnag BEAM конечно намного интереснее питона.

Узнаю ЛОР...

Дата регистрации: 27.10.2014 13:58:22

Э?

ТС, выбирай лиспы точеные. Они летают, и ты лети, подальше от питона.

Мне фактически одновременно дали попробовать Erlang и Python, и, хоть я большой противник использования отступов как части языка, считаю, что с точки зрения синтаксиса Erlang кошмарен, наверное это самый ужасный язык, на котором мне приходилось много писать. Но в целом Erlnag BEAM конечно намного интереснее питона.

Это ты ещё Scala исходники не читал, вот уж где с синтаксисом перестарались

От Erlang очень уж сильно прологом веет, от этого странности.

Ну а питон с этим его __ехал__ _андерскор_ через __андерскор__ и selfом погонял это вообще отдельная история.

В CL куда большая проблема – многословность и длиннословность.

В Racket эту проблему решили с помощью модулей. Когда при импорте можно указать (prefix-in m: my-long-package-name), то нет проблем называть модули достаточно длинно (для однозначной идентификации), а все импортируемые символы достаточно коротко. Опять же, при импорте можно указать (rename-in my-super-b-trees [map tree-map]) и использовать удобное для себя имя.

Жаль, что к CL нельзя прикрутить модули не поломав напрочь совместимость.

Если конкретнее, вот с этим проектом пришлось столкнуться:

Единственная претензия к исходнику по ссылке — он слишком «тупой» и разжеванный.

Субъективно после питоновского self js'ый this тычешь палочкой и не понимаешь, как с ним можно иметь дело.

Эликсир попробуй. Работает на эрланговской вм, по сути тот же эрланг, только с более простой мордой.
http://elixir-lang.org/

Есть лиспота на эрланге, дай бог жив буду, хоть попробую.
https://en.wikipedia.org/wiki/LFE_(programming_language)

Дык они и у меня тусклые. Но таки разноцветные.

JS'ный this всегда указывает на окружение получателя сообщения, где бы ни был определен метод. Это нормальная практика для ООП-языков. А вот пистоновский self и правда непонятно что делает. Видимо, какая то очередная ошибка в дизайне языка.

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

Видимо, в лиспах какие-то проблемы дизайна, раз там поднимаются подобные вопросы.

Питоновский self указывает:

class Class(object):
    def method(self):
        pass

obj = Class()

1.) Если прибегнуть к ручной привязке — Class.method(obj), то будет то же самое, но, как видно, ничто не мешает передать вместо объекта obj любой другой объект. Но тут уж ССЗБ.

Первый вариант наиболее распространен, и, как правило, если видишь self в методе, то уверен, что это обьект, который владеет методом.

Видимо, в лиспах какие-то проблемы дизайна, раз там поднимаются подобные вопросы.

Нет, там просто принят замшелый стиль оформления исходников с длинными идентификаторами. Плюс нет модулей вменяемых, только пакеты.