Some older PS1 games didn't work with the Dual Shock in analogue mode. You needed to press the button to disable the analogue sticks to play those games.
Lambdas are now a requirement for any modern programming language. Monadic promises are how asynchronous programming is done. Rust is basically OCaml except with typeclasses and without a GC.
Inch by inch, ideas from FP bubble up into mainstream programming.
I predict that algebraic effects (a la Koka) are next, but it'll be a while before the industry is ready for it.
To play the devil's advocate: From an OOP perspective, lambdas are just syntactic sugar for a special form of objects. Regarding monads, we had smart pointers and the like in C++ already in the 1990s. Both concepts are orthogonal to mutability.
I'm convinced that imperative programming will endure alongside functional code, because being stateful is how the real world works, and most programs have to repeatedly interact with the real world over the course of their execution.
Sure. I don't mean to say that imperative programming is going anywhere.
If you're looking for programming languages with no support for imperative programming, Excel is pretty much it. Even Haskell has robust support for sequencing actions. If it didn't, I don't think we'd be talking about it at all.
What I predict is that ideas from FP will continue to bubble up into the mainstream. Like prior inventions, they won't be presented as a thing that asks you to rework all of your algorithmic code. They will instead be polished and presented in a way that makes them work more as extensions to what you can already do.
If you squint a little bit, Haskell's do-notation is already available in mainstream languages in the form of async/await syntax. async/await is not quite as general as the original Haskell solution, but it also doesn't ask you to completely rethink the way you design algorithms.
Over the last 3 or 4 decades, our procedural and OO languages have slowly been absorbing the best ideas from "FP languages." We're getting to the stage where the very idea of a "functional language" is eroding.
>> From an OOP perspective, lambdas are just syntactic sugar for a special form of objects.
Indeed Smalltalk - a pure OOP language - had `Block` objects fifty years ago.
>> I'm convinced that imperative programming will endure alongside functional code, because being stateful is how the real world works, and most programs have to repeatedly interact with the real world over the course of their execution.
That, and also who wants to wrestle with monad transformers to make a stateful computation work when they have to fix a bug in production ASAP?
> Indeed Smalltalk - a pure OOP language - had `Block` objects fifty years ago.
Although in the original Smalltalk-80, blocks were not full closures, so it didn't support all the things you would expect to be able to do with a lambda.
"The major commercial Smalltalk implementations of the 1990’s all corrected these problems and developed various techniques for efficiently implementing blocks."
The duality between closures and objects is well known. It's hard to avoid having some construct like that, but mainstream languages shifting toward the functional perspective on it is definitely still evidence for penetration of functional ideas.
python will be the last man standing with basically no functional goodies
people will keep on trucking with their "pythonic" for loops containg appends to a list that was initialized right before, their disgust for recursion, their absence of lambdas, the lack of monadic return types or containers
Further, these extra components are easy to omit if you don't want to use them.
The REPL that we offer in the distribution doesn't include any of the analysis logic and it's just 1.7mb once compiled (on my M1 Macbook). I'm not sure how much smaller it gets if you omit CodeGen.
Also for the first ten years I used computers I was using all kinds of REPLs on computers that didn't have 1.7MB of RAM. On my first computer, which had one floppy drive and no hard drive, 1.7MB would have been 17 floppy disks, or 26 times the size of its RAM. So I'm kind of unconvinced by this stance that 1.7MB is a small REPL.
I mean, it's smaller than bash? But even your mom is smaller than bash.
Luau already has some notion of nominal types to deal with the fact that the Roblox API is basically a ton of C++ classes that have been mapped over via the FFI. Some of these types are totally structurally identical and yet incompatible.
We'd like to afford the same kind of ideas for native Luau code, but we're not there yet.
Super happy to see this released, and also for all the kids getting started programming on Roblox learning that there is a better way than random tag-checked mush :-)
Good on you all!
There is a transpiler in the source tree, but I expect it needs a polish pass. We haven't put it to use in quite some time.
In particular, I am pretty sure that it won't do the right thing when it encounters the extra syntax we've added to Luau. So far, that's an if-else expression and a continue keyword. Transpiling those accurately will take a bit of work.
I did a little bit of GBA homebrew development back in its heyday. It is a really fun little bit of hardware to hack on.
It's powerful enough that you can write your whole game in C++, but not so powerful that you should rely on the system allocator for anything.
It's in a lovely sweet spot for a particular dialect of zero-overhead C++ that's really fun to write.
As a simple example, I had a little class library of data types that were crafted to exactly map to the hardware registers of the GBA. The whole thing inlined away to nothing.
I've gotten into GBA homebrew again recently. The community is small but getting a bit bigger. gbadev on Discord is a fun place to hang out.
The tooling doesn't seem to have changed all that much from back in the day, which isn't a bad thing: the best way to get music on the GBA is still to compose something in an old-fashioned tracker and using Maxmod to import it. Sprite conversion tools haven't changed that much.
Programming it is just so lovely bare-metal: poking/prodding registers, writing backgrounds and sprites into memory regions.. Really fun stuff.
I understand what you're saying, but something I have noticed over the years is that the amount of code that I can make sense of at any given time is actually proportional to what I can see onscreen at any given moment.
I have had pretty good luck cheating this in a bunch of ways: I use a small font, a big display, and I use a terse programming style.
Once you internalize a bunch of common higher-order functions, you learn how to draw a ton of meaning out of a relatively small number of terms.
Yes, but this strategy is only suitable for a single developer, or a small group of similarly-experienced-with-that-specific-codebase developers. Onboarding somebody into a world full of single-character variable names and such is a headache. Named parameters are for reading code, and if you're not intimately familiar with the code on your screen right this second, they are helpful.
I think what we really need is a sort of "lens" system by which we can modify the syntactic appearance of our code without adjusting the semantics, but do these changes on-the-fly. So say you're doing some debugging or whatever and you're gonna be staring at the same 300 lines of code for a few days — so you switch over to "terse" mode and suddenly the named parameters are gone and the variable names are abbreviated (assume a magic system that picks good terse variable names according to your preference). But then when you're done with that section and ready to venture into the remainder of the codebase (or if you're a new developer who's unused to the team's naming conventions or whatever), you can use "verbose" mode that shows the parameter names and whatnot.
I imagine something like this is not obviously straightforward, but it could be worth investigating!
> Onboarding somebody into a world full of single-character variable names and such is a headache.
The opposite of named arguments isn’t single character variable names. Any organisation with an enforced coding standard would ensure that variables are descriptive irrespective of whether that language uses named arguments or not.
Yes, I agree! I was specifically addressing the parent comment's line about "I use a terse programming style." When it comes to functional programmers, they (more than any other group) will take terseness to the extreme in the form of single-letter variable names in inner functions, match forms, etc.
I didn't mean for my comment to be entirely literal, either. Rather, I just meant to say that terseness can impede readability for those who are not yet familiar with the codebase. (But I have personally been on the receiving end of onboarding into a codebase full of literal single-character names, which I found incredibly frustrating.)
> When it comes to functional programmers, they (more than any other group) will take terseness to the extreme
You should really read about APL and other array languages then. (I don't have a good starting point, but they tend to come up on HN periodically such as [0] [1]).
The right balance here can depend on the specific business you're working in.
Some companies earn the privilege of a super tenured core team of engineers who work on their product for an extended period of time. They will choose different tradeoffs from a team that needs to adapt to higher turnover.
