(no subject)

[beldmit]

Собственно, возвращаясь к посту про настоящего программиста. Там в комментах cmike высказал мнение, что Java - это такой нишевый язык.

Я задумался, и понял, что ниши для Java я не представляю. Возможно, сейчас не представляю - потому что уже есть C#.

Посему вопрос: какие задачи могут быть удачнее, чем на каком-либо другом языке, решены на чем-нибудь из списка: Java, Smalltalk, Haskell, Erlang? Меня устроит, если будет какой-то другой язык близкого класса, который это позволит сделать (кроме Java - там я хотел бы видеть четкие преимущества).

Желательно - чтобы с этими задачами было реально столкнуться на не сильно извилистом пути программиста (то есть если, чтобы к такой задаче подступиться, надо 15 лет учиться на микроэлектроника, то пример не канает).

Comments

[beldmit.livejournal.com]

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

[dimas.livejournal.com]

Ой, да при чем тут среда?

Язык (точнее его возможности) достаточно влияет на возможности ... Как компактности, так и читабельности/поддерживаемости кода ... Вспомни первые MFC или OWL ...

Как раз обычно больше говён я видел от "нарисованного в дизайнере", чем закодированного ... А уж как это выглядело, когда надо было какой-то кусок заюзать в еще одном месте ... А с той же Qt-кой я просто влегкую делал класс-биг-виджет и просто вставлял его в другом месте ...

Кстати, вот думаю, не поразвлекаться что ли на PyQt ...

[dph.livejournal.com]

О, а PyQt есть для Jython? А то это может быть забавный вариант :)

[dimas.livejournal.com]

В смысле для Питона? Ага, есть. И по мне - ну очень красиво, прям как С++ код :) На Хабре был уже ряд статей с примерами ...

Для явы, кстати, вроде тоже вариант есть, только не помню, платный или как, надо смотреть на trolltech.com.

[dimas.livejournal.com]

А, я тормоз, нашел что такое Jython ^) А смысл в таком изврате? Есть же Jambi?

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

[dph.livejournal.com]

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

А про Jambi я что-то ничего реального не нашел. Похоже, никто это не использует.

[vitus_wagner]

Проблему гуерисования ни в коем случае нельзя решать средой.
Её надо решать исключительно мозгами. Созданием адекватного этой проблеме понятийного аппарата и поддержкой его в языке. Все проблемы GUI на мейнстримовых языках происходят именно потому что у ПРОГРАММИСТА нет понятийного аппарата чтобы думать про GUI. Поэтому все GUI - непродуманные. Вот у смоллтолкеров кое-какие наметки на эту тему есть.

Думать же на уровне образов человек в принципе не в состоянии. Не заточены у него мозги для этого. Думать можно только "в терминах".

[beldmit.livejournal.com]

Витус, тут как с HTML. Можно писать в vim, но потом все равно надо в браузере глянуть.

[vitus_wagner]

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

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


я уж не говорю, про проблемы интернационализации, которые нафиг на корню убивают идею "Рисования GUI" - либо GUI будет "резиновым", и тогда его не рисовать надо, либо там не уместятся переводы надписей на финский или суахили, либо этот GUI не уместится на экран EeePC 700.

[beldmit.livejournal.com]

Не понял. То есть совсем. Как можно не смотреть на результат того, что получилось, если этот результат предназначен для восприятия глазами?

[vitus_wagner]

Э, дарагой, ты когда генерацию ключа ГОСТ Р 34.10 писал, ты все 2²⁵⁶ возможных значений проверял?

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

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

[beldmit.livejournal.com]

Тестирование бывает систематическое (полный перебор - как вариант), аналитическое (выявляем особые точки) и слепое/случайное. И каждое из них может найти ошибки.

[cmike.livejournal.com]

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

[vitus_wagner]

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

Дальше все. Для того чтобы перейти на следующий уровень абстракции все равно нужны слова.

[cmike.livejournal.com]

Уровень абстракции должен быть не высоким, а адекватным. И в случае UI скорее довольно низким.

Я недавно купил флешку, теперь пользуюсь и ругаюсь – слишком много ошибок в интерфейсе. Показывает название трека, но оно обычно не влезает и тогда показывается бегущей строкой – однако ползёт эта строка очень медленно и задолго до того, как доползёт до конца экран гаснет (зелень!). В процессе проигрывания не показывает число проигранных секунд, только бегунок. При проигровании песни показывает узорчики вместо названия трека/бегунка (workarond – залочить и разлочить плейер).

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

Я у тебя и другие ошибки вижу, но это имеет большее отношение к теме обсуждения.

Апичатка

[cmike.livejournal.com]

Я недавно купил флешку
Имеется в виду mp3-плейер, конечно.

[vitus_wagner]

Как раз работа на высоком уровне, мышление в терминах user experience, а не терминах "отдельно зелень, отдельно прокрутка" и поможет от подобных плюх избавиться.

[cmike.livejournal.com]

Да, конечно, но тут сталкиваются понятия user experience и средства реализации, какими они бы не были. А это неизбежно означает, что придётся лезть в детали. Модели в этих областях могут дать только первое приближение и единственный способ сохранить девственную простоту – постулировать, что "наша система и есть оптимальный user experience".

Пользовательский опыт и средства разработки неизбежно вступают в противоречие. Пример навскидку. Файл – хорошая абстракция и рано или поздно файл на удалённой машине тоже считается файлом. И сразу же оказывается, что пользователю нужно работать с такими файлами по-другому: показывать бегунок, делать докачку и т.д.