Nested Maps are the ultimate data structure as they can be merged. Down with ordered lists. Maps allow you fast path based access patterns etc. I love JSON without arrays

I disagree. There's a reason why there are so many data structures. Perlis' quote goes back to a time when the applications for computers were different, and far fewer, than today. It expresses a mindset believing that there is a universal foundation for all of computing, which I think is wrong.

100 functions that operate on one interface into 10 data structures.

Yeah I think I'd agree with Konrad here and disagree with the quote, but mostly because there will be times where if you change the data structure even slightly, it makes it possible to make the functions much easier to understand

I agree with Perlis if you really restrict yourself to those two options where you have to treat every new data structure completely orthogonally. Otherwise building up a corpus of functionality just takes forever. It just seems like such a false dichotomy.

Here's a heretical question that I found myself asking: why do we use data structures at all?

I believe that the goal of programming is to produce assembler that fits onto small and cheap non-development machines (like game consoles, etc.). From that perspective, data structures are only useful for developers, hence, data structures should be totally expunged in released production binaries. Users don't care if developers employed data structures, elaborate type systems, functional programming, etc, etc. As a developer, I want freedom to invent, hence, I do not want to be stuck with someone else's idea of what a good data structure is for their problem domain. In the 1950s, the push was towards finding schizophrenic data structures - data structures that helped developers think, while, also, ones that could be compressed down to being "efficient" on cheap hardware. We have more degrees of freedom than that today.

I guess from that perspective data structures are patterns of controlled access to memory?

By "10 functions on 10 data structures", do you mean different 10 functions per data structure?

Different data structures exist because different data structures have different ergonomics, both in the mind of a human developer and in terms of the computation required to manipulate them, no?

As with all problem-solving, is there more to it than the answer “what works best for the problem at hand?”

Paul Tarvydas Your idea sounds much like the Forth approach, nicely summarized in this blog post: Data is code.

I agree that the question of data structures matters only for developers. But in my corner of computing, users and developers are strongly overlapping groups. Data structures are not an implementation detail, because they are part of the interfaces between different parts of a software assembly.

Wondering... if the quote that started this thread isn't just another aspect of the general CS/tech attitude of valuing Code over data.

Steve Dekorte I think that's the "spirit" of the quote but not sure, the quote is not mine 🙂

Konrad Hinsen that’s an interesting perspective because Rich Hickey and the clojure community use the quote as evidence that data is more important than code. Maybe it’s that the lispers consider data structures code but the data inside of lists just data?

Data structures are not an implementation detail

Concrete implementations are, at least in the Clojure philosophy. For most application programmers most of the time the important thing is whether the interface is a map, vector, or set, not whether the map is implemented as an association list, property list, or hash map.

There's an awful old common lisp mailing group thread where they tore a guy to shreds for suggesting this ~25 years ago. Now it's standard practice in Clojureland and devs love it.

@Dave Liepmann I suspect that the distinction between abstract and concrete data types was not around when Perlis published his epigrams in 1982.

BTW, in Common Lisp this is quite common as well in recent libraries, but not nearly as widespread as in Clojure. Old habits stick.

Prolog terms

I'd be curious when it became mainstream but Liskov published dl.acm.org/doi/pdf/10.1145/800233.807045 in 1974

Without interoperability though, it's possible that having abstract types isn't as much a win for reuse.

Mariano Guerra I'd say 10 data structures with 10 functions each, or rather: 10 (data structure) classes with 10 instance methods each.

@Alexander Bandukwala Thanks for digging out that paper! Now I wonder if Perlis was aware of it. And now that I think of it, Smalltalk objects make abstract data structures as well, and Smalltalk was around and widely discussed in 1982.

To me the best data structure is... function. A closure to be more specific. You can model any other data structures with functions. An expression of the form user.email can be understood as email(user) or user(email) . Obviously, email can be defined as const email = (user) => user(email) . Similarly, obj.foo(x, y) translates to obj(foo)(x, y) or foo(obj)(x, y)

Hickey used this quote to contrast building your project from 666 different-purpose maps (which all share assoc update keys vals dissoc pr-str = empty? merge merge-with and other functions)

with building it from 666 different c#/java classes, which each require their own implementations of everything, and exponential explosion of custom code if you need them to interact, none of which could be reused elsewhere even in the same project.

it is a good idea. We have to go further now. We should be implementing our functions or algorithms on top of abstractions, not data structures

youtu.be/cPNkH-7PRTk?t=2243

another use in a different context, where idea is: if you share known datastructure as an "api" – client has way more options how to interact with it:

akovantsev.github.io/corpus/hickey#,ten%20data,tRoVyblAGrs,1042,0:17:22to_have_ten_ten[…]ng_in_very_tiny_increments_but_I_believe_that_quite

note: the final section got added very recently. i wrote about it here if anyone's interested

todepond.com/wikiblogarden/london/canon/chaos/no-escape

I've been surprised by how Bret Victor's work is little known, at least in Europe. I just spent two weeks with really top notch creative designers in an academic engineering dept and no-one had heard of him or realtalk/dynamicland. He's clearly really famous in certain tech subcultures and seems to suffer from that in some ways, but I haven't really worked out which ones he is and isn't famous in..

One problem with people enthusing about Bret Victor in the way you describe is that misunderstandings of his work get amplified

What if the future of coding is analogue?

EE. The analogue kind, not the digital variant. Lots of pre-existing literature and notations. A phase shifter guitar pedal is based on analogue EE. Early music, patch-board synthesizers were based on analogue EE. Line6 amps probably use both analogue and digital EE - analogue for the amp, digital for the digital modelling (FFT code running on DSPs and CPUs). Analogue EE involves massive asynchrony. Software involves massive synchrony.

ee as electronic engineering?

Yes. EE dealt mostly with analogue. Then, a portion of EE swung to the other extreme with digital. Maybe we need a middle ground mix of both?

Yes agreed, I think you can't really have one without the other so analogue people are in denial of the digital and vice-versa

Maybe it's simpler than that? Maybe It's just a need to remember that pure research not= viable product. A generalist (aka "production engineer") stands between bench prototype and viable product. My guess at the above photo is:

Bench prototype: Analogue Potentiometer -> Analog to Digital Converter (ADC) -> laptop -> stepper motor driver -> 3D printer

(Guesstimated costs): $0.25, $10.00, $1,000.00, $5.00, $100.00 = $1,115.25

Versus, production engineered: Analogue Potentiometer -> Analog to Digital Converter (ADC) -> Arduino-> stepper motor driver -> 3D printer

(Guesstimated costs): $0.25, $10.00, $5.00, $5.00, $100.00 = $120.25 (probably much lower with some more thought)

The actual UX is the potentiometer, i.e. 0.02% of the cost of the bench prototype, or 0.2% of the cost of the product. You could control something like 50 pots before the cost of the pots was 10% of the product (as guesstimated).

not sure that the pots are a great example there, though... you arguably get a much better similar interface (plus bypass the need for the ADC) by just using a high quality rotary encoder