/techbunker/ - Technology (Bunker)

(not (best_language (eq "lisp")))

>>350

>(best_language (eq "lisp"))

This hurts on at least three levels.

>>350

eq takes at least two arguments you dingus

you clearly don't even know how lisp works

>>353

It also doesn't work on strings and nobody uses snake_case in Lisp. Top LARP.

:- pred lisp_is_best is erroneous.

don't even have to write the code now.

>almost 2020

>other languages still don't have conditions and restarts

I'd love to shitpost about it but honestly it's depressing.

Lisp describes the way its creator and users talk.

I love lisp but if you're still calling it "LISP" you probably haven't learned scheme, CL, or clojure as LISP generally means everything before common lisp - which is radically different from modern lisp.

>>618

FUCK LISP, SAY HELLO TO "C"

HIGHER LEVEL LANGUAGES ABOVE BINARY, ASSEMBLY AND C, ARE FOR MORONS.

>>618

>hurr durr he doesnt join my PL club and adopt all our terminology

YOU MISS A NEAT TIME SAVING FEATURE IN A HIGHER LEVEL LANGUAGE? WELL THEN FUCKING CREATE A CODE UNIT OF C THAT DOES THE SAME FUCKING THING, AND JUST COPY AND PASTE IT WHEN NEEDED.

EVEN BRAINFUCK IS A BETTER CODING LANGUAGE THAN FUCKING LISP

>>644

>That's so wrong though you are far from the truth my friend.

Taking that literally yes, Lisp is way more capable than Brainfuck, but only because of the terrible Input / Output capabilities of the

original version. You can easily write your own compiler for your own version of Brainfuck to include file reading and writing, or graphical output.

>>650

>Lisp is far easier to use than brainfuck and far faster. Your arguments are simply invalid my friend. With my apologies.

Did you ever learn how to use the copy and paste function in text edit? Or is that simply beyond you? Have you ever written your own functions in low level code and then copied and pasted them as units of a higher level code? Lisp was made for idiots like you who cannot code for shit. This goes for all objective orientated programming full stop, and there is nothing stopping you from programming in an "object oriented" manner in a functional language. OOP has no interest in efficiently doing anything. OOP is nothing but semantic word games (calling lines of functional programming code "Objects"), and separating the baby-like retarded OOP-programmers from what is actually happening in their own code. At its best OOP can allow dim people to code. Lisp is a lazy/stupid persons language, the only reason you would want to use it, is if you are maintaining legacy code.

>>661

It's like you describe all the things lisp invented and then somehow it does not occur to you that the programming languages you use came after lisp and stole their ideas from lisp.

>>489

You can thank Eunuchs worshippers and "close to teh hardware!!!111" faggots for ignoring anything better.

Lisp (especially Common Lisp) is so good that almost all arguments against it boil down to strawmen, ignorance or bad faith.

>>661

If this wasn't pasta already, it is now.

>>689

It is like, Lisp did not invent anything that didn't already exist. It is a certain flavor of coding short hand that uses imaginary "objects" OOP, that allows the masses to code. And Lisp fails to even be a GOOD OOP coding language. It is needlessly confusing and complicated sometimes, for no reason. C++ may be bloated and confusing at times too, but it can do everything Lisp can and more.

>>704

>You can thank Eunuchs worshippers and "close to teh hardware!!!111" faggots for ignoring anything better.

Because there isn't anything better, most of the unsolvable bugs in complicated Lisp, Python and C++ programs with thousands or millions of lines of code are due to the code language and code compilers themselves. Functional programmers have written all the OOP languages. Good Functional programmers write their own higher level languages routinely in order to save time, when performance time and resources are not an issue. And then use the lowest levels of programming when they are needed, (undecipherable bugs, hardware incompatibilities, tiny micro-controller chips, esoteric operating systems, Or file size and speed limits).

Common Lisp did kill Lisp. Period. (just languages take a long time dying …) It is to Lisp what C++ is to C. A monstrosity that totally ignores the basics of language design, simplicity and orthogonality to begin with.

Whoever does not understand Lisp is doomed to reinvent it

all languages are ok

>>727

This has to be one of the best textbooks examples of an opinion that is constantly parroted, yet never elaborated further, because there isn't any basis to it.

You only say so because you've swallowed the small=good, large=bad mantra that /g/, /tech/ and other retarded boards promoted.

You know what actually killed Lisp? Scheme. Its reputation as "the world's most unportable language" is justified. It spawned millions of incompatible dialects which all badly reinvent what Common Lisp gives you for free.

This isn't to say Common Lisp is flawless, but it's almost always criticized for all the wrong reasons by Scheme fanboys.

It's also ironic that you make this comparison using C and C++, since, as bad as C++ is, it's still less bad than C.

it is often said that small is beautiful.  now, anything can be beautiful
when it is small.  the ugliest person you can think of was probably a quite
pretty baby.  it doesn't take much effort to find a beautiful 16-year-old
girl, either.  in fact, our modern notions of beauty and elegance are
_defined_ in terms of size and maturity, so the chance of anything small
and immature being beautiful is vastly higher than anything big or mature.
now, despite all the marketing that seems to be aimed at telling me that I
should dump a girlfriend when she becomes 25 and get a new 16-year-old (or
even younger), I plan to stay with mine partly because of her ability to
grow older in a way I like.  consequently, I take exceptions to the
pedophilic attitudes to beauty and elegance that our societies have adopted
over the years.  this is why I don't like the "small is beautiful" model of
aesthetics.  this is why I think that almost anybody could make something
small and beautiful, but only a few can create something that grows from
small to huge and still remains beautiful.  but then again, look at
interior architecture -- with huge spaces come a need for size-reducing
ornamentation.  the scaling process _itself_ adds "junk" to what was "clean
surfaces" in a small model.  Schemers refer to Common Lisp's "warts", and
prefer to think of Scheme as "clean".  now, I wonder, would Schemers prefer
to live in small houses with nothing on their walls?  would they still
prefer this if the walls were a 100 feet high and 200 feet long, or would
they, too, desire some ornamentation that would have looked _very_ bad if
it had been on a 10 by 20 feet wall?

Scheme's single namespace is a function of its size.  Scheme with more than
one namespace _would_ have had bags on its side -- it would be very
inelegant.  however, as applications grow and as Scheme environments grow,
the single namespace becomes disproportionately _small_.  therefore, people
resist a growth path that would have been natural, because their notion of
beauty forbid it.  Common Lisp with a single namespace would be confined
and forbidding, for the same reason.  an analogy may be in order.  in very
small towns, houses may have unique names.  as the town grows in size, this
becomes too hard to even imagine working, and houses are instead numbered,
and the number space is managed by a street name.  as the town grows more,
streets in neighboring towns it merges with may have the same name.  but
towns have names, too, and states may have many towns.  the United States
has lots of towns with the same name.  there are even towns that bear the
name of countries in the global namespace.  some people may still wish to
name their house, but it would be foolish to hope that that name would be
globally unique.  all over the place, we invent namespaces to manage the
huge number of things we deal with.  in Scheme, there are few things to
deal with, so few names are necessary.  in Common Lisp, there are many
things to deal with, so means to keep names apart is _necessary_.  in
consequence, Common Lisp has packages and symbol slots and namespaces.

why is a single name space bad for you?  in addition to the reasons given
above, I'd like to add a problem as a conclusion: nothing restricts your
growth path more than a restricted ability to name your inventions or
creations.  the psychological factor known as "cognitive load" imposes a
very heavy burden on our design, namely by having to avoid excesses in that
load.  a single namespace is good if you have few names, and more than one
namespace would be bad.  at some size of the set of names, however, a
single namespace becomes bad because what you once knew (namely, what a
symbol meant), _ceases_ to be rememberable.  namespaces introduce context
to a language.  I think communication without context is a contradiction in
terms, so naturally I applaud such introduction.

>>726

<i have absolutely no idea what i'm talking about: the post

>>750

><i have absolutely no idea what i'm talking about: the post

YOU DON'T DO YOU! NOBODY IS GOING YO PRY YOU AWAY FROM YOUR OVERLY VERBOSE, IMPRACTICAL UNPRODUCTIVE BOYFRIEND. IT IS AN EMOTIONAL THING. YOU CAN'T CODE.

And strings in Lisp….. poor lispers.

http://cl-cookbook.sourceforge.net/strings.html

>>749

>You only say so because you've swallowed the small=good, large=bad mantra that /g/, /tech/ and other retarded boards promoted.

No, YOU ARE RETARDED. A language can be big / OO and lack direct access to the lowest levels, contain language/compiler bugs, be slow, Be needlessly verbose and full of bizarre object-like concepts, hide inner workings away from the retarded user etc.

BUT, this can be justified, if it actually saves some time, and Isn't too defective.

Procedural programming > Functional > OOP

>>749

>C and C++, since, as bad as C++ is, it's still less bad than C.

HAHA, YOU ARE TOO STUPID TO COLLECT YOUR OWN GARBAGE. YOU HAVE NO PROBLEM WITH MOUNTAIN-LOADS OF UNDEFINED BEHAVIOR. YOU HAVE NO PROBLEMS WITH BUGGY STANDARD LIBRARIES. YOU NEED MOMMY C++ TO HOLD YOUR RETARDED LITTLE HANDS EVERY STEP OF THE WAY EVEN THOUGH SHE IS A BAD MOTHER.

"Within C++, there is a much smaller and cleaner language struggling to get out. […] And no, that smaller and cleaner language is not Java or C#."

-Bjarne Stroustrup

Some of the semantic elements that have been left undefined involve even simple concepts like the execution order of function calls:

foobar(foo(), bar());

It is not defined, whether foo() will be called before or after bar() has returned. That’s just silly.

Operations, such as division by zero, integer overflows or out-of-bound memory access will also result in undefined behavior. Granted, these things should not occur and can generally be avoided if the code offers even a slight hint of quality. However it would still be nice to have a well-defined behavior here, especially when talking cross-compiler and cross-platform.

"C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C [for Git] were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C."

Linus Torvalds

>>772

>>771

>>774

>>776

>>781

>>782

t. deranged individual (because it's clearly the same poster who wrote all these) who has so little knowledge of what he's talking about and so little actual arguments that he literally copypastes Xah Lee's website (implying the size of a standard is somehow relevant to anything) and an outdated Torvalds quote.

>>816

>who has so little knowledge of what he's talking about

People who say that without demonstrating in any way how that is the case generally have no argument.

>>816

>implying the size of a standard is somehow relevant to anything

Giant standards are not good in any way. Use your amazingly omnipresent insightful mind to work out why that is so…..

>>816

>so little actual arguments

you have given no arguments………none what so ever. You like coding languages that attempt to code for you , because you are too mentally handicapped to code.

>>816

>copypastes Xah Lee's website

copy-pasting is illegal on 8kun apparently. No mate my opinion is shared by many people, that is the point of quoting others.

>>816

>and an outdated Torvalds quote.

how in the fuck is that outdated, when the very same criticisms apply to the same fucking language, and Torvalds still feels the same way about c++ as do many other people.

>>816

Your Brain is a fly and you are attracted to shit. Thanks, for removing yourself from the coding gene pool. I am not going to stop you, just be the moron you were born to be.

>>853

….. ha

HAHAHAHAHAAAA

omg……

HAHAHHAHAAAAAAA

oh my god, you can run lisp on a computer…

HAHAHAAAAAAA

well done.

>>853

>Yeah well im posting this on a lisp machine, so your argument is moot. Lisp is the technical wonder achievement of our civilization.

Are you serious? you must be joking……

YES, we got another schizoposter back on the board.