4 ms·

As I understand it, Dyalog gives away their compiler, until you put it in production. You can do all your problem solving in it without giving them any money, u

by cess11 2y ago

As I understand it, Dyalog gives away their compiler, until you put it in production. You can do all your problem solving in it without giving them any money, unless you also put the compiled result in front of your paying customers. If your solution fits a certain subset you can go full bananas and copy it into April and serve from Common Lisp. The thing is, that APL people are generally very academic. They can absolutely perform engineering tasks very fast and with concise code, but in some hypothetical average software shop, if you start talking about function ranking and Naperian functors your coworkers are going to suspect you might need medical attention. The product manager will quietly pull out their notes about you and start thinking about the cost of replacing you. This is for several reasons, but the most important one is that the bulk of software development is about inventing a technical somewhat formal language that represents how the customer-users talk and think, and you can't really do that in the Iverson languages. It's easy in Java, which for a long time forced you to tell every method exactly which business words can go in and come out of them. The exampleMethod combines CustomerConceptNo127 from org.customer.marketing and CustomerConceptNo211 from org.customer.financial and results in a CustomerConceptNo3 that the CEO wants to look at regularly. Can't really do that as easily in APL. You can name data and functions, sure, but once you introduce long winded names and namespaced structuring to map over a foreign organisation into your Iverson code you lose the tersity and elegance. Even in exceptionally sophisticated type systems in the ML family you'll find that developers struggle to do such direct connections between an invented quasilinguistic ontology and an organisation and its processes, and more regularly opt for mathematical or otherwise academic concepts. It can work in some settings, but you'll need people that can do both the theoretical stuff and keep in mind how it translates to the customer's world, and usually it's good enough to have people that can only do the latter part.

skydhash 2y ago
Java, C# are good for these kind of situation where you want to imitate the business jargon, but in a technical form. But programming languages like CL, clojure, and APL have a more elegant and flexible way to describe the same solution. And in the end easier to adapt. Because in the end, the business jargon is very flexible (business objectives and policies is likely to change next quarter). And in Java, rewriting means changing a lot of line of code (easier with the IDE). The data rarely changes, but you have to put a name on it, and those names are dependent on policies. That's the issue most standard programming languages. In functional and APL, you don't name your data, you just document its shape[0]. Then when your policies are known, you just write them using the functions that can act on each data type (lists, set, hash, primitives, functions,...). Policy changes just means a little bit of reshuffling. [0]: In the parent example, CustomerConceptNo{127,211,3) are the same data, but with various transformations applied and with different methods to use. In functional languages, you will only have a customer data blob (probably coming from some DB). Then a chain of functions that would pipe out CustomerConceptNo{127,211,3) form when they are are actually need (generally in the interface. But they be composed of the same data structures that the original blob have, so all your base functions do not automatically becomes obsolete.
- cess11 2y ago
  If you sell one small piece of a business process, sure, go ahead. Once your customer has tens of gigabytes of data in your system you really don't want to shuffle around all of that all the time. Funny you mention Common 'do what the hell you want lol' Lisp in the same breath as Clojure and APL. If I ran a one or two person shop and didn't expect to have to grow and shrink the team with consultants at short notice I might use CL or Pharo.
buescher 2y ago
You left out that exampleMethod will of course belong to a Conway's law CustomerConceptManager object. I think this is one of the reasons that software as a field has taken off so well in recent decades while more conventional physical-stuff engineering has stagnated (outside of lithography to support... software) - you can map bureaucracy onto software and the bureaucratic mindset of "if I think I should be able to do something, I should just be able to tell people to figure out how" has fewer hard limits in software.
xelxebar 2y ago
> Can't really do that as easily in APL. This doesn't match my experience at all. I present you part of a formal language over an AST, no cover functions in sight: p⍪←i ⋄ t k n pos end(⊣⍪I)←⊂i ⍝ node insertion i←i[⍋p[i←⍸(t[p]=Z)∧p≠⍳≢p]] ⍝ select sibling groups msk←~t[p]∊F G T ⋄ rz←p I@{msk[⍵]}⍣≡⍳≢p ⍝ associate lexical boundaries (n∊-sym⍳,¨'⎕⍞')∧(≠p)<{⍵∨⍵[p]}⍣≡(t∊E B) ⍝ find expressions tainted by user input These are all cribbed from the Co-dfns[0] compiler and related musings. The key insight here is that what would be API functions or DSL words are just APL expressions on carefully designed data. To pull this off, all the design work that would go into creating an API goes into designing said data to make such expressions possible. In fact, when you see the above in real code, they are all variations on the theme, tailored to the specific needs of the immediate sub-problem. As library functions, such needs tend to accrete functions and function parameters into our library methods over time, making them harder to understand and visually noisier in the code. To my eyes, the crux is that our formal language is _discovered_ not handed down from God. As I'm sure you're excruciatingly aware, that discovery process means we benefit from the flexibility to quickly iterate on the _entire architecture_ of our code, otherwise we end up with baked-in obsolete assumptions and the corresponding piles of workarounds. In my experience, the Iversonian languages provide architectural expressability and iterability _par excellence_. [0]:https://github.com/Co-dfns/Co-dfns/tree/master https://github.com/Co-dfns/Co-dfns/tree/master
- cess11 2y ago
  I have never had a customer that would respond well to me saying 'let's build a formal language over an AST'. What customers have you had that did?
  - xelxebar 2y ago
    Does it matter? I'd bet most customers don't ask for "a somewhat formal language" in the first place, but that's what you're calling for. I definitely do have customers that want to find data potentially tainted by user input, and my code example shows that. With the code snippets, I tried to show how expressing customer-facing concepts doesn't require more code than detailed, internal concepts. Notice how the semantics captured by each example get progressively "larger" and closer to the frontend.

by cess11 2y ago

skydhash 2y ago

Java, C# are good for these kind of situation where you want to imitate the business jargon, but in a technical form. But programming languages like CL, clojure, and APL have a more elegant and flexible way to describe the same solution. And in the end easier to adapt. Because in the end, the business jargon is very flexible (business objectives and policies is likely to change next quarter). And in Java, rewriting means changing a lot of line of code (easier with the IDE). The data rarely changes, but you have to put a name on it, and those names are dependent on policies. That's the issue most standard programming languages. In functional and APL, you don't name your data, you just document its shape[0]. Then when your policies are known, you just write them using the functions that can act on each data type (lists, set, hash, primitives, functions,...). Policy changes just means a little bit of reshuffling. [0]: In the parent example, CustomerConceptNo{127,211,3) are the same data, but with various transformations applied and with different methods to use. In functional languages, you will only have a customer data blob (probably coming from some DB). Then a chain of functions that would pipe out CustomerConceptNo{127,211,3) form when they are are actually need (generally in the interface. But they be composed of the same data structures that the original blob have, so all your base functions do not automatically becomes obsolete.

cess11 2y ago
If you sell one small piece of a business process, sure, go ahead. Once your customer has tens of gigabytes of data in your system you really don't want to shuffle around all of that all the time. Funny you mention Common 'do what the hell you want lol' Lisp in the same breath as Clojure and APL. If I ran a one or two person shop and didn't expect to have to grow and shrink the team with consultants at short notice I might use CL or Pharo.

buescher 2y ago

You left out that exampleMethod will of course belong to a Conway's law CustomerConceptManager object. I think this is one of the reasons that software as a field has taken off so well in recent decades while more conventional physical-stuff engineering has stagnated (outside of lithography to support... software) - you can map bureaucracy onto software and the bureaucratic mindset of "if I think I should be able to do something, I should just be able to tell people to figure out how" has fewer hard limits in software.

xelxebar 2y ago

> Can't really do that as easily in APL. This doesn't match my experience at all. I present you part of a formal language over an AST, no cover functions in sight: p⍪←i ⋄ t k n pos end(⊣⍪I)←⊂i ⍝ node insertion i←i[⍋p[i←⍸(t[p]=Z)∧p≠⍳≢p]] ⍝ select sibling groups msk←~t[p]∊F G T ⋄ rz←p I@{msk[⍵]}⍣≡⍳≢p ⍝ associate lexical boundaries (n∊-sym⍳,¨'⎕⍞')∧(≠p)<{⍵∨⍵[p]}⍣≡(t∊E B) ⍝ find expressions tainted by user input These are all cribbed from the Co-dfns[0] compiler and related musings. The key insight here is that what would be API functions or DSL words are just APL expressions on carefully designed data. To pull this off, all the design work that would go into creating an API goes into designing said data to make such expressions possible. In fact, when you see the above in real code, they are all variations on the theme, tailored to the specific needs of the immediate sub-problem. As library functions, such needs tend to accrete functions and function parameters into our library methods over time, making them harder to understand and visually noisier in the code. To my eyes, the crux is that our formal language is _discovered_ not handed down from God. As I'm sure you're excruciatingly aware, that discovery process means we benefit from the flexibility to quickly iterate on the _entire architecture_ of our code, otherwise we end up with baked-in obsolete assumptions and the corresponding piles of workarounds. In my experience, the Iversonian languages provide architectural expressability and iterability _par excellence_. [0]:https://github.com/Co-dfns/Co-dfns/tree/master https://github.com/Co-dfns/Co-dfns/tree/master

cess11 2y ago
I have never had a customer that would respond well to me saying 'let's build a formal language over an AST'. What customers have you had that did?
- xelxebar 2y ago
  Does it matter? I'd bet most customers don't ask for "a somewhat formal language" in the first place, but that's what you're calling for. I definitely do have customers that want to find data potentially tainted by user input, and my code example shows that. With the code snippets, I tried to show how expressing customer-facing concepts doesn't require more code than detailed, internal concepts. Notice how the semantics captured by each example get progressively "larger" and closer to the frontend.