This article seems to break down into 3 parts - why multiple return values are bad, why go error handling is bad, and opinions about what to do about it.
The part that feels wrong to me is their issue with multiple return values. They argue that multiple return values are a special case in the type system, so they don't compose well. But, as far as I can figure, function arguments are also a special case, in the exact same way. I think if the author wants to argue go should only have one return value, then use tuple destructuring to simulate multiple return values, they should also argue functions should only take one argument, and use tuple destructuring to break it apart within the function.
I don't think having a special case for either the input or output of a function is particularly weird, and I can't think of any language (except haskell?) that limits you to one argument.
I don't know. I don't think they're particularly wrong about multiple return types being ugly, but it also doesn't feel like some great tragedy to me the way it does to the author.
Eg - fundraise to cover the cost of producing the movie and paying the salaries of everyone involved, because physically making a movie costs money. Then give the mp4 away for free because copying a digital file costs nothing. Piracy is only a problem because companies are trying to charge money for copying a file, which is fundamentally free.
I was wondering why the GCC Machine Description language was such an outlier, especially considering I've never heard of it before. I googled it, and it turns on machine description files use the extension ".md".
Epic bought artstation, bandcamp, and, sketchfab. I don't know for sure, but I don't think any of those are very profitable. They're almost like resume hosting websites for game developers. 3d artists show off their work on sketchfab, artists show off on artstation, musicians show off their work on bandcamp.
My impression is that epic bought them for sort of the same reason Microsoft bought linkedin. They don't make tons of money, but they enhance the pipeline of artists and musicians available to the game industry.
Of course I have no idea if that's why they did it, but epic has definitely shown interest in steering the direction of the game industry in the past, and aligning the talent pool with their way of thinking is maybe a good way to do that.
A few months ago, I watched some videos by Brett Victor and decided I wanted to develop a visual programming language. That led me to https://futureofcoding.org/ and its slack channel.
There was some cool stuff happening on the server, and the admin was doing his best to elevate things, but that slack channel was also the last stop for some people before they descended into templeOS levels of madness.
Right around the time I was joining, the admin posted in the meta channel that, with a heavy heart, he had finally banned [the developer of beads, I feel weird calling him out by name]. Apparently he had been too argumentative and stubborn for the server to further tolerate.
It left a weird taste in my mouth about the future of coding slack channel. On one hand, you don't want toxic people in your community. On the other hand, the server was clearly a channel of last resort for a lot of people with a lot of crazy ideas. Kicking out one if its more prominent members to toil in solitude felt kind of gross.
Its interesting to see that, a few months after being banned, the beads project seems to be materializing.
To me, the core of Haskell is that: "Haskell is C with one semi-colon per function."
This forces you to put all your code into method signatures. This, in turn, means Haskell (or C, if you follow the 1 semicolon rule in C) can understand almost everything about your program.
If you actually follow the 1 semicolon rule in C, you'll get very verbose syntax. All of Haskell's syntax is in service of making programming in this style palatable.
I'm definitely thinking of making a graph based text editor.
I think I could work off of code-highlighting files to figure out where to break code out into different nodes.
Then, I would look for matching terms in each node, and make connections. Connections could also be made based on containment (part of a class, or a child function, or a where clause).
One hotkey to follow a connection to it's destination (and select that node). Another to pull it in and make it share the screen with the current node (and select it). Pressing the "pull in" key would push a node off the screen if it were already on screen.
Of course, maybe you would only want to explode some of your code as nodes. You could highlight part of you file and hit "explode" to break it out into nodes for a minute.
On the topic of ways to improve the terminal, I'd like to see output separated from input.
Put the prompt 1/4 of the way down the screen instead of at the bottom. Above the prompt, we have a backlog of the commands we input. As we press up, it scrolls through the backlog, as normal.
Below the prompt, we see the output of the command.
I'd also like to see tab completion (and maybe some form of hinting) on programs, not just file paths.
They're both predictive typing, so they both fall on their face when it comes to two things. Proper nouns and slang.
Whenever I try to write one of those two thing (often, think email addresses, friends names , "yo", etc) I have to fall back on regular input.
With swiftkey, this means just going back to pecking. With minuum, it means going into a menu and switching to minuum's full sized view or long pressing each region to get a zoomed in view of the keys around there to pick out the one I want.
The compactness of minuum is great, though. And when I'm entering non-proper nouns it's as fast as any keyboard (given a few days to adjust).
I paticuraly like the "swipe left for space" function.
It makes me want to try even more radical keyboards. Maybe something chord based.
The part that feels wrong to me is their issue with multiple return values. They argue that multiple return values are a special case in the type system, so they don't compose well. But, as far as I can figure, function arguments are also a special case, in the exact same way. I think if the author wants to argue go should only have one return value, then use tuple destructuring to simulate multiple return values, they should also argue functions should only take one argument, and use tuple destructuring to break it apart within the function.
I don't think having a special case for either the input or output of a function is particularly weird, and I can't think of any language (except haskell?) that limits you to one argument.
I don't know. I don't think they're particularly wrong about multiple return types being ugly, but it also doesn't feel like some great tragedy to me the way it does to the author.