LINUX.ORG.RU

Джентельменский набор ЯП


1

0

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

А вообще какие языки и в какой последовательности было бы неплохо поучить?


Ответ на: комментарий от jtootf

> ты вопроса не понял. что означает плохого прогера? какой критерий, если не знание той же дискретки?

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

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

>В твоём месте обитания как-то иначе?

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

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

> в моём месте обитания без знаний дискретки ему будет непросто выполнить поставленные задачи в срок

Значит, забытая дискретка на твоем месте работы дает плохого прогера.

А кому-то нужны дифуры. Или микроэлектроника. Мне вот не помешала бы физика, линейка и риторика с психологие %)

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

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

это вроде не дискретка. или у нас разные о ней понятия :)

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

> что отображение объектов на их хеш-коды не сюръективно

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

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

>> Мозг прочищает и упорядочивает. Сильно.
> Где бы потом работу найти таким, с прочищенными мозгами? :)


Это даже срантехнику поможет, не только программисту.

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

>> не сюръективно и даже не инъективно
> функция имеет обратную iff она биективна :)


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

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

>> что отображение объектов на их хеш-коды не сюръективно
> c чего бы отображение (хеш-функция) было не сюръективно, если множество значений и есть множество хеш-кодов?


А с того, что так бывает в узком и никому не нужном частном случае.

gaa ★★
()

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

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

>Ололо, у нас на мехмате это было на первой же лекции по алгебре

что именно, и какую позицию ты отстаиваешь?

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

>что именно

Биективность функции, д-во "ф-ция f имеет обратную" <=> "ф-ция f биективна".

>и какую позицию ты отстаиваешь?

Позицию пока что никакую не отстаиваю, так как еще целиком не прочитал тренд.

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

>Биективность функции, д-во "ф-ция f имеет обратную" <=> "ф-ция f биективна"

ну вот и славно. можно идти спать с чистой совестью

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

> Биективность функции, д-во "ф-ция f имеет обратную" <=> "ф-ция f биективна".

Мехмату ли не знать, что это не так в случае плотных подмножеств топологического пространства? :)

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

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

> Да, и нет прощения Брайту за отсуствие оного в D.


Планируется для ast-макросов.

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

> Лисп только один - CommonLisp. Аффторов "лисп-подобных" систем нужно жестоко убивть.

И emacs?

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

>Из частоты приведения Коммон Лиспа в пример в твоем монументальном, так сказать, труде, я делаю вывод, что, по твоему мнению, Коммон Лисп - это где-то очень близко к идеалу. На столько близко, что на основе его идеологии конфетка делается весьма легко (Clojure) :)

>Хотя мне лично не нравится его базирование на jvm. Вот наверняка же у любого языка на jvm ограничения будут ограничения самой jvm.


А мне не нравится (категорически) что clojure не компилирует в class-файл - как на нём делать библиотеки и не грузить потом приложение пол дня?

Или я отстал от жизни?

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

>Забытая дискретка не означает плохого прогера

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

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

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

Какой "школой" - ВУЗ имеется в виду?

> не годятся для чего-либо интересного.

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

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

>> Да, и нет прощения Брайту за отсуствие оного в D.

>Планируется для ast-макросов.

Этого недостаточно, да и если судить по презентации Уолтера и Александреску, паттерн-матчинг там убогий. И AST-макросы всё еще планируются для D 2.0?

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

Нет. К D2 макросы не успели сделать. Он и так уже на три месяца просрочен.

И, конечно, оно будет работать только при компиляции. :)

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

Да, про паттерн-матчинг я не упомянул. Пример применяемого в промышленности паттерн-матчинга - это, конечно же, регэкспы. Или пролог. Но я не уверен, что стоит тратить силы на пролог.

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

> доказательство провести, или сам справишься?

Отлично, докажи мне биективность хеш-функции f(int x)=x%2. Гнилой помидор уже готов к броску.

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

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

По-моему, если у человека есть ясное понимание вопроса, то он подберёт наиболее естественные и простые слова Русского языка и скажет так, что будет понятно и второкласснику. А если сказать нечего, будет строить забор из заумных слов. Но тут он сам попадёт в ловушку. Слово весит и занимает ресурсы мозга. Происходит фрагментация сознания. На том же мехмате я был озадачен тем, как одни и те же понятия вводились под разным соусом сначала в матане, потом в функане, потом в тервере. Слава Богу, я уже забыл 90% того, чем мне там пытались забить голову :)

Вот тут продвинутый товарищ по имени cathode не понимает, зачем в языке программирования нужна иерархическая организация сущностей. Либо он никогда не пользовался файловой системой, либо это так дискра мозги промывает - я уж не знаю :) Я предлагаю в качестве упражнения отказаться от вложенных директорий на пару недель :) Т.е., /home можно иметь, а /home/cathode - ни-ни!

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

Но проблема с пр-вами имён в Common Lisp - не в том. Она - в том, что нет защиты от ошибок. Если код написан с расчётом, что есть такой символ foo, взятый из пакета bar, а на самом деле, такого символа нет, то символ будет молча создан и мы узнаем об ошибке только тогда, когда напоремся на отсутствующее смысловое содержание этого символа. А это будет не сразу (и здесь подлянку приготовила динамическая типизация).

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

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

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

>> c чего бы отображение (хеш-функция) было не сюръективно, если множество значений и есть множество хеш-кодов?

> А с того, что так бывает в узком и никому не нужном частном случае.

Например md5 хэш - сюръективная функция (для любого 128 битного числа найдется прообраз). Это "узкий и никому не нужный частный случай"?

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

>>>> функция имеет обратную iff она биективна :)

>>> так и запишем, не помнит ревнитель дискретки предмет своего обожания

>> доказательство провести, или сам справишься?

> Отлично, докажи мне биективность хеш-функции f(int x)=x%2.

Сначала придется кому-то доказать, что эта функция имеет обратную :)

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

>> Биективность функции, д-во "ф-ция f имеет обратную" <=> "ф-ция f биективна".

> Мехмату ли не знать, что это не так в случае плотных подмножеств топологического пространства? :)

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

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

>> Вот тут продвинутый товарищ по имени cathode не понимает, зачем в языке программирования нужна иерархическая организация сущностей.

Товарищь понимает. Товарищь не понимает, почему приплюснутые нэймспэсы хуже пакетов лиспа.

>> Я предлагаю в качестве упражнения отказаться от вложенных директорий на пару недель :)

Дерзай!

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

>Какой "школой" - ВУЗ имеется в виду

Это кому где прививали отвращение к математике:) Раньше AFAIR это делали в средней школе, сейчас не знаю.

>для того, что считаешь интересным _ты_

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

>люди с течением жизни меняются

Функциональщики говорят, что это уже _другие_ люди:)

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

> Товарищь не понимает, почему приплюснутые нэймспэсы хуже пакетов лиспа.

Вроде бы говорилось, что они (namespace'ы из Си++) как раз _лучше_ пакетов CL.

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

>Отлично, докажи мне биективность хеш-функции f(int x)=x%2. Гнилой помидор уже готов к броску

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

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

>> Если код написан с расчётом, что есть такой символ foo, взятый из пакета bar, а на самом деле, такого символа нет, то символ будет молча создан и мы узнаем об ошибке только тогда, когда напоремся на отсутствующее смысловое содержание этого символа.

Это проблема конкретно взятого компилятора и его настроек, а не языка.
Пжалста, вот что выдаст sbcl:

(defpackage :test)
(defun xxx () test::qwerty)
(compile 'xxx)

WARNING in XXX :
TEST::QWERTY is neither declared nor bound,
it will be treated as if it were declared SPECIAL.

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


ИМХО, это уже к языку мало относится.

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

>> Вроде бы говорилось, что они (namespace'ы из Си++) как раз _лучше_ пакетов CL.

Извиняюсь, зарапортовался.

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

>> это вроде не дискретка. или у нас разные о ней понятия :)

Это уже почти хаскель :))

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

>Функциональщики говорят, что это уже _другие_ люди:)

именно что! зато никаких тебе race conditions в общении с ними :)))

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

> А топология то здесь причем? Здесь все в рамках теории множеств написано, никакой тополгии и непрерывности отображений и не подразумевается даже.

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

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

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

Но заметь, что символ qwerty в пакет test внедрился _молча_. Если бы ты написал test:qwerty, то ридер бы ругнулся. На практике, приходится (и довольно часто) пользоваться внутренними символами из других пакетов. Почему? Потому что ты не можешь безболезненно экспортировать символ - могут возникнуть конфликты в использованных пакетах и задолбаешься их вылавливать. Т.е., конечно, можно вообще не использовать пакеты и тогда у нас всё будет как в старом добром С - все имена всегда нужно полностью квалифицировать. Что эквивалентно отсутствию такого понятия, как пространства имён, вообще.

Ещё одна ситуация. Бывает, что ты рассчитываешь, что символ был импортирован в твой пакет, а он не был импортирован. Т.е.,

(defpackage :test (:use :cl :foo))
; Раньше был символ foo:bar, а теперь его нет, т.к. после
; рефакторинга он попал в :quux. А поскольку foo у нас используется,
; то не пишем квалификатор.
(in-package :test)
(bar) - молча создаётся новый символ bar вместо ссылки на (переехавший) quux.bar.

<еще 200 строк мусора, если это в файле>
Ошибка/предупреждение: функция bar не определена

Что происходит дальше? Дальше нужно стереть все fasl-ы, где этот bar мог использоваться, перезапустить образ и загрузить всё по новой (а это занимает минуту и больше). И так далее много раз. Можно пытаться срезать путь и не перезагружать, но это, скорее всего, выйдет боком. В динамической среде все ошибки остаются в образе до тех пор, пока их не исправили. Если неверное определение функции лечится более-менее легко (при отсутствии inline её достаточно перекомпилировать), то ошибка в пространстве имён лечится тяжело.

> ИМХО, это уже к языку мало относится

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

Я на самом деле, эту проблему победил, пока что для одной реализации - мне удалось подменить функции find-symbol и intern в лиспворксе и я завёл список запретных имён. При попытки intern-ить запретное имя в неправильный пакет я порождаю ошибку. Только после этого я начал чувствовать себя более-менее в безопасности. А до этого не было никакой другой возможности рефакторить, кроме как перебрать ВСЕ определённые функции и переменные по одной и искать их во всех местах? где они используются. Что непроизводительно. В С и Паскале это решается проще - ты просто переносишь определения, запускаешь компилятор и ловишь сообщения об ошибке.

Я, кстати, ещё не рассказал о том, что продвинутый лисп крайне редко показывает место ошибки при компиляции файла. Его обычно нужно отыскивать с помощью телепатии и ясновидения. Одно это уже позволяет не рекомендовать лисп для промышленного применения. Если же пользоваться asdf (а придётся пользоваться), то в некоторых случаях придётся пользоваться инспектором, чтобы узнать имя файла и даже чтобы прочитать само сообщение об ошибке! Таким образом, замечательные метавозможности и прекрасный внутренний дизайн лиспа полностью компенсируются неудобством практической работы с ним. Мы видим слабость приложений и библиотек и это - самое неоспоримое доказательство того, что производительность труда при работе на лиспе низка.

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

>> В вакууме вообще трудно общаться :)

> признайся - ты просто никогда не пробовал ;)

Ooops... you found out. Now we have to kill you.

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

> s/Ruby/Python/

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

А ты почему здесь написал "s/Tcl/Python/ s/perl/Python/ s/Ruby/Python/"?

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

> На мой взгляд Python больше подходит для обучения (он проще и читабельнее). Программировать лучше на Ruby

Я не нашел больших преимуществ в Руби, и остановился на Питоне.

> А ты почему здесь написал "s/Tcl/Python/ s/perl/Python/ s/Ruby/Python/"?

Потому что я тролль, очевидно же. А раньше по треду для скриптования предлагались недоязычки^W всякие Tcl и Perl.

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

>> остановился на Питоне

> слава миссионерам уайтспейса!

Бугмакер, мы рады тебя видеть снова %)

> ура ура ура!

И поясной поклон не забудь :D

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

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

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

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