its sort of a chicken/chicken's egg problem. id personally like to see more apl jobs (mostly out of self-preservation). i also think theres plenty of reason why a "startup" would pick an array language as a competitive edge
I'll be honest I don't see much advantage unless you're doing something that benefits from that, it seems to me like APL would be more suited taking up some of the fortran market
when theyre building a software platform, they need to work very closely with their analysts to port that pricing model to wtvr language/set of languages they chose
@cannadayr this combination of features is consistent with how iverson described his notation's advantage (i watched an interview with him on yt once) - concise and does bulk operations
Good news: I raised the radical idea that now that we do a new thing ("#!" scripting) we have a once-in-a-lifetime opportunity to right some wrongs. So we should ignore all global states (⎕IO, ⎕ML, etc.) when running a script. And who would have thought… my idea was met with wide approval!
Whatever the interpreter default would be if you simply drop an interpreter onto a computer without installing or setting any envvars or registry settings etc.
@Marshall Very simple: your script can begin with ⎕IO←0
The only difference from what you have now is that you know what kind of environment you begin with, so you don't have to set any settings that need to have default values.
@ngn the most recent/well known example I can think of is early whatsapp. they were able to build a platform to handle hundreds of millions of users with maybe a cpl dozen engineers. and part of that was because the technology they chose (erlang) acts as a very concise service definition language. they didnt need hundreds of engineers, because they chose an abstraction that was capable of modelling their problems very tersely.
@dzaima No, but you can call existing code from a #! script.
CMP: If you have the foo.apl ("#!" script) and next to it is a foo.dcfg (Dyalog config file), should the interpreter apply the settings from the config file, or should all settings have to be set from inside the script?
@ngn My guess is that you don't think having two different defaults for #! and not-#! is an issue, because you would only use !# and you don't care about anyone but yourself and those that agree with you. Is this a correct guess?
I'm not ngn but I think having two different defaults for #! and not-#! isn't an issue because I'd value ease of use for newer people over large legacy code bases being able to hack scripts into their system
@dzaima Hm, that's an interesting idea. The config file is already launchable on Windows, and with dyalog CONFIG=path/file.dcfg everywhere, so in principle it'd be possible. Now sure how the interpreter would be able to tell what kind of file it is given.
@rak1507 I think Dyalog's official policy is that existing customers are more important than new ones. It surely translates to having fewer (=no) new costumers, but also in happier (not necessarily more-paying) existing customers.
here's an idea: compile two interpreters, one with ⎕io frozen to 0 and the other to 1. set the price for ⎕io←1 like 5% higher. it's gonna phase out pretty quickly :)
@KamilaSzewczyk I've not promised anything, only said that we're considering it. One of the things that need sorting first is how we can continue to feed our families.
this way hobbyists have everything they'd possibly want to, dyalog can get free contributions and insight from the community, and companies which already have a heck ton of money can pay
@dzaima Self-hosted BQN has a fair number of optimizations (merge sort! bin sort!) but having a VM with no concept of mutable arrays can make it kind of hard to speed up much.
@cannadayr Oh, yes. IBM and APL2000 are probably making orders of magnitude more money on their APL implementations than we are ― all basically without adding any features for decades. MicroAPL was so successful with their side business, that the otherwise very solid APLX became an unnecessary distraction.
@Adám Well, think about it this way: Would you really want to do business with a company that did not feel that the most important thing was to treat it's existing customers well?
The most important thing for current AND future customers of Dyalog is that Dyalog remains financially sound and is staffed by a competent team, able to maintain steady progress.
The current management of Dyalog was put in place 15 years ago in a partly customer-financed management buy-in, specifically designed to avoid the risk of acquisition by a single client.
@Adám We are definitely not trying to follow the modern get-rich-quick, boom-or-bust or acquisition model.
Yup, and I stand by Dyalog Ltd's management. I try to explain the decisions and their reasons, and how it can make sense even if it can lead to the eventual demise of Dyalog APL.
@MortenKromberg Exactly my point. If Dyalog Ltd wanted to maximise profit, they'd stop doing APL (like MicroAPL with APLX) and task all the amazing brains with more profitable jobs.
I, for one, appreciate stability, even if it isn't the "hip" thing to do.
There is little risk of the demise of Dyalog APL any time soon. Our customers run businesses that are based on Dyalog APL with a combined annual turnover in excess of a billion euros/dollars.
If by some misfortune or act of stupidity we manage to screw it up, I will do what I can to open source it before we put out the lights :-).
Realistically speaking, long term, Dyalog APL will probably cease to be attractive to newcomers when eventually replaced by a superior APL language, whether developed by Dyalog Ltd or not. Not a reason to forgo learning Dyalog APL now, though, as most of the acquired skills will be applicable forever, and I know of no viable alternative today.
@ngn Now sure what language you have in mind, but despite you making no secret of how superior you find (various versions of) K, and FOSS J being out there, and NumPy/Julia/MatLab/Mathematica/etc. existing, quite a steady stream of newcomers still seem to find it attractive enough to invest energy into learning. Source: this room's activity.
Oh, and those that do get into APL seem to prefer Dyalog's version, whether for direct usage to as inspiration for their own implementation.
@ngn No. I'm not here to manipulate, and I challenge you to find any examples of me being deceptive. Quite on the contrary, I think you'd find (if you approached the issue honestly) that I'm quite frank about things.
@ngn They'd probably leave it up to me as room owner to kick-mute you if I see so fit. However, since it is me that you are baselessly attacking, I feel it'd be unfair to silence you with such drastic measures. I'd much prefer if you'd agree to be nice. Of course, I still want you to express your opinions about on-topic matters, but do refrain from personal attacks unless based on hard evidence.
@Adám example: if you say something like "tradfns are ok to use" and don't explain the problem with dynamic scoping, i will call you out on that. but that's because i care about good programming, not because i want to attack you!
@ngn any time you say that writing short code is good, do you mention the caviat that it might be very hard to have that work in teams of people, and it makes for steeper code learning?
Is there was some way to mark dfns and say - "This function has such and such properties, you can do these sorts of optimizations on it, here's the inverse, etc."
@ngn it's wrong to make a point valid by making an unrelated differentiation. example: "APL is better than k because APL uses the character ' for string quoting instead of "."
@user no, that would be cool, and if I ever get round to making that APL dialect I've had in my head for a while you can do things like that like in haskell
@rak1507 Chicken and egg problem. As long as the glyphs are not there, people won't use the features, but we won't add the glyphs until we are sure about the design, i.e. after people have used the models.
@Adám fair enough. here it is again: i don't care about who you are, i'm not too interested in your persona, i'm not at all interested in attacking you personally. but if you say something stupid, i will contradict :)
@user We experimented with parallelising individual array operations, but the results were disappointing. There simply wasn't enough data parallelism in application code to make a big difference. Also, in a multi-core Intel machine, a single core reading and writing arguments and results of simple operations like + × / will quickly swamp the memory system and you won't actually get much speed-up by running them in parallel.
@user To get real speed-ups you probably need a compiler which can fuse multiple operations together and run them on something like a GPU, which is what Aaron Hsu is working on with his co-dfns compiler.
@user Meanwhile in the interpreter, futures and isolates provide parallelism at a level of granularity that several clients have used to achieve typically 5x speedups on an 8-processor Intel machine.
