Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-8081-

Thinking in Lisp

Name: Anonymous 2012-02-04 20:31

SQL, Lisp, and Haskell are the only programming languages that I've seen where one spends more time thinking than typing.
That's because it takes forever to think of the solution in Lisp and Haskell as opposed to a decent language. Faggot lispers will spend most of their time figuring out how best to abuse recursion because they think it makes them leet programmers or some shit.

Name: Anonymous 2012-02-04 20:34

it's easier for me to think of solutions in lisp then say C/C variants and java

Even easier in Perl for me

however I fail at thinking recursively no matter the language, any tips?

also since when was SQL a programming language?

Name: Anonymous 2012-02-04 20:35

>>2
You don't want to abuse recursion.

Name: Anonymous 2012-02-04 20:39

>>4
You don't want to abuse recursion.

Name: Anonymous 2012-02-04 20:51

>>4
You don't want to abuse >>3

Name: Anonymous 2012-02-04 21:00

>>1
Nope. It's much easier for me to write Lisp code than Java or most other languages. Once I mostly know what I want to write, I just write it. With other more popular high-level languages, I tend to write masturbatory AbstractFactoryFactories filler instead of just writing what I want, because the language forces me to fit my idea to their way of thinking, instead of allowing me to express the idea as directly and as clearly as possible.

Faggot lispers will spend most of their time figuring out how best to abuse recursion because they think it makes them leet programmers or some shit.
Don't confuse Lisp with Scheme. Sure you can abuse TCO all day long, but most of the time I write in CL, which has decent looping constructs (doesn't mean I don't prefer to write in a declarative manner where possible, but I'm not going to go out of my way to write in a functional manner if what I want is better acomplished some otherway), I don't go out of my way to use TCO.

Name: Anonymous 2012-02-04 21:27

>>6
I think YHBT and IHBT.  But yes, indeed, Lisp is just a way of thinking about syntax and exposing it bare to the user, and even letting the user write his own (regardless of the surface syntax, of course; sweet-expressions may still constitute a basis for a Lisp no matter what the faggot haters say).  In Lisp, when you notice you're writing boilerplate, you just write a macro (or a bunch of them to get rid of it).  In other languages, you're utterly doomed.

Oh yeah, and recursion is just a way of reducing all loops to a single type of construct, from the computer's point of view.  A proper Lisp user would immediately pull out his own loop macro implementation as soon as he notices one isn't available, or just use map if it fits the bill.

Name: Anonymous 2012-02-04 21:30

>>6
So then you disagree with the quote that you spend more time thinking than writing? Because you claim you can just write.

Name: Anonymous 2012-02-04 21:36

I was going to learn lisp, but I couldn't decide on scheme vs clisp

Name: Anonymous 2012-02-04 21:43

>>9
Scheme is small and clean and you write the way you want.
Common Lisp is huge and bloated and gives you less freedom

Name: Anonymous 2012-02-04 21:52

>>8
Not exactly, I sometimes spend more time thinking than writing code, but I end up spending much less time doing the sum of both than I would in another language. It's not like you don't have to think what your program has to do in another language, well, unless you got some ``architect'' doing all the thinking for you and he just tasks you to code some specific module, however regardless of that, someone has to do the thinking - in Lisp, you tend to do be able to just translate your thought more directly into code than in other languages.
>>9
Learn both. I mostly write Common Lisp these days because it lets you do a lot more things portably (across many implementations and OSes) than Scheme and overall has many features by default as well as lots of user libraries which just work with most implementations. Scheme is easy to learn either if you already know CL or if you're starting from scratch (although learning CL after Scheme might be harder for some if they dislike the Lisp-n style or other things CL does different from Scheme). Scheme has a small standard document that you can just read in an evening, although of course, if you actually want to understand what the language is all about, you should read SICP and the Lambda Papers.

Name: Anonymous 2012-02-04 22:05

>>1
being fair (and don't forget, i hate haskell) you almost never write directly recursive functions, you use High order functions (foldr,filter,map,scanl)

if i had to put in number, i would say that 5-10% of my code is pure recursive, the rest is higher order aplication.

Name: Anonymous 2012-02-05 3:40

>>11
I'm calling bullshit because people in general are able to come up with solutions quicker in procedural languages. It's just how we think.

There are no macros you can create in lisp that has no simple equivalent in C.

Name: Anonymous 2012-02-05 3:46

In C:

int fact(int n) {
  return(n<2 ? 1 : n*fact(n-1));
}
In Lisp:

(defun (fact n)
  (if (< n 2)
    1
    (* n (fact (- n 1)))))

Look at all those parenthesis!

In all seriousness C is more elegant than any lisp dialect.

Name: Anonymous 2012-02-05 5:17

>>13
It's how people who more background in imperative programming think. I've heard that people who started out with functional programming have trouble with imperative, because they can't get past the notion of mutable state. n = n + 1? But that's false for all integers, n!

Name: Anonymous 2012-02-05 5:50

>>13
I can write C faster for certain trivial imperative things, but not for more complex problems, some things that could take me weeks to do in C I can do in days in Lisp. You can think what you want, I don't care, it's a reality for me and it matters not to me if you actually believe me or not - it won't change anything about how I write programs.

>>14
And yet none of those parens have to be typed, you use a structural editor instead. Also your code is broken, CL's defun is not equivalent with Scheme's define. Also both your CL and C implementation is liable to stack overflow, neither is tail-recursive (of course, if you don't want to use tail-recursion, you don't have to, there's countless ways of writing such trivial functions).

>>15
Sometimes imperative makes sense, other times declarative and functional make more sense. Personally, I find declarative and functional work best for complex high-level problems, while imperative works best for low-level problems. I have no problem writing some quick-and-dirty C when it makes sense, then writing some declarative or functional CL. Better use the tool more suited for the job.

Name: Anonymous 2012-02-05 11:20

>>13
There are no macros you can create in lisp that has no simple equivalent in C.
Then let's see you implement do (http://www.lispworks.com/documentation/lw50/CLHS/Body/m_do_do.htm) in C. And while you're at it, go ahead and implement once-only to avoid any variable capture problems:

(defmacro once-only ((&rest names) &body body)
  (let ((gensyms (loop for n in names collect (gensym))))
    `(let (,@(loop for g in gensyms collect `(,g (gensym))))
      `(let (,,@(loop for g in gensyms for n in names collect ``(,,g ,,n)))
        ,(let (,@(loop for n in names for g in gensyms collect `(,n ,g)))
           ,@body)))))

Name: Anonymous 2012-02-05 11:24

>>14
If you think parens are ugly, write your own indentation-based surface syntax to sexp compiler.  If you think CL is an ugly manbeast and Scheme is useless, write your own Lisp.  If you think recursion is unreadable, use a loop macro or higher-order function.

Name: Anonymous 2012-02-05 11:50

>>17
I'm intrigued. What does this macro do?

Name: Anonymous 2012-02-05 12:01

>>19
When a macro expansion contains an expression passed to the macro, you usually only want it to be evaluated once. If the expansion contains (f x x), for example, where x is (g y), instead of expanding to (f (g y) (g y)), you need (let ((x (g y))) (f x x)). The problem with that is that the name x might already be used, so the new binding will shadow the old one and break your code.

The usual way to get around this is to generated a unique name for the temporary variable using gensym, so instead of

(defmacro m (x)
  `(... x ... x ...))

you would write

(defmacro m (x)
  (let ((y (gensym)))
    `(let ((,y ,x))
       (... ,y ... ,y ...))))

That's a lot of boilerplate, and repeated code is usually a bad thing, so once-only lets you do this:

(defmacro m (x)
  (once-only (x)
    `(... x ... x ...)))

Name: Anonymous 2012-02-05 12:03

>>20
Shit, x should be ,x in the first and third examples.

Name: not >>17 2012-02-05 12:08

>>19
It's a macro which is usually used when writing code generating code (that is, other macros). It generates code that bins some symbols of your choosing to only be evaluated once (this works by generating a let form and doing a very clever form of substition of the bound variables with gensyms), without it, if your macro was passed some state-changing code, or context-dependent code (such as by dynamic bindings and whatnot), it could end up being evaluated more than once and generate the wrong code.
I'll try to give a C example if you're not familiar with Lisp, you have a macro which takes one argument, this argument is supposed to be something that can be evaluated, but cannot be expected to always return the same value, such as i++, yet you only want to use the value of that expression once, not subtitute a i++ in each place you've used that macro argument. You can fix this in C by just creating a local variable, assigning your i++ to it and hoping the macro doesn't use your local variable in special ways (such as some symbol conflict) - it's not really possible to do it right with just text substition, you'd need access to the AST to even have a chance of getting it ``right'' and not just a ``very low chance of failure''.

Name: Anonymous 2012-02-05 13:03

How dare the programmer have to think a few more minutes and make a good algorithm that isn't filled with bugs and shitty code

Name: Anonymous 2012-02-05 15:06

>>16
Knock it off. Look at the return type in that C code. It's an integer. It's not designed to take parameters large enough to cause a stack overflow. Of course intentionally giving it values it's not designed for won't work.

>>15
n = n + 1? But that's false for all integers, n!
Only an idiot would be bothered by this. All it takes is understanding that = isn't equality.

Of course people who start off with functional programming will be able to come up with solutions faster in functional languages, but people in general are better with imperative. It's how we think on a day to day basis.

Name: Anonymous 2012-02-05 16:47

people in general are better with imperative. It's how we think on a day to day basis.

[citation needed]

Name: Anonymous 2012-02-05 17:08

but people in general are better with imperative.
I don't think that's true, not in any kind of a priori sense.

It's how we think on a day to day basis.
This certainly isn't true. Our thought is not even remotely well-represented by any common programming paradigm.

Name: Anonymous 2012-02-05 17:51

>>24
Ackermann's function returns an integer too.

Name: Anonymous 2012-02-05 19:05

>>20-22
Thanks, that's plenty.

There's something I never understood, though; in a decent Lisp, should defmacro top-level forms be evaluated one at a time (and injected immediately into the macro environment), such that mutual macro dependency is impossible (e.g. macro abc uses macro xyz and the other way around)?  Doing it any other way just seems like too much pain, if not impossible.  (yeah I'm the fucktard who wants to write a Lisp variant, shoot me)

Name: Anonymous 2012-02-05 20:26

>>24
I'd argue the common man thinks closer to Logic clauses like Prolog than Imperative. But even that isn't a good fit.

All it takes is understanding that = isn't equality.
lol!

Name: Anonymous 2012-02-05 21:09

>>29
What's so funny about that you idiot?

Name: Anonymous 2012-02-05 21:20

>>30
All it takes is understanding that (+ a b) is (a + b).
And all kinds of “programmers” don't understand this.

Name: Anonymous 2012-02-05 21:25

>>31
Perhaps idiots who are bothered by this.

Name: Anonymous 2012-02-05 21:29

>>31-32
Usually Lisp is fucking shit because of its surface syntax.

Name: Anonymous 2012-02-05 21:44

>>33
Lisp is shit.
Or perhaps you're an idiot who is bothered by this.

Name: Anonymous 2012-02-05 21:48

リ
ス
プ
。

Name: Anonymous 2012-02-05 21:56

>>33
Really, I didn't want to offend you.
My point here is the observation that people resist to changes because of such insignificant issues.

Nor “mutation” neither “syntax” are challenges to understanding. At least not for mine.

Name: Anonymous 2012-02-05 22:16

thinking in lisp is kind of like thinking in lisp

Name: Anonymous 2012-02-06 0:44

>>34
You are the idiot because you fail to realize that most people find its surface syntax uncomfortable if not unbearable, even after they've "gone past it" and understood the huge benefits of exposing the AST to the programmer (in this case, as a very regular syntax).  And before you bring it up, no, using a special text editor to fix a language's woes simply doesn't cut it.

>>36
Well aren't you quite the gentleman.  A polite post like yours deserves a polite reply.  Yes, people do resist to changes, which you argue to be insignificant, when these changes involve taking away things that they are comfortable with, such as using mutability (or at least some convincing imitation of it) when doing things like x[i] ^= a[i] + b[i] + c; as it often happens in cryptography.  A language should not imprison the programmer into an immutable prison, but rather encourage purely functional style while still allowing you to escape from it when it makes sense (such as for overwriting local variables inside an otherwise pure function).  As a short parenthesis (pun intended), this lack of freedom is one of the reasons I strongly dislike statically typed languages, particularly Haskell.  But that's just me.

As for syntax, well, I strongly believe that a different surface syntax for Lisp would do wonders, provided that it would have a simple and clear mapping to S-expressions.  I find S-expressions very unaesthetic, even to the point that they hinder the reading of the code that they represent.  You might be one of those gifted (perhaps misguided) souls who think they have no issues reading S-expressions directly.  That's alright, as long as you don't tell me (and every other person who agrees with me) that my issue with Lisp's de facto surface syntax is insignificant.

Name: Anonymous 2012-02-06 0:57

If it's lisp, it's shit.

Name: Anonymous 2012-02-06 2:55

>>38
If it doesn't follow single assignment paradigm, it's shitkind of hard to prove correctness, and parallelize.

Name: Anonymous 2012-02-06 3:43

(defun >>41 ()
  (>>42)
  (print "dubz"))

Name: Anonymous 2012-02-06 3:43

(defun >>42 ()
  (>>43)
  (print "functional"))

Name: Anonymous 2012-02-06 3:43

(defun >>43 ()
  (>>44)
  (print "these"))

Name: Anonymous 2012-02-06 3:44

(defun >>44 ()
  (print "check"))

Name: Anonymous 2012-02-06 3:46

(>>41)

Name: Anonymous 2012-02-06 3:58

>>41-45

Why is this considered functional when you can do the same thing in any language?

Name: Anonymous 2012-02-06 4:02

>>46
Actually, contrary to popular belief, Lisp is not purely functional. What gives people boners about Lisp is macros.

Name: Anonymous 2012-02-06 4:51

>>40
Single assignment is fucking awful, and if you can't write a compiler that deals with non-SSA and transforms it to SSA, I'm going to have to revoke your Lisp license.

Name: Anonymous 2012-02-06 5:14

>>48
why is it awful?

and for converting it, I guess this could work:

int f(int n) {
  int a = g(...);
  if(n < 3) a = h(...); // Note the wasted computation of g.
  ...code using a...
}
-->>
int f(int n) {
  int a = g(...);
  if(n < 3) {
     int a2 = f(...); // g is still wasted, but at least is looks ugly, encouraging you to write it like the following instead:
     ...duplicated code to use a2 instead...
  } else {
    ...code using a...
  }
}
// do this bro:
int f(int n) {
  int a;
  if(n < 3) {
    a = f(...);
  } else {
    a = g(...);
  }
  ...code using a...
}

Name: >>49 2012-02-06 5:17

the calls to f(...) should've been calls to h(...).

Name: Anonymous 2012-02-06 5:21

>>49

oh wait, this would be a better conversion:


int f(int n) {
  int a = g(...);
  int a2;
  if(n < 3) {
    a2 = f(...)
  } else {
    a2 = a;
  }
  ...code using a2...
}

But if g is a pure function, then this is wasteful code in the case that n < 3. Shame on you, making such unnecessary calculations.

Name: Anonymous 2012-02-06 5:32

>>38
I understand that people may have (usually have) hard time when reading s-exprs. And I agree that people must choose whatever is easier to understand, even C++¹, if you're coming from a imperative background. But I don't think that Lisp is that hard to understand.

People rejecting functional programming because of personal style or aesthetics just deserve every bug and shame that may arise when going on vacancy, or when Apollo 1 burnt, or when Therac-25 overdosed patients or when their billion-dollar jets crashed.

¹ Before learning C++ I tought it was the best language, because of its wide usage. Now I just think that people are dumb.

>>40,48
Implicit parallelization is great. But OpenMP is there for those you know who.

Name: Anonymous 2012-02-06 12:32

>>52
What I am saying is that Lisp is not necessarily S-exprs.  Lisp is a certain way of doing things, among which homoiconicity and macros

Name: Anonymous 2012-02-06 12:39

>>38
I find S-expressions very unaesthetic, even to the point that they hinder the reading of the code that they represent.
Personal tastes. I find XML very unaesthetic, but S-Exp's are heaven to read, if properly indented (such as by using Emacs).
Other languages can also become much harder to read the more complexity you add to your expression, yet this almost never happens with Lisp, unless you (ab)use a bit too many reader macros. Before I learned Lisp, I used to just think it's a bit weird, but after spending a week coding in it (and using the right tools to do so), it becomes very natural.

>>28
There's something I never understood, though; in a decent Lisp, should defmacro top-level forms be evaluated one at a time (and injected immediately into the macro environment), such that mutual macro dependency is impossible (e.g. macro abc uses macro xyz and the other way around)?  Doing it any other way just seems like too much pain, if not impossible.  (yeah I'm the fucktard who wants to write a Lisp variant, shoot me)

It's how CL does it. defmacro tends to be a macro which expands to an eval-when form which then sets a function in the global macro environment. Things are a bit more trickier with local macros.

In practice, you'll write code which expands to other macros, which are of course expanded as well, that way you can have mutually recursive macros (in the generated code). However, what you're asking for is a macro used at macro-expansion time which is then used as a macro that calls the initial macro at macroexpansion time, and so on. The problem with this is that you need to compile one macro, but to compile it, you need to be able to fully expand its body, which you won't be able to do because the other macro function referenced in your macro's body needs to be compiled as well, and yet to compile it, you need a compiled version of your original macro (that is, to compile A you need B to be compiled, but to compile B, you need A to be compiled, thus it doesn't make too much sense).

Related:
http://www.lispworks.com/documentation/HyperSpec/Body/m_defmac.htm
http://www.lispworks.com/documentation/lw51/CLHS/Body/03_bca.htm
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/73a48ff3fb098931/

Name: Anonymous 2012-02-06 12:42

Haskell is the only programming language that I've seen where one spends more time statically typing than thinking.

Name: Anonymous 2012-02-06 12:42

>>1
If you weren't such an idiot and had minimum english skills you'd know that what that sentence means is that LISP is so easy to code that after you reach a solution for a given problem implementig is pretty much straight forward and fast.

Name: Anonymous 2012-02-06 13:00

>>49
U MENA if(n < 3) a = h(...); // Note that g(...) probably has side-effects since this is C
Another bullshit strawman argument that assumes C programmers need to have the compiler wipe their asses for them. Are you the same retard who assumed functional programmers are all idiots who confuse equality and assignment (>>15)? If g() is declared with extensions like __attribute__((pure)) or #pragma pure g the compiler should be able to optimize it away even without single assignment. If someone wants to call a pure function whose return value isn't used, either the compiler can figure it out by looking at the definition or the programmer can rewrite the code so it's only called once. No single assignment faggotry needed.

Name: previous post was incomplete 2012-02-06 13:10

>>52
What I am saying is that Lisp is not necessarily S-exprs.  Lisp is a certain way of doing things, among which homoiconicity and macros.  But the surface syntax does not have to be S-expressions and I would argue that it could still be called Lisp, as long as there is an obvious and trivial mapping to a S-expressions-based Lisp.  I agree with you, rejecting everything that Lisp brings just because of its surface syntax is a tad bit silly.  But there's more than one way to get past it, and it doesn't have to be "well just get used to it".

People rejecting functional programming
With a few exceptions, Lisp allows side effects (but indeed encourages functional programming).  Implicit parallelization does not require purely functional programming style all throughout the language; the compiler must merely prove that a particular time-consuming function is pure, regardless of whatever impure things it does inside.  Functional programming is nice, but sometimes it's cumbersome not to just write things out imperatively.  I can't imagine writing a codec or a cryptographic library in purely functional style.  It's obviously possible (by Turing equivalence), but sometimes you just want to a[i] += f(x,y,z).  Yes, 98% of my functions *are* pure functions (possibly containing impure things like multiple assignments to the same variable), and the remaining 2% will probably be I/O and the likes.

So no, I don't see the point of forcing upon the user S-expressions nor purely functional programming.

Name: Anonymous 2012-02-06 13:24


Sussman tripped along lispingly. He was on his way to meet his
lover, Abelson, for Valentine's Day. He smiled to see a snake
hopping along, carrying a snake in its mouth.

Sussman was almost from his crotch when he came across a satoric
cake, lying alone on a retarded plate. "That must be a treat
from my small bear," he said to himself, and tripped over to it.
The cake looked big, so he ate it.

It gave him the most lisplike tingling sensation in his lung.
"How unusual!" he said and continued tripping to see Abelson.

When Abelson came out to meet him, he took one look and fell
over.

"What is it?" Sussman cried swiftly.

"Your brain! And your heart!" Abelson said. "They're dyadic!
Can't you feel it?"

Sussman felt his brain and his heart. They were indeed quite
dyadic. "Oh, no!" Sussman said. "I'm a woman!" He, or rather,
she started to cry. "It must have been that satoric cake you
left for me. Did you know what it would do?"

"I didn't leave you any cake," Abelson said. "I got you a SICP.
It must have been that obolescent man who lives nearby. He acts
a little quietly, ever since he compiled a Python."

"But how can you ever love me, now that I'm a woman?" Sussman
sobbed.

"Well, I never knew how to tell you this," Abelson said
satorically, "but I actually prefer women. And I think your
brain is really indeterminate like that."

"Really?" Sussman dried her tears. Sussman kissed Abelson and it
was an entirely monadic sensation, like a huge black snake head
with retarded-looking eyes.

They spent the night having entirely monadic sex, until the cake
wore off suddenly.

Everything was rather awkward after that.

Name: Anonymous 2012-02-06 14:14

>>58
I don't know, but if 98% of my functions were functional, I should be better using a functional language, shouldn't I?

I don't want to put your opinions on s-exprs down, it's okay to dislike anything. But I think the other two benefits (homoiconicity and macros) outweight the annoyance that s-exprs are to you. Just look at how nice is to deal with JSON when Javascripting. XML and Java do not look as good choices.

And I really think that previous statement holds (about paradigm background). People only have trouble with things that they don't understand clearly. If you get that any program is some transformation f : I → O between an element in I to an element in O, imperative or functional don't matter. My problem with imperative paradigm is that there's a lot of shared state, because it's easy (and desired, to minimize memory usage). There's nothing wrong with shared state, except that it defeats the whole purpose of modules. Your functions can't be considered modules anymore, and programmers should take extra attention to the enclosing scopes. When you evolve into a big code base and a lot of coworkers, your heat-seeking missiles are “locked”, but can easily retarget your allies without your control or awareness.

Name: Anonymous 2012-02-06 14:30

>>60
I don't know, but if 98% of my functions were functional, I should be better using a functional language, shouldn't I?
Ah, but you didn't really read my post.  I said that I might still use imperative (i.e. destructive) code inside functions that turn out to actually be pure.  Purely functional languages usually don't let you do that, or let you do it but in a rather awkward way.  If you just meant functional language as in language that puts emphasis on functional programming all while still allowing side-effects, then ignore this paragraph.

I don't want to put your opinions on s-exprs down, it's okay to dislike anything. But I think the other two benefits (homoiconicity and macros) outweight the annoyance that s-exprs are to you.
Ah but you didn't read my post.  I considering the possibility of a "more comfortable" non-S-expression surface syntax that has a direct mapping to S-expressions, thereby maintaining homoiconicity and macros (especially if the source code is preprocessed into S-expressions before any parsing even begins).

My problem with imperative paradigm is that there's a lot of shared state, because it's easy (and desired, to minimize memory usage).
Well yes, shared mutable state brings in a whole new class of bugs.  This is why I said that whenever I do end up writing impure functions, it's for I/O or for managing around the purely-functional workhorses.

Name: Anonymous 2012-02-06 14:53

>>59
use [m]

Beautiful, though.

Name: Anonymous 2012-02-06 14:57

>>61
You seem like a good programmer. Too bad you don't like S-exprs, but to each his own.

Name: Anonymous 2012-02-06 14:59

2^6 GET

Name: Anonymous 2012-02-06 15:16

>>64
U MENA (GET (expt 2 6))

Name: < 2012-02-06 15:30

def (GET (dubs (check (em) ) ) )

Name: Anonymous 2012-02-06 15:42

>>61
1. Ok, I thought that you had written “pure” to denote functions with local assignments only, I didn't mention “pure”, and this paragraph is properly ignored.

2. I read your post well, I just don't think you really considered it seriously. Also, it's less appealing for newcomers if they have to install a compiler to a compiler [or interpreter, doesn't matter].

3. So you know that mutation can brings more bugs, but still prefer to take the risk. I almost mentioned it before, but I didn't want to be offensive: I think this attitude is a specific form of “hacker syndrome”, which are mostly based on unprofessional claims.

Also, I'm not a Lisp or functional evangelist, because there's still room for reasonable imperative programs. My only complaint is that people don't have discernment to choose the right tools. There's a good phrase for that [took from the fellow Eduardo Marinho, free translation]: “I don't like to say that people are dumb, in fact they're dumbified”. From my own experience, industry code bases and tools have all kinds of tricks and unclear reasonings. People still don't understand that minimalism is the best-size-fits-all. From personal experience, the most pleasing languages for me where C, Lua and Lisp, maybe Ocaml. Not that they're that good, but they deserve a place in my brain, and are the closest to the first place. Anyway, I'm designing [another] language to interoperate with C and C++ ABI, maybe with some sort of scripting [in the same language], somewhat like a cleaner “C” counterpart to Lua.

Name: Anonymous 2012-02-06 18:26

>>67
Sorry, but bad programmers will find new and ingenious ways of writing bad code regardless of how much you try to prevent them with your language.  It's a game you can never win.

Name: Anonymous 2012-02-06 20:23

>>68
I don't want to and never will win this game.

Name: Anonymous 2012-02-06 23:13

>>24

It's best to not confuse your friendly neighborhood theorem prover.

>>28

A macro in lisp is a function that takes code as an argument, and generates code, which is then executed. So if a macro was to call another macro, the second macro would generate code for the first macro, which would be executed by the first macro, in its effort to generate code for the main program, and then the final result of the first macro would be executed.

Name: Anonymous 2012-02-06 23:48

>>57

Hi, after filtering out your buttrage, I extracted from your post:

"If the compiler can prove that g is pure, then it can optimize a = g(...); if(n < 3) a = f(...);  to  if(n < 3) a = h(...); else a = g(...)".

That's a nice and easy optimization (assuming the compiler can prove that the function is pure, which reduces to the halting problem in general, but should be easy in most cases), but I prefer to see it clearly in the code. It helps me reason about the efficiency of the program, and it helps me think about what value is actually inside of a. But, to each their own. I'll keep using it, you can choose to not use it. I don't think you have stated why you hate it though. You just say that it is shit, but the only negative thing that you've said about it is that it is unnecessary.

>>61

tail recursive calls to nested functions can be pretty self documenting representations of state change, and control transfer, and they generalize modifications to local variables. Take a step on the wild side, and code in a functional language. Modifications to local variables is not where functional languages limit you, but using immutable data structures can be painful when mutable arrays and hash tables are more suitable. Most functional languages support these though. So all I'm seeing is a failure on your part to learn a different representation for a universal technique, where you are already familiar with a different representation for the technique. If you only want to get things done, then that is fine, but if you want to discuss the trade offs of different paradigms, then you should be open to learning other things, and other ways of doing things.

Name: Anonymous 2012-02-07 1:17

It's easier to ``think" with object oriented languages like C++.

Fucking /prog/ hispters. Lisp is shit. SICP is obsolete training for programming.

Name: Anonymous 2012-02-07 7:30

>>71
I guess you could call it a tail call, not necessarily recursive.

>>72
Okay, make good use of C++ and take care of yourself, pitiful human being.

Name: Anonymous 2012-02-07 7:35

>>73

true, tail call is better. Seeples is good for a lot of things though. This doesn't need to be a which one is better contest.

Name: >>74 2012-02-07 7:43

>>72
but you shouldn't call seeples object oriented. You might offend the one who coined the term.

Name: Anonymous 2012-02-07 7:49

>>75
What do you mean offend? C++ is an object oriented language.

Name: Anonymous 2012-02-07 8:20

>>76
It would be better to call it a multi paradigm extension to C.

http://dis.4chan.org/read/prog/1325625255

Name: Anonymous 2012-02-07 8:42

>>77
It's not a C extension, if that were true then C would be a subset of C++-

Name: Anonymous 2012-02-07 8:53

>>78
you are being pedantic.

Name: 61 2012-02-07 9:04

>>71
Take a step on the wild side, and code in a functional language.
I think what you meant is ``purely functional language''.  No, tail recursion is not always the clearest way to express a computation, and forcing the programmer to do it in a specific way sounds like a horrible idea to me.  I love playing around and figuring out new and inventive ways to implement silly things like reverse on lists using tail recursion, but when it comes to implementing larger things, it might not be the best approach.

Name: Anonymous 2012-02-07 9:10

SQL, Lisp, and Haskell are the only programming languages that I've seen where one spends more time thinking than typing.

Because users of other languages don't think.

Name: Anonymous 2012-02-07 10:09

>>80
Well, larger things are usually implemented modularly, and so this comes down how each module is implemented, and using tail calls to nested functions to achieve reassignment of local variables is more of a stylistic choice, and in this context, only affects the contents of a single function, which is hopefully pretty small. So it's all equivalent, now matter how you look at it. You can ask the questions, which is easier to write, which is easier to read and verify the correctness of, and which is easier to come back to and add additional features to? I find imperative to be easier for 1, and functional better for 2 and 3.

Name: Anonymous 2012-02-07 11:40

Why doesn't everyone just learn D?

Name: Anonymous 2012-02-07 11:41

>>83
Not homoiconic.

Name: Anonymous 2012-02-07 20:04

>>78
One of C++ design goals was to compile C source code.

Name: Anonymous 2012-02-26 20:55

>>59
upvoted for lisplike

Name: Anonymous 2012-02-26 21:33

lispers will spend most of their time figuring out how best to abuse recursion because they think it makes them leet programmers or some shit.
lol, he thinks recursion is hard. That's just adorable.

Name: Anonymous 2012-02-26 21:36

>>87
no, reading through Lisp's shitsmear surface syntax is what's hard.

Name: Anonymous 2012-02-26 22:39

>>88
I lol'd hard.

Name: Anonymous 2012-02-26 22:51

]=> (eq? >>88 >>89)
#t
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -