Еще немного, и ты скажешь, что правильно работающие программы писать проще, чем неправильно работающие.

Конечно! Нет этой противной, никому не нужной отладки :) Написал программу, скомпилировал, запустил - хоп, сразу работает! Профит же!

только из-за противоречия общепринятому стилю?

да

Еще немного, и ты скажешь

говори за себя. это не так сложно, как кажется

encapsulation is used to refer to one of two related but distinct notions

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

а что ещё есть в Хаскелле для организации инкапсуляции? ну кроме замыканий

классы типов

> говори за себя. это не так сложно, как кажется

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

> классы типов

а, точно, я почему-то думал о них только в ключе организации ad-hoc полиморфизма

LISPосрач

Каждый 3-й вопрос в development слетает в лиспосрач. Такого даже лет пять назад не было.

Срачи нужны, если в рамках приличия. А недовольство срачами и всякая хрень типа «давайте жить дружно» не нужно.

> Каждый 3-й вопрос в development слетает в лиспосрач. Такого даже лет пять назад не было.

в этой теме лиспосрача нет, даже LoveFan не отписался (вроде, не помню весь тред)

Такого даже лет пять назад не было.

четыре года назад было. правда, тогда ещё был bugmaker

Из всех этих рассуждений никак не следует что (a (b c a (b a c) b (b s b) b s c (b (b (b (b a)))))) будет нравиться большинству. Потому что это нечитаемо большинству программистов. Обратное - ложь.

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

1) Первый, это тот что, условно говоря, «изоморфен» двухмерному синтаксису отступами - как в python или в haskell (особенно во втором).

if <condition>
   then
      <true-form>
   else
      <false-form>

(if (condition)
    (true-form)
    (false-form))

case <form> of
    <value_1> -> <form_1>
    ...
    <value_n> -> <form_n>
    _        -> <form__>

(case (form)
  (value-1 (form-1))
  ...
  (value-n (form-n))
  (otherwise (form-otherwise)))

foo a
    | <condition_1> = <form_1>
    | ...
    | <condition_n> = <form_n>
    | otherwise

(cond ((condition-1) (form-1))
      ...
      ((condition-n) (form-n))
      (t (form)))

Разница в том, что на CL чтобы использовать специальную форму не нужно знать ровным счётом ничего, а чтобы использовать специальную форму в Haskell нужно знать где именно расставлять закорючки и сколько отступов где ставить. И ещё разница в том, что в Haskell мы не можем прозрачно определить специальную форму, а в CL - можем (в Haskell есть ленивые функции, но это не спасает, а TH это то что я считаю непрозрачным способом). Т.е. эти вещи в принципе одинаковые, я бы был не против если бы в Haskell был опциональный скобочный синтаксис (упс, он там уже есть :) равно как и синтаксис с {} - без необходимости считать пробелы) и в CL - опциональный синтаксис с отступами. В CL такого нет - сделать можно, но никто не делает, видимо потому что никому не нужно

Правда есть забавный режим в емакс: http://www.wisdomandwonder.com/wordpress/wp-content/uploads/2008/02/color-box.png как тебе такой синтаксис? Это по прежнему лисп, если что.

2) И второй уровень это префиксная запись инфиксных выражений:

most popular

(1 + 2) * 3 - 4 / 5

vs.

(- (* 3 (+ 1 2)) (/ 4 5))

Я был бы тоже не против от опциональной инфиксной записи (и опять упс - в Haskell это уже есть!1, т.е. дуализм инфиксной и префиксной записи для одной и той же функции). И опять же - в CL это очень просто добавить, но никто этого не делает - не нужно >_<

А Java читаема даже начинающим.

public class UFO implements Cloneable {

    public UFO(int Id,
               int X,
               int Y,
               int Z) {
        this.Id = Id;
        this.X = X;
        this.Y = Y;
        this.Z = Z;
    }

    public int Id () {
        return Id;
    }

    public int X () {
        return X;
    }

    public int Y () {
        return Y;
    }

    public int Z () {
        return Z;
    }

    public void Move (int dX, int dY, int dZ) {
        X += dX;
        Y += dY;
        Z += dZ;
    }

    private int Id;
    private int X;
    private int Y;
    private int Z;

    private UFO (UFO ufo) {
         Id = ufo.Id;
         X  = ufo.X;
         Y  = ufo.Y;
         Z  = ufo.Z;
    }

    public UFO clone() {
        return new UFO(this);
    }
}

vs.

(defclass ufo ()
  ((id :reader id :initarg :id :type index)
   (x  :reader x  :initarg :x  :type fixnum)
   (y  :reader y  :initarg :y  :type fixnum)
   (z  :reader z  :initarg :z  :type fixnum)))

(defmethod move ((ufo ufo) dx dy dz)
  (with-slots (x y z) ufo
    (incf x dx)
    (incf y dy)
    (incf z dz))
  ufo)

Или если это очень больно и не переносимо, то:

class ufo
  id :reader id :initarg :id :type index
  x  :reader x  :initarg :x  :type fixnum
  y  :reader y  :initarg :y  :type fixnum
  z  :reader z  :initarg :z  :type fixnum

method move (ufo ufo) dx dy dz
  with-slots (x y z) ufo
    incf x dx
    incf y dy
    incf z dz
  ufo

Можешь нанять лиспового фрилансера для реализации такого синтаксиса :)

Т.е. кому-то явно платят за LOC :) Можно с первого взгляда угадать - что здесь трунтерпрайз.

Я был бы тоже не против от опциональной инфиксной записи (и опять упс - в Haskell это уже есть!1, т.е. дуализм инфиксной и префиксной записи для одной и той же функции). И опять же - в CL это очень просто добавить, но никто этого не делает - не нужно >_<

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

where cond1
  and cond2
  and (  cond3
      or cond4
      or cond5
      or (   cond6
         and (  cond7
             or cond8
             or (   cond9
                and cond10))))

например. вместо

where
  (and cond1
       cond2
       (or cond3
           cond4
           cond5
           (and cond6
                (or cond7
                    cond8
                    (and cond9 cond10)))))

Это потому что есть специальные формы, которые не имеют отношения к инфиксу - они либо в скобочной записи пишутся, либо с помощью отступов. Тут or и and не имеют отношения к логическим \/ и /\ - это специальные формы. Но когда речь идёт о foldable математических операторах - + - * / /\ \/ mod div и так далее, то инфиксная запись очень естественна. Фактически типичный язык программирования и язык математических выражений - это два совершенно разных языка. Если писать большую программу на CL то больше времени уделяется архетектуре, пакетам, функциям, классам - для всего этого скобочный синтаксис абсолютно естесвеннен (как и синтаксис отступами), и меньше всего времени - математическому языку арифметики, булевой логики и т.п. Если заставить математиков писать арифметические формулы и логически выводы в лисповом синтаксисе - они завоют :)

о foldable математических операторах - + - * / /\ \/ mod div

mod и div конечно не foldable и не операторы, экскюзми.

Object Pascal же) Во free-шной православной инкарнации. И без Lazarusa, на начальном уровне ;) Чтоб не учить плохому - программированию мышкой и т.д.

Ох, далеко тебе ехать, добровольче. И не ровен час, пограничники забанят.

Smalltalk однозначно - он просто не может «не подходить», ибо отец ООП и лучшее его воплощение.
А для быдлоподелок даже ВижуалВасик - вполне ООП. :)

smaltalk

// P.S. brainfuck - тоже ничего