Re[4]: Чем плох Паскаль?
От: kov_serg Россия  
Дата: 19.06.19 11:06
Оценка: +2
Здравствуйте, pagid, Вы писали:

C>>А зачем?

P>А зачем в школе предмет — информатика? Может и не нужен но если нужен, то как минимум про байты с битами придется рассказать, про организацию памяти, в простейшем виде, с линейной адресацией наверно тоже. Можно конечно предполагать, что библиотекарше и секретарше достаточно будет знать почти человеческий SQL Excel Питон. Но он точно школьку нужен больше, чем байт с битом?

В идеале инфоратика должна научить человека как объяснить машине сделать то что ему нужно. И желательно как можно проще.
Например заставить компьютер считать количество витков на трансформаторе, перевести список контактов из exel в iphone, распечатать шаблон детали или
решить диф уравнения для определения распределения температур и т.п.

И еще показать к чему приводит использование компьютеров, когда не понимаешь что хочешь.
и показать весь этот бл%^&кий цирк каменный век по подготовке к работе с нашими гос услугами личными, кабинетами, цифровыми подписями и криптопровайдерами
Re[6]: Чем плох Паскаль?
От: Mr.Delphist  
Дата: 19.06.19 15:03
Оценка:
Здравствуйте, pagid, Вы писали:

P>Здравствуйте, MamutArGud, Вы писали:


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

P>Так это как раз и есть арифметика, а не матанализ.

Арифметикой это кажется, пока знаешь только один способ организации памяти. Что делать — разбаловала нас линейная адресация.
Re: Чем плох Паскаль?
От: _hum_ Беларусь  
Дата: 19.06.19 15:10
Оценка:
Здравствуйте, Cicero, Вы писали:

C>Очень часто это слышу: Паскаль(иногда конкретизируют: Turbo Pascal) не подходят для обучения программированию.

C>Обычно аргументов нет. Самый "сильный" аргумент — это несовременный!

Тоже в свое время думал, на чем преподавать информатику (1 курс) тех.вуза. Остановился на PascalABC.Net.
Достоинства:
— максимально нацелен на то, чтобы обучаемый понял базовые концепты классического императивного программирования, не отвлекаясь на всякие-разные технические детали;
— разработчики постарались внести новшества, позволяющие приблизить его к современным языкам (например, переменные можно определять в теле программы, есть автовывод типов, анонимные функции, динамические массивы и т.п.);
— минималистическая IDE, содержащая все что нужно для знакомства с базовыми концептами работы с IDE (текстовый редактор с автоформатером и интелисенс, инструменты отладки, запуска).


Недостатки:
— остались атавизмы вроде "константы определяются только за пределами тела программы";
— наверное, из-за того, что язык построен на базе платформы .net, и авторы старались использовать ее возможности, появилась некоторая мешанина, не всегда дающая последовательно излагать материал. Например, из языка убрали возможность выделения массива заданного размера в динамической памяти, видимо, посчитав, что это не нужно, потому как есть заимствованный тип данных "динамический массив". Но, как по мне, это неправильно, потому как обучающийся не сможет полностью понять внутреннюю логику работы такого динамического массива без понимания того, что такое массив в динамической памяти, что такое ссылка/указатель, что такое класс/объект. Есть и другие вылезающие моменты технического характера (типа, статические массивы являются обычными типами, а динамические — ссылочными; статические массивы не могут передаваться в функцию через параметр без предварительного объявления типа-алиаза для этого параметра, а динамические можно, и т.п.);
— проблема с программированием GUI; вроде, какие-то попытки дать возможность в языке попробовать и это писать, но выглядят слишком коряво;
— осталась многословность Паскаля (эти begin end в более-менее нетривиальной программе выглядит чудовищно).
Re[7]: Чем плох Паскаль?
От: pagid Россия  
Дата: 19.06.19 15:49
Оценка:
Здравствуйте, Mr.Delphist, Вы писали:

MD>Арифметикой это кажется, пока знаешь только один способ организации памяти. Что делать — разбаловала нас линейная адресация.

Остальное школьникам и не к чему, мы же про школьный курс информатики.
Re[8]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 19.06.19 19:30
Оценка: :)
Здравствуйте, Mr.Delphist, Вы писали:

C>>Во всех современных языках управление зависимостями, если не в самом языке, то в стандартной библиотеке.

MD>Имя, сестра! Имя! (ц)
Go (modules), Rust (Cargo), Ruby (Gems), Python (PIP), Java (Maven).

MD>Как именно управляется зависимость в C++ STL?

С++ — это не современный язык.
Sapienti sat!
Re: Чем плох Паскаль?
От: LaptevVV Россия  
Дата: 20.06.19 04:15
Оценка:
C>Выскажу свое мнение:
C>Для обучения в школе как первый язык программирования с которым человек встречается Паскаль очень даже подходит.
В российских школах — как второй.
Или параллельно с русскоязычным.
Даже Константин Поляков, который преподает в родной питерской школе в профильном классе, высказался у себя на сайте, что первый язык должен быть русский.
В своем учебнике по информатике для профильных классов он так и написал — параллельно.
Слева — КуМир, справа — Паскаль.
Все основы параллельно, а потом, где указатели начались — уже только паскаль.

И еще.
Современен/несовременен — это мода.
Си, Фортран — тоже несовременны.
Если кто скажет, что они развиваются, а паскаль — нет, то это ерунда.
Смотрите Оберон и Зоннон.
Фактически — нет конторы, которая поддерживала бы паскаль на рынке.
Вот и все несовременность.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[18]: Чем плох Паскаль?
От: Sharowarsheg  
Дата: 20.06.19 04:29
Оценка:
Здравствуйте, netch80, Вы писали:

N>Тогда — несерьёзный подход. В школе ещё 99% не знают точно, кем они станут, и учить надо всему понемногу.


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

N>>>Только педагог с опытом знает, как именно это обучение окупается (если не идёт явным насилием).

S>>Нет, это не правда. Через много лет после обучения я знаю, что и где окупилось, а что нет, а что и не могло окупиться.

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


N>Именно, что кто не профессионал в педагогике, чаще всего не понимает принципов.


Я думаю (на основании своего опыта с профессионалами), что здравого смысла вполне достаточно.
Re[19]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.06.19 05:24
Оценка:
Здравствуйте, Sharowarsheg, Вы писали:

N>>Тогда — несерьёзный подход. В школе ещё 99% не знают точно, кем они станут, и учить надо всему понемногу.

S>Учить нужно понемногу и желательно так, чтобы это было применимо к реальной жизни, а массивы в это не влезают.

Если массивы не влезают, то только потому, что словари берут на себя их роль.
Словари — влезают сразу и серьёзно. Любая реальная задача включает в себя поиски и модификации в каком-то хранилище по ключу.

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


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

N>>>>Только педагог с опытом знает, как именно это обучение окупается (если не идёт явным насилием).

S>>>Нет, это не правда. Через много лет после обучения я знаю, что и где окупилось, а что нет, а что и не могло окупиться.
S>>> Это не слишком сложно, чтобы нужно было иметь диплом педагогического университета, чтобы понять это.
N>>Именно, что кто не профессионал в педагогике, чаще всего не понимает принципов.
S>Я думаю (на основании своего опыта с профессионалами), что здравого смысла вполне достаточно.

Нет. Потому что люди настолько разные, что здравый смысл, основанный только на персональном опыте, будет работать только в пределах окружения этой же персоналии.
Для результатов, которые годятся хотя бы для соседей, надо исследования, статистику, обобщение и формулировку принципов.
The God is real, unless declared integer.
Re[2]: Чем плох Паскаль?
От: pagid Россия  
Дата: 20.06.19 05:38
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>В своем учебнике по информатике для профильных классов он так и написал — параллельно.

LVV>Слева — КуМир, справа — Паскаль.
LVV>Все основы параллельно, а потом, где указатели начались — уже только паскаль.
А разве не во всех учебниках так? Во всяком случае в том, который я видел точно так же. И на ЕГЭ тоже на выбор.

LVV>Если кто скажет, что они развиваются, а паскаль — нет, то это ерунда.

LVV>Смотрите Оберон и Зоннон.
Но они почти никого не заинтересовали. Ну и они не Паскали

LVV>Фактически — нет конторы, которая поддерживала бы паскаль на рынке.

Пока Борланд поддерживала ей пришлось настолько изменить язык, что от Паскаля там только несколько ключевых слов осталось.
Re[13]: Чем плох Паскаль?
От: pagid Россия  
Дата: 20.06.19 05:49
Оценка:
Здравствуйте, netch80, Вы писали:

N>Например, берём Unix API:

N>int open(аргументы);
N>реально два значения — дескриптор и код ошибки (который поступает в errno).
Тут есть своя логика, примитивная конечно.
Признак ошибки -1 в возвращаемом значении, если ошибки нет, то её код не нужен совсем.

N>int pipe(int fildes[2]);

N>три значения — два дескриптора и код ошибки.
N>int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
N>три выходных — код ошибки, сокет и адрес.
N>И так далее.
N>Windows? То же самое: у до чёрта функций код ошибки передаётся боковым каналом, его надо доставать через GetLastError(). И аналог такого accept() есть, и многое другое.

Это все забавно, но что получается, что языкам, где не предусмотрено возвращение нескольких значений путь в эту новую "правильную" ОС с "правильными" системными вызовами будет закрыт? Или придется лепить страшные костыли.
Re[6]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.06.19 06:16
Оценка: +1
Здравствуйте, Mr.Delphist, Вы писали:

C>>И где тут строгость? Просто идиотское ограничение — оба массива идентичны.

MD>Похоже, насчёт строгой типизации нам говорить ещё рано

Верно замечено — вам, похоже, таки рано.

Там, где не рано, делают, например, так (близко к Ada)


type real = float;

type temperature = new float;

type altitude = new float;

type foo = struct {
  bar: integer;
  baz: float;
};

type buka = foo;

type ziuka = new foo;


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

А теперь сюрприииз — в том самом Go, в котором вы увидели только duck typing, то же самое:

type real = float
type altitude float
type temperature float

type foo struct {
  bar int
  baz float
}

type buka = foo
type ziuka foo


с тем же результатом — buka идентичен foo (алиас для него), real = float во всём использовании, а вот ziuka, altitude и temperature отделены.

А изображать "строгую типизацию" разделением типов просто из-за идентичного объявления массива в двух местах... ну да, Вирту в Модуле такое приснилось. Только повторять это на трезвую голову никто не хочет.

MD> Синтаксис JS строже чем у Pascal... Разрешите тогда упомянуть классику: https://www.destroyallsoftware.com/talks/wat


Я не защищаю тут позицию Cyberaxʼа, но вы синтаксис от семантики не отличаете.

С синтаксисом у JS, таки, есть проблемы, но в другом, например:

  return
    1;


он вернёт null.
В ролике про WAT про это ни слова, там другие хохмы (да, реальные и грустные).

Кстати, ещё один из ваших мифов про Go:

MD> Go — основан на duck-typing (ещё бы, наследования-то не завезли)


Завезли:

A field declared with a type but no explicit field name is called an embedded field. An embedded field must be specified as a type name T or as a pointer to a non-interface type name *T, and T itself may not be a pointer type.

A field or method f of an embedded field in a struct x is called promoted if x.f is a legal selector that denotes that field or method f.

Given a struct type S and a defined type T, promoted methods are included in the method set of the struct as follows:

If S contains an embedded field T, the method sets of S and *S both include promoted methods with receiver T. The method set of *S also includes promoted methods with receiver *T.
If S contains an embedded field *T, the method sets of S and *S both include promoted methods with receiver T or *T.


И это наследование ещё и множественное. Вот виртуальных функций в нём, да, нет и не предвидится, поэтому по сравнению с традиционным наследованием типа C++/Java/etc. оно инвалидное.
The God is real, unless declared integer.
Re[7]: Чем плох Паскаль?
От: AlexRK  
Дата: 20.06.19 07:25
Оценка:
Здравствуйте, netch80, Вы писали:

N>и с этого момента buka — просто алиас для foo, а ziuka — намеренно отдельный тип, все имплицитные соответствия, конверсии и присвоения запрещены, то же для температуры (ей высоту просто так не присвоишь, матчинг функции не будет происходить, и так далее).


Не уверен, что эти фичи являются показателем строгости типизации. ИМХО, строгая типизация — это когда нет неявных преобразований между типами разной структуры. И паскаль этому определению вполне соответствует.

N>А теперь сюрприииз — в том самом Go, в котором вы увидели только duck typing, то же самое:

N>с тем же результатом — buka идентичен foo (алиас для него), real = float во всём использовании, а вот ziuka, altitude и temperature отделены.

А, ню-ню.

package main

import (
    "fmt"
    "net"
)

func main() {
    var foo net.IP
    var bar []byte = []byte{1, 2, 3, 4}

    foo = bar       // OH SHI~

    fmt.Println(foo)
}
Re[2]: Чем плох Паскаль?
От: elmal  
Дата: 20.06.19 08:31
Оценка: +2
Здравствуйте, LaptevVV, Вы писали:

LVV>Вот и все несовременность.

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

Соответственно основная проблема паскаля — для новичков он в современном понимании слишком сложен. Есть языки проще. На которых можно быстро написать что то простое и полезное. Например можно быстро написать базовую проверку орфографии во входном файле. На паскале это не совсем тривиальная задача, на других языках это писать 15 минут. Соответственно вопрос — нахрена отпугивать новичков излишней сложностью и низкоуровневостью на ровном месте? Что, современные детишки или студенты стали на порядок более умными, чем были при СССР чтоль, соответственно на джавах питонах для них будет слишком просто, нужно искусственно усложнить?
Re[8]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.06.19 14:26
Оценка:
Здравствуйте, AlexRK, Вы писали:

N>>А теперь сюрприииз — в том самом Go, в котором вы увидели только duck typing, то же самое:

N>>с тем же результатом — buka идентичен foo (алиас для него), real = float во всём использовании, а вот ziuka, altitude и temperature отделены.

ARK> А, ню-ню.

ARK> foo = bar // OH SHI~

Читайте внимательнее, вот и не будет "ню ню" или "OH SHI~":

package main

import (
    "fmt"
    "net"
)

func main() {
    type barray []byte // вот это и есть определение нового типа
    var foo net.IP
    var bar barray = []byte{1, 2, 3, 4}

    foo = bar       // ага!

    fmt.Println(foo)
}


и результат:

./prog.go:13:9: cannot use bar (type barray) as type net.IP in assignment


Не завели новый тип, воспользовались при определении переменной просто массивом — получили совместимость.
И если в первой строке main вставить '=' -скомпилируется.

ARK> Не уверен, что эти фичи являются показателем строгости типизации. ИМХО, строгая типизация — это когда нет неявных преобразований между типами разной структуры. И паскаль этому определению вполне соответствует.


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

А Паскаль — не соответствует.
Например, в нём нет запрета неявной конверсии int во float (по Borland; real — по Вирту), хотя она может дать потерю данных.
The God is real, unless declared integer.
Отредактировано 20.06.2019 14:39 netch80 . Предыдущая версия . Еще …
Отредактировано 20.06.2019 14:33 netch80 . Предыдущая версия .
Отредактировано 20.06.2019 14:30 netch80 . Предыдущая версия .
Отредактировано 20.06.2019 14:29 netch80 . Предыдущая версия .
Re[14]: Чем плох Паскаль?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 20.06.19 14:39
Оценка: +1
Здравствуйте, pagid, Вы писали:

N>>Например, берём Unix API:

N>>int open(аргументы);
N>>реально два значения — дескриптор и код ошибки (который поступает в errno).
P>Тут есть своя логика, примитивная конечно.
P>Признак ошибки -1 в возвращаемом значении, если ошибки нет, то её код не нужен совсем.

Это просто такой стиль проекции ответа {ok, Handle} | {error, Error}.
Точно так же как значение NULL для указателя (Хоар плачется, что это была ошибка, но на момент введения это было отличным выходом).
И это не единственный вариант стиля.
Например, возврат 0 из read() это вариант показать ошибку EOF. Просто EOF как бы принято считать не совсем ошибкой, потому оно не выделяется.
А вот в раннем SunOS nonblocking I/O был флаг FIOASYNC, который давал при отсутствии данных в данный момент — 0 вместо {-1, EAGAIN}, и путался с честным EOF — из-за чего его и отменили.
А могли сделать наоборот — 0 как признак ошибки вместо реального ответа, а EOF внести в errno. Тоже метод, хоть и менее практично.

N>>int pipe(int fildes[2]);

N>>три значения — два дескриптора и код ошибки.
N>>int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
N>>три выходных — код ошибки, сокет и адрес.
N>>И так далее.
N>>Windows? То же самое: у до чёрта функций код ошибки передаётся боковым каналом, его надо доставать через GetLastError(). И аналог такого accept() есть, и многое другое.

P>Это все забавно, но что получается, что языкам, где не предусмотрено возвращение нескольких значений путь в эту новую "правильную" ОС с "правильными" системными вызовами будет закрыт? Или придется лепить страшные костыли.


Придётся лепить ровно такие же костыли, как и сейчас: заполнение нескольких раздельных значений по указателям, заполнение структуры по указателям, возврат структуры явным образом (на уровне конвенции превращающемся опять же в указатель на структуру). Ничего нового.
The God is real, unless declared integer.
Отредактировано 21.06.2019 4:42 netch80 . Предыдущая версия .
Re[9]: Чем плох Паскаль?
От: AlexRK  
Дата: 20.06.19 14:52
Оценка:
Здравствуйте, netch80, Вы писали:

N>Не завели новый тип, воспользовались при определении переменной просто массивом — получили совместимость.


Совместимость, идущую вразрез с духом golang, ибо алиаса в явном виде нет.

ARK>> Не уверен, что эти фичи являются показателем строгости типизации. ИМХО, строгая типизация — это когда нет неявных преобразований между типами разной структуры. И паскаль этому определению вполне соответствует.

N>Непрактично.
N>Лучше так: строгая типизация — это когда нет неявных преобразований, которые явно запрещены, могут потерять данные или принципиально изменить семантику операций со значениями.

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

N>Например, в нём нет запрета неявной конверсии int во float (по Borland; real — по Вирту), хотя она может дать потерю данных.


https://ideone.com/Vctxcc

program ideone;
var
    A: Real;
    B: Integer;
begin
    A := 33;
    B := A;
    Write(B);
end.


prog.pas: In main program:
prog.pas:7: error: incompatible types in assignment




N>А Паскаль — не соответствует.


Как видим, соответствует.
Re[10]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 20.06.19 16:57
Оценка:
Здравствуйте, AlexRK, Вы писали:

ARK>
ARK>program ideone;
ARK>var
ARK>    A: Real;
ARK>    B: Integer;
ARK>begin
ARK>    A := 33;
ARK>    B := A;
ARK>    Write(B);
ARK>end.
ARK>

ARK>
Нужно наоборот — присвоить integer к float'y. При этом возможна потеря точности, если integer достаточно большой.
Sapienti sat!
Re[11]: Чем плох Паскаль?
От: AlexRK  
Дата: 20.06.19 17:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нужно наоборот — присвоить integer к float'y. При этом возможна потеря точности, если integer достаточно большой.


А! Пардон, я неправильно прочел. Да, наоборот можно. Но это почти везде можно.
Re[6]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 20.06.19 17:38
Оценка:
Здравствуйте, Mr.Delphist, Вы писали:

C>>Go, Rust, даже JavaScript.

MD>Синтаксис JS строже чем у Pascal... Разрешите тогда упомянуть классику: https://www.destroyallsoftware.com/talks/wat
Я про синтаксис, а не семантику.

C>>Из современных — Go, Rust, Elm.

MD>Go — основан на duck-typing (ещё бы, наследования-то не завезли), и это Строгая Типизация? Лол, рофл, что там далее по списку.
Не основан. Просто использует интерфейсы вместо наследования классов, статически проверяемые, кстати.

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

Нет. Rust — это чисто практический язык, который используется (в том числе) для переписывания Firefox.

MD>E... простите, ЧТО? А, гугл подсказывает, что это препроцессор для JS, который используют все три компании, которые про него слышали. Потрясающий production!

Мы его используем.

C>>И где тут строгость? Просто идиотское ограничение — оба массива идентичны.

MD>Похоже, насчёт строгой типизации нам говорить ещё рано
То есть?
Sapienti sat!
Re[10]: Чем плох Паскаль?
От: Cyberax Марс  
Дата: 20.06.19 17:46
Оценка:
Здравствуйте, pagid, Вы писали:

C>>Ну да, рассказать можно и даже нужно, в качестве заметки на полурока. Заниматься разборами представления чисел в памяти — в базовом курсе не нужно.

P>А в углубленном?
Это смотреть уже на углублённость.

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

Я бы даже проскочил мимо шестнадцатеричной системы.

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

Самое смешное, что у меня на уроках в школе как раз IEEE 754 было. Практически единственная вещь, которую я не знал сам тогда.

C>>Есть мнение, что так и надо делать.

P>Как?
Вообще не преподавать информатику.

C>>Я знаю людей (не программистов), которые ничерта не понимают в основах программирования, но пишут вполне неплохие скрипты на Питоне или Matlab. Так что я не вижу никаких проблем в том, что будет больше упор на практические стороны.

P>То есть на уроках информатики должны учить писать скрипты на Питоне, Matlab и наверно пользоваться Excel'ем?
Вполне возможно.

P>Ну может и так Хотя Питон в такой раскладке я бы из списка выбросил, Excel там чуток и так изучают, что там с Matlab и нужен ли он не знаю.

Всё-таки нужен какой-то язык хотя бы показать. Питон тут подойдёт как раз неплохо.
Sapienti sat!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.