LINUX.ORG.RU

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


1

7

Понятно, что Java - наверное самый мэйнстрим на текущий момент, ну с C#(Mono)(я не рассматриваю здесь пыхпых, джаваскрипт и прочий веб), но мне известна(как и большинству местных) статья, что изучение с Явы вредно для мозгов.
И вот, столкнувшись с тем, что отданные под моё руководство студенты 3го курса не сильно способны заниматься программированием на С++, задумался, как решить эту проблему, избегая 2х тупиков - делать всё за них, и выгнать их.
Допуская, что производительность языка не нужна(хотя, ввиду того, что делаем мы в основном числодробилки, это очень сильно допущение) и вообще у нас под рукой кластер, какой язык посоветует ЛОР, помогающий развить мозг молодых учёных до уровня С/С++? Да и вообще, список годных для обучения, и негодных соответственно. Думал было python, но тем не в нём производительность недостаточная, а самому реализовывать затратные вещи на С пока не хочется.
Update: vb и delphi не Ъ ввиду того, что я то под линуксом сижу. Update 2: всё, наработанное за время использование предложенного языка, не хочется терять, поэтому хорошо бы, если б можно было соединять уже готовые вещи с C/C++. Насчёт pascal я просто никогда такого не желал, там такое есть?

★★★★

Последнее исправление: aptyp (всего исправлений: 2)
Ответ на: комментарий от Miguel

haskell с интегралами или что?

Именно. Какая связь-то?

Декларативный, более менее привычная для математиков привыкших к размышлениям в разрезе типов нотация.

haskell - неплохой dsl для записи математических формулировок.

Кхм. Сомнительное утверждение, как минимум.

То есть, плохой?

Я вот смотрю, например, на «лемму о змее» и в упор не представляю, как её хотя бы начать записывать на хаскеле.

Хз что такое лемма о змее, а под пивасик расчехлять влом.

alienclaster ★★★
()
Ответ на: комментарий от shty

не за саму дельфи, и даже не за использование ея, а за преподавание с использованием оной

Ну так бы и сказал :) Вообще, тренд такой был. RAD и все такое, мол плюсы и прочий низкоуровневый ужос скоро-скоро отомрет нафиг, инфа 100%! - вот щас диаграмки «потоков данных» в ErWin нарисуем - а код сам напишется. Доходило до дипломов по совсем визуальным языками, типа http://ru.wikipedia.org/wiki/Дракон_(алгоритмический_язык), только не в rocket science, а как бы для обучения детей программированию. Другой крайностью были только системы с элементами (в следовых количествах, но всем пох) «Искуственного Интеллекта» (ТМ) (под этим соусом модуль для обсчета подшипника в X-каде на Й-лиспе можно было скормить как элементы зайчатков искуственного разума).

slackwarrior ★★★★★
()
Ответ на: комментарий от quasimoto

вот, уже конкретика :) но, давайте скажем честно - можно написать интерпретатор Lisp на С++, и не обломаться, и будет работать

shty ★★★★★
()
Ответ на: комментарий от Miguel

Ну после того как они развернуты, мы опускаемся в нутро компилятора.

Но компилятор, в SBCL например, это ТОЖЕ расширяемая штука, наподобие макросов. Это часть рантайма. См. сорцы. И мы можем прямо в ходе компиляторных преобразований что-то переопределить.

Поэтому я говорю, что языка нет, его нельзя выделить.

anonymous
()
Ответ на: комментарий от stack_protector

Я пишу стартап на лиспе, а ты дрочишь скриптоту на бидоне.

anonymous
()
Ответ на: комментарий от shty

Еблан, ты вообще знаешь что такое AST?

Оно не может быть НЕ фиксировано, еблан. Он из синтаксиса выходит, если оно вообще есть, и всегда однозначно, если вообще выходит.

anonymous
()
Ответ на: комментарий от shty

Нельзя.

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

anonymous
()
Ответ на: комментарий от anonymous

Еблан, ты вообще знаешь что такое AST?

Оно не может быть НЕ фиксировано

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

shty ★★★★★
()
Ответ на: комментарий от anonymous

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

да

shty ★★★★★
()
Ответ на: комментарий от shty

Бляя.
Мне что тебе, объяснять вообще самые основы парсинга?
Иди-ка ты нахуй, еблан неграмотный, и там почитай Ульмана какого-нибудь.

anonymous
()
Ответ на: комментарий от anonymous

ко-ко-ко

кудах-так-тах?

ко-ко-ко, бля!

shty ★★★★★
()
Ответ на: комментарий от shty

А знаешь, почему ты так думаешь? Потому, что ты еблан, штя. Тупой, невежественный, неграмотный, еблан, который и может только что на ЛОРе кукарекать.

CL метациклическая динамическая система, и ее невозможно написать вне ее самой.

Это очень сложно вдолбить таким ебланам как ты, правда, которые кроме бидона и C++ в жизни ничего не видели.

anonymous
()
Ответ на: комментарий от anonymous

Мне что тебе, объяснять вообще самые основы парсинга?

Куда тебе, Парфён, кататься, ты ж облёваный весь. (с)

shty ★★★★★
()
Ответ на: комментарий от stack_protector

Нет.

Потому что среда CL обязана быть метациклической.
Таким образом, ты ее обязан реализовать на самом CL. И тогда это будет уже CL, а не «интерпретатор на C++».

anonymous
()
Ответ на: комментарий от anonymous

А то что его можно интерпретировать вообще как угодно.

Ну это на уровне «можно интерпретировать множество A как угодно в силу возможности построить A × B, где B - любое».

Но, GC полагается на сишный рантайм. И вообще, куча вещей полагается на сишный рантайм.

Сишный рантайм это соглашение о вызове, абстракция плоской памяти и, в конечном итоге, системные вызовы ядра. Соглашения о вызовах в реализациях ЯВУ уровня SBCL/GHC легко делаются своими. Лисповый рантайм всё равно начинается на плоской памяти - виртуальной, отданной ядром, или железной со страницами и фрагментами, при виртуальной памяти (ИМХО) оверхед всё равно константный.

С GC например приходится делать кучу финтов ушами чтобы избежать конфликтов с сишечкой. Со стеком то же самое - то есть так как у нас control stack шарится с сишкой, мы должны ебать мозг опять же тем чтобы сосуществовать с ней.

При взаимодействии GC с FFI? Без FFI в самом простом лиспе - получили сколько-то виртуальной памяти и процессорного времени от ядра и в их пределах можем делать всё что угодно, ни с кем конфликтовать не приходится.

Виртуальная память, а конкретнее, разделение уровней привилегий(необходимое для Си, потому что в Си мы можем куда угодно в памяти обратиться) как минимум ТОРМОЗИТ.

Согласен с тем, что на голом железе лисповая куча конкретно для лиспа лучше виртуальной памяти и кучи типичного ядра. Но модель вычислений лиспа далеко не единственная, бедные языки с указателями и абстракцией плоской памяти которые будут портироваться на такую ОС :)

Точно также для Erlang-а было бы очень хорошо прибить по CSP-шедулеру на процессор и посылать сообщения путём псевдо-атомичной записи в память. Но то что хорошо для erlang-овской модели вычислений плохо для других.

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

quasimoto ★★★★
()
Ответ на: комментарий от shty

Я тебе прямо это и говорю, что ты тупой, неграмотный. невежественный ебанько.

Ты вообще должен ценить, что я опускаюсь до того, что разъясняю тебе это. Так бы ты никогда об этом и не узнал, вследствие теоремы Гёделя и всего такого.

anonymous
()
Ответ на: комментарий от anonymous

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

о, я ценю как ты выпрыгиваешь из своей помойной ямы разбрызгивая какашки :)

shty ★★★★★
()
Ответ на: комментарий от quasimoto

При взаимодействии GC с FFI?

Не только FFI. Сам рантайм то обязан к ОС обращаться, хотя бы для IO и менеджмента памяти.

anonymous
()
Ответ на: комментарий от quasimoto

бедные языки с указателями и абстракцией плоской памяти которые будут портироваться на такую ОС :)

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

anonymous
()
Ответ на: комментарий от shty

Блять, ебанько, посмотри сорцы.
Там точно такая же метациклическая динамическая система, как и остальные CL, а не твоя мокрая фантазия в виде «интерпретатора на C++».

anonymous
()
Ответ на: комментарий от Harald

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-26.html#%_sec_4.1

Значит использующая для своей реализации себя саму.

anonymous
()
Ответ на: комментарий от Miguel

Вот это место не вполне понял. Что имеется в виду? Что всякая монада — аппликативный функтор? Или что-то ещё?

Что интерфейс (ну и функционал, конечно) любого аппликативного парсера воспроизводится посредством обвёрток над интерфейсом монадического парсера. У того же parsec есть инстансы для Applicative - можно писать аппликативные парсеры почти без обвёрток, на самом деле можно даже оттранслировать [e]BNF определения в аппликативный парсер и/или сделать хаскельный eDSL для [e]BNF (аппликативные комбинаторы уже BNF по смыслу, остаётся только добавить класс Lift чтобы отображать возвращаемые вложенные кортежы в конкретные конструкторы AST).

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

quasimoto ★★★★
()
Ответ на: комментарий от alienclaster

Декларативный, более менее привычная для математиков привыкших к размышлениям в разрезе типов нотация.

Да. А интегралы-то при чём? Или это все твои знания о математике?

То есть, плохой?

То есть, не для того.

Хз что такое лемма о змее

http://en.wikipedia.org/wiki/Snake_lemma

Miguel ★★★★★
()
Ответ на: комментарий от anonymous

И мы можем прямо в ходе компиляторных преобразований что-то переопределить.

И шо? Во всех компиляторах всех языков внутренние структуры данных по ходу компиляции меняются.

Miguel ★★★★★
()
Ответ на: комментарий от anonymous

то есть тебе нечего сказать по делу? :)

shty ★★★★★
()
Ответ на: комментарий от Miguel

не меняется структура типов структур и преобразований.

в лиспе может меняться. Хотя бы теоретически.

anonymous
()
Ответ на: комментарий от stack_protector

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

Я элементарные вещи рассказываю. Абсолютно элементарные. Многие из них вообще в такой элементарной книжке как SICP есть.

anonymous
()
Ответ на: комментарий от anonymous

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

НЕ ВСЕ компиляторы лиспов пишутся на лиспах. Что вполне естественно.

Miguel ★★★★★
()
Ответ на: комментарий от anonymous

Я элементарные вещи рассказываю. Абсолютно элементарные.

ты несёшь бред, в который изредка вставляешь умные слова, иногда умные слова сильно невпопад попадают :)

Многие из них вообще в такой элементарной книжке как SICP есть.

вот чувствуется что дальше этой книжки для 1 курса ты не продвинулся :)

shty ★★★★★
()
Ответ на: комментарий от Miguel

В случае CL - все.

А, остальные это недолиспы.
Ни одного нормального лиспа после CL не появилось еще.

anonymous
()
Ответ на: комментарий от anonymous

CL метациклическая динамическая система, и ее невозможно написать вне ее самой.

Ты всерьёз думаешь кого-то напугать подобными словами?

Можно. CL не более чем тьюринг-полон, так что, если бы его нельзя было написать на пистоне (например), то его нельзя было бы написать и на CL.

Miguel ★★★★★
()
Ответ на: комментарий от anonymous

Так бы ты никогда об этом и не узнал, вследствие теоремы Гёделя и всего такого.

Гм. Ты, вообще, в курсе, что именно утверждает теорема Гёделя?

Miguel ★★★★★
()
Ответ на: комментарий от shty

Мне лично давно чувствуется, ты тупое хуйло.
Нахуй пошел, ебанько недоученное.

Бред у тебя в голове, недоумок. Она просто не вмещает нихуя.

anonymous
()
Ответ на: комментарий от anonymous

Бред у тебя в голове. Она просто не вмещает нихуя.

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

shty ★★★★★
()
Ответ на: комментарий от Miguel

Да. А интегралы-то при чём?

Ну что-то же нужно было привести в качестве матан-примера. Дискретка (при чем чем практически вся из применяемой *мной* на практике) на лиспе выглядит в стопицот раз лучше.

Или это все твои знания о математике?

А что там знать-то?

То есть, не для того.

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

Хз что такое лемма о змее

http://en.wikipedia.org/wiki/Snake_lemma

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

alienclaster ★★★
()

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

Tck/Tk

anonymous
()
Ответ на: комментарий от Miguel

Реализация вычислителя и компилятора CL требуют уже работающего CL. Это все, что я этой фразой пытаюсь сказать.

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.