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 »

cowboy beepboop: Feb 24, 2001

Shaggar posted:

this is just as bad as it sounds with unknown changes getting shoved into your build left and right to the point where you have no idea where anything came from. what happens when you uninstall a package? who knows. it might clean up the project changes it made, it might not. even if it does, its guaranteed to break if you made any customizations to the build yourself.

this is how windows works when you install programs so it makes sense

# ? Jul 27, 2015 12:42

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 08:02

Pie Colony: Dec 8, 2006; I AM SUCH A FUCKUP THAT I CAN'T EVEN POST IN AN E/N THREAD I STARTED

Soricidus posted:

wow

the first claim is weak because your classes aren't going to fit on the screen at once in a single file unless they're absolutely trivial, and in that case what's wrong with just nesting them? the only downside is that it can get confusing if the nested classes are non-trivial, but we've already established that we must be talking about trivial classes. and in any case, if anything it's easier to view two classes side by side if they're in different files.

i don't even know what the second sentence is trying to say. how exactly does having things in the same file make it easier to move them to different files incrementally than if they were already in different files to begin with? and in any case, refactoring code and moving it from file to file is the ide's job, not mine.

nested classes in java are horrible

# ? Jul 27, 2015 15:55

Bloody: Mar 3, 2013

im gonna make my own maven for .net. gonna name it yosnet

# ? Jul 27, 2015 16:18

akadajet: Sep 14, 2003

Bloody posted:

im gonna make my own maven for .net. gonna name it yosnet

i'll start the wiki

# ? Jul 27, 2015 16:22

hepatizon: Oct 27, 2010

Pie Colony posted:

nested classes in java are horrible

details

# ? Jul 27, 2015 16:24

Sapozhnik: Jan 2, 2005; Nap Ghost

They're alright. Actually, they have their uses. For instance, I like to implement callback interfaces as nested classes so that I don't have implementation detail callbacks hanging out of my class like some uncouth ingrate.

Static nested classes don't inherit their parents' type variables, which is a bit annoying but whatever (I'm sure there's a good reason for it -- not being sarcastic here). They're nice for defining Builders and things like that.

Anonymous nested classes are gross but those are mostly obsoleted by JDK8 lambdas.

# ? Jul 27, 2015 16:46

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

Plorkyeran posted:

"as good as ant" generally isn't considered a compliment

it was 2003, dude

maven was brand new and untested. ant was the state of the art at the time. it was scads better than writing Makefiles

# ? Jul 27, 2015 17:02

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

Bloody posted:

im gonna make my own maven for .net. gonna name it yosnet

you should hang out with the nant guy and swap war stories about being ignored by the industry

# ? Jul 27, 2015 17:02

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

Mr Dog posted:

Static nested classes don't inherit their parents' type variables, which is a bit annoying but whatever (I'm sure there's a good reason for it -- not being sarcastic here).

that is literally the entire reason why static nested classes exist: since they aren't tied to the parent class, they don't hold an implicit reference to it and can be constructed without access to an instance of it. sometimes this is useful. if it's not useful for you, then you just don't make the nested class static.

e: gently caress, my eye skipped over the word "type" there. sorry bout that. yeah, that part has made me kind of annoyed for a few minutes once or twice but it's probably related to the fact that they're independent of the parent class

there is literally nothing wrong with nested classes, other than that the definitions can get messy and confusing if they're non-trivial. but if you have a non-trivial class then it probably makes sense to put it in its own file anyway. if you have multiple non-trivial classes that are so tightly coupled that it's difficult to separate them at all, then you have bigger problems than java syntax.

Soricidus fucked around with this message at 19:24 on Jul 27, 2015

# ? Jul 27, 2015 19:22

Pie Colony: Dec 8, 2006; I AM SUCH A FUCKUP THAT I CAN'T EVEN POST IN AN E/N THREAD I STARTED

hepatizon posted:

details

nested classes are statically bound and not part of the instance of the enclosing object. essentially this will lead to a bunch of fun problems you discover a little too late. this is one example, similar situations arise when Outer actually starts to reference or instantiate Inners

code:

public class Test {
    static class Outer {
        class Inner {
            int get() { return 0; }
        }
    }

    static class OuterP extends Outer {
        class Inner extends Outer.Inner {
            int get() { return 1; }
        }
    }

    public static void main(String[] args) {
        Outer a = new Outer();
        Outer b = new OuterP();

        System.out.println(a.new Inner().get());
        System.out.println(b.new Inner().get());
    }
}

code:

$ javac Test.java
$ java Test
0
0

# ? Jul 27, 2015 22:52

Shaggar: Apr 26, 2006

Plorkyeran posted:

msbuild as originally designed is actually kinda elegant: ideally the project file should contain nothing but a list of files associated with various tasks and some configuration settings for those tasks, with the tasks themselves defined in .net assemblies written in the .net language of your choice. unfortunately, the other 90% of msbuild is awful cancerous growths of functionality hacked in in the worst possible ways because for some reason they decided not to just tell people to write custom build tasks when they need some logic in their build system.

the design was a failure from the start because its still task oriented instead of result oriented.

# ? Jul 27, 2015 22:53

CPColin: Sep 9, 2003; Big ol' smile.

Pie Colony posted:

nested classes are statically bound and not part of the instance of the enclosing object. essentially this will lead to a bunch of fun problems you discover a little too late. this is one example, similar situations arise when Outer actually starts to reference or instantiate Inners
code:
public class Test {
    static class Outer {
        class Inner {
            int get() { return 0; }
        }
    }

    static class OuterP extends Outer {
        class Inner extends Outer.Inner {
            int get() { return 1; }
        }
    }

    public static void main(String[] args) {
        Outer a = new Outer();
        Outer b = new OuterP();

        System.out.println(a.new Inner().get());
        System.out.println(b.new Inner().get());
    }
}
code:
$ javac Test.java
$ java Test
0
0

Well that's what you get for using "Inner" twice.

# ? Jul 27, 2015 23:18

Sapozhnik: Jan 2, 2005; Nap Ghost

why the gently caress would you declare doubly-nested classes ever

like if this is the least contrived situation in which you can cause nested classes to behave counterintuitively then that's a really weak argument

# ? Jul 27, 2015 23:28

Pie Colony: Dec 8, 2006; I AM SUCH A FUCKUP THAT I CAN'T EVEN POST IN AN E/N THREAD I STARTED

hmm this toy program to demonstrate the problem is contrived and not practical?? :rolleyes:

the more standard example is

code:

class Graph {
    class Edge {
        public Edge() {
            ....
        }
    }
}

class WeightedGraph extends Graph {
    class WeightedEdge extends Graph.Edge {
        public WeightedEdge() {
            super();
            this.weight = 0;
        }
    }
}

good luck trying to make this class work if Graph at all references Edge

# ? Jul 27, 2015 23:36

leftist heap: Feb 28, 2013; Fun Shoe

bad code is bad :monocle:

# ? Jul 27, 2015 23:43

Sapozhnik: Jan 2, 2005; Nap Ghost

here's an actual criticism of Java, or at least its stdlib: futures.

Everybody knows standard Java futures are a little bare-bones: basically the only standard implementation of java.util.concurrent.Future<> in Java 1.5 or whatever is what you get back when you post a Runnable (closure) to an Executor (task pool). Then all you can do on that Future<> is block on it. Which is only marginally useful. I think the canonical case is kicking off a handful of network I/O operations in parallel and then waiting for them all to finish.

Of course, Future<> is a rather simple interface that you can implement or extend yourself, so Guava (and other libs, AsyncHttpClient comes to mind) extended this interface into ListenableFuture<>. This lets you chain a future, e.g.

code:

Future<Baz> baz = something.asyncGetFoo().andThen(Foo::timeConsumingConversionToBar).andThen(Bar::timeConsumingConversionToBaz);

... which sets up a chain of long-running background operations, each of which consume the previous stage's output. These operations get run one after the other in the thread pool.

Java 8, instead, adds CompletableFuture. And this isn't an interface, it's a class with a bazillion methods taking various kinds of "function pointer" type interfaces. You can return a CompletableFuture<> from your API and your clients can attach another computation stage to it.

but they can also supply a result as well which is goddamn loving retarded: this will broadcast that value to every other client that's currently listening or chaining on that future.

Oh, and also, Future.get() throws the checked exception ExecutionException. So every loving use of Future has to catch CheckedException and then unpack what actually went wrong so you have some idiotic chain of instanceof if/elses. Whereas the correct way to do this would be something along the lines of

code:

interface CheckedFuture<T, X extends Throwable> {
    // ...

    T get() throws InterruptedException, X;

    // ...
}

// Convenient shorthand for a CheckedFuture<> that only throws unchecked exceptions
interface Future<T> extends CheckedFuture<T, Error> { }

which could be used like so:

code:

Future<BigDecimal> pi = piCalculator.computeDigits(1000000);
pi.get(); // Only throws InterruptedException

CheckedFuture<String, IOException> theFuckingWeather = theFuckingWeather.getWeather(10011);
theFuckingWeather.get(); // Must also catch or propagate IOException

But that would have made too much sense, apparently.

Also maybe it wasn't possible to type-parameterize an exception specification back in the ancient days of Java 1.5 when Future<> was added idk.

# ? Jul 27, 2015 23:53

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

We used NAnt extensively at a previous job, it worked great.

# ? Jul 27, 2015 23:55

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

sarehu posted:

We used NAnt extensively at a previous job, it worked great.

too bad you were the only ones

# ? Jul 27, 2015 23:57

Shaggar: Apr 26, 2006

ant isn't good enough for anyone to make custom visual studio integration for. maven might be.

# ? Jul 27, 2015 23:58

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Shaggar posted:

the design was a failure from the start because its still task oriented instead of result oriented.

i think the motivation there was for faster incremental builds when working in the ide, but of course in the time since tup and ninja have delivered the same benefits by just taking advantage of the fact that the dependency graph typically doesn't change between two incremental builds, and for the first few years of vs.net the ide couldn't really handle projects with enough files for it to matter anyway

# ? Jul 28, 2015 00:13

Brain Candy: May 18, 2006

Mr Dog posted:

Also maybe it wasn't possible to type-parameterize an exception specification back in the ancient days of Java 1.5 when Future<> was added idk.

checked exceptions are part of the type signature, so just try two to see how bad this gets

code:

interface CheckedFuture2<R, E1 extends Throwable, E2 extends Throwable> {
  R get() throws E1, E2, InterruptedException;
}

great, fine but CheckedFuture2<R, Fart, Boner> != CheckedFuture2<R, Boner, Fart>

but if that weren't enough, look at that InterruptedException. It's checked, so look how screwed I am if I use CheckedFuture<R, InterruptedException>, i have no idea whether the interruption was for my thread or not.

if its for my thread, i might be able to retry, it might be a spurious wake, but if it's for the async execution it will always throw and I can't tell the difference. well, unless i compare stacks, which will be all sorts of misleading to logging

don't take this as an apology for that trash through, because all this pain could be hidden behind the scenes with async/await

# ? Jul 28, 2015 01:28

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

checked exceptions are one of those things that sound really cool until you try using them

# ? Jul 28, 2015 01:45

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

they just feel like someone saw either/maybe/other type-based solutions for error handling and went "hmm... how can i make this loving terrible"

# ? Jul 28, 2015 01:47

Quebec Bagnet: Apr 28, 2009; mess with the honk
you get the bonk; Lipstick Apathy

Notorious b.s.d. posted:

checked exceptions are one of those things that sound really cool until you try using them

it'd be cool if the penalty for not handling was a compiler warning instead of error. the idiots will ignore the warning and it won't be any different from today, the pedants can handle them to shut up the compiler.

# ? Jul 28, 2015 01:48

Sapozhnik: Jan 2, 2005; Nap Ghost

I'm kinda warming up to Go (I liked Vala until I realized that its, or rather GLib's, approach to handling out-of-memory conditions was to fart really loudly and then immediately abort the entire process; GLib's code consistently assumes that memory allocations can never fail). But I know exactly what is going to happen to it: it will inevitably gain generics, just like every single other statically typed language that initially omitted generics because they overcomplicate things, and there will be a K-T event in its library ecosystem sediment, and god help any poor bastard who has to program something that has to interact with both sides of that K-T event.

e: oh, apparently there is no way to recover from out-of-memory in Go either. cool. well, it has GC but no exceptions so that's hardly surprising I suppose.

Sapozhnik fucked around with this message at 22:54 on Aug 3, 2015

# ? Aug 3, 2015 22:51

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Mr Dog posted:

I'm kinda warming up to Go (I liked Vala until I realized that its, or rather GLib's, approach to handling out-of-memory conditions was to fart really loudly and then immediately abort the entire process; GLib's code consistently assumes that memory allocations can never fail)

what the hell were you doing to hit this boundary condition on your 32gb of ram dev server?

# ? Aug 3, 2015 23:10

MononcQc: May 29, 2007

ultramiraculous posted:

what the hell were you doing to hit this boundary condition on your 32gb of ram dev server?

it's a systems language because it requires all of the system's resources to work

# ? Aug 3, 2015 23:20

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

what does rust do when it runs out of memory?

# ? Aug 4, 2015 00:26

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

Soricidus posted:

what does rust do when it runs out of memory?

abort

# ? Aug 4, 2015 00:32

b0lt: Apr 29, 2005

Mr Dog posted:

I'm kinda warming up to Go (I liked Vala until I realized that its, or rather GLib's, approach to handling out-of-memory conditions was to fart really loudly and then immediately abort the entire process; GLib's code consistently assumes that memory allocations can never fail). But I know exactly what is going to happen to it: it will inevitably gain generics, just like every single other statically typed language that initially omitted generics because they overcomplicate things, and there will be a K-T event in its library ecosystem sediment, and god help any poor bastard who has to program something that has to interact with both sides of that K-T event.

e: oh, apparently there is no way to recover from out-of-memory in Go either. cool. well, it has GC but no exceptions so that's hardly surprising I suppose.

there's no way to recover from out of memory in the default settings for every single distribution of linux anyway, since overcommit means malloc will never fail, so your program will go happily on and then get brutally murdered by the oom killer

# ? Aug 4, 2015 00:41

Cybernetic Vermin: Apr 18, 2005

trying to recover from fatally bad situations tends to amount to smearing poo poo all over yourself and a bunch of log files in almost all software

on that theme i think the checked exceptions of java was a sort of correct idea, but in reality a vast number of exceptions shoukd never be checked since the software has no consistent world-view of what the failure means. even opening a configuration file resulting in a file not found exception is way out of the scope of the vast majority of all softwares purview, you have already left the operational parameters and pretty much anything the software does from there is lovely programmers lovely attempts at replicating the concept of a core dump in every log file that exists

if you think you can deal with an out of memory error you really need to either be the operating system or be an application so deeply intertwined with it that you actually can start prodding around memory tables

# ? Aug 4, 2015 00:57

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

i mean, or you could release a bunch of cached data i guess

also, swift-style checked exceptions are awesome, and c++ is rapidly moving in that direction (though taking the opposite tack with noexcept())

# ? Aug 4, 2015 01:06

MononcQc: May 29, 2007

Erlang also just goes "failed to allocate, gently caress this I'm out" if you don't allow it to use Swap or anything. For server-software (taking back the dig at Go), it's often a reasonable way to do things because most people build their poo poo to handle going offline on specific instances from time to time. That's how most people deploy anyway.

# ? Aug 4, 2015 01:11

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

hi

here's a two hour talk on elevators, it's pretty good https://www.youtube.com/watch?v=rOzrJjdZDRQ

# ? Aug 4, 2015 02:25

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

tef posted:

hi

here's a two hour talk on elevators, it's pretty good https://www.youtube.com/watch?v=rOzrJjdZDRQ

actually just said the same thing in the sec-fuckup thread

# ? Aug 4, 2015 03:15

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

Dessert Rose posted:

i mean, or you could release a bunch of cached data i guess

also, swift-style checked exceptions are awesome, and c++ is rapidly moving in that direction (though taking the opposite tack with noexcept())

thanks, ive been hoping the bien-pensants in this thread would take a second to tear it to shreds

abort on out-of-memory is really the only reasonable solution if you're not willing to go hardcore gently caress-you-this-is-systems and make allocation failure a checked error, which also (probably?) precludes any language features that do implicit allocation, and also fucks the optimizer

# ? Aug 4, 2015 03:37

Ralith: Jan 12, 2011; I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

MononcQc posted:

Erlang also just goes "failed to allocate, gently caress this I'm out" if you don't allow it to use Swap or anything. For server-software (taking back the dig at Go), it's often a reasonable way to do things because most people build their poo poo to handle going offline on specific instances from time to time. That's how most people deploy anyway.

Specifically, this is a reasonable way to handle OOM (and other borderline-unrecoverable errors) because if you are writing large-scale server software and your system can't handle processes/machines/datacenters randomly going offline, you're doomed to slow and painful failure.

Also, you know, the whole "linux makes it futile anyway" thing.

# ? Aug 4, 2015 03:38

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

Allocation failure is more likely the result of your program passing a garbage size to malloc anyway.

# ? Aug 4, 2015 06:24

Space Whale: Nov 6, 2014

tef posted:

hi

here's a two hour talk on elevators, it's pretty good https://www.youtube.com/watch?v=rOzrJjdZDRQ

Holy poo poo, they really test their redundancies and safeties.

Running at full speed overloaded into that pit buffer.

# ? Aug 4, 2015 08:34

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 08:02

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

Cybernetic Vermin posted:

trying to recover from fatally bad situations tends to amount to smearing poo poo all over yourself and a bunch of log files in almost all software

on that theme i think the checked exceptions of java was a sort of correct idea, but in reality a vast number of exceptions shoukd never be checked since the software has no consistent world-view of what the failure means. even opening a configuration file resulting in a file not found exception is way out of the scope of the vast majority of all softwares purview, you have already left the operational parameters and pretty much anything the software does from there is lovely programmers lovely attempts at replicating the concept of a core dump in every log file that exists

if you think you can deal with an out of memory error you really need to either be the operating system or be an application so deeply intertwined with it that you actually can start prodding around memory tables

drivers. drivers can't crash on oom, and this leads to interesting situations where sometimes handling oom requires allocating resources (e.g. for posting a notification somewhere), so you have to pessimistically pre-allocate all the resources you'll need in the worst case scenario lol jk, just leave the driver in an undefined state :classiclol:

# ? Aug 4, 2015 11:08

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

«‹›1784 »