u/c4augustus

This has been my main accusation against Rust not being truly "open" source: a downloaded binary from some central authority is required to actually build it from source. I've been staying away from Rust for this along with other reasons, but I might give your solution a shot--when I next have to use Rust.

OTOH, Zig can be built from its source using only a C compiler.

Thanks for this alternative. IMO, I wouldn't choose to make the entire program (main) recursive rather than making only the code that acquires the count be recursive. The lower part of main that begins outputting text should never be recursed.

Mutability vs Immutability is obviously a major topic of discussion for us. https://www.youtube.com/watch?v=LXntxq0p8Lw

In general, where does the programming community of Scheme stand on this? Given that Lisps are based upon Lambda Calculus and purported to be functional, why wouldn't immutability be a tenant of Scheme or Common Lisp? Clojure decided to push much harder on immutability, and LFE (Lisp Flavoured Erlang) has little choice in that it sits on the BEAM which does not support mutable variables.

do: hearing this again I might change the default to replace the do with recursion.

rec: as I mentioned in the video, I did a variation with function (get-count ...) that is then called recursively, obviating the need for (rec ...) which does seem fringe and hence in a SRFI. The motive for using (rec ...) was to avoid having any named function for recursion, but it sounds like that isn't considered idiomatic, so perhaps the use of rec should be a variation instead.

cond better than if: why is this more idiomatic, in your opinion? Earlier in the video we discuss the awkwardness of reading if versus case in Erlang, so I would agree with you there, but Scheme's if reads okay to my eyes.

I did do a BBHW in Racket along with the old Scheme variation, that was show quickly at the end of the previous video. But it still hasn't been refactored to eliminate mutation and global variables. https://github.com/proglangbase/bbhw/blob/main/code/racket/bbhw.rkt

Interesting. I hadn't considered making a single source file that could be run under multiple implementations. For now, the BBHW repo has separate language implementation subdirectories under each language, along with a ./run shell script that tries to build its implementation if it's not found in the path. Making a single file to support multiple implementations makes it far more complex, but I appreciate having that example so we can see it. Thanks.

Assuming "simpler" == less features, comparing that with something that merely has more features would be meaningless at best and misleading at worst. Productivity is determined by precisely which features a language provides regardless of the size of its set of features along with the fact that most programming utilizes only a subset of available features, combined with their suitability for the use-cases in question. It would be more useful to compare features in different languages as they correspond to specific capabilities. For example, how can we iteratively apply an operation over a collection of items in language A versus B? And how is it typically done, i.e. idiomatically?

I've shifted from basing my programming language on Scheme into something more like BQN so that it has support for array programming. I'm still deciding whether to stick to ASCII symbols, as does J, or go full Unicode, as do APL, BQN, and Uiua.

This seems like a choice between making your own opinionated programming language or a meta-programming language in which others will be motivated to design their own DSL or general language within it. The first choice will represent your point-of-view on programming whereas the second allows others to express their points-of-view. Which do you prefer? For my own language experiment I am selfishly choosing the first option so that I end up with something that I want to program in instead of factoring in what anyone else would like to have.

Oh Swift; I'm forced to program in that quite a lot and I have a few peccadillos. There is a tendency for everything coming out of Apple to be presented as if they invented it. I suspect that branding mentality oozed its way into the creation of Swift.

Thanks for kind words and clarification regarding Racket's support for the Rs. We will be doing an entire episode dedicated to Racket due to its unique capability for language oriented programming.

I agree about using do; it doesn't feel right. I threw these implementations together quickly based upon what I had already done in the previous languages. I have already written a variation in Gambit Scheme to rid myself of those dread set! mutations, although I aggressively subdivided it into many separate procedures to do that. I will be making another variation to reduce so much of that granularity.

Finally, watching back I noticed how often I used the phrase "function" when I really should have been using the term "procedure"--which, IMO, is the more accurate term as correctly expressed in Scheme documentation (i.e. SICP). This is particularly hypocritical of me since I have recently made a crusade of saying "function" for what others only call a "pure function", leaving anything impure (i.e. side-effectful) to be called a "procedure". It seems hard to break that habit.

Good point. We will definitely address this.

Apple, as it typically does, markets Swift as if they invented its language features rather than copied them from other languages and then invented new names for them.

Aside from that, when big tech empires create programming languages they tend to control their fate even when released as open source. Google: Go and Dart, Facebook: React and Reason ML, Jetbrains: Kotlin, Microsoft: C#, F#, and Rust--yes Mozilla (hardly an empire) created it but now that MS is invested in it the biggest gorilla will be in charge.

As to differences between Swift and Rust, Swift is still very OOP, regardless of its support for FP, while Rust is procedural, regardless of its support for FP. This alone yields dramatically different thinking behind the code typically written.

Welcome to programming in a more functional way. Jetpack Compose isnt all FP, but it's a few steps in a better direction.

Have you tried it? I'm planning to embed CBQN into something else I'm doing (2-dimensional syntax parsing), especially since they changed to license so that it can run on iOS. Also, one of my next steps for the new language is make a Racket #lang for it.

I justed started a language intending to do exactly this. We must be twins, but I am probably the evil one.

To my eyes Lisps have the advantage of being immediately recognized as program code and not mistaken for psuedo-code or other language families. Languages made from the typical "if ... else ..." syntax are all over the map as are those with curly braces.

Single-glyph keyword languages like APL, BQN, and Uiua also have the advantage of appearing as code or math formulas instead of prose. They also are free from being biased to English words.

I am designing a new programming language that combines these syntaxes: parenthetical S-expressions with all reserved keywords/special forms only as symbols (hopefully the most common ones across international keyboards) so that all words can be defined by the user/library in whatever language is desired.

Same here. The Hi/Low threads to 0 settings doesn't fix it either. Too bad. I only play this game because of VR

I am using KMM to create an Android implementation of an existing iOS app that already has a large user base. So in this case KMM is well suited because I need to keep the iOS ObjC+Swift code intact while adding new features to both platforms with a single Kotlin implementation. This also allows incrementally replacing (and testing) the old ObjC+Swift code with its new equivalent in Kotlin as the Android implementation is built up.

This makes for a very complex programming setup that I deem worthwhile in this case. Be aware, however, that even for a greenfield app where all the code is new, KMM is still a complicated approach.

Agreed. You need to know the old ways as well as the new. This makes for the strongest candidates that I interview.

Welcome to dependency and version hell. Be ready to spend a lot of time wrangling build configurations through trial-and-error whenever the version of anything --Android OS, Android Studio, plugin, language, framework, or library--gets "upgraded" or deprecated.

Whether or not due to a JVM limitation, Kotlin definitely lacks a true sum type. It has to be faked using a sealed class that wraps other classes/data classes for the sum type variants (set elements). The Kotlin enum isn't sufficient because all of its variants must be structurally equivalent--unlike the Swift enum which allows different shapes in its variants.

We can build emacs from source without using CMake. That was a dealbreaker for me with neovim.

Total junk. I have a bunch of gear decades newer than this and I'm trying to figure out who I can get to come take it away just so that I can clear the storage space that I have to pay for to keep it.

But don't feel bad because intermediates, beginners, and people new to windsurfing are frequently getting robbed like this. It's questionable if gear is > 10 years old, worthless if > 20.