> ADAоченьхороший язык, который с успехом используется во > многих сложных проектах. Описывать его плюсы здесь не > стану, в Сети есть объективные сравнения. Попытался найтиобъективныесравнения. Ничего кроме общих слов не обнаружил. Однако, помнится, была Ada83 и ей пророчили колоссальное будущее. Потом была Ada95 - говорили, что "уж теперь она доведена до совершеноства". Были ли еще - не знаю, но пока ни Ada95, ни Ada83 не прижилась. Если это такой хороший язык программирования, почему же так происходит? Насчет "многих сложых проектах" не знаю, но то что "многих" - не правда. У меня есть куча знакомых программеров, которые учавствуют в сложных проектах. Про Аду я от них никогда не слышал.
Единственное объективное преимущество (если я правильно понял очень размытые формульровки) - "многопоточночть" внутри самой программы. То бишь если я пишу симулатор гонок, то я могу ввести нексолько параллельно выполняющихся функции для описания поведения каждой из машин и заботиться о параллельном выполнении обоих будет уже сама Ада, а меня это не касается. Это если я все правильно понял из найденных ФАКов. Однако зачем оно нужно бегиннерсу?
> Часть истории это C/C++, ну а ADA 2005 - IMHO именно > "главное" будущее gcc (http://www.gnat.com/ada_2005.php). Очень громкое заявление и ничем не обоснованное. ИМХО, вообще бред. Приведи аргументы.
> .NET и C# уже в 99% используются в тех-же около-плюшевых > нишах что и Visual Basic. Java реально живет только в > "чисто аппликухах". Я с ними не знаком и не ощущаю в них потребности. Здесь ничего не скажу.
> ASM нужен для понимания того "как все на самом деле", а > Эйфель -правильныйобъектный язык программирования. С > последним советую ознакомиться. Насчет ASM'а согласен, а про Effel никогда не встречал никаких заметок. Но опять же: тема у нас "с какого языка начинать учить азбуку программировния", а ты начинаешь говорить проправильноеООП. ИМХО, ООП в "азбуку" не входит. Да и вообще в 90% случаях объекты с классами лепят там, где они не нужны. И так люди совсем уже отупели от этих объектов. Видел когда-нибудь человека, который начинал изучение программирования с обектно-ориентированного языка? Они даже для print "Hello world" вызывают метод класса.
Про Effel могу сказать то же самое, что и про Ada - если он такой хороший, то почему его никто не использует? А для изучения объектов хорошо пригодитсялюбаякнижка по самой теории ООП и почти любой язык программирования, где объектами даже не пахнет - в большинстве случаев объектный подход можно реализовать самому (правда, с некоторыми ограничениями, но зато придёт понимание).
На одном сайте натолкнулся на вопрос:
"с какого языка начинать учить азбуку программировния - с PASCAL (DELPHI) или идти путем Си (Java)?"
И несколько ответов:
с Бэйсика
с Паскаля
с любого структурированого, но лучше с Паскаля
по-любому лучше с Бэйсика.
Предлагаю обсудить эту тему. На мой взгляд лучше Паскаль.
Че-то отвлеклись все. Может пора закрывать ветку? Или не надо?27.10.05 18:01 Автор: Fighter <Vladimir> Статус: Elderman
Жалко только что про яву мало спорят. Я очень люблю когда при мне говорят слово "кроссплатформенный". У меня сразу слюноотделение резко повышается и может родимчик приключиться. Не знаю почему.
Потом z0 проснулся неожиданно - тоже хорошо. Когда ж мы в баню-то пойдем, родное сердце?! Как раз снежок выпал, сейчас самое милое дело на фонари залиться и выскакивать из парилки в сугроб во дворе :)
Где-то на 3-й странице рассказывают разницу между объектами и структурами - всюду жизнь!
"призрак видел все!"(с)28.10.05 14:31 Автор: z0 <z0> Статус: Member
Рисовать то я рисовал, но только для отчетности (на некоторых лабораторных в отчете надо было привести блок-схему). Сначала программа, а потом по этой программе - блок-схема :-)
Ту дык и с чего бегинерсу лучше начать? С Си или блок-схем?26.10.05 15:46 Автор: Den <Денис Т.> Статус: The Elderman
Не видел ни одной уважаемой книжки по программированию, где были бы нарисованы эти уродцы. Книжки с UML видел, хотя он мне и не особо нравится, а вот с блок-схемами - нет.
На свалку Истории?26.10.05 17:03 Автор: Den <Денис Т.> Статус: The Elderman
Они морально устарели? Принципы блок-схем перестали соответсвовать ныне используемым языкам?
Блок-схемы или некоторое их подобие перестали использовать при разработке больших проектов на этапе проектирования для связи между компонентами и модулями программ?
Но на физика. Из программухи были только численные методы. Сдавали проги, объясняя устно как все работает.
а функциональные языки лучше вобще не учить или просто начинать с них не стоит??25.10.05 21:55 Автор: zelych Статус: Member Отредактировано 25.10.05 21:55 Количество правок: 1
Но так как язык определяет вещи о которых ты способен ДУМАТЬ (не помню как назывался опыт, но для естественных языков это доказанный факт), то лучше выучить как можно больше языков и желательно с поддержкой как можно большего числа парадигм
--------------
Только что подумал, что ты мог неправильно употребить выражение функциональные языки (где то там внизу уже встречалось такое неправильно употребление). Функциональные языки это Lisp, Haskel, ML (OCaml, SML). Функиональную парадигму в той или иной мере поддерживают также мультипарадигменные языки типа python, tcl, ruby, perl
C/C++ и Pascal/Delphi никак нельзя назвать функциональными языками (хотя я встречал библиотеку темплейтов для C++, которая добавляет поддержку функциональной парадигмы в C++ - intelib называется)
Если же имелись в виду процедурные языки (не ООП), то учить их конечно тоже стоит. Если сильно хочется можно и начинать с них же.
Начинать надо с того, что ближе к машине27.10.05 05:15 Автор: Zef <Alloo Zef> Статус: Elderman
Тем более, что ты ведь не знаешь, какие задачи жизнь тебе подсунет. Зачем загружать себя предметно-ориентированной лабуой, котоая, возможно, никогда не понадобится? Надо знать, как эта лабуда (компилеры) функционирует и пишется, тогда, при необхоимости легко осоишь любой язык, или создашь новый под конкретную задачу.
В этом смысле С - разумный компромисс между машинным и человеческим. Он уже понятен человеку, но на нем еще можно сделать все, что угодно. Другие языки позволяют делать только то, для чего они предназначены.