О настоящих программистах

О настоящих программистах

http://petr-panteleyev.livejou... 

==
Оказывается, в SWT принято делать публичные поля классов и через них влиять на поведение объекта.

закоренелый настоящий программист может написать фортрановскую программу на любом языке
==

мОлодеж, до изучения классического трактата, просьба не беспокоиться

Re: О настоящих программистах



Оказывается, в SWT принято делать публичные поля классов и через них
влиять на поведение объекта.


http://en.wikipedia.org/wiki/C... 


Re: О настоящих программистах

Alex Mizrahi <udodenko@users.sourceforge.net> wrote:



Оказывается, в SWT принято делать публичные поля классов и через них
влиять на поведение объекта.


http://en.wikipedia.org/wiki/C... 



что ты сказать-то хочешь?

Re: О настоящих программистах

"Slawa Olhovchenkov" <slw@zxy.spb.ru> wrote in message
news:fs0618$cr4$1@news.demos.su...

Alex Mizrahi <udodenko@users.sourceforge.net> wrote:



Оказывается, в SWT принято делать публичные поля классов и через них
влиять на поведение объекта.


http://en.wikipedia.org/wiki/C... 



что ты сказать-то хочешь?


очевидно,

From time to time, the term "cargo cult" is invoked as an English language
idiom, to mean any group of people who imitate the superficial exterior of a
process or system without having any understanding of the underlying
substance.

--
All mockery of Jews and their one God
shall be kept to an appropriate minimum.


Re: О настоящих программистах

Constantine Vulakh <z1@vulakh.us> wrote:

"Slawa Olhovchenkov" <slw@zxy.spb.ru> wrote in message
news:fs0618$cr4$1@news.demos.su...

Alex Mizrahi <udodenko@users.sourceforge.net> wrote:



Оказывается, в SWT принято делать публичные поля классов и через них
влиять на поведение объекта.


http://en.wikipedia.org/wiki/C... 



что ты сказать-то хочешь?


очевидно,

From time to time, the term "cargo cult" is invoked as an English language
idiom, to mean any group of people who imitate the superficial exterior of a
process or system without having any understanding of the underlying
substance.



что такое "cargo cult" я знаю, что сказать-то хотел?

Re: О настоящих программистах




Оказывается, в SWT принято делать публичные поля классов и через них
влиять на поведение объекта.



??>> http://en.wikipedia.org/wiki/C... 

что ты сказать-то хочешь?


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

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

таким образом, это точно подходит под определение cargo cult: Cargo cult
programming is a style of computer programming that is characterized by the
ritual inclusion of code or program structures that serve no real purpose.
[1]

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


закоренелый настоящий программист может написать фортрановскую

программу на любом языке

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

[1]: http://en.wikipedia.org/wiki/C... 


Re: О настоящих программистах

"Alex Mizrahi" <udodenko@users.sourceforge.net> wrote in message
news:fs0cjf$2caq$1@ddt.demos.su...


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


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

1. Если ты не имеешь контроль над всеми клиентами, то сконвертировать
поле в property будет попросту невозможно.

2. Даже если ты имеешь контроль над всеми клиентами, поле нельзя
засунуть в интерфейс и его нельзя замочить (google: mocks). Поэтому,
класс с голым полем (точнее, его пользователей) будет трудно тестировать.

3. Доступ к полю невозможно засунуть в интерфейс, соответственно
контракт класса неотделим от собственно класса. Это мешает в ряде
случаев, например если мы хотим использовать штучки типа
decorator pattern, или если нужен remoting.

Впрочем, если писать маленькую программку узкого назначения,
это можно просто игнорировать, как и многие другие принципы,
предназначенные для больших программ. Можно вообще все состояние
сложить в одну глобальную структуру и сделать все методы static.
Получится С (ну или Фортран). Оно будет работать. В небольшом
масштабе. Люди так 30 лет писали, и ничего.

Иван

Re: О настоящих программистах

Alex Mizrahi <udodenko@users.sourceforge.net> wrote:




Оказывается, в SWT принято делать публичные поля классов и через них
влиять на поведение объекта.



??>> http://en.wikipedia.org/wiki/C... 

что ты сказать-то хочешь?


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

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


это можно долго спорить про ООП. и про то какое оно должно быть, и что оно есть и т.п.

я вообще не люблю ООП (по крайне мере в типичном C++ стиле), а жабу вообще не трогаю



таким образом, это точно подходит под определение cargo cult: Cargo cult
programming is a style of computer programming that is characterized by the
ritual inclusion of code or program structures that serve no real purpose.
[1]

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


закоренелый настоящий программист может написать фортрановскую

программу на любом языке

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



мнэ, ты точно помнишь этот опус про настоящих програмистов?
потому как иначе непонятно почему ты не уловил на какое именно фортрановское
действие тут ссылка (как мне кажется).


[1]: http://en.wikipedia.org/wiki/C... 



Re: О настоящих программистах


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



1. Если ты не имеешь контроль над всеми клиентами, то сконвертировать
поле в property будет попросту невозможно.



2. Даже если ты имеешь контроль над всеми клиентами, поле нельзя
засунуть в интерфейс и его нельзя замочить (google: mocks). Поэтому,
класс с голым полем (точнее, его пользователей) будет трудно
тестировать.



3. Доступ к полю невозможно засунуть в интерфейс, соответственно
контракт класса неотделим от собственно класса. Это мешает в ряде
случаев, например если мы хотим использовать штучки типа
decorator pattern, или если нужен remoting.


всё это не причины, а недостатки языка Java. если люди пользуются
ацессорами, можно было сделать прозрачное представление полей в виде
пропертей как в Delphi или C#. но не сделали. почему?

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


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


принцип дефективности?


Можно вообще все состояние
сложить в одну глобальную структуру и сделать все методы static.


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

p.s. я сейчас пользуюсь языком программирования, в котором: 1) ацессоры
пишутся автоматически; 2) они реально удобнее чем прямое обращение к полям;
3) но, тем не менее, язык позволяет в случае необходимости переопределить
всё и без ацессоров


Re: О настоящих программистах


мнэ, ты точно помнишь этот опус про настоящих програмистов?


этот: http://www.pbm.com/~lindahl/real.programmers.html
?


потому как иначе непонятно почему ты не уловил на какое именно
фортрановское действие тут ссылка (как мне кажется).


конкретное действие?
я думюл речь о том, что настоящие программисты забивают на ограничения и
принципы вроде "структурного программирования" -- Real Programmers aren't
afraid to use GOTOs.
только тут real programmers забили на ООП и не боятся использовать поля
напрямую.

или там есть что-то более подходящее?


Re: О настоящих программистах

Alex Mizrahi <udodenko@users.sourceforge.net> wrote:


мнэ, ты точно помнишь этот опус про настоящих програмистов?


этот: http://www.pbm.com/~lindahl/real.programmers.html
?



ага



потому как иначе непонятно почему ты не уловил на какое именно
фортрановское действие тут ссылка (как мне кажется).


конкретное действие?
я думюл речь о том, что настоящие программисты забивают на ограничения и
принципы вроде "структурного программирования" -- Real Programmers aren't
afraid to use GOTOs.
только тут real programmers забили на ООП и не боятся использовать поля
напрямую.

или там есть что-то более подходящее?




мне показалось что про изменение константы 4 в фортране.

или это было не оттуда а из теста?

Re: О настоящих программистах

Ivan Krivyakov wrote:


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

1. Если ты не имеешь контроль над всеми клиентами, то сконвертировать
поле в property будет попросту невозможно.

2. Даже если ты имеешь контроль над всеми клиентами, поле нельзя
засунуть в интерфейс и его нельзя замочить (google: mocks). Поэтому,
класс с голым полем (точнее, его пользователей) будет трудно тестировать.

3. Доступ к полю невозможно засунуть в интерфейс, соответственно
контракт класса неотделим от собственно класса. Это мешает в ряде
случаев, например если мы хотим использовать штучки типа
decorator pattern, или если нужен remoting.


+ concurrency issues.

--

Sol Windborn

Re: О настоящих программистах

Alex Mizrahi wrote:



Можно вообще все состояние
сложить в одну глобальную структуру и сделать все методы static.


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

p.s. я сейчас пользуюсь языком программирования, в котором: 1) ацессоры
пишутся автоматически; 2) они реально удобнее чем прямое обращение к полям;
3) но, тем не менее, язык позволяет в случае необходимости переопределить
всё и без ацессоров


По результатам использования Питона (где getters не приняты) и Джава, лично меня
Питон не убедил, совсем.


Папуасам читать Martin Fowler.

--

Sol Windborn

Re: О настоящих программистах


Папуасам читать Martin Fowler.


Пробовал. Графоман он. Одна-две умные мысли на 100 страниц каши.

Re: О настоящих программистах


"Alex Mizrahi" <udodenko@users.sourceforge.net> wrote in message
news:fs0cjf$2caq$1@ddt.demos.su...




Оказывается, в SWT принято делать публичные поля классов и через



них



влиять на поведение объекта.



??>> http://en.wikipedia.org/wiki/C... 

что ты сказать-то хочешь?


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


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


Re: О настоящих программистах

Aleksandr A wrote:



Папуасам читать Martin Fowler.


Пробовал. Графоман он. Одна-две умные мысли на 100 страниц каши.


А на мой взгляд он на редкость светлая голова.

--

Sol Windborn

Re: О настоящих программистах


"Sol Windborn" <root@earth.solarsystem.milkyway.universe> wrote in message
news:fs0mds$mjt$3@ddt.demos.su...

Ivan Krivyakov wrote:


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

1. Если ты не имеешь контроль над всеми клиентами, то сконвертировать
поле в property будет попросту невозможно.

2. Даже если ты имеешь контроль над всеми клиентами, поле нельзя
засунуть в интерфейс и его нельзя замочить (google: mocks). Поэтому,
класс с голым полем (точнее, его пользователей) будет трудно тестировать.

3. Доступ к полю невозможно засунуть в интерфейс, соответственно
контракт класса неотделим от собственно класса. Это мешает в ряде
случаев, например если мы хотим использовать штучки типа
decorator pattern, или если нужен remoting.


+ concurrency issues.


Вот-вот. Встретился С++ класс, в котором некоторые обращения к собственным
private полям осуществлялись через private (!) функции доступа. Сначала
подумал, что overkill. Потом увидел попытки синхронизации threads. Решил,
что хрен с ним, но осадок почему-то все равно остался...


Re: О настоящих программистах

Рынский, Дениска (старшой) wrote:

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


Это от полного непонимания замешанных тут принципов. А также от непонимания
того, что уровни доступа не делятся на просто "можно менять"/"нельзя менять", а
содержат еще несколько градаций. Вы просто о них не знаете.

Разница между голым полем и парой методов доступа - огромна. Пара методов
доступа 1) скрывает факт физического существования поля и его физическое
расположение, 2) не позволяет выполнять lvalue доступ к полю со всем вытекающими.

А аргументы типа "это не поднадобится в 99% случаев" - смешны. Это все равно,
что вписывать в тело программы явное представление магической константы
3.1415... на основании того, что "оно ведь все равно меняться не будет".

--
Best regards,
Andrey Tarasevich

Re: О настоящих программистах

Slawa Olhovchenkov wrote:



что ты сказать-то хочешь?

Он видимо хотел сказать "зелен виноград",
что к коммерческому успеху Софта это
отношения не имеет. Почти.



--
Привет. Иаков
--- -- -- -- -- -- --- -- ---
ICQ № 24392270 / Skype:senatov

Re: О настоящих программистах

On Fri, 21 Mar 2008 14:21:52 -0700, Peter Vasyutin wrote:


Вот-вот. Встретился С++ класс, в котором
некоторые обращения к собственным private
полям осуществлялись через private (!)
функции доступа. Сначала


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


подумал, что overkill. Потом увидел попытки
синхронизации threads. Решил, что хрен с
ним, но осадок почему-то все равно
остался...


Какой еще осадок? Нормальная практика.

Re: О настоящих программистах

Alex Mizrahi wrote:


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


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

-СБ