diff --git a/algorithmique/cours/Makefile b/algorithmique/cours/Makefile new file mode 100644 index 0000000..8b94f17 --- /dev/null +++ b/algorithmique/cours/Makefile @@ -0,0 +1,216 @@ +# Makefile for Sphinx documentation +# + +# You can set these variables from the command line. +SPHINXOPTS = +SPHINXBUILD = sphinx-build +PAPER = +BUILDDIR = _build + +# User-friendly check for sphinx-build +ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1) +$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/) +endif + +# Internal variables. +PAPEROPT_a4 = -D latex_paper_size=a4 +PAPEROPT_letter = -D latex_paper_size=letter +ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) . +# the i18n builder cannot share the environment and doctrees with the others +I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) . + +.PHONY: help +help: + @echo "Please use \`make ' where is one of" + @echo " html to make standalone HTML files" + @echo " dirhtml to make HTML files named index.html in directories" + @echo " singlehtml to make a single large HTML file" + @echo " pickle to make pickle files" + @echo " json to make JSON files" + @echo " htmlhelp to make HTML files and a HTML help project" + @echo " qthelp to make HTML files and a qthelp project" + @echo " applehelp to make an Apple Help Book" + @echo " devhelp to make HTML files and a Devhelp project" + @echo " epub to make an epub" + @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter" + @echo " latexpdf to make LaTeX files and run them through pdflatex" + @echo " latexpdfja to make LaTeX files and run them through platex/dvipdfmx" + @echo " text to make text files" + @echo " man to make manual pages" + @echo " texinfo to make Texinfo files" + @echo " info to make Texinfo files and run them through makeinfo" + @echo " gettext to make PO message catalogs" + @echo " changes to make an overview of all changed/added/deprecated items" + @echo " xml to make Docutils-native XML files" + @echo " pseudoxml to make pseudoxml-XML files for display purposes" + @echo " linkcheck to check all external links for integrity" + @echo " doctest to run all doctests embedded in the documentation (if enabled)" + @echo " coverage to run coverage check of the documentation (if enabled)" + +.PHONY: clean +clean: + rm -rf $(BUILDDIR)/* + +.PHONY: html +html: + $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html + @echo + @echo "Build finished. The HTML pages are in $(BUILDDIR)/html." + +.PHONY: dirhtml +dirhtml: + $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml + @echo + @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml." + +.PHONY: singlehtml +singlehtml: + $(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml + @echo + @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml." + +.PHONY: pickle +pickle: + $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle + @echo + @echo "Build finished; now you can process the pickle files." + +.PHONY: json +json: + $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json + @echo + @echo "Build finished; now you can process the JSON files." + +.PHONY: htmlhelp +htmlhelp: + $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp + @echo + @echo "Build finished; now you can run HTML Help Workshop with the" \ + ".hhp project file in $(BUILDDIR)/htmlhelp." + +.PHONY: qthelp +qthelp: + $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp + @echo + @echo "Build finished; now you can run "qcollectiongenerator" with the" \ + ".qhcp project file in $(BUILDDIR)/qthelp, like this:" + @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/Algorithmique.qhcp" + @echo "To view the help file:" + @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/Algorithmique.qhc" + +.PHONY: applehelp +applehelp: + $(SPHINXBUILD) -b applehelp $(ALLSPHINXOPTS) $(BUILDDIR)/applehelp + @echo + @echo "Build finished. The help book is in $(BUILDDIR)/applehelp." + @echo "N.B. You won't be able to view it unless you put it in" \ + "~/Library/Documentation/Help or install it in your application" \ + "bundle." + +.PHONY: devhelp +devhelp: + $(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp + @echo + @echo "Build finished." + @echo "To view the help file:" + @echo "# mkdir -p $$HOME/.local/share/devhelp/Algorithmique" + @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/Algorithmique" + @echo "# devhelp" + +.PHONY: epub +epub: + $(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub + @echo + @echo "Build finished. The epub file is in $(BUILDDIR)/epub." + +.PHONY: latex +latex: + $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex + @echo + @echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex." + @echo "Run \`make' in that directory to run these through (pdf)latex" \ + "(use \`make latexpdf' here to do that automatically)." + +.PHONY: latexpdf +latexpdf: + $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex + @echo "Running LaTeX files through pdflatex..." + $(MAKE) -C $(BUILDDIR)/latex all-pdf + @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex." + +.PHONY: latexpdfja +latexpdfja: + $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex + @echo "Running LaTeX files through platex and dvipdfmx..." + $(MAKE) -C $(BUILDDIR)/latex all-pdf-ja + @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex." + +.PHONY: text +text: + $(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text + @echo + @echo "Build finished. The text files are in $(BUILDDIR)/text." + +.PHONY: man +man: + $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man + @echo + @echo "Build finished. The manual pages are in $(BUILDDIR)/man." + +.PHONY: texinfo +texinfo: + $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo + @echo + @echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo." + @echo "Run \`make' in that directory to run these through makeinfo" \ + "(use \`make info' here to do that automatically)." + +.PHONY: info +info: + $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo + @echo "Running Texinfo files through makeinfo..." + make -C $(BUILDDIR)/texinfo info + @echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo." + +.PHONY: gettext +gettext: + $(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale + @echo + @echo "Build finished. The message catalogs are in $(BUILDDIR)/locale." + +.PHONY: changes +changes: + $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes + @echo + @echo "The overview file is in $(BUILDDIR)/changes." + +.PHONY: linkcheck +linkcheck: + $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck + @echo + @echo "Link check complete; look for any errors in the above output " \ + "or in $(BUILDDIR)/linkcheck/output.txt." + +.PHONY: doctest +doctest: + $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest + @echo "Testing of doctests in the sources finished, look at the " \ + "results in $(BUILDDIR)/doctest/output.txt." + +.PHONY: coverage +coverage: + $(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage + @echo "Testing of coverage in the sources finished, look at the " \ + "results in $(BUILDDIR)/coverage/python.txt." + +.PHONY: xml +xml: + $(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml + @echo + @echo "Build finished. The XML files are in $(BUILDDIR)/xml." + +.PHONY: pseudoxml +pseudoxml: + $(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml + @echo + @echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml." diff --git a/algorithmique/cours/_static/cesi.jpg b/algorithmique/cours/_static/cesi.jpg new file mode 100644 index 0000000..dafbe55 Binary files /dev/null and b/algorithmique/cours/_static/cesi.jpg differ diff --git a/algorithmique/cours/conf.py b/algorithmique/cours/conf.py new file mode 100644 index 0000000..b607f02 --- /dev/null +++ b/algorithmique/cours/conf.py @@ -0,0 +1,355 @@ +# -*- coding: utf-8 -*- +# +# Algorithmique documentation build configuration file, created by +# sphinx-quickstart on Thu Mar 16 16:07:00 2017. +# +# This file is execfile()d with the current directory set to its +# containing dir. +# +# Note that not all possible configuration values are present in this +# autogenerated file. +# +# All configuration values have a default; values that are commented out +# serve to show the default. + +import sys +import os + +# If extensions (or modules to document with autodoc) are in another directory, +# add these directories to sys.path here. If the directory is relative to the +# documentation root, use os.path.abspath to make it absolute, like shown here. +#sys.path.insert(0, os.path.abspath('.')) + +# -- General configuration ------------------------------------------------ + +# If your documentation needs a minimal Sphinx version, state it here. +#needs_sphinx = '1.0' + +# Add any Sphinx extension module names here, as strings. They can be +# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom +# ones. +extensions = [ + 'sphinx.ext.pngmath', +] + +# Add any paths that contain templates here, relative to this directory. +templates_path = ['_templates'] + +# The suffix(es) of source filenames. +# You can specify multiple suffix as a list of string: +# source_suffix = ['.rst', '.md'] +source_suffix = '.txt' + +# The encoding of source files. +#source_encoding = 'utf-8-sig' + +# The master toctree document. +master_doc = 'index' + +# General information about the project. +project = u'Algorithmique' +copyright = u'2017, Gwen' +author = u'Gwen' + +# The version info for the project you're documenting, acts as replacement for +# |version| and |release|, also used in various other places throughout the +# built documents. +# +# The short X.Y version. +version = u'1' +# The full version, including alpha/beta/rc tags. +release = u'1' + +# The language for content autogenerated by Sphinx. Refer to documentation +# for a list of supported languages. +# +# This is also used if you do content translation via gettext catalogs. +# Usually you set "language" from the command line for these cases. +language = 'fr' + +# There are two options for replacing |today|: either, you set today to some +# non-false value, then it is used: +#today = '' +# Else, today_fmt is used as the format for a strftime call. +#today_fmt = '%B %d, %Y' + +# List of patterns, relative to source directory, that match files and +# directories to ignore when looking for source files. +exclude_patterns = ['_build'] + +# The reST default role (used for this markup: `text`) to use for all +# documents. +default_role = 'literal' + +# If true, '()' will be appended to :func: etc. cross-reference text. +#add_function_parentheses = True + +# If true, the current module name will be prepended to all description +# unit titles (such as .. function::). +#add_module_names = True + +# If true, sectionauthor and moduleauthor directives will be shown in the +# output. They are ignored by default. +#show_authors = False + +# The name of the Pygments (syntax highlighting) style to use. +pygments_style = 'sphinx' + +# A list of ignored prefixes for module index sorting. +#modindex_common_prefix = [] + +# If true, keep warnings as "system message" paragraphs in the built documents. +#keep_warnings = False + +# If true, `todo` and `todoList` produce output, else they produce nothing. +todo_include_todos = False + + +# -- Options for HTML output ---------------------------------------------- + +# The theme to use for HTML and HTML Help pages. See the documentation for +# a list of builtin themes. +html_theme = 'alabaster' + +# Theme options are theme-specific and customize the look and feel of a theme +# further. For a list of options available for each theme, see the +# documentation. +#html_theme_options = {} + +# Add any paths that contain custom themes here, relative to this directory. +#html_theme_path = [] + +# The name for this set of Sphinx documents. If None, it defaults to +# " v documentation". +#html_title = None + +# A shorter title for the navigation bar. Default is the same as html_title. +#html_short_title = None + +# The name of an image file (relative to this directory) to place at the top +# of the sidebar. +#html_logo = None + +# The name of an image file (relative to this directory) to use as a favicon of +# the docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 +# pixels large. +#html_favicon = None + +# Add any paths that contain custom static files (such as style sheets) here, +# relative to this directory. They are copied after the builtin static files, +# so a file named "default.css" will overwrite the builtin "default.css". +html_static_path = ['_static'] + +# Add any extra paths that contain custom files (such as robots.txt or +# .htaccess) here, relative to this directory. These files are copied +# directly to the root of the documentation. +#html_extra_path = [] + +# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, +# using the given strftime format. +#html_last_updated_fmt = '%b %d, %Y' + +# If true, SmartyPants will be used to convert quotes and dashes to +# typographically correct entities. +#html_use_smartypants = True + +# Custom sidebar templates, maps document names to template names. +#html_sidebars = {} + +# Additional templates that should be rendered to pages, maps page names to +# template names. +#html_additional_pages = {} + +# If false, no module index is generated. +#html_domain_indices = True + +# If false, no index is generated. +#html_use_index = True + +# If true, the index is split into individual pages for each letter. +#html_split_index = False + +# If true, links to the reST sources are added to the pages. +#html_show_sourcelink = True + +# If true, "Created using Sphinx" is shown in the HTML footer. Default is True. +html_show_sphinx = False + +# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True. +html_show_copyright = False + +# If true, an OpenSearch description file will be output, and all pages will +# contain a tag referring to it. The value of this option must be the +# base URL from which the finished HTML is served. +#html_use_opensearch = '' + +# This is the file name suffix for HTML files (e.g. ".xhtml"). +#html_file_suffix = None + +# Language to be used for generating the HTML full-text search index. +# Sphinx supports the following languages: +# 'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja' +# 'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr' +#html_search_language = 'en' + +# A dictionary with options for the search language support, empty by default. +# Now only 'ja' uses this config value +#html_search_options = {'type': 'default'} + +# The name of a javascript file (relative to the configuration directory) that +# implements a search results scorer. If empty, the default will be used. +#html_search_scorer = 'scorer.js' + +# Output file base name for HTML help builder. +htmlhelp_basename = 'Algorithmiquedoc' + +# -- Options for LaTeX output --------------------------------------------- + +latex_elements = { +# The paper size ('letterpaper' or 'a4paper'). +'papersize': 'a4paper', + +# The font size ('10pt', '11pt' or '12pt'). +#'pointsize': '10pt', + +# Additional stuff for the LaTeX preamble. +#'preamble': '', + +# Latex figure (float) alignment +#'figure_align': 'htbp', +} + +# Grouping the document tree into LaTeX files. List of tuples +# (source start file, target name, title, +# author, documentclass [howto, manual, or own class]). +latex_documents = [ + (master_doc, 'Algorithmique.tex', u'Cours d\'algorithmique', + u'promotion GMSI B3', 'manual'), +] + +# The name of an image file (relative to this directory) to place at the top of +# the title page. +latex_logo = '_static/cesi.jpg' + +# For "manual" documents, if this is true, then toplevel headings are parts, +# not chapters. +latex_use_parts = True + +# If true, show page references after internal links. +#latex_show_pagerefs = False + +# If true, show URL addresses after external links. +#latex_show_urls = False + +# Documents to append as an appendix to all manuals. +#latex_appendices = [] + +# If false, no module index is generated. +#latex_domain_indices = False + + +# -- Options for manual page output --------------------------------------- + +# One entry per manual page. List of tuples +# (source start file, name, description, authors, manual section). +man_pages = [ + (master_doc, 'algorithmique', u'Algorithmique Documentation', + [author], 1) +] + +# If true, show URL addresses after external links. +#man_show_urls = False + + +# -- Options for Texinfo output ------------------------------------------- + +# Grouping the document tree into Texinfo files. List of tuples +# (source start file, target name, title, author, +# dir menu entry, description, category) +texinfo_documents = [ + (master_doc, 'Algorithmique', u'Algorithmique Documentation', + author, 'Algorithmique', 'One line description of project.', + 'Miscellaneous'), +] + +# Documents to append as an appendix to all manuals. +#texinfo_appendices = [] + +# If false, no module index is generated. +#texinfo_domain_indices = True + +# How to display URL addresses: 'footnote', 'no', or 'inline'. +#texinfo_show_urls = 'footnote' + +# If true, do not generate a @detailmenu in the "Top" node's menu. +#texinfo_no_detailmenu = False + + +# -- Options for Epub output ---------------------------------------------- + +# Bibliographic Dublin Core info. +epub_title = project +epub_author = author +epub_publisher = author +epub_copyright = copyright + +# The basename for the epub file. It defaults to the project name. +#epub_basename = project + +# The HTML theme for the epub output. Since the default themes are not +# optimized for small screen space, using the same theme for HTML and epub +# output is usually not wise. This defaults to 'epub', a theme designed to save +# visual space. +#epub_theme = 'epub' + +# The language of the text. It defaults to the language option +# or 'en' if the language is not set. +#epub_language = '' + +# The scheme of the identifier. Typical schemes are ISBN or URL. +#epub_scheme = '' + +# The unique identifier of the text. This can be a ISBN number +# or the project homepage. +#epub_identifier = '' + +# A unique identification for the text. +#epub_uid = '' + +# A tuple containing the cover image and cover page html template filenames. +#epub_cover = () + +# A sequence of (type, uri, title) tuples for the guide element of content.opf. +#epub_guide = () + +# HTML files that should be inserted before the pages created by sphinx. +# The format is a list of tuples containing the path and title. +#epub_pre_files = [] + +# HTML files that should be inserted after the pages created by sphinx. +# The format is a list of tuples containing the path and title. +#epub_post_files = [] + +# A list of files that should not be packed into the epub file. +epub_exclude_files = ['search.html'] + +# The depth of the table of contents in toc.ncx. +#epub_tocdepth = 3 + +# Allow duplicate toc entries. +#epub_tocdup = True + +# Choose between 'default' and 'includehidden'. +#epub_tocscope = 'default' + +# Fix unsupported image types using the Pillow. +#epub_fix_images = False + +# Scale large images. +#epub_max_image_width = 0 + +# How to display URL addresses: 'footnote', 'no', or 'inline'. +#epub_show_urls = 'inline' + +# If false, no index is generated. +#epub_use_index = True diff --git a/algorithmique/cours/fondement.txt b/algorithmique/cours/fondement.txt new file mode 100644 index 0000000..6346eb4 --- /dev/null +++ b/algorithmique/cours/fondement.txt @@ -0,0 +1,99 @@ +Présentation de l'art de programmer +==================================== + +Le processus d'abstraction +-------------------------- + +Débuter en programmation n'est pas une chose aisée. Aujourd'hui, la tendance est au +"bas niveau". Souvent, on se jette dans le grand bain : + +- soit en s'approchant au maximum de la machine (admin système et réseau, noyau + linux, langage C) + +- soit en faisant du dev web côté backend, ce qui ramène à une administration réseau + de bas niveau (microservices, monde nodeJS/javascript, etc...) + +Soit on suit un cursus scolaire traditionnel qui commence souvent par une +explication du fonctionnement d'une machine abstraite de bas niveau, puis en +allant de plus en plus haut, mais étant sous-entendu qu'il faut rester connecté au +bas niveau (comprendre comment ça se passe derrière la scène). + +Dans ces deux cas, il est sous-entendu qu'on apprend plus de choses et plus +rapidement en mettant les mains dans le cambouis, ce qui vrai bien sûr. Mais cela +sous-entend qu'un développeur doit rester le nez dans le guidon, ou au moins qu'il +se doit d'être un expert du système dans lequel il évolue (connaissance du système +d'exploitation, binding avec le C, du ramasse miette (garbage collector), +interaction avec les différentes librairies, gestion et optimisation de la mémoire, +architecture par microservices, threads...) + +L'approche algorithmique consiste en exactement le contraire : elle commence par se +placer du côté de l'esprit humain et de ses capacités de compréhension et +d'abstraction. + +Le lien est fait ensuite avec le plus bas niveau grâce une implémentation effective +des langages à partir des paradigmes de rationalisation de la penseée (modules, +objects, généricité, polymorphisme paramétrique...) et d'un outil de communication +avec la machine qu'on appelle compilateur (dont la description est en dehors de +l'objectif de ce cours). + +La tendance générale de l'évolution des languages est de se libérer de ces +contraintes de bas niveau, un peu comme en sciences physiques où les lois physiques +dépendent de l'échelle d'en dessous (du niveau microscopique/quantique) mais qu'à +l'échelle du dessus, on n'a pas affaire à des effets de bas niveau (pas d'effets +quantiques à un niveau macroscopique en général). Ce processus d'évolution est vrai +aussi dans le monde de la technique informatique lui-même (modèle OSI, comment est +construite une trame IP, indépendances de chaque couche (transport, payload) entre +elles). Même la tendance système est à la virtualisation qui accentue encore la +tendance à s'affranchir du bas niveau (le niveau système), le séparer nettement du +haut niveau (le niveau applicatif). + +Il apparaît régulièrement de nouveaux langages. Comment s'orienter ? Quel(s) +langage(s) choisir pour un projet de développement ? Au delà de leurs disparités, la +conception et la genèse de chacun d'eux procèdent d'une motivation partagée : la +volonté d'abstraire. + +- **s'abstraire de la machine** : un langage de programmation permet de + négliger l'aspect *mécanique* de l'ordinateur. On oublie le modèle du + microprocesseur, jusqu'au système d'exploitation sur lequel sera exécuté + le programme. + +- **abstraire les erreurs** : Il s'agit ici de garantir la sûreté d'exécution; un + programme ne doit pas se terminer brutalement ou devenir incohérent en cas d'erreur. + Un des moyens pour y parvenir est le typage des programmes et la mise + en oeuvre d'un mécanisme d'exceptions. + +- **abstraire le mode opératoire** : Il s'agit de choisir une représentation, un + paradigme d'implémentation qui est indépendant du domaine considéré (paradigme + objet, modulaire, générique, composants...) + +- **abstraire les composants** : Les langages de programmation donnent la + possibilité de découper une application en différents composants logiciels, plus ou + moins indépendants et autonomes. La modularité permet une structuration de plus haut + niveau de l'ensemble d'une application complexe. Les langages à objets constituent + une autre approche de la réutilisabilité permettant la réalisation très rapide de + prototypes. + +Détails des niveaux d'abstraction par rapport à la machine +----------------------------------------------------------- + +L'extrème déploiement des langages (plusieurs milliers de langages différents) +est dû au succès de l'ordinateur. + +- **niveau 0** : le langage machine. Illisible, c'est une suite d'optcode. + impossible de coder dans ce langage. + +- **niveau 1** : langage d'assemblage. Il reste très dépendant de la machine + et aujourd'hui il est rare d'en faire, sauf si on code un bootloader par exemple, + la gestion de l'accès à la mémoire est en réel (le mode protégé n'apparaît que après). + Il faut gérer les ressources,le langage est très optimisé mais presque impossible + à maintenir et rendre générique. Aujourd'hui plus personne ne code en assembleur. + +- **niveau 2** : langages dits de **bas niveau** : (exemple : le C, le C++) + indépendance par rapport à la machine, grande structuration mais très verbeux + +- **niveau 3** : langages dits de **haut niveau** : le raisonnement dans ces + langages ne dépent plus de la machine, et ils implémentent des paradigmes de + programmation indépendant de l'état de la mémoire de l'ordinateur, + ils sont indépendant même du système d'exploitation. + + diff --git a/algorithmique/cours/index.txt b/algorithmique/cours/index.txt new file mode 100644 index 0000000..6c75413 --- /dev/null +++ b/algorithmique/cours/index.txt @@ -0,0 +1,30 @@ +.. Algorithmique documentation master file, created by + sphinx-quickstart on Thu Mar 16 16:07:00 2017. + You can adapt this file completely to your liking, but it should at least + contain the root `toctree` directive. + +Introduction à l'algorithmique +================================ + +Contents: + +.. toctree:: + :maxdepth: 2 + + fondement + langage + modularite + + +.. algorithmique + + + + +Indices and tables +================== + +* :ref:`genindex` +* :ref:`modindex` +* :ref:`search` + diff --git a/algorithmique/cours/langage.txt b/algorithmique/cours/langage.txt new file mode 100644 index 0000000..526a543 --- /dev/null +++ b/algorithmique/cours/langage.txt @@ -0,0 +1,220 @@ +Les langages de programmation +============================= + +Approche historique et chronologique +------------------------------------- + +- début des langages vers les années 1950 (A0, Fortran(impératif), + Lisp(impératif et fonctionnel), Cobol) +- années 60 : Simula (classes), CPL (compilation séparée) +- années 70 : C (référence du langage impératif de bas niveau), Pascal + (procédures), Smalltalk (programmation orientée objects), Prolog + (programmation logique), Scheme (programmation fonctionnelle pure), Modula, + C++, Ada, Turbo Pascal, Common Lisp, Eiffel (programmation par contrats) +- années 80 : ML, CAML (langages fonctionnels) +- années 90 : Perl, Python, Ruby (languages de scripting multi-paradigmes) + Haskell (fonctionnel pur), Lua, Delphi, Java (orienté objet, machine + virtuelle), PHP (impératif, dédié au web), Erlang (fonctionnel+ + programmation concurrente), javascript (orienté web, objets par + prototypage), OCaml (multi-paradigme, fortement typé, orienté sécurité, + programmation générique, fonctionnelle et objets, modulaire et fonctorielle) +- 2009 : go (google, compilé, typage statique, objets par prototypage, + prgrammation concurrente), Rust (fondation mozilla, multiparadigme, programmation concurrente) + +Les langages actuellement les plus utilisés dans le monde de l'entreprise sont : + +- javascript/NodeJS (70% du code dans le dépôt github) mais victime de son + succès (chaos complet des librairies) +- le go est de plus en plus utilisé, c'est **le** langage qui monte + actuellement +- Python, Ruby, lua, autres langages de scripting (de plus en plus utilisés) +- PHP, Java (stagnants) +- C, C++ (de moins en moins utilisés) + +Approche par typologie des langages +----------------------------------- + +- **A0 (1954)** : possibilité de découpage de programmes en + sous-programmes ; + +- **ALGOL (1958)** : concept de bloc de code (pas forcément nommé) et d'imbrication + de blocs de code ; + +- **C (1971)** : syntaxe claire et simple, programme fortement structuré ; + +- **C (1980)** : le **code objet**, qui consiste à essayer de faire fonctionner + un seul jeu d'instructions sur des machines différentes. Avant, le code + d'assemblage dépendait du processeur, donc il n'y avait pas un seul et unique + jeu d'instructions ; + +- **1980** : déploiement et succès des langages à objets ; + +- **1983** : turbo pascal (Borland) qui fut le tournant du C, + propose un IDE (Environnement de Développement Intégré). + aujourd'hui le turbo pascal a pratiquement disparu mais pas totalement, + il est soutenu par une communauté open source autour de **Lazarus** ; + +- **depuis les années 90** : deux grands groupes de langages. Les langages à + objets, et les langages fonctionnels. Les deux mondes s'interpénètrent (les + avancées actuelles du web, les microservices (Erlang, Haskell), + viennent du monde fonctionnel, le NoSQL, etc). + Les grandes avancées architecturales (système d'exploitation, linux, etc...) + viennent du monde de l'impératif. + + +Approches par modèles de programmation +-------------------------------------- + +- **le mécanisme d'exceptions** : il est possible de rompre l'exécution normale d'un + programme à un endroit et de la reprendre à un autre endroit du programme prévu à + cet effet. Ce mécanisme permet de gérer les situations exceptionnelles. + +- **le paradigme impératif** : les entrées-sorties, les modifications physiques de + valeurs et les structures de contrôle itératives sont possibles. + +- **le paradigme fonctionnel** : manipule les fonctions comme étant des valeurs du + langage. Celles-ci peuvent être utilisées en tant que paramètres d'autres fonctions + ou être retournées comme résultat d'un appel de fonction. + +- **le paradigme objet** : La représentation du programme colle à la réalité en + reproduisant des entités relativement proches des objets réel. Attention, le piège + est de croire qu'il s'agit *du* paradigme universel puisqu'il reproduit en miroir le + réel. **C'est en fait un processus d'abstraction comme un autre**. + +Sûreté du langage, typage +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Tri par ordre de sûreté croissant : + +0. typage très faible (presque inexistant aujourd'hui) : 42 == "42" == 42.0... +1. typage dynamique faible : (javascript) (possibilité de changer le prototype + d'un objet pendant l'éxécution du programme, c'est la fête on peut faire + n'importe quoi) +2. typage dynamique fort inféré par le comportement (behavior, duck typing) + (python, ruby, PHP) Le contenu de la variable détermine le choix du typage + `var = 0 -> type int` +3. typage statique déclaré fort (Java) + `int var = 0 ;` (pas mal mais super lourd, pas **agile** du tout) +4. langages à types statiques muni d'un moteur d'inférence de types (Ocaml) + sûreté d'exécution, agilité, sécurité. + + +La syntaxe, la lisibilité +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Importance de la lisibilité (notamment par rapport aux méthodes agiles). + +- courte (python) +- verbeuse (C) +- l'importance des mots clef du langage +- délimiteur de phrase, de blocs (parenthèses, accolades, tabulations, blocs...) + +Langages compilés ou interprétés ? +----------------------------------- + +- **le typage statique** : la vérification de la compatibilité entre les types des + paramètres formels et des paramètres d'appel est effectuée au moment de la + compilation du programme. Dès lors, il n'est pas nécessaire de faire ces + vérifications durant l'exécution du programme ce qui accroît son efficacité. En + outre, la vérification de type permet d'éliminer la plupart des erreurs introduites + par maladresse ou étourderie et contribue à la sûreté de l'exécution. + +- **le typage dynamique** : la vérification de la compatibilité entre les types des + paramètres formels et des paramètres d'appel est effectuée au moment de l'exécution + ou de l'appel à certaines parties de codes du programme. + +- **le polymorphisme paramétrique** : une fonction ou un objet qui n'explore pas la + totalité de la structure d'un de ses arguments accepte que celui-ci ait un type non + entièrement déterminé. Ce paramètre est alors dit polymorphe. Cette particularité + permet de développer un code générique utilisable pour des structures de données + différentes tant que la représentation exacte de cette structure n'a pas besoin + d'être connue par le code en question. L'algorithme de typage est à même de faire + cette distinction. + +- **l'inférence de types** : le programmeur n'a besoin de donner aucune information + de type à l'intérieur de son programme. Le langage se charge seul de déduire du code + le type le plus général des expressions et des déclarations qui y figurent. Cette + inférence est effectuée conjointement à la vérification, lors de la compilation du + programme. + +Les grands paradigmes de programmation +--------------------------------------- + +Le paradigme des objets +~~~~~~~~~~~~~~~~~~~~~~~ + +- 1962 (SIMULA) : premières notions de classes ; + +Pui, une dizaine d'années plus tard : + +- C++ : intégration des classes pour le C ; +- turbo pascal : intégration des classes pour le pascal ; + +Tous les langages actuels ont intégré des traits objets mais de manière très +différentes : + +- perl (1987) +- python (1991) +- Ruby (1993) + +- L'implémentation des objets en python est très proche des notions initiales de + classes issues du Smaltalk et présente une tentative très intéressante + d'unification des objets et des types depuis python 2.2 ; + +- Java (1995) : très grosse réussite industrielle en surfant sur la vague de la + programmation objet, et des machines virtuelles, mais en fait et avec le recul, + doté d'un support objet lourd et alambiqué. + Le monde Java est lourd, avec des outils consommant beaucoup de mémoire et + qui ne satisfont pas à la règle du KISS (Keep It Simple, Stupid) ; + + +Les supports objets sont riches et variés, + +- objets obligatoirement construits pas des classes (Java, C++, ...) +- objets sans définition de classes (javascript, Ocaml, go, rust) +- langages à attributs (python) +- langages ou le type des objets est défini par leur classe (python, ruby) +- langages ou le type des objets est différent du type de leur classe (Ocaml) +- objets sans classes mais construits par des prototypes (javascript) +- construction d'objets possibles objets sans classe du tout (Ocaml) +- encapsulation des attributs des objets (Java, Ocaml, C++, PHP) +- pas d'encapsulation des attributs (python, ruby, javascript...) + +Le paradigme impératif +~~~~~~~~~~~~~~~~~~~~~~ + +Un programme est une suite d'états de la mémoire de l'ordinateur, +c'est la suite logique des machines de Turing. +La plupart des programmeur aujourd'hui raisonnent suivant ce paradigme, +et ont une très faible visibilité par rapport aux autres paradigmes existants. +Seuls les programmeurs cultivés sont aujourd'hui capable de raisonner +suivant différents paradigmes, ce sont des programmeurs chevronnés et +cultivés. + +Le paradigme fonctionnel +~~~~~~~~~~~~~~~~~~~~~~~~ + +La notion de fonction que possède sous une forme ou une autre la plupart des +langages est empruntée aux mathématiques et non à l'électronique. D'une manière +générale, les langages substituent des modèles formels aux conceptions purement +calculatoires. Ils y gagnent en expressivité. Certains langages fondent leur +paradigme de programmation sur l'abstraction entrée-traitement-sortie, donc sur le +**mathème fonctionnel** et pas sur la boite noire électronique. La fonction +mathématique apporte un niveau opératoire dans le traitement de l'information. + + +Approche par fonctionnalités +---------------------------- + +Plusieurs domaines de l'informatique on proposé/imposé des méthodologies, +des manières de faire. Ces modèles de programmation on fortement influencé +en retour les langages. On reconnaît aujourd'hui : + +- Le modèle client-serveur +- Le modèle de programmation concurrente (exécution de processus légers, threads) : +- Le modèle de développement d'une application de bureau (MVC, ergonomie d'interface) +- Le modèle de développement web (communiquer sur le réseau Internet, API + REST, microservices...) +- Le modèle de programmation système et réseau +- le modèle **Dev Ops** et les méthodes de développement virtualisés +- les langages présentant des **fonctionnalités agiles** diff --git a/algorithmique/cours/modularite.txt b/algorithmique/cours/modularite.txt new file mode 100644 index 0000000..9947bfe --- /dev/null +++ b/algorithmique/cours/modularite.txt @@ -0,0 +1,51 @@ +La programmation modulaire +========================== + +Structuration d'un programme +----------------------------- + +La réalisation d'applications importantes oblige le programmeur ou l'équipe de +développement à se poser des questions d'organisation et de structuration. +Aujourd'hui, on dispose de deux grands modèles d'organisation dont les avantages et les +particularités sont distincts. + +La modularité +~~~~~~~~~~~~~ + +Les données et les traitements sont regroupés au sein d'une même entité à deux +facettes : d'un côté le code proprement dit, de l'autre son interface. La +communication entre modules s'effectue via leur interface. La description d'un +type peut être masquée en n'apparaissant pas dans l'interface du module. Ces +types de données abstraits facilitent les modifications d'implantation à +l'intérieur d'un module sans affecter les autres modules qui s'en servent. De +plus, les modules peuvent être paramétrés par d'autres modules augmentant +ainsi leur réutilisabilité. + +Le paradigme objet +~~~~~~~~~~~~~~~~~~ + +Les descriptions des traitements et des données sont regroupées dans des +entités appelées **classes**; un objet est une instance (valeur) d'une classe. +La communication entre objets est réalisée par envoi de message, l'objet +receveur détermine à l'exécution (liaison retardée) le traitement +correspondant au message. En cela, la programmation objet est dirigée par +les données. La structuration d'un programme provient des relations entre +classes, en particulier l'héritage permet de définir une classe par extension +d'une autre. + +Comparaison entre les deux paradigmes +------------------------------------- + +Il y a dualité entre ces deux modèles. + +- On ne peut pas augmenter les composants d'un type dans un module (pas + d'extensibilité des données), mais on peut ajouter de nouveaux traitements + (extensibilité des traitements) sur ces données. + +- En objet, on peut ajouter des sous-classes à une classe (extensibilité des + données) pour traiter des nouveaux cas, mais on ne peut pas ajouter de nouveaux + traitements visibles de la classe ancêtre (pas d'extensibilité des traitements). + +**La combinaison des deux paradigmes offre de nouvelles extensibilités pour les +traitements et les données.** +