Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Arthur Whitney's 'B' Language

kparc.com

Post reply on HN
Print view View original

31–40 of 109 posts

Re: Arthur Whitney's 'B' Language

#31

Post by 5166cc9c39fa61 »

mamcx wrote: post #28
yiyus wrote: post #23

I studied this code for a long time. I have lots of notes, going through everything almost line by line. I would be embarrassed of making them public because I never finished (at some point, I was just rewriting the x64 reference), but if somebody is interested I do not mind sharing. I would recommend everyone doing C to have a very careful look at this. The code is full of nice tricks and you start appreciating the…

I wish* exist a simplified implementation of this (or APL) in "normal" looking code. Array languages are the most "obscure" of all paradigms I have looked into. Even concatenative ones have some few resources about how work. Also, the community live in a parallel world! So when asked about stuff, redirect me to https://code.jsoftware.com/wiki/Essays/Incunabulum or https://github.com/kevinlawler/kona as if it somehow…

> Array languages are the most "obscure" of all paradigms I have looked into. Even concatenative ones have some few resources about how work.

Have you tried looking at APL books? There are dozens of books on APL you can find. There are journals and conference proceedings from ACM, IBM, Dyalog, and Vector UK. I started to get into APL more seriously last year and lack of resources is definitely not a problem in my experience, lack of time to read them all is. Also, it's more about thinking of algorithms in terms of matrix and array operations. A lot of the techniques and algorithms can be easily adapted from Matlab.

Re: Arthur Whitney's 'B' Language

#35

Post by yiyus »

mamcx wrote: post #28
yiyus wrote: post #23

I studied this code for a long time. I have lots of notes, going through everything almost line by line. I would be embarrassed of making them public because I never finished (at some point, I was just rewriting the x64 reference), but if somebody is interested I do not mind sharing. I would recommend everyone doing C to have a very careful look at this. The code is full of nice tricks and you start appreciating the…

I wish* exist a simplified implementation of this (or APL) in "normal" looking code. Array languages are the most "obscure" of all paradigms I have looked into. Even concatenative ones have some few resources about how work. Also, the community live in a parallel world! So when asked about stuff, redirect me to https://code.jsoftware.com/wiki/Essays/Incunabulum or https://github.com/kevinlawler/kona as if it somehow…

You have ivy, for example: https://github.com/robpike/ivy by Rob Pike and, of course, gofmted. I have had a quick look at a few APL implementations and some of them are very readable code (by normal standards).

However, although I totally get your point (I've been there), I have to say there is much more to learn if you try to understand that parallel world. It can take a while, but I think it is worth it.

Re: Arthur Whitney's 'B' Language

#37

Post by quadcore »

otikik wrote: post #27

Programming is not telling the machine what to do. That's the easy part. What programming is about, and what's hard, is telling the next programmer what the machine does. This makes the easy part a bit easier, and the hard part much harder, than using C. And I already disliked C to begin with, for similar reasons.

Now I think you're right, but there is two strategies which boils down to the following: "you can either make a program that's so complex there is no obvious defect, or you can make a program so simple it's obvious there is no defect."

What it says is that the hard part to make the next programmer understand what the machine does is not reading code, it's code complexity. Training yourself to read terse code is O(1), understanding code is at least O(N) where N is the number of lines of code.

Before you start arguing, try it. Try writing code as simple and succinct as possible. You won't go back to anything else because it works. It does make programming simpler and more productive.

Re: Arthur Whitney's 'B' Language

#38

Post by yiyus »

jonathanhd wrote: post #30
nemo1618 wrote: post #12

Whitney is so fascinating to me. His code is simultaneously awe-inspiring and horrifying. It's like he struck a Faustian bargain to gain programming powers beyond the ken of mere mortals, and is now cursed to write transcendently beautiful code that manifests as unintelligible gibberish to everyone else.

If you think this is horrifying you should see what people-who-aren't-Whitney write when they're copying his style, or adding to his codebase.

I think this is one of the reasons he does not release his code. K is such a small language, with a very limited number of primitives, that were chosen for the task they wanted to solve. Every user would want to change that one he never uses for that one he uses the whole time, so we would have lots of k implementations, each of them with its own mesh of spaghetti code and slightly different behaviors.

Talking for myself, I would love a FOSS version of k, but I am sure as hell I would patch a couple of things, and I am sure I would write much worse code than Whitney's (in his style or in my style).

Re: Arthur Whitney's 'B' Language

#39

Post by ploxiln »

yiyus wrote: post #38
jonathanhd wrote: post #30

Earlier quoted context omitted.

If you think this is horrifying you should see what people-who-aren't-Whitney write when they're copying his style, or adding to his codebase.

I think this is one of the reasons he does not release his code. K is such a small language, with a very limited number of primitives, that were chosen for the task they wanted to solve. Every user would want to change that one he never uses for that one he uses the whole time, so we would have lots of k implementations, each of them with its own mesh of spaghetti code and slightly different behaviors. Talking for my…

I think the closest thing is https://github.com/kevinlawler/kona

Re: Arthur Whitney's 'B' Language

#40

Post by theamk »

quadcore wrote: post #37
otikik wrote: post #27

Programming is not telling the machine what to do. That's the easy part. What programming is about, and what's hard, is telling the next programmer what the machine does. This makes the easy part a bit easier, and the hard part much harder, than using C. And I already disliked C to begin with, for similar reasons.

Now I think you're right, but there is two strategies which boils down to the following: "you can either make a program that's so complex there is no obvious defect, or you can make a program so simple it's obvious there is no defect." What it says is that the hard part to make the next programmer understand what the machine does is not reading code, it's code complexity. Training yourself to read terse code is O(1),…

I did, once, when I was at school. It was great - everything was so fast to type, the program (a somewhat complex game) would fit in on two screens. I almost finished it in a week.

And the I had exams, and did not touch the computer for two weeks. When I came back, I forgot it all. Cx? Dzy? Those names were meaningless.

This was a very importantly lesson - programs must be maintaineable. Unless you want to spend your entire life working on a single piece of software, you want to be able to context switch, and do it quickly.

Post reply on HN