There's an entire genre of games (immersive sims) that focus on experiencing the world with little to sometimes no skill required on the part of the player. The genre is diverse and incorporates elements of more gameplay-focused genres. It's also pretty popular.
I think some people want to play, and some want to experience, in different proportions. Tetris is the emanation of pure gameplay, but then you have to remember "Colossal Cave Adventure" is even older than Tetris. So there's a long history of both approaches, and for one of them, these models could be helpful.
Not that it matters. Until the models land in the hands of indie developers for long enough for them to prove their usefulness, no large developer will be willing to take on the risks involved in shipping things that have the slightest possibility of generating "wrong" content. So, the AI in games is still a long way off, I think.
> We obviously have smaller pre-merge tests as well.
This. I feel like trying to segregate tests into "unit" and "integration" tests (among other kinds) did a lot of damage in terms of prevalent testing setups.
Tests are either fast or slow. Fast ones should be run as often as possible, with really fast ones every few keystrokes (or on file save in the IDE/editor), normal fast ones on commit, and slow ones once a day (or however often you can afford, etc.). All these kinds of tests have value, so going without covering both fast and slow cases is risky. However, there's no need for the slow tests to interrupt day-to-day development.
I seem to remember seeing something like `<slowTest>` pragma in GToolkit test suites, so at least a few people seem to have had the same idea. The majority, however, remains fixated on unit/integration categorization and end up with (a select few) unit tests taking "1-2 orders of magnitude" too long, which actually diminishes the value of those tests since now they're run less often.
You're assuming that named lambda is the same thing as a function, which often isn't true. Unless you mean that `=>` should be ambiguous depending on scope (lambda inside a function, a function in global scope)? That would also be a bit problematic, wouldn't it?
> Just curious, why is this? All of the Erlang debugging stuff seems to work.
But you'd see a decompiled Erlang-ish code in the (WX-based, graphical) debugger, no? Genuinely curious, I think it was like that last I checked, but that was in 2019.
(Assuming you're not trolling: you chose to focus on features that can only be judged subjectively, and therefore can only be discussed as preferences. It's ok to have them, but actively displaying them is a bit pointless. Objectively measurable features of both languages put them very close together, with both having slight advantages over the other in different areas, on average making them almost equivalent. Especially compared to anything non-BEAM.)
I'm not trolling, but I'm very serious about language design after going through a long gauntlet. I don't think making mutation easy, and also having the ability to hide code execution, is necessarily a good practice in a system principally designed for safe, robust and efficient concurrency. Don't use a flathead on a phillips screw.
Rebinding is not mutation. This seems pedantic but is an important distinction. None of the semantics of the runtime are changed. The data remains immutable. You probably know this. However, for the benefit of readers who may be less familiar: Erlang does not allow variables to be rebound, so it's somewhat typical for Erlang code like this:
X1 = 8.
X2 = X1 + 1.
X3 = X2 * 302.
You cannot, say, do this:
X1 = 8.
X1 = X1 + 1.
This is because in Erlang (and in Elixir) the `=` is not just assignment, it is also the operator for pattern matching. This has implications that are too broad for this post, but the key point here is that it's attempting to see if the the left side and the right side "can match".
Whereas writing the same thing in Elixir would look like:
x = 8
x = x + 1
x = x * 302
This is because Elixir allows `x` to be rebound, in effect changing what data `x` points to, but not mutating the underlying data itself. Under the hood Elixir rewrites each expression into something resembling the Erlang version.
The practical effect of this is that if you for example insert a process spawn somewhere in between any of the lines that references `x`, that process gets its own totally immutable version of the data that `x` points to at that point in time. This applies in both Erlang and Elixir, as data in both is completely immutable.
It should also be noted that handling state like that is not really idiomatic Erlang. State is updated at a process level, thus traditionally you spawn another process which is trivial to do. On the BEAM that is fast enough for 95% of cases. If you really need mutation on local variables for performance reasons, you should already be writing NIFs anyways.
State variables are what I think corpos call a "code smell". The BEAM/OTP isn't a number cruncher, there are better tools out there if you're doing a lot of that. Erlang is, at it's core, about constraint logic programming. It should be best thought as a tool for granular, scalable, distributable userspace scheduling. If you need something outside of that, NIFs or Ports. Both are quite nice.
This has nothing to do with math or number crunching on the BEAM. This has nothing to do with mutation. This has nothing to do with performance.
This kind of process and function-local static single-assignment code is all over the place in Erlang codebases. It's incredibly common. The other popular method is tail recursion.
I searched for literally 30 seconds and found these:
> It should also be noted that handling state like that is not really idiomatic Erlang.
It's not about the state but about intermediate results. When you have a value that you pass to one function, and then you need to pass the result to another function, you're not dealing with a "state" as OTP defines it, unless the calls are asynchronous. Often, they're not, and that's where variable rebinding comes in.
Worth noting: `|>` macro operator in Elixir serves a similar purpose, as long as you don't need pattern matching between calls. In that case, you don't have to name intermediate results at all, resulting in cleaner code.
> State variables are what I think corpos call a "code smell".
Having to call multiple functions in a sequence is the most natural thing to do, and Erlang code is littered with "X1 = ..., X2 = ...(X1), X3 = ...(X2)" kind of code everywhere.
There are some libraries (based on parse transforms) that introduce a sort of "do" notation to deal with this issue (erlando and its variations come to mind).
I love it. I didn't know. It's going to take a while to make this a pervasive feature of most Erlang codebases, but it seems like a good feature to introduce.
I know there are monad libraries using parse transforms and/or list comprehensions, but I often found their use is frowned upon in the Erlang community. I kind of assumed the GP in this thread would reject them, given their negative opinion on macros.
I was in a similar situation, ended up relying on libs that used parse transforms a lot and then found out most of my usage could have been replaced by the new `maybe` expression.
to the five lines of the equivalent made with macros, function calls, and keyword arguments.
I know all the problems with reader extensions, really. I understand being cautious. But at some point, you gotta wonder: what's the point of the programmable reader when you're unwilling to add programs to it?
That's on quicklisp, not Coalton. Honestly, quicklisp is one of the worst parts of CL nowadays (right after the lack of coroutines[1], which is by far the worst offender.) It should have been replaced a long time ago. ASDF3 provides a lot of flexibility, and quicklisp uses maybe 15% of its capabilities. There are reasons why it's still so bad, but it gets less and less excusable each year :(
[1] Does anybody know how to ping Kartik Singh about the coroutines implementation in SBCL? Apparently, he made an experimental port of the green threads implementation from CMUCL, but I can't find it anywhere online, nor any obvious way to catch anyone involved. Is the mailing list the only way?
Thank you!! I was very interested in `convert-thread-to-coroutine` - I saw it on the ELS presentation, and when I went spelunking in the CMUCL codebase, I found the prototypes for `fork` and `resume`, but (probably because CMUCL is single-threaded?) nothing that would suggest how that `convert...` should look like.
Why is there so little interest in green threads/coroutines in CL community? cl-cont really isn't something to point to when asked about C10K problem... or yield/yield*... or async/await...
There's great interest for it, not little. The challenge is who can do compiler programming, add a production ready implementation as contrib SBCL package, and maintain it?
Hm, my impression is based on the lack of posts or articles with people demanding this to be a feature. I searched, and it just doesn't seem to come up in discussions, and when it does, it's invariably about cl-cont and problems with it.
The first implementation doesn't need to be production-ready. And the maintenance burden (along with polishing the implementation and porting to other architectures) could be shared by a few people and done over time. Having a starting point in the form of CMUCL code (already adapted to SBCL!) is the perfect opportunity for everyone interested to chime in: enough voices in favor could convince someone capable to continue the work. Yet, there are literally just 3 comments under the ESL presentation video, and it's not mentioned anywhere else...
It's mentioned on X and Discord plenty, but you're right about cl-cont.
The first few steps would be building on top of this work and reaching out to the SBCL maintainers via the mailing list to see what it takes to get this merged in.
It needs a lot more good tutorials about its type system. Lacking the background in whatever subfield of math that would help here, I couldn't type my way out of a wet paper bag in it. I'd love a concise, down-to-earth, exposition of the type system "for the working programmer". It's just so different than anything else I know (from Haskell to Prolog) that I had a really hard time understanding Shen's type system.
You're right: Shen's mathematical underpinnings (sequent calculus, dependent type theory) can intimidate programmers without a formal logic background. I bought the "The Book of Shen" (TBOS) revision 1 and revision 3. Revision 4 is available on the website. It's a great book with some CS history, logic, and development of Shen from Qi as well as how everything works in Shen including the type system.
Shen uses a dependently typed Sequent-Calculus based Type System (SCTS). It uses type rules vs. type classes, and type checking is optional, you can turn it on or off. Haskell's type inference makes things a bit simpler, and is a battle-tested static type system with excellent type inference which lends itself better for functional programming and large-scale software engineering (for the moment). Shen's TC is more expressive, but requires more effort.
Aditya Siram has some old but goody YT videos on Shen.
I wanted to buy it - I don't remember exactly, but I think I couldn't find an e-book version, and the paper one was expensive and didn't even ship to my country :( I hope to be wrong on that, though, do you know if there's an ebook available from somewhere?
Other than the online version (4th edition), I don't know of any other place to get it. Yes, the paperback was expensive, but I bought it anyway. It proved to be very informative and more substantive than I had thought. I believe the 5th edition is almost ready for publication.
I'm an idiot. I looked at this page: https://shenlanguage.org/TBoS/tbos.html many times, tried clicking on the table of contents, realized that chapter titles are not links, and went away thinking it's only the ToS for promotional purposes. I only realized that the page numbers are links just now. To my defense, they don't differ in color that much and lack the underline that often marks links. Still, a HUGE facepalm :D Thanks for mentioning this and making me realize my own stupidity :)
Glad you found it. I've done much worse, believe me!
If you have any questions check out the Google Groups (no Groups comments!) for Shen. I am eager to see the 5th edition, and I will probably buy the print version.
Obviously, also available in CL, in Serapeum library[1]. Racket is credited in the docstring (since it's ~> instead of ->). Also, `nest` works very well for unnesting forms[2]
> It has value because a student can only get it by learning and problem-solving.
No. That's how it should be, but the reality looks different: it has value because it shows that someone spent 3+ years doing what they were told to do, enduring all the absurdities they were subjected to in the meantime. Whatever means they used to cheat don't matter, since they still worked on what someone told them to and produced results satisfying the expectations.
There are, perhaps, institutions where learning and problem-solving are seen as the most important while "following orders" and "staying in line" are deemphasized. For the students of all the others, putting up with an utterly absurd environment is often one of the biggest barriers to learning. Yet, it's a requirement without fulfilling which you can forget about graduating. Hence my conclusion: the diploma from most learning institutions certifies you as a good corporate drone - and that's enough of a signal in many situations, so why bother trying to fix it?
This is a very bold statement, you should consider substantiating it at least a little, maybe give just one example on what those absurdities collee students have to endure are, that prove they're good corporate drones?
From what I remember it was 4 years of learning stuff I signed up to learn, occasionally being quizzed on said stuff, and then they gave me a paper that claims I know the stuff.
You might live in another country where the situation is different, or maybe my experiences are outdated (20 years later, they might be). What I remember is unfairness and corruption, feudal-like relationships, tons of wasted time on things I didn't sign up for and things I already knew but couldn't say I know for fear of retaliation. I was still better than people going to private institutions: on top of all that, they were also extorted for money at every turn. ...thinking about it, yeah, I really hope my experience is outdated.
I'm not saying a college CAN'T provide an education, but it IS a little ridiculous you can't just test pass four years of regurgitating textbooks. Ideally for a fraction of the cost.
I think some people want to play, and some want to experience, in different proportions. Tetris is the emanation of pure gameplay, but then you have to remember "Colossal Cave Adventure" is even older than Tetris. So there's a long history of both approaches, and for one of them, these models could be helpful.
Not that it matters. Until the models land in the hands of indie developers for long enough for them to prove their usefulness, no large developer will be willing to take on the risks involved in shipping things that have the slightest possibility of generating "wrong" content. So, the AI in games is still a long way off, I think.
reply