Re: Absent's Code Thread

yeah I'm installing it now
had a lot of problems because I guess I forgot to reboot after updating a bunch of shit and breaking the kernel and shit
like I forgot to change the initrd and what not and it kept fucking up the slackbuild until I fixed everything and rebooted idk
something something compiler linking something something fucked if I know


I forget if I actually needed oracle's jdk for something or not so we'll see because I got rid of it
netbeans maybe


also wtf are people still using sourceforge for lol
shit's down :/
can't even update libreoffice or other shit

Re: Absent's Code Thread

yeah i hate how some projects are still in sourceforge
slackware? there's openjdk slackbuilds. openjdk8 is LTS for a while. zulu-openjdk9 is a bit newer, idk what shit they added, but it'll be unsupported soon

sloth wrote:

Comfy does not provide challenge, challenge provides success, success provides happiness. Our world is not comfy, although we tried to make it so. Slaves of our own inventions, yada, yada. Not only on a technological level, also on a social and political level. Nothing more but apes. Apes with psychosomatic disorders.

Re: Absent's Code Thread

Yeah netbeans is set up for oracles jdk I guess or I like, installed the netbeans version from oracle or something because it won't start without it. I don't feel like bothering. I'm gonna try to run both and see what happens lmao.


Yeah it works if I run it from the terminal. Idk why it doesn't work from dmenu :/
Probably because openjdk replaced jdk in the path. That's fine though idc.

Re: Absent's Code Thread

lol fuck netbeans, try intellij

sloth wrote:

Comfy does not provide challenge, challenge provides success, success provides happiness. Our world is not comfy, although we tried to make it so. Slaves of our own inventions, yada, yada. Not only on a technological level, also on a social and political level. Nothing more but apes. Apes with psychosomatic disorders.

Re: Absent's Code Thread

I used to use intellij but iirc it has a lot less "hints" and shit.


I didn't do a very good job of learning java / OO stuff in college lmao so basically I'm trying to nail down terminology and best coding practices and shit. Like, for example, access modifiers and what not. The current version of netbeans I'm using will warn me if I did something pointless or stupid usually. Plus I'm just pretty used to the interface. Maybe I'll switch to Intellij at some point but I feel like netbeans is pretty standard these days for a lot of places. Like most shops use Eclipse or netbeans I feel like.

Re: Absent's Code Thread

On emacs and stack space issues and how to fix them: http://lists.gnu.org/archive/html/emacs … 00014.html

Re: Absent's Code Thread

It's been almost a month since I've written any code.
Fuck sake. Getting back into it now.

Re: Absent's Code Thread

One of the things that's starting to sink in is why encapsulation is so useful. Rewriting Ocaml-pass has become a bit of a nightmare because of the interdependence between the methods. When I change this to make it memory secure, 3 other methods crucial to even running the application break and it's no longer able to compile. I'm not sure if OOP style encapsulation is a good idea here, or not. I'm pretty sure Ocaml has features to implement objects, which might be nice, but that doesn't strike me as a good idea in a FP language. That's OOP the point is to use a more functional style.


Really, I guess it comes down to better design and experience? If I were a better programmer at the outset and/or spent more time on concrete design, I could have defined a clearer interface between the encryption and other operations such that changing the actual implementation of certain functions wouldn't break the entire system. I'm trying to think of better ways to do this. I know in LISP we essentially built 100% abstract interfaces for every method, such that changing the implementation details never really fucked anything else up because you could pretty much just tweak a couple of things to get better results. I remember that wasn't quite as easy in ML, but in ML it didn't matter as much because the code was significantly more concise, so there was less to rewrite anyways. That was what my professor taught anyway.


I don't really know what the best approach to "encapsulation" or really, abstraction / modular design in FP is I guess.
Like I need to reduce coupling but there doesn't seem to be a great functional way to ensure this, besides better design.

Re: Absent's Code Thread

So looks like what Ocaml uses instead of classes and objects and OO design patterns, are modules. http://www.cs.cornell.edu/courses/cs311 … notes.html Which I sorta kinda knew but not really in the context of what they replace in OO. I'm buzzed and this is very complicated, I think, but I think ocaml-pass will need to be rewritten with modules, maybe. I mean I could do the whole thing without them, but it's decidedly a bit harder to reason about, and if it grows I'll regret the interdependence the functions'll end up having. Basically I just want a good interface system for the different functions, I guess. Plus it'll solve some other weird issues I've been having.

Re: Absent's Code Thread

The module system is still fairly confusing to me, but I'm pretty sure I can get it. Mainly .mli files and writing signatures / interfaces confuses me. Still, at an abstracted level, I think:


Module: Encryption --> This will replace the large encryption functions. Hopefully inside of this I can break the larger encryption functions down into multiple, very specific functions. This module will then have a very simple interface: Take text, return encrypted text. Take encrypted text, return decrypted text. Or possibly, a separate encryption and decryption module, to reduce coupling. I don't want to have to reuse code for each module, though. But that's how it is already so idk what the best design here is. Could just have an all encompassing encryption / decryption module. The idea is to have independent modules testable independently. If something in this (these?) module absolutely requires another module to be tested, I've fucked up again. Plus modules shouldn't depend on the internals of another module, which I would need to do for this, so probably I'll just have one module for "encryption/decryption". I could use includes and functors for this, though, and seperate them. That'd be smart, I think.


Module: UI module --> User I/O, basically program flow. While loop to keep the thing running, takes user input, passes to other modules and gets the shit back from those modules, then displays it.


I'm not sure how the fuck I'd use modules to do file I/O and regex without them being hopelessly intertwined with the rest of the modules.


Module: Configuration --> Essentially stores / generates session keys and takes the password.



Agh, I don't even know how to design this shit well. It's tough and I have no examples to look at.


This is a classic design problem. In OOP languages, it is hard to resolve this elegantly because a class encapsulates both a type definition and methods related to that type. Thus, as soon as you have a function such as a_of_b, which regards two types to an equal extent, there is no clear place for it.

OCaml correctly provides distinct language mechanisms for these distinct needs: type definitions are introduced with the keyword type, and related methods are collected together in a module. This gives you greater flexibility in designing your API, but does not solve the problem automatically.

One possibility is to define modules A and B, both with their respective types and compare functions. Then, the question remaining is where to put a_of_b and b_of_a. You could arbitrarily give preference to module A, and define the functions A.to_b and A.of_b. This is what the Standard Library did when it put to_list and of_list in Array. This lacks symmetry; there is no reason not to have put these functions in B instead.

Instead you could standardize on using of_ functions vs to_ functions. Let's say you prefer to_. Then you would define the functions A.to_b and B.to_a. The problem now is modules A and B are mutually dependent, which is only possible if you define them in the same file.

If you will have lots of functions that deal with values of type A.t and B.t, then it may be worth defining a module AB, and putting all these functions in there. If you will only need two, then an extra module is perhaps overkill.

On the other hand, if the total number of functions regarding A's and B's is small, you could create only the module AB, with type a, type b, and all related methods. However, this does not follow the OCaml community's convention of naming a type t within its own module, and it will be harder to apply the Set and Map functors to these types.


Fuckin design gets hard.


Edit: Not this is broken. What it should have, is a few modules such as encryption/decryption, maybe configuration, and parsing, then have a "core" which may or not be a module, which handles the actual "main" program execution and shit. The modules are useful for abstracting certain specific higher level actions with good interfaces, then the "core" module (or even just code not in a module) uses the modules to implement the rest of the actual program. So it'd look something like this:


http://plugins.netbeans.org/data/images/1369339853_case1.png

Re: Absent's Code Thread

Yeah, modules, types and shit.
Haskell has typeclasses and stuff. I don't think an abstract interface is even a thing in Haskell.
I will read up on OO design. Ugh

sloth wrote:

Comfy does not provide challenge, challenge provides success, success provides happiness. Our world is not comfy, although we tried to make it so. Slaves of our own inventions, yada, yada. Not only on a technological level, also on a social and political level. Nothing more but apes. Apes with psychosomatic disorders.

Re: Absent's Code Thread

I'm not really sure modules etc would even count as OO design. You need some kind of software engineering esque features or you'll inevitably end up with a clusterfuck on medium to large projects, imo. Especially if there's more than one dev. Ocaml-pass doesn't necessarily need it because it's fairly small and I could rewrite the whole thing without it given energy and time, but I think it'd be better to do it with modules and shit just to make it easier to extend and reason about.

Re: Absent's Code Thread

So I implemented a Stack today. It uses my doubly linked list, but only uses the addHead and removeNode methods from it. It wasn't too bad, but I had to make pretty much everything public in the implementation. This isn't really problematic because a linked list class should pretty much all be public. What's the point of hiding shit in a linked list object? You want to be able to use it in the most ways possible, we're not implementing it for a specific purpose. It should be extensible by anything that wants to use it.


So yeah, here that is: https://github.com/Jchase2/Java_Basics/ … Stack.java


Fairly easy. Once I implement a queue hopefully I'll be able to implement trees and graphs, then finally learn about maps and hash maps and all this. I have basically no idea how they work, and they seem to be used everywhere. I also need to focus more on big o and whatever the fuck ADT's do and MVC (??), a few different "patterns" like singleton pattern, composition and delegation.... Fucking, idek. There's a lot. Garbage collection is pretty big in interviews. Idk. I should implement something that connects to a server in java, as well. Get a little bit of an idea of how http shit works. I remember doing stuff in a networking class that was easy peasy. There's just so much shit to know. Plus, of course, software engineering principles.


Ugh. I bought 2 books on interviewing though so I will go through them.

Re: Absent's Code Thread

Purchased "Cracking the Coding Interview" which is apparently like the best book on coding interviews out, and "Programming interviews exposed", which is like, a more basic version. I'll start with the more basic version considering I'm not tryna apply at the big 4 and I'm a jr dev.

Re: Absent's Code Thread

There were loads of errors in my linked list and stack lmfao.
Fixed now, though. Working on finishing up my Queue now.
On chapter 3 of the first interview book.
I wanna get through these data structures before I dive in too deep in that though.
Ugh.

Re: Absent's Code Thread

Queue is finished: https://github.com/Jchase2/Java_Basics/ … Queue.java

Re: Absent's Code Thread

Hash tables are less complicated than I thought. Conceptually, I mean. The actual hash functions are probably pretty complicated, but 'sides that it's basically just hashing objects and having a key/value array, afaik. It's annoying learning enough to pass interviews. You have to memorize syntax, you have to memorize parts of the core language that is always changing, you have to memorize the details of certain data structures even though they're pretty much built into every language now... Ugh. You also have to get good at algorithmic thinking and soft interview questions.


It's a lot.