|
eschaton posted:I think you can get CLIM with the commercial implementations Lispworks supports it but doesn't recommend it because your application will look like it's from 1992. It has a newer universal graphics API thingy that's supposed to work on Windows (it's a form!), Mac (it's a Cocoa window!) and Linux (it's a GTK+ window!) but I can't say I've shelled out the $500 for it.
|
# ? Oct 9, 2015 23:02 |
|
|
# ? Jun 5, 2024 08:37 |
|
Luigi Thirty posted:Lispworks supports it but doesn't recommend it because your application will look like it's from 1992.
|
# ? Oct 9, 2015 23:16 |
|
Here is a short useful lie about monads that will help you understand why FP people like them: A monad is analogous to a an Object that stores a value that can be only accessed by callback. The monadic rules define composition methods for them. Chaining them up is creating a callback and passing it as an argument. Haskell's do-notation is just sugar to make writing the chained callbacks a lot easier. The trick is that when when you chain up callbacks, you can write special logic to handle the compositions. You can call the callback on a value and skip it on null. You can call the callback for each value you get. You get to determine the evaluation order, but also the evaluation semantics. In F# this idea has been developed more-so than in haskell, with F# Computation Expressions, so things like LINQ, Generators, and Optional expressions can be defined, composed, and extended. It has a lot more to it than monads and do-notation and the language benefits from it intensely. With monadic style composition of functions: you don't need macros with special evaluation order, with or without hygiene, to define new special forms. You can write it using normal code and type check it like normal code. Take the power of callbacks to build special evaluation orders, use sugar to thread the spaghetti code, and suddenly you have an incredibly powerful program transformation without resorting to eval or macros. But when you ask a Haskell programmer to explain what they are, they won't tell you that, they'll tell you the type signature for the composition functions and ask you to work out the rest.
|
# ? Oct 9, 2015 23:48 |
|
Soricidus posted:isn't looking like something from 1992 all the rage these days? all the flat blocky primary color poo poo that everyone seems to have inexplicably decided doesn't look like rear end I like the good 1992 where everything has an inexplicable marble texture
|
# ? Oct 10, 2015 00:11 |
|
i used a ultra 60 with solaris 8 / CDE as my desktop for a while in the 2000's. i liked the aethetics of Motif and i don't care who knows it
|
# ? Oct 10, 2015 00:20 |
|
eschaton posted:in sdl.c around line 213 there's a block: excellent. now I have USER AIDS. unfortunately the windows key doesn't seem to map to SUPER like it says in the docs so I can't get past the YOUR NETWORK IS BROKEN error no matter how i reconfigure it in gnome's keyboard layout!
|
# ? Oct 10, 2015 01:23 |
|
George: I just got off the phone with Nick, who told me he had passed my previous message about Ken to you. I hope that you understand that I was really just venting at Nick, and I didn't intend that my message be passed on to you, Ken, or his father. There is still, however, a very significant problem we (Q Studios) have in dealing with Ken. Every update Ken makes to his engine turns out to be a major tribulation for us. He regularly makes changes that break our code without any advance warning. He consistently ignores our requests for fixes or suggestions for design strategy. Nick is constantly on me to "Call him. Just get on the phone and talk to him," but to be honest, talking to Ken on the phone is pretty much near the bottom of the list of things I'd like to do with my life. The problem is, he's just so completely unresponsive. I'll ask him a question, and nine out of ten times I'll either get silence or "I don't know" as a response. I know he's highly intelligent, but so are a lot of people I know, and I can TALK to THEM. Okay, so perhaps his personality is a bit different, but he still needs to work WITH us, not AGAINST us. We've had a resource and memory manager in Blood since last year, and it's been working well and is very solid code at this point in time. To get it working back in December though, I had to completely replace parts of the engine, no thanks to Ken. A well designed system would have been built on the ground up from a good memory manager, or at the very least with hooks laid in so it could be developed later. To get our virtual memory system to work with Ken's engine, I had to spend weeks reverse engineering Ken's code, documenting variables, prototyping functions -- all things that Ken himself should have done or provided. Now in June, he hacks in his "group file" system, and says we have to use it. In one sense he's right -- he's hard coded the thing into his engine, and it's broken Blood unless I can figure out which parts of the engine I need to replace. By the time we're done with Blood, we probably won't have any of Ken's engine left... Perhaps you'll want to reconsider the royalties that you are paying him. A few months ago, Ken made a change to the engine that allowed each tile to have its own origin -- a reference point by which it could be positioned. This change was a good one, but there were some problems with the implementation. When the bit was turned on to enable sprites to be centered on their origin, animations bounced, and sprites appeared at the wrong position. It turns out the solution was one of procedure -- by setting the origin at the base for sprites that are supposed to be on the floor, everything appears correctly. Unfortunately, setting the origin for several thousand tiles using Ken's EDITART tool was just a bit too cumbersome for us, so I spent a few days developing a tool that would allow simple tweaking of the tile origins, among other things. This tool is integrated with our new sequence editor, which will be used to create and edit all the actor animations (walking, attack, death, etc.) Everything with this system was going fine until we discovered that Ken has some engine flaws in dealing with sprites that use origin based centering. The clipmove() function doesn't work, and neither does hitscan(). These two functions are pretty much essential to doing anything with the engine. I could rewrite them, of course, but that would be a few days to weeks out of our schedule, depending on how many more bugs and design problems crawl out of the woodwork. We had waited a few months before switching to the new origin based centering, so I was quite surprised to find such fundamental problems with it. We called up Ken and told him about it, and he said he didn't think anyone was using it, but he really didn't know. We asked him to fix it. Tonight I called up Ken because of the group file problems, and because we still don't have a fix for the clipmove() or hitscan() problems. Ken he wasn't going to fix it and we should go back to using the old centering mode. This is totally and completely unacceptable. We've already invested time and effort (need I say money?) into using something, and we're not about to waste more regressing. Ken understands algorithms, and he understands graphics. What he doesn't get is how to design SYSTEMS. Everything he does to the engine is a piecemeal enhancement to something that should have been designed right from the beginning. The memory system is a poignant example of this. It is a hack, like most of his code, and not very robust. From what I've disassembled of the group file code (trying to figure out a way to eliminate or replace it), it too demonstrates plentiful opportunities for crashing the system -- pointers being freed without validation, files being closed without verifying the handle, etc. Our resource and memory manager are quite superior to Ken's (no bragging), so to abandon our body of code would be a step in the wrong direction. When I mentioned to him that our resource manager used an LRU list to handle purging of resources, he said that he didn't understand how they worked and he didn't want to undertake something that complicated. It isn't that complex; it's just outside the realm of Ken's experience. I usually end my phone conversations with Ken with something like the following: "Ken, is there anything I can do, anything I can provide to you, that would help you make these fixes or changes?" The answer is invariably "No." After we hang up, I usually bang my head on the desk for about ten minutes. I've tried to explain to Nick that this is why I don't like to call Ken, but I think he already knows. Tonight I tried to explain to Ken what a library file is. I told him how linkers work, and how they resolve symbol name when producing an executable. I tried to impress on him the benefits of "code granularity" -- breaking a system up into as many small discrete modules as possible so that the linker can efficiently pack only used code into the executable. I informed him about "dead code", and why there was so much of his in Blood. I don't think I made any impression at all. George, I want you to understand one thing. When I ask Ken to make a fix or enhancement, it is most surely something we absolutely need for Blood. I wouldn't force myself to make the phone otherwise. However, everything that I ask for would benefit not only Blood, but EVERY OTHER build project. I've spent enough time as a Project Manager for commercial programming tools that I know what makes a good API, and I know what makes a system extensible. The things I've been asking for are "hooks" so we can implement our own features, not have him do them for us. I sometimes wonder, though, if I'm going against the flow. Perhaps Ken added his cache system in response to other teams request for a memory manager? Maybe the group file code was asked for by the Duke Nukem team? These fears usually turn out to be unfounded, since other teams report similar problems as a result of Ken's "updates." I realize that most of the problems I've been describing with Ken are highly historical in nature, and there's no way to change the past. What can and must be done though is to make Ken more responsive to our needs. He needs to work WITH us, not against us. I don't know why he is so combative, but I can guess -- ego. He probably feels about his code the way a lot of programmers do: it's okay to criticize your own code, but for anyone else to do so is blasphemy. I used to be that way until I realized that a lot of the suggestions people were making to me were actually right.
|
# ? Oct 10, 2015 02:22 |
|
The best monad tutorial is the first one in 92 by Wadler. http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf Unlike many other monad tutorials, Wadler actually first provides and explains a concrete problem that monads help solve before introducing monads.
|
# ? Oct 10, 2015 02:47 |
|
The thing that made monads finally click for me was this video, in which Brian Beckman explains it at a very manageable pace going all the way from "things you already know".
|
# ? Oct 10, 2015 02:56 |
|
Luigi Thirty posted:George: didn't read
|
# ? Oct 10, 2015 03:06 |
|
haskell, mercury, pure, erlang and clojure are the only languages i know that do immutable correctly (no references in immutable data), and i am not so sure about clojure
|
# ? Oct 10, 2015 03:08 |
|
Barnyard Protein posted:i used a ultra 60 with solaris 8 / CDE as my desktop for a while in the 2000's. i liked the aethetics of Motif and i don't care who knows it if you're going to dig through my posting history for computer opinions, please at least source your quotes
|
# ? Oct 10, 2015 03:41 |
|
Bloody posted:didn't read didn't, or couldn't?
|
# ? Oct 10, 2015 03:47 |
|
the talent deficit posted:haskell, mercury, pure, erlang and clojure are the only languages i know that do immutable correctly (no references in immutable data), and i am not so sure about clojure i think rust does a good job too. you can have references in immutable data, but it's all captured in the type system
|
# ? Oct 10, 2015 03:54 |
|
the talent deficit posted:haskell, mercury, pure, erlang and clojure are the only languages i know that do immutable correctly (no references in immutable data), and i am not so sure about clojure well, in Clojure there are atoms and refs, which specifically are mutable through transactions but you at least know what you're getting into when you stick a bunch of atoms in a vector or whatever, it's explicit
|
# ? Oct 10, 2015 04:23 |
|
Dessert Rose posted:well, in Clojure there are atoms and refs, which specifically are mutable through transactions it's weird seeing a bunch of lisp that avoids setf as much as possible and then a bunch of lisp in a different package being all profligate with the setf
|
# ? Oct 10, 2015 07:24 |
|
Luigi Thirty posted:excellent. now I have USER AIDS. unfortunately the windows key doesn't seem to map to SUPER like it says in the docs so I can't get past the YOUR NETWORK IS BROKEN error no matter how i reconfigure it in gnome's keyboard layout! I don't know about the specifics of the keymap but it should just be a matter of looking at sdl.c or even tweaking it edit: tried it on my system and I couldn't press super-a but I didn't need to either, pressing the right mouse button got me the USER AIDS you've been chasing eschaton fucked around with this message at 08:41 on Oct 10, 2015 |
# ? Oct 10, 2015 07:25 |
|
comedyblissoption posted:The best monad tutorial is the first one in 92 by Wadler. holy poo poo this is so approachable and good.
|
# ? Oct 10, 2015 09:01 |
|
fart simpson posted:i think rust does a good job too. you can have references in immutable data, but it's all captured in the type system What? Rust doesn't have immutable data.
|
# ? Oct 10, 2015 09:31 |
|
lisp variable scope confuses me. how do function-local variables work? googling lisp particulars seems to give monad-tier explanations for just about anything. I don't want to pollute the global namespace with strings that i'm assembling in a function which setq does.
|
# ? Oct 10, 2015 19:51 |
|
function local variables? you mean a variable that persists its value between calls? if so look at http://www.gigamonkeys.com/book/variables.html the section "Lexical Variables and Closures" explains it for common lisp also this is for scheme, but i'm guessing its the same enough for any other lisp that it is sufficient, it explains how the closure thing works in terms of how the lambda expression captures the binding etc etc https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-21.html#%25_sec_3.2.3 Jerry Bindle fucked around with this message at 20:15 on Oct 10, 2015 |
# ? Oct 10, 2015 20:07 |
|
Luigi Thirty posted:lisp variable scope confuses me. how do function-local variables work? googling lisp particulars seems to give monad-tier explanations for just about anything. I don't want to pollute the global namespace with strings that i'm assembling in a function which setq does. it sounds like you want some sort of "let" http://docs.racket-lang.org/reference/let.html
|
# ? Oct 10, 2015 20:10 |
|
you know what gets my goat? having to make 2 dimensional arrays by hand coz ue4 blueprints only has single dimensional arrays which wouldntbe so bad but it becomes clear without learning it why out of bounds access is an issue
|
# ? Oct 10, 2015 20:44 |
|
echinopsis posted:you know what gets my goat? having to make 2 dimensional arrays by hand coz ue4 blueprints only has single dimensional arrays it's a 3d engine. shouldn't you be using using spirtes and polygons and stuff for multidimensional structures?
|
# ? Oct 10, 2015 21:01 |
|
Barnyard Protein posted:if so look at http://www.gigamonkeys.com/book/variables.html the section "Lexical Variables and Closures" explains it for common lisp this is the best book if you actually want to learn to do anything useful in common lisp.
|
# ? Oct 10, 2015 21:07 |
|
MALE SHOEGAZE posted:it's a 3d engine. shouldn't you be using using spirtes and polygons and stuff for multidimensional structures? I'm talking about behind scenes poo poo. data structures for keeping track of a 2d grid based map for example
|
# ? Oct 10, 2015 21:09 |
|
at one stage rod rocket was played on procedurally generated levels and I had to make a 2d data structure to construct the levels. I tried to create a quad tree in it too but I couldn't get it to work. honestly I'm amazed how far I did get
|
# ? Oct 10, 2015 21:11 |
sarehu posted:What? Rust doesn't have immutable data. I'm not sure I see what you're getting at here. Rust has immutable data, and data is even immutable by default. Rust also has mutable data, but so does pretty much every language (including Haskell and company).
|
|
# ? Oct 10, 2015 21:14 |
|
eschaton posted:it's weird seeing a bunch of lisp that avoids setf as much as possible and then a bunch of lisp in a different package being all profligate with the setf yeah every single emacs lisp example uses setq everywhere and it's like, you fuckers, we're writing lisp here, not porting python or w/e
|
# ? Oct 10, 2015 22:06 |
|
emacs lisp is bad, or at least thats what i've read from random people on the internet. it seems needs-suiting-ly good for copy/pasting other peoples configs into ~/.emacs and setting up org-mode projects
|
# ? Oct 11, 2015 00:14 |
|
VikingofRock posted:I'm not sure I see what you're getting at here. Rust has immutable data, and data is even immutable by default. Rust also has mutable data, but so does pretty much every language (including Haskell and company). In Rust you can have mutable data in your immutable data.
|
# ? Oct 11, 2015 00:29 |
sarehu posted:In Rust you can have mutable data in your immutable data. You're talking about things like RefCell, right? I think that's what fart simpson was talking about when he said it was reflected in the type system. Like if you have an immutable Vec with mutable members, it's a Vec<RefCell<T>>. edit: Wait I think I see what you're getting at. Are you saying that you can have an object which contains a RefCell, and can thus be mutated even when immutable, and that you are free to not make this obvious in the type of the object? If so I'd buy that argument, although I wouldn't go so far as to say that just because you can engineer your way around immutability that Rust doesn't have immutable types. VikingofRock fucked around with this message at 03:27 on Oct 11, 2015 |
|
# ? Oct 11, 2015 03:24 |
|
so without researching and testing myself i'm curious, is a final variable/object in java or const-equivalent in C++ immutable on the inside? edit: loling at myself for searching "wikipedia languages with immutable data" like it would return a loving list of them pepito sanchez fucked around with this message at 03:46 on Oct 11, 2015 |
# ? Oct 11, 2015 03:44 |
|
sarehu posted:What? Rust doesn't have immutable data. am i using a word incorrectly or something? i think vikingofrock understands what i meant to say
|
# ? Oct 11, 2015 04:11 |
|
Rust has immutable data in the way C# or Java have immutable data (in that you could define a type with no methods that let you mutate the data, if it pleased you). It's not like the way C++ has immutable data, because with C++, const is supposed to mean const, but with Rust you have shared vs. exclusive borrowing where the exclusive borrowing is named "mut."
|
# ? Oct 11, 2015 04:51 |
|
Barnyard Protein posted:i used a ultra 60 with solaris 8 / CDE as my desktop for a while in the 2000's. i liked the aethetics of Motif and i don't care who knows it
|
# ? Oct 11, 2015 04:59 |
|
sarehu posted:Rust has immutable data in the way C# or Java have immutable data (in that you could define a type with no methods that let you mutate the data, if it pleased you). It's not like the way C++ has immutable data, because with C++, const is supposed to mean const, but with Rust you have shared vs. exclusive borrowing where the exclusive borrowing is named "mut." I don't think I understand what you're trying to say, because this program: code:
code:
|
# ? Oct 11, 2015 05:08 |
|
That's because x is an integral type. But with your own type Foo, you can writecode:
The use of let also acts like the way "final" does on local variable declarations in Java, so you can't just brazenly assign to it, but the mutability of the object itself is a question of that type's API decision.
|
# ? Oct 11, 2015 05:55 |
|
I'm not sure why you'd claim C++ somehow has better immutability, given that it's just as easy to cast away the const-ness inside the implementation somewhere without mentioning that fact in the API.
|
# ? Oct 11, 2015 06:20 |
|
|
# ? Jun 5, 2024 08:37 |
|
Luigi Thirty posted:George:
|
# ? Oct 11, 2015 07:51 |