APL (Dyalog Unicode), 62 bytes (SBCS)
,⌿⎕{⍺∊⍺⍺:((∊|⍴¨⍺××)n)(⍺/⍨0⌈2÷⍨≢⍵↓⍨n←⍺÷⍨+/⍵)⋄/∘⍺¨⌽0 2⊤≢⍵}⌸⍨∘|⍨⎕
Try it online!
The initial "straightforward" version was around 76 bytes long; folks at The APL Orchard helped me golf it substantially to the snippet above. Thanks!
How does it work?
Explanatio...
Honestly the explanations for the subproblems feel "wrong" (I'm taking the APL code right-to-left and almost mechanically translating to English!), but at least showing the table that comes out of the Key operator is helpful, I think.
It's possible the approach is different from them. I saw Key and ran with it. I didn't read the other golf-language solutions. Gonna take a peek now.
Folks are grouping multiple times, I'm grouping just once at beginning.
Sorting values and taking 2-fold reduce was something I toyed with but didn't get anywhere. Looks like it would be viable after all.
I've had great fun with this, and learned a few things by seeing you folks golfing. And to think I wanted to try the padding optimization on the query engine :)) Welp, maybe tomorrow. I have it sketched out on paper (much less code than I anticipated), now just to try it out on real data!
It surprised me first (not what I'm used to from FP languages) but it's really handy, yeah!
before I sketched this out I was like "man, I'll have to (padding rho 0),original data" but nope!
But I also don't hold lack of overtaking against the other languages. APL is overspecialized to numbers and characters. Would be hard to conjure default values for "type Card = Heart | Club | Diamond | Spade" (bad example but I'm too tired to type something more convincing) in an useful manner for the tasks done in those languages
For a prototype and an ADT, I guess one could define a custom default value when it makes sense. When it doesn't, it's nonsense to write a program that requires one anyway
CMC: Collect lines of input text (⍞) until a blank line is entered, then return that as a vector of character vectors, without the trailing empty vector.
@RomillyCocking Thank you. Now, if you compare to a similar article you'll see some differences in both style and content. Do you want to polish this new article or should I?
@Adám That's true, in as far as it applies, but it's based on a false premise. APL did become widespread, for a while. Of the 100 largest UK companies, in 1986 well over 30% used APL for mission-critical applications, and Gilman & Rose's 'APL an interactive approach' had sold over 100,000 copies.
In the 1980s there were lots of things that businesses needed to do that nothing else could do as well.
@Adám I'm happy to do polish the 5100 article, but not today.
@Adám I think there's potentially a huge advantage for those in AI working on the frontiers of RL and ANNs. Almost all published papers describe their Algorithms in math notation. They may or may not provide implementations. If they do they are typically in TensorFlow, PyTorch, R or matlab. An APL implementation would be as readable as the math and yet be executable.
@rak1507 Yeah, we definitely need to improve the experience of installing both APL itself, and libraries/packages. And we really need to look at keyboarding too.
@Adám TryAPL goes a long way towards that goal. The thing it lacks (from my POV) is the ability for the user to attach their external storage - Dropbox, Google Drive or AWS storage for example. Several great web-based apps do that well,and it would permit the saving of wssws and the use of external apl source files.
The ability to load notebooks is a big step in that direction but I have not yet found a way to make notebooks persist in a session. (That would also solve the problem)
I feel like tryapl does what it is meant to (introduce beginners to APL) well, and there's not much need to give it loads of extra functionality. Docker containers + rentable servers sound like a better idea to me
@RomillyCocking We also have the "trypl workspaces" in the "File" tab, but have not yet implemented a ?ws=URL which would allow you to pre-populate a tryapl link with data
@rak1507 If you want beginners to learn enough APL to be useful I think you need to show the language solving real but simple problems, and to make it easy for them to start doing that on their own.
@RomillyCocking considering one of the inspirations was tryhaskell.org, it has amazed me going back there recently to see how little you can actually do on tryhaskell.org
@RomillyCocking not at all - it is my dream to have a URL you can go to to get a fully functioning RIDE in no time / no installation, but alas
<strong opinion warning>The vital thing is to reduce or eliminate friction for beginners and then ease the path to installing APL and using RIDE</strong opinion warning>
Morten wants to have some of these images already up and running, so that when you connect, you get one right away, and then we spin new ones up as the pool diminishes.
@MartinJaniczek I've thought about multiple people working on the same workspace, but it has many potential issues. I guess if only one person had write access, it could work…
@MartinJaniczek I think the RIDE link can be accessed in public though, so it might work if you share that link (instead of the Gitpod instance one) to others.
@Adám My company is not there yet :) I wanted that live sharing for eg. a Google Meet call where I show off and explain some APL to the colleagues working on their implementations of the same thing I work on
But I'm guessing sharing my screen will work reasonably well
@Bubbler I am mostly using my school laptop at the moment rather than my desktop pc, and I don't have any programming languages (other than dyalog) etc installed, so being able to still do stuff online sounds great
Are any of the language implementors here familiar with IBM's IL? It was an APL-inspired Implementation Language that was used by IBM to implement a portable APL.
You can read the only paper I know of that describes it here: https://pdfs.semanticscholar.org/e748/f7d4e64883d0a3ec518fc3b79c5b46fd81ed.pd
@Adám oh that's sort of disappointing. There should really be no issue to allowing it afaik - send all messages to all clients, and treat received messages from any all the same. The protocol is built in a way that that should always work afaik
@Adám I would be content if people were allowed to enter their own expressions and everybody seeing both the expression and the result. No need to see them typing it.
And it's just what I expected to happen ("connect multiple clients to the same session"), not something I sorely need. As you said, screen sharing is a viable alternative.
Modern screen sharing tools allow taking control too.
Having a free-for-all would quickly become a mess. What happens if I'm editing a function and someone else closes the window with a different definition? What I was typing would be lost.
Never mind the editor. If I type an expression, but have not pressed Enter yet, and someone enters an expression, my session log would change, and my partial input would need to be lost.
It makes much more sense for multiple people to access a single synced workspace, but each with their own interpreter. And this already works.
(… I claim, having not actually tried it ― but theoretically, it should.)
@dzaima It'd sync whenever someone closes the editor (or saves from within it). Link monitors a shared drive and updates the workspace when it detects file changes, and it writes changes to disk, so…
@Adám oh, so others wouldn't even see me doing a←1. That definitely doesn't work for live exploring
@Adám I guess the separator could only transfer info about open windows to the people who opened it, and not allow multiple opening the same one at the same time (or maybe only the first has write access?). Kinda sucks though, and makes the thing much more complicated than the simple idea of just copy-pasting messages
@dzaima No, you'd have to do ]add a to push your changes to everyone else. We are working on a workspace crawler that'd detect the change and auto-sync it ifa has been registered as part of the source.
@dzaima (for reference, the current behavior is that the cursor just forcibly jumps to the end of the log when there are new things logged from outside RIDE, but otherwise it handled it just fine. That should be rather simple to fix if one wanted to)
Again, I think a fine-grained syncing would be more frustrating than useful. If you pair-program, then shared control (like provided by Zoom) makes more sense.
@dzaima It'd not match the interpreter's native behaviour though. Try executing 't'⎕WC'Timer'5000 1('Timer' '⍎⎕←⎕TS')
@Adám that only allows one person editing at one time. A RIDE protocol hack could allow for that too if you wanted to, with a bonus of less bandwidth & better quality/latency, and allowing doing separate things too
@Adam I've local-paired doing TDD in Java (ugh) extensively and remote-paired (in Python and APL) occasionally. Local pairing usually has the devs alternating use of the keyboard and mouse. (A writes a test, B makes it pass, B writes a test, A makes it pass). It can be quite a pleasant and productive experience.
Remote paring *can* work but IMO it always feels painful however it's done.
@dzaima I don't think two people doing things at the same time makes any sense, unless so disconnected that they might as well have their own sessions. RIDE as a form of screen share could work, but you'd anyway want at least voice comms, which I do think is beyond RIDE's scope.
@RomillyCocking Sure, I've done that too, and you can easily have two monitors, keyboards, and mice, if you want (though I've never seen that in practice ― sitting next to each other at a single mouse and keyboard seems to work fine). Anything remotely is more awkward, but surely the two devs need to see the same image.
The late sheep-and-cheese google group had quite a few experience reports from skilled devs doing remote pairing (though none in APL). I'll see if I can find any worth sharing here.
@RomillyCocking well, you could still have git, just not the need to commit constantly (and if you wanted to, you could probably bodge up a thing to create commit on any file change anyways)
That's true, but do you really want version tracking for every little change?
@dzaima Ah, good point. No need for a bodge. Link already has a feature that allows you to hook into whenever it changes a file, so you could simply put git commit there.
The way that ENVY worked was very different, and you'd need to use it for a while to experience how comfortable it felt. Everyone I know who used the original ENVY still feels it was the best ream development environment the've ever used.
@rak1507 depending on the editor, there might be better ways for local tiny change history. (IntelliJ has something of the sort, and google docs just straight up stores each character thange)
I'm working on a project, going through issues. So I change a bunch of things to fix an issue. No the issue is fixed. At this point, I should commit (or squash, if I've had auto-micro-commit on).
I guess at that point, I could ]commit Fix #123 and that'd squash for me.
Anecdote: being indoctrinated by RIDE's ` bindings, I even uninstalled the IME on my wife's Windows laptop as it was a bit invasive (might have been my bad settings of the keyboard layout settings, to not make it leak to other apps etc.)
@rak1507 Nobody seems to remember. IIRC, until version 12.0 we gave a choice at install time: ALtGr or Ctrl, with AltGr being the recommended option. Then, with the introduction of Dyalog Unicode, the IME was introduced, and the AltGr option was removed.
One important reason why "the top people at Dyalog" use Windows is that nearly all of our existing user base is on Windows. I agree that we need to do more to move faster in the direction of embracing new IDE's, but we need to be careful not to alienate the people who feed us.
The reason for the choice of ctrl rather than alt is that alt is a Windows accelerator key, Alt+B might be a keyboard shortcut for a menu item or button. Therefore, back in 1990 or whenever it was, it was felt that ctrl conflicted less with the way Windows applications typically worked back then.
Today, alt seems less conflicted than ctrl. On of the reasons why I haven't been keen to change is that my current feeling is that all of Alt, Ctrl or even the Windows Key are "doomed". The walls are closing in and the OSes and editors will gradually consume them all. The prefix char is the solution.
@dzaima though i still have all of ascii without altgr on the latvian layout, so the transition doesn't change anything for it. I think the best (but also the hardest) option would be to have completely separate layouts per language
These are difficult issues and people have very different opinions. Making everyone happy seems almost impossible. We have agreed at Dyalog to have a meeting to rethink it all this spring, once version 18.1 is well under way.
My current thinking is 1) we should make it easier to choose the "APL key" 2) we should try to make prefix typing available everywhere as an alternative
For many years, it was almost impossible to type {[]} on a Danish Mac. When I incredulously asked a Mac user about this, he said "yeah, programmers don't by Macs with a Danish keyboard, everyone knows that".
It may be a problem that the Dyalog CTO is too adaptable. I seem to be able to become productive on a keyboard with a different APL key or layout very quickly. I even managed to install our product "SQAPL" in Paris without swearing too much after the first 30 minutes.
(S Q A are all in unfamiliar places on a French keyboard)
Anyhow, this input is all useful, although the labelling of people as "top people at Dyalog" as if that explains something feels a bit unnecessary ;-). The development manager and several developers use Linux primarily, unfortunately our latest C developer selected Windows rather than macOS because he wanted to wait for the new Mac processors before getting a Mac.
@MortenKromberg None of the Linux guys write much APL at all. Even Marshall, who was on Linux, never got around to setting up an APL keyboard ― he'd copy and paste symbols from Vi!
@rak1507 the people who develop under Linux agree with you. The Windows guys love their VS projects and some of the debugging features available there. Everyone seems to hate Apple because they impose such bizarre things on you and keep changing the rules.
It is true that the people who use Linux tend to be "engine room" developers and the Windows guys are more focused on applications and working with users. The people at Dyalog who work IN APL rather than C are slowly moving from Windows to Linux, at least for debugging after deployment.
@rak1507 The latest C developer is a kid straight out of Uni, so he's still a Mac fanboi
I was wondering what possibilities there are when trying to create "large" APL applications.
E.g. say I wanted to create a basic neural network framework. In Python I would create an object for a generic network and then create classes, e.g., for the activation and loss functions.
And then a user would create a network and possibly assign different activation functions to each layer and any of the loss functions.
In APL I have no idea how to build something with this type of flexibility.
Right. We're back to the question of more than two args and destructuring. Namelists in tradfns are probably better approach once you start hitting that limit.
In APL I would avoid using objects, and instead go for a table driven description of the network, perhaps containing the names of the functions - or if that is distasteful a namespace containing the function. I would stay away from OOP in most cases.
Either that or, as Morten says, pass in an object as a way to provide multiple named arguments. This also makes for a convenient way to leave something with its default: Simply omit it.
@MartinJaniczek I am ok with passing 3 or more values. My issue is with non-array things.
I can have arrays of namespaces, correct? That I can deal with. I could have each layer to be a namespace with references to the different things I need.
I should probably do that in my own code instead of juggling ⍺ ⍺⍺ ⍵⍵ ⍵ around between functions where each means something else (and they're already containing multiple items themselves and need to be destructured)
dfns already don't have automatic destructuring. Though you can do it manually with (a (b c))←⍵. I can't think of a good syntax to allow even manual destructuring of a namespace while also auto-localising the names.
@dzaima (i don't particularly like that syntax, but there aren't many alternatives)
BQN has ⟨a,b⟩←𝕩 with ⟨newA⇐a ⋄ newB⇐b⟩←𝕩 giving different names for the created variables. Kind of abuses overloading of vector destructuring, but ¯\_(ツ)_/¯
APL (Dyalog Unicode), 62 bytes (SBCS)
,⌿⎕{⍺∊⍺⍺:((∊|⍴¨⍺××)n)(⍺/⍨0⌈2÷⍨≢⍵↓⍨n←⍺÷⍨+/⍵)⋄/∘⍺¨⌽0 2⊤≢⍵}⌸⍨∘|⍨⎕
Try it online!
The initial "straightforward" version was around 76 bytes long; folks at The APL Orchard helped me golf it substantially to the snippet above. Thanks!
How does it work?
Explanatio...
