Налоги надо платить и спать спокойно (С)… ну, и со всеми, как говорят, можно договориться… видимо Вы не пробовали что-то продать — раз этого не знаете :) Лично у меня нет реактора, но ради интереса пробовал продавать ПО через одну из специализированных на этом фирм (не называю, чтобы не упрекнули в рекламе). Вполне продавалось — они даже налоги за меня платили — мне только оставалось подтверждать поступление денег на мой счет.
Парадный портрет автора, заодно иллюстрирующий идею современной веб-разработки
Отлично! В лучших традициях конца прошлого века. Ностальгия! Оч. понравилось. Теперь о том, что не совсем понравилось:
Неужели отображение данных на экране для просмотра и редактирования — такая неслыханная и невиданная задача, что никто не знает, с какой стороны к ней даже подступиться? Я вас умоляю. Она решалась столько раз, что даже просто перечислить — заболит палец, жмущий на клавишу «запятая». Так, навскидку, то, о чем я слышал: терминалы IBM 3270, Смоллтолк, экранный Постскрипт, WinAPI, TurboVision, VisualBasic, dBase, Tcl/Tk, XUL, Rebol/View, XAML.
Зачем валить в одну кучу как минимум два решения с противоположными целями? — Так будет еще меньше ясности. Постскрипт и т.д. (еще TeX забыли упомянуть!) своей целью имеет точное 1 в 1 воспроизведение верстки на любом устройстве — будь то стационарный дисплей, принтер или eBook или телефон. У HTML противоположная цель — переформатировать контент в зависимости от устройства вывода наиболее удобным для чтения образом. В первом случае задача решаема и решение найдено, нпр., pdf-формат. А во втором — задача в общем случае неразрешима, поэтому все попытки правильного отображения элементов оформления работают в не очень широких пределах. Чем больше таких элементов оформления и чем они сложнее — тем хуже они воспроизводятся на всем зоопарке возможных устройств. Это закон природы, и ничего тут не поделать. Поэтому чем проще веб-документ — тем лучше. Однако многие веб-дизайнеры не страдают отсутствием аппетита и так хотят кушать, что очень часто пытаются ухудшить уже сделанное. Т.о. ИМХО проблема даже не в вебе, а в недоедании дизайнеров.
В технике выделяются: средняя техническая квалификация техник-программист (ранее «программист-лаборант») и высшая техническая квалификация инженер-программист. (Вики)
PS Если дома термоядерный реактор, то можно соседям электричество продавать за пол-цены, выручку использовать на расширение своей электросети и на ее охрану :)
Да. Прежде всего школьнику нужно помочь понять: на какую работу он хочет приходить. Я очень надеюсь, что большинство не захотят приходить на IT-работу, иначе кто нас будет кормить и лечить…
а том тебя просят забыть всё, что ты учил раньше, и учиться приходится совершенно новому делу (причем, именно, делу) и учиться совершенно заново.
Это обычно технологии. А алгоритмы почти не меняются, меняются языки их реализующие.
Мне кажется, что мы обо всем договорились: на любом языке можно написать очень плохой код, но в школе главное не язык, а алгоритмика. Когда-то на Fortran-IV писали — на перфокартах (ужас!), но получалось алгоритмику изучать. И сейчас на фортране-4 можно, если учитель захочет лишних никому не нужных сложностей себе и своим ученикам. Но и на фортране можно.
В список языков, поддерживающих множественное наследование, входят: Io, Eiffel, C++, Dylan, Python, некоторые реализации классов Javascript (например, dojo.declare), Perl, Curl, Common Lisp (благодаря CLOS), OCaml, Tcl (благодаря Incremental Tcl)[1], а также Object REXX (за счёт использования классов-примесей). (Вики)
Придумавший ООП Алан Кей с этими «тремя китами» не согласится.
К примеру, можете сделать программу, которая в Го или даже в шахматы играет лучше существующих, можете внести ясность в проблему P=?NP и т.д. Но хорошо если что-то из этого получится у одного человека из всего населения Земли за 10 лет. А для остальных более мелкие дела. Кто сделал хоть что-то при прочих равных имеет больше шансов получить работу, чем те, что ничего не сделали.
Я знаю Oberon с момента его рождения. Но в любом случае ООП — это три кита: инкапсуляция, наследование и полиморфизм. В качестве приложения к ним куча проблем, нпр., проблемы множественного наследования. Это неоднозначно и для профи, а школьнику, который лирик это совсем не нужно — не мучайте детей…
Размер описания ничего не доказывает. ИМХО ООП, как и другие технологии, большинству школьников не нужны. И сколько книг по алгоритмам на Обероне на русском?
Зачем валить в одну кучу как минимум два решения с противоположными целями? — Так будет еще меньше ясности. Постскрипт и т.д. (еще TeX забыли упомянуть!) своей целью имеет точное 1 в 1 воспроизведение верстки на любом устройстве — будь то стационарный дисплей, принтер или eBook или телефон. У HTML противоположная цель — переформатировать контент в зависимости от устройства вывода наиболее удобным для чтения образом. В первом случае задача решаема и решение найдено, нпр., pdf-формат. А во втором — задача в общем случае неразрешима, поэтому все попытки правильного отображения элементов оформления работают в не очень широких пределах. Чем больше таких элементов оформления и чем они сложнее — тем хуже они воспроизводятся на всем зоопарке возможных устройств. Это закон природы, и ничего тут не поделать. Поэтому чем проще веб-документ — тем лучше. Однако многие веб-дизайнеры не страдают отсутствием аппетита и так хотят кушать, что очень часто пытаются ухудшить уже сделанное. Т.о. ИМХО проблема даже не в вебе, а в недоедании дизайнеров.
И где мешает монолит?
Существует с момента турбо-5, а микрософт тогда сделал свой, но он оказался не успешен. А был еще Think Pascal на Маке и т.д.
Извините, но я на этом «убожестве» много лет успешно работаю.
Лирикам не придётся.
Для изучения сортировки пузырьком иного не надо.
Да. Прежде всего школьнику нужно помочь понять: на какую работу он хочет приходить. Я очень надеюсь, что большинство не захотят приходить на IT-работу, иначе кто нас будет кормить и лечить…
Это обычно технологии. А алгоритмы почти не меняются, меняются языки их реализующие.
Это не важно — важно, что получилось.