Live data from Hacker News

Ask HN: Which programming language should a journeyman programmer learn?

news.ycombinator.com

21–27 of 27 posts

Re: Ask HN: Which programming language should a journeyman programmer learn?

#22

Lisp/Scheme are great brain-expanders. So is APL. For long-term maintenance, the more static typing the better, so I wouldn't use them for anything big, but they're great for one-off problem solving. Before anyone chimes in with " you can do that with macros ," patched-in and after-the-fact typing doesn't count. Go is a strange mix of functional and imperative that, despite its simplicity, is illuminating in its own…

> Before anyone chimes in with "you can do that with macros," patched-in and after-the-fact typing doesn't count.

Why not? Common Lisp macros allow a programmer to implent a new language and to make optimizing compilers. Take for example Coalton, which is a strongly, staticaly, and strictly typed language that can interact with the base language

Re: Ask HN: Which programming language should a journeyman programmer learn?

#23

Lisp/Scheme are great brain-expanders. So is APL. For long-term maintenance, the more static typing the better, so I wouldn't use them for anything big, but they're great for one-off problem solving. Before anyone chimes in with " you can do that with macros ," patched-in and after-the-fact typing doesn't count. Go is a strange mix of functional and imperative that, despite its simplicity, is illuminating in its own…

> Before anyone chimes in with "you can do that with macros," patched-in and after-the-fact typing doesn't count. Why not? Common Lisp macros allow a programmer to implent a new language and to make optimizing compilers. Take for example Coalton, which is a strongly, staticaly, and strictly typed language that can interact with the base language

The base specs of lisp/scheme aren't statically typed. If some lisp-like is statically typed from square-one, that's nice, but it's not really lisp at that point.

If I can copy-paste unmodified CL code into Coalton, and it still runs, then Coalton's typing isn't particularly strict. If I can't--if I have to add some form of escaping or FFI decoration--then Coalton isn't lisp. Not that that is a bad thing--just wasn't what I was writing about.

Re: Ask HN: Which programming language should a journeyman programmer learn?

#24

Earlier quoted context omitted.

In that case, something like Prolog would definitely be a change and possibly a lot of fun to explore but I have no idea about the community. I also liked Chapel [1] a lot when I looked at a couple of years ago (again modulo community). If you are into distributed systems TLA+ could be a nice thing to know though obviously it's not a general purpose language. [1]: https://chapel-lang.org/

@blueslurpee: I'm definitely biased, but agree that Chapel would be a fun language to explore, particularly if you're interested in looking at integrated task- and data-parallelism within a language or distributed computing with a partitioned global namespace. If you do, feel free to reach out with questions/comments/requests on Stack Overflow, Discourse, GitHub, Gitter, etc. [1] -Brad [1]: https://chapel-lang.org/co…

I have a question for you Brad (hope you see this):

How would you characterize the suitability of Chapel for (what is being called) ML-Ops both in terms of work distribution (something like 'Ray' etc.) and interop with ML/GPU libraries and frameworks?

Re: Ask HN: Which programming language should a journeyman programmer learn?

#26

Earlier quoted context omitted.

> Before anyone chimes in with "you can do that with macros," patched-in and after-the-fact typing doesn't count. Why not? Common Lisp macros allow a programmer to implent a new language and to make optimizing compilers. Take for example Coalton, which is a strongly, staticaly, and strictly typed language that can interact with the base language

The base specs of lisp/scheme aren't statically typed. If some lisp-like is statically typed from square-one, that's nice, but it's not really lisp at that point. If I can copy-paste unmodified CL code into Coalton, and it still runs, then Coalton's typing isn't particularly strict. If I can't--if I have to add some form of escaping or FFI decoration--then Coalton isn't lisp. Not that that is a bad thing--just wasn't…

Coalton isnt a lisp, it runs on top of a lisp. Common Lisp provides you with primitives so that you can implement things like this in ways that are much more straight forward than in other languages. This is one of key defining features of being a lisp
Post reply on HN