Why there are other programming languages besides Lisp? With Lisp's macro system you can create any language you need ever. Small, big, finely tuned for your task. Supporting other languages means opposing progress and delaying the inevitable future. There should be only one language and myriad languages at the same time. The one language is Lisp.
>>1
Lisp has been around long enough that if it was going to make any dent in software engineering in general it would have already done so a long time ago and we wouldn't be having this discussion.
>>2,4-6
Your shitty languages are reimplementing half of Common Lisp now (the tenth rule), see C# and anonymous functions, Sepples and anonymous functions, Java and garbage collection, Ruby and symbols, Python and no, Python just sucks, etc.
>>9
Because you are a fanboi who who wants to believe that folks are copying your beloved languages features rather the the simple expediency of implementing the same solutions to the same problems in different contexts.
LISP isnt a language, cuz it doesnt have any syntax. LISP is an operating system.
The existence of an interpreter and the absence of declarations makes it particularly natural to use LISP in a time-sharing environment. It is convenient to define functions, test them, and re-edit them without ever leaving the LISP interpreter. A demonstration of LISP in a prototype time-sharing environment on the IBM 704 was made in 1960 (or 1961). (See Appendix 2). L. Peter Deutsch implemented the first interactive LISP on the PDP-1 computer in 1963, but the PDP-1 had too small a memory for serious symbolic computation.
>>12
It is you that wants to believe so badly, thus in your own mind you make "the evidence" true. I personally don't care about who borrows what from whom.
You are quite simply delusional, Mister Lisper faggot.
Name:
Anonymous2011-01-31 12:27
Lisp isn’t really a programming language. It’s a consistent system for defining programming languages in general. That is why learning it is difficult– you’re going up into a level abstraction that you never imagined could exist.
Lisp isn't really a language at all. It's more of a mathematical entity. You might say it wasn't invented but discovered. In fact if there is intelligent life in the universe and they have computers I'll bet they have something equivalent to Lisp too.
Name:
Anonymous2011-01-31 12:29
>>15
Wow that's some good bullshit you are smoking right there.
For the same reason Forth is dead: the language gives too much freedom.
Forth and Lisp are similiar but also very different, both give the programmer the ability to extend every part of the language, creating DSLs, and have a consistent non-syntax. The only difference, is that the Forth programmer works near the hardware, at low level, where the Lisp programmer works on top of an abstraction layer, creating more abstractions.
They both are the ultimate languages, they gives you everything you need.
That's the problem with them, you need to master the language, understand it, start thinking in it, become one with it to use it properly.
If we only had these two essential languages, programming would really be something ``for smart people only''. (and learning the art of it would also really make you smarter)
"SQL, Lisp, and Haskell are the only programming languages that I've seen where one spends more time thinking than typing." -- Philip Greenspun
The Fortran/Algol branch of languages has become more widespread because they are braindead.
Pick a random language from that branch, you'll see that they have hardcoded, ``nice-looking'' statements for the most common operations, such as loops, ifs, etc, all of them with a different syntax. This makes them easier to learn for non-programmers, at the cost of the programmer's freedom and power.
Then, C and UNIX came, UNIX was a really simple system, everything was a file and didn't have a versioning filesystem. It had flaws, many flaws, you can read some in the UNIX Haters Handbook, but most of the problems it addresses don't apply anymore.
So, C was inferior to Lisp and Forth, UNIX was inferior to Lisp Machines, why in the world they replaced them?
They are simple, everyone can use them without having to think and learn how to use them.
C is a static language, you've got if, while, for, goto and return, you must use these and nothing else, you can't add anything to it.
In UNIX, everything is a file. The concept of a file, without attaching versioning informations and such to it, is really simple, everyone can understand it. Could you explain your grandmother how a file in a complex versioning filesystem works? I can't. Could you explain her, instead, what would it be in a simple filesystem? ``You write your stuff in this file, then you archive it, when you need to modify it you take it again and do your modifications, then rearchive.''
The time passed, and we developed a Stockholm syndrome torwards UNIX and Fortran-based languages.
The Lisp/Forth-aware people can't do anything but suffer in silence.
It's sad, but the men it's just limiting its evolution.
>>21 The Lisp/Forth-aware people can't do anything but suffer in silence.
Because they sure as hell can't program anything that would make lisp useful for a real project (or demonstrate that it is).
>>22
Does ``a consistent, simple syntax'' make you happier?
>>23
I can understand your ignorance about Lisp, but Forth, come on, have you tried to do something more than running gcc main.c -Wall -Werror -O3 -march=native -msse2 -fomit-frame-pointer -fomg-optimized?
I thought /prog/ had smarter people than this.
>>25
``You're just not smart enough to use our shittyultimate perfect tools.'' This is how you attract users. God forbid you actually fix any of the problems in them.
>>26
The Lisp community in general doesn't bite newcomers, it is actually helpful and kind. But if we get attacked by people that doesn't know what they're talking about, why shouldn't we defend ourselves?
There are Lisp fanatics that say ``Hah! You damned fool, using an inferior language, you'll never be allowed to use the Omnipotent Language Lisp.'' and take away people that might be interested in it, giving the wrong impression about Lispers.
I'm always there when it comes to help someone that's new to Lisp and/or wants to know more. I also list the pros and cons of using Lisp in 2011, and suggest to use C, which is fundamental to know when dealing with Unix-like systems.
You may note, I also mentioned Forth as ``ultimate language'', if I really was the elitist Lisper you think I am, I would just sell Lisp as ``the One and Only True Language'', but Forth excels in things Lisp is not meant to handle.
You can't deny they've got features that other languages don't have.
The only who's being elitist here is you: ``Lisp, Forth, your ``ultimate'' shitty language sucks, learn Java, faggot!''
Name:
Anonymous2011-01-31 14:27
>>27 Forth excels in things Lisp is not meant to handle.
You know, you can have Forth DSL in LISP?
(crappy-concatenative-style-macro-for-faggots dup rot swap swap3 dup swap dup2 rot swap drop drop drop)
>>28
Of course I know, but I meant that Forth is much more low-level-oriented than Lisp, which is all abstracting the hardware away.
And yes, I know Lisp could work at low-level too (Lisp Machines were Lisp all the way down, after all), but with Forth seems much more natural.
2/10
You would achive 1 if you will use mailto:noko next time
Name:
Anonymous2011-02-02 6:44
>>21 For the same reason Forth is dead: the language gives too much freedom.
I have noticed one pretty damn interesting thing about lispers. >>15 said it most clearly here:
That is why learning it is difficult– you’re going up into a level abstraction that you never imagined could exist.
As someone who knows both Lisp and Forth, I'm getting progressively more baffled by this. Like, it doesn't seem like a big thing initially, but the more I look at it, the deeper it goes.
Learning Lisp is not difficult.
I mean, come on, really. Compare it to an entry course on linear algebra and shut the fuck up, ashamed.
Sure, for someone who sees the stuff for the first time it could be somewhat mindblowing, for a couple of hours. But look around, these days you have to understand anonymous functions, closures and higher-order functions to get a job as a Visual Basic code monkey. And guess what? Even Visual Basic code monkeys do understand this shit, because it's simple.
While lispers have been saying for thirty years, and continue to say, that lisp is unpopular because the average programmer can't get map/filter/reduce and prefers "less powerful" languages.
Don't even get me started on homoiconicity. After a couple of months of learning to program, every non-retarded programmer gets a mindblowing revelation: his C compiler is a program too! And some other program could compose a text of a third C program, then feed it to the compiler, and run the result! WHOA. Whoa, man. Wait, that's obvious, I'm a little ashamed of not getting it earlier. <- that's how the natural progression should look like, unless the person in question is retarded, right?
Learning lisp is not difficult. Functional programming is not difficult. Metaprogramming is not difficult. Any sane programmer gets her share of revelations about this shit, like, maybe two or three hours of blown mind all put together, then naturally transitions from awe to the real understanding, and feels a bit ashamed for not getting these simple things earlier.
Yet lisp fanboys ceaselessly repeat profound bullshit about the "levels of abstraction that you never imagined could exist". As I said, that's not a very big deal, on the surface. But as I think about the roots, the possible reasons for this behavior, something very much like the true answer for the Lisp Unpopularity Enigma comes looming from the depths. Every reader, except for lisp fanboys, must have realized what it is by now.
Name:
Anonymous2011-02-02 7:15
>>52 Compare it to an entry course on linear algebra and shut the fuck up, ashamed.
Linear Algebra is hard not because underlaying concepts hard, but because Set Theory is a tainted jewish pseudoscience. It is like explaining programming in terms of Astrology: your program has failed, because Mars was in wrong position and God hates you. If you reformulate algebra in terms of LISP and finite lists, it will become easy as fuck.
Name:
Anonymous2011-02-02 7:18
Remeber, kids: there are no hard things, there are hard jews, that make things hard for you. Next time, you will hear about infinite sets, just leave class room.
Because this
foldr f acc [] = acc
foldr f acc (x:xs) = f x $ foldr f acc xs
is far more readable than this
(defun foldl (f acc list)
(if (null list)
acc
(f (car list) (foldl f acc (cdr list)))))
Sure you can create a slow bug ridden implementation of half of haskell's syntax on top of a lisp with macros but why not use a language that has nice syntax to begin with?
Sometimes the flexibility of lisp is nice but it comes at a price (homogayiconicity) which you still have to pay when you don't need that flexibility.
Name:
Anonymous2011-02-02 7:31
>>55
>why not use a language that has nice syntax to begin with?
Prefix notation is a nice and uniform syntax, that signifies underlaying AST.
Name:
Anonymous2011-02-02 7:33
>>56
For example, jewish Set Theory uses this ugly Set notation, instead of plain lists. And it makes it agonizingly hard to learn and read.
Name:
Anonymous2011-02-02 7:39
>>56
AST shmAST. Maybe nice was the wrong word but you can't deny that the haskell example in my post is far more readable and the difference is even bigger when you have more complex code.
If you can parse a piece of haskell code twice as fast as a piece of lisp code that's a huge advantage.
Name:
Anonymous2011-02-02 7:46
>>58
I dont know Haskell, nor its syntax, but I know, that (x:xs) is a high level operation, and in your LISP example you use only low level, manual list splicing. So, you're probably a jew, that tries to brainwash us.
Name:
Anonymous2011-02-02 7:52
In my Lisp DSL, I can do foldr in one line foldr f [x@xs] -> foldr f xs |> f x
no
>foldr `+` [1 2 3 4 5 6]
21
so, haskell sucks even here
>>58
>difference is even bigger when you have more complex code.
I've seen complex Set Theory expressions, and I cant read them. Even simple Zermelo-Frenkel axioms look very scary, compared to LISP.
Name:
Anonymous2011-02-02 8:03
>>60
Eh, so what?
You can easily write that in one line of haskell.
Also, you can put my lisp example in one line too, so why even mention your dsl?
>>65 I was talking about haskell.
It is this ugly jewish language, sponsored by Micro$oft, that uses {x | such that unintelligible symbol mess} notation from Set Theory, instead of simple (remove-if predicate list)?
Name:
Anonymous2011-02-02 8:15
>>66
[quote]Sure you can create a slow bug ridden implementation of half of haskell's syntax on top of a lisp with macros but why not use a language that has nice syntax to begin with?[/quote]
Name:
Anonymous2011-02-02 8:17
>>67
LISP doesnt. You can even write LISP as a bitstream, assigning to #\( and 0 to #\)
>>62 I've seen complex Set Theory expressions, and I cant read them.
That's because you're genetic garbage, a product of three hundred years of rapings by Mongols, and of ubiquitous alcoholism (as a mode of escapism).
Jews tried to enlighten you Untermenschen by installing Communism, you know, free education, eradication of primitive selfishness, that kind of stuff. We all know how it ended, they'd better have tried to educate baboons, to see actual improvement and at least some gratitude.
No wonder you hate Jews, it's the hate of a cripple for whole persons, complete with rationalizations, "the absurd notion of usefulness of legs is brainwashing and propaganda".
No wonder you adore lisp, you fit >>52 perfectly. And don't try to derail the discussion with your inept trolling.
Name:
Anonymous2011-02-02 8:18
>>69 why not use a language that has nice syntax to begin with
Already using it. Called LISP.
>>70
That's still syntax. Just because you use binary digits as your alphabet, that doesn't mean you don't have syntax. Without syntax, there can't be language. IHBT
>>81
What about Forth, does it have syntax? It's a succession of words, like Lisp is a succession of lists, delimited by *whatever character reads lists in the readtable*
>>86
Actually, the syntax is predefined. You [i]can[i/] change it, yet that still doesn't mean it doesn't have one. And when you do change it, it is no longer Lisp, it's something else entirely. A language is it's syntax and it's semantics. If you change one or the other, it's not really the same language anymore.
>>94
Saying ``non-syntax'' and ``simple syntax'' is the fucking same thing.
Non-syntax implies having syntax that is not real syntax. The syntax dictates how something has to be done/written, in Lisp you can change it whenever you want.
>>84 >>21 never said that Lisp, he mentioned the high layer of abstraction and implied it's a mind-opener. What higher level of abstraction are you talking about? Closures and higher-order functions? VB.NET code monkeys all have had this mind-opening revelations already, come to terms with it and don't consider it something worth boasting of.
Look, I'm not saying that it's not mind-opening, it most definitely is. Like, you know, the realization that each integer can be thought of and operated on in terms of its prime divisors. That is a pretty WHOA realization too, before you thought that all integers are like black boxes, now you see the structure in them, the true nature.
I'm saying that these are pretty basic, simple things. You must learn them, but you can't boast about it. It's like learning to use toilet, which another pretty important stage in personal development!
When I see a person who remains in this excited state about Lisp for months and years and decades, I can only assume that she is retarded, that she was never able to completely understand and internalize these higher-level concept, so they never lost this earth-shattering quality for her. And doubly retarded because she doesn't notice that she positions herself as being dumber than VB.NET code monkeys these days.
A mind-opening revelation is supposed to left the mind in the more open state and pass. If instead the mind is forever locked in some half-open, perpetually being opened, state, it is not normal, it's some kind of phimosis.
>>93
It doesn't matter how syntax is implemented. It's still there. But I kinda see what the ``no syntax'' comes from. Lisp is actually just the interpreter/compiler program, whith which you interact through a basic predefined language (which is also called Lisp), which itself has constructs that allow you to tell the interpreter/compiler to modify (mostly the syntax of) the language it implements. And the same goes for Forth. But to say that Lisp doesn't have syntax is still misleading. Because, if you're talking about the language, that's just plain absurd; and if you're talking about the compiler/interpreter, well, it wouldn't have a syntax anyway, it would understand a syntax.
>>101
Nope, that syntax right there allows for constructs that wouldn't be part of most languates. That basic Forth syntax I gave you is pretty much the syntax of Forth in interpretation mode. Of course, when you go into compilation mode, it has all the extra syntax for control flow constructs and stuff. But yes, I get what you're saying, what I posted wasn't even close to a complete Forth syntax.
>>98 What higher level of abstraction are you talking about? Closures and higher-order functions?
Code=data, you can make a program that writes your program at runtime
I just woke up and can't write nothing more than this.
When I see a person who remains in this excited state about Lisp for months and years and decades, I can only assume that she is retarded
We (well, most of us) are not in that state about Lisp, we're just saying that Lisp has things other languages don't have (or, few languages have: TCL has homoiconicity and can ``fake'' macros using upvar and uplevel, which are both really powerful and enable call-by-name, Forth has macros (immediate words), etc)
Of couse, I have periodically a big "Aha!" when coding in Lisp, when ``discovering'' a new way to do things, and do them better.
You never really master Lisp, you always have something new to learn because of the freedom it gives to the programmer.
>>104
Yes, I do realize that the ``basic Forth syntax'' I posted is also too general to be called a Forth syntax, and is hence not just ``incomplete'' but plain wrong. But anyway, that just goes to show that Forth does have a syntax (that is actually not that simple) even if it is extensible.
>>96 Non-syntax implies having syntax that is not real syntax. The syntax dictates how something has to be done/written, in Lisp you can change it whenever you want.
Oh, so Perl has a non-syntax too. Thanks for clearing that up! And here I thought you were just being a jerk and using words with no meaning because you thought they sounded vaguely impressive.
Name:
Anonymous2011-02-02 10:15
>>105 Code=data, you can make a program that writes your program at runtime I just woke up and can't write nothing more than this.
... I repeat, yes, the realization that there's no magic inside the computer, that a C compiler is just another program, and that there's nothing special about source code to prevent it from being generated by another program, is mind-opening.
The alternative -- I'll spell it out for you, -- believing that compilers work by magic and that only a human can write source code, is outright retarded. Stupid. Idiotic. In a clinical sense, like shitting your pants.
Unless you are a babe, or just began learning to program, of course. But if you are a dude in your twenties, shitting your pants or thinking that compilers are magical, that means that you are mentally retarded.
And if you are a dude in your twenties or older, and you tell everyone about how you've discovered that you can shit in the toilet or that code is data, you are exactly one small step above clinical mental retardation.
Which is made all the funnier by your attitude, demonstrated for instance in the "beating the averages" by Paul Graham (the "blub paradox" part).
We (well, most of us) are not in that state about Lisp, we're just saying that Lisp has things other languages don't have
Every popular language developed in the past twenty years has higher-order functions and some form of compiler-as-a-service functionality. The former makes macros technically unnecessary, the latter is the gist of the "code is data" idea, true homoiconicity is just the glazing.
Every. Popular. Language. Not just TCL. Perl, Python, Java, Ruby, C#. Even C++ gets true closures now.
Every. Popular. Language. Does this sink in?
What can I feel about a person who is ignorant of this basic fact of nature, but (or, "and because of it") considers himself an expert on relative merits of programming languages, and his chosen language to be superior to most of the rest?
Of couse, I have periodically a big "Aha!" when coding in Lisp, when ``discovering'' a new way to do things, and do them better. You never really master Lisp, you always have something new to learn because of the freedom it gives to the programmer.
This is not limited to Lisp. This is true for every popular language developed in the past twenty years. Unless you can't see that freedom, because you are an idiot, of course.
It is not about the language, it is about what you write using the language, and every popular language developed in the past twenty years lets you get to that part relatively painlessly.
>>108 ... I repeat, yes, the realization that there's no magic inside the computer, that a C compiler is just another program, and that there's nothing special about source code to prevent it from being generated by another program, is mind-opening.
that a C compiler is just another program, and that there's nothing special about source code to prevent it from being generated by another program
Are you really a Lisper? Have you ever heard of eval? Calling gcc from a C program to compile a C source ``generated'' at runtime, written in a file with fwrites and fprintfs is not homoiconicity, and the compiled new program doesn't have nothing to do with the current running one.
compiler-as-a-service functionality.
Not the same, read above.
The former makes macros technically unnecessary,
That's not true, learn to macros.
the latter is the gist of the "code is data" idea, true homoiconicity is just the glazing.
You never used eval in Lisp, ok.
Every. Popular. Language. Not just TCL. Perl, Python, Java, Ruby, C#. Even C++ gets true closures now.
Every. Popular. Language. Does this sink in?
Did I mentioned closures? Where? I know that.
What can I feel about a person who is ignorant of this basic fact of nature, but (or, "and because of it") considers himself an expert on relative merits of programming languages
see >>108
Unless you can't see that freedom, because you are an idiot, of course.
Indeed I can modify every little aspect of the C programming language.
Modern?
Indeed I can modify every little aspect of Python, I don't even use indentation anymore, and I implemented multiline that accept statements with my powerful macro sys-Oh.
Well, Ruby has extensive metaprogramming support and nice syntax for it at runti-Wait, but that makes it SLOW AS FUCK!!!
I don't really know, maybe Perl 6, but it's a mudball of operators.
Maybe I am an idiot, can you please enlight me?
It is not about the language, it is about what you write using the language, and every popular language developed in the past twenty years lets you get to that part relatively painlessly.
Implement the ``in Lisp DSL'' in your favourite popular language that is good just because it's popular, please.
Name:
Anonymous2011-02-02 10:58
Calling gcc from a C program to compile a C source ``generated'' at runtime, written in a file with fwrites and fprintfs is not homoiconicity, and the compiled new program doesn't have nothing to do with the current running one.
It is not homoiconicity but it is a full embodiment of the "code is data" idea. Why do I need to repeat myself? Ah, because that's what one has to do when talking to a not very bright person. But I digress.
If you don't see how you can achieve everything macros give you by runtime codegeneration, then you don't truly understand the "code is data" concept. Which is my point, really -- to remain fascinated by some idea you must forever have it half-understood. Not because it's too complex or rich, but because you are fucking dumb. Also because you and your circlejerk fellows keep telling ourselves that you've already there, that you've "become better programmers simply by learning Lisp", and there's no need to move forward.
The former makes macros technically unnecessary, That's not true, learn to macros.
That is true. You don't understand that because you don't understand the essence behind macros. You see them as a final concept, kind of like some VB.NET dolt might view his "if" operator.
Did I mentioned closures? Where? I know that. I mention closures because with closures you technically don't need macros (which you don't understand). Also, three of the six languages I mentioned have fully-fledged eval, C# has expression trees and C++ has touring-complete templates.
Indeed I can modify every little aspect of Python, I don't even use indentation anymore,
You are concerned about indentation because you are not a programmer.
Implement the ``in Lisp DSL'' in your favourite popular language
You are an idiot. ``in Lisp DSL'' is not the something, it's not a thing.
>>111
Yeah, "my uninformed opinion is as good as your expert knowledge", and when the other side points out that the opinion is, in fact, uninformed, it's an "ad hominem" and automatic loss.
Internet is an elitist meritocracy, baby. If you are an idiot, you would be called an idiot and your opinion would be disregarded, appeals to "ad hominem" wouldn't protect you.
>>110 but it is a full embodiment of the "code is data" idea.
Explain why, I give a reason of why it IS NOT: and the compiled new program doesn't have nothing to do with the current running one.
The evaluation must be done in the current scope of the current program, not elsewhere, not using a compiler, it must be done inside the language, it's not about macros, it's about evaluating fucking code generated at runtime by the current program, for the current program.
This is code=data:
(define (generate-lambda args-list &rest body) `(lambda ,args-list ,@body))
You can eval this at runtime and will generate a lambda using the runtime arguments you give to that function, not macro, at runtime. And will return the lambda, it's not an indipendent file that does indipendent things. The code I generate at runtime is used in the current program. Get it? Eval.
That is true. You don't understand that because you don't understand the essence behind macros. You see them as a final concept, kind of like some VB.NET dolt might view his "if" operator.
Nope, the only thing that resembles Lisp macros in a ``modern'' programming language are D mixins and Nemerle macros.
I mention closures
Ok, but it is known that all new languages support closures
with closures you technically don't need macros (which you don't understand)
Why? A macro is code executed at compile-time, it generates code, a closure is created by from a new lexical scope that closes over a free variable, at runtime. They are not interchangeable, they are two different things, it's like saying ``with functions you don't need ifs''.
Also, three of the six languages I mentioned have fully-fledged eval,
But the code is not data.
C++ has touring-complete templates.
But I can't pass code to a template.
You are concerned about indentation because you are not a programmer.
It was an example, can't I make examples?
You are an idiot. ``in Lisp DSL'' is not the something, it's not a thing.
If it exist, it is a thing. Implement something like that in your favourite popular language.
>>114
Oh god, I wrote some mutant strange CL/Scheme derivative there, I really wanted to write: (define (generate-lambda args-list . body) `(lambda ,args-list ,@body))
The evaluation must be done in the current scope of the current program
Why? It seems like you think that "programs" are real and important, and can't see the computation behind them. The "code is data" concept is about computations. The restrictions you try to impose ("in the same program", blah blah) are utterly irrelevant.
It's like if a not very bright Lisp programmer declared that Haskell is less powerful than Lisp because in Lisp conses are mutable, while in Haskell you have to return another cons, and another cons is not the same cons. Like if computation cared about such minutae.
Nope, the only thing that resembles Lisp macros in a ``modern'' programming language are D mixins and Nemerle macros.
Again, you are talking about superficial resemblance.
>> with closures you technically don't need macros (which you don't understand) Why? A macro is code executed at compile-time, it generates code, a closure is created by from a new lexical scope that closes over a free variable, at runtime. They are not interchangeable, they are two different things, it's like saying ``with functions you don't need ifs''.
And again, the shallowness of your thought is astonishing.
Macros and closures are tools. Instruments. They are used to achieve some goals, to write a program that has certain form and does certain things. I say that having closures allows you to do anything you can do with macros, in a more or less similar fashion. Like, screws and nails look differently and are applied differently, but in the end when you need too planks put together, it doesn't matter much if they are nailed or screwed together.
And yes, with anonymous functions I don't need a built-in "if", I can write my own which would be used in pretty much the same fashion. Have you read your SICP today?
Also, three of the six languages I mentioned have fully-fledged eval, But the code is not data.
Why, is there such a huge difference between using a single grave mark and two quote marks?
But I can't pass code to a template.
Um, why do you want to do it? I urge you to go look at boost::lambda (the interface, not the implementation) to get a feeling of what is possible with templates.
It was an example, can't I make examples?
It is bad enough when you can't see "what" behind "how", as above. It is even worse when you bring up stupid "what"s, like changing the method for indicating nesting. You can go discuss such matters with your buddies, I'm completely not interested in it. I don't want to replace FOIC with braces, I don't want Language-Integrated BBCode, neither is related to programming. Not interested at all, sorry.
Why? It seems like you think that "programs" are real and important, and can't see the computation behind them. The "code is data" concept is about computations. The restrictions you try to impose ("in the same program", blah blah) are utterly irrelevant.
Please, just shut up.
It's like if a not very bright Lisp programmer declared that Haskell is less powerful than Lisp because in Lisp conses are mutable, while in Haskell you have to return another cons, and another cons is not the same cons. Like if computation cared about such minutae.
You're getting boring.
Again, you are talking about superficial resemblance.
Lisp macros are called Lisp macros because Lisp has Lisp macros.
And again, the shallowness of your thought is astonishing.
Macros and closures are tools. Instruments. They are used to achieve some goals, to write a program that has certain form and does certain things. I say that having closures allows you to do anything you can do with macros, in a more or less similar fashion. Like, screws and nails look differently and are applied differently, but in the end when you need too planks put together, it doesn't matter much if they are nailed or screwed together
From today, start programming in BASIC, not even Visual Basic, just BASIC. It is Turing-complete, it's just a tool, it has everything you need, it can do all the computations you need to do because it's Turing-complete, blah, blah.
Stupid brainless troll.
And yes, with anonymous functions I don't need a built-in "if", I can write my own which would be used in pretty much the same fashion. (define (if p t f) ; how does I branched without something to branch with now, without using (lambda (x y) x) and (lambda (x y) y) for true and false, because they are not #t and #f, because they are not t and nil, (``somebranch-when-eq?-p-#t'' (t) (f))
)
(if (number? 3) (lambda () (display "it's true")) (lambda () (display "it's false")))
Have you read your SICP today?
I have, what about you? Have you compiled your metacircular evaluator in C, today? Hahaha I'm so funny, C is not homoiconic!
Why, is there such a huge difference between using a single grave mark and two quote marks?
Because Lisp programs are lists, C++ programs are not strings. '(1 2 3) is a shorthand for (quote (1 2 3)). Are you saying that C++ translates "string" to string(string);? What about the spaces, then?
Even if we joke on it, the DSL is very powerful and pure art.
Name:
Anonymous2011-02-02 12:51
>>120 From today, start programming in BASIC, not even Visual Basic, just BASIC. It is Turing-complete, it's just a tool,
I never said anything about touring-completeness. I did however specifically worded my statement as "to write a program that has certain form and does certain things. I say that having closures allows you to do anything you can do with macros, in a more or less similar fashion".
how does I branched without something to branch with now
Obviously, when you are rolling out your own if, you roll out your own :t, :f, and comparison operators. Or you can demand the existence of a much simpler construct, like in FORTH if is implemented in terms of conditional jump basically.
The important thing is that you have to perform O(1) work, so to speak, to do that once, and then use it with almost no cruft through the rest of your code. You can't do that in BASIC.
Because Lisp programs are lists, C++ programs are not strings. '(1 2 3) is a shorthand for (quote (1 2 3)).
Why does that matter? You keep pointing out some differences that I honestly consider superficial, without even trying to explain why these are important. Yes, when I write return eval('lambda x: {}'.format(n)) simple string substitution happens instead of symbol substitution in AST. Why the fuck should I care? It's the "how", the result is the same.
If you want to deal with dynamic code generation/modification in a more safe manner, no problem, the compiler is there, the decompiler is there, the sky is the limit. Here, look at the Python goto module: http://entrian.com/goto/download.html
Here, take a look of what we call ``in Lisp DSL''
MY EYES.
I value my sanity too much.
If I got the idea right, it's a variation on Ocaml pipes (though with some crazy shit that I'm afraid of).
Go look at LINQ syntax, then at the code it's translated into by the compiler.
Sure, it's nice to have a nice list comprehension syntax. It could be even nicer to be able to implement one yourself. However it only saves you a couple of characters per term when compared to raw combinator chaining. from x in lst where x > 0 select x * 2 is nice, but not that much nicer than lst.Where(x => x > 0).Select(x => x * 2).
There are much more interesting and difficult problems in programming than applying minor changes to syntax. If you boast of the ability to apply minor changes to syntax as if it was an intellectually liberating mind opener, then, uh, yo'ure either inexperienced or retarded.
Name:
sage2011-02-02 12:57
>>119
[quote]
I say that having closures allows you to do anything you can do with macros, in a more or less similar fashion.
[/quote]
:p that made me laugh, if you aren't just trolling, then I suggest you go learn up on lisp macros...
>>121 I never said anything about touring-completeness. I did however specifically worded my statement as "to write a program that has certain form and does certain things. I say that having closures allows you to do anything you can do with macros, in a more or less similar fashion".
I say that being Turing-complete allows you to do anything you can do with another Turing-complete language, {b in a more or less similiar fashion}.
You can't do that in BASIC.
You can't do that in C.
Why does that matter?
Because the code is data if and only if the code {i is} data.
You keep pointing out some differences that I honestly consider superficial, without even trying to explain why these are important.
I already explained it many times, the code must be data to be called data, the data must be code to be called code.
The generated code must be evaluable in the current scope, because I want a program that writes a program to modify itself, not a program that writes a program that does something, that would be just stupid.
Yes, when I write return eval('lambda x: {}'.format(n)) simple string substitution happens instead of symbol substitution in AST.
But your data is not code and your code is not data. You can't do (write '(my configuration list) my-configuration-file), then (read my-configuration-file) and return the same list.
Why the fuck should I care? It's the "how", the result is the same.
Not the same, read above.
MY EYES.
We all know that the DSL's syntax is terrible{spoiler.i !}, but it's a good example of {i macros}.
It could be even nicer to be able to implement one yourself. (define-syntax (lc stx)
(syntax-case stx ()
((~ expr (a b c) . r)
#'(map (lambda (a) (~ expr . r))
(filter (lambda (x) (c x)) b)))
((~ expr (a b) . r)
#'(map (lambda (a) (~ expr . r)) b))
((~ expr) #'expr)))
(lc (+ b c)
(b '(1 2 3 4 5 6) even?)
(c '(1 3 5)))
(define-syntax (lc2 stx)
(syntax-case stx (for in when select)
((lc for var in xs when p r ...)
#'(map (lambda (var) (lc r ...)) (filter p xs)))
((lc for var in xs r ...)
#'(map (lambda (var) (lc r ...)) xs))
((lc select b) #'b)))
(lc2
for b in '(1 2 3 4 5 6) when even?
for c in '(1 3 5)
select (+ b c))
[code]
but not that much nicer than lst.Where(x => x > 0).Select(x => x * 2).
[code](map (lambda (b c) (+ b c)) (filter even? '(1 2 3 4 5 6)) '(1 3 5)))
There are much more interesting and difficult problems in programming than applying minor changes to syntax.
(defmonadfn >>= (m x f)
#:apply #'((monad-base-bind m) f x)
#:id #'(monad-base-bind m))
(defmonadfn >> (m f g)
#:apply #'(>>= m f (λ (_) g))
#:id #'(λ (f g) (>> m f g)))
(defmonadfn return (m x)
#:apply #'((monad-base-return m) x)
#:id #'(monad-base-return m))
(defmonadfn mplus (m x y)
#:apply #'((monad-plus-mplus m) x y)
#:id #'(monad-plus-mplus m))
(defmonadfn mzero (m)
#:apply #'(mzero (current-monad))
#:id #'(monad-plus-mzero m))
(defmonadfn m-lift (m n f)
#:apply
(let* ((xs (map gensym (make-list (syntax->datum #'n) 'x)))
(zipxs (map (λ (x y) (list x (list #'return y))) xs xs)))
#`(lambda #,xs
(do-monad m #,zipxs
(f #,@xs))))
#:id #f)
>>131
What makes you say that? I was looking for a place where I could discuss the procedural generation of trees in Unity 3... This board seems like a great place for me.
>>124
Wow more Lithp faggotry. code=data is a fucking terrible idea, at least in its current most quoted embodiment (((Lithp))). Fuck you and your shitty sea of parentheses. It's been 40 years since that language was invented and nobody came up with a standardized better syntax that would maintain the so-called code=data principle. Guess why?
>>138 It's been 40 years since that language was invented and nobody came up with a standardized better syntax that would maintain the so-called code=data principle. Guess why?
Because S-expression already work perfectly?
( ≖‿≖) D
( ≖‿≖ ) I
(≖‿≖ ) C
(‿≖ ) K
(≖ )
( ) T
( ) O
( ≖) W
( ≖‿) E
( ≖‿≖) R
I'm pretty sure that he'll enjoy being stuffed into anuses of clueless toddlers. ( ≖‿≖)
( ≖‿≖) R
( ≖‿) E
( ≖) W
( ) O
( ) T
(≖ )
(‿≖ ) K
(≖‿≖ ) C
( ≖‿≖ ) I
( ≖‿≖) D
Name:
Anonymous2011-02-02 16:22
>>124 I say that being Turing-complete allows you to do anything you can do with another Turing-complete language, {b in a more or less similiar fashion}.
and immediately... You can't do that in BASIC. You can't do that in C.
You must have the memory of a chicken, to contradict yourself so hard so soon.
Touring completeness is completely meaningless when discussing differences between programming languages. They all are, and the DSLs which aren't are so fucking different that no sane person would go as far as decided to include them in the comparison.
Mentioning touring completeness only marks you as a sophomore who just learned of the concept and plugs it anywhere he can. Or as an intellectually challenged individual who continues to do so long after he should have realized its limitations.
I repeat, there's an informal but a much more useful metric for comparing the expressive power of different languages. In this metric C and BASIC are far below any language which has proper anonymous functions, and those are pretty damn close to languages which have compile-time transformations, like Lisp. Which, in turn, are somewhat below languages which have unrestricted compile-time transformations, like Forth, but not that far below, compared to the level where having anonymous functions brings you.
Oh, back to your remark about C, I want to point out that I was talking about the languages developed in the past twenty years, C falls short by almost twenty years as well, C++ -- by ten years.
I already explained it many times, the code must be data to be called data, the data must be code to be called code.
The generated code must be evaluable in the current scope, because I want a program that writes a program to modify itself, not a program that writes a program that does something, that would be just stupid.
And I already explained that this objection is no more meaningful than an objection to Haskell's conses on the grounds that you have to make a new cons if you want it modified. It doesn't mean that Haskell's conses are somehow inferior, because nobody cares about such minute details, except for the people who can't see the computation behind the trees.
But your data is not code and your code is not data. You can't do (write '(my configuration list) my-configuration-file), then (read my-configuration-file) and return the same list. Obviously I can serialize a list into a file and then deserialize it back. Not needing to "import pickle" to use the serializer is not a benefit you mention in a thoughtful discussion.
Also, it has nothing to do with the "code as data" thing. What you probably wanted to say is that I can't dump some code into a file and then import that file. Which I obviously can.
Now implement multiline lambdas, without writing 100M LoC.
You don't know shit about what you're talking about. Python's lambdas are multiline. Just enclose the expression in, wait for it, wait for it, parentheses. What they are not, is allowing statements, and, as it happens, I've recently added about 15 LOC to my "void.py" file, which provide me with all expressions I need, wrapped in functions. With lambdas you can do that.
but not that much nicer than lst.Where(x => x > 0).Select(x => x * 2). [code](map (lambda (b c) (+ b c)) (filter even? '(1 2 3 4 5 6)) '(1 3 5)))
Your point is? You seem to be quite confused and just latching on any bait you imagine to see. I never said that Lisp is less powerful than C#, there's no need to translate every bit of C# code I show into Lisp. I don't care if your dick is small. However I'd like to point out that Lisp notation is retarded, in C# the flow of data matches the flow of code, in Lisp you get function names progressively more separated from their important arguments. Go make the DSL to fix that, then make all your imaginary friends use it.
There are much more interesting and difficult problems in programming than applying minor changes to syntax. defmonadfn
HAHAHAHAHA, well, HAHAHA, oh, small minds and shit... HAHAHAHAHAHA.
>>153 I was talking about the languages developed in the past twenty years
But Lisp is 52 years old, now! (Also, Java: 1995)
Also, it has nothing to do with the "code as data" thing.
You can't load and... What you probably wanted to say is that I can't dump some code into a file and then import that file. Which I obviously can.
... then transform the code, or use it as data.
But on this you've won.
You don't know shit about what you're talking about
But you said you could do anything Lisp does and better~ ：（
I've recently added about 15 LOC to my "void.py" file, which provide me with all expressions I need, wrapped in functions.
So, you need to define named function to defined proper anonymous functions? Yeah, that makes sense.
Python's lambdas are multiline. expr1 and expr2 and expr3 and expr4 doesn't count as multiline, a (logical) ``line'' in Python is (expr|stmt)[\n;]
In a language full of statements, having lambdas that can't use them is pointless.
HAHAHAHAHA, well, HAHAHA, oh, small minds and shit... HAHAHAHAHAHA.
You might prefer
(define-syntax >implying
(syntax-rules (is called with and)
((>implying proc is called)
(proc))
((>implying proc is called with var)
(curry proc var))
((>implying proc is called with vars ... and var)
(curry proc vars ... var))))
It will remind you from where you came, after all.
By the way, show something Lisp can't do, now.
You know, just for fun.
But you said you could do anything Lisp does and better~ ：（
Nope. I could do anything Lisp does not much worse, and then some things that I actually want to do, much better.
expr1 and expr2 and expr3 and expr4 doesn't count as multiline, a (logical) ``line'' in Python is (expr|stmt)[\n;]
In a language full of statements, having lambdas that can't use them is pointless.
You don't understand. Again, the chicken memory of yours is to blame, I'm getting a suspicion regarding your preferred Scheme dialect.
I can have as long lambdas as I want, split into separate lines and indented any way I want, as long as they are enclosed in parentheses. That part about necessary parentheses, it doesn't bother you too much, I presume?
Now there's a problem -- normally, I use statements in Python, like, the "for" statement, or the "while" statement, or the "raise" statement, and so on.
Well, as it happens, all my looping needs are completely satisfied with list comprehensions, and for things like "raise" I can define a "raise_" function which does exactly that. I have to do it once and then just import my "void.py" which contains everything I need. I'm OK with having to do it with a named function, because I have to do it once.
You might prefer
Nope, I don't prefer you pointlessly showing off in any fashion. too lisp; didn't read.
By the way, show something Lisp can't do, now.
Not looking like an oatmeal with fingernail clippings mixed in, in a commonly accepted fashion?
It can't. So I prefer to use languages which allow me to do everything Lisp can do with not much overhead, and then do the things I want without looking like the proverbial oatmeal, e.g. much much better.
PS: I want to point out that we quite digressed from my original point, which was not about why I don't use Lisp, but about the peculiar property of the vast majority of the Lisp advocates: they tend to praise mundane, simple features that are already included in VisualBasic.NET™, as true mind openers. And then, in more private circumstances, complain that it's these features that are too hard for the rabble to understand, and that's why Lisp is unpopular. Unlike VisualBasic.NET™. And that this enigmatic tendency might have something to do with the fact that Lisp is so unpopular that it's less popular than Haskell. Namely, that the Lisp community consists mostly of mentally retarded people, and that is a push off of a kind.
>>157 You don't understand. Again, the chicken memory of yours is to blame, I'm getting a suspicion regarding your preferred Scheme dialect.
Scheme doesn't restrict lambdas, I don't have to do any and/begin tricks.
Here it's 23:52PM, ````sorry'''' for my ``chicken memory''.
I can have as long lambdas as I want, split into separate lines and indented any way I want, as long as they are enclosed in parentheses. That part about necessary parentheses, it doesn't bother you too much, I presume?
What bothers me is to not being able to do x = ???;something.set(x);somethingelse.set(x)
Now there's a problem -- normally, I use statements in Python, like, the "for" statement, or the "while" statement, or the "raise" statement, and so on.
It's too soon to say ``yeah, you finally get it.''
Well, as it happens, all my looping needs are completely satisfied with list comprehensions,
Look at me, I'm fighting against my tool! I need to do what my hammer want me to do!
and for things like "raise" I can define a "raise_" function which does exactly that.
See above.
I have to do it once and then just import my "void.py" which contains everything I need. I'm OK with having to do it with a named function, because I have to do it once.
See above.
Nope, I don't prefer you pointlessly showing off in any fashion. too lisp; didn't read.
Too faggot; didn't read.
Not looking like an oatmeal with fingernail clippings mixed in, in a commonly accepted fashion?
It can.
It can't.
Hello, #I reader macro, standard even on Lisp Machines!
So I prefer to use languages which allow me to do everything Lisp can do with not much overhead
Too uninformed; didn't read.
and then do the things I want without looking like the proverbial oatmeal
Why, hello there, Larry.
e.g. much much better.
That's just an example, it doesn't have to be real (n.b.: it doesn't)
PS: I want to point out that we quite digressed from my original point, which was not about why I don't use Lisp, but about the peculiar property of the vast majority of the Lisp advocates: they tend to praise mundane, simple features that are already included in VisualBasic.NET™, as true mind openers.
VBNET enforces Lisp-style of doing things.
And then, in more private circumstances, complain that it's these features that are too hard for the rabble to understand, and that's why Lisp is unpopular.
I even said it's simple.
Unlike VisualBasic.NET™.
I just said it's braindead. It is.
And that this enigmatic tendency might have something to do with the fact that Lisp is so unpopular that it's less popular than Haskell.
We're comparing sepples to dead dogs, now.
Namely, that the Lisp community consists mostly of mentally retarded people, and that is a push off of a kind.
QED. Oh, wait.
What bothers me is to not being able to do x = ???;something.set(x);somethingelse.set(x)
That's because you don't understand lambda calculus. How the fuck you can claim any deep understanding of any Lisp then is beyond me. No, I'm lying, I do understand that the utter lack of understanding is quite conductive to claims of greater understanding.
Look, it's simple. When you want to write "x = expr; stuff ..." in an imperative fashion, you can rewrite it as "(lambda x: stuff ... )(expr)", in a pure functional fashion.
Is your mind blown? If it is, then shut the fuck up and reflect on how this shit is pretty obvious to anyone who understands lambda calculus, and how ashamed you should be for not understanding it earlier. A hint: just ashamed enough to never mention this shit unless you are pretty sure that the person doesn't know it.
Hello, #I reader macro, standard even on Lisp Machines!
Yeah, yeah, and there's that scheme proposal #754 or something, which no one uses, ever. Because lispers are insecure dumb fucks who don't understand why exactly they have the power and are afraid to change anything lest they lose it.
VBNET enforces Lisp-style of doing things.
You are missing the point. Code monkeys are OK with VB.NET and are not OK with Lisp. As VB.NET converges on the good parts of Lisp, it's getting harder and harder to convincingly assert that it's the good parts that are the reason for Lisp sliding into oblivion, because code monkey supposedly can't understand them. They can, this is the truth. You have to admit that there are bad parts in Lisp, but you also can't, because yo'ure a fauxing fanatic.
I just said it's braindead. It is.
You don't know anything, Jon Snow.
We're comparing sepples to dead dogs, now.
No, we are comparing undead dogs to something which lives in the minds of the cultists only, by now. It can't eternal lie, it's vanished.
Namely, that the Lisp community consists mostly of mentally retarded people, and that is a push off of a kind. QED. Oh, wait.
No need to backtrack, acknowledge the truth which you've seen already.
>>161 That's because you don't understand lambda calculus. How the fuck you can claim any deep understanding of any Lisp then is beyond me.
Lisp is not based on lambda calculus.
Look, it's simple. When you want to write "x = expr; stuff ..." in an imperative fashion, you can rewrite it as "(lambda x: stuff ... )(expr)", in a pure functional fashion.
Oh my! You discovered functional programming! Too bad Python is imperative as fuck! Yes, it does have functools, yes, you can do fp with it, yes, it's best practices to separe functional code from imperative one and Yes, GvRhates functional programming, and I'd like to do something similiar to (define (f x) (lambda (y) (begin0 x (set! x (+ x y)))))
Is your mind blown?
Sure (no) If it is, then shut the fuck up and reflect on how this shit is pretty obvious to anyone who understands lambda calculus
Then let me continue. Yeah, yeah, and there's that scheme proposal #754 or something, which no one uses, ever. Because lispers are insecure dumb fucks who don't understand why exactly they have the power and are afraid to change anything lest they lose it.
We are happy with parentheses for a reason. You are missing the point. Code monkeys are OK with VB.NET
Are OK with Java too, what's the point? and are not OK with Lisp.
How can they be not OK with something they don't even know exists? You have to admit that there are bad parts in Lisp, but you also can't, because yo'ure a fauxing fanatic.
yo'ure
Maybe you're right, I can't be objective on Lisp because I'm a Lisp elitist faggot who thinks it's the pure perfection and nothing will ever be as powerful. But Doctor Racket (see previous posts) was pretty objective, IMHO.
Try discussing with him, next time, instead of the fauxing fanatic that I am. (I'm serious, talk with him, you need a doctormight enjoy the conversation) You don't know anything, Jon Snow.
You don't either. No, we are comparing undead dogs to something which lives in the minds of the cultists only, by now. It can't eternal lie, it's vanished.
Haskell is not undead, it was a medium sized dog. No need to backtrack, acknowledge the truth which you've seen already.
Then, why don't you let the thread die?
Wow, so much trolling in this thread.
As for the question >>1 asked:
Lisp can be made into anything, although if you change it too much, it becomes something too different from Lisp, in which case it will either be a DSL or a completly new language implemented in Lisp.
Other languages exist because people made them. Some of them fit niches which Lisp isn't perfect for (C is good for mid/low-level code, although you can of course do low-level tasks in specific Lisp implementations; assembly is required for low-level parts of OSes, required in compilers, may be useful for squeezing performance out of an algorithm (or implementing something some SIMD-like instruction set), of course, assemblers can be implemented in Lisp and called at runtime (or compile-time) just as well). Others (such as Java, C#, C++) are meant to be easier to move to from those that learned to program in imperative languages like Fortran, C, Algol, Pascal (you can thank the educational systems for this).
Having some variety in programming languages doesn't hurt, although it does mean you'll have to learn new syntaxes and APIs which are very much alike each other (once you're familiar with the major paradigms). As for me, I'll be content using CL, C and my platform's assembly for most tasks, at least until I need to interoperate with code written in other languages, in which case I may write code in other languages - it won't kill me.
Name:
Anonymous2011-02-03 9:49
bump pants
Name:
Anonymous2011-02-03 10:04
>>168
>Having some variety in programming languages doesn't hurt
It hurts, because you can only find jobs in C++/Java/C#/PHP/Python, so if all these inferior languages to be exterminated, I could at last find a LISP job and stop being an anti-social revolutionary.
>>174
Actually he didn't become a painter because he was supposed to meet with a Jew, who was murdered because of some kids who took Hitler too seriously. A paradox, if you will.
Name:
Anonymous2011-02-03 12:38
>>175
No. Art College turned off his application, because his drawing style was to empirical and didnt meet abstract jewish tendencies.
i'm going to start over with SICP
from page 1
what's the LUNIX /prog/RAM i should use again? i forgot
Name:
Anonymous2011-02-10 22:29
yes, yes [o][u][sup]H[/sup]ugs& repl& beam[/u][/o] OH MY
Name:
Anonymous2011-02-11 23:15
>think prog is shit because of robots farming threads and every other thread is trolling/autism
>mfw this thread is informative, complex, and has even been pruned for troll spam
Looks like we got some new janitors.
Name:
Doctor Mario!TRiP/.FAG2011-02-27 11:27
ITT NIGGERS TOO SICP DIDNT LISP
Name:
Anonymous2011-02-27 11:46
Lisp is a metalanguage for creating languages, thus the existence of other languages is logic, otherwise, Lisp wouldn't do anything.
Name:
Anonymous2011-03-01 5:40
>>193
If you're good enough to use lisp, you'll soon be frustrated with lisp. Lisp is not an adequate lisp. By the time my bus had made it two blocks I'd written some simple lisp macros that were so powerful they made lisp completely obsolete and replaced it with a new language. Fortunately, that new language was also called lisp. And i was able to prove, mathematically, that the new lisp i'd created was both far superior to lisp in every conceivable way, but also exactly equivalent to lisp in every possible way. I was very excited by this. But also found it very boring.
Name:
BAMPV RANDALL2011-03-01 5:55
>>194 Using only an Emacs and a lisp interpreter, it's impossible to construct friends.
Name:
Anonymous2011-03-01 6:01
h,,
Name:
Anonymous2011-03-01 6:01
* 4)
* 35: I am going to email this thread to GJS (225)
* 36: How get better at being a progamer (15)
* 37: /prog/ whining (38)
* 38: Bluetooth Auth throught DBUS. (22)
* 39: ???????????????????????????????????????? (5)
* 40: TOP 10 BEST THINGS ABOUT /prog/ (20)
>>205
I had begun to seriously doubt MrVacBob's existence as a /prog mod a while before learning of the deletion of >>179,181,183,185. He certainly doesn't give much of a fuck though.
:GJS1M 67dcbdbce4a0b67c4b48e86a6ae29205a95e4b83024a9d947213d1231800e8d9
:67 2e014826be38d8213344e7f740437b67
:1296487765 1299006870 >>169 <-- that's cool and all, but check 'em
>>214
As powerful, or the same as? There are different ways to extend the untyped lambda calculus, and I don't recall ever seeing a "type system power" ranking
Funny, I got a resume that said they knew Scheme and actually cited SICP in their resume. I figured it was some idiot from this board. So me, along with HR did the logical thing. We threw the resume away and then sent this person a letter that basically said to the effect "Never apply here again".
>>225
Good going, mate. Wouldn't want to bore such and enlightened mind to death by programming Kodak's galleries or whatever crud they make in your workshop.