tangus

Here's an index of sorts. I couldn't find anything better.

https://archive.org/details/byte-magazine?sort=date

I guess they wanted to keep working on their slides (at least for the moment) and not be forced to go debugging. Sadly, the hang was deterministic, so they didn't have another option.

Aren't they basically saying opposite things? Perlis is saying "don't choose the right data structure, shoehorn your data into the most popular one". This advice might have made sense before generic programming was widespread; I think it's obsolete.

My minuscule pet peeve is that having only one source where the number 5 is depicted with a triangle (all others show it as a separated segment, like the number 6 but shorter), that's how every article or library draws it. It's all because the guy who wrote a book about them saw that source first so he based his figures on it.

Here's a small summary about the numbers with many examples: https://www.unicode.org/L2/L2020/20290-cistercian-digits.pdf

Everything they have is downloadable. Go to their home page and follow the links.

Everybody carries a gun in Heinlein stories, so those terrorists will be quickly dealt with by armed citizens, thus confirming the superiority of Libertarianism.

For the record, if you want to avoid the creation of intermediate arrays, you can:

    lst.lazy.grep(Array).flat_map(&:itself).sum

But the point is the interface, not the implementation. Efficiency doesn't mandate assembly-like DSLs. Your interface could be as clear and clean as Ruby's and produce fast, inlined code by the power of macros. Ruby doesn't have macros, so chaining lambdas is the best it can do.

Ruby also has call/cc. None of the iterating methods has any provision to make them "safe" from it. They aren't safe from modifications to the iterated collection either. I think it makes sense; being forced to accumulate using only linked lists and having to be constantly on guard to support a rarely used quirky feature is a bad tradeoff IMO.

Careful. Seeing how I was downvoted for asking, it looks people here don't want that information to spread.

It may be somewhat awkward; zipping collections to iterate over them in unison makes the first one (the sender) seem special, while it not necessarily is. And accumulating more than one value isn't always straightforward; you usually have to reduce explicitly. But it's so much better in the general case!

Like the example you showcase your macro with. In Ruby it would be:

    lst = [[1, 2], :dud, [3, 4], [5, 6]]
    lst.grep(Array).flatten.sum
    => 21

  def partition (arr)
    yes = []
    no = []
    arr.each do |elt|
      if yield elt
        yes << elt
      else
        no << elt
      end
    end
    [yes, no]
  end

Looping in Ruby is the opposite of awful. You only have to define an `#each` method in your class and include the `Enumerable` module, and you get a plethora of composable methods to iterate and accumulate in every which way. I find it nothing short of brilliant.

It's paywalled, please provide a workaround.

In the late 90's I had a girlfriend who worked for a shop that made web pages in COBOL. I thought those were COBOL's death throes, but apparently I was mistaken...

They provoked the strike on purpose by giving the workers an unacceptable contract. The aim was to wreck the union (they succeeded). They prepared in secret for two years for this.

Here's an account: https://www.huffpost.com/entry/wash-post-busted-pressmens-un...

Also related: https://puzz.link/db/

Even if it didn't dedupe strings, mutable string literals means that it has to create a new string every time it encounters a literal in run time. If you have a literal string in a method, every time you call the method a new string is created. If you have one inside a loop, every iteration a new string is created. You get the idea.

With immutable strings literals, string literals can be reused.

Strings are going to keep being mutable by default. Only strings created by string literals won't be.

I do not understand how you can even begin coming to the conclusion of ...

Obviously he's not serious, he's playing the part of the out of touch old man.

Related to "Last is first", old Spanish books sometimes put at the end of the page the first syllable of the next page. (It was quite disconcerting when I first saw it.)

They say it right in the next sentence.

But fb2 files are marked up text, which is (relatively) trivial to index. The bulk of Anna's Archive's books are made of from scanned images.

I don't think in Red a function can decide whether to evaluate its arguments or not. It's more like a Logo: functions have fixed arity, so you don't need to delimite the call, and lists ("blocks") are always quoted, so you need to explicitly evaluate them.

Not very reliable, this Phantom thing.

I've seen it. Sometimes a DSL is more readable than trying to shoehorn control flow into method calls (".then().catch()..."). Or see C#'s LINQ.

Besides that, in Buenos Aires, for instance, every access to the street has its own address. A building with 2 entrances (front door and garage) has 2 addresses, etc.

Just in time to kill the giants sloths?

You can pay the penalty and get safe container access, too. AFAIK, C++ standard containers provide both bounds checked (.at()) and unchecked ([]) element retrieval.

And how do we escape those characters? With ESC (27)? Inside a SI/SO (15/14) pair?

I think CSV or TSV are good enough. People keep trying to find a format where you can separate the records and fields with a simple string.split and there's no need to contemplate escapes.

But that's not possible, no matter the format you'll have to parse it right. And then, a format that uses visual delimiters has the obvious advantage of being editable with any text editor.

Yeah, well... you won't get very far with just TP-style objects and strings and without dynamic arrays.

Yes, but Delphi is no rocket either.

It doesn't deserve a second look.

The only things Pascal has going for it nowadays are: (1) static executables and (2) some good libraries (and not many at that). As a language it's extremely primitive and unergonomic, and the Free Pascal maintainers don't really want to improve it because they are used to it.

As an implementation, it's the slowest compiled language there is. Everything is heap allocated (and reallocated) and it doesn't even have an efficient allocator, not to mention garbage collector.

The only reason there is to use Pascal nowadays is when you need one of the two things I mentioned and the results offset the torture that is programming in that language.