Создатель Python разочарован в Scala

> А в чём ваша проблема?

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

> смутно подозреваю, вы вряд ли придерживаетесь какого-либо coding style и в других языках

Пройдите еще раз курсы повышения квалификации по телепатии.

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

>Ну, не все же, как ты, считают быдлокодерство вершиной своей карьеры (и своих интересов)

А не иначе собрался закончить карьеру полковником уфскн в отставке? Ну тогда зря с программиста начал. Они дальше майора в уфскн не растут обычно

>Нет. Ему пофиг. У него нет и не было цели "завоевать мир", как у некоторых:)

Как у Гуидо One Россума?

>А должны? Это и хорошо, что непохожи: у Erlang VM - это не говённая JVM. И синтакис может быть любой - это изначально заложено.

>Led (*) (23.11.2008 1:04:09)

Может быть тогда уж следующим Mono или .NET? Вот уж что мертворожденным сразу вышло так это .NET Framework

>Пока - не являются. Но на серверах Java (по крайней мере, в моей практике) в новых проектах вытесняется уже (причём, с треском пролетает ещё на этапе выбора инструмента).

Ну и чем вытесняется? Неужели Mono на Windows Server 2008? OMG! Нет, Эрлангом на Vista 7?

>не стать скале следующией java в первую очередь из-за сложности. Вот groovy вторым языком может стать, это да.

Да не обязательно весь набор из Скалы всем использовать? Вот ты часто volatile в прогах на Java используешь? А создатели библиотек возможно используют. Так и Scala, будет больше возможностей создавать удобные библиотеки, которые смогут даже обезьянки с Java в свои быдлопрограммы вставлять, кто-то будет использовать наиболее очевидную часть Scala, кто-то продвинется дальше, в зависимости от ума и образования

>Зх, не получилось толкового флейма... /me ушел спать голодным.

Щас подкину дровишек. Вот и Scala уже рекомендуют забыть http://stephan.reposita.org/archives/2008/01/09/qi4j-the-next-java-forget-scala/ , на замену Java идет фреймворк Qi4J http://www.qi4j.org/introduction.html

> Чтобы развить в себе эти качества нужны годы обучения как гуманитарным так и естественным наукам. (sv75, или это опять overkill?)

Про "гуманитарным" не уверен. Филология в полезной программисту области либо может считаться либо естественной наукой, либо философией (языка). Хмм, Или я сильно утрирую?

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

Это к психологу.

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

отступ в восемь пробелов не заметен? O_o

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

это что, мне для гвиды за свои деньги психоаналитика нанимать?!

> это что, мне для гвиды за свои деньги психоаналитика нанимать?!

Не угадали.

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

> отступ в восемь пробелов не заметен? O_o

Наблюдения показывают, что спорить тут бесполезно :( Очевидно, что есть люди, которые испытывают разного рода затруднения от того, что в python пробелы являются частью синтаксиса. Им то редактор не настроить, то бедняжки копипастят не читая того что собственно они копипастят, то ещё какая-нибудь беда с ними приключается... Прочитайте первоначальную цитату. У меня нет оснований думать что её автор пишет программы более внимательно. Невозможно определить что это - родовая травма или безответственность, но острые ножи, C (опасные указатели!) и python (ужасные пробелы!) в таких случаях противопоказаны...

> Про "гуманитарным" не уверен. Филология в полезной программисту области либо может считаться либо естественной наукой, либо философией (языка). Хмм, Или я сильно утрирую?

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

> 5) запустить получившуюся программу под valgrind, чтобы померять
> выделение оперативной памяти.

Здесь (room) лучше valgrind'а подойдёт.

$ cat mem.lisp
(declaim (optimize (speed 3) (space 0) (debug 0) (safety 0)))

(format t "~%-- start --~%")
(room)

(defvar data nil)
(defvar deviation nil)
(defvar average 0)
(defconstant sz #xa00000)

(setq data nil)
(setq *print-array* nil)
(setq data (make-array sz :element-type '(signed-byte 8)))
(setq deviation (make-array sz :element-type '(signed-byte 8) :initial-element 0))

(with-open-file (s "/dev/urandom" :element-type '(signed-byte 8))
  (read-sequence data s :end sz))

(setq average 0)
(dotimes (i sz)
  (incf average (aref data i)))

(setq average (/ average sz))

(dotimes (i sz)
  (setf (aref deviation i) (floor (abs (- average (aref data i))))))

(with-open-file (s "deviation"
		   :direction :output
		   :if-exists :overwrite
		   :if-does-not-exist :create
		   :element-type '(signed-byte 8))
  (write-sequence deviation s))

(format t "~%-- end --~%")
(room)

(format t "~%-- after gc --~%")
(gc :full t)
(room)

$ sbcl --eval '(load "mem.lisp")'
This is SBCL 1.0.22.17, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.

-- start --
Dynamic space usage is:   47,769,424 bytes.
Read-only space usage is:      6,288 bytes.
Static space usage is:         3,872 bytes.
Control stack usage is:        2,864 bytes.
Binding stack usage is:          368 bytes.
Control and binding stack usage is for the current thread only.
Garbage collection is currently enabled.

Breakdown for dynamic space:
  12,826,736 bytes for    11,651 code objects.
  12,588,240 bytes for   786,765 cons objects.
   7,606,592 bytes for    88,254 instance objects.
   6,504,064 bytes for    59,315 simple-vector objects.
   8,275,312 bytes for   163,875 other objects.
  47,800,944 bytes for 1,109,860 dynamic objects (space total.)

-- end --
Dynamic space usage is:   66,843,792 bytes.
Read-only space usage is:      6,288 bytes.
Static space usage is:         3,872 bytes.
Control stack usage is:        2,864 bytes.
Binding stack usage is:          368 bytes.
Control and binding stack usage is for the current thread only.
Garbage collection is currently enabled.

Breakdown for dynamic space:
  20,971,568 bytes for         3 simple-array-signed-byte-8 objects.
  12,822,288 bytes for    11,635 code objects.
   9,014,816 bytes for   563,426 cons objects.
   8,644,320 bytes for   116,702 instance objects.
   6,462,000 bytes for    58,657 simple-vector objects.
  11,235,200 bytes for   278,244 other objects.
  69,150,192 bytes for 1,028,667 dynamic objects (space total.)

-- after gc --
Dynamic space usage is:   63,712,880 bytes.
Read-only space usage is:      6,288 bytes.
Static space usage is:         3,872 bytes.
Control stack usage is:        2,864 bytes.
Binding stack usage is:          368 bytes.
Control and binding stack usage is for the current thread only.
Garbage collection is currently enabled.

Breakdown for dynamic space:
  20,971,568 bytes for         3 simple-array-signed-byte-8 objects.
  12,820,464 bytes for    11,632 code objects.
   8,938,368 bytes for   558,648 cons objects.
   8,131,600 bytes for   106,351 instance objects.
   6,389,760 bytes for    57,920 simple-vector objects.
   8,549,408 bytes for   189,867 other objects.
  65,801,168 bytes for   924,421 dynamic objects (space total.)
* 

Ну и теперь напишите просто цифру :)

20,971,568 bytes for 3 simple-array-signed-byte-8 objects.

+ ~4мб на временные cons'ы, который gc потом порезал.

Ваш "практический опыт", извините, ничего не стоит. Вы даже не подмастерье, а так, погулять вышли. Практический опыт - это в Google, в Microsoft, в IBM, в Sun. А там математика ой как нужна.

Это четыре разных человека!

> Ваш "практический опыт", извините, ничего не стоит. Вы даже не подмастерье, а так, погулять вышли. Практический опыт - это в Google, в Microsoft, в IBM, в Sun. А там математика ой как нужна.

Пруфлинк?

> БОльшая часть задач энтерпрайз левела по математическому содержанию примитивны.

Много ты знаешь, детка, про интерпрайз. Логистика - суровая комбинаторика. Финансовая математика - это и мат. стат, и дифуры, и много чего ещё страшненького. Огромное количество задач ложится в constraint programming, тоже не без страшенной математики.

Хотя, конечно же, дикарям в Индии и прочие России аутсорсят всякую фигню, типа мордочек к примитивным базам данных. Вот дикари и думают, что интерпрайз именно так и выглядит.

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

> Посмотри хотя бы на те вопросы, которые задают на собеседовании в гугле.

Т.е. пруфлинка нет. Я так и думал.

Думать ты не научился пока ещё, деточка (и гуглить тоже).

http://careers.cse.sc.edu/googleinterview

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

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

> http://careers.cse.sc.edu/googleinterview

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

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

>Язык описания данных для игр по-моему сложно отделить от скриптинга. А DSL там же есть, потому что есть domain.

Domain есть везде. А Lua и Python это не DSL. По простому DSL - это например SQL с точки зрения того что domain - реляционная алгебра.

shell таки тоже DSL, узкоспециализированная запускалка процессов.

> А Lua и Python это не DSL.

А я это утверждал? Рассматривался вопрос замены DSL'а на каждый чих динамическим языком. Примерно GPSS vs SimPy.

>shell таки тоже DSL, узкоспециализированная запускалка процессов.

Нет. Там нет ничего в языке что это поддерживает.

Ну почти. Обратные кавычки похожи на DSLный элемент. Но этого боюсь мало.

Обратные кавычки, if, подстановка wild cards, простой синтаксис запуска приложения, простой синтаксис для создания pipeline - чем не DSL?

Аналог ls | grep ... | sort ... | sed на языке общего назначения выглядел бы весьма кошмарной кашей из кучки popen-ов.

Соглашусь что есть пара элементов - но все же в качестве DSL он бы мог быть покруче - скорее это некая подвижку в ту сторону.

Ну так что, какие результаты, выводы?

Так я и думал ;)

1. немайнтабельно. Как там с выравниванием, изменением структуры поинта и т.д?

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

Да и полезность сомнительная ;) Так что костыли, костыли...

> Вот и Scala уже рекомендуют забыть http://stephan.reposita.org/archives/2008/01/09/qi4j-the-next-java-forget-scala/, на замену Java идет фреймворк Qi4J

Я Ъ, Qi - тот самый Qi, который поверх CL? Тогда не будет он ничем "следующим", ибо Лисп проклят от рождения %)

> Я Ъ, Qi - тот самый Qi, который поверх CL? Тогда не будет он ничем "следующим", ибо Лисп проклят от рождения %)

Сходил по ссылке, Qi4J - это не Qi, который поверх CL. Это уёжище какое-то :)

> Qi4J - это не Qi, который поверх CL. Это уёжище какое-то :)

Тоже сходил по ссылке и ниасилил этот ужоснах. Пусть уж лучше Scala будет следующей Явой %)

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

Ты похоже даже по диагонали не прочел код. Напиши такое же без юнионов на с++. Жду.

> Аналог ls | grep ... | sort ... | sed на языке общего назначения выглядел бы весьма кошмарной кашей из кучки popen-ов.

Гы-гы-гы.

На с++ этот аналог *в худшем случае* выглядел бы так:

string result = run("ls") | "grep ..." | "sort ..." | "sed ..." ;

> 1. немайнтабельно. Как там с выравниванием, изменением структуры поинта и т.д?

Что касается поддержки -- то имхо проще всего такое поддерживать руками, т.к. point меняется не часто.

Но еще раз повторю: прочти код внимательно и попробуй сделать такое же без юниона.

Ещё раз есть методы!

class Rect {
  Point f_p1, f_p2;
public:
  Point & p1();
  Point & p2();
  int & left() {return f_p1.x;}
 ....
}

PROFIT!!

На питоне проперти есть, так что покрасивее будет.

>class Rect {
> Point f_p1, f_p2;
>public:
> Point & p1();
> Point & p2();
> int & left() {return f_p1.x;}
> ....
>}


Превед ничего полезного не делающий boilerplate-код.

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

> Ещё раз есть методы!

Согласен, мейнтенить такое проще, хотя читать -- думаю сложнее.

А теперь, методичный ты наш, перепиши свой пример на случай, если
 Point имеет битовые поля. А я посмотрю на твои прокси-объекты  :-)

struct Point {int x:4; int y:4; int other:24; }
/* вместо other куча других битовых полей, к которым не нужно дублировать доступ */

struct Rect { union {
    struct {
        Point top_left;
        Point bottom_right;
    } point;
    struct {
        int left:4;
        int top:4;
        int _unused0:24;
        int right:4;
        int bottom:4;
        int _unused1:24;
    } coord;
};};

Как только вы привидетё мне _реально нужный пример_. И не раньше ;) А так - опять же методы гет/сет никто не отменял ;) И опять же, в языке поддерживающем проперти всё решается легко и правильно ;)

>зато не надо париться выравниванием,

Ты всеж прочитай вот это. http://en.wikipedia.org/wiki/Tagged_union

> На питоне проперти есть, так что покрасивее будет.

В плюсах пропертей очень не хватает, вроде (могу соврать) собрались их ввести в С++0х.

> А так - опять же методы гет/сет никто не отменял ;)

Либо этот неэститчиный и многословный гет/сет, либо трах с прокси объектом, либо... может все-таки юнион?