Oberon space
General Category => Общий раздел => Тема начата: ilovb от Январь 05, 2013, 03:44:03 pm
-
[19:19:34] <egp> Ха. В Excelsior Китыч написал Оберон Систему на яве
[19:19:37] <egp> вот урл
[19:19:54] <egp> https://github.com/pjBooms/The-Nothing-System#readme
http://www.excelsior.ru/news/hack-day-one
-
Собрал. Выглядит это так:
http://hostingkartinok.com/show-image.php?id=62ebe4de83ee9b5357a96733e1680c0a
-
[19:19:34] <egp> Ха. В Excelsior Китыч написал Оберон Систему на яве
[19:19:37] <egp> вот урл
[19:19:54] <egp> https://github.com/pjBooms/The-Nothing-System#readme
http://www.excelsior.ru/news/hack-day-one
Да, подобное на яве делается элементарно. О чем я давно говорил (а народ упорно не верил) :-)
Впрочем, от browser hell'а это не спасет никак вообще.
У меня в плане оберонов есть не столь амбициозные возможно, но существенно более приземленные к современным реалиям планы :-) Если вдруг получится - обещаю небольшой вау-эффект.
-
Да, подобное на яве делается элементарно. О чем я давно говорил (а народ упорно не верил) :-)
В нише Явы у Оберона принципиальное преимущество в простоте для образования - и в перспективах, основанных на этом (кадры, непрерывность и проч.) Ну и то, что легко сделать и поддерживать свой инструментарий.
Но в плане эффективности для самого программирования все преимущества, действительно, не раскрываются, если программировать "в режиме Явы" - с активным мусорением в памяти и т.п.
Как раз интересные преимущества проявляются, когда пытаешься соответствовать уровню С/С++, но с безопасностью.
-
Да, подобное на яве делается элементарно. О чем я давно говорил (а народ упорно не верил) :-)
В нише Явы у Оберона принципиальное преимущество в простоте для образования - и в перспективах, основанных на этом (кадры, непрерывность и проч.) Ну и то, что легко сделать и поддерживать свой инструментарий.
Только эта легкость пока не достаточная для имеющихся ресурсов.
Но в плане эффективности для самого программирования все преимущества, действительно, не раскрываются, если программировать "в режиме Явы" - с активным мусорением в памяти и т.п.
Ну, ты же понимаешь, что там где "в режиме явы" в обероне будет мусор, то в самой яве мусора может и не быть вовсе :-) + если вдруг неизбежно возникает мусор, то для явы это не столь критично, ибо сборщик мусора там на порядок лучше (+ из несколько + они настраиваются под высокую реалтайм нагрузку).
Ну и до кучи ява безусловно выше уровнем чем любой из Оберонов (в том числе и КП), и безопасней (как минимум она больше проверяет на этапе компиляции, там где в Обероне будет рантайм еррор, там в джаве будет ошибка компиляции).
Я не говорю что Оберон и его производные не нужен, просто для подобной задачи (см. топик) ява действительно подходит пожалуй лучше. Позволяет на порядки быстрее написать нечто реально работающее.
Как раз интересные преимущества проявляются, когда пытаешься соответствовать уровню С/С++, но с безопасностью.
Ну, ты же знаешь, что я могу с этим поспорить :-) В С++ безопасности как минимум не меньше чем в Обероне. А учитывая тот факт, что С++ выше уровнем чем даже ява, вероятность ошибки в плюсах еще сильнее снижается. Но, безусловно, чтобы на С++ писать нужно С++ знать, иначе будет программирование в стиле Сей с классами (или даже без классов), и вот там то нет ни безопасности ни высокоуровневости.
-
Вроде работает даже: :)
http://hostingkartinok.com/show-image.php?id=61df91b86ba379e961e5e3e6f40d9f34
-
так в чём же смысл этого проекта?
-
http://devday.2gis.ru/report/22
Никита Липский:
Все новое — хорошо забытое старое, гласит известная поговорка.
В этом докладе, автор расскажет об одной хорошо забытой технологии, изобретенной в середине 80-х годов автором языка Паскаль Никлаусом Виртом, носящее название Оберон система, и объяснит почему за этой технологией будущее интернета, а также всей методологии разработки клиентского ПО.
Что мы имеем сегодня: web, mobile, desktop.
Преимущества и недостатки web.
Mobile и desktop — два мира, суть одна: отдельно устанавливающаяся программа с графическим пользовательским интерфейсом — GUI.
Преимущества и недостатки GUI.
Вывод. Нам нужна система совмещающая достоинства обоих подходов и лишенная их недостатков.
Оберон система — как альтернативная парадигма разработки ПО и как пример того, что все могло было быть иначе.
Базовые принципы Оберон системы. Все есть текст.
The Nothing System. Дальнейшее развитие идей Оберон системы. Зарождение нового интернета, основанного на новых технологических принципах, стирающих грань между web, mobile, desktop.
-
Впрочем, от browser hell'а это не спасет никак вообще.
Спасёт. Ты посмотри по devdays ссылке из ридми видео + презенташку. Там ясно выражена мысль заменить HTML+JS явой. То есть будет так (в соотв. с vision TNS): на какой урл ни ткни, тебе прилетает ява-код с урла.
-
Впрочем, от browser hell'а это не спасет никак вообще.
Спасёт. Ты посмотри по devdays ссылке из ридми видео + презенташку. Там ясно выражена мысль заменить HTML+JS явой. То есть будет так (в соотв. с vision TNS): на какой урл ни ткни, тебе прилетает ява-код с урла.
Есть ещё нюансы:
- потенциальные проблемы с безопасностью системы
- потенциальные проблемы с лицензиями ПО
-
Впрочем, от browser hell'а это не спасет никак вообще.
Спасёт. Ты посмотри по devdays ссылке из ридми видео + презенташку. Там ясно выражена мысль заменить HTML+JS явой. То есть будет так (в соотв. с vision TNS): на какой урл ни ткни, тебе прилетает ява-код с урла.
И-и? Ява-код то прилетит, только вот от "browser hell'a", повторяюсь, это никак не спасет. У разных товарищей разные jvm, они все живут в разных ОС на разном оборудовании. Если вокруг jvm тут требуется еще и обвязка из жаба-кода (собственно сама Nothing system), то сюда добавятся еще и разные реализации этой обвязки. И привет, приплыли.
Browser hell - это обычное следствие мультивендорности. И лучше бороться с browser hell'ом, чем с последствиями моновендорности.
-
Алексей -так в чем ее революционность... не как не могу понять.. можно кратко.. а то прочитав приведенное Валерием сообщение от создателя... появилось ощущение не полной адекватности оного...
-
Алексей -так в чем ее революционность... не как не могу понять.. можно кратко.. а то прочитав приведенное Валерием сообщение от создателя... появилось ощущение не полной адекватности оного...
Да нет там ничего супер-революционного. Разработчики из эксельсиора развлекаются. :-)
Взяли жабу, побыстрому, за 3 дня реализовали на ней подобие классического Оберона, точнее самую-самую базу. Текст как интерфейс, все дела. Динамическая компиляция модулей, команды и так далее. Ну и показывают как бы альтернативную реальность, где нет браузера, где вместо браузера, Оберон (среда а не язык) писанный на яве :-)
Ну, почему бы и нет? Можно будет даже посотрудничать с ними. Благо на яве пишется все быстро. Just for fun, так сказать :-)
-
Разница лишь в том, что Оберон сам себе ось и реализован с абсолютного нуля на голой машине ;)
И осмелюсь предположить что он значительно эффективнее жабы (даже с jazelee).
-
Разница лишь в том, что Оберон сам себе ось и реализован с абсолютного нуля на голой машине ;)
И осмелюсь предположить что он значительно эффективнее жабы (даже с jazelee).
Смотря что под эффективностью подразумевать. Если что - jazelee дает меньшую производительность на той же железяке нежели jit.
-
Если бы jit был везде доступен, то потребности в jazelee наверно не возникло бы ;)
-
Разница лишь в том, что Оберон сам себе ось и реализован с абсолютного нуля на голой машине ;)
И осмелюсь предположить что он значительно эффективнее жабы (даже с jazelee).
едва ли...ибо работа с железом делалась непрофессионалами... замеряли же производительность ББ кода и того же Шарпа.. ББ - был в жопе... вроде Сергей этим делом занимался
-
DIzer, а я и не про CP говорю, а про виртовский Оберон (в котором нет ООП)
-
Если бы jit был везде доступен, то потребности в jazelee наверно не возникло бы ;)
Ну, единственная причина почему jit может быть не доступен - если на железке ОЧЕНЬ мало ОЗУ (скажем мегабайта 4). Если же ОЗУ исчисляется десятками и тем более сотнями мегабайт, то все. Никакой jazalee.
На счет Оберон ОС - производительность её никто вроде бы не замерял. Да еще и на оригинальной железяке.
-
DIzer, а я и не про CP говорю, а про виртовский Оберон (в котором нет ООП)
ilovb, а я говорю про генерируемый компилятором (на котором эта гребанная система написана) машинный код, точнее на его качество
-
и это даже без учета специфики поддержки продвинутых возможностей современных устройств ввода вывода...
т.е. код ББ просерал даже на численных задачах.. а если учесть, что разработчики ББ занимались созданием Оберон ОС.. то картина вырисовывается прозрачная
-
Ну ладно, ладно... Это лишь мои предположения. Я только лишь хотел подчеркнуть, что этот жоберон совсем не оберон во всех возможных смыслах. Единственное что похоже - это интерфейс. Но и то весьма отдаленно. Контролы жабовские... Окошки... Да и вообще они сделали графический интерфейс, тогда как в оригинальном обероне кроме текста на экране реально больше ничего нет. Они этот момент видимо не вкурили.
В Обероне Вирта только тайловые фрэймы и текст. Графики нет совсем. Графические только вьюшки, но и они лишь элементы текстовых документов. Кнопки у фреймов (закрыть, развернуть и т.д.) - это тоже тупо текст.
А они сделали мини виндовс с панелькой справа....
-
Ну ладно, ладно... Это лишь мои предположения. Я только лишь хотел подчеркнуть, что этот жоберон совсем не оберон во всех возможных смыслах. Единственное что похоже - это интерфейс. Но и то весьма отдаленно. Контролы жабовские... Окошки... Да и вообще они сделали графический интерфейс, тогда как в оригинальном обероне кроме текста на экране реально больше ничего нет. Они этот момент видимо не вкурили.
В Обероне Вирта только тайловые фрэймы и текст. Графики нет совсем. Графические только вьюшки, но и они лишь элементы текстовых документов. Кнопки у фреймов (закрыть, развернуть и т.д.) - это тоже тупо текст.
А они сделали мини виндовс с панелькой справа....
Ну, они по мотивам сделали. Примерно также как тот же ББ. Почему бы и нет?
То есть взяли один аспект из Оберон ОС, и реализовали на современном инструментарии.
-
Вот оригинальный интерфейс:
https://www.youtube.com/watch?v=UTIJaKO0iqU
Придраться только к полосе прокрутки можно. Но назвать это графикой язык не поворачивается ;D
-
Я так понял что автор хотел оригинальную философию замутить:
Базовые принципы Оберон системы. Все есть текст.
http://devday.2gis.ru/report/22
А в BB тоже не текстовый интерфейс. У Вирта была идея заменить командную строку. Т.е. ему тупо в лом было каждый раз одни и те же команды набирать, и хотелось эффективнее использовать пространство экрана.
Об этом можно у самого Вирта почитать.
-
Еще поясню в чем суть:
Когда мы работаем с командной строкой, то у нас активна одна строка, а остальное лог.
Все это как бы в одном фрэйме на весь экран. Если мы хотим редактировать текст, то запускаем текстовый редактор и теряем на время командную строку и лог.
Есть очевидные недостатки такого подхода:
1. Все функции выполняет один фрэйм на весь экран. И соответственно пространство экрана используется неэффективно, т.к. реально мы только малую часть экрана используем в каждый момент времени.
2. Команды нужно набирать каждый раз заново.
3. Параметры у команд нужно набирать заново.
4. Ну и т.д. в том же духе.
Что сделал Вирт? Он взял и разделил экран на фрэймы.
Даже по умолчанию система запускается с 3 фрэймами, функции которых не сложно угадать. Это те самые функции которые раньше лежали на одном фрэйме (редактор, командная строка, лог)
Вот это настоящая философия Оберона по Вирту. Простое, дешевое концептуальное решение == мегатонный профит.
Вирт не делал окошек. Он просто порезал текстовый экран наиболее простым способом.
Все остальное фантазии народа, который недопонял Вирта (c) ;D
-
Что сделал Вирт? Он взял и разделил экран на фрэймы.
Даже по умолчанию система запускается с 3 фрэймами, функции которых не сложно угадать. Это те самые функции которые раньше лежали на одном фрэйме (редактор, командная строка, лог)
Вот это настоящая философия Оберона по Вирту. Простое, дешевое концептуальное решение == мегатонный профит.
Вирт не делал окошек. Он просто порезал текстовый экран наиболее простым способом.
Все остальное фантазии народа, который недопонял Вирта (c) ;D
Разве... я почему то думал, что вся фича в том, что комманды(как системного уровня так и управления приложениями) можно набирать В ЛЮБОМ месте доступном для печати...фишка крутая для ранних ОС - где такие вещи приходилось делать часто рядовому пользователю.. но с появлением Нортон командера.. эта необходимость резко снизилась
-
DIzer, а я и не про CP говорю, а про виртовский Оберон (в котором нет ООП)
Борис, а ООП - вообще не влияет на производительность...
Проблемы с оптимизациями и сборками мусора, но Оберон можно применять в таком режиме, когда минимизируется нагрузка на сборщик, тут-то и принципиальное преимущество, ибо Ява без оптимизирующего JIT, который способен все эти её срачи в памяти переделать на лету на стек, вообще не летает прилично :)
-
фишка крутая для ранних ОС - где такие вещи приходилось делать часто рядовому пользователю.. но с появлением Нортон командера.. эта необходимость резко снизилась
Необходимость повтора из раза в раза каких-то последовательностей действий, которые можно оформить в цепочки команд или даже в параметризуемую процедуру (если уметь программировать на школьном уровне) никогда никуда не денется. Проблема только в том, что пользователей до сих пор держат (и они сами держаться) на уровне "тупых юзеров". А профит для обоих сторон: и для пользователя, который автоматизирует своё мышкотыкательство, и для разработчика, которому не нужно часто вообще строить гуй... Как здесь: http://oberspace.dyndns.org/index.php/topic,407.msg12008.html#msg12008
-
Борис, а ООП - вообще не влияет на производительность...
Зависит от реализации... при использовании полиморфизма наследования обычно происходит поиск метода соответствующего фактическому обьекту, в таблице виртуальных методов - чего обычно нет при вызовах статических методов.
-
Необходимость повтора из раза в раза каких-то последовательностей действий, которые можно оформить в цепочки команд или даже в параметризуемую процедуру (если уметь программировать на школьном уровне) никогда никуда не денется. Проблема только в том, что пользователей до сих пор держат (и они сами держаться) на уровне "тупых юзеров". А профит для обоих сторон: и для пользователя, который автоматизирует своё мышкотыкательство, и для разработчика, которому не нужно часто вообще строить гуй... Как здесь: http://oberspace.dyndns.org/index.php/topic,407.msg12008.html#msg12008
Проблема в том, что вы (последователи этой доктрины) - никак не можете осознать что рядовой пользователь - НЕ ХОЧЕТ знать этого, как блондинка не хочет знать устройство карбюратора порше, на котором она ежедневно ездит на шопинг, более того , она не хочет даже открывать крышку капота... но она готова (точнее ее папик) платить другим людям за это - каждому свое....
-
далее... в своем "добродетельном" порыве исправить это, вы фактически срете в то место, которое вас кормит... ну разве не уроды ВЫ
-
Борис, а ООП - вообще не влияет на производительность...
Зависит от реализации... при использовании полиморфизма наследования обычно происходит поиск метода соответствующего фактическому обьекту, в таблице виртуальных методов - чего обычно нет при вызовах статических методов.
Общеизвестный факт.
И при программировании "без ООП в языке", как в Обероне, будут ручные виртуальные таблицы указателей на процедуры.
Также и на С многие библиотеки в около-объектном стиле написаны.
А без полиморфизма вообще путную архитектуру не построишь.
-
Борис, а ООП - вообще не влияет на производительность...
Зависит от реализации... при использовании полиморфизма наследования обычно происходит поиск метода соответствующего фактическому обьекту, в таблице виртуальных методов - чего обычно нет при вызовах статических методов.
Общеизвестный факт.
И при программировании "без ООП в языке", как в Обероне, будут ручные виртуальные таблицы указателей на процедуры.
Также и на С многие библиотеки в около-объектном стиле написаны.
А без полиморфизма вообще путную архитектуру не построишь.
разница в том, что в первом случае КАЖДОЕ использование такой структуры ОСОЗНАННО и МАКСИМАЛЬНО ЭКОНОМИЧНО..., во втором случае оно скрыто под капотом и используется даже в том случае когда без него можно обойтись... не будете же вы отрицать что программы написанные на ассемблере зачастую эфектвнее чем те что получаются при компиляции с ЯВУ - причина приблизительно та же..
-
Проблема в том, что вы (последователи этой доктрины) - никак не можете осознать что рядовой пользователь - НЕ ХОЧЕТ знать этого, как блондинка не хочет знать устройство карбюратора порше, на котором она ежедневно ездит на шопинг, более того , она не хочет даже открывать крышку капота... но она готова (точнее ее папик) платить другим людям за это - каждому свое....
Пусть юзер (и его блондинка) не знает устройство того, на чём он каждый день "сёрфит по инету", но когда он осваивает ПО, в котором будет работать профессионально каждый день, то право и долг разработчика такого ПО стимулировать пользователя освоить именно такой стиль, в котором ему самому, юзеру, будет потом удобнее всего годами работать... Я видал и тёток в банках (не-программисток), которые любили ФАР, потому что им показали преимущества, и других, казалось бы, "тупых юзеров", которым кто-то что-то сумел правильно показать - и дело пошло...
А как можно, работая в образовании, не понимать, что нужно не подстраиваться под текущую ситуацию, а пытаться задавать нужный вектор?
А Вы предлагаете тупо всё принимать, как есть, и быть соучастником идиотизма.
-
"Ершовский" принцип - базовая компетентность в сфере программирования нужна всем, чтобы осознанно действовать в новой "цифровой реальности". Но в текущих условиях любые базовые знания в области алг-и и прогр-я неспециалисту просто некуда приложить. Что-то реальное (хоть для ПК, хоть для мобильников, хоть для встроенки) совершенно оторвано, недосягаемо для тех знаний, которые неспециалист может получить из общих курсов. Т.е. школьная или вузовская непрофильная информатика так и остаётся непрактичным знанием, как и большая часть математики.
А могло бы быть всё по-другому.
Представим пространство цифровых устройств, сделанное по-другому. Допускающее взаимодействие посредством программирования - простого, на нормальном школьном уровне. "Как в Блэкбоксе".
Попробуйте "подумать эту мысль".
-
далее... в своем "добродетельном" порыве исправить это, вы фактически срете в то место, которое вас кормит... ну разве не уроды ВЫ
Коллега, я недавно поставил и ваш диагноз:
http://oberspace.dyndns.org/index.php/topic,308.msg12707.html#msg12707
Интересно, насколько с ним согласны Вы сами.
-
А как можно, работая в образовании, не понимать, что нужно не подстраиваться под текущую ситуацию, а пытаться задавать нужный вектор?
А Вы предлагаете тупо всё принимать, как есть, и быть соучастником идиотизма.
Нет - Илья - я ЭТОГО НЕ ПРЕДЛАГАЮ... Проблема в другом... в том, что ВЫ не в состоянии понять, что понятие ОБРАЗОВАНИЕ - не эквивалентно понятию ПРОГРАММИРОВАНИЕ, а задачи СИСТЕМНОГО ПРОГРАММИРОВАНИЯ - составляют небольшую часть от задач ОБЩЕГО ПРОГРАММИРОВАНИЯ... где взаимодействие с ОС изолированно. И точно такая же ситуация в ДРУГИХ науках.. например , в разделах математики и физики... но там у людей ума хватает не заниматься тем, чем занимаетесь вы...
-
Борис, а ООП - вообще не влияет на производительность...
Зависит от реализации... при использовании полиморфизма наследования обычно происходит поиск метода соответствующего фактическому обьекту, в таблице виртуальных методов - чего обычно нет при вызовах статических методов.
Это особенность не ООП, а одной из реализаций полиморфизма.
Вот Хаскелл -- ни разу не ООЯ, но ad-hoc полиморфизм там обычно реализуют через таблицы виртуальных методов...
-
"Ершовский" принцип - базовая компетентность в сфере программирования нужна всем, чтобы осознанно действовать в новой "цифровой реальности". Но в текущих условиях любые базовые знания в области алг-и и прогр-я неспециалисту просто некуда приложить. Что-то реальное (хоть для ПК, хоть для мобильников, хоть для встроенки) совершенно оторвано, недосягаемо для тех знаний, которые неспециалист может получить из общих курсов. Т.е. школьная или вузовская непрофильная информатика так и остаётся непрактичным знанием, как и большая часть математики.
А могло бы быть всё по-другому.
Представим пространство цифровых устройств, сделанное по-другому. Допускающее взаимодействие посредством программирования - простого, на нормальном школьном уровне. "Как в Блэкбоксе".
Попробуйте "подумать эту мысль".
1. Ершов говорил о реальности .. не зная ее, сейчас я уверен, он бы сказал другое...
2. Курсы -курсам рознь... но из ситуации которая сложилась с базовой Инф и ЯП - не следует что они не нужны.. такая же ситуация и с другими разделами наук...
-
А могло бы быть всё по-другому.
Представим пространство цифровых устройств, сделанное по-другому. Допускающее взаимодействие посредством программирования - простого, на нормальном школьном уровне. "Как в Блэкбоксе".
Попробуйте "подумать эту мысль".
Не могло быть по-другому. Почитайте Савельева: мозг не любит думать, это очень энергозатратно. И всеми способами увиливает от нагрузок, заставить его чрезвычайно трудно.
И это у всех, не только у блондинок.
-
Борис, а ООП - вообще не влияет на производительность...
Зависит от реализации... при использовании полиморфизма наследования обычно происходит поиск метода соответствующего фактическому обьекту, в таблице виртуальных методов - чего обычно нет при вызовах статических методов.
Это особенность не ООП, а одной из реализаций полиморфизма.
Вот Хаскелл -- ни разу не ООЯ, но ad-hoc полиморфизм там обычно реализуют через таблицы виртуальных методов...
Евгений (или Геннадий ) - а вам не приходило в голову.. что эти две строчки эквивалентны фразе "в Хаскелле мы имеем ровно то же" :)
-
а вам не приходило в голову.. что эти две строчки эквивалентны фразе "в Хаскелле мы имеем ровно то же" :)
Ровно то же что?
-
а вам не приходило в голову.. что эти две строчки эквивалентны фразе "в Хаскелле мы имеем ровно то же" :)
Ровно то же что?
при фактической реализации ооп в ооп языках... вестимо.. о чем же еще был еще пост который вы цитировали..
-
а вам не приходило в голову.. что эти две строчки эквивалентны фразе "в Хаскелле мы имеем ровно то же" :)
Ровно то же что?
при фактической реализации ооп в ооп языках... вестимо.. о чем же еще был еще пост который вы цитировали..
О тормозах в программах на хаскелле из-за таблиц виртуальных методов? Так это известный факт.
Есть реализация, в которой вообще нет таких таблиц, но в каком она состоянии я не знаю, слышал только, что такой подход приводит к раздуванию машинного кода, что тоже не хорошо.
Промышленный компилятор GHC в меру сил старается оптимизировать такие таблицы для простых типов -- инлайн-вставки делает и даёт программисту (знающему, что он делает) возможность подсказать компилятору такие оптимизации.
-
Борис, а ООП - вообще не влияет на производительность...
А вызов метода разве не дороже вызова процедуры?
-
Борис, а ООП - вообще не влияет на производительность...
А вызов метода разве не дороже вызова процедуры?
У современных процессоров практически... равноценно... что прямой вызов подпрограммы, что косвенный...
-
Общеизвестный факт.
И при программировании "без ООП в языке", как в Обероне, будут ручные виртуальные таблицы указателей на процедуры.
Также и на С многие библиотеки в около-объектном стиле написаны.
А без полиморфизма вообще путную архитектуру не построишь.
Т.е. у Оберона херовая архитектура? O_o
-
У современных процессоров практически... равноценно... что прямой вызов подпрограммы, что косвенный...
Если абсолютизировать то на современных процессорах много что сгладилось. :)
А если это микроконтроллер? ;)
-
Общеизвестный факт.
И при программировании "без ООП в языке", как в Обероне, будут ручные виртуальные таблицы указателей на процедуры.
Также и на С многие библиотеки в около-объектном стиле написаны.
А без полиморфизма вообще путную архитектуру не построишь.
Т.е. у Оберона херовая архитектура? O_o
ilovb - но хоть вы то , немного подумайте.. причем здесь Оберон.. или Хаскель.. в том случае, когда речь идет об процедуре которая использует РОДОВОЙ метод у обьекта который СОЗДАЕТСЯ ВОВРЕМЯ ВЫПОЛНЕНИЯ (и его фактический тип определятся тогда же).. - то ВСЕГДА стоит задача поиска подходящего метода для ФАКТИЧЕСКОГО вызова...- тут даже не надо знать OOP просто немного здравого смысла. Заметьте, что в данном случае "вы попали плевком в небо" .
-
Разве... я почему то думал, что вся фича в том, что комманды(как системного уровня так и управления приложениями) можно набирать В ЛЮБОМ месте доступном для печати...фишка крутая для ранних ОС - где такие вещи приходилось делать часто рядовому пользователю.. но с появлением Нортон командера.. эта необходимость резко снизилась
Не совсем так. В Обероне предполагается что вы будете группировать команды в текстовых документах, и открывать последние в отдельном фрэйме. Возможность набрать команду в любом месте - это следствие, а не причина. Т.е. просто положительный побочный эффект.
А Нортон да... решает ту же проблему. Но подход Вирта имхо мощнее.
-
У современных процессоров практически... равноценно... что прямой вызов подпрограммы, что косвенный...
Если абсолютизировать то на современных процессорах много что сгладилось. :)
А если это микроконтроллер? ;)
Надо смотреть на тактовку процессора... Сколько тактов тратится на прямой и косвенные вызовы. Это должно быть записано в документации. Если интересно по Intel или AMD, то описания есть на их сайтах...
-
ilovb - но хоть вы то , немного подумайте.. причем здесь Оберон.. или Хаскель.. в том случае, когда речь идет об процедуре которая использует РОДОВОЙ метод у обьекта который СОЗДАЕТСЯ ВОВРЕМЯ ВЫПОЛНЕНИЯ (и его фактический тип определятся тогда же).. - то ВСЕГДА стоит задача поиска подходящего метода для ФАКТИЧЕСКОГО вызова...- тут даже не надо знать OOP просто немного здравого смысла. Заметьте, что в данном случае "вы попали плевком в небо" .
Вы смотрели в исходный код оригинального Оберона?
Он написан без ООП.
-
Не совсем так. В Обероне предполагается что вы будете группировать команды в текстовых документах, и открывать последние в отдельном фрэйме. Возможность набрать команду в любом месте - это следствие, а не причина. Т.е. просто положительный побочный эффект.
А Нортон да... решает ту же проблему. Но подход Вирта имхо мощнее.
1.Может быть.. но я так понял что наоборот.. кстати Илья фактически с этим согласился..
2. Нортон решал проблему ДЛЯ МАССОВОГО ПОЛЬЗОВАТЕЛЯ.. ВИРТ - тоже... прав тот кто выиграл...мощность массовому конечному
пользователю в рот не уперлась.
-
Он написан без ООП.
ilovb - вы что специально злите... может плохо кончится... все началось с вашей не относящейся к делу фразы.. которую оспорил Илья (сказав что это в ПРИНЦИПЕ х..я) , моя позиция - нет все ОК .. хотя к делу не относится...
-
Общеизвестный факт.
И при программировании "без ООП в языке", как в Обероне, будут ручные виртуальные таблицы указателей на процедуры.
Также и на С многие библиотеки в около-объектном стиле написаны.
А без полиморфизма вообще путную архитектуру не построишь.
Т.е. у Оберона херовая архитектура? O_o
ilovb - но хоть вы то , немного подумайте.. причем здесь Оберон.. или Хаскель.. в том случае, когда речь идет об процедуре которая использует РОДОВОЙ метод у обьекта который СОЗДАЕТСЯ ВОВРЕМЯ ВЫПОЛНЕНИЯ (и его фактический тип определятся тогда же).. - то ВСЕГДА стоит задача поиска подходящего метода для ФАКТИЧЕСКОГО вызова...- тут даже не надо знать OOP просто немного здравого смысла. Заметьте, что в данном случае "вы попали плевком в небо" .
Может быть я чего-то недопонимаю... Но при создании объекта определённого типа/класса во время выполнения делается простая привязка к его VMT, а далее следуют косвенные вызова без какого-либо поиска.
Иное дело... сообщения, но и там задача решается довольно изящно, в подавляющем числе случаев. Так как, сообщения описываются при написании программы, то в их описание включается и адрес (прямой/косвенный) обрабатывающего метода. Включение происходит непосредственно при компиляции программы/модуля. Во время работы в сообщение могут подставляться какие-то параметры, не изменяющие тип сообщения... Но могут быть, конечно, ситуации, когда сообщение создаётся непосредственно во время исполнения, и заранее тип сообщения неизвестен. Тогда нужен поиск, который ускоряется либо за счёт древовидного списка типов сообщений, либо за счёт хэширования. Но, тем не менее, поиск в таких ситуациях нужен... только часто ли возникают подобные ситуации?..
-
Может быть я чего-то недопонимаю... Но при создании объекта определённого типа/класса во время выполнения делается простая привязка к его VMT, а далее следуют косвенные вызова без какого-либо поиска.
Почему.. я точно так же это понимаю и говорю про эту "привязку" - обычно этот процесс называют связыванием
-
ilovb - вы что специально злите... может плохо кончится... все началось с вашей не относящейся к делу фразы.. которую оспорил Илья (сказав что это в ПРИНЦИПЕ х..я) , моя позиция - нет все ОК .. хотя к делу не относится...
Да относится оно к делу. Что непонятного то? Оберон написан без ООП и без эмуляции ООП.
Очевидно что CP и BB менее эффективен чем Оберон.
Можно конечно и на CP писать в стиле Оберона, но это уже будет передергиванием...
-
ilovb - вы что специально злите... может плохо кончится... все началось с вашей не относящейся к делу фразы.. которую оспорил Илья (сказав что это в ПРИНЦИПЕ х..я) , моя позиция - нет все ОК .. хотя к делу не относится...
Да относится оно к делу. Что непонятного то? Оберон написан без ООП и без эмуляции ООП.
Очевидно что CP и BB менее эффективен чем Оберон.
Можно конечно и на CP писать в стиле Оберона, но это уже будет передергиванием...
ПОТОМУ ЧТО ВЫ ОТПУСТИЛИ СВОЙ ПОСТ КАК РЕПЛИКУ НА МОЕ СООБЩЕНИЕ В КОТОРОМ ООП И НЕ ПАХЛО
-
DIzer, едрен батон... Вот ваш пост:
едва ли...ибо работа с железом делалась непрофессионалами... замеряли же производительность ББ кода и того же Шарпа.. ББ - был в жопе... вроде Сергей этим делом занимался
и он к делу не относится. Я говорил про Оберон, а вы приплели ДРУГУЮ СИСТЕМУ С ДРУГИМ ЯЗЫКОМ С ДРУГИМ МЕТОДОМ РАЗРАБОТКИ.
Не согласны? Ваше право.
Теперь перечитайте мои последние посты. Кто еще кого злит?!
-
вы либо тупы, либо встали не с той ноги...
вот ВАША ремарка на которую среагировал Илья.. и ответил Я http://oberspace.dyndns.org/index.php?action=post;quote=12775;topic=419.15;last_msg=12817 (http://oberspace.dyndns.org/index.php?action=post;quote=12775;topic=419.15;last_msg=12817) >:( >:( >:( >:( >:( >:( >:( >:( >:( >:( >:( >:( >:( >:(
-
Взаимно
-
ПОТОМУ ЧТО ВЫ ОТПУСТИЛИ СВОЙ ПОСТ КАК РЕПЛИКУ НА МОЕ СООБЩЕНИЕ В КОТОРОМ ООП И НЕ ПАХЛО
На всякий случай... Если до вас все еще не дошла суть нашей беседы. В том вашем сообщении как раз пахло ООП.
И я на это намекнул.
Некорректно критиковать Си тестами на С++
Некорректно критиковать качество одного компилятора кривизной рук разработчиков другого.
ps Если у вас туго с пониманием моих сообщений, то можно просто уточнить, а не начинать перепалку.
-
Господа, полнолуние давно прошло, де вы раньше были? ))
-
Господа, полнолуние давно прошло, де вы раньше были? ))
Новогодние каникулы круче полнолуния :-)
-
Все вернулись отдохнувшими с новыми силами. Нужно же энергию выплеснуть ;D
-
Еще поясню в чем суть:
Когда мы работаем с командной строкой, то у нас активна одна строка, а остальное лог.
Все это как бы в одном фрэйме на весь экран. Если мы хотим редактировать текст, то запускаем текстовый редактор и теряем на время командную строку и лог.
Есть очевидные недостатки такого подхода:
1. Все функции выполняет один фрэйм на весь экран. И соответственно пространство экрана используется неэффективно, т.к. реально мы только малую часть экрана используем в каждый момент времени.
2. Команды нужно набирать каждый раз заново.
3. Параметры у команд нужно набирать заново.
4. Ну и т.д. в том же духе.
Что сделал Вирт? Он взял и разделил экран на фрэймы.
Даже по умолчанию система запускается с 3 фрэймами, функции которых не сложно угадать. Это те самые функции которые раньше лежали на одном фрэйме (редактор, командная строка, лог)
Вот это настоящая философия Оберона по Вирту. Простое, дешевое концептуальное решение == мегатонный профит.
Вирт не делал окошек. Он просто порезал текстовый экран наиболее простым способом.
Все остальное фантазии народа, который недопонял Вирта (c) ;D
Это все было бы так, если Вирт не видел ничего кроме доса. В мире GNU это вообще не так, то есть как бы оберон-подход к интерфейсу не нужен. Это начиная где-то с 1987 года.
По пунктам:
1) Даже если предположить, что на результаты выполненных команд мы не смотрим, у нас есть screen (см. скриншот - у нас одновременно в одной и той же консоли имеем два окошка, в одном запущен top, в другом man по скрину, все это, чтобы не казалось что у меня какой-то тайловый линуксовый X11 оконный менеджер, отображается через putty под виндой, удаленный сеанс, так сказать).
2) Не нужно. Есть же Ctrl+r, и есть history, и, в конце концов, есть копочка up. Это вам не дос.
3) Не нужно. Ибо см. пункт 2. Для особо хитрых команд пишешь свой скрипт (тупо mycommand.sh и туда копипастишь свою команду). Все.
4) Угу. Все в консоли удобно. А вот в Оберон-GUI приходится на каждый чих до крысы тянуться. При этом, поскольку там "текст как интерфейс", клавиатуру выкинуть тоже не выходит. Вот и получается что юзер мечется между крысой и клавой.
То есть мегаценности Оберон-UI без графики тогда, и тем более сейчас, не представляет.
-
По пунктам:
1. Прикольно. Не знал. Ну это примерно и есть та идея, которую имел Вирт. Только он пошел еще дальше.
2. Ну в принципе да. У меня в FAR'е тоже нет проблем с набором команд ибо автоподстановка. Но у Вирта то вообще ничего набирать не надо. Все нужные команды с параметрами уже на экране. Достаточно кликнуть крысой на нужной.
3. см. 2
4. Я не говорю что интерфейс Вирта идеален. Мне в нем тоже многое не нравится. Крысу тоже ненавижу всей душой :D Просто мне не нравится когда подменяют идеи Оберона (не важно хорошие или плохие) своими фантазиями.
Вот философия Оберона: Acme (http://ru.wikipedia.org/wiki/Acme_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B5_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D0%B5))
А Joberon уже не торт... ;)
-
2. Ну в принципе да. У меня в FAR'е тоже нет проблем с набором команд ибо автоподстановка. Но у Вирта то вообще ничего набирать не надо. Все нужные команды с параметрами уже на экране. Достаточно кликнуть крысой на нужной.
Но ведь первый раз её кто-то должен набрать. А одноразовую команду ещё и стереть придётся...
-
По пунктам:
1. Прикольно. Не знал. Ну это примерно и есть та идея, которую имел Вирт. Только он пошел еще дальше.
Да никуда он дальше не пошел, он пошел перпендикулярно, сделав работу без крысы невозможной. Для меня это банально не эргономично.
2. Ну в принципе да. У меня в FAR'е тоже нет проблем с набором команд ибо автоподстановка. Но у Вирта то вообще ничего набирать не надо. Все нужные команды с параметрами уже на экране. Достаточно кликнуть крысой на нужной.
Я тянуться до крысы и ей кликать буду дольше, чем на клавиатуре Ctrl+R + первые две буквы команды. Более того, мне для этого даже задумываться не придется и переключать контекст в голове.
4. Я не говорю что интерфейс Вирта идеален. Мне в нем тоже многое не нравится. Крысу тоже ненавижу всей душой :D Просто мне не нравится когда подменяют идеи Оберона (не важно хорошие или плохие) своими фантазиями.
Ну, во-первых не надо из Оберона делать священное писание. Был базовый набор идей, и без фантазий не будет развития.
Во-вторых, кто сказал что вот именно ты понял верно Вирта, а у всех остальных фантазии? :-)
Вот философия Оберона: Acme (http://ru.wikipedia.org/wiki/Acme_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B5_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D0%B5))
А Joberon уже не торт... ;)
Угу. Абсолютно не юзабельная штука.
-
Во-вторых, кто сказал что вот именно ты понял верно Вирта, а у всех остальных фантазии? :-)
Возможно я тоже неправильно понял ::) Но я пересказываю то, что написано в книге "Проект Оберон" по памяти :)
-
Господа, полнолуние давно прошло, де вы раньше были? ))
Geniepro - вы атеист или хто.. valexey_u научным методом доказал независимость всплесков активности определенного уровня от фазы луны...
-
Господа, полнолуние давно прошло, де вы раньше были? ))
Geniepro - вы атеист или хто.. valexey_u научным методом доказал независимость всплесков активности определенного уровня от фазы луны...
Я рассматривал тот график и уверен, что там есть явная корреляция.
Не понимаю, почему валексей её отбросил ((
-
Да никуда он дальше не пошел, он пошел перпендикулярно, сделав работу без крысы невозможной. Для меня это банально не эргономично
Так вроде как бы наоборот.. печатаешь что то в произвольном месте... приспичило вызвать системную команду.. печатаешь ее.. выделяешь .. и комбинацией клавиши запускаешь... где - то так...
-
Господа, полнолуние давно прошло, де вы раньше были? ))
Geniepro - вы атеист или хто.. valexey_u научным методом доказал независимость всплесков активности определенного уровня от фазы луны...
Я рассматривал тот график и уверен, что там есть явная корреляция.
Не понимаю, почему валексей её отбросил ((
а каким методом вы определили, что она есть?
-
2 valexey
В Обероне есть такое понятие "Tool"
Это текстовый документ с набором команд сгруппированных по смыслу. В Обероне предполагается что человек будет работать так:
http://www.youtube.com/watch?v=U4z70f5YwUA&feature=youtu.be
Т.е. заранее открываем нужный tool (или несколько) и работаем с ним. Все команды с параметрами набраны. Аргументы - это либо выделенный текст, либо фокус на фрэйме (звездочка в видео)
На клаве я набрал только имя нового файла.
ps Оригинального оберона под рукой нет. Потому в несколько продвинутой версии... :)
-
а каким методом вы определили, что она есть?
На глаз. Ну ВИДНО же там! ))
-
2 valexey
В Обероне есть такое понятие "Tool"
Это текстовый документ с набором команд сгруппированных по смыслу. В Обероне предполагается что человек будет работать так:
http://www.youtube.com/watch?v=U4z70f5YwUA&feature=youtu.be
Т.е. заранее открываем нужный tool (или несколько) и работаем с ним. Все команды с параметрами набраны. Аргументы - это либо выделенный текст, либо фокус на фрэйме (звездочка в видео)
На клаве я набрал только имя нового файла.
ps Оригинального оберона под рукой нет. Потому в несколько продвинутой версии... :)
Мы вообще сосредоточились не на том. Окошки (разделение текстового или там фрейм-буфера) это все мелочи. Основное отличие Оберона от GNU (да и вообще юниксов) с точки зрения парадигмы UI в понятии файла. В юниксе файл, по сути, это поток данных (в частности - пайп). Соответственно все заточено на манипулирование этими потоками. Там так удобно строить цепочки и деревья обработки потоков этих. Потоки конечно же бесконечны (то есть никто не делает предположения что они могут быть конечными)
В Обероне же файл, это, пардон, документ. Точнее - текстовый буфер. И все в Обероне, в UI, нацелено на манипуляции с этим буфером (в том числе, например, с выделенной областью оного буфера). Накидать команд в правое окошко, а затем выделяя в левом кликать на правые, трансформируя левый буфер - это то, для чего Оберон действительно хорош.
Это принципиально две разные парадигмы. Каждая решает своё множество задач, они практически не пересекаются. Если противопоставлять, да сравнивать, то Оберон тут следует столкнуть лбами с emacs'ом, коий также оперирует трансформациями текстового буфера.
-
а каким методом вы определили, что она есть?
На глаз. Ну ВИДНО же там! ))
Там кое-где видны месячные колебания. Это не то же самое, что корреляция, а тем более зависимость от фазы луны.
-
valexey, полностью согласен. Именно так я и понимаю Оберон. У тебя даже лучше получилось выразить эту мысль.
Я уже где-то говорил что у Оберона и Unix по сути одна философия (в плане простоты и гибкости) Только реализовано это разными способами.
А разделение фрэйм буфера (плюс остальные плюшки) - это имхо и есть реализация этой идеи. То же самое в Acme
-
а каким методом вы определили, что она есть?
На глаз. Ну ВИДНО же там! ))
и это ответ атеиста... куда мы идем...
-
И кстати valexey, попробуй в joberone так работать ;)
Разработчик методику работы в Обероне похоже тоже не до конца вкурил... как и "все есть текст".
-
Пусть юзер (и его блондинка) не знает устройство того, на чём он каждый день "сёрфит по инету", но когда он осваивает ПО, в котором будет работать профессионально каждый день, то право и долг разработчика такого ПО стимулировать пользователя освоить именно такой стиль, в котором ему самому, юзеру, будет потом удобнее всего годами работать... Я видал и тёток в банках (не-программисток), которые любили ФАР, потому что им показали преимущества, и других, казалось бы, "тупых юзеров", которым кто-то что-то сумел правильно показать - и дело пошло...
Есть только одна маааленькая проблема. Предсказать обучаем пользователь или нет невозможно. Тем более когда у вашего продукта десятки, сотни или больше пользователей. Тут уже начинает рулить общая часто неочевидная статистика, а не способности отдельного индивида.
И строптивый юзер - это звэрь не обязательно тупой. Люди просто любят заниматься разведением тараканов в своей башке. Встречаются невероятно уникальные экземпляры. У меня однажды клиент не хотел принимать разработку из-за того что кнопка на форме была не того оттенка... изменил... через неделю опять не так... а потом выяснилось, что она время от времени работает на разных мониторах.
-
Есть только одна маааленькая проблема. Предсказать обучаем пользователь или нет невозможно. Тем более когда у вашего продукта десятки, сотни или больше пользователей. Тут уже начинает рулить общая часто неочевидная статистика, а не способности отдельного индивида.
Любой человек становится обучаем, если у него есть достаточный стимул.
Вопрос в том, даст ли эта оберон-технология активных текстов достаточно стимула простому пользователю...
-
Смотря кто этот простой пользователь.
Термин этот слишком перегружен смыслами.
-
Смотря кто этот простой пользователь.
Термин этот слишком перегружен смыслами.
Ну скажем так: это человек, для которого компьютер не является основным инструментом в его профессиональной деятельности.
Для того, что бы пообщаться по скайпу, или написать емэйл, или просто почитать электронную книгу, уметь программировать вовсе необязательно.
-
Такому конечно не подойдет. Да и вообще сейчас идет миграция на планшеты, а там интерфейс Оберона ну совсем не катит.
-
В Обероне Вирта только тайловые фрэймы и текст. Графики нет совсем. Графические только вьюшки, но и они лишь элементы текстовых документов. Кнопки у фреймов (закрыть, развернуть и т.д.) - это тоже тупо текст.
Если вдруг кому-то непонятно о чем я говорил:
http://www.youtube.com/watch?v=GCcTT-B8bIQ&feature=youtu.be
-
А могло бы быть всё по-другому.
Представим пространство цифровых устройств, сделанное по-другому. Допускающее взаимодействие посредством программирования - простого, на нормальном школьном уровне. "Как в Блэкбоксе".
Попробуйте "подумать эту мысль".
Не могло быть по-другому. Почитайте Савельева: мозг не любит думать, это очень энергозатратно. И всеми способами увиливает от нагрузок, заставить его чрезвычайно трудно.
И это у всех, не только у блондинок.
А если такое взаимодействие, в конце концов, снижает энергозатраты?
Программирование (в нормальном, не перегруженном инструментальном и технологическом окружении) я бы не сравнивал с автосервисом. Отнюдь. Австосервис - это рутина, вынужденная. Я хотел бы, чтобы автомобиль не ломался, но увы...
Я бы сравнил владение программированием (в той форме, в какой предлагает, например, И-21) с умением водить.
Можно неуметь - и ездить на транспорте, на такси.... Можно даже придумывать аргументы за это (полезнее для экоологии, для трафика в больших городах).
Но ничто не отменяет того факта, что умеющий водить принципиально более свободен в перемещениях, экономит своё время и деньги, чем прибегающий к услугам наёмного транспорта.
А ещё можно себе представить ситуацию, что в какой-то момент в прошлом (до массовой популяризации личных авто) были бы введены жёсткие ограничения на вождение - "только профессиональным водителям", и проч. Кто-нибудь бы предвидел аварийность при массовой автомобилизации, и т.п. Допустим.
Или управление автомобилем требовало бы каких-нибудь манипуляций на уровне управления электровозом.
И мы бы сейчас рассуждали "ах, кому нужно учится управлять автомобилем - есть профессиональные водители... Всё это фигня, человеку лень напрягать себя вождением".
-
И мы бы сейчас рассуждали "ах, кому нужно учится управлять автомобилем - есть профессиональные водители... Всё это фигня, человеку лень напрягать себя вождением".
Всё это, конечно, правильно, и всё уметь полезно. Полезно уметь водить автомобиль, самолёт, корабль, полезно уметь печь хлеб и варить сталь, полезно уметь забивать скот и ловить на траллах рыбу, очень полезно быть сантехником и электриком, канализацию прочищать...
Вот придумайте хоть одну профессию, которая не была бы полезной...
-
Но ничто не отменяет того факта, что умеющий водить принципиально более свободен в перемещениях, экономит своё время и деньги, чем прибегающий к услугам наёмного транспорта.
Ничто не отменяет факта, что в большинстве случаев - что глобальная экономия времени и денег не оправдывает локальных затрат на обучение и глобальных на содержание, а в тех случаях когда оправдывает.. народ просто учится водить и покупает личный транспорт..
-
1) Целевая аудитория "программирования-как-вождения", разумеется, не отождествляется с "народом" как всем населением. Допустим, пусть это будет 100 тысяч человек умственного труда сейчас не программирующих, но могущих, если бы это стало доступным.
2) Очевидно, что если бы это стало доступным (и не усложнялось рудиментарно либо эгоистично собственно ИТ-шной сферой), то эти 100 тысяч "пойдут и будут водить".
Таким образом, проблема единственно в том, что:
- неочевидно в народе (народе "умственного труда"), что программировать вообще можно достаточно легко - и получать полезный личный эффект;
- действительно за накопленной свалкой технологий неочевидно, каким образом это можно делать (но мы-то здесь знаем, как);
- как только делаются попытки преодолеть эти факторы (объяснить, что можно, стоит, нужно, да ещё и есть конкретный способ) - поднимается буча изнутри ИТ с ревностным возмущением.
-
1) Целевая аудитория "программирования-как-вождения", разумеется, не отождествляется с "народом" как всем населением. Допустим, пусть это будет 100 тысяч человек умственного труда сейчас не программирующих, но могущих, если бы это стало доступным.
2) Очевидно, что если бы это стало доступным (и не усложнялось рудиментарно либо эгоистично собственно ИТ-шной сферой), то эти 100 тысяч "пойдут и будут водить".
Таким образом, проблема единственно в том, что:
- неочевидно в народе (народе "умственного труда"), что программировать вообще можно достаточно легко - и получать полезный личный эффект;
- действительно за накопленной свалкой технологий неочевидно, каким образом это можно делать (но мы-то здесь знаем, как);
- как только делаются попытки преодолеть эти факторы (объяснить, что можно, стоит, нужно, да ещё и есть конкретный способ) - поднимается буча изнутри ИТ с ревностным возмущением.
1. А напрасно.. желание водить и поиметь личное авто возникает тоже далеко не у всех... у меня вот не возникает...
2. ОЧЕНЬ НЕОЧЕВИДНО - на гране безумства (при текущем уровне обобщения) -принципиально другое.. если отношение к продукту ЧИСТО ПОТРЕБИТЕЛЬСКОЕ - то пользователь будет сосредоточен на потреблении, а раз так то на ура будут восприниматься все достижения убирающие преграды на этом процессе..
-
А могло бы быть всё по-другому.
Представим пространство цифровых устройств, сделанное по-другому. Допускающее взаимодействие посредством программирования - простого, на нормальном школьном уровне. "Как в Блэкбоксе".
Попробуйте "подумать эту мысль".
Не могло быть по-другому. Почитайте Савельева: мозг не любит думать, это очень энергозатратно. И всеми способами увиливает от нагрузок, заставить его чрезвычайно трудно.
И это у всех, не только у блондинок.
А если такое взаимодействие, в конце концов, снижает энергозатраты?
Программирование (в нормальном, не перегруженном инструментальном и технологическом окружении) я бы не сравнивал с автосервисом. Отнюдь. Австосервис - это рутина, вынужденная. Я хотел бы, чтобы автомобиль не ломался, но увы...
Я бы сравнил владение программированием (в той форме, в какой предлагает, например, И-21) с умением водить.
Можно неуметь - и ездить на транспорте, на такси.... Можно даже придумывать аргументы за это (полезнее для экоологии, для трафика в больших городах).
Но ничто не отменяет того факта, что умеющий водить принципиально более свободен в перемещениях, экономит своё время и деньги, чем прибегающий к услугам наёмного транспорта.
А ещё можно себе представить ситуацию, что в какой-то момент в прошлом (до массовой популяризации личных авто) были бы введены жёсткие ограничения на вождение - "только профессиональным водителям", и проч. Кто-нибудь бы предвидел аварийность при массовой автомобилизации, и т.п. Допустим.
Или управление автомобилем требовало бы каких-нибудь манипуляций на уровне управления электровозом.
И мы бы сейчас рассуждали "ах, кому нужно учится управлять автомобилем - есть профессиональные водители... Всё это фигня, человеку лень напрягать себя вождением".
В плане автоматизации работы с системой практически ничего не меняется уже вот как лет 20-30. То есть никакого нового мусора там нет. Программируй под свои личные нужды как хочешь. Я говорю конечно о скриптинге. Языки программирования там простейшие.
А теперь давайте сравним сколько процентов пользователей могли написать простейший батник (или шелл-скрипт) 20 лет назад, и сколько сейчас?
-
Но ничто не отменяет того факта, что умеющий водить принципиально более свободен в перемещениях, экономит своё время и деньги, чем прибегающий к услугам наёмного транспорта.
Ничто не отменяет факта, что в большинстве случаев - что глобальная экономия времени и денег не оправдывает локальных затрат на обучение и глобальных на содержание, а в тех случаях когда оправдывает.. народ просто учится водить и покупает личный транспорт..
Таки да. У меня вот нет машины. Просто потому, что машина это геморрой - её надо где-то хранить (на минуточку - место на крытой парковке стоит 300 000 рублей, точнее стоило, сейчас наверно дороже), за ней надо ухаживать, техосмотры, резина и прочее.. До работы на машине добираться 30 минут зимой (по пробкам), на трамвае - 20 минут (у него выделенная линия).
-
А теперь давайте сравним сколько процентов пользователей могли написать простейший батник (или шелл-скрипт) 20 лет назад, и сколько сейчас?
нафига это сравнивать? - сравнение в ДАННОМ случае неуместно, пользователь сейчас и 30 лет назад - разные вещи (с точки зрения способностей , но не потребностей)
-
А теперь давайте сравним сколько процентов пользователей могли написать простейший батник (или шелл-скрипт) 20 лет назад, и сколько сейчас?
нафига это сравнивать? - сравнение в ДАННОМ случае неуместно, пользователь сейчас и 30 лет назад - разные вещи (с точки зрения способностей , но не потребностей)
То есть сейчас пользователи тупее, чем 20 лет назад?
-
То есть сейчас пользователи тупее, чем 20 лет назад?
Не тупее, а на другое ориентированы. Тот самый принцип экономии энергии :-)
-
То есть сейчас пользователи тупее, чем 20 лет назад?
Можно сказать и так, за счет экспоненциально разросшегося контингента (усредненная абилка упала) - не будите же вы отрицать это...
-
Но Алексей вот в чем прав, с точки зрения автоматизации базового конечнопользовательского взаимодействия с системой , с момента появления первых файловых менеджеров (20 -30 лет назад ) мало что изменилось.. -а они были популярны в то время и для той же аудитории... - я сужу по себе и своему окружению.. :)
-
Вот придумайте хоть одну профессию, которая не была бы полезной...
Торговый агент.
-
Вот придумайте хоть одну профессию, которая не была бы полезной...
Торговый агент.
очень даже полезно.. ибо позволяет извлечь нехилую прибыль из утиля (вроде китайских утюгов с 20 сантиметровым шнуром..), и самим жить не плохо...
-
А если такое взаимодействие, в конце концов, снижает энергозатраты?
Не получится, опять-таки читайте Савельева.
Примерно такой же случай: ну вот же, мозг, у меня полно жратвы, хватит и на завтра и на послезавтра и вообще. Нет, мозг заставляет нажраться до отвала, как в последний раз. Что там будет потом и конце концов, ему пофигу.
-
очень даже полезно.. ибо позволяет извлечь нехилую прибыль из утиля (вроде китайских утюгов с 20 сантиметровым шнуром..), и самим жить не плохо...
кстати , насчет утюгов... у меня в свое время даже возникла гипотеза о причине 20 сантиметровости шнура...
- это спец утюги для торговых агентов.. если опомнившийся потребитель забьет этот утюг в задницу торговому агенту (вовремя не успевшему ретироваться).. то включить его в розетку (для продления банкета) - будет весьма затруднительно...
-
А если такое взаимодействие, в конце концов, снижает энергозатраты?
Не получится, опять-таки читайте Савельева.
Примерно такой же случай: ну вот же, мозг, у меня полно жратвы, хватит и на завтра и на послезавтра и вообще. Нет, мозг заставляет нажраться до отвала, как в последний раз. Что там будет потом и конце концов, ему пофигу.
Это статистическая картина.
А когда мы планируем что-нибудь делать (ну, например, хотя бы пойти где-нибудь попреподавать), мы всегда намерены работать с исключениями из статистики, не так ли?
Иначе зачем вообще что-то делать, кроме как становиться пассивной составляющей текущей во времени статистики?