Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'm turning into a Lisp snob

briancarper.net

Post reply on HN
Print view View original

81–90 of 94 posts

Re: I'm turning into a Lisp snob

#81

Post by whye »

c00p3r wrote: post #80
mjgoins wrote: post #47

Earlier quoted context omitted.

Are you slamming the people of the island state of Java, or the programming language, or both?

I'm telling you that commercially successful hi-tech things in general, and programming languages in particular, should be easy to use for average prople. Java and especially PHP (which is a total mess which was never designed) are the proof of concept. Note that both of them are using C-like syntax. The biggest prof is, of course, the mobile phones market. Usability and simplicity (along with simple visual effects)…

"And yes, Java (and Windows) was designed to use low-skilled labor."

This is an assertion I've seen repeated many times, but never with anything to back it up. Do have any evidence for this, or is it just a feeling that you have? Based on what I've read, Java was designed for use in embedded systems like set top boxes, and the authors wanted to design away some common developer errors. An evolutionary biologist might say that Java was "pre-adapted" for use by low-skilled labor, but I don't think there is any indication that it was designed for it.

Re: I'm turning into a Lisp snob

#82

Post by dasil003 »

lispm wrote: post #67
miloshh wrote: post #66

Earlier quoted context omitted.

Oh, Haskell is also not used very often for those things. It's just my (outsider) perception that Lisp programmers frequently pick on C/C++ as inferior. Haskell programmers instead ask "what can we do to make Haskell performance closer to C/C++?" However, I am doing graphics for a living, and much of it in C++. I am sincerely interested if I can use another language to give me a higher degree of productivity and not…

C/C++ are inferior. C and C++ are very bad as a dynamic and interactive languages. C makes it hard to write secure programs and C++ is just horrible in many ways. But C/C++ are superior as static low-level languages compared to Lisp. The Haskell programmers should really ask themselves how to get closer to C/C++ in speed - especially since the Haskell language implementations (GHC!) are mostly static and code is usua…

The Haskell programmers should really ask themselves how to get closer to C/C++ in speed - especially since the Haskell language implementations (GHC!) are mostly static and code is usually statically compiled - just like C and C++. If Haskell compilers generate slower code or user code is slow, Haskell users have little excuse, only poorer tools and/or poorer code.

Obviously Haskell could improve, but can it be as fast as C? How do you shave the last bit of overhead of type safety and strictness?

Re: I'm turning into a Lisp snob

#83

Post by cameldrv »

jerf wrote: post #45
pavelludiq wrote: post #24

Earlier quoted context omitted.

I'm curious, i rarely see any REAL[1] criticism of lisp, just the old "ughh, my eyes, all those parenthesis, aaa" type of nonsense. Why do you think its a wrong direction? [1] Im not talking about implementations, obviously, Common lisp, scheme and clojure have their problems, im talking about the general idea of lisp.

I think Lisp's philosophy, as explained by Paul Graham (perhaps you've heard of him :) ), is to enable the programmer to do anything they put their mind to. When choosing whether to do the powerful thing or the simpler thing, they will choose the thing that gives the programmers more power, and point out (not entirely incorrectly) that they can wrap up simpler versions for simpler cases with macros. As a skilled deve…

A lot of it has to do with the relative power of context in languages. If I write a statement, what other places in the code could the meaning of that statement be modified? Languages like Lisp let you modify the meaning of things in tons of ways. Languages like Java only let you change the meaning of things in certain carefully restricted ways, like object polymorphism.

In order to understand what is actually happening in any one part of a Lisp program, I may have to understand most of the rest of the program, if it is written in a particularly complicated way. This is usually never the case in Java.

Re: I'm turning into a Lisp snob

#84

Post by c00p3r »

whye wrote: post #81
c00p3r wrote: post #80

Earlier quoted context omitted.

I'm telling you that commercially successful hi-tech things in general, and programming languages in particular, should be easy to use for average prople. Java and especially PHP (which is a total mess which was never designed) are the proof of concept. Note that both of them are using C-like syntax. The biggest prof is, of course, the mobile phones market. Usability and simplicity (along with simple visual effects)…

"And yes, Java (and Windows) was designed to use low-skilled labor." This is an assertion I've seen repeated many times, but never with anything to back it up. Do have any evidence for this, or is it just a feeling that you have? Based on what I've read, Java was designed for use in embedded systems like set top boxes, and the authors wanted to design away some common developer errors. An evolutionary biologist might…

the authors wanted to design away some common developer errors, which average developer cannot overcome.

There is no rocket science in memory management and pointer manipulation, but, from commercial (manager's) point of view, those difficult to find and debug memory issues is the common cause of troubles with schedule and budget, because good programmers are rare, expensive and difficult to deal with, while average code monkeys are cheap in the first place, and easy to hire and replace.

That's why Java is the de-facto standard for corporate in-house development (read - coding fabrics) and no one in that world even considers that stuff like the ability (in theory) to run the same code on a different platform, especially while it is impossible in so-called objective reality. (Just try to run some bloated, poorly designed spring-hibernate-with-dependences project on a platform other than x86).

And finally, consider RoR - same approach, same and big success.

Re: I'm turning into a Lisp snob

#85

Post by whye »

c00p3r wrote: post #84
whye wrote: post #81

Earlier quoted context omitted.

"And yes, Java (and Windows) was designed to use low-skilled labor." This is an assertion I've seen repeated many times, but never with anything to back it up. Do have any evidence for this, or is it just a feeling that you have? Based on what I've read, Java was designed for use in embedded systems like set top boxes, and the authors wanted to design away some common developer errors. An evolutionary biologist might…

the authors wanted to design away some common developer errors , which average developer cannot overcome. There is no rocket science in memory management and pointer manipulation, but, from commercial (manager's) point of view, those difficult to find and debug memory issues is the common cause of troubles with schedule and budget, because good programmers are rare, expensive and difficult to deal with, while average…

> the authors wanted to design away some common developer errors, which average developer cannot overcome.

Even the best programmers make mistakes. When writing for an embedded platform, mistakes can be exponentially more costly and difficult to fix.

All I see is hand waving and misdirection, no facts. How disappointing.

Re: I'm turning into a Lisp snob

#86

Post by c00p3r »

whye wrote: post #85
c00p3r wrote: post #84

Earlier quoted context omitted.

the authors wanted to design away some common developer errors , which average developer cannot overcome. There is no rocket science in memory management and pointer manipulation, but, from commercial (manager's) point of view, those difficult to find and debug memory issues is the common cause of troubles with schedule and budget, because good programmers are rare, expensive and difficult to deal with, while average…

> the authors wanted to design away some common developer errors, which average developer cannot overcome. Even the best programmers make mistakes. When writing for an embedded platform, mistakes can be exponentially more costly and difficult to fix. All I see is hand waving and misdirection, no facts. How disappointing.

If you didn't see any facts it not means that they does not exist. =)

Re: I'm turning into a Lisp snob

#87

Post by klipt »

Perceval wrote: post #20
mechanical_fish wrote: post #8

Earlier quoted context omitted.

And yet Antoine is famous for book-length works, not poetry, and certainly not minimalist poetry. Don't take the lesson too literally. You can, in fact, take too much away. How much you need to put in depends on your artistic goals and, of course, on your audience.

so much depends upon a red wheel barrow glazed with rain water beside the white chickens.

Makes you think, until

you realize you don't even

have a wheelbarrow.

Re: I'm turning into a Lisp snob

#88

Post by klipt »

dasil003 wrote: post #82
lispm wrote: post #67

Earlier quoted context omitted.

C/C++ are inferior. C and C++ are very bad as a dynamic and interactive languages. C makes it hard to write secure programs and C++ is just horrible in many ways. But C/C++ are superior as static low-level languages compared to Lisp. The Haskell programmers should really ask themselves how to get closer to C/C++ in speed - especially since the Haskell language implementations (GHC!) are mostly static and code is usua…

The Haskell programmers should really ask themselves how to get closer to C/C++ in speed - especially since the Haskell language implementations (GHC!) are mostly static and code is usually statically compiled - just like C and C++. If Haskell compilers generate slower code or user code is slow, Haskell users have little excuse, only poorer tools and/or poorer code. Obviously Haskell could improve, but can it be as f…

Isn't the difficulty with Haskell that evaluation isn't strict? Laziness adds a lot of flexibility but there's definitely a time cost to it...

Re: I'm turning into a Lisp snob

#89

Post by klipt »

parenthesis wrote: post #62
ekiru wrote: post #29

Earlier quoted context omitted.

I also feel that Lisp is a wrong direction. Its main problem is the lack of static typing. It is understandable that a language which has existed for so long with relatively little change would lack a static type system, but with as much progress as has been made in research on type systems since then, there is no good reason for a modern language to lack a powerful type system.

There is nothing to stop a lisp dialect from adopting static typing.

Since this point keeps on being brought up, here's a concrete example: Qi.

http://www.lambdassociates.org/

http://en.wikipedia.org/wiki/Qi_%28programming_language%29

Re: I'm turning into a Lisp snob

#90

Post by lispm »

dasil003 wrote: post #82
lispm wrote: post #67

Earlier quoted context omitted.

C/C++ are inferior. C and C++ are very bad as a dynamic and interactive languages. C makes it hard to write secure programs and C++ is just horrible in many ways. But C/C++ are superior as static low-level languages compared to Lisp. The Haskell programmers should really ask themselves how to get closer to C/C++ in speed - especially since the Haskell language implementations (GHC!) are mostly static and code is usua…

The Haskell programmers should really ask themselves how to get closer to C/C++ in speed - especially since the Haskell language implementations (GHC!) are mostly static and code is usually statically compiled - just like C and C++. If Haskell compilers generate slower code or user code is slow, Haskell users have little excuse, only poorer tools and/or poorer code. Obviously Haskell could improve, but can it be as f…

I thought type safety in Haskell is a compile time thing? Where are the runtime costs?

Then I thought that non-strictness (!), non-mutability of data and referential transparency offer all kinds of possibilities for optimizations done by the compiler?

But maybe the 'interesting research' done in the Haskell community is more into fancy type system features that get the author a PhD and not so much into compiler optimizations?

Post reply on HN