Cadoles/formations
20
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

début du cours d'algorithmique pour le CESI

Browse Source
This commit is contained in:
gwen 2017-03-17 11:33:14 +01:00
parent d7a4bcc466
commit 9cbe2e337a
7 changed files with 971 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

216
algorithmique/cours/Makefile Normal file
View File

@ -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 <target>' where <target> 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."

BIN
algorithmique/cours/_static/cesi.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 59 KiB

355
algorithmique/cours/conf.py Normal file
View File

@ -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
# "<project> v<release> 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 <link> 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

99
algorithmique/cours/fondement.txt Normal file
View File

@ -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.

30
algorithmique/cours/index.txt Normal file
View File

@ -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`

220
algorithmique/cours/langage.txt Normal file
View File

@ -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**

51
algorithmique/cours/modularite.txt Normal file
View File

@ -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.**