Языки программирования в обучении

ALEX · 30-10-09 11:13:16

Linups_Troolvalds пишет:

static void Main()
За main, возвращающую void, следует бить головой об backspace. Читайте описания стандартов, вникайте.

Что тебе мешает использовать void, рекомендации, что в книжках пишут использовать int main() {return 0} ?

Namolem · 30-10-09 12:00:10

не знаю как в этом вашем C#, но в стандарте С++ разрешен только int main()
некотороые пишут код на "С++"

#include <iostream.h>

void main()
{
  cout <<"Hello";
}

а потом удивляются, почему это турбо с++ компилирует программу, а g++ выдает 4 ошибки. Значит линукс говно

Отредактировано Namolem (30-10-09 12:05:02)

city17 · 30-10-09 17:19:06

Невропаразитолог пишет:

city17 пишет:
PS. Про GOTO в школе лучше вообще не рассказывать.
Вот опять, ради чего, ограничивать кого-либо из-за технически необоснованной традиции ненавидеть GOTO? Уберите из языка все операторы DO...LOOP, FOR...NEXT, WHILE...AGAIN, UNTIL...AGAIN, GOSUB...RETURN, их модификации и комбинации, и... весь их функционал прекрасно реализуется одной-единственной GOTO с применением IF...THEN...ELSE. Говоря о традициях - вспомните ассмблер, команду безусловного перехода jpNNNN - прямой предок GOTO. Вот вам и преемственность.

Ограничение не из-за традиций, а для удобства. Ведь все те конструкции, которые вы привели, были созданы для облегчения написания программі, для улучшения читаемости, для абстрагирования от низкоуровневого кода. Бэйсик - язык высокого уровня, не вижу смысла для преемственности с ассемблером.
Я, и мои знакомые, на собственном опыте поняли, что код с GOTO усложняет разработку и сопровождение программы. Лично я услышал про гонения на GOTO случайно, уже после того, как перестал его использовать. С GOTO, наверное, просто писать что-то небольшое, но привычка использовать этот оператор везде, где только можно, закрепляется очень быстро, и отвыкать потом трудно.

Невропаразитолог пишет:

При совпадении, наращиваем счётчик промахов?

Да, тут я ошибся.

MOP3E · 30-10-09 17:26:22

city17 пишет:

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

Кстати, да. Довольно трудно. И ещё довольно трудно переезжать с языка типа классического Бейсика на язык без нумерации строк. По собственному опыту убедился. Хотя от GOTO отвыкал без особых проблем. Когда узнал, что можно обойтись без него, стало прикольно придумывать как это реализовать. В ассемблере JMP используется только потому, что там нет нормальных условных конструкций. В языках высокого уровня такой оператор - уже атавизм.

З.Ы. Программу с большим количеством GOTO называют "спагетти-программа".

ALEX · 30-10-09 19:08:58

Namolem пишет:

а потом удивляются, почему это турбо с++ компилирует программу, а g++ выдает 4 ошибки. Значит линукс говно

В Visual C++ что int main() {return 0}, что void main() - разницы нет. Всё прекрасно компилируется.

Linups_Troolvalds · 31-10-09 02:04:40

Что тебе мешает использовать void, рекомендации, что в книжках пишут использовать int main() {return 0} ?

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

Linups_Troolvalds · 31-10-09 02:10:28

В Visual C++ что int main() {return 0}, что void main() - разницы нет. Всё прекрасно компилируется.

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

ALEX · 31-10-09 02:25:20

Linups_Troolvalds пишет:

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

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

Namolem · 31-10-09 02:31:07

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

MOP3E · 31-10-09 03:09:03

Namolem пишет:

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

Вот тут есть коротенькая заметка о сравнении GCC и MSVC: www.reactos.org/ru/newsletter_63.html

Более неприятная проблема возникла в связи с тем, что GCC не предупреждал о функциях, вызывающих самих себя. Использование таких рекурсивных вызовов возможно, но не в этом случае, так как это приводит к бесконечному рекурсивному вызову. Проблема порождена заголовками в w32api, которые используются в mingw для разработки Windows. Например, в заголовке функция ExAllocatePoolWithQuotaTag была определена как ExAllocatePoolWithQuota. Это вызвало очень неприятную ситуацию, поскольку ExAllocatePoolWithQuota это просто вызов функции ExAllocatePoolWithQuotaTag, так как одна функция служит как оболочка для другой. Код, который был откомпилирован с использованием таких заголовков и пробовал использовать функцию ExAllocatePoolWithQuotaTag, вероятно застревал в бесконечном цикле, в конечном счете исчерпывая стек и вызывая "синий экран". Компилятор MSVC указал на эту проблему и выдавал предупреждение даже на самом низком уровне уведомлений, тогда как GCC не обращал на это внимания.

Mike22 · 23-11-09 16:39:30

Перл. Нахождение чисел Фибоначчи простейшей рекурсией:

sub fibo {
my $n = shift;
return 1 if $n < 3;
return fibo($n - 1) + fibo($n - 2);
}

for (1..10) {
print fibo($_)." ";
}

Это к слову об использовании половых извращений вида a,b = b, a+b

Mike22 · 23-11-09 16:42:35

Перл. Первая задача.

print "Введите A: ";
my $a = <>;
print "Введите B: ";
my $b = <>;

print ("A + B = ".($a+$b)."\n");

Mike22 · 23-11-09 16:52:58

Перл, мощь хешей. Числа фибоначчи.
my %h;
sub fibo {
my $n = shift;
return 1 if $n < 3;
$h{$n} = fibo($n - 1) + fibo($n - 2) unless exists $h{$n};
return $h{$n};
}

for (1..10) {
print fibo($_)." ";
}

Все результаты вычислений помещаются в хеш %h, откуда и будут извлекаться в случае повторных обращений.
Таким образом, вычислив, скажем, значение для n=9, вызов для n=10 не будет пробегать весь ряд заново, а сразу возьмет готовые значения для 8 и 9.

Armanx64 · 24-11-09 14:01:44

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

ReactOS 0.3.10 всё ещё находится в стадии разработки (alpha) и не готова для реального использования.
Проекту можно помочь несколькими способами: просто рассказывая о проекте своим друзьям, в блогах, на вебсайтах, конференциях, пожертвовав немного денег в Фонд ReactOS или потратить своё время и что-нибудь сделать (патч, перевод, форум, и т.д.).

все слышали?! А ну бегом помогать дармоедам деньгами и бесплатным трудом!

Архитектура NT была спроектирована командой под руководством David Cutler, бывшего ведущего разработчика системы VMS. Им потребовалось более 4 лет, чтобы соединить всё лучшее из UNIX, VMS и OS/2 и спроектировать архитектуру NT.

Так-то. Оказывается, NT включает в себя Unix, VMS и OS/2))))
Вообще-то, NT способна эмулировать Unix, но не включает. OS/2 - а кто там OS/2 писал? MS.
VMS - а это что за зверь такой?

Современные инкарнации типа Mac OS X предлагают красивый графический интерфейс на "верху" UNIX'а, что бы скрыть все системные детали и сфокусироваться в основном на начинающих пользователях, а не продвинутых профессионалов командной строки. С другой стороны, были созданы разные дистрибутивы Linux и BSD для серверного использования, и поэтому очень ориентированные на использование командной строки, текстовых файлов конфигурации и т.п.

Так-то детишки - оказывается, проффесионалы должны не дела свои делать, а допиливать чьи-то "оси")))

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

С каких пор этот самозагружаемый Wine(слон) стал лёгким? Да он и 30% Win2000 не может эмулировать

По сути, эта "ось" нужна для плавной пересадки юзверей на линукс.

Отредактировано Armanx64 (24-11-09 14:02:13)

Mike22 · 25-11-09 19:35:02

Пару слов в пользу изучения перла.

1. Всего четыре типа данных: скаляр (он же ссылка, строка или число), массив, ассоциативный массив и дескрипторы.

2. Никаких выносящих мозг взаимных конверсий между скалярными типами. Операции сложения и сравнения строк и чисел четко разделены. Каждый тип имеет характерный префикс ($@%) так, что его невозможно спутать с другим типом. Т.е. @a - это всегда массив. Соотв. путаница переменных и спец.слов - исключена.

3. Встроенная поддержка регулярных выражений. А без низ скоро никуда, они во всех редакторах появляются.

4. Огромное число умолчаний, не трахающих мозг, в том числе- прекрасная локальная переменная $_;

5. Великолепная область видимости "my", ограничивающая переменную текущим блоком.
Простой пример: for (my $i=0; $i < 10; $i++) {...} внутри цикла итератор $i виден, снаружи цикла - нет, причем, если снаружи цикла уже есть переменная $i, то она не испортится.

Вообще, всего три области видимости: our (общая), local (внутри блока и в вызванных из этого блока процедурах), my (строго внутри блока).

6. Для дрючки нерадивых учеников всегда есть опции strict и warning, которые требуют объявлять переменные, ругаются на некорректные операции (например, сложение undef и 1), и вообще, мотивируют на чистый код.

Отредактировано Mike22 (25-11-09 19:36:01)

Armanx64 · 25-11-09 19:38:50

Mike22, текст должен быть читабелен и понятен. Приведите пример a+b=c с вводом a и b с клавиатуры с пояснениями всех знаков. А то ваши предыдущие примеры больше похожи на эззотерические языки

Отредактировано Armanx64 (25-11-09 19:43:53)

Armanx64 · 25-11-09 19:42:18

Namolem, если в C# без void, то тогда в теле метода обязятельно наличие return

ALEX · 25-11-09 21:55:40

Armanx64 пишет:

Namolem, если в C# без void, то тогда в теле метода обязятельно наличие return

Ну как и в плюсах.

Mike22 · 26-11-09 21:41:58

Armanx64:
Это вопрос привычки. Стандартное обозначение переменных без выделения их спецсимволами, имхо, менее понятно и вносит путаницу.

print "Введите A: "; # Напечатать строку "Введите А:"
my $a = <>; # Объявить переменную $a и присвоить ей значение одной строки входного потока
print "Введите B: "; # # Напечатать строку "Введите B:"
my $b = <>; # Объявить переменную $b и присвоить ей значение одной строки входного потока

print ("A + B = ".($a+$b)."\n"); # Напечатать строку, являющуюся сложением строк "А + B = ", ($a + $b), "\n", где \n - стандартный перевод строки.

Из необходимых знаний:
1. Переменные объявляются словом my, our или local
2. Прочитать одну введенную строку можно так: <> или так <STDIN> или так readline(*STDIN)
3. Строки складываются "точкой", а числа - "плюсом". Поэтому, "1"+"1" это 2, а "1"."1" это "11"

Для сишных олдфагов есть кошерный sprintf()

Armanx64 · 26-11-09 21:52:33

Armanx64:
Это вопрос привычки. Стандартное обозначение переменных без выделения их спецсимволами, имхо, менее понятно и вносит путаницу.
print "Введите A: "; # Напечатать строку "Введите А:"
my $a = <>; # Объявить переменную $a и присвоить ей значение одной строки входного потока
print "Введите B: "; # # Напечатать строку "Введите B:"
my $b = <>; # Объявить переменную $b и присвоить ей значение одной строки входного потока
print ("A + B = ".($a+$b)."\n"); # Напечатать строку, являющуюся сложением строк "А + B = ", ($a + $b), "\n", где \n - стандартный перевод строки.
Из необходимых знаний:
1. Переменные объявляются словом my, our или local
2. Прочитать одну введенную строку можно так: <> или так <STDIN> или так readline(*STDIN)
3. Строки складываются "точкой", а числа - "плюсом". Поэтому, "1"+"1" это 2, а "1"."1" это "11"
Для сишных олдфагов есть кошерный sprintf()

$a = <> - странная конструкция, не находите? Зачем так мучаться?
int a уже не катит? или var a:integer?

Mike22 · 27-11-09 10:53:35

Armanx64:
Для желающих есть readline или <STDIN>, принципиальной разницы между readln(a) и $a = readline(<STDIO>) я не вижу. А $a = <>; так и вовсе проще запомнить.
А выделение переменных знаками $%@& - имхо, куда правильнее и намного читаемее, чем "классика", где переменные сливаются именами с функциями и кодовыми словами.

Типизация вызываем много ошибок. Например, в приведенном примере: var:a,b,c:uint64; - грубое нарушение условий задачи. Почему инт, да еще и неотрицательный? Что, -2.47 - не число?

Отредактировано Mike22 (27-11-09 11:08:08)

Armanx64 · 27-11-09 11:57:43

var:a,b,c:uint64; - а зачем вам uint64? int64 уже не хватает?)

Туго, очень туго.

А выделение переменных знаками $%@& - имхо, куда правильнее и намного читаемее, чем "классика", где переменные сливаются именами с функциями и кодовыми словами.

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

Теперь начинаю понмиать, почему линуксоиды ненавидят Delphi

MOP3E · 27-11-09 12:10:46

Mike22 пишет:

Armanx64:
Для желающих есть readline или <STDIN>, принципиальной разницы между readln(a) и $a = readline(<STDIO>) я не вижу. А $a = <>; так и вовсе проще запомнить.
А выделение переменных знаками $%@& - имхо, куда правильнее и намного читаемее, чем "классика", где переменные сливаются именами с функциями и кодовыми словами.
Типизация вызываем много ошибок. Например, в приведенном примере: var:a,b,c:uint64; - грубое нарушение условий задачи. Почему инт, да еще и неотрицательный? Что, -2.47 - не число?

Как раз вчера наткнулся на старую книжку по применению ЭВМ в учебных заведениях. Дык, там прямо сказано: язык для обучения должен содержать только необходимый минимум инструкций, должен быть прост в понимании и должен сразу выполняться на ЭВМ. То что здесь показано - это уже дополнительное усложнение конструкций языка, вероятно, удобное для профессионального программиста (как уже меня эти $ в PHP за*бали!), но непонятное для студента или школьника. Это было во-первых.

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

З.Ы. Нахрена эти все экранирующие символы, когда нормальный текстовый редактор с подсветкой высветит и ключевые слова, и имена функций, и переменные с константами?

Mike22 · 27-11-09 13:04:39

MOP3E:
Потому что, как раз школьники еще не знают всех ключевых слов и библиотечных функций.
Почему бы мне не создать переменную for, как сокращение слова formula? А нельзя, почему-то. И придется школьникам объяснять, что есть целая куча запрещенных названий. В перле же - жестко разделены переменные и все остальное. Хочещь переменную $for? Пожалуйста! Хоть $if. В итоге, требуется знать меньше - всего лишь, что любая скалярная переменная начинается с $, а не что "переменная может быть любой, кроме (список на сотни пунктов)"

Более того, перл как раз ругают за низкий порог синтаксической проверки. Т.е. если не использовать модель strict/warning, то перл "думает за программиста". Можно, к примеру, не объявлять переменные - при первом использовании он их сам "объявит" как переменную глобальной видимости. Не надо перечислять входные параметры функции - на вход приходит массив параметров, так что, можно его как распарсить строкой вида:
my ($a, $b) = @_; так и использовать напрямую вообще не декларируя ничего: $_[0] - первый аргумент функции.
Масса стандарных функций, если им не указать входных данных, используют переменную $_, в т.ч. для строковых операций.
Пример:
my @ar = ("111", "222", "sdas22");
for (@array) {
next if/\D/; # Проверяет переменную цикла по умолчанию ($_) на соответствие регулярному выражению /\D/
}
То же самое, но полноценно записаное:
for my $i (@array) {
next if ($i=~m/\D/);
}

Позволяет не указывать скобки, или оставлять запятую в конце перечислений. Например @a= ("a", "b", "c",);

Функции могут возвращать любой тип. Никакой предекларации. Хочешь - возвращай массив, хочешь - число, хочешь - undef.

Armanx64 · 27-11-09 13:32:33

Допустим, вариант с $ оказался интересным, хотя мне пофигу на названия переменных, лишь бы сам не забыл.

А кто-нибудь приведёт пример на Ruby? А то в apple на него переходят с перла и питона...

Форум StopLinux

Объявление

#26 30-10-09 11:13:16

Re: Языки программирования в обучении

#27 30-10-09 12:00:10

Re: Языки программирования в обучении

#28 30-10-09 17:19:06

Re: Языки программирования в обучении

#29 30-10-09 17:26:22

Re: Языки программирования в обучении

#30 30-10-09 19:08:58

Re: Языки программирования в обучении

#31 31-10-09 02:04:40

Re: Языки программирования в обучении

#32 31-10-09 02:10:28

Re: Языки программирования в обучении

#33 31-10-09 02:25:20

Re: Языки программирования в обучении

#34 31-10-09 02:31:07

Re: Языки программирования в обучении

#35 31-10-09 03:09:03

Re: Языки программирования в обучении

#36 23-11-09 16:39:30

Re: Языки программирования в обучении

#37 23-11-09 16:42:35

Re: Языки программирования в обучении

#38 23-11-09 16:52:58

Re: Языки программирования в обучении

#39 24-11-09 14:01:44

Re: Языки программирования в обучении

#40 25-11-09 19:35:02

Re: Языки программирования в обучении

#41 25-11-09 19:38:50

Re: Языки программирования в обучении

#42 25-11-09 19:42:18

Re: Языки программирования в обучении

#43 25-11-09 21:55:40

Re: Языки программирования в обучении

#44 26-11-09 21:41:58

Re: Языки программирования в обучении

#45 26-11-09 21:52:33

Re: Языки программирования в обучении

#46 27-11-09 10:53:35

Re: Языки программирования в обучении

#47 27-11-09 11:57:43

Re: Языки программирования в обучении

#48 27-11-09 12:10:46

Re: Языки программирования в обучении

#49 27-11-09 13:04:39

Re: Языки программирования в обучении

#50 27-11-09 13:32:33

Re: Языки программирования в обучении

Подвал форума