/tech/ - Technology★

>>959940 (OP)

>Lisp

That's a shitty imperative language with tons of mutation and state. Try Haskell instead.

>>959941

I wanted to try Haskell but the syntax looks way too complex when I barely understand functional concepts.

SML is the most attractive one, I think. There's mercury too, if you want to go Prolog.

>>959940 (OP)

Is that image meant to be a comment on functional programmers? I don't even know where to start.

>>959941

Can't Scheme be used in a purely functional manner?

>>959955

No I just like cute girls

>>959963

I already learnt C

>>959975

>I just like cute girls

That doesn't explain the image

>>959964

>Can't Scheme be used in a purely functional manner?

I'm not OP, but not really. Scheme doesn't have any means of doing IO in a purely functional way, it doesn't even have types. It's still a wonderful language to learn and it can serve as a introduction to writing functional programs but not really for actually writing complex purely functional programs. If you are really set on a purely functional language I've heard good things about Elm and Clean as far as simplicity goes but there are quite a bit more learning materials available for Haskell. If you still want to learn Scheme the book attached is the standard as well as these lectures:

http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/

Alternatively there is the new version of SICP which is supposed to be much easier to learn and more pragmatic, I sadly don't have a pdf copy of this one you can get it online for free here: http://htdp.org/

>>959943

> the syntax looks way too complex

The syntax is no more complicated than python that every idiot seems to understand how to use

>>959964

>Can't Scheme be used in a purely functional manner?

Somewhat but so can assembly.

>>959981

> I've heard good things about Elm

Elm is more limited than even go.

SICP. You can use Dr Racket to run your programs. Get the specific SICP scheme dialect plugin for it, and you're good to go.

>>959981

Htdp isn't really a "new version" of SICP, it's just inspired by it, and supposed to be easier. SICP gets pretty hard sometimes.

It seems there is no common lisp coder here at all (what a surprise /tech/ is full of larpers since around 2 years).

If you already know how to code, and want a quick rundown, then read Practical Common Lisp (PCL). If you don't, and want to take more time, then go for "A gentle introduction to symbolic computation" (I reall liked this book, it explained very well how cons cell works).

SICP is about scheme, so it's not the same. Now, maybe should you read SICP, then get to know common lisp through PCL. But SICP is an hard read compared to PCL.

You easely can switch between elisp, common lisp and scheme, if you know one of them.

After that, there is other book, like Lisp in small pieces, Let over Lambda etc...

>>959943

It's not that complex. The many operators and few parentheses do make it hell though until you understand the precedences. Lisp looks like hell too but at least it's really obvious how the expressions are grouped.

>>960189

it's not the syntax, it's the way people write it. A typical CL programmer will try to write clear code. A typical Haskell programmer will try to avoid variable names.

>>960191

Variable names are bloat.

>>960187

If it makes you feel.any better, practical common lisp is next on the list after I finish SICP. Everything I've read leads me to believe that common lisp is more practical for real world applications, and not just because of the libraries.

>>959940 (OP)

'Functional programming' means three things:

1. ML and its children. You got your variant type constructors and advanced type system and type inference. You got your homogeneously-typed lists. You got your pattern-matching. You got everything written in the language being an expression with a value. If not for #1 nobody would give a shit about FP. Even Haskell's appeal is mostly due to its ML elements.

2. masturbatory Haskell bullshit: anti-features, non-features, and category theory. Imagine if Japan's first contact with the west were with a coven of fucking witches. Japan: "woah these sea-barbarians have all kinds of amazing wisdom, knowledge, and technology -- and also they're completely degenerate nutballs! It's too bad you can't have one (ML) without the other (Haskell) :( o Mistress Pink, please teach me how to properly set up altars while sky-clad and also how your guns work."

3. "using functions as first class values" - which is how anyone ever came to speak of Lisp and FP in the same breath, even though you can't take a deep breath without inhaling a few dozen languages with first-class functions.

if you want to learn Lisp you've gotten some advice here already.

if you want to learn FP take a look at ReasonML or Elm. Probably the easiest possible starts right now. Focus on making stuff productively, and occasionally ask (here, on a code review site, in Reason/Elm fora) if you're doing it right

if you want to learn #3 FP and would prefer not to confuse that minor task with learning a new language, then your options depend on what you know. for example, if you know Perl, then Higher Order Perl is pretty good.

>>960187

There's no common lisp coder anywhere. That's why it's a meme.

>>960187

>common lisp

>functional programming

lol okay retard. common lisp is the most imperative piece of shit ever.

>>960198

ML is totally inferior to Haskell lacking basic runtime features and higher kinded types.

>>960210

Common Lisp is functions, it just doesn't enforce functionality.

Erlang is even better at this. It tries to be functional, but when something gets impractical or complicated because of the functional paradigm, they have no qualms about just abandoning it.

>>960212

s/functions/functional

My fault for being a phone poster when I know better.

>>960212

Yeah so is c++ faggot. Languages have lambda and all of the sudden think they are a functional language.

>>960188

>Notepad++

Come on man, I appreciate the help but do you really think anyone here uses Windows?

>>960198

I want to learn FP but ReasonML and Elm are web languages I can't come up with a practical use for.

>>960178

>Elm is more limited than even go.

You didn't quote the whole thing I said "I've heard good things about Elm and Clean as far as simplicity goes" also GO is a wonderful language so long as you're in a use case which can handle GC stops (most applications) Elm in my mind is useful for two things teaching FP and maybe writing UIs.

>>960186

>Htdp isn't really a "new version" of SICP, it's just inspired by it, and supposed to be easier. SICP gets pretty hard sometimes.

This is true, I did SICP spread out over the span of a year including a summer as a NEET. I honestly think anyone can do it with enough time and tenacity but that's not something must people are at the liberty to have which is why I suggested it. Not sure why I used the term new version, perhaps to give it creditability so that new folks don't get overwhelmed by SICP and think SICP is the thing everyone starts with.

>>960187

This is good advice, because Common Lisp is a more complex standard than Scheme I think I would suggest learning Scheme first, but not through SICP. Htpd I think is the natural choice for a novice in todays age.

>>960198

Functional programming seems more like a style to me and a gradient of languages which make that style necessary or convenient. So in Scheme you primarily work with recursion with, anonymous functions, and with map/filter to write your programs, state is only introduced when "necessary" do to the flaws of the language in a rather poorly isolated way.

>>960216

I don't think you're going to find something purely functional, general purpose, well documented, & easy to learn. The best you're going to be able to do is compromise. Elixer might be a possibility, Scheme might be one, Haskell might be one, ELM might be another, maybe even a Ocaml or F# (but probably not).

>>960214

Holy shit you're retarded. You obviously know Jack shit about Erlang nor C++

Did you actually want resources or were you just trying to initiate discussion?

>>960187

> read Practical Common Lisp (PCL)

Until you come to the part where you need to install the "Foo" library and want to strangle either the author of the book or the author of the library. This has to be the most un-searchable name for a programming library of all time. And the book is not really that great, it glosses over important things and wastes too much time on trivial things.

>>960188

> CLISP

Is there a reason to recommend Good Goy Lisp over SBCL these days?

>>960210

Common Lisp is as functional as its implementation makes it. Since tail recursion is not mandated by the standard you cannot rely on it being there (even though it usually is), leading people to favour imperative programming.

>>960245

>You obviously know Jack shit about Erlang nor C++

Nice argument fuck-wit.

>>960248

> Since tail recursion is not mandated by the standard you cannot

Retarded. A so called "functional language" where you cant even rely or recursion being implemented correctly.

>>960249

Tail recursion is an optimization detail, it's not necessary for the logic of recursion.

>>960255

You sure as fuck won't be writing functional programs if your stack is blown every time you calculate the 200th Fibonacci number. Brain fuck could be used for weather prediction on a super computer. It's just an implementation detail after all.

>>960258

Recursive programming should be avoided anyway as tail call optimization is rarely present in languages and implementations. Javascript, for example.

>>960211

He was talking about ML derivatives knucklehead

>>960266

The ML derivatives are even worse you retard.

>>960264

Ah yes NON FUNCTIONAL LANGUAGES lack FUNCTIONAL LANGUAGE FEATURES. Wow that sure is confusing.

>>960258

Your programming skills suck if you blow your stack with trivial recursive processes. I'll forgive you if your processes beyond the trivial.

>>960267

>The ML derivatives are even worse you retard.

Still better than anything I've ever seen Haskell doing. Some ML derivatives are actually used in code bases I've actually seen in the real fucking world, asshat.

>>960270

Do you even have a basic understanding of how Stack Frames are implemented in almost any programming language? Do you even fucking understand what Tail Call Optimization is? ANY recursive code will cause a stack overflow if not properly optimized. Now go fuck off stupid ass LARPing son of a bitch.

>>960264

Yes because Javashit is the arbiter of what good optimized code looks like.

Did you even read what you posted?

>>960244

Guess I'll just grit my teeth and go for Haskell then.

>>960246

Both, though the discussion was secondary.

>>960277

If you actually want to get a job learn OCaml

>>960275

It's more rare and limited across languages than you think. The better CS schools teach you to avoid it.

>>960281

Getting a job isn't really a concern for me

>>960271

how about handling all of facebooks spam prevention is that good enough for you? trillions of events per day.

>>960270

Literally all recursion blows the stack in these shitty non functional languages unless you implement some retarded trampoline system like on the JVM.

>>960277

it's for the best. I would recommend "the haskell book".

>>960275

this

>>960281

only in eastern europe where you make 2 euro an hour

>>960283

for jobs its everywhere, in actual CS its nowhere.

>>960285

Depends what job. I'd try to do better than something that a streetshitter could apply for. E.g. you won't find that kind of deeply recursive call in the kernel.

>>960286

>you won't find that kind of deeply recursive call in the kernel.

Because it's written in c the most bug prone language ever made. Where one trivial memory error causes remote code execution.

>I'd try to do better than something that a streetshitter could apply for.

Ah you mean like C and Java.

>>959975

*tranny

>>960315

> Тhat thing

> Feminine

Anon, it's $CURRENT_YEAR, it's OK to admit that you are into Jewish trannies.

>>960277

Good choice. ML beats the shit out of Lisp, and Haskell has the most learning resources of the family. You also get laziness, enforced purity, and some applied category theory.

>>959941

Actually, it's a multiparadigm language. You can write in purely functional style, or purely imperative style, or mix and match as you prefer.

>>960246

s/discussion/shitflinging show/

ftfy

>>960315

>If you're at the point where you think anyone remotely feminine is a tranny

...then you've probably lurked teh 'chans for too long. It's true more often than not around here.

>>959943

>I wanted to try Haskell but the syntax looks way too complex

The syntax is fairly simple. I think you are confused about what some functions do rather than the syntax.

Most concepts are easy to understand, but everyone gives poor explanations which makes them seem hard.

>>960248

>SBCL

I learned lisp back around in 2007, so I haven't heard of it.

>>960403

It seems hard because everyone keeps trying to explain it in terms of maths.

>>960409

anon, I was using SBCL in 2001. You never heard of SBCL because you didn't join #lisp on Freenode.

>>960369

>Dodie is literally the height of femininity

How many children does she have?

>>960198

Don't be so hard on Haskell.

Monads and Cat theory is necessary to make sure all that type stuff from ML is actually composable and semantically correct. And when it comes to modelling parallel programming, you can't compare the power of Haskell monadic based IO to Ocaml's ref pointers.

Also there is the GHC, Haskell code is already faster than Java on most cases. And for a lot of parallel software Haskell is already on C-like levels of performance.

>>960490

15

>>960392

Just like c++, d, javascript, every other shitty languages that claims to be multi paradigm. AKA it's not.

>>960501

>garbage collected language

>as fast as C

Worst forced meme ever. Only true for programs almost not using the heap.

>>960556

Actually moving garbage collectors are faster for programs that actually do use the heap. Tiny shit programs everyone runs barely use any memory. When you get a server with a half terabyte heap a moving garbage collector becomes incredibly beneficial. Even without the fact that c programs leak like a bitch the fact that you need pointer stability is very damaging. There is a reason all the big data processing enterprise applications use java.

>>960563

>Actually moving garbage collectors are faster for programs that actually do use the heap. Tiny shit programs everyone runs barely use any memory.

That's obviously wrong, unless you mean that the overhead matters more for tiny programs.

>When you get a server with a half terabyte heap a moving garbage collector becomes incredibly beneficial.

Over what? GC performance is always a race between throughput and latency; you'll always get fucked somewhere.

>Even without the fact that c programs leak like a bitch

C programs don't leak, bad programmers create leaks. Very bad programmers when you see that tools like lsan or even valgrind makes it very easy to resolve.

>the fact that you need pointer stability is very damaging.

What do you mean?

>There is a reason all the big data processing enterprise applications use java.

The same reason python or javascript are used almost everywhere now, including in some performance sensitive contexts. Big data is the most entreprise buzzword there exist, of course they'll use a programming language as industry memed to implement it. The meme "Java is as fast as C" is the one that started the joke, too.

>>960563

Garbage collection is absurdly inefficient.

>There is a reason all the big data processing enterprise applications use java

Because they massively outsource development and rely on Java to keep the poo in the loo. It's incredibly slow and bloated but hardware is cheap and developers are expensive.

>>960570

>That's obviously wrong

...

>What do you mean?

>>960571

You have have no idea what I even said and are now throwing shit all over the walls.

>>960572

I'm fully aware you're a moron and are posting your "c programs leak like a bitch" tears via several hundred million lines of C.

>>960501

>And for a lot of parallel software Haskell is already on C-like levels of performance.

If it's having to expand out over more cores, it isn't as fast as that program that doesn't, it's only taking more resources to get to the same end goal, which is a fancy way of saying that it's slower.

>>960577

Ah the c fag is triggered by the fact that his language is a hand cannon responsible for a metric fuck ton of trivial errors made daily by even expert programmers with decades of experience. I just love when someone appends 2 strings together incorrectly leading to remote code execution.

>>960579

Except when c leaks memory everywhere and fragments the heap leading to slower performance with actually large amounts of data.

>>960572

You can answer, you know. As much tuned as your curry magic (incredibly complex bloat, I'm sure you like this) is, it's still not used where performance matters. No, Big data isn't actually trying to be performant, it's trying to exploit naïve parallelism because it's easier than to write a clever algorithms.

Just dumb entreprise big wigs discovering HPC and creating a bad meme.

>>960584

PHP is a memory-safe language yet is responsible for far greater damage. Let that sink in, webdev.

>>960585

>hurr durr c can't compete and really the fucked up failures of c are a good thing.

Go back to microcontrolers faggot where you're 2kb of memory matters.

>>960587

That's what evaling strings does. I fucking hate PHP. Probably as much as I hate c.

>>960584

>Except when c leaks memory everywhere

Nice opinion, fagtron.

>and fragments the heap leading

Everyone knows about pooling, retard. Well, everyone not using a toy language where allocation is done by mommy (for a price).

>>960589

>resources are here to be wasted

Thanks to your kind, normalcattle is rocking smartphones with 8GB of RAM and more cores than my laptop.

Also, GC doesn't only have a cost in RAM, but in CPU, which is never free.

>>960584

C programs _can_ have vulnerabilities. The JVM has tons of them, and you can't do anything about it.

>>960591

oy vey goy just stop using malloc that will solve all the shitty problems with c!

>>960591

> but in CPU, which is never free.

<What is a concurrent collector

>The JVM has tons of them, and you can't do anything about it.

Yes this is the problem with programs written in C.

>>960595

If you're having fragmentation problems in C you're doing it wrong.

>>960595

>oy vey goy just stop using malloc

Or just use a good malloc like jemalloc.

>that will solve all the shitty problems with c!

Get your meds, nobody's interested in your persecution complex. Nobody who has written C will say that it's perfect: it has big flaws (no real array support, no generics, stdint isn't used by the stdlib, unicode handling is shitty) but it's simply not as bad as the others where resources are wasted because they're here and programmers treated like poos who need their hands held. I won't even talk of the bloat (incurring complexity, bugs, unease of porting and other problems) of the other languages' runtime (inb4 gcc is a big fat shit, tcc and pcc exist).

>>960598

>>960600

You c larpers who i'm sure are either students or have never developed anything sure have amazing opinions of the language and its capabilities found by literally no experts.

>>960601

I've been writing C/C++ for 25 years, qt.

>>960602

Ah then you must agree with all the other c experts that c is prone to buggy shit.

>>960605

Not that much more than anything else. Like, if I'm writing something super delicate like writing cmsg goo or netlink messages I'm not going to be magically saved from logic errors in all that mess by switching to rust. There's a pretty thin set of errors it promises to improve and those tend to be rare. Not that I wouldn't like to have a better C, I just don't think it exists yet.

>>960601

>resorts to name calling

>no argument since the start of the shit flinging

Gradually, I started to hate them.

>>960609

>have index error in most languages

<program crashes

>have index error in c

<remote code execution takes over computer

The only thing worse than c is those retarded languages that execute strings as a matter of course.

>>960611

There was no argument to respond to. Faggot.

>>960612

And in all these "wonderful" languages, it's just a branch for each access, just to check that you don't overflow. I'm sure your disgusting kind will be the perfect market for autonomous cars.

>>960613

That's why you don't make retarded claims like "c programs leak", faggot. Here's a C program that doesn't leak:

int main(void)
{
    return 0;
}

Anyway, who cares about you retarded toddlers whining about C while never accomplishing anything that isn't pure garbage in your babysitting languages?

>>960612

Exploitable issues like that are rare enough today with 64 bit ASLR that language-specific issues are no longer the main concern, at least in my field. Again, I'd love to be rid of them entirely but there is currently no alternative.

>>960616

>ASL means memory errors are ok

LOL

>>960615

>Here's a C program that doesn't leak

oy vey o program that does less than hello world does not leak

> that isn't pure garbage

you mean c?

>>960619

*ASLR

>>960619

If you're not aware, it cut the number of exploitable pointer errors down to such a low number that language-neutral coding errors have become the biggest threat. I do a lot of packet surgery and those pointers remain entirely in bounds while still potentially opening up all sorts of security holes.

>>960623

ASLR is great and its an amazing piece of technology. It also is a far cry from fixing remote code execution vulnerabilities.

>>960623

ASLR does not reduce the number of exploitable errors it simply makes the errors that exist less likely to succeed consistently.

>>960616

Any little information leak and your ASLR ends up useless.

>>960639

Yeah, but there's often not enough space to upload complex methods that rely on the branch target buffer and a server isn't running a web browser. In practice, it's reduced the number that are exploitable.

>>959964

functional programming feels quite natural in lisp.

>>960187

this is the correct answer. start with Practical Common Lisp and/or Littler Schemer. read SICP after those. in my opinion, scheme is far better choice for learning than Common Lisp or Haskell (there aren't any unnecessary details and everything is clear) But do use Common Lisp or Clojure for your actual work.

>>960188

>stay away from Emacs. It's a masochism machine

pls stop pajeet. GNU Emacs is very comfy and powerful editor (it's par with vim/neovim)

>>960210

>>960520

But Common Lisp is functional, too. you can write 100% functional code with it, if you so wish. you can expand Common Lisp to include any paradigm (future or past) using Lisp's advanced macro/meta-programming capabilities that are build into the language.

>>960281

you can perhaps get a job with F# but not with OCaml

>>960623

pls read this --> >>960630 and go fix your code ASAP!!!

>GNU Emacs is very comfy

But it's not Lisp. It's a monstrosity that has evaluating Lisp code as one of its many widgets along with the kitchen sink. Back when I first searched Lisp it took me forever to find an interpreter that wasn't glued to this abomination. Emacs is to Lisp what a leech is to an otherwise healthy person. Emacs is not Lisp. It's something that stands between you and Lisp. You wanna learn Lisp? Get an interpreter like SBCL or CLisp . You wanna be a masochist and waste your time learning something that has no relation to Lisp? Get Emacs. God, I hope the search results have improved and newbs don't have to go trough the pain I did.

>>960726

>you can write 100% functional code with it

Around 95 % of code is functional, the there's the IO and variable sections, which are not. While Lisp is functional as a paradigm, it's not a "pure" functional language like Haskell or ML. You can make wrappers and macros around effectfull code and what-not, but you'd need to implement a strict type system for the thing to work properly.

>>960734

Isn't ML impure too?

>>960724

You don't need to rely on the branch target buffer tbh. Any leak and you go ROP like never before

>>960779

Yeah. Sorry.

I was thinking of Clean. It uses uniqueness types instead of monads for doing side-effects.

>>960850

It's not that easy anymore.

>>960853

muh linear types

muh use exactly once semantics

>>960912

Presumably it's easier to optimize. There's not many good ways to put side-effects in "pure" functional programing.

Monads have clunky syntax. I once made a syntax transformer in lisp that turned "pseudo-imperative" code into monadic code. A more advanced version of do notation. You had two "functions":

"unwrap" that had type :: M x -> x

It was supposed to be "effecful" .

"wrap" that had type x -> M x

The catch is "wrap" was actually a macro, that transformed code containing "unwrap" into code using ">>=" monad operations. "Unwrap" wasn't actually an effect-full function, it was only a "token" directing the wrap macro. So you couldn't have a "naked" unwrap.

Ie.

wrap ( f ( unwrap m) (unwrap n))

would translate roughly to

do m1<- m

n1<-n

return (f m1 n1)

The point is I'd like lisp syntax in the Haskell language. There's nothing preventing a language from adopting such a syntax, thus gaining lisp-like metaprograming capabilities.

>>960912

in Mercury it's just a gimmick for I/O. Clean may be the same. but in ATS you can create your own linear types and work with them naturally. This isn't a gimmick or a meme: it's the feature that allows ATS to not absolutely require a GC, and it's a natural fit for file handles, database handles, and 'pure' uses of mutation.

>>960927

hell I just realized that you could recreate mercury's io type in ATS, with a stdlib that restricts I/O to that. bam, you got your pure functional language, and you get it with tools provided by the language instead of from deus ex compiler writer.

although, I wonder about optimization. Mercury/Clean probably don't actually pass the 'state of the world' around.

>>960922

>I'd like lisp syntax in the Haskell language

gross. http://shenlanguage.org/

>>960726

>CL is functional

then so are 99% of languages that exist.

>>960872

Well. In theory you're right, but the different protections that allow us to protect our programs from advanced ROP attacks also have a huge overhead on performance. So in reality, these protections are not used and the programs stay vulnerable.

>>960927

Ah yes ATS the language you cant actually execute.

>>960945

#include "share/atspre_staload.hats"

datavtype io = io

fun ioprint(x: string, io: io): io = (print_string(x); io)

fun iomain(io0: io): io =
	let
		val io1 = ioprint("Hello, ", io0)
		val io2 = ioprint("world!\n", io1)
	in
		io2
	end

implement main0() = () where { val- ~io() = iomain(io()) }

#include "share/atspre_staload.hats"

datavtype io = io

fun ioprint(x: string, io: !io): void = print_string(x)

fun iomain(io: !io): void = (
	ioprint("Hello, ", io);
	ioprint("world!\n", io);
)

implement main0() = () where {
	val world = io()
	val+ () = iomain(world)
	val- ~io() = world
}

>>960964

If by execute you mean ran the type checker.

>>960967

I mean I compiled both and ran the resulting executable and it printed text out. ATS is this: http://ats-lang.org/

>>960968

>ATS is feature-rich (like C++).

>like c++

Dropped

>>960932

What specifically bothers you about Common Lisp so much? is it the LOOP macro?

>>960987

CL is OK.

it's just not special at all in its support for FP

you can take any CL book (barring macro-heavy stuff like Let Over Lambda) and follow along in pretty much any other language

>>959940 (OP)

>>959943

The Easiest resource to get started with Haskell: Learn You a Haskell for Great Good http://learnyouahaskell.com/chapters

>>960726

>>960281

Jane Street Capital uses OCaml

>>959940 (OP)

>5.81mb

>>962569

I prefer dodie in HD