Здравствуйте, Cyberax, Вы писали:

ПС>>Что такое «промокашка» ? ...
C>Салфетки, на которых по легенде во время обеда...

сдается мне ты тоже не разу не видел промокашку

Здравствуйте, Odi$$ey, Вы писали:

ПС>>>Что такое «промокашка» ? ...
C>>Салфетки, на которых по легенде во время обеда...
OE>сдается мне ты тоже не разу не видел промокашку
Видел, когда был в школе — их еще для чего-то в тетради вкладывали

Где сейчас их можно найти — совершенно не представляю.

Здравствуйте, Cyberax, Вы писали:

C>Видел, когда был в школе — их еще для чего-то в тетради вкладывали

Промокашками промокали кляксы, оставляемые чернильными ручками. Надеюсь что такое клякса объяснять не надо?
Блин, неужели я так стар

Здравствуйте, IT, Вы писали:

C>>Видел, когда был в школе — их еще для чего-то в тетради вкладывали
IT>Промокашками промокали кляксы, оставляемые чернильными ручками. Надеюсь что такое клякса объяснять не надо?
IT>Блин, неужели я так стар
Чернильные ручки? Что это такое?

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

Здравствуйте, Cyberax, Вы писали:

C>Чернильные ручки? Что это такое?

Это когда чернила наливались в чернильницу и туда макалась ручка с железным пером.

C>Когда я учился — их уже не было, одними шариковыми пользовались. Но времена были еще конца СССР, так что скорее всего промокашки вкладывали чисто по инерции.

Когда я учился тоже использовали шариковые, но чернильницы ещё встречались.

Здравствуйте, IT, Вы писали:

C>>Чернильные ручки? Что это такое?
IT>Это когда чернила наливались в чернильницу и туда макалась ручка с железным пером.
C>>Когда я учился — их уже не было, одними шариковыми пользовались. Но времена были еще конца СССР, так что скорее всего промокашки вкладывали чисто по инерции.
IT>Когда я учился тоже использовали шариковые, но чернильницы ещё встречались.
Я такое уже видел, к счастью, только в мультфильмах ужасов.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Cyberax, Вы писали:

C>>Чернильные ручки? Что это такое?

IT>Это когда чернила наливались в чернильницу и туда макалась ручка с железным пером.

C>>Когда я учился — их уже не было, одними шариковыми пользовались. Но времена были еще конца СССР, так что скорее всего промокашки вкладывали чисто по инерции.

IT>Когда я учился тоже использовали шариковые, но чернильницы ещё встречались.

В то время были и шариковые и чернильные ручки. Причем нам сначала (класса до 6-го) запрещали пользоваться чернильными, вплоть до выставления двоек за домашние задания, написанные чернильной ручкой.

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

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

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

Здравствуйте, eao197, Вы писали:

E>Чернильные ручки отличались от шариковой тем, что были пузатенькие и внутри у них был резервуар, который заканчивался сверху пипеткой. С помощью этой пипетки и набирались чернила -- перо ручки опускалось в бутылочку с чернилами, а пипетка расжималась и чернила заливались в резервуар.

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

Кстати, на самом деле хорошая перьевая ручка намного круче шариковой — она не оказывала сопротивление в процессе писания, а качество картинки было в разы лучше (жидкие чернила ложаться намного лучше, чем вязкая паста намазывается). Окончательно перьевые ручки, ИМХО, умерли при появлении гелевых. Однако и по сравнению с гелевыми у перьевых есть одно преимущество — из за того что пишущий элемент не круглый, а плоский малой толщины, начертание букв получается лучше.

Здравствуйте, eao197, Вы писали:

C>>>Когда я учился — их уже не было, одними шариковыми пользовались. Но времена были еще конца СССР, так что скорее всего промокашки вкладывали чисто по инерции.
IT>>Когда я учился тоже использовали шариковые, но чернильницы ещё встречались.
E>В то время были и шариковые и чернильные ручки. Причем нам сначала (класса до 6-го) запрещали пользоваться чернильными, вплоть до выставления двоек за домашние задания, написанные чернильной ручкой.

Жуть какая. Твои учителя сошли с ума.
Раньше (где-то до середины 70-х), наоборот, в младших классах разрешали писать только чернильными ручками — считалось, что иначе почерк испортится. В принципе это было правильно — пока шариковые ручки ещё не были освоены в широком производстве, а доступными были чернильными, начинать писать шариковыми было нельзя, потому что иначе было слишком тяжело переходить на чернильные.

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

Вот некоторые обсуждения этой темы:
раз
(в районе от 104-го сообщения, с моим участием)

поиск
(гугл подломан в плане кодировок, но в поиске видны даже страшилки про ломания шариковых ручек учителями)

E>Чернильные ручки отличались от шариковой тем, что были пузатенькие и внутри у них был резервуар, который заканчивался сверху пипеткой. С помощью этой пипетки и набирались чернила -- перо ручки опускалось в бутылочку с чернилами, а пипетка расжималась и чернила заливались в резервуар.

Это называлось чернильной автоматической ручкой ("авторучкой"), потому что она сама подавала чернила из баллончика. Но в школах такие ручки стали популярны не ранее 60-х. До того —
1) неавтоматические ручки, которые представляли из себя только перо воткнутое в держатель; немного чернил держалось на капиллярном эффекте в щели между верхней частью пера и ответной пластиной на держателе
2) чернильницы, в которые приходилось постоянно макать перья чтобы набрать следующую порцию чернил.

Ещё в мультиках 50-х годов хорошо виден процесс использования простых перьевых ручек и чернильниц со всеми вытекающими проблемами (например, нужна хорошая координация и отработка движений, чтобы не ставить кляксы). Впрочем, кляксы — проблема и авторучек — надо не совершать сильных нажимных движений вбок, иначе капиллярный канал раскрывается и его содержимое выливается.

E>Процедура заправки часто оказывалась очень грязной. Да и сами ручки, если были дешовыми или старыми, могли оставлять большие капельки чернил при длительном нажатии, а то и просто течь. Так что промокашки были очень востребованными.
E>Кстати, на промокашке практически невозможно было писать чернилами -- они расплывались. А карандаши легко рвали промокашки, только шариковой ручкой и получалось.

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

Здравствуйте, netch80, Вы писали:

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

Здравствуйте, FR, Вы писали:

FR>Понятно, значит грамотное развитие новых языков и средств программирования приведет в конечном счете к использованию чернильных ручек, прогресс однако.
Меня всегда удивляло куда заводят дискуссии на RSDN Например, в флейме "Час расплаты для Америки" было обсуждение стадий эволюции Солнца

Здравствуйте, mkizub, Вы писали:

M>За счёт того, что целое — больше суммы частей его составляющих.
M>Расширяемость и сложность на уровне компилятора ограничивается фиксированностью языка (байткода, нэйтивного кода и т.п.). Можно значительно повысить качество компилятора за счёт передачи ему высокоуровневой информации (напрямую, в виде дерева). И одновременно можно значительно повысить качество кода, имея расширяемый компилятор. И наоборот — никому нафиг не нужен расширяемый компилятор, если ему на вход и у него на выходе стоит нерасширяемый формат данных (синтаксис). Никому нафиг не оказались нужны просто structured editor для редактирования фиксированного текстового синтаксиса. А вместе они дают больше, чем каждый по отдельности. Точно так-же эта технология продолжается вглубь, до железа (вроде специальных GPU или настраиваемых FPGA) и вверх до дизайна программ (туда, где ныне живёт UML и пр.).

Всего один маленький вопрос (в одно слово): совместимость?
Есть Вася и Коля:
1. Вася: супер-пупер-крутой-синтксисис Васи -> семантические онтологии Васи -> ... ->байт код Васи.
2. Коля: супер-пупер-крутой-синтксисис Коли -> семантические онтологии Коли -> ... ->байт код Коли (заточенные под процессор Пети).

Теперь представьте что В, К и П — это не кучка подростков, а несколько конкурирующих корпораций, у каждой из которых свои стандарты.
А теперь ответьте на каком уровне будет обеспечиваться совместимоть?
Если на уровне описания онтологий — то мы получим еще один байт-код, только уровнем повыше. Нечто подобное есть в скале, там тоже есть внутренне представление, которые затем компилируется в JVM или .NET.
Но проблема в том что избавившись от бутылочного горлышка JVM/NET/командыПроцессора мы получили новое — семантические онтологии. Ведь наверняка найдутся люди которым этих возможностей не хватит и они быстренько "улучшат" стандарт (не будем показывать польцем на фирму на букву M...).
А на каком уровне проводить оптимизацию? Если генерить байт код JVM то задача опимизации под конкретное железо ложится на JIT, а если генерить сразу машинные комманды, то на семантические онтологии? И кто всем этим будет заниматься? И где гарантия что сгенеированные под одному DSL байт код JVM и машинный код будут совместимы (а уж тем более интероперабельны)? А если нет — то нахрена нам еще один уровень и лишний геморой? За это тоже будет отвечать SOP? Вы то сами в это верите?
А так ли уж важна расширяемость именно на уровне синтаксиса языка — може просто стоит наклепать еще одну предметно оринетированныую библиотечку и/или встроить groovy для скриптинга?

Лично мне нравиться Скала — там и синтаксис расширяемый и компилятор. Кроме того в отличии от всяких академических поделок она вполне применима (здесь и сейчас!), хотя бы как частичная замены Явы (например вместо xalan для обработки XML). Более того Скала может потеснить Яву как раз благодаря тому что они интероперабельны (если использовать -Xgeneric в Скале), то есть для того чтобы дернуть старую библиотеку на Яве из Скалы ровным счетом не требуется никаких извращений (хотя утверждать что бибилиотека написана на Яве тоже нельзя — может быть на той же Скале — бк он и в Африке бк).
Когда же я смогу использвать SymADE для написание сисетемы обмена информации между магазинами, да еще и так чтобы она компилировалась по желению в JVM/NET/машинныйКод и везде одинаково работала? Учтите что есть еще различные фреймворки и платформы.
И чтобы добиться этого Вам придется непросто написать тулзу для работы с семантикой + кодогенератор, но еще прикрутить к ней поддержку всех уже используемых платформ (legacy — страшная вещь!) + убедить всех остальных использовать это.

P.S. Сдается мне что светлое программистское будущее (с Вашей точки зрения) сильно напоминает строительство коммунизма.... Лучше уже пусть продолжают создавать различные языки под JVM, совместимые по библиотекам + клепают эти самые библиотеки. По крайней мере связка:
Разные языки->Один байт код->Разные JVM (под разные платформы, но соотвествуют одному стандарту)
уже сущесвует и вполне работоспособна и решает большую часть тех задач что и мифический SOP (по крайней мере никаких проблем с переносимостью и оптимизацией под железо нет).

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, netch80, Вы писали:

FR>Понятно, значит грамотное развитие новых языков и средств программирования приведет в конечном счете к использованию чернильных ручек, прогресс однако.

Естественно! Потому что символ делового успеха — "Паркер" с золотым пером.

Здравствуйте, IT, Вы писали:
IT>Промокашками промокали кляксы, оставляемые чернильными ручками. Надеюсь что такое клякса объяснять не надо?
Не надо . Я не понял, как связаны листочек бумаги из школьной тетради и UML (ни разу не видел промокашку с UML-диаграммой ). Поэтому подумал, что в данном случае слово «промокашка» — это какой-то жаргон (типа promotion action, для продвижения UML, только там он и выглядит хорошо).

Здравствуйте, Odi$$ey, Вы писали:
OE>сдается мне ты тоже не разу не видел промокашку
С UML-диаграммой — действительно ни разу не видел. Поэтому не могу сказать, хорошо UML смотрится на промокашке или плохо .

Здравствуйте, mini_root_2, Вы писали:

__>Всего один маленький вопрос (в одно слово): совместимость?

Не хуже, чем ныне. Если процессор X поддерживает фичу Y — то на нём можно сделать данное расширение. Если он не поддеживает эту фичу — её либо можно эмулировать (скажем, SIMD инструкции можно развернуть в последовательность комманд), либо в принципе нельзя (на текстовой консили не нарисовать графику). Ровно так-же обстоят дела и с операционными системами, графическими тулкитами и библиотеками и т.д. И решаются эти проблемы всё тем-же способом — или минимальным общим знаменателем, или использовать непереносимые фичи на конкретных платформах. Если у тебя программе удобно пользоваться иконками в трее, а трей есть не во всех операционках — то можешь либо не пользоваться треем вообще, либо пользоваться только там, где трей есть.

Разница только в одном — сейчас за тебя это решают сторонние дяди (вроде — делать поддержку трея в Java или нет), а в SOP это будешь решать ты (использовать расширение для трея или нет).

__>Теперь представьте что В, К и П — это не кучка подростков, а несколько конкурирующих корпораций, у каждой из которых свои стандарты.

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

__>Но проблема в том что избавившись от бутылочного горлышка JVM/NET/командыПроцессора мы получили новое — семантические онтологии. Ведь наверняка найдутся люди которым этих возможностей не хватит и они быстренько "улучшат" стандарт (не будем показывать польцем на фирму на букву M...).

Да, я же говорю — для этого всё и делается.
Чтоб фирма F могла добавить нужное ей для приложения Z расширение.

__>А на каком уровне проводить оптимизацию?

В SOP нет фиксированных "уровней". В виду единства формы представления кода программы. Это сейчас есть, скажем, 5 стадий компилятора из исходного кода в байткод, и 3 стадии компиляции из байткода в нэйтивный код. А в SOP фиксированного байткода нет, нет и "уровня байткода". Скажем, для компиляции приложения для мобилки, её частично может компилировать программист написавший программу, частично она может компилироваться на сервере (перед загрузкой в мобилку), и частично на мобилке. И нет стандарта — где и сколько надо оптимизировать и компилировать. Если у тебя смартфон или PDA, то хоть всё на мобилке|PDA компилируй. Если у тебя устройство с минимумом памяти — заливай на неё уже нэйтивный код.

__>Если генерить байт код JVM то задача опимизации под конкретное железо ложится на JIT, а если генерить сразу машинные комманды, то на семантические онтологии? И кто всем этим будет заниматься? И где гарантия что сгенеированные под одному DSL байт код JVM и машинный код будут совместимы (а уж тем более интероперабельны)? А если нет — то нахрена нам еще один уровень и лишний геморой?

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

__>За это тоже будет отвечать SOP? Вы то сами в это верите?

SOP вообще ни за что не будет отвечать. По причине того, что это парадигма программирования, а не компилятор.

__>А так ли уж важна расширяемость именно на уровне синтаксиса языка — може просто стоит наклепать еще одну предметно оринетированныую библиотечку и/или встроить groovy для скриптинга?

В SOP нет расширяемости на уровне синтаксиса, так как текстового представления нет. В нём есть расширяемость на уровне семантики.
По поводу наклёпывания ещё одной библиотеки — под одну яву уже наклепали их штуки 4. В результате, когда мне нужно отобразить сообщение с текстом и вопросом да/нет — мне надо выбирать какую использовать — AWT, Swing, SWT или ещё какую. И потом на другую не перелезть — только переписывать полностью программу.
А имея онтологию для пользовательского интерфейса я смогу вначале задать интерфейс, а уже потом выбирать на какой библиотеке это будет рисоваться.

__>Когда же я смогу использвать SymADE для написание сисетемы обмена информации между магазинами, да еще и так чтобы она компилировалась по желению в JVM/NET/машинныйКод и везде одинаково работала? Учтите что есть еще различные фреймворки и платформы.
__>И чтобы добиться этого Вам придется непросто написать тулзу для работы с семантикой + кодогенератор, но еще прикрутить к ней поддержку всех уже используемых платформ (legacy — страшная вещь!) + убедить всех остальных использовать это.

Так вроде я эту тему и открыл, чтоб обсудить данный вопрос. И начиналось первое сообщение с констатации факта, что даже будь у меня очень много денег — я не смогу убедить не то что всех — даже много людей не смогу убедить перейти на эту платформу. В силу законов эволюции.
И магазин на SymADE не скоро будет написан — для этого нужны деньги, чтоб прописать поддержку веб-программирования. А этих денег у меня нет. И не дадут — уже не дали, хотя год искал. И правильно сделали, что не дали — этот рынок забит под завязку, SOP тут просто не пробъётся, вложенные деньги не окупятся.

__>P.S. Сдается мне что светлое программистское будущее (с Вашей точки зрения) сильно напоминает строительство коммунизма....

А не строительство капитализма — светлого будущего всего человечества?

__>Лучше уже пусть продолжают создавать различные языки под JVM, совместимые по библиотекам + клепают эти самые библиотеки.

Так я же не против. Пусть.

Здравствуйте, Пётр Седов, Вы писали:

ПС>Здравствуйте, IT, Вы писали:
IT>>Промокашками промокали кляксы, оставляемые чернильными ручками. Надеюсь что такое клякса объяснять не надо?
ПС>Не надо . Я не понял, как связаны листочек бумаги из школьной тетради и UML (ни разу не видел промокашку с UML-диаграммой ). Поэтому подумал, что в данном случае слово «промокашка» — это какой-то жаргон (типа promotion action, для продвижения UML, только там он и выглядит хорошо).
Это именно жаргон. По легенде, большое количество повседневно используемых техничеких решений (например, идея стека протоколов TCP/IP или кодировка UTF-8) были впервые задокументированы на салфетках в кафе. Промокашка делается из близкого к салфеткам сорта бумаги — ее задача, как и у салфетки, хорошо впитывать, а не давать проверхность приспособленную для письма и рисования.

Лично я никогда не видел подобного применения салфеток: они чудовищно неудобны, рвутся от малейщего нажатия, а кроме того, в 100% кофеен салфетки не белые, а какого-нибудь насыщенного цвета. Вряд ли можно изобрести UTF-8, мучительно черкая синей ручкой по темно-зеленой рыхлой бумаге.

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

Здравствуйте, mkizub, Вы писали:

M>Эта мысль заключается в следующем — ни один тип животных и растений не смог вытеснить другой напрямую. Биоценоз — слишком хорошо отлаженная машина, и новичку в неё влезть практически невозможно. Все изменения в биосфере происходили в виде формирования нового биоценоза (где-нибудь в маргинальных местах, который старый не мог заполнить), и не вытеснял напрямую старые сообщества (животных и растений), а занимал временно опустевшие места (скажем, выгорел участок старого леса, и его заполнини новые растения).

Все D-программисты должны собраться и убить всех C++-программистов



M>Вывод для SymADE (и прочих "новых" языков и сред программирования, вроде Nemerle, Scala и т.д.) неутешительный — они не смогут вытеснить старые языки и средства разработки из их "экологических ниш". Но это же и ответ как развиваться дальше — надо занимать маргинальные ниши, где только они и могут существовать (в силу их преимуществ). И уже оттуда понемногу они будут развиваться дальше, и занимать всё большую часть пространства средств разработки программ.

Ассемблер вытеснил машинные коды.
С почти вытеснил Ассемблер.
С++ почти вытеснил С.
Java успешно начал вытеснять С++.

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

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

з.ы. Более интересный вывод: все вытесненные не умирают совсем (что было бы совсем неплохо в данном контексте). Все вытесненные продолжают тихонько жить где-то на задворках, но не уходят на совсем. И с каждым десятилетием их количество всё растёт. Страшно представить, что будет ещё через 50 лет. Даже немного жалко будущих программистов.

Здравствуйте, remark, Вы писали:

R>з.ы. Более интересный вывод: все вытесненные не умирают совсем (что было бы совсем неплохо в данном контексте). Все вытесненные продолжают тихонько жить где-то на задворках, но не уходят на совсем. И с каждым десятилетием их количество всё растёт. Страшно представить, что будет ещё через 50 лет. Даже немного жалко будущих программистов.

Хм, сначала были машкоды, потом ассемблер, потом пошли языки с абстракциями всё более высокого уровня. Попутно появились языки с компиляцией не в машкод, а в байткод виртуальной машины. При дальнейшем повышении абстракций как в языках, на которых пишет человек, так и в языках, которыми оперируют VM-ы, придём к тому, что программы будут писать программы, а человек — декларировать желаемый результат. Где-то так

Здравствуйте, netch80, Вы писали:

Да что вы в самом деле, 60-е, 80-е. Я вон в 90х помню эти авторучки, пытались мне в 3м классе почерк исправить . Ничего из этого не вышло, терпеть не мог когда кто-то из-за спины смотрит что я делаю, отмазался в итоге так: спросил — "Тебя мои пятерки устраивают? Ну так чего ты в душу лезешь?" (цитата)

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