Follow

The programming language was invented in 1972.

was invented in 1966.

My current thought experiment: what if had been built in an APL environment instead of a C one?

@codesections You got causality the wrong way around: Multics begat UNIX begat C.

APL was written in an IBM/360 environment, so no fun new OS or better language was going to emerge from that situation.

@codesections Well, the Bell Labs guys did eventually write an APL, that being S, now superseded by the compatible R. But if you look at the Lions book, it's hard to see how APL would have helped for what they were trying to do.

@kragen @codesections Algol was also pretty useless in the actual spec (most platform versions weren't as useless). C is just "Algol the Good Parts", plus some PDP assembly.

@mdhughes @codesections There's truth in that, but C was also initially typeless, like BCPL and B, and diametrically unlike Algol. And a lot of the syntactic elements were Ken Thompson's personal taste, perhaps informed in part by using a teletype terminal, not being able to touch-type, and being a researcher rather than a manager, bureaucrat, or navy officer.

@kragen @codesections Algol-68 and Pascal family really went into the BDSM type system, but there's a lot of languages where Algol-60 flow control & style were used with dynamic typing (most obviously Scheme, Awk, Perl, Python).

I think most of that space was investigated pretty well. Maybe SNOBOL needed more support from someone.

@mdhughes @codesections Yeah, Algol-60 flow control and indentation are definitely super influential. Scheme, though, I don't think it's safe to describe as using Algol-60 flow control and indentation; it has Algol-60 block structure, but the whole macros/call-with-current-continuation/tail-call approach to control flow is very different from the Algol family (including, I agree, C.)

As for SNOBOL, you might be pleased to learn that Unicon has revived Icon development: unicon.org/

@kragen @codesections Scheme explicitly calls out Algol for giving it lexical scoping, and switching from LISP-like list-processing-everywhere to richer block control structures, tho usually just 'do' or let-loops.

@mdhughes @codesections Hmm, but I think Lisp programs at that time commonly used nonrecursive control structure? I mean from the beginning it had "the program feature" with goto, but Scheme was born around the same time as such things as the MACLISP LOOP macro. Do you think MACLISP got it from Scheme?

@kragen @mdhughes

Oh, man, I wasn't expecting to come up today. My parents programmed it back in the 70s before they left the programming field and got what they thought of as "real" jobs!

@mdhughes @codesections Also, I think it's worth pointing out that Algol-60 didn't have pointers. Algol-68 did, but BCPL was first implemented in 1967. Algol-W did have pointers (and strings, and complex numbers) and was published in 1966.

@codesections On first read, I thought you typoed C#, and I was sitting here thinking, "Wasn't that only created around the turn of the century?"

I need more caffeine.

@mike

> On first read, I thought you typoed C#, and I was sitting here thinking, "Wasn't that only created around the turn of the century?" I need more caffeine.

Yeah, I've always wondered about whether there's a better way to use a hashtag with C

@codesections can you imagine what shell scripts would have been like with an APL keyboard to play with?

@penguin42 as I'm not familiar with #APL, I had to look it up and found this layout image by #Rursus on Wikipedia: commons.wikimedia.org/wiki/Fil
mastodon.social/media/RNgKbCbh

That definitely looks interesting! I could at least see the comparison operators being used.

@codesections

@rudolf @FiXato @codesections Forth is definitely an interesting language; but heck no, I wouldn't ever want to do anything large in it

@penguin42 @rudolf @FiXato @codesections And, yet, I'm in the process of building a Forth environment to be an operating system for a home-brew computer right now.

I don't understand this visceral hatred towards Forth that some people have. It makes no sense to me.

@vertigo @penguin42 @rudolf @FiXato

> I don't understand this visceral hatred towards Forth that some people have. It makes no sense to me.

*I* certainly don't feel any hatred towards , visceral or otherwise. (If anything, I've always had an odd soft spot for it, ever sense I read about it as the right language to build a spell compiler in Rick Cook's fantasy novels).

That said, I've not yet found a practical use case for forth myself

@codesections @penguin42 @rudolf @FiXato Well, there are several Mars rovers operating with Forth. Forth drove the shuttle's robotic arm back the day. Forth powers some of the telecommunications equipment that the public utilities use to report telemetry between power substations, etc.

And, more whimsically, I once had a blog engine that I'd written in GForth years ago, which powered my personal blog for about 4 years before I switched over to hosting on GitHub.

@codesections @penguin42 @rudolf @FiXato To be clear, my reply was in response to the phrase "heck no, I wouldn't ever want to do anything large in it", with emphasis on the "heck no" and "ever".

@vertigo @penguin42 @rudolf @FiXato

> And, more whimsically, I once had a blog engine that I'd written in GForth years ago, which powered my personal blog for about 4 years before I switched over to hosting on GitHub.

That sounds pretty cool, and I'd love to see the code if you still have it somewhere

@codesections @penguin42 @rudolf @FiXato It's up on my bitbucket site, but I have to preserve it and convert it to Git soon.

You can see it as it currently stands here: bitbucket.org/kc5tja/unsuitabl

Not well documented, but at least on a 32-bit Forth implementation, it was functional. I'm planning on rewriting it for more platform independence, especially since I want to run an instance on my #Kestrel3 when it can finally grok networking.

@codesections For a start, it would never have any buffer overflow problems. OTOH, it probably couldn't have fit on the PDP-7 and PDP-11 that Unix was first written on either.

@vertigo

> For a start, [Forth] would never have any buffer overflow problems.

Yeah, but it would have stack underflow problems :D

> Well, there are several Mars rovers operating with Forth.

Yeah, I've heard that has a pretty serious niche in embedded computing, but I haven't done any work in that space.

I still really hope that forth/some concatenative language make a comeback for general-purpose programming, though. I feel like they have some under-explored ideas.

@codesections Did I misread your original post, which was talking about APL, not Forth?

@vertigo

> Did I misread your original post, which was talking about APL, not Forth?

No, I'm interested in both languages—both seem to have had really powerful ideas that aren't explored very well in modern programming languages.

('s idea of array programming is explored in some languages, but using math-like notation to enable clearer, more concise programming has been basically dropped)

@codesections OK, I was just wondering, making sure I wasn't seeing things. I'd woken up not long ago, but thanks to my stupid cats, haven't gotten more than 2 hours contiguous sleep all last night. It's easy for me to see things under such conditions. :)

@codesections Stack imbalances are definitely a valid concern; however, I counter-argue that the Unix kernel and most of its CLI tools are not prone to such bugs. More precisely, if such an imbalance were to happen, you'd see it crash _very_ early on in testing. The only times I've suffered latent imbalance bugs was when working on code paths that are infrequently executed (and, thus, infrequently tested).

@codesections re: comeback potential -- it would be nice. While traditional infix languages are convenient to work with, they exhibit a relatively poor tool complexity versus programmer payoff ratio. Proof of this can readily be found in anyone who expresses an interest in writing their own OS, or designing their own CPU, or whatever. It took the entire RISC-V community several *years* of effort before getting a working GCC and libc combination.

@codesections And, to be clear, there are still open issues; but, now that several Linux distributions have been made for the architecture family, it's no longer a technical matter to fix them; politics must now be a consideration.

IMO, this is the hallmark of excessive complexity. When I was a dev for AmigaOS, I remember things getting fixed (up to and including complete ABI changes) much more rapidly, and not having nearly the problems suffered today.

Sign in to participate in the conversation
Fosstodon

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.