p-lang thread: (now (have you (problems two)))

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »

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

Smoke_Max posted:

I'm not sure about structural typing, but row polymorphism can definitely be done in a type-safe way. An example of a language that does it is Purescript, where, as an added bonus, it can also be inferred.

you absolutely can, but no one on the pro static types side is talking about purescript's type system

# ? Feb 26, 2017 22:53

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 09:43

Bloody: Mar 3, 2013

tef posted:

i mean i can go back to yelling about deferred type errors, or threesomes with blame, or row polymorphism, or higher kinded types

like, at least if you were arguing for total functional programming, you'd just be a little bit more consistent in the level of decidability of your types and your programs

i could write some long effort post like ttd about how things like runtime inspection of types is pretty neat, or how type systems need to handle versioning of types (hello protobufs, gob, etc, or i could hark on about how robust behvaiour comes from good error handling not bug elimination)

sure if i'm writing something with complex types, like a compiler, tbh, static typing is a useful dicipline,

and yet when you talk to static typing advocates they present it as a complete black and white problem "you do it this way, or you're wrong", or if you will you do it this way or you're showing such disrespectful unwillingness"

you fucks haven't even written a program in constraints and you're telling me to use this pissy little backwards rear end homebrew ad-hoc theorem prover to demonstrate some subset of correctness and you're the ones getting mad at me for not verifying my program in crayon

tef posted:

i mean i can go back to yelling about deferred type errors, or threesomes with blame, or row polymorphism, or higher kinded types

like, at least if you were arguing for total functional programming, you'd just be a little bit more consistent in the level of decidability of your types and your programs

i could write some long effort post like ttd about how things like runtime inspection of types is pretty neat, or how type systems need to handle versioning of types (hello protobufs, gob, etc, or i could hark on about how robust behvaiour comes from good error handling not bug elimination)

sure if i'm writing something with complex types, like a compiler, tbh, static typing is a useful dicipline,

and yet when you talk to static typing advocates they present it as a complete black and white problem "you do it this way, or you're wrong", or if you will you do it this way or you're showing such disrespectful unwillingness"

you fucks haven't even written a program in constraints and you're telling me to use this pissy little backwards rear end homebrew ad-hoc theorem prover to demonstrate some subset of correctness and you're the ones getting mad at me for not verifying my program in crayon

lol this post is so bad

# ? Feb 26, 2017 22:53

jony neuemonic: Nov 13, 2009

tef posted:

you fucks haven't even written a program in constraints and you're telling me to use this pissy little backwards rear end homebrew ad-hoc theorem prover to demonstrate some subset of correctness and you're the ones getting mad at me for not verifying my program in crayon

tef posted:

i'm not hostile, i'm not hostile, i yell into the green and black void

you uh, doing okay over there tef?

# ? Feb 26, 2017 22:53

jony neuemonic: Nov 13, 2009

tbh it's probably just the honeymoon phase i'm still in with elixir, but i'm starting to think it's not static languages i like so much as compiled ones. being able to catch problems before runtime is great, static typing is just one way to accomplish that.

# ? Feb 26, 2017 22:57

Doom Mathematic: Sep 2, 2008

abraham linksys posted:

there's other stuff i want from my tools that typing doesn't check. my biggest pain point as a web developer is that i wish i had checks that i'm correctly consuming or producing the resources for a REST API, and I want these checks to exist at runtime, too. you need to make a fuckload of assumptions to make this work well, though, so idk if it's a reasonable request. it's a nice dream though.

Say, have you heard of SOAP?

# ? Feb 26, 2017 23:06

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

tef posted:

i'm not hostile, i'm not hostile, i yell into the green and black void

green?!

# ? Feb 26, 2017 23:07

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Honestly I feel like immutability is more important than static typing.

fight me

# ? Feb 26, 2017 23:29

Doom Mathematic: Sep 2, 2008

You can't have immutability without static typing, though, surely?

# ? Feb 26, 2017 23:41

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Doom Mathematic posted:

You can't have immutability without static typing, though, surely?

Sure you can. All immutability guarantees is that you can't mutate a piece of data, its' shape could change, be updated, whatever, but that's still immutable.

# ? Feb 26, 2017 23:46

Hollow Talk: Feb 2, 2014

Doom Mathematic posted:

You can't have immutability without static typing, though, surely?

Racket has a bunch of immutable data structures that have nothing to do with Typed Racket or with using contracts. Structs are immutable by default, as are pairs (i.e. cons).

# ? Feb 26, 2017 23:46

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

Doom Mathematic posted:

You can't have immutability without static typing, though, surely?

erlang and elixir say hi

# ? Feb 26, 2017 23:50

The Laplace Demon: Jul 23, 2009; "Oh dear! Oh dear! Heisenberg is a douche!"

Destroyenator posted:

the other thing a good type system can give you is a more explicit modelling of your problem space
i stole this from some blog post, but you can see that in a couple of dozen lines it's possible to lay out what data you're going to be working with and what the relationships you care about are
code:
type Suit = Spades | Hearts | Clubs | Diamonds

type Rank = Two | Three | Four  | Five |  
            Six | Seven | Eight | Nine | 
            Ten | Jack  | Queen | King | Ace

type Card = Rank * Suit  
type Deck = Card list

type Player = { Name : string; Hand : Card list }

type Game = { Deck : Card list  
              Players : Player list 
              CurrentPlayer : Player
              DiscardPile : Card list }

Like, I see where you're coming from, but...

code:

(def suits [:diamonds :clubs :hearts :spades])

(def ranks [2 3 4 5 6 7 8 9 10 :jack :queen :king :ace])

(def full-deck (for [rank ranks suit suits] [rank suit]))

(defn initial-state [player-names]
  {:deck (shuffle full-deck)
   :players (mapv #(assoc {:hand []} :name %) player-names)
   :current-player 0
   :discard-pile []})

You have to repeat yourself ad infinitum to actually do anything with those types. I'd rather keep my code as declarative as possible and build it up from playing with the data in a repl.

Maluco Marinero posted:

Honestly I feel like immutability is more important than static typing.

# ? Feb 26, 2017 23:53

jony neuemonic: Nov 13, 2009

Maluco Marinero posted:

Honestly I feel like immutability is more important than static typing.

fight me

yeah, knowing nothing is going to get changed behind my back because i passed it to a mutating function is huge.

# ? Feb 26, 2017 23:54

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

abraham linksys posted:

i just treat static typing as a really smart linter. works out okay. typescript is basically just eslint except you add a few special bits to your code that get stripped away. also as an added bonus, my text editor can do smarter things like tell me how to use a method in a third party api.

there's other stuff i want from my tools that typing doesn't check. my biggest pain point as a web developer is that i wish i had checks that i'm correctly consuming or producing the resources for a REST API, and I want these checks to exist at runtime, too. you need to make a fuckload of assumptions to make this work well, though, so idk if it's a reasonable request. it's a nice dream though.

i've never worked anywhere that was very good at runtime assertions, tbh. i like react's propTypes thing, but like, i don't know how to apply that concept in the general. i'm terrified of all of our ruby code at work. like, absolutely scared out of my mind when i work on it. because it's rails and i have no idea what assumptions, if any, i can make about any of the code paths. that's not the kinda problem static typing is really gonna solve, i don't think. but i think static languages tend to have a more obvious design, for purposes of type checking, and that helps?

i treat everything written in ruby as a potential bomb that could destroy everything at any time

double so for dsls like chef

# ? Feb 27, 2017 00:10

Sinestro: Oct 31, 2010; The perfect day needs the perfect set of wheels.

i got started on a Haskell database migration thing, but i kinda just got bored and stopped working on it before it was done, just like every thing else that i start. if anyone wants to take a look at it, it's here. :effort:

code:

[1 of 1] Compiling Database.Migratory.Schema ( /Users/awilliams/Development/migratory/src/Database/Migratory/Schema.hs, interpret
ed )                                                                                                                             
Ok, modules loaded: Database.Migratory.Schema.                                                                                   
Loaded GHCi configuration from /private/var/folders/bq/g8g7qd9x3dv6fqz1nmvvff1m0000gn/T/ghci72616/ghci-script                    
ghci>let tbl = Table ColumnSet :: Table "organization" '[]                                                                          
ghci>let addId = addColumn (Column :: Column "id" SerialCol '[PrimaryKey])                                                          
ghci>let addName = addColumn (Column :: Column "name" TextCol '[])                                                                  
ghci>let alterId = alterColumn (Column :: Column "id" IntCol '[PrimaryKey])                                                         
ghci>let removeId = removeColumn (Column :: Column "id" IntCol '[PrimaryKey])                                                       
ghci>tbl' <- snd <$> runIxStateT addId tbl                                                                                          
ghci>:t tbl'                                                                                                                        
tbl'                                                                                                                             
  :: Table "organization" '[Column "id" 'SerialCol '['PrimaryKey]]                                                               
ghci>tbl'' <- snd <$> runIxStateT addName tbl'                                                                                      
ghci>:t tbl''                                                                                                                       
tbl''                                                                                                                            
  :: Table                                                                                                                       
       "organization"                                                                                                            
       '[Column "name" 'TextCol '[],                                                                                             
         Column "id" 'SerialCol '['PrimaryKey]]                                                                                  
ghci>tbl''' <- snd <$> runIxStateT alterId tbl''                                                                                    
ghci>:t tbl'''                                                                                                                      
tbl'''                                                                                                                           
  :: Table                                                                                                                       
       "organization"                                                                                                            
       '[Column "name" 'TextCol '[], Column "id" 'IntCol '['PrimaryKey]]                                                         
ghci>tbl'''' <- snd <$> runIxStateT removeId tbl''                                                                                  
                                                                                                                                 
<interactive>:12:32: error:                                                                                                      
    � No column Column "id" 'IntCol '['PrimaryKey] exists in the table!                                                          
    � In the first argument of �runIxStateT�, namely �removeId�                                                                  
      In the second argument of �(<$>)�, namely                                                                                  
        �runIxStateT removeId tbl''�                                                                                             
      In the first argument of �GHC.GHCi.ghciStepIO ::                                                                           
                                  forall a. IO a -> IO a�, namely                                                                
        �snd <$> runIxStateT removeId tbl''�                                                                                     
ghci>tbl'''' <- snd <$> runIxStateT removeId tbl'''                                                                                 
ghci>:t tbl''''                                                                                                                     
tbl'''' :: Table "organization" '[Column "name" 'TextCol '[]]

# ? Feb 27, 2017 00:22

Doom Mathematic: Sep 2, 2008

Maluco Marinero posted:

Sure you can. All immutability guarantees is that you can't mutate a piece of data, its' shape could change, be updated, whatever, but that's still immutable.

I don't see how changing the shape of a piece of data or updating it doesn't count as mutating it. Could you give an example?

# ? Feb 27, 2017 00:27

redleader: Aug 18, 2005; Engage according to operational parameters

ok so what are the actual advantages of dynamic typing? what would make me want to go from my obviously dumb and lovely static typing to a more dynamic type system?

# ? Feb 27, 2017 00:29

Hollow Talk: Feb 2, 2014

redleader posted:

ok so what are the actual advantages of dynamic typing? what would make me want to go from my obviously dumb and lovely static typing to a more dynamic type system?

Macros

edit: vvv I know they are not mutually exclusive per se, but you are going to have a hard time finding them fully featured just side-by-side. Since that's a Racket-ish system, note that Typed Racket doesn't deal too well with Racket macros at the moment, as one example.

Hollow Talk fucked around with this message at 00:42 on Feb 27, 2017

# ? Feb 27, 2017 00:36

Asymmetrikon: Oct 30, 2009; I believe you're a big dork!

https://github.com/lexi-lambda/hackett begs to differ

# ? Feb 27, 2017 00:38

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Doom Mathematic posted:

I don't see how changing the shape of a piece of data or updating it doesn't count as mutating it. Could you give an example?

Mutable.

code:

thing = {some: "thing"};
thing.some = "blue";
thing.some == "thing" // false

Immutable.

code:

thing = {some: "thing"};
thing2 = thing.set('some', "blue");

thing.some == "thing" // true

Obviously langs can have different syntaxes, but the point is mutations don't change the object in place, they return copies with the change in place, and usually use structural sharing to improve efficiency (only parts of a complex object tree will actually need to change to accommodate the operation)

# ? Feb 27, 2017 00:51

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

jony neuemonic posted:

you uh, doing okay over there tef?

not really but i think i've been exposed to far more frothing fp zealots than other people

# ? Feb 27, 2017 01:31

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

i guess i was trying to say that there's a bunch of cool static analysis and research but my experience in using most type systems is often frustration

# ? Feb 27, 2017 01:35

TheresNoThyme: Nov 23, 2012

Doom Mathematic posted:

Say, have you heard of SOAP?

It really is amazing to think how much of programming is people (including myself ofc) migrating to the frameworks whose tradeoffs they haven't personally experienced yet.

I'm sick of this tight coupling time to go non-relational/JSON!
I'm sick of having poo poo contracts time to go SOAP/RMI!

Wait now I've got it, REST with XML payloads! JSON schemas! :barf:

TheresNoThyme fucked around with this message at 01:45 on Feb 27, 2017

# ? Feb 27, 2017 01:36

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

btw blame wadler for the threesomes thing: http://homepages.inf.ed.ac.uk/wadler/papers/threesomes-popl/threesomes-popl.pdf

The threesomes presented in this paper provide a streamlined data structure and algorithm for representing and normalizing coercions. Furthermore, threesomes provide a typed-based explanation of coercion reduction.

# ? Feb 27, 2017 01:39

fritz: Jul 26, 2003

Hollow Talk posted:

Macros

no, seriously

# ? Feb 27, 2017 02:04

Doom Mathematic: Sep 2, 2008

Maluco Marinero posted:

Mutable.
code:
thing = {some: "thing"};
thing.some = "blue";
thing.some == "thing" // false
Immutable.
code:
thing = {some: "thing"};
thing2 = thing.set('some', "blue");

thing.some == "thing" // true
mutations don't change the object in place, they return copies with the change in place

Okay, this is a definition of "mutation" which I wasn't previously aware of. I mean, thing hasn't changed at all (or "mutated", as it were) in your second example. You haven't updated it, you've just created a second, also-immutable object derived from it.

# ? Feb 27, 2017 02:10

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

reminder that the only problem with mutation is reference semantics, but fp ideology has been throwing the baby out with the bathwater for almost thirty years

# ? Feb 27, 2017 02:14

FamDav: Mar 29, 2008

tef posted:

i guess i was trying to say that there's a bunch of cool static analysis and research but my experience in using most type systems is often frustration

im super curious why tho. like, how does every single statically typed lang youve used cause you frustration?

TheresNoThyme posted:

It really is amazing to think how much of programming is people (including myself ofc) migrating to the frameworks whose tradeoffs they haven't personally experienced yet.

I'm sick of this tight coupling time to go non-relational/JSON!
I'm sick of having poo poo contracts time to go SOAP/RMI!

Wait now I've got it, REST with XML payloads! JSON schemas!

the right answer is whatever your company uses to create rpc clients/servers. if your company is internally vending REST apis with "discoverable" specs you should probably leave because they're more beholden to dumb principles than productivity

# ? Feb 27, 2017 02:18

comedyblissoption: Mar 15, 2006

rjmccall posted:

which dynamically typed languages are you thinking of exactly that aren't centered around object-oriented programming, because oop is pretty core to python, ruby, and javascript

they have OOP concepts, but programmers in these languages are much more likely to compose their programs out of functions instead of a bunch of interwoven mutable objects with absurd inheritance trees AFAIK. it's more of a cultural thing.

and yes, I know people have created OOP-like frameworks in javascript with inheritance.

# ? Feb 27, 2017 02:18

comedyblissoption: Mar 15, 2006

rjmccall posted:

reminder that the only problem with mutation is reference semantics, but fp ideology has been throwing the baby out with the bathwater for almost thirty years

I think a rust-like system where you can statically notate mutability and immutability of data, statically prevent concurrent data races, and statically prevent mutable aliasing of data where you don't want to mutably alias that data might have the best of both worlds

it lets you use mutability where it's the best fit for the problem and lets you use immutability where it's the best fit for the problem.

the best benefits for immutability in general for me is locality of reasoning and I think rust handles that in a lot of cases through preventing aliasing and its immutability guarantees.

# ? Feb 27, 2017 02:20

comedyblissoption: Mar 15, 2006

jony neuemonic posted:

tbh it's probably just the honeymoon phase i'm still in with elixir, but i'm starting to think it's not static languages i like so much as compiled ones. being able to catch problems before runtime is great, static typing is just one way to accomplish that.

by definition, catching a problem at compilation and before running the program is static typing. "type" is a broad term which just means proving some property of your program.

of course, you can have some hybrid approach of static and dynamic typing. I think it's kind of a sliding scale between how much your language embraces static and dynamic typing.

# ? Feb 27, 2017 02:24

comedyblissoption: Mar 15, 2006

Hollow Talk posted:

Macros

edit: vvv I know they are not mutually exclusive per se, but you are going to have a hard time finding them fully featured just side-by-side. Since that's a Racket-ish system, note that Typed Racket doesn't deal too well with Racket macros at the moment, as one example.

Statically typed languages can also take expressions, statically type check those expressions, manipulate those expressions, expand them at compile time, and then even statically type check these expanded expressions. Rust can do this and it results in things like a type-safe printf.
https://doc.rust-lang.org/beta/book/macros.html

You might not be able to do all the stuff with macros you could in Common Lisp and it's not homoiconic, but it might be good enough. Even if rust doesn't do everything you'd want, you could probably imagine a statically typed language that could in practice do so.

# ? Feb 27, 2017 02:29

TheresNoThyme: Nov 23, 2012

FamDav posted:

the right answer is whatever your company uses to create rpc clients/servers. if your company is internally vending REST apis with "discoverable" specs you should probably leave because they're more beholden to dumb principles than productivity

Well, any company doing SOA stuff for > 5 years will have several options in my experience, some of them might even be for good reason (meaning the tradeoffs were actually considered). I'm part of a team that maintains SOAP services with dedicated infrastructure devices, internal webservices using native RPC calls, as well as public API's with plain old REST + JSON and oauth. We are slowly retiring the RMI stuff.

That said I agree discoverability in REST is more pain than it's worth. One of these days I'll do a personal project in HATEOAS just to experience it for myself though.

TheresNoThyme fucked around with this message at 03:09 on Feb 27, 2017

# ? Feb 27, 2017 02:37

comedyblissoption: Mar 15, 2006

redleader posted:

ok so what are the actual advantages of dynamic typing? what would make me want to go from my obviously dumb and lovely static typing to a more dynamic type system?

I'm an incredibly statically typed language bigot, so these are literally the only things I can think of:

dynamically typed languages used to have the cool and powerful language features (e.g. higher order functions, closures, macros based on expressions), but this is not the case anymore
dynamically typed languages tended to have less boilerplate and syntactic noise, but with type inference and GC being popular in mainstream statically typed languages this is no longer an issue IMO
it's probably easier to create a new dyamically typed language than a new statically typed language
interop with binaries/programs from other languages or web apis can require more up-front declaration in a statically typed program that can still fail at runtime anyways if you get the declarations wrong
manipulating or reading json-like data that you haven't deserialized into your language's native types will be more cumbersome
if your type system is not capable of representing more advanced concepts (e.g. generics in golang or higher kinded types in C#/java) and you try to represent these in your program, the best you can generally do is rely on dynamic type checks and now you've lost the benefit of static typing and are going through some syntactic and boilerplate hurdles to represent what you want.
for concepts your language can't express, you often have to do certain "design patterns" which basically translates into concepts your language is bad at expressing (e.g. creating an object representing a function before Java 8)
dynamically typed languages tend not to have a culture or ecosystem encouraging giant inheritance trees or other java-like OOP-isms

comedyblissoption fucked around with this message at 02:47 on Feb 27, 2017

# ? Feb 27, 2017 02:43

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

FamDav posted:

im super curious why tho. like, how does every single statically typed lang youve used cause you frustration?

from the list above:

comedyblissoption posted:

interop with binaries/programs from other languages or web apis can require more up-front declaration in a statically typed program that can still fail at runtime anyways if you get the declarations wrong

manipulating or reading json-like data that you haven't deserialized into your language's native types will be more cumbersome

if your type system is not capable of representing more advanced concepts (e.g. generics in golang or higher kinded types in C#/java) and you try to represent these in your program, the best you can generally do is rely on dynamic type checks and now you've lost the benefit of static typing and are going through some syntactic and boilerplate hurdles to represent what you want.

dynamically typed languages tend not to have a culture or ecosystem encouraging giant inheritance trees or other java-like OOP-isms

for the bullshit code i've been writing (heavy amounts of automation and third party interop), it's rarely worth it

# ? Feb 27, 2017 02:55

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

throw in a "languages with good type systems tend to lean towards ADTs and not OO-esque styles", which is great except when sometimes OO-esque is better (foreign data or apis)

also i am in a nightmare world with thousands of types but all of them are differently formatted strings

# ? Feb 27, 2017 03:05

TheresNoThyme: Nov 23, 2012

people will disagree about it being a good thing but I think dynamically typed languages tend to be easier for first time programmers. there's a lot of learning that goes into understanding object casting and, more fundamentally, it takes time to reach a level where you feel comfortable exploring a programming API in order to hunt down that toInteger function. hell in my first year of programming just typing syntactically correct code inside an IDE took a lot of time.

# ? Feb 27, 2017 03:06

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

comedyblissoption posted:

I'm an incredibly statically typed language bigot, so these are literally the only things I can think of:

dynamically typed languages used to have the cool and powerful language features (e.g. higher order functions, closures, macros based on expressions), but this is not the case anymore

dynamically typed languages tended to have less boilerplate and syntactic noise, but with type inference and GC being popular in mainstream statically typed languages this is no longer an issue IMO

it's probably easier to create a new dyamically typed language than a new statically typed language

interop with binaries/programs from other languages or web apis can require more up-front declaration in a statically typed program that can still fail at runtime anyways if you get the declarations wrong

manipulating or reading json-like data that you haven't deserialized into your language's native types will be more cumbersome

if your type system is not capable of representing more advanced concepts (e.g. generics in golang or higher kinded types in C#/java) and you try to represent these in your program, the best you can generally do is rely on dynamic type checks and now you've lost the benefit of static typing and are going through some syntactic and boilerplate hurdles to represent what you want.

for concepts your language can't express, you often have to do certain "design patterns" which basically translates into concepts your language is bad at expressing (e.g. creating an object representing a function before Java 8)

dynamically typed languages tend not to have a culture or ecosystem encouraging giant inheritance trees or other java-like OOP-isms

ps thank you for this list it is better than what i've been trying to whine about

# ? Feb 27, 2017 03:08

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

comedyblissoption posted:

they have OOP concepts, but programmers in these languages are much more likely to compose their programs out of functions instead of a bunch of interwoven mutable objects with absurd inheritance trees AFAIK. it's more of a cultural thing.

and yes, I know people have created OOP-like frameworks in javascript with inheritance.

oh right, i'm here, welp

# ? Feb 27, 2017 03:09

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 09:43

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

TheresNoThyme posted:

people will disagree about it being a good thing but I think dynamically typed languages tend to be easier for first time programmers. there's a lot of learning that goes into understanding object casting and, more fundamentally, it takes time to reach a level where you feel comfortable exploring a programming API in order to hunt down that toInteger function. hell in my first year of programming just typing syntactically correct code inside an IDE took a lot of time.

in some ways scratch is a statically typed language because you can't just mash the blocks together, and benefits wildly from it :toot:

# ? Feb 27, 2017 03:11

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »