HerrMonnezza

I wonder if there was any followup, trying to assess languages explicitly addressing programming education (e.g., Logo, Pyret) against the sins and recommendations of this paper?

Does anyone have experience with Logo environments still available today? And what results did you have with teaching kids to use them?

Grand-Parent (comment)

Not sure if there's anything written on the topic, but I guess you can take a look at some of Damian Conway's public code to see it being used. For example: https://metacpan.org/release/DCONWAY/Keyword-Declare-0.00101...

The issue is that `int(x) / int(y)` would yield an int result in Python 2, but a float result in Python 3. So you had to find all the spots in your code where `/` was being used as an integer division operator and replace it with `//`.

Since Python 2 does not have any form of type annotation, this made the task hard to do automatically and error-prone.

I had the same thought. Reading the Wikipedia page for the respective Italian law [1], it seems to me (but IANAL) that it would only apply to ownership of material things, not apply to monetary claims.

However, Italy also abolished all noble titles with the fall of the monarchy in 1946 -- I would have also expected that fiefs and any associated claims had been extinguished at the same time...

[1]: https://it.wikipedia.org/wiki/Usucapione

The point is: Logo >> turtle graphics.

Quite some time ago, I built `j2pp` to be a general text file preprocessor, à la m4 or cpp but using Jinja2 syntax: https://github.com/riccardomurri/j2pp (being written in Python seriously hinders its deployment, though)

Another tool that I wrote (and have used quite a lot) is ElastiCluster: https://elasticluster.readthedocs.io/ It's a CLI tool to deploy compute clusters (of different types (well, it's basically a large collection of Ansible playbooks with a Python wrapper), but mostly focused on batch-queueing systems) on IaaS clouds. There's now multiple tools for doing the same but I think this one is still one of the few (if not unique) to be able to deploy multiple types of clusters on multiple clouds.

Literate programming seems to becoming popular in the R community due to KnitR and Rmarkdown. This seems to have sparked a few similar-working tools with possibly broader scope and adoption. In my bookmarks I find:

- knot [1]: tangles source code from a text file formatted using plain markdown syntax, can use any markdown converter for weaving into a printable document

- snarl [2]: extends markdown code blocks with syntax used for tangling, its "weave" steps just removes the additional syntax and outputs plain markdown

- pylit [3] [4]: a bidirectional converter: code to formatted text and back. Uses reST for formatting, and preserves line numbers which is useful when debugging. Not an LP tool strictly, as it doesn't define/rearrange code blocks so you have to write your script in the order the compiler wants it, not in the order that would make the best exposition.

Both seem to preserve relative indentation of chunks, so would be useful for Python too.

[1]: https://github.com/mqsoh/knot [2]: https://blog.oddbit.com/post/2020-01-15-snarl-a-tool-for-lit... [3]: https://github.com/gmilde/PyLit [4]: https://github.com/slott56/PyLit-3

I have used Noweb a few years ago [^1] for a small Python program; there were two major issues with it, from my PoV:

- I had to take care of writing each Python code chunk with the amount of indentation appropriate for where it had to end up, since Noweb does (did?) not respect relative indentation of chunks when tangling.

- Debugging the resulting script was more painful than plain Python sources, as all the debugging info (line numbers, etc.) referred to the tangled code and not to the actual noweb source file I was editing.

[^1]: Looking at the website, it doesn't seem to have changed much since then.

  In other words, static typing is pointless. It has, maybe,  
  some documentary value, but it does not substitute
  documentation on other invariants. For example, your 
  invariant might be something like I’m expecting here a 
  monotonically increasing array of numbers with a mean 
  value of such and such and a standard deviation of such 
  and such. The best any static type checking will let you 
  do is “array[float]”. The rest of your invariant must be 
  expressed in words as a documentation of that function.

I wonder if "design by contract" [1] tooling would help here? It seems to me one could express the stated invariants of the array as pre- or post-conditions on any function processing that array.

[1]: https://wiki.c2.com/?DesignByContract

Why do you consider the survey design "sloppy"? E.g., doom-emacs is a well-known emacs distribution; there nothing weird if 18% of survey respondents use it.

Whether the survey respondents are a representative sample of the general emacs population is a different question, and one which is very hard to answer given that we have no other data about people's preferences in emacs. Hopefully, the survey will become more popular with time, so we'll see results approaching the "true" values.

Relevant Oatmeal comic: https://theoatmeal.com/comics/bees_vs_hornets

Twice...

I am pretty sure Emacs could already read and send email by the time JWZ formulated this law...

Having read both PAIP and Practical CL, I do not see them as comparable: PAIP teaches classical AI algorithms, and introduces as much CL as nacessary to carry out the task; Practical CL instead has a goal of teaching Common Lisp, and uses coding examples to showcase features the language.

I agree that the MP3 streaming server example in PCL looks outdated, but so are many topics in PAIP as Norvig himself points out at the end of his retrospective [1]. (And I still think that the MP3 parser in PCL is a really good example for showing Lisp I/O, binrary processing abilities, and subtleties of CLOS, despite not being something that anyone would code as a side project nowadays.)

[1]: http://norvig.com/Lisp-retro.html

I think you meant to say that the "condition handler can run before the stack is unwound." (whereas exception handlers in Java, C++, Python unwind the stack while searching for the handler)

(I agree it's a nitpick, but since your comment is likely directed to people who do not know the condition system, it's better to be precise.)

I really really wish Ubuntu had decided to ship MATE as their default desktop at the time of the GNOME 2 to 3 transition, instead of trying to create their own DE, abandon it 4 years later, and then reverting on GNOME3 ...

This talk by Chris Lonsdale gives some practical advice on learning new languages fast. Most of it is along the lines of what the article says, but seems to say that the key part is to get a "language parent", whom you can have conversations with and will try to understand and reply to you, no matter what (like parents do with small children):

https://www.youtube.com/watch?v=d0yGdNEWdn0

3) Backslash before keywords looks inspired by TeX to me.

Also: https://www.ale-lang.org/

From a cursory reading of the README, I would say that Metacall allows any of the supported languages to call any other one, whereas Swig only allows calling C or C++ code. (Swig takes a `.h` file as input and then generates the bindings for the desired target language.)

The initial submission lacked the tag in the title.

This is from (1993)

This sounds interesting! Can you give any reference to your publication or URL?

The HN entry title might be misleading: this is a Python tool, Perl is only mentioned in the Readme for comparison.

Somebody took your idea quite literally: https://www.coi-dev.org/

(HN discussion: https://news.ycombinator.com/item?id=19216077 )

The announcement is somewhat click-baity: the seeds have not sprouted directly on the moon surface; they're enclosed in a pressurized container with earth soil and air.

This is a biographical page about Cantor, rather than an article about the Continuum Hypothesis proper. (Which is explained, as are many of Cantor's results, as narration proceeds along his life and achievements as a mathematician.)

> Centuries-old typography rules can't be applied directly for screens.

Some of it, certainly not.

A (larger IMHO) part of typography wisdom has really been distilled from experience making text easier and prettier to read over generations, and should not be thrown away lightheartedly because "screen is different from paper". Yes it is, but human eyes and brain are the same ;-)