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

Ask HN: What programming language has you really excited lately, and why?

news.ycombinator.com

Post reply on HN
Print view View original

101–105 of 105 posts

Re: Ask HN: What programming language has you really excited lately, and why?

#101

Post by MichaelBurge »

msdos wrote: post #93
vorg wrote: post #87

Earlier quoted context omitted.

> for (minion in party) { > Just little things like not having 'for (var minion in party)'. It clears the clutter. Would be even less cluttered if it allowed for minion in party { minion.jumpToTheLeft() } Parens around a for clause when there's braces following are unnecessary.

It'd be less cluttered if "in" wasn't in there.

The shortest is Haskell's:

    forM_ party jumpToTheLeft
Assuming there is a 'party :: [ Minion ]' and 'jumpToTheLeft :: Minion -> IO Minion' in scope.

Re: Ask HN: What programming language has you really excited lately, and why?

#102

Post by veddox »

jlarocco wrote: post #100
veddox wrote: post #98

Earlier quoted context omitted.

I love writing Lisp, it feels not so much like coding but like writing poetry... Unfortunately, it has lots of problems with interpreter interoperability, lack of threading, etc. (unless I simply haven't found the solution to my problems yet). Therefore I often find myself forsaking it for Python, which has the added advantage that my friends will be able to read the code.

All of the modern Common Lisp implementations support threading. I'd almost even say the situation is better than most other languages, because there is very good threading support at several levels of abstraction. First, all of the modern implementations include some kind of implementation specific, low level OS thread wrapper. It's unfortunate that these are all incompatible, but few people need to use them directl…

I wasn't aware of lparallel and cl-cuda, thank you for pointing those out! The only threading I knew of was the implementation-specific kind, which makes for some portability headaches. (Especially as I personally use CLISP instead of the more common SBCL.)

Yes, the standardized definition is a Good Thing. What I meant by "interpreter interoperability" (I probably should have said implementation compatibility) are things like processing commandline arguments, which are not defined in the standard and vary wildly between operations. (Is there a library for that too? I haven't come across any yet, but that might just be me.)

Post reply on HN