С чего лусше начать, потом продолжить и т.д.
 

Вот я например искренне хочу изучать(или хотябы понять что смогу, но вроде слабоумием и невосприимчивостью к чемуто новому не отличаюсь) языки програмирования. Подскажите плиз с чего лучше начать новичку и т.д. (Только не надо плиз обьяснять как пользоваться мышкой и т.д. это я уж както сам разберусь :-D ), я имею в виду литературу, если не трудно выложите ссылки ссылки. Вот сейчас нашел литературу по Ассемблеру(хз по русски так звучит или нет), изучаю, а стоит или нет? Мож с чего другого нада начинать? Буду благодарен любой информации. И еще, ппц, установил висту и через некоторое время перестал работать Enter(причем оба), мож я кудато нажал, подскажите кто знает, первый раз с вистой общаюсьеще не успел освоиться. Заранее всем благодарен, надеюсь не проигнорируете.

Для начало б уяснить, какая конечная цель поставлена в программировании? Начать то можно с чего угодно. ;) А вот чего хочется достичь в конце? Отсюда и пойдут реперные точки. А вот про висту не скажу, спм под ХР и линуксом.

Да я сам пока затрудняюсь к чему хочу прийти, просто интересно для себя. Поэтому и прошу совета. А к чему вообще можно прийти?:d

Смотря какой путь выбрать. В принципе при желании можно и до тюрьмы дойти. ;) И тем не менее сначала надо определиться в конечной цели. Если просто поюзать, а есть подозрение что именно так и есть, путь годится любой, приемлемый и понятный. С чего начать? Ну как правило, чтоб научиться читать - учат алфавит, и от этого никуда.

http://www.intuit.ru/department/pl/vbnet/
Что касается начинаний :)

Типа мне курсы по бейсику предложил? ;)

хм... бэйсик?...

имхо лучше С, С++ или Java...

Я дал тебе ссылку на курс лекций по VB.NET. Не думаю, что это плохая срда разработки. Но на сайте немерено курсов, так что выбирай сам :)

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

"... и я, и я, и я того же мнения" (с) ослик Иа из м\ф Винни-пух ;d

уж точно не Биллу Гейтсу учить программированию
и не нам учить его делать бизнес

Ваще то запрос "с чего начать" делал некто sokol (см. первый пост) ;d И как раз недавно в баше был форвардинг в эту тему:
1. Посоветуйте мне лучшую среду для java программирования.
2. Для java программирования среда на следующей неделе обещает быть самой лучшей.
За точность цитаты не ручаюсь, но смысл такой...
По поводу выбора действительно трудно сказать, кроссплатформа, она и в африке...

А зря не ему, он стока ДОСов написал В)) Про винду я молчу - он не большое внимание в её написании принимал, а вот в написании досов принимал непосредственное участие, и ничего так, неплохие были системы. ФАТ до сих пор быстрей НТФС, правда со стабильностью не так сильно. Ладно, не будем поднимать священных войн, просто софт от масофта самый распространённый и это уже о чём-то говорит.

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

С трёхтомника Кнута В)
И позвольте увести разговор немного в другую степь: а Вы знаете такую ФС, где нет фрагментации?
Хотя... работа GC похожа на такую ФС. В) Только это уже всё равно дефрагментатор.

В-) Данная тема есть в Программисты шутят. В)

А вот позволю не согласиться. Каталог на NTFS представляет собой файл, хранящий ссылки на другие файлы и каталоги, создавая иерархическое строение. Файл каталога поделен на блоки, каждый из которых содержит имя файла, базовые атрибуты и ссылку на элемент, который уже предоставляет полную информацию об элементе каталога. Внутренняя структура каталога-бинарное дерево. Для поиска файла с данным именем в линейном каталоге, таком, как у FAT-а, системе приходится просматривать все элементы каталога, пока она не найдет нужный. Бинарное же дерево располагает имена файлов таким образом, чтобы поиск файла осуществлялся с помощью получения двухзначных ответов на вопросы о положении файла. Вопрос, на который бинарное дерево способно дать ответ, таков: в какой группе, относительно данного элемента, находится искомое имя - выше или ниже? Мы начинаем с такого вопроса к среднему элементу, и каждый ответ сужает зону поиска в среднем в два раза. Файлы, скажем, просто отсортированы по алфавиту, и ответ на вопрос осуществляется очевидным способом - сравнением начальных букв. Область поиска, суженная в два раза, начинает исследоваться аналогичным образом, начиная опять же со среднего элемента. Вывод - для поиска одного файла среди 1000, например, FAT придется осуществить в среднем 500 сравнений (наиболее вероятно, что файл будет найден на середине поиска), а системе на основе дерева - всего около 12-ти (2^10 = 1024). Экономия времени поиска налицо.

Народ, я решил попробовать себя в С#, можно пытаться начать с него не зная никаких других языков(кроме русского конечно :d )? Если да, то дайте плиз скачать Visual Studio .NET, и кстати, он на висте пойдет? Если нет то если вкорячить и висту и ХР они конфликтовать не будут?

для фата
reiserfs
а в ext3 фрагментация не превышает 3-5% самый максимум
http://www.ylsoftware.com/?action=ne...wfull&news=379
вот тут расписано
для меня 3-5% не имеют большого значения по сравнению с 42%
потому я и не принимаю ее в расчет

у меня в ДЦ расшарен VS 2008. качай
на висте идет без проблем
ник в ДЦ LiMoN

Не дефрагментируемых ФС не существует. Мне кажется вопрос надо поставить немного под другим углом. Какая ФС при одинаковой степени дефрагментации страдает от этого меньше чем другие.

А Вы дочитали процитированную статью до конца? ТАм было чётко написано, что современные (а статья была написана в 2000 году) средства ДОС свели на нет разницу между процессом поиска файлов в каталоге.

Вот уж не знаю почему (не разбирался), но натурные измерения копирования файлов показывают, что на ФАТ32 оно выполняется в среднем на 10-12% быстрее.

Вот это как раз в точку. И как раз НТФС страдает от фрагментации опупенно. Хотя опять же, информация давно минувших дней, может быть сейчас что-то уже изменилось.
Кстати, может кто поделиться ссылочкой, где можно почитать, почему на *никс системах такая низкая фрагментация? Осмелюсь предположить, что там в саму ФС встроен алгоритм дефрагментации перед записью. Т.е., если надо записать какой-то файл, ищется ближайшее свободное место (возможно в какой-нибудь карте) и затем расширяется с помощью переноса обрывков влево и вправо до очистки необходимого места.
И кстати, не совсем понятно о какой фрагментации идёт речь: о физической или о логической?

www.google.com Вам в помощь
з.ы. а вот фрагментация на одном из моих разделов
вот поэтому во внимание ее я и не принимаю

Чисто из практики могу сказать, что при размере диска выше 20гиг, НТФС работает быстрее. Хотя тоже спорный вопрос, смотря какими средствами тестить и какие критерии брать для оценки.

Да тут наверное ссылка бесполезна в какой то мере. Я пробовал и не нашёл исчерпывающего ответа. Для любителей поанализировать, наверное надо погуглить приемлемый для своего понимания материал по ext FAT NTFS, почитать, сесть и сравнить..ИМХ однозначного ответа всё равно не будет. НЕТ идеальных ФС! У каждой свои плюсы и минусы и смотря с какой стороны подойти, то минусы одной, могут стать плюсами другой. ФС надо выбирать из круга решаемых задач с целью получения максимальной пользы и минимальной потери!

Тестировал на двух одинаковых разделах по 250 Гигов на рейде. Источником был рам-диск.

Последнее предложение абсолютно в точку, как в прочем и остальной пост. В)
И так, мы плавно возвращаемся в русло начатой темы: Начинать лучше с того, что ты хочешь делать, каждый язык хорош для чего-то одного: С++ для ресурсоемких приложений, Паскаль для рапид-программинга, васик - побыстрей выучить (хотя спорно уже сейчас) - C# - вот тут хз, похоже это замут на будущее - имхо CLR будет в будущих версиях винды работать в ядре и работать очень не медленно.

Извиняюсь, но не показатель. Для чистоты эксперимента должно быть одинаковое количество_одинаковых файлов_задач_операций_циклов конвеера ..нельзя скинуть со счёта специфику работы скази и организацию работы RAID..етс. Но вообще то в этой теме пора ставить точку. :-/ Мы с этим копанием уходим в цикл. Я не апологет какой либо ОС или ФС. Исхожу из существующих реалий и круга решаемых задач. Примерно поровну работаю как в винде, так и в линуксе..как на работе, так и дома. Отречься от чего то не пытаюсь, т.к. всё существующее есть объективные реалии и их надо принимать де-факто. Не в тему, но тем не менее бувально как вчера прочёл на каком то форуме. Один виндусятник говорит, что настроил загрузку системы за 28 секунд, другой ему вторит, типо - КАК? Я, мол, как не бился, не смог настроить загрузку меньше чем за 32 секунды! Колись, как сделал! :yahoo: Далее у них следовал 5-ти дневный тред по этому вопросу!! ..мне показалась, что аудитория форума слушала их базар с интересом и благоговением. ;)

Мысленно аплодирую!

А чем закончилось-то? В)

;) Темы такого рода не заканчиваются. Они живут вечно. Это как Жванецкий про ремонт сказал: Ремонт закончить нельзя, его можно только прервать.

Кошерный путь, с которого начинают "правильные" программисты, это книжка SICP (Structure and Interpretation of Computer Program) и язык, соответственно, Scheme.

Книжка, как и несколько реализаций Scheme, доступны бесплатно.

Эх-ма, не хотелось встревать изложением достаточно длинного содержания, да больно тут уж безапеляционные и однозначные ответы/советы. Поостерёгся бы я давать такие. ИМХО начинать следует с shell. Поскольку в мире имеется огромное количество программ, из которых, как из кирпичиков, с помощью более или менее сложного скрипта можно быстро и просто построить решение чуть не любой задачи - для большинства пользователей этим можно и закончить. C/C++/Java допустимы для тех, кто активно интересуется вопросом. Им тогда в придачу архитектуру надо учить (и чуточку ассемблера), или соответственно практику написания ООП-кода во избежание типичных грабель этих индустриальных языков. По любасу понять ООП программирование проще тому, кто уже понимает, что такое процедурное программирование, а из процедурных языков C самый ходовой, и не по историческим причинам. Особенно легко и приятно не думать на С, который тоже не думает за человека, а потом долго удивляться, а чего это программа в корку падает, куда память утекает, почему в файл вместо данных кракозябры пишутся, почему "мой-наикрутейший-собственноручно-написанный-вебсервер-сломали". Это не отменяет единое для всех языков программирования свойство, что чтобы писать хорошие программы надо это делать умеючи. С - язык не для обучения программированию. Совсем наоборот. C отличный язык, чтобы изучать программирование. Он требует понимания того, как работает машина. Машинного мышления, если хотите. Натурально, любой директивный язык гомоморфен машине им. фон Неймана. Включая, кстати, стандартный язык оболочки ОС. Изучение синтаксиса, это 100 страниц. А понимание, как правильно писать программы - тысячи страниц. И более того, понятие "научиться программировать" обычно по неграмотности ужимают до процесса написания кода на каком-либо языке программирования. Мне кажется в данном контексте "с чего начать", преследует именно эту цель!!
Если действительно хочется научиться, то надо:
1) Научиться делать постановку задачи. Понимать, ЧТО именно мы хотим получить на выходе.
2) Научиться системно подходить к решению задачи. (Определение системы: "Система - совокупность взаимодействующих между собой подсистем. Каждая подсистема является системой") Т.е. уметь разбивать задачу на подзадачи. Построить общий алгоритм решения.
3) Научиться выбирать для решения каждой из задач наиболее эффективный инструмент (наконец-то дошли до выбора языка программирования)
4) Научиться грамотно пользоваться выбранным инструментом.
5) Научиться контролировать процесс каждого из этапов, выявлять возможные ошибки заранее ("чувствовать, где могут лежать грабли"). Проштудировать "Законы Мэрфи" ;-)
И не надо тут говорить, что существуют какие-то специальные языки, которые подходят для обучения, а какие-то другие - не подходят. Все это чушь. Учиться программированию следует на том инструментарии, который больше годится для практической работы, а не на каких-то идеальных сферических конях.

Веб-дневник Владимира Шабанова 2007
SICP: Впечатления от прочтения

SICP — это не учебник по Lisp, это книга по Программированию. Если вы просто хотите изучить Lisp или Scheme, то SICP не для вас, лучше попробовать что-нибудь попроще. Книга стала одним из самых интересных и серьезных текстов, прочитанных мною за последнее время. После книг Кернигана и Ритчи, Страуструпа, книг по OCaml, Haskell, кучи тьюториалов, мануалов, статей и прочей литературы, SICP стала для меня чем то вроде откровения о том, какой должна быть книга по программированию. Книга действительно предназначена для первокурсников. Она не требует никаких предварительных знаний по программированию. В отличии от обычных книг, SICP не учит синтаксису (его у лиспа почти нет), а учит базовым вещам, необходимым для понимания того, как надо программировать. Причем, выбор этих базовых вещей и уровень их объяснения поистине шедеврален. Уже на 20-й, 30-й странице мы узнаем о нормальном порядке вычислений, lexical scoping, рекурсивных и итеративных процессах, функциях высших порядков, lambda-выражениях, замыканиях и прочих вещах, о которых я узнал гораздо позже, чем надо. А к концу второй главы знаний хватает на то, чтобы писать 90% встречающегося кода. И мы еще не дошли до изменяемого состояния, модулей и объектов! И вот мы доходим до модулей, объектов, потоков, параллелизма, распространения ограничений. Вы думаете, сейчас вам будут рассказывать, как пользоваться готовыми фреймворками или специально заточенными элементами языка программирования? Фигушки! Вам объяснят, как это сделать с нуля, из тех самых базовых кирпичиков, изученных в первых двух главах. Ничего больше не нужно! Это потом, в других языках (или на следующем курсе), вы увидите, как это можно сделать короче и запутаннее. Сейчас вы должны понять основы, как это сделать самому. И что самое приятное, все это сопровождается общими объяснениями, жизненными примерами и интересными упражнениями.
Теперь, казалось бы, мы знаем основные методики программирования. Только этого мало. Для лучшего понимания процесса вычислений нам надо построить несколько интерпретаторов: самой Scheme, схемы с ленивыми вычислениями, с недетерминистским вычислением, а также интерпретатор для среды логического программирования. Четвертая глава вам в этом поможет.
Что, скилл в вычислениях прокачан и карма аж светится? Но ведь вы все это время были далеки от железа и не знаете, как все это работает уровнем ниже Scheme! Тут то (в заключительной главе) вам и расскажут про регистровые машины, даже парочку-троечку спроектируют. Чтобы было на чем их проверять, вам опишут имитатор регистровых машин. Вы узнаете про стек. Вам расскажут про сборку мусора (и конечно покажут, как ее сделать с нуля ;). Чтобы прокачать понимание регистровых машин, вы напишете интерпретатор Scheme на своеобразном ассемблере. Но ведь интерпретатор — это медленно, надо написать компилятор! А компилятор сам по себе не очень удобен (нет интерактивной разработки), так что скрестим его с интерпретатором. Страшно? Ничего, ребята действительно хорошо все объясняют.
Вот теперь, дочитав до конца, я по-настоящему пожалел, что не прочел эту книгу раньше, до бейсика, паскаля, с, асма, с++, окемла, лиспа, пролога, эрланга, хаскела и др. Еще в первой половине списка я начал находить много общего, потом уже я узнал про императивное, функциональное, логическое программирование, посылку сообщений и т.д. Примерно понимал и устройство компа, знал что такое интерпретаторы, компиляторы и их помеси. Но, черт возьми, это все было от деталей к туманному общему, а не наоборот, от разжеванного общего к деталям на практике.

Выводы

Если Вы только начинающий программист, SICP обязательна к прочтению. Многие вещи, которые Вы будете изучать потом, будут казаться Вам знакомыми.

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

Кому интересна книга забирайте в ДС, в формате pdf. Ну и библиографическая редкость! Едва, едва отрыл на просторах инета. ;) Итак читаем sicp.pdf

ЛОР, опрос про любимый язык программирования:

anonymous: "Давайте представим аналогичный опрос скажем, на форуме врачей:

какой ваш любимый инструмент ? -скальпель рулит! -нифига, скальпель только лохи юзают, вот градусник - сила!! -да все отстой, за горчичниками будущее...." (С) баш

Ещё одно. Я прочитал, весьма интересна.
http://second.udomlya.ru/uf/showpost...3&postcount=29

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

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

Аналогичные впечатления, добавить нечего...

В личке довольно долго обсуждали тему с человеком, сложившееся в результате этого мнение решил форварднуть сюда. ИМХО, чтобы на РНР писать программы, а не решето из дыр, квалификация должна быть довольно высокая. Здесь лучше начать с Ruby и/или Python. Если надо получить краткий обзор языка плюс какие-нибудь ссылки по нему, я обычно смотрят на http://ru.wikibooks.org
Чтобы "въехать" – лучше купить бумажный букварь. Для начального обучения, это предпочтительнее онлайновых руководств. Поскольку речь идет о Web-программировании - прежде чем изучать какой-либо язык динамического создания страниц - НЕОБХОДИМО в совершенстве изучить язык их разметки - HTML. К примеру:
- Е.В. Мальчук - HTML и CSS
- Н.Н. Куссуль - Использование PHP
Годятся и любые другие, только не брать слишком толстые - поскольку основное назначение таких книг - дать быстрое начальное введение и основные понятия, а вот уже в качестве справочника удобнее использовать онлайновые руководства. И ещё пара книг: "Разработка Web-приложений на Php и MySQL" - книжка очень полезная, в ней рассматриваются возможности языка и не отдельно только они, но и совместно со всякими вспомогательными инструментами, которые просто не могут не пригодится разработчику интернет приложений. И вторая книга "PHP глазами Хакера" - в ней очень кратко, но довольно доходчиво разъясняются основные ошибки программиста и методы взлома соответственно.

Попалась на глаза старая тема....решилось уточнить вдруг. :)
Как мне кажется, выбор языка важен только в том случае, если планируется сразу после обучения подключиться к какому-нибудь реальному проекту.
Если же это не предвидится, то следует выбирать из языков, которые:
1) хорошо известны тому, кто реально будет учить, чтобы учитель не попадал в неловкое положение от того, что он не только не знает каких-то вещей, но и слабо ориентируется в справочных материалах по выбранному языку. Это в случае поддержки со стороны, ибо твёрдо убеждён, что высказываемые желания поучится/научиться программированию при отсутствии гуру просто фикция. Самому с нуля научиться - практически не реально. (никогда не верю тем, кто подобное говорит)
2) хорошо воспринимаются конкретным человеком в силу его психологических особенностей:
одни лучше усваивают избыточное и более приближенное к естественному языку (Модула, паскаль, бейсик). другие - схематичные языки вроде С/С++, третьи - нечто промежуточное вроде Fortran.

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

Единственное, что действительно имеет смысл учесть при выборе базового языка и среды программирования для начала обучения, это либо максимальная абстрактность этого языка, либо кроссплатформенность, чтобы не привязывать к конкретной среде разработки (в наиболее общем смысле, от ОС до языка), если, конечно, это не натаскивание под конкретную задачу..

Ааааа...я не умею программировать.....suicide.

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

Я не претендовал на истину в первой инстанции, это некие, чисто субъективные мысли вслух, чтоб популярно изложить видение вопроса, так как сам понимаю его смысл. :) И судя по реакции, тот кто понимает о чём речь, думают примерно так же. На мой взгляд, сейчас очень много развелось "программистов", которые на вопрос: На чём пишешь? Бойко отвечают, что дескать он и на перле, и на питоне, и на РНР (ещё пяток может следовать). Но что-то никто не видел от таких хотя б несколько сот страниц кода. В лучшем случае десяток строк в bat или cmd, и ещё аляповато состряпанный сайт, обязательно с гостевухой, в которой непременно есть записи - Клёво, "Витёк". Так держать! Отличный сайт!...и прочее. :) Да ещё чтоб "белый" IP, да чтоб в инете видно было. К сожалению подобный "набор" стал являться мерилом квалификации, а ещё обиднее, что едва научившись всё это делать, человек дальше не идёт. Ну да это тоже мысли...и никому не в обиду.

Аналогично квоту. Но хотел бы свои пять копеек. Я согласен с Мессиа, что без хорошего живого учителя-гуру очень тяжело, ответы на некоторые элементарные вопросы приходится искать по различным форумам, факам, даташитам и т.д. Дело в том, что профессиональные программисты (тех, которых я знаю) постоянно следят за периодикой, и проскальзывающие там "золотые мысли" обязательно копипастят или хранят в голове (есть такие, у которых память потрясающая).
Например, столкнулся недавно с такой проблемой (расскажу, раз уж тема про программирование): мне потребовалось на ноге TxD порта RS232 держать постоянно неактивный уровень, т.е. +12 В. Делал я это в С# и спользование стандартного компонента (неплохо работает, кстати). Первая мысль была (я почему-то так и думал, что все так делают): посылать постоянно посылку их 0x00, но вот одна незадача: посылка всегда заканчивается стоп-битом (лог. 1 =-12 V, в результате получается не 12В, а 9.8В), а поставить 0 стоповых бит почему-то нельзя. Долго гуглил, лазил по всяким форумам, долго пасся на CodeProject, нигде ответа не нашёл. Уже в четвёртом часу ночи решил поискать исходники программатора, к моему величайшему удивлению, нашёл сорцы под линукс одного из программаторов, долго ковырялся по нему и наконец нашёл это простейшее решение (меня долго удивляло, что он делает это действо всего одной строчкой, никак не мог понять почему). Выяснилось, из-за моего неточного понимания работы порта RS-232 я и не смог найти решение. Дело в том, что режим IDLE в RS-232 - это высокий активный уровень, т.е. -12 В, но есть такой режим - BREAK, это когда на шине устанавливается низкий активный уровень больше чем на один фрейм, т.е. - имеется возможность напрямую управлять пином TxD. Потребовалось всего 1 строчка:
и всё. Вот так вот один вопрос знающему человеку смог бы сэкономить мне около 8 часов жизни. В)

ЗЫ. забыл сказать, первая реазилация этой задачи занимала порядка 30 строк с выделением дополнителного буффера и созданием отдельного потока, который постоянно пихает 0x00 в порт. В) А ведь есть программы, разработчики которых не стали заморачиваться и остановились на подобном решении, а мы потом спрашиваем, почему это компьютерные программы тормозят всё больше и больше.

Таким примерам несть числа, а способность человека разобраться в ситации и решить её, это отдельная тема для разговора, и программирование для этого подходит как нельзя лучше. Я как-то писал о квалификации "железячников", в которой есть 2 реперные точки. Траблешутер - высшая квалификация человека способного разобраться в ЛЮБОЙ проблеме и решить её...и хелп деск - человек объясняющий секретарше назначение ярлыков на рабочем столе. Точек то две, но между ними бездна. :)