Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2007.12.02;
Скачать: [xml.tar.bz2];

Вниз

смогу ли я быть программистом   Найти похожие ветки 

 
Валентин   (2007-10-25 14:19) [0]

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


 
clickmaker ©   (2007-10-25 14:27) [1]


> утечки памяти

главное - представлять, при каких условиях эти утечки могут возникать. И не допускать


 
SerJaNT ©   (2007-10-25 14:30) [2]


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


сможешь. Главное - желание, а остальное придёт с опытом...


 
БарЛог ©   (2007-10-25 14:33) [3]

Валентин   (25.10.07 14:19)  
Не любишь, потому что не понимаешь. Научат - полюбишь :) Удачи!


 
KSergey ©   (2007-10-25 14:34) [4]

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


 
KSergey ©   (2007-10-25 14:36) [5]

Впрочем у меян сильное подозрение, что я не понимаю что автор подразумевает под словами "утечки памяти". Т.е. какое действие с его стороны его в этом напрягает?


 
Dib@zol ©   (2007-10-25 14:41) [6]

> [0]
Нет. Знаю по себе. Например, попробуй извлеки из TrueType-шрифта векторное изображение символа с помощью GetGlyphOutline, без работы с указателями и теми самыми байтами и смещениями.
ЗЫ Программистом-то ты станешь, но вот что сильно хорошим - вряд ли...
ИМХО ИМХО ИМХО ИМХО ИМХО ИМХО ИМХО


 
Skier ©   (2007-10-25 14:46) [7]

Нефтью выгодней заниматься...:)


 
Ega23 ©   (2007-10-25 14:48) [8]


> изучать ООП

и

> байты, смещения, утечки памяти и т.д.

не вяжется друг-с-другом.


 
БарЛог ©   (2007-10-25 14:48) [9]

> Нефтью выгодней заниматься...:)
Только ее всё меньше, а людей всё больше :)

Архитектированием зданий тоже неплохо заниматься! :)


 
Jeer ©   (2007-10-25 14:50) [10]


> Ega23 ©   (25.10.07 14:48) [8]
>
>
> > изучать ООП
>
> и
>
> > байты, смещения, утечки памяти и т.д.
>
> не вяжется друг-с-другом.


У ООП есть нутрь, там и размещаются байты, смещения, утечки, etc


 
Cerberus ©   (2007-10-25 14:54) [11]

Всё придет главное это желание двигатся вперёд. Сам чем сложнее задачи будут тем будет глубже твои познания. Главное помнить что в программировании возможно всё.


 
ocean ©   (2007-10-25 14:57) [12]

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


 
Юрий ©   (2007-10-25 15:00) [13]

> [0] Валентин   (25.10.07 14:19)

Смогу ли я быть великой балериной? Видимо уже нет...


 
Skier ©   (2007-10-25 15:38) [14]


> Только ее всё меньше, а людей всё больше :)

Есть мнение что нефть - возобновляемый ресурс. :)


 
Ditrix ©   (2007-10-25 15:45) [15]

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


 
Anatoly Podgoretsky ©   (2007-10-25 15:47) [16]

> Skier  (25.10.2007 15:38:14)  [14]

Купил по 1х100, продал по двести - купил по 2х100 и так далее.


 
isasa ©   (2007-10-25 15:52) [17]

Skier ©   (25.10.07 15:38) [14]
Есть мнение что нефть - возобновляемый ресурс. :)


:)

Возможно. Но перед этим все кто ее потребил должны хорошенько разложиться.


 
Ega23 ©   (2007-10-25 15:54) [18]


> У ООП есть нутрь, там и размещаются байты, смещения, утечки,
>  etc


Я об этом и говорю. Может не совсем понятно выразился.
Ибо - http://delphimaster.net/view/2-1193307134/  пост [16] :)


 
Ega23 ©   (2007-10-25 15:55) [19]


> Купил по 1х100, продал по двести


И вот на эти 2 процента и живу...   :)))))


 
Anu   (2007-10-25 16:06) [20]

История одного байта

http://www.wasm.ru/article.php?article=onebyte


 
vpbar ©   (2007-10-25 16:20) [21]

В принципе это тебе не помешает стать хорошим программистом и писать на lisp, ml, ruby, perl, php, c#
Но чтобы программировать более низкоуровнывые вещи - с указателями надо разобраться.


 
Dib@zol ©   (2007-10-25 16:21) [22]

> http://www.wasm.ru/article.php?article=onebyte

О, это мегарульная весчь! Между прочим, побудила меня на изучение асма!


 
vpbar ©   (2007-10-25 16:34) [23]

>>Dib@zol ©   (25.10.07 16:21) [22]
А меня изучение асма наткнуло на это мегарульную вещь.
А асм начал изучать чтобы в корсаров поиграться.
Вот такие извилистые пути.


 
Рамиль ©   (2007-10-25 16:52) [24]

До сих пор никак в толк взять не могу, что такого страшного в указателях?
Почему их боятся?


 
isasa ©   (2007-10-25 16:59) [25]

Рамиль ©   (25.10.07 16:52) [24]

Потому, что ты их не видишь, а они есть! :)


 
Ins ©   (2007-10-25 17:06) [26]


> До сих пор никак в толк взять не могу, что такого страшного
> в указателях?
> Почему их боятся?

Вроде бы у Спольски было что-то на тему: "у некоторых людей отсутствует часть мозга, ответственная за указатели"...


 
vpbar ©   (2007-10-25 17:08) [27]

Многие программисты на Си просто не знают, как заставить работать указатели. Я, как правило, не отказываюсь от кандидата из-за отсутствия у него какого-то навыка. Однако я обнаружил, что понимание указателей в Си — это не навык, а способность. В начале первого курса на факультете кибернетики набирается человек 200 вундеркиндов, писавших в четырехлетнем возрасте игрушки для Atari 800 на BASIC"е. Они хорошо проводят время, изучая Паскаль, но в один прекрасный день профессор заводит речь об указателях, и они внезапно перестают понимать. То есть абсолютно. 90% потока переходит на отделение политологии, обьясняя это тем, что на кибернетике мало симпатичных студенток. На самом же деле, по неизвестной причине часть человечества просто рождается без того отдела мозга, который понимает указатели. Указатели — это не навык, а способность, требующая особого мышления, и некоторые люди им просто не обладают. (с)  Джоэла Сполски , кажется


 
Ins ©   (2007-10-25 17:14) [28]


> vpbar ©   (25.10.07 17:08) [27]

Да уж, мысли сходятся... Не к добру... :)


 
vpbar ©   (2007-10-25 17:26) [29]

>>Ins ©   (25.10.07 17:14) [28]
Ну почему же не к добру.
Глупостей много - истина одна.


 
@!!ex ©   (2007-10-25 17:42) [30]

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

P.S.
Сам стал лучше понимать. ;)


 
crux   (2007-10-25 17:44) [31]

@!!ex ©   (25.10.07 17:42) [30]

Указатели на указатели на указатели понимаете?


 
@!!ex ©   (2007-10-25 17:48) [32]

> [31] crux   (25.10.07 17:44)

А в чем проблема? Указатель явялется такой же переменной, которая занимает место и хранится в памяти по какому то адрему. Где проблема?
Единственно Дельфи мешает нормальному пониманию указателей в слиу того, что позволяет в ряде случаев работать с указателем как с обычной переменной. Например:
var
 Point:^TVector;
begin
 Point.X:=0;
 Point.Y:=0;
 Point.Z:=0;
end;

И это компилится и работает...
Так всетаки Point - указатель или переменная типа TVector?????
Нипанятна.. Это сбивает начинающих очень сильно, т.к. не логично.


 
crux   (2007-10-25 17:50) [33]

@!!ex ©

А на что может указывать указатель на указатель в случае указателя на указатель на указатель. А на что указатель может указывать?


 
KSergey ©   (2007-10-25 18:05) [34]

> @!!ex ©   (25.10.07 17:48) [32]
> var
>  Point:^TVector;
> begin
>  Point.X:=0;
>  Point.Y:=0;
>  Point.Z:=0;
> end;
> И это компилится и работает...
> Так всетаки Point - указатель или переменная типа TVector????? Нипанятна..

Очевидно, что это указатель на тип TVector.
Однако я не понял подвоха примера.
В смысле вас удивляет что это работает или что допускается применять точку к указателю без расыменования?


 
KSergey ©   (2007-10-25 18:06) [35]

> crux   (25.10.07 17:50) [33]
> А на что может указывать указатель на указатель в случае
> указателя на указатель на указатель.

на что угодно!
Я никак не пойму в чем вопрос-то? Ровно на то и указывает, на что вы называете.


 
crux   (2007-10-25 18:15) [36]

KSergey ©   (25.10.07 18:06) [35]
а вот и нет, он содержит то, что я называю, а указывает он на другое.


 
AlexanderMS ©   (2007-10-25 18:37) [37]


> Я учучь в школе. Скоро мне предстоит сделать выбор профессии.
>  Я увлекаюсь программированием. Мне очень нравится создавать
> алгоритмы для решения той или иной прикладной задачи, быть
> архитектором своих программ, изучать ООП.

Это ко мне тоже относится, поэтому эта ветка мне также интересна.
Есть вопросы, которые, возможно интересуют и автора ветки. Вот, к примеру, есть 8 программистов. Ниже - "резюме" каждого из них:
1) Знает Delphi только со стороны VCL, не разбираясь и не вникая в указатели, работу с памятью и т.п., т. е. создающий самые простые программы.
2) Знает Delphi только со стороны VCL, но включая указатели, работу с памятью и т.п.
3) Работает с базами данных в Delphi, не владея работой с памятью, указателями и т. п (по-моему, это не обязательно для этого случая).
4) Свобоно пишет без VCL на WinApi в Delphi.
5) Может всё вышеперечисленное.
6) Имеет опыт в разработке игр и работе с графикой OpenGL или DirectX.
7) Спокойно пишет на ассемблере, и не только в Delphi (WASM, TASM, к примеру).
8) Владеет знаниями по написанию драйверов, сервисов, знает ассемблер, в общем, самый "крутой" и "глубоко пробравшийся в ОС".

Меня интересуют следующие вопросы:
- Степень востребованности каждого;
- Средняя заработная плата каждого из вышеперечисленных.
- Кого сейчас больше?


 
Ппш   (2007-10-25 18:39) [38]

Валентин, ты можешь стать тем кем захочешь!
Главное не хоти стать - милиционером, космонавтом или пивицей. :)


 
AlexanderMS ©   (2007-10-25 18:40) [39]


> Валентин, ты можешь стать тем кем захочешь!
> Главное не хоти стать - милиционером, космонавтом или пивицей.
>  :)


Поддерживаю.


 
KSergey ©   (2007-10-25 18:41) [40]

> crux   (25.10.07 18:15) [36]
> а вот и нет, он содержит то, что я называю, а указывает он на другое.

Вопрос был "на что указывает"
При чем тут "что содержит"??


 
KSergey ©   (2007-10-25 18:46) [41]

> AlexanderMS ©   (25.10.07 18:37) [37]

А пошукать вакансии в тырнете - не умеем?


 
hahol_64_rus   (2007-10-25 18:47) [42]

всем привет тут вот читаю ваше обсуждение и четт тоже захотелось поучастовать
Рас тут все такие профи то раскажите пжалста как им стать (програмистом)
Стать та я им стану, но вот каким и как быстро
Мошть кто подскажете какунть литературу
осбенно хочу шоб советы были в области баз данных и ассемблера
всем пасибо


 
KSergey ©   (2007-10-25 18:48) [43]

На сайте Подгорецкого есть уроки его авторства.
И на Королевстве от ЮЗ.


 
hahol_64_rus   (2007-10-25 18:56) [44]

а что если мне интересна литература не в электронном виде
просс мне не очень хочется ломать зрение уставив свои глаза в жк
да и чет мне как - то луче усваиваца сидя в кресле  
или в автобусе(прос 2 раза в день езжу на тренировку)
так  мошть подкинете инфы по (Fireberd, Delphi и ассемблеру )


 
Zeqfreed ©   (2007-10-25 18:56) [45]

Хочу видеть живьем человека, который «не понимает указатели» (это то же, что и «не понимать пиво»?). Это банальная лень — пассование перед неочевидным, требующим мозговой деятельности на этапе освоения.


 
crux   (2007-10-25 19:01) [46]

KSergey ©   (25.10.07 18:41) [40]

>Вопрос был "на что указывает"
Совершенно верно

>При чем тут "что содержит"??
Если я точно интерпретировал ваш ответ, то вы ответили не верно. Это подсказка.


 
KSergey ©   (2007-10-25 19:11) [47]

> crux   (25.10.07 19:01) [46]
> Если я точно интерпретировал ваш ответ

ну тогда это не ко мне :)


 
Сергей Суровцев ©   (2007-10-25 19:15) [48]

>Zeqfreed ©   (25.10.07 18:56) [45]
>это то же, что и «не понимать пиво»?).
>Это банальная лень — пассование перед неочевидным, требующим
>мозговой деятельности на этапе освоения.

Это о пиве?


 
Ппш   (2007-10-25 19:22) [49]

AlexanderMS ©   (25.10.07 18:37) [37]

Все таки я думаю, что как таковые знания не оплачивают и не пользуются спросом, они по сути никому кроме Вас не нужны.
Эти знания могут помочь только(!) ЛИЧНО Вам. Предприятию, в котором Вы работаете, от них не холодно ни жарко.

Предприятию нужны решения различных задач.


 
Anatoly Podgoretsky ©   (2007-10-25 19:27) [50]

> crux  (25.10.2007 17:50:33)  [33]

Чувствую брата Колю (С)


 
AlexanderMS ©   (2007-10-25 19:52) [51]


> Все таки я думаю, что как таковые знания не оплачивают и
> не пользуются спросом, они по сути никому кроме Вас не нужны.
>
> Эти знания могут помочь только(!) ЛИЧНО Вам. Предприятию,
>  в котором Вы работаете, от них не холодно ни жарко.
>
> Предприятию нужны решения различных задач.

Спасибо, и вправду, так.


 
vpbar ©   (2007-10-25 19:54) [52]

>>AlexanderMS ©   (25.10.07 18:37) [37]
Я бы взял с таким резюме:
Почитаю Кнута, Макконела и Буча. Владею языками: русский, английский, MMIX. Имею опыт программирования  на С++,Delphi, asm. Реализованные проекты: (список штук несколько)


 
Ins ©   (2007-10-25 19:56) [53]


> всем привет тут вот читаю ваше обсуждение и четт тоже захотелось
> поучастовать
> Рас тут все такие профи то раскажите пжалста как им стать
> (програмистом)


> На сайте Подгорецкого есть уроки его авторства.
> И на Королевстве от ЮЗ.


Ага, и сразу же станешь профессионалом, как АП или ЮЗ :) Лучше Ленина читай, у него есть мааааленькая, но очень емкая фраза, отвечающая на вопрос, как стать профессионалом, и не важно в какой области.


 
Ппш   (2007-10-25 20:11) [54]

AlexanderMS ©   (25.10.07 19:52) [51]
Спасибо, и вправду, так.


Предприятию нужны решения различных задач.

Не, тезка, я не стал раскрывать все знания (шучу), но приготовился к вопросам, но ты все понял правильно: Те знания, что ты приобретешь это только плюс, они, и помогут тебе устроится на работу и решать те самые задачи для работодателя.

Но, то что ты что-то не знаешь и не умеешь, еще не означает, что ты этого не сможешь выполнить: ведь - век живи, век учись :) походу все освоится... не надо бояться.


 
vpbar ©   (2007-10-25 20:16) [55]

>>Ппш   (25.10.07 19:22) [49]
Да, но при устройстве на работу узнать, что вы можете решать нужные задачи работадатель не может (если только всех не брать на испытательных срок), поэтому и смотрит на резюме.


 
Anatoly Podgoretsky ©   (2007-10-25 20:20) [56]


> поэтому и смотрит на резюме.

В первом приближении.

Программист - это склад ума, строгая логика.


 
vpbar ©   (2007-10-25 20:21) [57]

Программист это ума палата и странная логика.


 
Ппш   (2007-10-25 20:27) [58]

vpbar ©   (25.10.07 20:16) [55]
>>Ппш   (25.10.07 19:22) [49]
Да, но при устройстве на работу узнать, что вы можете решать нужные задачи работадатель не может (если только всех не брать на испытательных срок), поэтому и смотрит на резюме.


Да, это так (с)

Я и говорю, что эти знания (что в резюме) помогают ТОЛЬКО тебе! в данном случае устроится на работу. Работодатель посмотрел на резюме, увидел кучу инструментов, которыми ты владеешь, значит, думает, сможешь им помочь.

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

В армию берут также, что с тебя взять... придя туда тебе дадут месяц на изучение-обучение, а потом заступаешь на БОЕВОЕ дежурство. Прикинь, месяц обучения и защищаешь свою родину.


 
Ппш   (2007-10-25 20:32) [59]

месяц на изучение-обучение

У меня это было после учебки (пол года), но не по рофелю я попал в часть. Поэтому можно сказать: изучал VB... пришел в часть, месяц на изучение C++ и американский взвод морских котиков через меня не пойдет :)


 
Anatoly Podgoretsky ©   (2007-10-25 20:49) [60]

> vpbar  (25.10.2007 20:21:57)  [57]

Ума у многих много, а вот жесткая или странная логика есть не у всех. А без жесткой логики какой же он программист, он же фокусник.


 
Сергей Суровцев ©   (2007-10-25 21:10) [61]

>Ппш   (25.10.07 20:32) [59]
>Поэтому можно сказать: изучал VB... пришел в часть, месяц на изучение
>C++ и американский взвод морских котиков через меня не пойдет :)

Траншеи хорошо роешь и маскируешь?

>Anatoly Podgoretsky ©   (25.10.07 20:49) [60]
>Ума у многих много, а вот жесткая или странная логика есть не у всех. А
>без жесткой логики какой же он программист, он же фокусник.

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


 
Ппш   (2007-10-25 21:21) [62]

Сергей Суровцев ©   (25.10.07 21:10) [61]
Траншеи хорошо роешь и маскируешь?


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


 
Anatoly Podgoretsky ©   (2007-10-25 21:24) [63]

> Сергей Суровцев  (25.10.2007 21:10:01)  [61]

Волшебник это почетная профессия


 
Ппш   (2007-10-25 21:25) [64]

Сергей Суровцев ©   (25.10.07 21:10) [61]
>Ппш   (25.10.07 20:32) [59]
>Поэтому можно сказать: изучал VB... пришел в часть, месяц на изучение
>C++ и американский взвод морских котиков через меня не пойдет :)

Траншеи хорошо роешь и маскируешь?


Странный вывод ты всеже сделал.
В учебке учили на акустика на большие коробли, а попал на берег.


 
@!!ex ©   (2007-10-25 21:27) [65]

> [34] KSergey ©   (25.10.07 18:05)

меня удвиляет, что дельфи позволяет обращаться к указателю как к данным без явного указания того, что мы хотим работать не с указателем, а с данными на которые он указывает.
Указатель - это адрес памяти, где лежат данные. Откуда у него какие то поля, свойства, методы?
ИМХО это не логично. ЛОгично было бы требовать обязательно ^, если мы хотим работать с данными.


 
Anatoly Podgoretsky ©   (2007-10-25 21:30) [66]

> Ппш  (25.10.2007 21:21:02)  [62]

> "научат".

А больно не будет?


 
Anatoly Podgoretsky ©   (2007-10-25 21:30) [67]

> @!!ex  (25.10.2007 21:27:05)  [65]

Не логично, это излишне.


 
Ппш   (2007-10-25 21:36) [68]

Anatoly Podgoretsky ©   (25.10.07 21:30) [66]
> Ппш  (25.10.2007 21:21:02)  [62]
> "научат".
А больно не будет?


Проницательный Вы человек ;)
Исли ты не научишься, то выходит "старому товарищу" придется заступать на вахту (ладно, возьмем, что так и так ему заступать, НО не в удобное для себя время) :) да фигня это все, не серьезно, так, традиции ради. :)


 
Ins ©   (2007-10-25 21:46) [69]


> Не логично, это излишне.

А я кстати поддержу @!!ex, не то, чтобы это такая серьезная проблема, но сам всегда ставлю шляпочки, чтобы потом когда смотрю на код знать, что это у меня именно указатель, а не сама запись. Все-таки паскаль тем и хорош, что за счет некоторой избыточности получаем строгость и наглядность. Думаю, за счет избыточности он намного нагляднее того же C, где скобки вместо begin..end, точки, запятые, стрелочки всякие, значки, в то время как в паскале - слова. Хотя, возможно, это дело привычки. Так что ИМХО это все. :)


 
vpbar ©   (2007-10-25 21:48) [70]

>>@!!ex ©   (25.10.07 21:27) [65]
Зачем. Когда и так понятно что мы хотим обратиться к данным. Единственное что не логично, на мой взгляд - это операция присваивания. Тут хорошобы уточнять что присваивается

 
pt1,pt2:TPoint;
ppt1,ppt2:PPoint;
..................
pt1:=pt2; // присваиваем структуры
pt1.X:=10; // логично
ppt1.X:=10; //логично
ppt1:=ppt2; // неожидано присваиваем указатели, хотя похоже на то что выше
ppt1^:=ppt2^; // нужно почемуто так
pt1:=ppt; // и так нельзя :(

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

Т.е. я хотел бы что бы по умолчанию ppt виделось как ppt^.
А если мне понадобится считать ppt указателем, то например делать так
ppt@:=nil (@ - оператор обращения к указателю)
if ppt1@=ppt2@ then Oni_Ravny;


 
Ппш   (2007-10-25 21:50) [71]

Ins ©   (25.10.07 21:46) [69]
намного нагляднее того же C, где скобки вместо begin..end, точки, запятые, стрелочки всякие, значки, в то время как в паскале - слова.


"У наших предков, у славян,
Меж дел великого значенья
Всегда к реченьям и словам
Было особое почтенье".
(Кобзев).

:)


 
vpbar ©   (2007-10-25 21:51) [72]

>>Ins ©   (25.10.07 21:46) [69]
Привычки. К тому же, если по-вашему, то С++ логичнее так как там есть "." и "->" , а в делфи только "."


 
Сергей Суровцев ©   (2007-10-25 21:51) [73]

>Ппш   (25.10.07 21:25) [64]
>Странный вывод ты всеже сделал.
>В учебке учили на акустика на большие коробли, а попал на берег.

Не подразумевал плохого. Просто траншея, замаскированная, лучшее средство от проходящего взвода.


 
Ins ©   (2007-10-25 21:56) [74]


> [72] vpbar ©   (25.10.07 21:51)

Т зншь, чт рсскй зк тж збтчн? :) Нфг нжн глсн бкв? Бз нх тж нплх...


 
vpbar ©   (2007-10-25 21:57) [75]

>>Ins ©   (25.10.07 21:56) [74]
Т не понял. Я не о избыточности, а о логики и единообразии.


 
Ins ©   (2007-10-25 22:00) [76]


> Я не о избыточности, а о логики и единообразии.

Тогда немного не въехал в [72] :)


 
Ппш   (2007-10-25 22:00) [77]

Сергей Суровцев ©   (25.10.07 21:51) [73]

вы о чем? чет я не понял! :)


 
@!!ex ©   (2007-10-25 22:05) [78]


> [67] Anatoly Podgoretsky ©   (25.10.07 21:30)

Нипанятна каким образом у адреса(читай числа) появляются какие то методы, поля и свйоства.
Объясните мне, откуда они берутся?
Адрес и данные - это не одно и тоже, даже не близко..
Так почему же позволительно работать с адресом, как будто это данные? Тем более не всегда, а только в части случаев, как уже было отмечено в [20].

> [72] vpbar ©   (25.10.07 21:51)

в дельфи еще и ^. есть, это полный аналог -> или я чего то не учитываю?


 
Ins ©   (2007-10-25 22:07) [79]


> [78] @!!ex ©   (25.10.07 22:05)

Про методы я не понял. Что имеется в виду? Записи с методами из последних версий Delphi или уже от записей перешли на классы?


 
vpbar ©   (2007-10-25 22:27) [80]

Попробую пояснить, что имел ввиду.
Во первых в языке нужно не смешивать ссылки и указатели.
Ссылка - ссылается на объект определенного типа или никуда не ссылается (равна nil). Ссылке можно присвоить nil или ссылку на объект совметимого типа. Проверить на равенство с nil или с другой ссылкой. Ее можно разименовать, т.е. указать что мы хотим работать не ссылкой, а с объектом на который она ссылается. И все. Т.е. ссылка нужно для того чтобы ссылаться на объект из разных мест.
Указатель - это адрес блока в памяти. Это низкоуровневая конструкция. Ее можно складывать сравнивать с другими указателями и приводить к ссылке определенного типа.
Так вот в делфи переменная типа объект (TObject) это по сути ссылка. Переменная типа Pointer of Type - это тоже ссылка. Но работа с ними не логична потому что в одном случае подразумевается объект на который указывает ссылка (a:TObject; a.Field:=10) а в другое сама ссылка (a,b:TObject; a:=b;);
Конечно в случае с оператором "." можно считать что слева должен быть указатель на структуру. И это как бы сокращение от a^.Field
Но в случае с динамическим массивом (arr1,arr2) arr1[1] // arr1- массив
arr1:=arr2 //arr1 - ссылка.
Ссылке можно свободно присвоить указатель, хотя при этом теряется типобезопастность, но этого не видно.

p:pointer;
o:Tobject;
...
o:=p; // надо помнить что такое p
//Логичнее приведение типа o:=TObject(p);

Т.е. нужно постоянно помнить что ссылка это ссылка. Хотя обычно это не важно - а важно то на что она ссылается.
Поэтому я считаю, то обязательное указание на то что мы используем ссылку как ссылку, а не как объект - логично и наглядно.
Например
arr1:=arr2 // присваиваем массивы
arr1@:=arr2@ // присваиваем ссылки.

ЗЫ. В принципе можно запомнить, что в некоторых случаях (например, присваивание) имеется ввиду ссылка, а в других (например, обращение к полям, элементам) объект. Но мне кажется это не логичным.

По-поводу C++
Если объект на стеке то обращается к полям через "." а если на куче то "->". Но обычно где он - это не важно и не зачем это так выделять. Т.е. имхо еще не логичнее.


 
vpbar ©   (2007-10-25 22:29) [81]

>>@!!ex ©   (25.10.07 22:05) [78]
>>в дельфи еще и ^. есть, это полный аналог -> или я чего то не учитываю?
О нет! Совсем не полный. У си тут своя логика. Особенно когда -> перегружен.


 
@!!ex ©   (2007-10-25 22:37) [82]

> [81] vpbar ©   (25.10.07 22:29)

ну так и + в дельфи не равен + в С, особенно если + перегружен. ;)


> [79] Ins ©   (25.10.07 22:07)

Например, указатель на объект.
Form:^TForm;
при том что Form - это указатель на ссылку, мы все равно можем работать с ним как с непосредственно объектом. Это не логично. ИМХО опять же.


 
Ins ©   (2007-10-25 22:42) [83]


> Во первых в языке нужно не смешивать ссылки и указатели.

По мне так деление на ссылки и указатели излишне. Так как по сути своей это одно и то же. А раз так, то зачем плодить сущности без надобности.


> Ее можно складывать сравнивать с другими указателями

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


 
vpbar ©   (2007-10-25 22:54) [84]

>>Ins ©   (25.10.07 22:42) [83]
А по мне не лишне. Ибо p:Pointer и O:Tobject; (или ppt:PPoint) это разные весчи. И что допуситимо с указателем (p1>p2; inc(p)) не имеет смысла с сылкой. Кроме того ссылка имеет определенный тип а указатель нет.

Поэтому O:=P - это грубое нарушение. Почему тогда нельзя O:=ppt ?
>>Опять таки, считаю, что арифметика указателей не должна быть в строготипизированном языке
Вот именно указатель это очень низкоуровневая конструкция в отличии от ссылки.


 
Ins ©   (2007-10-25 22:56) [85]

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


 
hirabayashi   (2007-10-25 22:58) [86]

Ins ©   (25.10.07 22:56) [85]

Но это все фигня, после того как ты постиг дзен.


 
vpbar ©   (2007-10-25 22:59) [87]

>>hirabayashi   (25.10.07 22:58) [86]
Да уж. Ничего нет, кроме последовательности байт. Остальное иллюзия.


 
Ins ©   (2007-10-25 23:01) [88]


> Вот именно указатель это очень низкоуровневая конструкция
> в отличии от ссылки.

Вы указатель приравняли к целому, что недопустимо в строготипизированном языке. Точно также, как и приравнивать к целому логический, перечислимый и прочие типы. Приравнивая все это к целому, мы спускаемся с "человеческого" уровня абстракции на "машинный". Да еще и смешиваем их. Вся прелесть теряется. То, о чем я сказал в [85] вам не дано понять, что ж, жаль, Delphi язык не для вас.


 
@!!ex ©   (2007-10-25 23:05) [89]

Дельфи - далеко не строго типизированный язык.
написав пару шейдеров на GLSL - начинаешь понимать это.


 
vpbar ©   (2007-10-25 23:08) [90]

Ins ©   (25.10.07 23:01) [88]
Гы. Не судите, да не судимы будите.
Delphi строго типизированный язык?
тогда почему прокатывает это


var
p:Pointer;
O:TObject;
c:Pchar;
begin
c:="hello";
inc(c);
c^:="2"; // Последствия знаете, знаток делфи?

p:=0; // указателю и целое (0 - это ведь целочисленный литерал) присвоили  
O:=p;
// и все без явного приведения типа.
end;


 
Ins ©   (2007-10-25 23:22) [91]


> Последствия знаете, знаток делфи?

Во-первых, воздержись от наездов. Во-вторых, где здесь нарушение строгой типизации? PChar это кроме всего прочего и ^Char, только если хочешь его потом использовать и как указатель на нультерминальную строку, о том самом терминаторе позаботься. Типизация тут нипричем. Вот я реально один косячек Борланда знаю с PChar, если интересно - могу показать.


> p:=0; // указателю и целое (0 - это ведь целочисленный литерал)
> присвоили  

Варнинг получите. А вот другое целое, кроме как 0, не присвоишь.


> O:=p;

Если честно, я бы тоже запретил подобные присваивания, но Borland так сделали вероятно по известным только им причинам.


 
Ins ©   (2007-10-25 23:28) [92]


> Последствия знаете, знаток делфи?

Или тут имелось в виду AV, которое возникает при выполнении этих трех строк. Если да, опять таки, дело не в типизации. Просто память, на которую ссылается c располагается в защищенном от записи сегменте кода. Где строковой константе и место.


 
vpbar ©   (2007-10-25 23:29) [93]

>>Во-первых, воздержись от наездов.
Это вопрос, а не наезд. Ели это наезд, то в таком случае это тем более "То, о чем я сказал в [85] вам не дано понять, что ж, жаль, Delphi язык не для вас."
>>Во-вторых, где здесь нарушение строгой типизации?
Ну хорошо. То что не надо PChar разименовывать, что бы присвоить ему символ Вы не считаете нарушением типизации. Но ошибка там будет из-за другого нарушения типизации. По сути тут  "c" - это ссылка на константу и менять ее нельзя.

>>Варнинг получите. А вот другое целое, кроме как 0, не присвоишь.
Слишком много тонкостей чтобы оправдать это.
>>Если честно, я бы тоже запретил подобные присваивания, но Borland так сделали вероятно по известным только им причинам.
Не виду причин. Наверно просто ошибка при построении языка или компилятора.


 
vpbar ©   (2007-10-25 23:31) [94]

>>Ins ©   (25.10.07 23:28) [92]
Эх. Все таки, видимо, у нас разные взгляды на типизацию. Что ж не буду вас переубеждать. Да и сам останусь при своем мнении (оно у меня весьма обосновано), пока не увижу реальных аргуменов не в его пользу.


 
Ins ©   (2007-10-25 23:34) [95]


> То что не надо PChar разименовывать, что бы присвоить ему
> символ Вы не считаете нарушением типизации.

Хе-хе. Вы и правда думаете, что
var
 c: PChar;
begin
 c:="2";    /*
 c^:="2";  /**
end;
* и ** - это одно и то же? :)


> Слишком много тонкостей чтобы оправдать это.

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


 
vpbar ©   (2007-10-25 23:37) [96]

Ins ©   (25.10.07 23:34) [95]
Не одно конечно. В первом случае "2" -это строка а во втором "2" -это символ.
Еще одна ненужная тонкость.


 
vpbar ©   (2007-10-25 23:38) [97]

>>Ins ©   (25.10.07 23:34) [95]
>>не забывай, что Pointer и Integer - это не одно и то же.
Я нигде не говорил этого. Наоборот, всячески разграничивал указатели от других типов.


 
Ins ©   (2007-10-25 23:42) [98]


> Еще одна ненужная тонкость.

Просто не нужно думать, что PChar - это ^Char. Это не так. PChar - это особый встроенный в компилятор тип. Цель этих особенностей - облегчить работу со строками. А насчет строгой типизации, просто не нужно забывать, что есть как совместимые типы, так и несовместимые. Паскаль допускает совместимость типов, но только тех, которые должны быть совместимы, а не так как в C++, целое оно же логическое оно же указатель.


 
Ins ©   (2007-10-25 23:47) [99]


> Наоборот, всячески разграничивал указатели от других типов.

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


 
vpbar ©   (2007-10-25 23:48) [100]

>>Ins ©   (25.10.07 23:42) [98]
> Еще одна ненужная тонкость.
В [96] я о том что "Х" - это и строка и символ.
Хотя можно считать ее всегда символом - логичнее будет.

По-поводу совместимости типов в Делфи спроить не буду с этим получше чем в Си, но тоже не идеал.


 
vpbar ©   (2007-10-25 23:52) [101]

>>Ins ©   (25.10.07 23:47) [99]
>>Правильно, только понятие указателя несколько расширить нужно
Нафик. Лучше я буду разделять указатели и ссылки.

ЗЫ  У меня такое ощущение, что вы пытаетесь меня учить, при том что знаете не больше меня. Не стоит. Если я забуду какуюто Делфийскую тонкость всегда могу нажать Ctrl+Shift+C
А в области теорий ваши учения мне не импонируют.


 
Ins ©   (2007-10-25 23:53) [102]


> Хотя можно считать ее всегда символом - логичнее будет.

А как тогда присвоить PChar-у указатель на строковый литерал из одного символа?


> По-поводу совместимости типов в Делфи спроить не буду с
> этим получше чем в Си, но тоже не идеал.

Не идеал. Я с совместимостью Pointer-TObject тоже не согласен. Опять таки потому, что приходиться спускаться на более низкий уровень абстракции.


 
Ins ©   (2007-10-25 23:55) [103]


> У меня такое ощущение, что вы пытаетесь меня учить, при
> том что знаете не больше меня.

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


 
Ins ©   (2007-10-25 23:59) [104]

Проблема в том, что я мыслю в категориях Паскаля, а вы - скорее C++, так как нету в Паскале ссылок. Не-ту. Не вводил Вирт такого понятия.


 
vpbar ©   (2007-10-26 00:03) [105]

>>Ins ©   (25.10.07 23:53) [102]
Так же как и строке. Разрешить присваивать  символ.
Возможно же присвоение типа String:=Char . Хотя с PChar тут опять несуразность PChar:=Char - нельзя, но PChar:=String тоже нельзя. Хотя PChar:="строка" можно. Так почему же не считать что PChar:="с"
(где "с" - символ) тоже можно.

Ins ©   (25.10.07 23:55) [103]
Давайте. Просто у меня возникло такое ощущение после [95] и гдето еще.

ЗЫ. Вообщем все. Я спать. А то запутано что то объясняю такие простые весчи.


 
vpbar ©   (2007-10-26 00:05) [106]

>>Ins ©   (25.10.07 23:59) [104]
Неее я мыслю в категориях абстрактных понятий, а вы как и сказали "в категориях Паскаля". Просто я считаю что Макконел прав. "Программировать нужно не на языке, а с использованием языка"


 
vpbar ©   (2007-10-26 00:07) [107]

Точно спать пора.
Макконнелл - кажется точнее будет :)


 
oxffff ©   (2007-10-26 00:09) [108]

Парни открывайте устройство управляемого кода, особенно почитайте про Machine State.


 
Ins ©   (2007-10-26 00:10) [109]


> [108] oxffff ©   (26.10.07 00:09)

Да вообще лучше забить на императивные языки и изучать функциональные. :) Там таких проблем нет.


 
Ins ©   (2007-10-26 00:18) [110]


> Просто я считаю что Макконел прав.

Вирт наверное не читал Макконелла, но мне импонирует та идеология, которую он вложил в Паскаль. :) И я ее придерживаюсь.


 
oxffff ©   (2007-10-26 00:21) [111]


> Ins ©   (26.10.07 00:10) [109]
>
> > [108] oxffff ©   (26.10.07 00:09)
>
> Да вообще лучше забить на императивные языки и изучать функциональные.
>  :) Там таких проблем нет.


Это были просто мои мысли в слух.  
Ни кому и не о чем.
:)

P.S. Мне спать пора уже.
И сняться мне цистерны и вагоны.
Привет Mettler Toledo.


 
Юрий Зотов ©   (2007-10-26 00:23) [112]

Читал-читал про типизацию, но так и не понял - сможет Валентин быть программистом, или нет?

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


 
Ins ©   (2007-10-26 00:23) [113]


> Это были просто мои мысли в слух.  
> Ни кому и не о чем.
> :)

Дык у меня тоже :) Все фигня.


 
oxffff ©   (2007-10-26 00:26) [114]


> Скажите, это обязательно знать, смогу ли я быть, скажем
> так, хорошим программистом, не вдаваясь глубоко внутрь?


Чего?


 
oxffff ©   (2007-10-26 00:27) [115]


> Чего?


Не, мне точно пора спать. LOL сам с себя.


 
@!!ex ©   (2007-10-26 00:32) [116]

> [112] Юрий Зотов ©   (26.10.07 00:23)

Мне интересны... Значит я смогу?


 
oxffff ©   (2007-10-26 00:36) [117]


> @!!ex ©   (26.10.07 00:32) [116]
> > [112] Юрий Зотов ©   (26.10.07 00:23)
>
> Мне интересны... Значит я смогу?


Если прочитаешь про Assignment compatibility

The formal description of assignment compatibility

verification type compatibility.
In essence, a value V is assignment compatible with a location L if it meets one
of the following conditions:
• The exact static type referred to by the type signature of V matches the exact type of the location.
• V, described by the generic type signature G<U1,...,Un>, is assignment compatible with L,
described by the generic type signature H<T1,…,Tn>, if and only if G=H, and for each generic
parameter of G with a variance annotation of var_i we have:
o var_i = none or Ti is a value type or Ti is a generic parameter: Ui is the same exact
type as Ti
o var_i = +: Ti := Ui (covariant: an instance of Ui can be stored in a location of type Ti)
o var_i = -: Ui := Ti (contravariant: an instance of Ti can be stored in a location of
type Ui).
One of the types supported by the exact type of V is assignment compatible to the type of L.
This allows, for example, an instance of a class that inherits from a base class (hence supports
Partition I 33
the base class’s type contract) to be stored into a location whose type is that of the base class.
[Note: Recall that a location constraint is just a type constraint plus two additional possible
constraints (literal and constant), and thus a location constraint can be converted into a type
constraint in a natural way. end note] Under this set of rules, transitivity of assignment
compatibility holds: if L := V and M := L, then M := V.

И т.д. и т.п.

Интересно?


 
@!!ex ©   (2007-10-26 00:37) [118]

> [117] oxffff ©   (26.10.07 00:36)

старо.


 
oxffff ©   (2007-10-26 00:40) [119]


> @!!ex ©   (26.10.07 00:37) [118]


Да ты крут как я погляжу. :)

Тогда поясни почему при передачи var параметра его тип должен точно соответствовать типу параметру метода.


 
@!!ex ©   (2007-10-26 00:52) [120]

> [119] oxffff ©   (26.10.07 00:40)
> Тогда поясни почему при передачи var параметра его тип должен
> точно соответствовать типу параметру метода.

Не должен. Вы это откуда взяли?


 
DevilDevil ©   (2007-10-26 08:18) [121]

такс...

> Валентин   (25.10.07 14:19) [0]
станешь ты программистом или нет - зависит только от тебя.
предупреждаю заранее: нет предела совершенству, втянешься - будешь прогить круглосуточно )

по поводу непонимания указателей

указатели даются сложно потому, что не понятно, зачем вообще они нужны. Непонятно так же, зачем вообще нужны динамические переменные.

Указатели нужны для работы с памятью. А у типичного кнопкошлёпа или просто начинающего, нет абсолютно никакой потребности работы с памятью. Лично мне стала понятна суть, когда попробовал ScanLines[ ].

> @!!ex ©   (25.10.07 17:48) [32]
Разработчики Pascal/Delphi - молодцы. Если в Си++ ты используешь -> для обращения к данным по указателю (Form1->Caption), точку для обрашения к структуре (Rect.Left = 5), четыре точки для определения пространства имён ( Graphics::TBitmap* B = NULL ) или при реализации класса ( void __fastcall TMainForm::FormCreate(TObject *Sender) ), то в Delphi ВО ВСЕХ этих случаёх обходишься ТОЧКОЙ !

Если придерживаться указательной логики, то ты должен обращаться Bitmap^.Canvas^.MoveTo(...);

ИМХО про обращение к данным без "крышечки" они правы. Код с многообразием таких "крышечек" смотрится поуродски как то.

Ссылки...
В Delphi они реализованы более изящно: через var, out и const для неперечисляемых типов.

Проще на примере:

procedure SomeProcWithVar(var R : TRect);
begin
  if @R = nil then ShowMessage("Fuck off!");
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  SomeProcWithVar( TRect(nil^) );
end;


Благодарю за внимание.


 
oxffff ©   (2007-10-26 08:34) [122]


> @!!ex ©   (26.10.07 00:52) [120]
> > [119] oxffff ©   (26.10.07 00:40)
> > Тогда поясни почему при передачи var параметра его тип
> должен
> > точно соответствовать типу параметру метода.
>
> Не должен. Вы это откуда взяли?


Тогда читай help.
И теорию типов заодно. :)


 
KSergey ©   (2007-10-26 09:27) [123]

> DevilDevil ©   (26.10.07 08:18) [121]
>   SomeProcWithVar( TRect(nil^) );

Да вы извращенец, товарисч! Такого я еще не встречал :)


 
KSergey ©   (2007-10-26 09:53) [124]

> @!!ex ©   (25.10.07 22:05) [78]
> Нипанятна каким образом у адреса(читай числа) появляются
> какие то методы, поля и свйоства.
> Объясните мне, откуда они берутся?

Тут все очень просто, думаю.
Да, формально правильно надо бы писать p^.field, однако я не знаю ни одного примера, когда конструкция p.field могла бы быть интерпретирована как-то иначе, чем p^.field. Отсюда и введеное в синтаксис сокращение, а вовсе не "наделение указателя свойствами". (Говорится, что в [20] приведен какой-то пример, но мне сейчас лень это словоблудие читать, сорри.)


 
Игорь Шевченко ©   (2007-10-26 10:09) [125]

Таких не берут в программисты


 
DevilDevil ©   (2007-10-26 10:28) [126]

> KSergey ©   (26.10.07 09:27) [123]
> Да вы извращенец, товарисч! Такого я еще не встречал :)

SomeProcWithVar( PRect(nil)^ );


 
KSergey ©   (2007-10-26 10:29) [127]

> Игорь Шевченко ©   (26.10.07 10:09) [125]
> Таких не берут в программисты

Сказал - как отрезал! :)


 
@!!ex ©   (2007-10-26 10:52) [128]

> [122] oxffff ©   (26.10.07 08:34)

Да что вы ерунду говорите.
Где тут строгое соответствие:
type
 TVR = record
   X:byte;
   Y:byte;
   Z:byte;
   W:byte;
 end;

 TVA = array[0..1] of word;

Procedure Check(var v:TVA);
begin
end;

var
 a:TVR;
begin
 Check(TVA(a));


 
boriskb ©   (2007-10-26 10:57) [129]


> смогу ли я быть программистом


А "программист" это кто?
Кто программирует?
Так ты уже он.


 
isasa ©   (2007-10-26 11:14) [130]

@!!ex ©   (26.10.07 10:52) [128]

:)

TVR = packed record

забыл, а то можно нарваться ...


 
oxffff ©   (2007-10-26 11:17) [131]


> @!!ex ©   (26.10.07 10:52) [128]
> > [122] oxffff ©   (26.10.07 08:34)
>
> Да что вы ерунду говорите.
> Где тут строгое соответствие:
> type
>  TVR = record
>    X:byte;
>    Y:byte;
>    Z:byte;
>    W:byte;
>  end;
>
>  TVA = array[0..1] of word;
>
> Procedure Check(var v:TVA);
> begin
> end;
>

Ты не понял. Попробуй без явного приведения.
Объясни почему нельзя передавать в качестве var параметра совместимые типы, например передать потомка в метод, сигнатура которого включает прием только базового типа с точки зрения теории типов.
То есть с доказательством. :)

> var
>  a:TVR;
> begin
>  Check(TVA(a));


 
Игорь Шевченко ©   (2007-10-26 11:28) [132]

"В последнее время наметилась одна тенденция. Дело в том, что сейчас для того, чтобы выйти на рынок программных средств и занять в нём свою нишу, фирма, а, соответственно, и программисты должны делать продукт как можно быстрее. При этом, естественно, достаточно часто вопросы эффективности, быстродействия, минимизации размера используемой памяти и тому подобные во внимание просто не принимаются. Зачем, дескать, думать о таких «мелочах», если современные компьютеры достаточно мощные и «переваривают» почти любые объёмы. Подумаешь, мегабайт памяти туда, мегабайт сюда… Кроме того, очень сильное влияние на квалификацию программистов оказывают многочисленные средства быстрой разработки, бурное развитие которых наблюдается в последнее время. Средства, предназначенные для повышения производительности труда квалифицированных программистов, заняли на рынке совершенно другое место. Достаточно часто эти средства используются программистами низкой квалификации для того, чтобы в кратчайшее время создать работающую программу, прикладывая при этом минимум усилий. Более того, средства быстрой разработки позволяют программисту скрыть недостаток квалификации, ибо вся черновая работа делается без участия программиста. Вместо того, чтобы овладеть необходимым для профессиональной деятельности минимумом, можно недостаток квалификации скрыть посредством использования программы, которая всё сделает сама. Таким образом, средства быстрой разработки используются превратились в средства создания неэффективных программ неквалифицированными программистами. Что поделаешь, рынок диктует свои условия…

Соответственно, такой подход приводит к тому, что достаточно часто у программистов появляется завышенная самооценка. Раз я могу «накропать» программу за неделю, значит, я – ВЕЛИКИЙ ПРОГРАММИСТ, всё умею, всё могу. Зачем мне чему-то учиться, я (при помощи конкретного средства) всегда сделаю то, что хочу! Появилось даже расхожее определение – «программист, пишущий мышкой»… Но стоит у подобных, с позволения сказать, программистов, забрать средство быстрой разработки, как они становятся беспомощными. Ведь они являются программистами на конкретном средстве! Другими словами, они являются ПОЛЬЗОВАТЕЛЯМИ конкретного средства… А пользователи и программисты – это совершенно различные классы людей, использующих компьютер в своей профессиональной деятельности. И если пользователю необходимо знать только порядок использования и взаимодействие частей одной или нескольких программ (WinWord, бухгалтерская или банковская программы, программа обработки изображений и так далее), то программист помимо всего прочего должен, почти обязан понимать то, как функционирует компьютер, на основе каких принципов построена операционная система, понимать принципы организации данных и быть в состоянии написать эффективную программу, решающую поставленную перед программистом задачу. В том случае, если программист является профессионалом, то использование средств быстрой разработки только поможет ему, позволив сократить время, необходимое для разработки программы, и минимизировать усилия, необходимые для разработки таковой. "

http://www.techbook.ru/rumyantsev.html


 
Petr V. Abramov ©   (2007-10-26 11:40) [133]

> Появилось даже расхожее определение – «программист, пишущий мышкой»
такого сотрудника надо назвать "разработчик интерфейса", и все встанет на свои места.

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

Да здравствует разделение труда


 
KSergey ©   (2007-10-26 11:54) [134]

> Игорь Шевченко ©   (26.10.07 11:28) [132]

Один представитель MS говорил на какой-то кнференции следующее (и у меня сложилось впечатление - совершенно без стеба, на полном серьезе, на основе собственного опыта управлением проектами) :
"Я не люблю программистов на C++, т.к. они постоянно заботятся лишь о каких-то микросекундах и сэкономленных байтах, готовы ночами просиживать и получать кайф от экономии очередной микросекунды и очередного байта. А вот программисты на VB мне нравятся, т.к. они делают продукт, они ориентуруются на конечный бизнес-результат, на создание инструмента, пригодного бизнесу. Я их называю computer-ориентированные и business-ориентированные сортудники."


 
oxffff ©   (2007-10-26 12:11) [135]

Подходы и средства все это направлено на борьбу со сложностью.
Поэтому чем выше поколение средства(языка ) разработки, т.е 2GL,3GL,4GL и т.д, тем легче борьба со сложностью.
И те и другие программисты только разных уровней. :)


 
megabyte ©   (2007-10-26 12:13) [136]

Я вот тоже не то, что не понимаю указатели, скорее почти никогда их не использовал))) Понимание приходит, когда используешь что-то на реальной задаче. Ну не было необходимости и самостоятельно изучать не тянуло...
С ассемблером тоже не знаком.
Мне вообще ближе создание серверной части: построение и проектирование структуры БД, безопастность, нормализация, построение запросов, оптимизация и т.д. Здесь я тоже буду материться, когда человек будет говорить, что рюхает работу с БД и знает SQL, но при этом не понимает, что такое нормализация, уровни изолированности, транзакция, хранимые процедуры, триггеры, индексы, а знает только как сделать выбору и вставить запись(и то через какой-нить Грид только).

Насчет IDE, согласен, многие только батоны кидать умеют...


 
Валентин   (2007-10-26 13:26) [137]

Привет еще раз.
Я тут послушал про указатели. В том смысле, в каком они описывались здесь, я никогда с ними не сталкивался (с#). Я привык понимать их как ссылку на область памяти, содержащий объект, т.е. адрес. Какое-то специальное их использование никогда не осуществлял, а только как необходимость при создании объекта класса.
Сейчас читаю Рихтера, про сборку мусора. Мне нравится. Но что я хотел сказать в первом посте - так это то, что больше люблю строить логигку программы, повышать ее функциональность, но никак не держание в голове способов от утечки, минимизации использования памяти ит.д., т.е. чисто системные такие вещи...Я понимаю без этого не обойтись. Просто я ставлю приоритет для таких задач далеко не высокий..И очень далеко.


 
@!!ex ©   (2007-10-26 13:42) [138]

> [131] oxffff ©   (26.10.07 11:17)

НЕ понял вопроса...
Не опнимаю как можно применить теорию типов к доказательству строгой типизации в применении Var"a.
Было бы интересно это доказательство увидеть.


 
oxffff ©   (2007-10-26 13:47) [139]


> @!!ex ©   (26.10.07 13:42) [138]
> > [131] oxffff ©   (26.10.07 11:17)
>
> НЕ понял вопроса...
> Не опнимаю как можно применить теорию типов к доказательству
> строгой типизации в применении Var"a.
> Было бы интересно это доказательство увидеть.


Просто ты упомянул фразу, что это "старо".
в @!!ex ©   (26.10.07 00:37) [118].

Что ты имел под этим?

P.S. А между тем, на этом "старо" все до сих пор и работает.
Я привел тебе часть требований .NET. Это тоже старо?


 
Alkid ©   (2007-10-26 13:54) [140]


> Валентин   (26.10.07 13:26) [137]

В принципе для тебя определённая ниша на рынке существует - это разная бизнес-логика на Java/.NET, ASP.NET, возможно специализированные языки для систем. 1C, опять же :)

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


 
@!!ex ©   (2007-10-26 14:02) [141]

> [139] oxffff ©   (26.10.07 13:47)

нам это в ВУЗе преподавали.
Так вы не ответили на свой же вопрос.
Приведите доказательство. а?


 
Маша Шрайбер ©   (2007-10-26 14:53) [142]

>> Валентин   (25.10.07 14:19)  
> смогу ли я быть программистом

А смысл? (с)


 
oxffff ©   (2007-10-26 15:00) [143]


> @!!ex ©   (26.10.07 14:02) [141]
> > [139] oxffff ©   (26.10.07 13:47)
>
> нам это в ВУЗе преподавали.
> Так вы не ответили на свой же вопрос.
> Приведите доказательство. а?


Я то доказательство могу привести. Только правда на английском.
Подожду от вас его.
Вы же утверждали, что это старо, а между тем его даже не знаете.
:)


 
@!!ex ©   (2007-10-26 15:05) [144]

> [143] oxffff ©   (26.10.07 15:00)

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

P.S.
Я, кстати, все еще не понимаю связи между: теорией типов, требованиями к NET., и delphi.


 
oxffff ©   (2007-10-26 15:24) [145]


> @!!ex ©   (26.10.07 15:05) [144]
> > [143] oxffff ©   (26.10.07 15:00)
>
> Стоп-стоп-стоп. Я же сказа. Не знаю.


-Не знаю
-Старо

Это разве одно и тоже?

Я думаю вы намек поняли.

>P.S.
>Я, кстати, все еще не понимаю связи между: теорией типов, требованиями >к NET., и delphi.

А то, что в .NET языках, Delphi есть типы и есть определенные правила ( требования) по их использованию. Вы что не знали?

:)


 
oxffff ©   (2007-10-26 15:27) [146]

Type theory
Suppose that formal var parameter p is declared to have type T1, and actual parameter a is declared to have type T2. Since the function is implemented assuming it receive a value of type T1 in p, the compiler needs to ensure that all possible values of a are valid values of type T1. That is, T2 must be a subtype of T1. In addition, the caller is written to assume that it receives a value of type T2 in a when the function returns. Since the function is only implemented to return values of type T1, any value of type T1 also needs to be a valid value of type T2, so T1 must be a subtype of T2. In order for T1 and T2 to be subtypes of each other, they must be identical types. (Any type is considered to be a subtype of itself.)


 
@!!ex ©   (2007-10-26 15:35) [147]

> [145] oxffff ©   (26.10.07 15:24)

Нет, где тут связь? Теорию типов нам читали на дискретной математике, но вот почему нельзя передавать разные типы в var"е нам не доказывали.

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


 
oxffff ©   (2007-10-26 15:59) [148]


> @!!ex ©   (26.10.07 15:35) [147]
/I>

А где объяснение твоего высказывания "это старо"?

Что сейчас этим уже не пользуются?
Что уже никаких требований и правил?


 
KSergey ©   (2007-10-26 16:31) [149]

Ну как, Валентин, ясности в вопросе прибавляется?


 
@!!ex ©   (2007-10-26 16:32) [150]

> [148] oxffff ©   (26.10.07 15:59)


> нам это в ВУЗе преподавали.

Не объяснение?


 
oxffff ©   (2007-10-26 16:58) [151]


> Не объяснение?


И это уже устарело?
Безнадежно?

P.S.

Зачем быть таким упрямым, если можно просто сказать, что выразился некорректно.

С уважением Антонов Сергей.

Хорошей пятницы и выходных. ;)


 
KSergey ©   (2007-10-26 17:03) [152]

> @!!ex ©   (26.10.07 16:32) [150]

Я вот тут слежу за вашей дискуссией и одного не могу понять признаться: лично вы этого ("строгой типизации в применении Var"a") правда не понимаете или тут уже не о сути спор, а о том кто первый виноватым назовется?


 
@!!ex ©   (2007-10-26 17:07) [153]

> [152] KSergey ©   (26.10.07 17:03)

Почему не понимаю? Понимаю. потому что так захотели разработчики. Мне действительно интересно увидеть доказательство. Причины, по которым так сделано, а не констатацию факта: так требует компилятор.


> [151] oxffff ©   (26.10.07 16:58)

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


 
KSergey ©   (2007-10-26 17:13) [154]

> @!!ex ©   (26.10.07 17:07) [153]
>  Причины,  по которым так сделано,

Т.е. вы их вообще хотите узнать или вы хотите их услышать именно от oxffff ?


 
@!!ex ©   (2007-10-26 17:15) [155]

> [154] KSergey ©   (26.10.07 17:13)

Вообще. Гугль не помог, я честно пытался сам найти.


 
oxffff ©   (2007-10-26 17:29) [156]


>
> Если понимать "старо" как "это уже устарело", это одно,
> если понимать "старо" как "я это уже видел", это другое,
>  что я и пытаюсь объяснить.


То есть, если ты говоришь человеку "Ты старый" - это по твоему значит
"Мне кажется я вас где-то уже видел". Железная логика.

:)


 
@!!ex ©   (2007-10-26 17:34) [157]

> [156] oxffff ©   (26.10.07 17:29)

По вашей логике старый == устаревший?

Вопрос звучал как : "Интересно?"
Нет не интересно, так как "старо", видел я это уже.


 
oxffff ©   (2007-10-26 17:45) [158]


> @!!ex ©   (26.10.07 17:34) [157]


Я уже понял, что ты еще тот ЖУК. :)


 
KSergey ©   (2007-10-26 17:45) [159]

> @!!ex ©   (26.10.07 17:15) [155]

Ну это же вполне очевидно!
var-переменная компилятором передается как указатель. Т.е. в функцию приезжает просто адрес куска памяти, где внутренности функции ожидают увидеть экземпляр объекта, определенного в параметрах. И, соответсвтенно, смело в эту область памяти пишут.
Понятно, что на этапе выполнения никто уже не может проверить что же за адрес на самом деле подсунули. А вот при компиляции - как раз можно.
Так что никакой тут блажи нет.


 
@!!ex ©   (2007-10-26 17:52) [160]

> [159] KSergey ©   (26.10.07 17:45)

Это не объясянет, почему нельзя передать в качестве параметра наследника класса, который требуется передать. Ведь наследник в точности повторяет структуру родителя+ еще свои поля имеет, которые будут просто игнорироваться.


 
KSergey ©   (2007-10-26 18:22) [161]

> @!!ex ©   (26.10.07 17:52) [160]
> > [159] KSergey ©   (26.10.07 17:45)
>
> Это не объясянет, почему нельзя передать в качестве параметра
> наследника класса, который требуется передать. Ведь наследник
> в точности повторяет структуру родителя+ еще свои поля имеет,
>  которые будут просто игнорироваться.

Однако и это понятно: причина - в природе "ссылок на классы" в дельфи.
И в самом деле: эти самые ссылки - по сути указатели на объект. На занимаемую объектом память.
Пусть есть

TClassA = class
...
end;

TClassB = class(TClassA)
...
end;

procedure SomeProc(var aClass: TClassA);
begin
  aClass := TClassB.Create;
end;


И вот теперь представьте: передаем по сути указатель на указатель (crux, привет!) свято веря внутри SomeProc, что имеем дело с объектом А, а вот вызывающая функция как раз подразумевает, что ей вернули ссылку на B, и начинает с ним работать как с В. Пипец, правда?

Пока писал это, в голову пришел даже еще более плохой пример:

TClassA = class ... end;
TClassB = class(TClassA) ... end;
TClassС = class(TClassA) ... end;

procedure SomeProc(var aClass: TClassA);
begin
  aClass := TClassB.Create;
end;


Представьте что будет, если вызывающая функция будет выглядеть так:

var
  cl: TClassC;
begin
  SomeProc(cl);
...


Т.е. SomeProc законно присваивает параметру ссылку на TClassB, в то время как вызывающая далее работает с С!!!

А вот в С++ таких проблем не возникает, т.к. там если передается ссылка - то гарантированно на готовый экземпляр.


 
KSergey ©   (2007-10-26 18:25) [162]

Сорри. Поправки.

> KSergey ©   (26.10.07 18:22) [161]
> в природе "ссылок на классы" в дельфи.

В природе "ссылок на экземпляры" конечно же.

И в первом примере должно быть так:

TClassA = class
end;

TClassB = class(TClassA)
end;

procedure SomeProc(var aClass: TClassA);
begin
  aClass := TClassА.Create;
end;


 
@!!ex ©   (2007-10-26 19:18) [163]

> [161] KSergey ©   (26.10.07 18:22)

Спасибо!
То что нужно. Все, я понял теперь. Это за доказательство сойдет.



Страницы: 1 2 3 4 5 вся ветка

Форум: "Прочее";
Текущий архив: 2007.12.02;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.95 MB
Время: 0.047 c
2-1194434383
dumka
2007-11-07 14:19
2007.12.02
Поиск


2-1194692484
GSC
2007-11-10 14:01
2007.12.02
Переименование ключа


2-1194595298
lobach
2007-11-09 11:01
2007.12.02
Обработка ошибки


15-1193819195
Новичок
2007-10-31 11:26
2007.12.02
Ошибка подключения к серверу


15-1193777739
Принтер
2007-10-30 23:55
2007.12.02
Бытовые струйники энд лазерные притеры





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский