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 »

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

buh buh buh bird bird bird, bird is the turd

# ? Aug 22, 2013 01:41

Adbot: ADBOT LOVES YOU

# ? Jun 5, 2024 11:20

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

bird poop for next page

http://dspace.mit.edu/bitstream/handle/1721.1/5836/AIM-248.pdf

# ? Aug 22, 2013 01:46

Nomnom Cookie: Aug 30, 2009

oh also 0mq doesn't expose timers and doesn't let you have fds which is a minor pita

# ? Aug 22, 2013 01:46

Posting Principle: Dec 10, 2011; by Ralp

C++ code:

typedef QColor QColour;

# ? Aug 22, 2013 03:16

FamDav: Mar 29, 2008

yo what is the name of the dogge book again

# ? Aug 22, 2013 04:02

Deacon of Delicious: Aug 20, 2007; I bet the twist ending is Dracula's dick-babies

FamDav posted:

yo what is the name of the dogge book again

do you mean the practice of programming?

# ? Aug 22, 2013 04:15

MSPain: Jul 14, 2006

the only thing anyone ever does in lisp anymore is make metacircular interpreters to run lisp programs in their lisp program.

# ? Aug 22, 2013 04:17

Zombywuf: Mar 29, 2008

MSPain posted:

the only thing anyone ever does in lisp anymore is make metacircular interpreters to run lisp programs in their lisp program.

Which is far more fun in Prolog.

# ? Aug 22, 2013 13:08

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

trex eaterofcadrs posted:

really?

i have written some pretty complex clojure programs with quite a bit of java interop and not really had too many issues. in fact I've done clojure/groovy interop, and that poo poo was kind of a horrorshow but it still worked and the "interop" part wasn't really the issue.

where did you run into this? i macro-generate clojure "javabeans" and register them into a spring di app context and don't even really need to muck around with gen-class or reify (proxy and protocols for sure but i've never had to touch reify)

so here's the key thing: proxies and protocols are a big pain in the rear end. you have to write code to bridge incompatible metaphors and ugh

and for calling the other way, like you said yourself you use macros to generate getters and setters. that's pretty hairy on its own. especially if everyone reinvents the same macro.

here are the steps to scala<=>java interop:

write code
re-use code elsewhere

it's not just easy it's completely loving effortless

# ? Aug 22, 2013 15:04

Shaggar: Apr 26, 2006

heres a better procedure:
1) just use java instead of useless hacks on top of java.

# ? Aug 22, 2013 15:05

Condiv: May 7, 2008; Sorry to undo the effort of paying a domestic abuser $10 to own this poster, but I am going to lose my dang mind if I keep seeing multiple posters who appear to be Baloogan.

With love,
a mod

can't blame a shaggar for shaggaring

# ? Aug 22, 2013 17:45

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

Shaggar posted:

heres a better procedure:
1) just use java instead of useless hacks on top of java.

if java moved with the times then we would do this
but it doesn't

the .net guys get helpful new features like, every year

# ? Aug 22, 2013 17:58

Shaggar: Apr 26, 2006

there aren't any new features that java really needs aisde from upgrades to the standard lib (ex: replace Calendar w/ .net's DateTime).

# ? Aug 22, 2013 17:59

Nomnom Cookie: Aug 30, 2009

Scala never met a feature it didn't like. Also compiling Scala takes forever. Also Java 8 will have option types and lambdas, the 2 best features of Scala.

# ? Aug 22, 2013 18:02

Posting Principle: Dec 10, 2011; by Ralp

also java 8 apps will probably keep the permgen smaller than the working set

# ? Aug 22, 2013 18:16

Posting Principle: Dec 10, 2011; by Ralp

its cool how a medium sized scala app can generate more classes than are in the entire jre

# ? Aug 22, 2013 18:17

Posting Principle: Dec 10, 2011; by Ralp

scala is still rad though

# ? Aug 22, 2013 18:17

Condiv: May 7, 2008; Sorry to undo the effort of paying a domestic abuser $10 to own this poster, but I am going to lose my dang mind if I keep seeing multiple posters who appear to be Baloogan.

With love,
a mod

Nomnom Cookie posted:

Scala never met a feature it didn't like. Also compiling Scala takes forever. Also Java 8 will have option types and lambdas, the 2 best features of Scala.

they are getting a new compiler in scala 2.11 that is really drat fast, better at optimizing, and fixes some issues scala had. For example, the initialization order problem is done away with by this compiler from what I hear.

initialization order problem:

code:

abstract class A {
  val x1: String
  val x2: String = "mom"
  
  println("A: " + x1 + ", " + x2)
}
class B extends A {
  val x1: String = "hello"
    
  println("B: " + x1 + ", " + x2)
}
class C extends B {
  override val x2: String = "dad"
  
  println("C: " + x1 + ", " + x2)
}
// scala> new C 
// A: null, null
// B: hello, null
// C: hello, dad

# ? Aug 22, 2013 18:34

prefect: Sep 11, 2001; No one, Woodhouse.
No one.; Dead Man’s Band

Nomnom Cookie posted:

Scala never met a feature it didn't like. Also compiling Scala takes forever. Also Java 8 will have option types and lambdas, the 2 best features of Scala.

do you think java would be adding those things if scala weren't as popular as it is? maybe java advances are being pushed forward by the competition?

(i'm not closely in tune with the java community, so i could be completely wrong; this is just a theory)

# ? Aug 22, 2013 18:42

Vanadium: Jan 8, 2005

What do option types even buy you in a language with null pointers?

# ? Aug 22, 2013 18:52

MeruFM: Jul 27, 2010

more obfuscation for more job security

# ? Aug 22, 2013 18:58

Shaggar: Apr 26, 2006

Vanadium posted:

What do option types even buy you in a language with null pointers?

the same thing as lambdas

MeruFM posted:

more obfuscation for more job security

# ? Aug 22, 2013 18:58

Condiv: May 7, 2008; Sorry to undo the effort of paying a domestic abuser $10 to own this poster, but I am going to lose my dang mind if I keep seeing multiple posters who appear to be Baloogan.

With love,
a mod

Vanadium posted:

What do option types even buy you in a language with null pointers?

not as much as they should, but if you use them where you would normally use null it greatly decreases the risk of encountering null pointer errors.

# ? Aug 22, 2013 18:59

crazypenguin: Mar 9, 2005; nothing witty here, move along

Posting Principle posted:

its cool how a medium sized scala app can generate more classes than are in the entire jre

not really scala's fault. jvm sucks hard at closures, they all have to be their own classes.

Java 8 lambdas are "solving" this problem by using all that invokedynamic stuff they added for dynamic languages to turn a static method into a class at runtime instead of having to emit a .class at compile time.

I really don't know how they decided that was a good solution.

# ? Aug 22, 2013 19:00

Bloody: Mar 3, 2013

crazypenguin posted:

Java... I really don't know how they decided that was a good solution.

# ? Aug 22, 2013 19:03

Shaggar: Apr 26, 2006

crazypenguin posted:

not really scala's fault. jvm sucks hard at closures, they all have to be their own classes.

Java 8 lambdas are "solving" this problem by using all that invokedynamic stuff they added for dynamic languages to turn a static method into a class at runtime instead of having to emit a .class at compile time.

I really don't know how they decided that was a good solution.

because theres no reason to waste time devising a better solution for adding useless cruft to the jvm to support dumb crap like closures

# ? Aug 22, 2013 19:04

gonadic io: Feb 16, 2011; >>=

Vanadium posted:

What do option types even buy you in a language with null pointers?

if the compiler warned you when you just assumed an object wasn't null without proving it first (i.e. by manually checking) then you wouldn't need Option.

can you have nonnullable objects? seems pretty pointless if anything you know isn't Nothing or whatever it is in java could just be null after all

e: what i'm trying to say is that option is essentially a not terrible version of null

gonadic io fucked around with this message at 19:10 on Aug 22, 2013

# ? Aug 22, 2013 19:05

Max Facetime: Apr 18, 2009

crazypenguin posted:

not really scala's fault. jvm sucks hard at closures, they all have to be their own classes.

Java 8 lambdas are "solving" this problem by using all that invokedynamic stuff they added for dynamic languages to turn a static method into a class at runtime instead of having to emit a .class at compile time.

I really don't know how they decided that was a good solution.

doing it like that means the generated classes can't be aliased in client code. maybe they foresee the other compiler to be able to optimize things better, if not now then in the future

# ? Aug 22, 2013 19:28

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

AlsoD posted:

if the compiler warned you when you just assumed an object wasn't null without proving it first (i.e. by manually checking) then you wouldn't need Option.

can you have nonnullable objects? seems pretty pointless if anything you know isn't Nothing or whatever it is in java could just be null after all

This exists. you tag things with @NonNull/@Nullable annotations and the ide uses that to figure out what can and can't be null

i'm using it in eclipse and it does make the language a bit less painful. but none of the libraries you'll want to use have nullability annotations, so it;s not exactly great yet

# ? Aug 22, 2013 21:19

Max Facetime: Apr 18, 2009

Soricidus posted:

This exists. you tag things with @NonNull/@Nullable annotations and the ide uses that to figure out what can and can't be null

i'm using it in eclipse and it does make the language a bit less painful. but none of the libraries you'll want to use have nullability annotations, so it;s not exactly great yet

yo, check dis:

The Checker Framework distribution contains annotations for popular libraries, such as the JDK6 and JDK7. It uses both of the above mechanisms. The Nullness, Javari, IGJ, and Interning Checkers use the annotated JDKs (Section 21.3), and all other checkers use stub files (Section 21.2).

I haven't actually tried compiling against their JDK.jar in lieu of normal JRE jars, but theoretically it should work

# ? Aug 23, 2013 00:27

Nomnom Cookie: Aug 30, 2009

prefect posted:

do you think java would be adding those things if scala weren't as popular as it is? maybe java advances are being pushed forward by the competition?

(i'm not closely in tune with the java community, so i could be completely wrong; this is just a theory)

scala tries lots of things and java looks at that and steals the good things

Vanadium posted:

What do option types even buy you in a language with null pointers?

weeelll i assume java 8 options ensure that Some is non-null. what you get is basically the Maybe monad, which is a good monad (IO is a bad monad). it makes some kinds of code clearer to operate on a Maybe than to have several if statements or whatnot

AlsoD posted:

if the compiler warned you when you just assumed an object wasn't null without proving it first (i.e. by manually checking) then you wouldn't need Option.

can you have nonnullable objects? seems pretty pointless if anything you know isn't Nothing or whatever it is in java could just be null after all

e: what i'm trying to say is that option is essentially a not terrible version of null

null is terrible and lovely and the compiler nagging you to deal with the shittiness doesn't fix things

Max Facetime posted:

yo, check dis:

The Checker Framework distribution contains annotations for popular libraries, such as the JDK6 and JDK7. It uses both of the above mechanisms. The Nullness, Javari, IGJ, and Interning Checkers use the annotated JDKs (Section 21.3), and all other checkers use stub files (Section 21.2).

I haven't actually tried compiling against their JDK.jar in lieu of normal JRE jars, but theoretically it should work

lol yeah lemme just compile my code against some janky 3rd party stdlib and debug the problems it causes in qa

# ? Aug 23, 2013 00:48

Max Facetime: Apr 18, 2009

Nomnom Cookie posted:

lol yeah lemme just compile my code against some janky 3rd party stdlib and debug the problems it causes in qa

you would be compiling against that augmented JDK, but it doesn't include the bytecode that implements the standard library so you wouldn't be able to run your code with it, you'd be by necessity testing and deploing against your regular JDK

# ? Aug 23, 2013 03:35

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

Max Facetime posted:

you would be compiling against that augmented JDK, but it doesn't include the bytecode that implements the standard library so you wouldn't be able to run your code with it, you'd be by necessity testing and deploing against your regular JDK

i don't care how you describe it, monkey-patching the std library is a sign you done hosed up

# ? Aug 23, 2013 04:23

spongeh: Mar 22, 2009; BREADAGRAM OF PROTECTION

i'm not a java programmer but i'm pretty sure yall are missing the point. you build against an annotated jdk just for the purposes of confirming your code conforms to whatever those annotations check. you don't do anything with that annotated jdk past test compiling. your output is byte for byte identical.

# ? Aug 23, 2013 05:29

Nomnom Cookie: Aug 30, 2009

spongeh posted:

i'm not a java programmer but i'm pretty sure yall are missing the point. you build against an annotated jdk just for the purposes of confirming your code conforms to whatever those annotations check. you don't do anything with that annotated jdk past test compiling. your output is byte for byte identical.

oh so you confirmed that the output is identical in all cases. thanks for doing the legwork

# ? Aug 23, 2013 11:49

Max Facetime: Apr 18, 2009

Nomnom Cookie posted:

oh so you confirmed that the output is identical in all cases. thanks for doing the legwork

just compile and run your unit tests like before with the regular JDK, what more needs to be confirmed?

# ? Aug 23, 2013 14:23

Shaggar: Apr 26, 2006

Nomnom Cookie posted:

oh so you confirmed that the output is identical in all cases. thanks for doing the legwork

no, what hes sayin is you use the special jdk in eclipse and during an initial compile to find any places where you have accidental nulls. then once it passes all that, you do the release compilation w/ the normal jdk.

# ? Aug 23, 2013 14:26

MononcQc: May 29, 2007

somewhat related to optional type checking. But Java's stuff is so weak as a type system you need an additional one on top :v:

# ? Aug 23, 2013 17:14

Nomnom Cookie: Aug 30, 2009

Shaggar posted:

no, what hes sayin is you use the special jdk in eclipse and during an initial compile to find any places where you have accidental nulls. then once it passes all that, you do the release compilation w/ the normal jdk.

if someone else is using it, ok...im not gonna be the one to set it up in maven tho

# ? Aug 23, 2013 23:23

Adbot: ADBOT LOVES YOU

# ? Jun 5, 2024 11:20

Cocoa Crispies: Jul 20, 2001; Vehicular Manslaughter!; Pillbug

Nomnom Cookie posted:

if someone else is using it, ok...im not gonna be the one to set it up in maven tho

lol it'd be cake to set up in gradle

# ? Aug 23, 2013 23:26

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

«‹›1784 »