Недавно хотел переходить на C#, но почитав топики типа C# vs VB пришел к выводу, что C# по крайней мере для моих скромных задач (Windows-приложение "для домашнего пользователя") будет пониже уровнем чем VB. Вот, интересует, с теоретической точки зрения, какой язык более высокоуровневый? И в чем вообще измеряется эта высокоуровневость?
Еще как-то спорил с человеком, который убеждал, что C++ выше по уровню чем VB и при этом Лисп выше по уровню чем VB, такое возможно или он просто недолюбливал VB?

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

_M>Недавно хотел переходить на C#, но почитав топики типа C# vs VB пришел к выводу, что C# по крайней мере для моих скромных задач (Windows-приложение "для домашнего пользователя") будет пониже уровнем чем VB. Вот, интересует, с теоретической точки зрения, какой язык более высокоуровневый? И в чем вообще измеряется эта высокоуровневость?

В длине, вестимо!

_M>Еще как-то спорил с человеком, который убеждал, что C++ выше по уровню чем VB и при этом Лисп выше по уровню чем VB, такое возможно или он просто недолюбливал VB?

У него просто линейка не той системы!

Здравствуйте, _Mihail,

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

А просто "уровень абстракции" — пустозвонство.

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

ГВ>...то уровень абстракции можно "мерять" только по отношению к чему-то конкретному. К командам процессора, например. Или по отношению к другим абстракциям, которые объявляются в этом случае "низкоуровневыми".

ГВ>А просто "уровень абстракции" — пустозвонство.

Ну, то что всё относительно, это понятно. Но должна же быть какая-то усредненная, общепризнанная точка отсчета, по которой все эту высокоуровневость меряют. Например, сложно найти такой пример, когда ассемблер, окажется выше по уровню, чем C#. Ну а определить кто выше — VB или С#, это фактически тоже самое, только в меньшем масштабе...

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

ГВ>>...то уровень абстракции можно "мерять" только по отношению к чему-то конкретному. К командам процессора, например. Или по отношению к другим абстракциям, которые объявляются в этом случае "низкоуровневыми".

ГВ>>А просто "уровень абстракции" — пустозвонство.

_M>Ну, то что всё относительно, это понятно. Но должна же быть какая-то усредненная, общепризнанная точка отсчета, по которой все эту высокоуровневость меряют.

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

_M>Например, сложно найти такой пример, когда ассемблер, окажется выше по уровню, чем C#. Ну а определить кто выше — VB или С#, это фактически тоже самое, только в меньшем масштабе...

А смысл-то какой в этой уровнеметрии? ИМХО, кроме как для споров в курилках её никуда не приткнёшь.

PS.: Впрочем, за всю Одессу не скажу, может быть, кто-то что-то и придумал.

Высокоуровневый означает, что программист меньше заботится о конкретных алгоритмах, использующихся в логике приложения, и больше — о самой логике. В идеале имеем декларативное описание того, что нам хочется видеть, а на выходе получаем готовую систему.
В случае с VB и C#, VB позволяет делать меньше телодвижений при написании ПО, хотя и делает это за счет снижения уровня контроля процесса, поэтому его в приниципе можно считать более высокоуровневым.

Здравствуйте, Пятачок, Вы писали:

П>В случае с VB и C#, VB позволяет делать меньше телодвижений при написании ПО, хотя и делает это за счет снижения уровня контроля процесса, поэтому его в приниципе можно считать более высокоуровневым.

Вот и я тоже так думаю.

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

_M>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>А просто "уровень абстракции" — пустозвонство.

_M>Ну, то что всё относительно, это понятно. Но должна же быть какая-то усредненная, общепризнанная точка отсчета, по которой все эту высокоуровневость меряют. Например, сложно найти такой пример, когда ассемблер, окажется выше по уровню, чем C#. Ну а определить кто выше — VB или С#, это фактически тоже самое, только в меньшем масштабе...

Как general-purpose язык, VB будет повыше уровнем, чем C#. Только давай посмотрим, какой из этого можно сделать вывод.

Ты прав в том, что уровень абстракции действительно имеет значение. Чем меньшим кол-вом операций уровня языка решается задача, тем лучше. Заметь, я выделил слово "решается". Но может и не решиться, или решиться, но очень через "ж". В таком случае два выхода: либо перейти на язык с более низким уровнем абстракции, либо вместо general-purpose языка использовать DSL.

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

Здравствуйте, Пятачок, Вы писали:

П>В случае с VB и C#, VB позволяет делать меньше телодвижений при написании ПО

А можно конкретные примеры снижения телодвижений.

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

V>А можно конкретные примеры снижения телодвижений.

Меня лично больше всего испугали замечания по поводу какой-то усложненной работы с Optional-параметрами в C#. Строчить десятки перегрузок как в .Net Framework или вытворять всякие трюки с проверками параметров, как в VB6 — нет никакого желания.

Ещё непонятности с привязкой событий к методам. Привязка, как я понял, происходит где-то в генеренном коде и говорят, что если метод убрать, она там остается и надо вручную туда лесть и чистить. Ну и т.п. — обработка событий вообще в C# мне кажется на много непонятнее сделана, чем в VB — в VB handler'ы можно выбрать из чекбоксов и не нужно ничего динамически привязывать. Но, конечно, я мельком смотрел, мог чего и не увидеть.

Прошу ногами не бить, если чего напутал, в C# не разбираюсь практически совсем .

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

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

Объясните, а то моя твоя не понимать

_M>Ну и т.п. — обработка событий вообще в C# мне кажется на много непонятнее сделана, чем в VB — в VB handler'ы можно выбрать из чекбоксов и не нужно ничего динамически привязывать.

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

_M>Прошу ногами не бить, если чего напутал, в C# не разбираюсь практически совсем .

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

_M>Меня лично больше всего испугали замечания по поводу какой-то усложненной работы с Optional-параметрами в C#. Строчить десятки перегрузок как в .Net Framework или вытворять всякие трюки с проверками параметров, как в VB6 — нет никакого желания.

На практике совершенно не напрягает. Честно говоря, даже наоборот лучше иногда.

_M>Ещё непонятности с привязкой событий к методам. Привязка, как я понял, происходит где-то в генеренном коде и говорят, что если метод убрать, она там остается и надо вручную туда лесть и чистить. Ну и т.п. — обработка событий вообще в C# мне кажется на много непонятнее сделана, чем в VB — в VB handler'ы можно выбрать из чекбоксов и не нужно ничего динамически привязывать. Но, конечно, я мельком смотрел, мог чего и не увидеть.


Эээээ... ЧЕГО-О-О-О-О???????????????????????????!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Кого чистить???? Там есть в контекстном меню reset, если ты про среду разработки и события в форме
А что в C# нужно привязывать динамически, что в VB можно привязать через GUI системы программирования?

_M>Прошу ногами не бить, если чего напутал, в C# не разбираюсь практически совсем .

Хорошо, будем бить кувалдами

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

_M>Недавно хотел переходить на C#, но почитав топики типа C# vs VB пришел к выводу, что C# по крайней мере для моих скромных задач (Windows-приложение "для домашнего пользователя") будет пониже уровнем чем VB. Вот, интересует, с теоретической точки зрения, какой язык более высокоуровневый? И в чем вообще измеряется эта высокоуровневость?
_M>Еще как-то спорил с человеком, который убеждал, что C++ выше по уровню чем VB и при этом Лисп выше по уровню чем VB, такое возможно или он просто недолюбливал VB?

Уровень VB и C# в .NET практически один и тот же, в частности, за счёт того, что они пользуются одной и той же библиотекой .NET framework
Вопрос только в синтаксисе и всё. Вот если ты будешь писать на MS IL, тогда другое дело, это уже будет ниже уровнем.

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

V>Здравствуйте, Пятачок, Вы писали:

П>>В случае с VB и C#, VB позволяет делать меньше телодвижений при написании ПО

V>А можно конкретные примеры снижения телодвижений.

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

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

_M>Недавно хотел переходить на C#, но почитав топики типа C# vs VB пришел к выводу, что C# по крайней мере для моих скромных задач (Windows-приложение "для домашнего пользователя") будет пониже уровнем чем VB. Вот, интересует, с теоретической точки зрения, какой язык более высокоуровневый? И в чем вообще измеряется эта высокоуровневость?
_M>Еще как-то спорил с человеком, который убеждал, что C++ выше по уровню чем VB и при этом Лисп выше по уровню чем VB, такое возможно или он просто недолюбливал VB?
Высокоуровневость — штука весьма субъективная. В принципе, можно говорить о мощности языка в плане сложности конструкций, которые в нем поддерживаются напрямую, т.е. являются т.н. "first class citizens".
И даже в этом случае ответ будет неоднозначным. Вот, к примеру, если взять язык MSX BASIC, то он с одной стороны выше уровнем, чем С, т.к. в нем есть конструкция PRINT для вывода в консоль и конструкция LINE для рисования линии алгоритмом брезенхема, а в С их нет. С другой стороны, в С есть понятие "функции", а в бейсике его нету. Поэтому там, где в С можно спрятать сложность предметной области за одним вызовом, в бейсике будет шаманство с установкой значений переменных. А в С++ можно определить операторы таким образом, чтобы получить синтаксис рисования линии достаточно близким к бейсику, и при этом без потери общности — там, где в бейсике захардкожен банальный брезенхем, в плюсах может на лету подцепляться реализация из AntiGrain с субпиксельным сглаживанием.

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

Если сравнивать C# и VB.NET, то высота уровня со всех точек зрения окажется практически одинаковой. Это, грубо говоря, один и тот же язык с немножко разным синтаксисом.
Список "фундаментальных" различий очень-очень мал. Вот Nemerle является языком более высокого уровня по отношению к обоим сравниваемым кандидатам.

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

S>И даже в этом случае ответ будет неоднозначным. Вот, к примеру, если взять язык MSX BASIC, то он с одной стороны выше уровнем, чем С, т.к. в нем есть конструкция PRINT для вывода в консоль и конструкция LINE для рисования линии алгоритмом брезенхема, а в С их нет. С другой стороны, в С есть понятие "функции", а в бейсике его нету. Поэтому там, где в С можно спрятать сложность предметной области за одним вызовом, в бейсике будет шаманство с установкой значений переменных. А в С++ можно определить операторы таким образом, чтобы получить синтаксис рисования линии достаточно близким к бейсику, и при этом без потери общности — там, где в бейсике захардкожен банальный брезенхем, в плюсах может на лету подцепляться реализация из AntiGrain с субпиксельным сглаживанием.

Как по мне, то плясать нужно от того, что в С есть указатели и адресная арифметика а Бейсике нет. Это как минимум.

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Как по мне, то плясать нужно от того, что в С есть указатели и адресная арифметика а Бейсике нет. Это как минимум.

ANS>А в общем то, получается, что чем выше уровнем язык, тем сложнее его использовать как универсальный язык

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

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

ANS>>А в общем то, получается, что чем выше уровнем язык, тем сложнее его использовать как универсальный язык

F>Может ассемблер и проще использовать как универсальный язык, нежели С, но как-то это непросто получится

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

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

S>А в С++ можно определить операторы таким образом, чтобы получить синтаксис рисования линии достаточно близким к бейсику, и при этом без потери общности — там, где в бейсике захардкожен банальный брезенхем, в плюсах может на лету подцепляться реализация из AntiGrain с субпиксельным сглаживанием.

Согласен, на С++ наверно можно реализовать функции, которые реализованы в VB, да ещё подогнать их под свои вкусы. Что там говорить — и VB и студия написаны на C++, можно и их написать, и тот же Nemerle. Только это уже фактически не C++ будет, а опять VB или Nemerle — как ни крути, а придется всё равно расплачиваться падением универсальности, за высокоуровость. Вобщем, прятаться за "потенциальные" возможности высокоуровности языка врятли получится. Поэтому мне кажется C++ в любом случае оказывается ниже по уровню, чем VB.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Как по мне, то плясать нужно от того, что в С есть указатели и адресная арифметика а Бейсике нет. Это как минимум.
Это не "как минимум", а очень-очень узкий взгляд на вещи.

К тому же ты что, собрался мерить уровень языка по отсутствию в нем чего-то? Ну тогда С++, к примеру, значительно ниже уровнем, чем С. Т.к. в С нет почти ничего из того, что есть в С++. Это какой-то нездоровый парадокс. И таких парадоксов — море. К примеру, с таким подходом лисп и форт — языки примерно одного уровня.


ANS>А в общем то, получается, что чем выше уровнем язык, тем сложнее его использовать как универсальный язык
Непонятно, с чего бы это. Вот как раз ассемблер x86, к примеру, очень сложно использовать как универсальный язык. Ну-ка, изобрази мне на нем что-нибудь несложное; к примеру — веб-сервер с формз аутентификацией и персонализацией. А вот очень-очень высокоуровневый язык типа Nemerle можно использовать для чего угодно.

В общем, ребяты, низкоуровневость не сводится к возможности написать драйвер. Драйвера к Singularity влет пишутся на любом языке дотнета, в том числе и VB.

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

_M>Согласен, на С++ наверно можно реализовать функции, которые реализованы в VB, да ещё подогнать их под свои вкусы. Что там говорить — и VB и студия написаны на C++, можно и их написать, и тот же Nemerle. Только это уже фактически не C++ будет, а опять VB или Nemerle — как ни крути, а придется всё равно расплачиваться падением универсальности, за высокоуровость.
А можно показать мне конкретно, в какой момент придется расплачиваться? Я вот совершенно этого не вижу.

_M> Вобщем, прятаться за "потенциальные" возможности высокоуровности языка врятли получится. Поэтому мне кажется C++ в любом случае оказывается ниже по уровню, чем VB.
Ребята, это совсем другая ось графика. Есть DSL — языки, специфичные для определенной области. Они не выше и не ниже, чем General Purpose Programming Languages, они сбоку.
И VB.NET и С++ являются turing-complete языками, и никакого "падения универсальности" в них нет. Если у вас оно происходит, то проблема не в языке.

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

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

S>В общем, ребяты, низкоуровневость не сводится к возможности написать драйвер. Драйвера к Singularity влет пишутся на любом языке дотнета, в том числе и VB.

приводить в качестве доказательства возможности операционки, которую никто не видел и неизвестно когда можно будет увидеть, по меньшей мере неубедительно

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

_M>Ну, то что всё относительно, это понятно. Но должна же быть какая-то усредненная, общепризнанная точка отсчета, по которой все эту высокоуровневость меряют. Например, сложно найти такой пример, когда ассемблер, окажется выше по уровню, чем C#. Ну а определить кто выше — VB или С#, это фактически тоже самое, только в меньшем масштабе...

Нет точки. Есть отношение "A более высокоуровневый, чем B", но для него не выполняется свойство трихотомии. Так что расположить языки как точки на прямой не получится. Да и само отношение нельзя определить достаточно строго.

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

Тогда уж, самый высокоуровневый — UML.

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

ГВ>А смысл-то какой в этой уровнеметрии? ИМХО, кроме как для споров в курилках её никуда не приткнёшь.
ГВ>PS.: Впрочем, за всю Одессу не скажу, может быть, кто-то что-то и придумал.
А меры Холстеда помните? Там у него есть оцифровка уровня языка...

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


V>А можно конкретные примеры снижения телодвижений.

Неявные приведения типов, т.е. код немного короче без этих операторов приведения. Еще ToString() не надо вызывать и т.д.

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

_M>Недавно хотел переходить на C#, но почитав топики типа C# vs VB пришел к выводу, что C# по крайней мере для моих скромных задач (Windows-приложение "для домашнего пользователя") будет пониже уровнем чем VB. Вот, интересует, с теоретической точки зрения, какой язык более высокоуровневый? И в чем вообще измеряется эта высокоуровневость?

Высокоуровневость [во многом] определяется развитостью системы типов языка. В ассемблере типов нет вообще. В С типы присутствуют, однако отсутствует контроль типов — в том плане он близок к макроассемблеру. Что подверждается практикой его применения — он в основном используется сейчас как переносимый ассемблер.

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

Да, у VB c C# система типов одинакова. Не в курсе, правда, есть ли в VB поддержка параметрических типов (женериков) и прочие рюшки, их отсутствие поменяет расклад в сторону C#.

Насчет Лиспа вопрос крайне интересный. Он не особенно вписывается в приведенную классификацию, как, впрочем, огромное множество других языков программирования . Хотя бы потому, что вопрос "есть ли типы в Лиспе" — до определенной степени философский.

ЗЫ: Поменьше интересуйся уронями языков, и побольше — самими языками. С практической точки зрения вопрос "уровня языка" — бессмысленный, ответ на него ничего не меняет. Вот например, в 1С, которым я по молодости занимался, применяется наитупейший язык, при этом — учетные приложения на 1С пишутся в разы быстрее, чем на VB. Можно задаваться философскими вопросами, почему получается так, если 1С — говно, но факт остается фактом.

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

LVV>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>А смысл-то какой в этой уровнеметрии? ИМХО, кроме как для споров в курилках её никуда не приткнёшь.
ГВ>>PS.: Впрочем, за всю Одессу не скажу, может быть, кто-то что-то и придумал.
LVV>А меры Холстеда помните? Там у него есть оцифровка уровня языка...

...языка выражения, а не самого по себе языка программирования.

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

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

S>Если сравнивать C# и VB.NET, то высота уровня со всех точек зрения окажется практически одинаковой. Это, грубо говоря, один и тот же язык с немножко разным синтаксисом.

И здесь одно любопытное соображение возникает. В общем-то, C# — это приглашение программистов C++ в .Net. Потому что если бы их пригласили в VB.NET, то они бы и не пошли скорее всего — из-за традиционного презрения к Бейсику .

А соображение вот какое. Насколько развитие языков программирования (да и IT вообще) определяется внутренними законами отрасли как таковой и насколько — привходящими факторами (нелады MS с Sun, а до этого — с IBM, желание привлечь си-шников в .Net и т.д.) ?

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

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

PD>А соображение вот какое. Насколько развитие языков программирования (да и IT вообще) определяется внутренними законами отрасли как таковой и насколько — привходящими факторами (нелады MS с Sun, а до этого — с IBM, желание привлечь си-шников в .Net и т.д.) ?

PD>В математике, к примеру, такого нет. Если математик предложит некую теорему, а докажет ее каким-то нестандартным способом, то другие математики найдут стандартный способ доказательства. (если, конечно, такой существует) Именно он попадет в учебники, а про исхищрение скорее всего забудут.

Ну и как, по прежнему рулит начертательная геометрия?





на становление математики ушло сколько лет? 3000? 5000?
Становление IT сколько — 50 лет? 70?
Математика куда как больше устоялась, вот и кажется там многое "стандартным". Хотя когда-то таких стандартов тоже не было.

И не надо забывать, что IT — это по большей части прикладная сфера, а доказательство теорем — научная.

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

И что никакая компания по производству калькуляторов или математических пакетов никогда не пыталась переманить пользователей от конкурентов?

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

F>на становление математики ушло сколько лет? 3000? 5000?

Это совершенно пофигу. Важно не то, что и сколько становилось. Математика оперирует чистыми абстракциями, а программирование на выходе имеет конкретный продукт. Байку о взаимосвязи диаметра ускорителей шаттлов и ширине задницы римской лошади напомнить?

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


AVK>Это совершенно пофигу. Важно не то, что и сколько становилось. Математика оперирует чистыми абстракциями, а программирование на выходе имеет конкретный продукт.

Все технологии имеют на выходе конкретный продукт. Но если бы Эдисон умер в младенчестве, мы бы сейчас все равно без света не сидели, и лампочка была такой же, какой она сейчас является (кстати, вольфрамовую нить придумал ИМХО не Эдисон). И не родись Дизель, дизели все равно бы появились, правда, назывались бы иначе . И без Маркони мы бы имели Радио России и Эхо Москвы

А вот без Кернигана-Ритчи-Страуструпа мы бы С/C++ не имели бы. Был бы иной язык, определивший бы развитие IT в 90-е годы. И если бы Билл Гейтс не посоветовал IBM 8088 процессор, об этой архитектуре давно бы забыли.

Я аналогичного в истории техники не знаю.

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

PD>Я аналогичного в истории техники не знаю.

А как же римские лошади?

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

PD>Все технологии имеют на выходе конкретный продукт. Но если бы Эдисон умер в младенчестве, мы бы сейчас все равно без света не сидели, и лампочка была такой же, какой она сейчас является (кстати, вольфрамовую нить придумал ИМХО не Эдисон). И не родись Дизель, дизели все равно бы появились, правда, назывались бы иначе .

Пожалуйста убедительные доказательства того, что лампочка была бы точно такая же без Эдисона Может быть есть результаты экспериментов?
Почему бы тема на провисла еще на 50 лет, а потом кто-нибудь не придумал бы сразу неонки, и они бы стали стандартом, а лампы накаливания придумали бы позже и они бы так и считались непонятной неэффективной игрушкой?

Так же в природе не существует некоего единого "дизельного двигателя". Дизель запатентовал "Метод и аппарат для преобразования высокой температуры в работу". Была высказана общая идея самовоспламенения топлива при высоком давлении и предложен один возможный вариант реализации. Но вариантов реализации этого в железе — миллион и еще несколько. Их до сих пор совершенствуют.
Есть большие направления, считающиеся более пригодными для того или иного направления (корабли или автомобили), в рамках направления — есть отдельные реализации, укаждой свои плюсы и минусы, а иногда они вообще полностью аналогичны за исключением производителя.
Придумывались разные варианты, некоторые "классические" уже, некоторые считаются безумными, а через несоклько лет становятся "классическими"

Некоторые дизели различаются между собой как ассемблер и C# а между другими разницы меньше чем между C# и Java.

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

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

AF>А как же римские лошади?

Сорри, но я ничего не знаю про них. Расскажи.

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

F>Пожалуйста убедительные доказательства того, что лампочка была бы точно такая же без Эдисона Может быть есть результаты экспериментов?
F>Почему бы тема на провисла еще на 50 лет, а потом кто-нибудь не придумал бы сразу неонки, и они бы стали стандартом, а лампы накаливания придумали бы позже и они бы так и считались непонятной неэффективной игрушкой?

Ценю твой юмор . Убедительных доказательств, сам понимаешь, привести не могу, но некоторые аргументы все же приведу. Для создания неонки (и думателя надо все же иметь определенный уровень технологии. Создать плазму, научиться ей управлять и т.д. А вот то, что раскалившаяся спираль излучает свет — более на поверхности. Эдисон додумался все это в вакуум-сосуд поместить, да, это его заслуга. А вот поверить, что еще 50 лет сидели бы с керосиновой лампой — как-то плохо верится.



F>Так же в природе не существует некоего единого "дизельного двигателя". Дизель запатентовал "Метод и аппарат для преобразования высокой температуры в работу". Была высказана общая идея самовоспламенения топлива при высоком давлении и предложен один возможный вариант реализации. Но вариантов реализации этого в железе — миллион и еще несколько. Их до сих пор совершенствуют.

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

F>Некоторые дизели различаются между собой как ассемблер и C# а между другими разницы меньше чем между C# и Java.

Да, конечно. Но тем не менее дизель есть дизель и не становится от этого ни карбюраторным, ни реактивным двигателем.


F>Дизель — это Дейкстра.
F>Дейкстра сформулировал идею структурного програмиирования, а производители языков наклепали 1000 вариантов алгоритмических языков.

Хм... С тем, что все "поздние" языки поддерживают более или менее приличную структуризацию — не поспоришь (в отличие от Фортана-4, к примеру). Но вот то, что именно этот язык оказался основным — никак из идей Дейкстры не следует. Можно, конечно, утверждать, что C и Pascal (и Modula, и Ada) по возможностям и архитектуре близки, но все же есть большая разница между нынешним C-миром и гипотетическим Pascal-миром. А ведь мог и второй быть, если бы не Керниган-Ритчи. Или какой-то иной мир. Но не С, И это был бы совсем иной мир. Без Java. Без C#. Без PHP. Что-то совсем иное...

Вдогонку
F>>Дейкстра сформулировал идею структурного програмиирования, а производители языков наклепали 1000 вариантов алгоритмических языков.

А Бэкус с Науром сформулировали БНФ. Так сказать, идеи о том, каким язык должен быть. И Виртовский Паскаль этим идеям прекоасно удовлетворяет, и Модула, и Ада. А язык C, как будто специально, был сделан так, что под БНФ крайне плохо подходит. И прекрасно без всех этих БНФ-форм и синтаксических диаграмм просуществовал.

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

PD>Сорри, но я ничего не знаю про них. Расскажи.

«Конструкторы многоразового космического корабля „Кеннеди“ не могут увеличить мощность его ускорителей, потому что их диаметр (1,524 м) определяется... шириной лошадиного крупа». Не умаляя остроумия анонимного автора, который выдумал эту логическую цепочку и разместил её в интернете, уточним некоторые цифры. Каждый из двух твёрдотопливных ускорителей американского «Шаттла» имеет длину 45,7 м и диаметр 3,7 м (в районе топливных сегментов двигателя). Наружный топливный бак, который содержит криогенное топливо для питания маршевых двигателей «Шаттла», имеет диаметр 8,4 м. Дело в том, что двигатели эти доставлялись по железной дороге, которая проходит по узкому туннелю. Расстояние между рельсами стандартное: 4 фута 8,5 дюйма (1,435 м), поэтому конструкторы могли сделать двигатели только шириной 5 футов. Вопрос: почему расстояние между рельсами 4' 8,5"? Откуда взялась эта цифра? Оказывается, железную дорогу в Штатах строили такую же, как и в Англии, где, в свою очередь, железнодорожные вагоны делали такими же, что и трамвайные, а первые трамваи производились по образу и подобию конки. А длина оси конки составляла как раз 4' 8,5".

Но почему? Потому что конки делали с таким расчётом, чтобы их оси попадали в колею на английских дорогах – благодаря этому колёса меньше изнашивались, – а расстояние между колеями в Англии как раз 4' 8,5"! Отчего так? Да просто дороги в Великобритании стали делать римляне, подводя их под размер своих боевых колесниц, длина же оси стандартной римской колесницы равнялась... Правильно, 4' 8,5"!

Первые колейные дороги Древней Греции и Древнего Рима, представлявшие собой углубления до 50 мм в каменном основании, имели ширину 1,5–1,6 м. Это соответствовало ширине уличных экипажей.

Ну вот, теперь мы поняли, откуда взялся этот размер. Но всё же, почему римлянам вздумалось делать свои колесницы с осями именно такой длины? А вот почему: в колесницу запрягали обычно двух лошадей.
А 4' 8,5" – как раз размер двух лошадиных задниц! Делать ось колесницы длиннее было неудобно, так как это нарушало бы её равновесие. Суммарная ширина крупов двух лошадей намного больше длины оси колесницы.

Американские инженеры, строившие первые железные дороги в США, действительно ориентировались на английскую, стефенсоновскую колею шириной 1435 мм. В Англии ширина колеи на первых железных дорогах с конной тягой в рудниках и на угольных копях была различной – от 2' до 5'. Наиболее удачно была спроектирована железная дорога Мертир–Тайэфайл в Англии шириной 5', соответствующая колее обыкновенных экипажей. Полагают, что именно она послужила для Джорджа Стефенсона прообразом при строительстве в 1825 г. первой железной дороги Стоктон–Дарлингтон с паровой тягой. Стефенсон сначала предполагал колею шириной 4' 6" (1372 мм), что соответствовало ширине колеи, распространённой на севере Великобритании. Однако при конструировании своего паровоза, чтобы удобнее было разместить паровой котёл, ему пришлось расширить колею на 2,5" (получилась колея шириной 4' 8,5", т.е. 1435 мм). Сейчас такова ширина примерно 75% железных дорог на Земле.

В России при строительстве первой железной дороги Санкт-Петербург–Москва в 1843 г. инженер Мельников предложил расширить стефенсоновскую колею до 5' (1524 мм). Это обеспечивало более удобное размещение механизма паровоза, увеличение объёма его котла, массы груза в вагонах, лучшую устойчивость подвижного состава. Вот и ответ: даже теперь, когда человек вышел в космос, его наивысшие технические достижения напрямую зависят от размера лошадиного крупа, как и две тысячи лет назад.

После очередного старта «Шаттла» корпуса отработавших ускорителей спускаются на парашютах в Атлантический океан, подбираются спасательными судами и буксируются на мыс Канаверал. Затем их отправляют производителю в штат Юта для контроля и заливки топлива. После чего возвращают по железной дороге на мыс Канаверал. Пресс-секретарь НАСА подтвердил, что при проектировании двигателей твёрдотопливных ускорителей «Шаттла» учитывался размер туннеля, по которому они доставляются на пусковую площадку, и, следовательно, размер колеи. Но обратил внимание на то, что туннель имеет два пути, так что в реальности допустимый размер был как минимум вдвое больше.

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

AF>

Пресс-секретарь НАСА подтвердил, что при проектировании двигателей твёрдотопливных ускорителей «Шаттла» учитывался размер туннеля, по которому они доставляются на пусковую площадку, и, следовательно, размер колеи. Но обратил внимание на то, что туннель имеет два пути, так что в реальности допустимый размер был как минимум вдвое больше.

А интересно, пресс-секретарь не говорил, что бы ему сказали железнодорожники в ответ на предложение закрепить многотонную конструкцию на железнодорожной платформе сильно асимметрично относительно оси состава?

Это даже не рассматривая вариант встречнго поезда в момент прохождения туннеля...

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

F>Это даже не рассматривая вариант встречнго поезда в момент прохождения туннеля...

В СССР это рассматривали. У нас предельные цифры такие — 3.9 м без остановки встречного движения, и 4.1 с остановкой. Теперь смотрим на диаметры 1 и 2 ступеней наших тяжелых носителей:
Зенит — 3.9 м
Протон — 4.1 м

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

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

Люминесцентная лампа

Первым предком лампы дневного света была лампа Генриха Гайсслера, который в 1856 году получил синее свечение от заполненой газом трубки, которая была возбуждена при помощи соленоида. В 1893 году на всемирной выставке в Чикаго, штат Иллинойс, Томас Эдисон показал люминесцентное свечение. В 1894 году М.Ф. Моор создал лампу, в которой использовал азот и углекислый газ, испускающий розово-белый свет. Эта лампа имела умеренный успех. В 1901, Питер Купер Хьюитт демонстрировал ртутную лампу, которая испускала свет синего-зеленого цвета, и таким образом была непригодна в практических целях. Это было, однако, очень близко к современному дизайну, и имело намного более высокую эффективность чем лампы Гайсслера и Эллинойса. В 1926 году Эдмунд Джермер и его сотрудники предложили увеличить операционное давление в пределах колбы и покрывать колбы флуоресцентным порошком, который преобразовывает ультрафиолетовый свет, испускаемый возбуждёной плазмой в более однородно бело-цветной свет.

Лампа накаливания

В 1854 г. немецкий изобретатель Генрих Гебель разработал первую «современную» лампочку: обугленную бамбуковую нить в вакуумированном сосуде. В последующие 5 лет он разработал то, что многие называют первой практичной лампочкой.
11 июля 1874 г. российский инженер Александр Николаевич Лодыгин получил патент за номером 1619 на нитевую лампу. В качестве нити накала он использовал угольный стержень, помещённый в вакуумированный сосуд
Английский изобретатель Джозеф Вильсон Сван получил в 1878 г. британский патент на лампу с угольным филаментом. В его лампах филамент находился в разреженной кислородной атмосфере, что позволяло получать очень яркий свет.
Во второй половине 1870-х годов американский изобретатель Томас Эдисон проводит исследовательскую работу в которой он пробует в качестве нити различные металлы. В конце-концов он возвращается к угольному волокну и создаёт лампочку с временем жизни 40 часов. Несмотря на столь непродолжительное время жизни его лампочки вытесняют использовавшееся до тех пор газовое освещение.
В 1890-х годах Лодыгин изобретает несколько типов ламп с металлическими нитями накала.
В 1906 г. Лодыгин продаёт патент на вольфрамовую нить компании General Electric. Из-за высокой стоимости вольфрама патент находит только ограниченное применение.
В 1910 г. Вильям Дэвид Кулидж изобретает улучшенный метод производства вольфрамовой нити. Впоследствии вольфрамовая нить вытесняет все другие виды нитей.
Остающаяся проблема с быстрым испарением нити в вакууме была решена американским учёным Ирвингом Ленгмюром, который, работая с 1909 г. в фирме General Electric, придумал наполнять колбы ламп инертным газом, что существенно увеличило время жизни ламп.

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

F>>Некоторые дизели различаются между собой как ассемблер и C# а между другими разницы меньше чем между C# и Java.

PD>Да, конечно. Но тем не менее дизель есть дизель и не становится от этого ни карбюраторным, ни реактивным двигателем.

И что? Как это отменяет наличие в его конструкции вещей, зависящих от субъективных факторов?
Кстати, помимо дизеля и современных карбюраторных/инжекторных движков есть еще другие типы ДВС. Например двигатель Ванкеля. Все они построены на основе термодинамики и циклов Карно (в том числе и ТРД, и ГТД, и ракетные двигатели), однако смотри сколько различных вариантов их существует.
Еще примеры — у нас традиционно МБР оснащаются ЖРД (только относительно недавно начали всерьез экспериментировать с ТТРД), американцы же использовали ТТРД с самого начала. У нас все АПЛ двухкорпусные, очень часто с двумя реакторами, у американцев однокорпусные с одним реактором. Аэродинамику Бурана скопировали с шаттла, просто потому что не хотели создавать и обкатывать собственную с нуля и тратить на это кучу денег. Р-7, Р-9, Н-1 Королевские используют в качестве топлива керосин, несмотря на то, что объективно мощные движки для НГМД тогда было сделать проще. Сам НГМД используется так широко, потому что его уже производила химическая промышленность для других целей. УРМ-1 у Ангары явно перетяжелен для ее движка, потому что планировалось поставить на нее блок И. Потом от этого отказались, но размер УРМ остался прежним.
Вобщем примеров масса. Заточка под имеющиеся технологии, станки, персонал, и просто заморочки главного совершенно обыденная вещь в инженерной деятельности, промышленное создание программ тут ничем не выделяется.

P.S. Еще пару хороших примеров вспомнил — современное управление автомобилем ввиде руля и педалей, как оказалось, очень далеко от оптимума, просто так исторически сложилось. Совсем близкий к IT пример про раскладку клавиатуры английской. Знаешь откуда такая взялась?

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

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

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

AF>И даже в "чистой и возвышенной" математике используется десятиричное исчисление, и почему? Не потому, что эта основа самая лучшая и удобная. А всего лишь потому, что когда-то первобытные изобретатели придумали считать, загибая свои пальцы

пальцев 10 — следовательно система должна была получиться одиннадцетиричная.
в Вавилоне использовали 60-ричную систему

Автор: reductor
Дата: 16.11.05

.
"дюжина" — намёк на двенадцитиричную систему.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>пальцев 10 — следовательно система должна была получиться одиннадцетиричная.


Концепция нуля появилась намного, очень намного позже.

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

ANS>>пальцев 10 — следовательно система должна была получиться одиннадцетиричная.

AF>
AF>Концепция нуля появилась намного, очень намного позже.

Я тебе на это и намекаю

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Я тебе на это и намекаю

А ты не намекай, а прямым текстом скажи.

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

AF>А ты не намекай, а прямым текстом скажи.

Ладно. Чем ты объясняеш появление 60 ричной системы? Пальцев у человека гораздо меньше.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Ладно. Чем ты объясняеш появление 60 ричной системы? Пальцев у человека гораздо меньше.

Насколько я знаю, происхождение этой системы точно никому не известно. Некоторые считают, что это связано с астрономией. Но это уже отдельный вопрос. То, что 5, 10, 12 и 20-ричная системы имеют анатомическое происхождение — это известный факт. Что подтверждается названиями этих чисел во многих древних языках — "рука", "две руки", "человек" и так далее.
Так что ты не намекай, а лучше соответствующую литературу почитай.

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

AF> То, что /.../ 12 /.../ системы имеют анатомическое происхождение — это известный факт. Что подтверждается названиями этих чисел во многих древних языках — "рука", "две руки", "человек" и так далее.

Не понял?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

AF>>А ты не намекай, а прямым текстом скажи.

ANS>Ладно. Чем ты объясняеш появление 60 ричной системы? Пальцев у человека гораздо меньше.

Двенадцатирукий Шива.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

AF>> То, что /.../ 12 /.../ системы имеют анатомическое происхождение — это известный факт.
ANS>Не понял?

Что говорится в Википедии:

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

Я попробовал — получается!

А вообще почитал — занятная система, надо попробовать серьезно посчитать в 12ричной.

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

S>Вот как раз ассемблер x86, к примеру, очень сложно использовать как универсальный язык. Ну-ка, изобрази мне на нем что-нибудь несложное; к примеру — веб-сервер с формз аутентификацией и персонализацией.

Если использовать встроенный HTTP-стек Виндовса, как это происходит в случае с Дотнетом, объём работ будет сопоставим.

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

AF>И даже в "чистой и возвышенной" математике используется десятиричное исчисление, и почему?
В высшей математике с константами не работают

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


AF>>> То, что /.../ 12 /.../ системы имеют анатомическое происхождение — это известный факт.
ANS>>Не понял?

F>Что говорится в Википедии:

F>

F>Некоторые народы Нигерии и Тибета используют двенадцатеричную систему счисления. Некоторые учёные полагают, что такая система возникала у них из подсчёта фаланг на руке большим пальцем.

F>Я попробовал — получается!

Прикольно. А я то думал это как раз доказательство обратного. А на чем основывают свои догадки "некоторые ученые"? Потому что, без дополнительных фактов (кроме совпадения кол-ва фаланг на четырёх пальцах) это не серьёзно. Что в тибете большим пальцем считают?

F>А вообще почитал — занятная система, надо попробовать серьезно посчитать в 12ричной.

Господа фанаты! читайте про HTTP API

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Прикольно. А я то думал это как раз доказательство обратного. А на чем основывают свои догадки "некоторые ученые"? Потому что, без дополнительных фактов (кроме совпадения кол-ва фаланг на четырёх пальцах) это не серьёзно. Что в тибете большим пальцем считают?

Не знаю как на Тибете, но реально мне так считать показалось довольно удобно — если считать загибая пальцы, до чтобы досчиттаь до 10 нужно уже 2 свободные руки, а тут достаточно одной свободной руки хватает для счета до 12. И при этом вполне удобно получается.

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

F>Не знаю как на Тибете, но реально мне так считать показалось довольно удобно — если считать загибая пальцы, до чтобы досчиттаь до 10 нужно уже 2 свободные руки, а тут достаточно одной свободной руки хватает для счета до 12. И при этом вполне удобно получается.

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

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

F>>а тут достаточно одной свободной руки хватает для счета до 12. И при этом вполне удобно получается.

R>+1
R>Скажу даже, что одной руки хватает для счета до 15, если после 12 указательным пальцем считать фаланги большого пальца.

Ну это уже большее сложные действия Но мысль интересная.
При этом до 3й (или 1й?) фаланги большого пальца дотянуться указательным — очень-очень сложно — она слишком глубоко утоплена

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

F>При этом до 3й (или 1й?) фаланги большого пальца дотянуться указательным — очень-очень сложно — она слишком глубоко утоплена

Уж легче, чем большим до фалангов мизинца

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

F>>При этом до 3й (или 1й?) фаланги большого пальца дотянуться указательным — очень-очень сложно — она слишком глубоко утоплена

R>Уж легче, чем большим до фалангов мизинца

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

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

WH>Я вот легко дотягиваюсь большим до всех фалаг мезинца, а вот указательным поллучается дотянуться только до двух фаланг большого.
+1
А, ну правильно, это я тупость сморозил. Я не совсем фалангу считал Немного упростил (с оптимизировал путь прохождения ) и считал в качестве третьей фаланги подушечку большого пальца — эффект тот же, а так действительно дотянуться тяжело. О, идея, увеличить КПД одной руки можно, если считать и кончики пальцев, сколько там получается... 16 без большого пальца (вот откуда вязлась 16-ая система счисления ) и 19 с большим (нижнюю фалангу не используем из-за трудоемкости), кто больше

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

GN>Господа фанаты! читайте про HTTP API
Не смеши мои тапочки. Возможности HTTP API ничего существенно нового по сравнению с sockets программисту не дают. Ну разрешат тебе встать на 80й порт, что невозможно сделать через сокеты на открытом IISе. Но никто ведь за тебя парсинг запроса не сделает; авторизацию придется писать самому (да-да, весь тот нудный мусор по управлению сессионной кукой и прочими нудными редиректами), а персонализацию ты вообще сделаешь к пенсии своего внука. "Объем работ будет сопоставим". Шутник.

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

S>Не смеши мои тапочки. Возможности HTTP API ничего существенно нового по сравнению с sockets программисту не дают.

Например он даёт HTTPS.

S>Ну разрешат тебе встать на 80й порт, что невозможно сделать через сокеты на открытом IISе. Но никто ведь за тебя парсинг запроса не сделает;

HTTP запросы парсятся АПИ.

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

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

S> "Объем работ будет сопоставим". Шутник.

Если б я хотел пошутить, написал бы "для работы универсального Дотнета может потребоваться 2й сервиспак ОС"

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

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

WH>>Я вот легко дотягиваюсь большим до всех фалаг мезинца, а вот указательным поллучается дотянуться только до двух фаланг большого.
R>+1
R>А, ну правильно, это я тупость сморозил. Я не совсем фалангу считал Немного упростил (с оптимизировал путь прохождения ) и считал в качестве третьей фаланги подушечку большого пальца — эффект тот же, а так действительно дотянуться тяжело. О, идея, увеличить КПД одной руки можно, если считать и кончики пальцев, сколько там получается... 16 без большого пальца (вот откуда вязлась 16-ая система счисления ) и 19 с большим (нижнюю фалангу не используем из-за трудоемкости), кто больше

Загибая пальцы одной руки можно считать до 2^5 = 32. На двух руках уже 2^10 = 1024

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

Сорри, что не ответил. Отсутствовал 2 недели в онлайне.

AVK>Здравствуйте, Pavel Dvorkin, Вы писали:

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

AVK>Люминесцентная лампа
AVK>

Первым предком лампы дневного света была лампа Генриха Гайсслера, который в 1856 году получил синее свечение от заполненой газом трубки, которая была возбуждена при помощи соленоида. В 1893 году на всемирной выставке в Чикаго, штат Иллинойс, Томас Эдисон показал люминесцентное свечение. В 1894 году М.Ф. Моор создал лампу, в которой использовал азот и углекислый газ, испускающий розово-белый свет. Эта лампа имела умеренный успех. В 1901, Питер Купер Хьюитт демонстрировал ртутную лампу, которая испускала свет синего-зеленого цвета, и таким образом была непригодна в практических целях. Это было, однако, очень близко к современному дизайну, и имело намного более высокую эффективность чем лампы Гайсслера и Эллинойса. В 1926 году Эдмунд Джермер и его сотрудники предложили увеличить операционное давление в пределах колбы и покрывать колбы флуоресцентным порошком, который преобразовывает ультрафиолетовый свет, испускаемый возбуждёной плазмой в более однородно бело-цветной свет.

Итак, только в 1926 году появляется нечто, пригодное к практическому использованию. Все предыдущее — лабораторные эксперименты, не более.

AVK>Лампа накаливания
AVK>[q]В 1854 г. немецкий изобретатель Генрих Гебель разработал первую «современную» лампочку: обугленную бамбуковую нить в вакуумированном сосуде. В последующие 5 лет он разработал то, что многие называют первой практичной лампочкой.
AVK>11 июля 1874 г. российский инженер Александр Николаевич Лодыгин получил патент за номером 1619 на нитевую лампу. В качестве нити накала он использовал угольный стержень, помещённый в вакуумированный сосуд
AVK>Английский изобретатель Джозеф Вильсон Сван получил в 1878 г. британский патент на лампу с угольным филаментом. В его лампах филамент находился в разреженной кислородной атмосфере, что позволяло получать очень яркий свет.
AVK>Во второй половине 1870-х годов американский изобретатель Томас Эдисон проводит исследовательскую работу в которой он пробует в качестве нити различные металлы. В конце-концов он возвращается к угольному волокну и создаёт лампочку с временем жизни 40 часов. Несмотря на столь непродолжительное время жизни его лампочки вытесняют использовавшееся до тех пор газовое освещение.

А это произошло во второй половине 1870-х годов. И эти ламочки "вытесняют использовавшееся до тех пор газовое освещение". Т. е вполне практичны (для того времени, конечно).

Разница по времени — 50 лет.

Что и требовалось доказать.

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

PD>Разница по времени — 50 лет.
PD>Что и требовалось доказать.
Доказать требовалось вовсе не это. Ты утверждал, что без создания лампы накаливания неонки не было бы, однако приведенные цитаты свидетельствуют о том что исследования развивались параллельно и независимо. А значит и создание неонки был лишь вопрос времени и собственно наличие или отсутствие лампы накаливания существенно на этот процесс не повлияло...
Точнее повлияло скорее отрицательно, после появления лампы накаливания все сосредоточились на доведении этого способа до ума на другие варианты до поры до времени забили. Так что если бы не было лампы накаливания, неонка появилась бы быстрее.

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

PD>Итак, только в 1926 году появляется нечто, пригодное к практическому использованию. Все предыдущее — лабораторные эксперименты, не более.

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

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

П>>В случае с VB и C#, VB позволяет делать меньше телодвижений при написании ПО

V>А можно конкретные примеры снижения телодвижений.

Coding Horror: C# and the Compilation Tax

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

V>>А можно конкретные примеры снижения телодвижений.

no4>Coding Horror: C# and the Compilation Tax

The second is the C# compilation tax. When working in C#, I'm constantly compiling the solution to ensure that I haven't broken anything. It's a ridiculous productivity tax in an endless loop: Write some code. Compile. Write a little more code. Compile. Change a function. Compile. Rename a variable. Compile. Refactor some methods. Compile. Then compile again, just to be sure. Wait a second.. did I compile this yet? Compile!

Ужас просто

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

no4>>Coding Horror: C# and the Compilation Tax

AVK>

The second is the C# compilation tax. When working in C#, I'm constantly compiling the solution to ensure that I haven't broken anything. It's a ridiculous productivity tax in an endless loop: Write some code. Compile. Write a little more code. Compile. Change a function. Compile. Rename a variable. Compile. Refactor some methods. Compile. Then compile again, just to be sure. Wait a second.. did I compile this yet? Compile!

Ну привык человек к хорошему, правда про решарпер в комментах ему уже сказали.

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

no4>Ну привык человек к хорошему, правда про решарпер в комментах ему уже сказали.

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

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

AVK>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Итак, только в 1926 году появляется нечто, пригодное к практическому использованию. Все предыдущее — лабораторные эксперименты, не более.

AVK>Ты чуть далбше читай. "Это было, однако, очень близко к современному дизайну". Т.е. та самая случайность — на тот момент у известных люминофоров был неподходящий цвет — и привела к тому, что люминесцентные лампы стали использовать позже. А если бы тот люминофор, что использовал Хьюитт, давал бы более приемлемую окраску?

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

Вдогонку...

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