Сообщений в теме: 447

[Big Joe]

> есть достойные, свободно доступные, бесплатные IDE.
Turbo Delphi Explorer - бесплатная Delphi от Borland

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

Литературы по Дельфи на русском в разы больше

> эти языки дадут хорошее понимание ООП.

А чем отличается ООП в этих языках от ООП в Дельфи?

> так можно стать простым "кнопкодавом".

Кнопкодавом и в С# можно стать


> и клоуны удивляются потом... "почему прога так тупит?

Это человек тупит при разработке...

[Big Joe]

hes, он же оскарег, ты че тут делаешь в теме начинающих программистов ?)
ты же кодер со стажем

Случайно не "Вирус Оскарег" ?

[hes]

СЗОТ
hes, он же оскарег, ты че тут делаешь в теме начинающих программистов ?)
ты же кодер со стажем

ну бывают настолько старые задачки, что уже и подзабываю
интересно жеж)

Big Joe смотря для кого вирус один из старых ников , нигде не светил вроде..хммм

[Big Joe]

hes

А я от Random-а тебя знаю=) я еще щеглом был

[Kaganov]

Вы употребили слово проект = )))
А проект имеет следующий жизненный цикл.
- Определение (ТЗ, спецификации)
- Планирование
- Выполнение(Кодинг)
- Завершение

Может у вас не проекты? = )))

Ну а на практике? Вы Боги, чтобы на этапе определения и планирования уже знать на 100% какой должен быть проект????

[Kaganov]

курите нормативную документацию, ГОСТы, СТ РК наконец....

Да если бы это было бы в ГОСТах... Методики вычислений, конечно, из нормативных актов. А все остальное - фантазия программистов.

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

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

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

Да уж. Не рассказывайте мне про согласования. Систему управления качеством читали? Я пролистнул. Так с ней мы 29 дней в месяц будем только согласовывать. А на саму разработку останется 1 день.

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

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

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

Девушки плачут. А я не с железным сердцем. Не могу на это спокойно смотреть.

[@сенька]

Как дела у начинающего программиста?
До пол пути добрались?
Как настрой?

ЗЫ: Хоть поинтересуюсь, а то спорят тут только.

Приветик всем! Спасибо Jismo, что интересуетесь,,, купила таки Делфи 2-е издание(это переработаный вариант 1-й книги), потому как в электронном виде не всегда удавалось заглянуть хотя-бы на 3-4 часа(((
Возникла большая пауза в обучении (до пол-пути мне о-о-о-й как далеко)... присела я пока на блоках-схемах, во всяком случае -машинная логика расчетов мне уже ясна)))) или если я ошибаюсь, то звиняйте)))
Судя по задачкам в этой теме от г-на Visual1, даже и не думала никада, что логическую задачу можно решить вычислением!!! Нуочень интересно! Как предупреждает автор книги,- читать нужно всё и внимательно,,,поэтому не скакаю и скакать не буду...
По поводу, какой же все-таки из языков обучения самый доступный (читала здесь мнения по поводу Делфи)
пришла к выводу, что выбор сделала правильный!!!
А есчо меня отвлекает то, что приходится ковыряться по теме веб-програмирования, это для моего семейного бизнес-сайта((( может зря я в это влезла (за 2-мя зайсами, как говорится) мне нужно просто активизировать форму связи, там хостинг заморочит эту тему в связи с повальным спамом. если здесь есть желающие помочь мне (небецкарысна канешнааа))))
буту рата!

[@сенька]

мне пришлось учиться в процессе работы - примерно пол года ушло на самостоятельное изучение архитектуры ОС, приобретение начальных знаний об алгоритмах и т.д., учитывая то что первоначальные знания о самом компе у меня были с профтехшколы, потом примерно месяц или 2 я вплотную занималась языком(С#), в частности очень понравился американский курс TestOut, у них есть сайт на котором нифига не понятно что где взять но если искать в гугле можно найти рабочие ссылки и бесплатно скачать (курсы там разные и по сетям - подготовака к CCNA, CCNP итд, по БД и серверам, там же можно получить международные сертификаты после прохождения определенного курса, но я этим не заморачивалась), но все курсы на англ, так что подходят не всем, не зкажу за качество других, но по си шарпу я поняла все что хотели до меня донести, очень понятный и удобный - и видео и краткое письменное описание и задания причем с проверкой. И вот после 2-х мес мне начали давать задания, причем задания довольно серьезные т.к. компания где я работаю пишет софт для банка, пришлось еще начать учить PL/SQL без этого оказалось в моей работе тоже никуда, и вот тогда то и начались самые большие головоломки и первые ошибки, но практика самый хороший учитель!

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

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

Огромное спасибо за поддержку! белая зависть у меня))) за ваше стремление в этой науке , постичь и повысить проф.навыки!

[@сенька]

Ужас во что тема превратилась...

Рекомендую не начинать с дельфи. Ибо оно ломает новичку представление о ... Короче много о чем.

Начинать с интерпретируемого языка (PHP, Python) очень привлекательно простотой пользования без IDE, но опасно отсутствием понимания о типах.

Очень рекомендую начать с жёстко - типизированного языка, например Java или C#. Потому что:
- есть достойные, свободно доступные, бесплатные IDE.
- эти языки дадут хорошее понимание ООП.
- это универсальные языки, которые могут быть использованы для любых приложений, включая Веб.
- касаемо этих языков есть огромная масса литературы.


PS Повторюсь... очень не рекомендую начинать с дельфи, так можно стать простым "кнопкодавом". Таких среди "дельфинов" процентов 80. Накидали кнопок на форму, написали код по двойному клику... и клоуны удивляются потом... "почему прога так тупит? "

PPS Если кого-то заинтересовало, то что я написал - дайте знать... я продолжу.

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

[Big Joe]

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

[hes]

2Каганов

Не рассказывайте мне про систему управления качеством - чужда она нам Это чушь и бред, говорю как инженер-эксперт и чел, который 4 года изучал в институте что такое ГОСТ, СТ РК, СТП, ТУ, ОСТ, СТ СЭВ, ИСО и прочее прочее прочее.
Менеджмент качества - новый виток паранойи
А то, что нужны грамотные технические писатели - факт. У нас пока их маловасто.
Навскидку могу дать линк, но там российские техписы, еще со времен СССР в теме - http://authorit.ru, работают и поныне в области IT.
И вполне применимы наши еще советские ГОСТы к разработке. А что, разве методы разработки ПО как то за сотню лет изменились ?

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

Эх, девушки, так успокаивать их надо, отпаивать, ну и так далее, по мере развития ситуации

[Visual1]

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

using System;

class Program
	{
		static void Main(string[] args)
		{
			//Для хранения небольших целых чисел лучше использовать переменные 
			//типа byte, чтобы наиболее рационально использовать память компьютера.
			byte a = 10;
			byte b = 15;
			byte c = a + b;
			//Вывести значение суммы на экран
			Console.WriteLine ("c = " + c);
		}
	 }

Ошибка здесь вроде бы ну совсем никак не может появиться. Переменные типа byte могут хранить значения от 0 до 255, поэтому насчет переполнения результата при сложении можно не беспокоиться. А программка-то не работает. Она вообще даже не компилируется!

Сообщение отредактировал Visual1: 09.11.2009, 15:37:36

[xn80akxm]

чтобы на этапе определения и планирования уже знать на 100% какой должен быть проект????

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

[xxel]

Рекомендую не начинать с дельфи. Ибо оно ломает новичку представление о ... Короче много о чем.

Ломает представление не дельфи, а учителя-дебилы.

Очень рекомендую начать с жёстко - типизированного языка

... о! а еще наверно бывает типизация мягко-типизированная, бело- и пусшисто-.
Че за бред?! Типизация бывает строгой и слабой.

К тому же типизация в дельфях эквивалетна оной в С#, если не лучше, т.к.
не содержит идиотизма в виде "Неявное приведение типов в неоднозначных ситуациях"

PS Повторюсь... очень не рекомендую начинать с дельфи,

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

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

А это как раз пример из серии что типизация в C# так себе. Работает. но только на бумаге.
Конкретно в данном пример компилятор зачем-то, бессовсетно преобразовавет
Byte в Int32 перед сложением (возможно просто операция сложения для Byte не
определена), а назад преобразовать уже стесняется (и то хорошо)

ЗЫ

//Для хранения небольших целых чисел лучше использовать переменные
//типа byte, чтобы наиболее рационально использовать память компьютера.

Это было очень давно. Сейчас неактуально ибо компилер все одно выравняет на границу 32-бит, если с бубном не плясать и работа к чистыми byte гораздо накладнее

[dzid]

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

using System;

class Program
	{
		static void Main(string[] args)
		{
			//Для хранения небольших целых чисел лучше использовать переменные 
			//типа byte, чтобы наиболее рационально использовать память компьютера.
			byte a = 10;
			byte b = 15;
			byte c = a + b;
			//Вывести значение суммы на экран
			Console.WriteLine ("c = " + c);
		}
	 }

Ошибка здесь вроде бы ну совсем никак не может появиться. Переменные типа byte могут хранить значения от 0 до 255, поэтому насчет переполнения результата при сложении можно не беспокоиться. А программка-то не работает. Она вообще даже не компилируется!

Вообще лучше всего BASIC... Особенно один его очень специфичный диалект, где писали

10 PAPER NOT PI; INK NOT PI; RANDOMIZE USR VAL ("15616")

Кто помнит, нафига и почему?

[Visual1]

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

А это как раз пример из серии что типизация в C# так себе. Работает. но только на бумаге.

Не согласен. Не так себе, а очень даже. И работает отлично. В C# нет типа данных Variant, который есть в Visual Basic 6 и некоторых сценарных языках, так что типизация очень строгая. Однако можно объявлять переменные с обобщенным типом var, и компилятор во многих случаях способен сам определить истинный тип такой переменной. А если тип объекта до компиляции вообще неизвестен? Если он становится известен только на стадии выполнения? Для определения типа в C# есть средства получше, чем Variant. Но все это не для начинающих программистов.

Конкретно в данном пример компилятор зачем-то, бессовсетно преобразовавет
Byte в Int32 перед сложением (возможно просто операция сложения для Byte не
определена), а назад преобразовать уже стесняется (и то хорошо)

Не "зачем-то" и не "бессовестно". Это неизбежная расплата за общеязыковую исполняющую среду (CLR) и общую систему типов (CTS), единую сразу для нескольких языков с разными типами. Но опять же, это не для начинающих программистов.

ЗЫ

//Для хранения небольших целых чисел лучше использовать переменные
//типа byte, чтобы наиболее рационально использовать память компьютера.

Это было очень давно. Сейчас неактуально ибо компилер все одно выравняет на границу 32-бит, если с бубном не плясать и работа к чистыми byte гораздо накладнее

Странно как-то. По вашей логике, если работать с byte гораздо накладнее и без специальных плясок с бубном не рекомендуется, тогда не надо также использовать типы short (System.Int16) и ushort (System.UInt16). Нет?

Сообщение отредактировал Visual1: 09.11.2009, 18:14:35

[xxel]

Не согласен. Не так себе, а очень даже. И работает отлично. В C# нет типа данных Variant, который есть в Visual Basic 6 и некоторых сценарных языках, так что типизация очень строгая. Однако можно объявлять переменные с обобщенным типом var, и компилятор во многих случаях способен сам определить истинный тип такой переменной. А если тип объекта до компиляции вообще неизвестен? Если он становится известен только на стадии выполнения? Для определения типа в C# есть средства получше, чем Variant. Но все это не для начинающих программистов.

Так себе. Просто строгая, а не очень строгая. Примерно как в дельфи. И Variant тут не причем. Языки с очень строгой типизацией такой фигни как пример с byte не позволяют. Они четка заявляют что у них не определен оператор сложения для данного типа, а не как С# (ща мы втихаря конвертнем byte в int, вдруг проканает)
И эта... var это никакой не "обобщенный тип" это просто неявный тип, для последующего вывода типа переменной. И относится это также как и извесность типа только в рантайме к совсем другому критерию разделения типизации на категрии статической и динамической. Variant кстати относится вопросу о динамической типизации. И да... вспомнил.. Ща в 4-ой редакции C# запилят тип Dynamic и наступит всем счастье как в VB6.0

Не "зачем-то" и не "бессовестно". Это неизбежная расплата за общеязыковую исполняющую среду (CLR) и общую систему типов (CTS), единую сразу для нескольких языков с разными типами. Но опять же, это не для начинающих программистов.

Я даже представить боюсь откуда _это_ могло родиться. Надеюсь это не личные убеждения а цитирование не от мира сего сотрудников MS. Так вот немного о Жабе. Первые версии жабы были без дженерик типов. И среда исполнения жабамашины их не подерживала. Но потом рыданьями жабафилов в одной из редакций запилили дженерики. Но! Среда исполнения при этом осталась прежней! Она дженерики не поддерживала. А вот новый компилятор весь код с дженериками умудрялся компилить так что б все выполнялось на старой жабамашине, которая о дженериках даже не догадавалась. А еще есть такая исполняющя среда как CPU Intel/AMD неважно. Единая сразу для всех языков с разными типами, но вот компиляторы почемуто не требуют никакой "расплаты" за эту единую среду. Ну и насчет НетFramework'a. Есть достаточное кол-во компилаторов под Нет, которые на попытку написать аналог C#-ного

byte i = 1;
int y = 2;
Console.Write("={0}", i + y);

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

Console.Write("={0}", (int)i + y);

И снова ни о какой расплате за общеязыковую исполняющую среду (CLR) и общую систему типов (CTS) никто из них не подозревает. Никогда кривизна компилятора не может списываться на среду выполнения!

Странно как-то. По вашей логике, если работать с byte гораздо накладнее и без специальных плясок с бубном не рекомендуется, тогда не надо также использовать типы short (System.Int16) и ushort (System.UInt16). Нет?

Вывод совершенно верный. Смысла в [U]Int16 сейчас также нет. Все это издержки легаси и/или железа - только тогда использование оправдано. Вообще данный факт удивления вызывать это не должно. Достаточно вернуться к примеру с byte. Компилер "бессовестно" переводит все в Int32 (он даже предположить не может что комуто понадобиться вернуться в byte). И оператора + для byte нет по этой же причине. Не мытьем так катаньем MS отучит пользоваться мелкоразрядной арифметикой.

[Visual1]

Так себе. Просто строгая, а не очень строгая. Примерно как в дельфи. И Variant тут не причем. Языки с очень строгой типизацией такой фигни как пример с byte не позволяют. Они четка заявляют что у них не определен оператор сложения для данного типа, а не как С# (ща мы втихаря конвертнем byte в int, вдруг проканает)

Ничего подобного, не "втихаря конвертнем byte в int", а всегда допускается неявное преобразование, если оно безопасно. Именно так и обстоит с преобразованием byte в int. А вот обратное преобразование (из int в byte) безопасным не является. Поэтому ответственность за него возлагается на программиста, который должен заявить о своем намерении явно. Я думаю, это совершенно правильно, нормально и удобно. Да и стандарту языка не противоречит, если не ошибаюсь.

И эта... var это никакой не "обобщенный тип" это просто неявный тип, для последующего вывода типа переменной.

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

Я даже представить боюсь откуда _это_ могло родиться. Надеюсь это не личные убеждения а цитирование не от мира сего сотрудников MS.

А вы не бойтесь. Читайте Дж. Рихтера, и других компетентных авторов. У Рихтера (который не является сотрудником MS, если не ошибаюсь) об этом прямо сказано: "в CLR арифметические операции выполняются только над 32- и 64-разрядными числами" (CLR via C#, с. 115).

Так вот немного о Жабе. Первые версии жабы были без дженерик типов. И среда исполнения жабамашины их не подерживала. Но потом рыданьями жабафилов в одной из редакций запилили дженерики.

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

А еще есть такая исполняющя среда как CPU Intel/AMD неважно. Единая сразу для всех языков с разными типами, но вот компиляторы почемуто не требуют никакой "расплаты" за эту единую среду.

Вот не знал, что CPU Intel/AMD - это "исполняющая среда" Но если вы о процессорах, то да, JIT-компилятор CLR никакой расплаты не требует, а вот оптимизацию машинного кода таки делает аналогично компилятору неуправляемого кода C++ (если не лучше). Он может самостоятельно обнаружить конкретный процессор (например, Pentium-4) или 2-процессорную конфигурацию и оптимизировать промежуточный IL-код под них так, что управляемое приложение будет работать даже производительнее неуправляемого.

Ну и насчет НетFramework'a. Есть достаточное кол-во компилаторов под Нет, которые на попытку написать аналог C#-ного

byte i = 1;
int y = 2;
Console.Write("={0}", i + y);

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

Console.Write("={0}", (int)i + y);

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

Вывод совершенно верный. Смысла в [U]Int16 сейчас также нет. Все это издержки легаси и/или железа - только тогда использование оправдано. Вообще данный факт удивления вызывать это не должно. Достаточно вернуться к примеру с byte. Компилер "бессовестно" переводит все в Int32 (он даже предположить не может что комуто понадобиться вернуться в byte). И оператора + для byte нет по этой же причине. Не мытьем так катаньем MS отучит пользоваться мелкоразрядной арифметикой.

Оператор + для byte, по-моему, все же есть. Благо в C# перегрузка операторов поддерживается. А вообще, конечно, 64-разрядные ОС уже вполне повседневная реальность, и многоядерные процессоры х64 тоже. Так что да, пора приучаться. Может, это даже к лучшему.

[yedyge]

хех. с java тоже не советуют начинать
http://local.joelons.../wiki/?%9...?ам

[xxel]

Ничего подобного, не "втихаря конвертнем byte в int", а всегда допускается неявное преобразование, если оно безопасно. Именно так и обстоит с преобразованием byte в int. А вот обратное преобразование (из int в byte) безопасным не является. Поэтому ответственность за него возлагается на программиста, который должен заявить о своем намерении явно. Я думаю, это совершенно правильно, нормально и удобно. Да и стандарту языка не противоречит, если не ошибаюсь.

Безопасное оно или нет не важно. Важно, что никто не заказывал это преобразование делается оно втихаря, т.е. неявно (op_Implicit). А это уже не можут являться "очень строгой типизацией"

"в CLR арифметические операции выполняются только над 32- и 64-разрядными числами" (CLR via C#, с. 115).

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

Да причем тут Жаба и дженерики. Я эту тему вообще не трогал, зачем вы в сторону уводите. Жаба одноязычная среда, а .NET многоязычная. Поддержка многих языков (у которых некоторые типы не полностью совместимы)

Для жабамашины (и только для нее) есть такие языки как Груви и Кожура (у которых типы нефига не совместимы). Так что жабамашина вполне себе многоязычная.

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

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

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