языки с самым лаконичным синтаксисом

[JTG]

В одну строку можно заколбасить, но "readability counts".

def qsort(lst):
    return [] if not lst else qsort([x for x in lst[1:] if x < lst[0]]) + [lst[0]] + qsort([x for x in lst[1:] if x >= lst[0]])

def qsort(lst):
    if not lst: 
        return []
    else:
        pivot = lst[0]
        left = qsort([x for x in lst[1:] if x < pivot])
        right = qsort([x for x in lst[1:] if x >= pivot])
        return left + [pivot] + right

Собственно использование в разумных пределах list comprehensions (списковых выражений, или как правильно перевести?) и человеческого тернарного оператора очень часто помогает сократить питонячий код, не превращая его в перл. Питон довольно лаконичен

[Kostia]

списковых выражений, или как правильно перевести?

По смыслу больше "генератор списков" подходит )

Вариант на руби с wiki, добавляет к классу array метод qsort:

class Array
   def qsort
      return self.dup if size <=1
      l,r = partition   {|x| x <= self.first}
      c,l = l.partition {|x| x == self.first}
      l.qsort + c + r.qsort
   end
end

Чем изучение Haskell/Python вредит программисту

[Utkin]

Чем изучение Haskell/Python вредит программисту

Статья ни о чем.

[the_deer_one]

Kostia

По смыслу больше "генератор списков" подходит )

не, генерация это скорее Computation Expression

[Kostia]

Просто вот это:

[y | y <- xs, y >= x]
[x for x in lst[1:] if x >= lst[0]]
{|x| x >= self.first}

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

Сообщение от Utkin

Статья ни о чем.

А вот лично я впервые столкнулся с подобной проблематикой после постижения PHP, затем все усугубилось после изучения прототипов JS и плюшек Ruby, и совсем все плохо стало когда начал постигать Haskell, который не только лаконичней С(в среднем раз в 10 меньше кода), но и быстрее o_O в скорости выполнения раза ~2(Душкин Р. В. Функциональное программирование на языке Haskell c. 48). Когда на работе только C++ и C#, то это несколько напрягает, благо в C++ есть шаблоны и можно творить шаблонную магию. =)

[MihalNik]

который не только лаконичней С(в среднем раз в 10 меньше кода), но и быстрее o_O в скорости выполнения раза ~2(Душкин Р. В. Функциональное программирование на языке Haskell c. 48).

Мм.. магические числа? Качнул. С 48:

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

Что значит "для некоторых задач"?
Исходный код в 10 раз короче - это с учетом комментариев или без них? Или коду на Хаскеле положен отдельный, внеконкурсный FAQ?

[Utkin]

и совсем все плохо стало когда начал постигать Haskell, который не только лаконичней С(в среднем раз в 10 меньше кода), но и быстрее o_O в скорости выполнения раза ~2(Душкин Р. В. Функциональное программирование на языке Haskell c. 48).

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

А вот лично я впервые столкнулся с подобной проблематикой после постижения PHP, затем все усугубилось после изучения прототипов JS и плюшек Ruby, и совсем все плохо стало когда начал постигать Haskell, который не только лаконичней С

О, как это узнаваемо. Давайте будем продолжать сравнивать языки высокого уровня и языки сверхвысокого уровня и будем по-прежнему мочиться от счастья. Хотите аналогию? Вы сравниваете Дельфи и Ассемблер. Или к примеру если брать автомобили - Вы сравниваете шестерку классику с каким-нибудь мерседес бизнес класса.

[Kostia]

И потом Вы думаю сами понимаете, что скорость не является свойством языка. Скорость это свойство реализации, то есть качественный показатель транслятора.

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

О, как это узнаваемо. Давайте будем продолжать сравнивать языки высокого уровня и языки сверхвысокого уровня и будем по-прежнему мочиться от счастья. Хотите аналогию? Вы сравниваете Дельфи и Ассемблер. Или к примеру если брать автомобили - Вы сравниваете шестерку классику с каким-нибудь мерседес бизнес класса.

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

Исходный код в 10 раз короче - это с учетом комментариев или без них? Или коду на Хаскеле положен отдельный, внеконкурсный FAQ?

[MihalNik]

Kostia, Вы сообщения JTG, Utkin'a (п.1) пропустили?
Я вроде вот нигде не спрашивал про кол-ва строк кода. А то, знаете ли, все можно закатать в одну строчку. Названия сократить (вплоть да a,b,c,d,...ab,ac,ad...). А где граница исходно вот этого с лаконичностью:
http://ru.wikipedia.org/wiki/%D0%9E%...86%D0%B8%D1%8F
?
Поэтому и спрашиваю еще раз: что будет в свете "код с комментариями"?
Поскольку анонимная абстракция, по определению не может быть само документированной. А также - как насчет ее рефакторинга через полгода? Настолько же "умна" IDE, сколь и язык?

[Kostia]

А то, знаете ли, все можно закатать в одну строчку.

Можно:

for (i=0; i<100; ++i) printf("привет"); // Сколько здесь строк кода?

Тут 2 логические строчки кода. Что не ясно?

Поэтому и спрашиваю еще раз: что будет в свете "код с комментариями"?

Странный вопрос, комментируйте код как хотите и сколько хотите

Названия сократить (вплоть да a,b,c,d,...ab,ac,ad...). А где граница исходно вот этого с лаконичностью

Для этого придумали Code Conventions *.

Поскольку анонимная абстракция, по определению не может быть само документированной.

Что-то я не понял, о чем вы?