/tech/ - Technology★

It's almost never used outside European academia.

I like how they tried to force themselves on the world by writing useful apps in ocaml and bundling the whole language in it to bootstrap with.

>>889258 (OP)

>Pure haskal code is shit.

"I want every part of code to be able to delete the my database and call random web services"

OCAML IS IMPURE SHIT

>>889258 (OP)

SML is much better. no shitty ad hoc constructs or dumbass objects, broken modules, structural typing, etc

>Pure haskal code is shit.

not really, but lazy evaluation is bad for security and robustness

>>889291

>"I want every part of code to be able to delete the my database and call random web services"

not an argument

>>891828

I mean, it is an argument, but if you think you are safe because you are using Haskal, you are way wrong.

The only people who hate it are Haskellniggers

>>891828

>not an argument

Actually it is an argument. Its a comment on fundamental properties of the languages.

>>891864

can you write an interrupt routine in it? you little shit, can your piss language do that?

>>891899

Which type of interrupt

>>891903

do you even know what an interrupt routine is? you little faggot

>>891899

>haskellnigger says words he doesn't understand

>>891917

I am talking about Holy C, not haskellshit

>>891914

You know that there are multiple types of interrupts right? Or did they not teach you that in pajeet code academy.

>>891918

>he fell for the meme OS

Sad!

>>889258 (OP)

OCaml was rendered obsolete by Rust

>>892209

>Can't implement a doubly linked list in it

>Obsoleted

>>892210

You technically can, it's just unreasonably convoluted compared to any other programming language.

>>892368

>unreasonably convoluted

Rust double linked List: https://doc.rust-lang.org/src/alloc/linked_list.rs.html

1660 LOC with comments

C++ doubly linked List: https://llvm.org/svn/llvm-project/libcxx/trunk/include/list

2421 LOC without comments

>>892502

Your Rust example uses unsafe all over the place.

>>892496

>>OOP if you like

Common LISP

>>Not purely functional, imperative if you like

Common LISP

>>GC if you like

D

>>No implicit type conversion

Why is this useful again? Serious question.

>>Nice syntax (subjective)

Common LISP and D

Of course, nobody really uses Ocaml, D, or CL so maybe people don't like this sort of thing?

>>892496

>But where is it typically used?

At INRIA in France.

>>892623

>he thinks using unsafe in rust is bad

>>892502

You know the C++ option does a billion more things right?

>>892502

Reading these gives me hope that one day APL/J/K/Q will make a come back.

>>892680

If you want a simple definition you can have one:

struct node

{

int data;

node *next;

};

class linked_list

{

private:

node *head,*tail;

public:

linked_list()

{

head = NULL;

tail = NULL;

}

void add_node(int n)

{

node *tmp = new node;

tmp->data = n;

tmp->next = NULL;

if(head == NULL)

{

head = tmp;

tail = tmp;

}

else

{

tail->next = tmp;

tail = tail->next;

}

}

};

It just means that your linked list will be missing all the optimizations, and extra operations you might want to do.

>>892681

obv you are going to want more things like delete node, a system for iterating, etc.

>>892662

>rewrite everything in Rust, it's super memory safe

>lol, just use unsafe in Rust, it's not a bad thing

>>892630

>Why is no implicit type conversion useful again?

I'd rather get an error I can correct myself when I'm trying to put the wrong type into something, rather than getting something out automatically, the type of which I may not expect. You might disagree for various reasons though.

>maybe people don't like this sort of thing?

I wouldn't know. Sounds fine to me, but those seem to be less important than other factors. Companies use legacy Matlab code and there's maniacs writing backends in Javascript as you read. Also there is a Haskell windomanager, iirc.

>>892682

>a system for iterating

>>892681

private:
    node *head,*tail;

Spotted your problem.

You obviously need a couple of getter/setter functions here.

>>892692

Which was what that comment was pointing out

>>892695

lol I was messing with ya kid.

>>892733

>just pretending to be retarded

>>892683

>codelet doesn't understand that sound type checkers can reject valid programs and you need to get around that.

wew

>>892751

>codelet does not understand that type safe languages are still Turing complete and that every program can be expressed in a non shit way.

Rusts type system is just shitty and weak.

>>892761

Its better than Java's, not a high bar. A type system that can't verify a list data type though is weak bullshit. BTW "weak" here means not powerful, not "weakly" typed like C.

>>892741

I'd like you to point out which post you think I was pretending in. Because I'm pretty sure you have no idea.

>>892630

Common Lisp has dynamic typing, which just means that type errors will bite you in the ass when it hurts the most, rather than sorting that shit out at compile time. There are type optional annotations, but those just remove type checking entirely in the name of speed, that's even worse.

>>892767

None of them.

>>892762

>A type system that can't verify a list data type though is weak bullshit.

Type safety isn't memory safety. Unsafe rust is guaranteed type safe, but not guaranteed memory safe.

0/10 apply yourself

>>892774

>Type safety isn't memory safety

Nope, but a smart type system can ensure memory safety.

> Unsafe rust is guaranteed type safe,

Well that's nice and all

>but not guaranteed memory safe.

And if the type system was not utter shit you could ensure a list was memory safe.

>>892775

>And if the type system was not utter shit you could ensure a list was memory safe.

you have no idea what you're talking about. kys

>>892776

Yea, i'm sure you know all about type systems. You are a smart one. Rust is the absolute limit of engineering and mathematics. Deciding that a list is type and memory safe is something that computer languages just cannot do. No other languages can do that.

>>892677

like what?

>>892938

Like plugging in a custom allocator just for that instance of the data type at runtime.

>>892952

Alright just add a allocator field of type alloc::allocator::Alloc to the LinkedList struct and then instead of using Box::new to allocate nodes use the alloc_one function of the allocator. This should add only a few lines of code.

What else justifies the unreasonably convoluted C++ version?

>>892963

>just add a allocator field of type alloc::allocator::Alloc to the LinkedList struct

Look these things add up. The CPP version has sort, merge, reverse, etc. Not to mention tons of extra definition info to make tracing the operation of the STL library based on compile options. The CPP version is also more optimized and has multiple ways to copy data around. Sometimes you want copies, sometimes you want references (not pointers), sometimes you want to do a memory swap, all for different cases.