terrible programmers: my god, it's full of chars

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›1446 »

Luigi Thirty: Apr 30, 2006; Emergency confection port.

eschaton posted:

I think you can get CLIM with the commercial implementations

I've been able to make McCLIM work on Linux (but not OS X) under SBCL, its example listener is bare-bones but does actually have some of the Symbolics features (like clicking on any compatible object in the transcript to provide input to the command line)

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

Adbot: ADBOT LOVES YOU

# ? May 27, 2024 15:56

Soricidus: Oct 21, 2010; freedom-hating statist shill

Luigi Thirty posted:

Lispworks supports it but doesn't recommend it because your application will look like it's from 1992.

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

# ? Oct 9, 2015 23:16

tef: May 30, 2004; -> some l-system crap ->

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

Luigi Thirty: Apr 30, 2006; Emergency confection port.

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

Jerry Bindle: May 16, 2003

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

Luigi Thirty: Apr 30, 2006; Emergency confection port.

eschaton posted:

in sdl.c around line 213 there's a block:
code:
if (offset > MAX_BITMAP_OFFSET) {
...
}
which should actually be:
code:
if (offset >= MAX_BITMAP_OFFSET) {
...
}
tweaking that was enough to boot to the full Lisp environment on my Linux box

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

Luigi Thirty: Apr 30, 2006; Emergency confection port.

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

comedyblissoption: Mar 15, 2006

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

Smoke_Max: Sep 7, 2011

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

Bloody: Mar 3, 2013

Luigi Thirty posted:

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.

didn't read

# ? Oct 10, 2015 03:06

the talent deficit: Dec 20, 2003; self-deprecation is a very british trait, and problems can arise when the british attempt to do so with a foreign culture

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

Soricidus: Oct 21, 2010; freedom-hating statist shill

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

echinopsis: Apr 13, 2004; by Fluffdaddy

Bloody posted:

didn't read

didn't, or couldn't?

# ? Oct 10, 2015 03:47

fart simpson: Jul 2, 2005; DEATH TO AMERICA

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

Dessert Rose: May 17, 2004; awoken in control of a lucid deep dream...

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

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

Dessert Rose posted:

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

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

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

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

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

comedyblissoption posted:

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.

holy poo poo this is so approachable and good.

# ? Oct 10, 2015 09:01

sarehu: Apr 20, 2007; (call/cc call/cc)

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

Luigi Thirty: Apr 30, 2006; Emergency confection port.

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

Jerry Bindle: May 16, 2003

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

suffix: Jul 27, 2013; Wheeee!

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

echinopsis: Apr 13, 2004; by Fluffdaddy

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

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

echinopsis posted:

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

it's a 3d engine. shouldn't you be using using spirtes and polygons and stuff for multidimensional structures?

# ? Oct 10, 2015 21:01

jony neuemonic: Nov 13, 2009

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

echinopsis: Apr 13, 2004; by Fluffdaddy

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

echinopsis: Apr 13, 2004; by Fluffdaddy

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

VikingofRock: Aug 24, 2008

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

Dessert Rose: May 17, 2004; awoken in control of a lucid deep dream...

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

Jerry Bindle: May 16, 2003

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

sarehu: Apr 20, 2007; (call/cc call/cc)

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

VikingofRock: Aug 24, 2008

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

pepito sanchez: Apr 3, 2004; I'm not mexican

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

fart simpson: Jul 2, 2005; DEATH TO AMERICA

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

sarehu: Apr 20, 2007; (call/cc call/cc)

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

Notorious b.s.d.: Jan 25, 2003; by Reene

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

Smoke_Max: Sep 7, 2011

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:

fn main() {
    let x = 5;
    
    println!("{}", x);
    
    x = 4;
    
    println!("{}", x);
}

Does not compile?

code:

error: re-assignment of immutable variable `x` [E0384]
error: aborting due to previous error

# ? Oct 11, 2015 05:08

sarehu: Apr 20, 2007; (call/cc call/cc)

That's because x is an integral type. But with your own type Foo, you can write

code:

fn main() {
    let x = Foo::new();
    display(&x);
    do_a_modify(&x);
    display(&x);
}

such that the first call to display will print 1, and the second will print 2.

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

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

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

Adbot: ADBOT LOVES YOU

# ? May 27, 2024 15:56

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

Luigi Thirty posted:

George:

I just got off the phone with Nick, who told me he had passed my previous
message about Ken to you.

It's an interesting read! It looks more and more like Ken Silverman lucked out by creating the Build engine just at the right time, but not because of any discernible coding skills outside the realm of 2.5d rendering algorithms. I guess that's why John Carmack and Tim Sweeney had a bit more staying power.

# ? Oct 11, 2015 07:51

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›1446 »