@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.
@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: http://unicon.org/
@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?
@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.
> 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: https://commons.wikimedia.org/wiki/File:APL-keybd2.svg
That definitely looks interesting! I could at least see the comparison operators being used.
> 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 #forth, 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.
> 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
You can see it as it currently stands here: https://bitbucket.org/kc5tja/unsuitable/src/default/
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.
> 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 #forth 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?
> 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.
(#apl'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.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.