Как писать программы.

[thesz]

Комментарий одного... специалиста. Цитата:I don't know how anyone wrote software back in the days before dual high resolution screens. It's a time consuming chore, requiring a number of dead tree tomes open on one's desk and constant shuffling about.
Собственно, программы писались путем абстрагирования, уменьшения сложности на каждом уровне

Comments

[jakobz]

Два моника это безусловно клево. Но и с одним вполне можно жить. Думаю тут проблема больше в не самом удобном способе переключения между окошками - действительно часто теряешься и забываешь что хотел сделать в этот момент. Не сильно удобный таскбар в винде + маленькие, дебильные, и незапоминающиеся иконки. Хоть бы цветом чтоли выделяли. Да и вообще народ как-то невнимательно к дизайну GUI относится, забывают насколько это важно.

[thesz]

В Макоси по AltTab переключаешься не между окошками, а между приложениями. Это удобней на порядки, буквально.

Внутри приложения можно перебирать его окошки отдельными кнопками - Alt~ и ShiftAlt~.

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

[antilamer]

Пока у меня был один монитор, я не понимал, насколько круто иметь два; теперь за уши не оттянешь :) Хотя не сказал бы, что это изменило мою жизнь.

[thesz]

23", 16x9 - моя мечта. (есть такой iMac)

Но и 17" - тоже неплохо. ;)

Все равно, дело не в мониторах, дело в умении уменьшать сложность.

[levgem]

Ты какие-то плохие библиотеки используешь. Вот, например, ActiveRecord: хочешь простого - будет просто. Хочешь посложнее - делай посложнее.

[thesz]

Ну, исключения встречаются везде. И я не идеален, само собой. ;)

[levgem]

Да не, в целом я тебя понимаю. Я похожего дерьма на C++ нагляделся.

[vshabanov]

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

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

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

[thesz]

С ОО библиотеками я поступаю примерно так же. ;)

И полностью поддерживаю "чем меньше лишней визуальной информации перед глазами, тем легче сосредоточиться." ;)

Насчет использования ОО в окамле.

[thesz]

Дык, эта. Полиморфизм же есть и функции высшего порядка. Зачем что-то еще? ;)

Re: Насчет использования ОО в окамле.

[vshabanov]

Точно. В этом некоторые товарищи (один из которых потом подрабатывал написанием спецификации для Java :) убедились достаточно давно.

отрывок отсюда:
The Scheme programming language was born from an attempt in 1975 to explicate object-oriented programming in terms that Gerry Sussman and I could understand. In particular, we wanted to restate Carl Hewitt's theory of actors in words of one syllable, so to speak. One of the conclusions that we reached was that "object" need not be a primitive notion in a programming language; one can build objects and their behavior from little more than assignable value cells and good old lambda expressions. Moreover, most of the objects in Hewitt's theory were stateless and unchanging once created; for those, lambda expressions alone were sufficient.

[thesz]

БК-0010 ;)

[thesz]

Ее поставили к нам в техникум, и оно работало.

Focal почти не мешал. ;)