4 ms·

The focus on Haskell as an alternative is unfortunate. What about, say, Racket? There's a language that emerged out of PL research, by researchers that clearly

by kenko 14y ago

The focus on Haskell as an alternative is unfortunate. What about, say, Racket? There's a language that emerged out of PL research, by researchers that clearly care about getting programming concepts across to people (The Little Schemer, etc.), that's pragmatically oriented and has a lot of research-derived neat features. Is the problem that there are too few Racket boosters? Racket seems pretty swell to me.

krutulis 14y ago
Good point. The focus on evaluating the success or failure of programming languages as a popularity contest is also unfortunate. There is also the matter of influence. In the mid 80's I took Dan Friedman's (author of The Little Schemer) Programming Languages course and simply had a ton of fun learning all about Scheme & the implementation of languages. I had no idea at the time it would be by far the most important class that I took as either an undergraduate or graduate student. Turns out, one of the most important things programming languages do is influence the way we learn and think about computation. I've learned crucial lessons from Scheme and all the languages I've worked in over the years. To this day, I am perplexed by people so vested in one programming language that they fear instead of savor the chance to work in another. As a math major, a key lesson demonstrated so vividly by Prof Friedman & by the philosophy of Scheme resonated with me personally: the importance of clearly understanding "what depends on what?" and of learning which things can and/or should be made fundamental and which derivative. The Golang Team has looked at their problem domain and, through the creation of Go, has built a striking and innovative statement on what they've judged as fundamental. I welcome their emphasis on selectivity over accumulation and believe there is much to be learned from their choices.
aufreak3 14y ago
Racket's goals appear more pedagogical and the effort they put in (which is bloody awesome for a relatively small team, btw) on the pragmatic aspects is to the extent necessary for teaching. If we, again, ask whether Racket (or any of the features in it such as delimited continuations) can help solve the problems that the Go team wants solved, I still need to scratch my head a bit. For example, V8 has overtaken mzscheme w.r.t. speed and you would (rightly) ask for a comparison with Node today for a class of server applications. (Being a PL buff, I'm pretty familiar with Racket/Haskell, having written and deployed a Scheme interpreter myself.) I offer another categorization - Go is to design where Racket/Haskell is to research. A good part of design work involves intelligent trade offs. In PL research, you're interested in ideas, new ways of thinking, insights, optimization techniques, etc. You're not (usually) interested in taking a new idea and packaging it so it is digestible to a certain class of programmers. Constant factor speed improvements are also not usually interesting to PL research, but very welcome to the pragmatic programmer. Syntax design, for example, is seldom the highlight of a PL research project.

by kenko 14y ago

krutulis 14y ago

Good point. The focus on evaluating the success or failure of programming languages as a popularity contest is also unfortunate. There is also the matter of influence. In the mid 80's I took Dan Friedman's (author of The Little Schemer) Programming Languages course and simply had a ton of fun learning all about Scheme & the implementation of languages. I had no idea at the time it would be by far the most important class that I took as either an undergraduate or graduate student. Turns out, one of the most important things programming languages do is influence the way we learn and think about computation. I've learned crucial lessons from Scheme and all the languages I've worked in over the years. To this day, I am perplexed by people so vested in one programming language that they fear instead of savor the chance to work in another. As a math major, a key lesson demonstrated so vividly by Prof Friedman & by the philosophy of Scheme resonated with me personally: the importance of clearly understanding "what depends on what?" and of learning which things can and/or should be made fundamental and which derivative. The Golang Team has looked at their problem domain and, through the creation of Go, has built a striking and innovative statement on what they've judged as fundamental. I welcome their emphasis on selectivity over accumulation and believe there is much to be learned from their choices.

aufreak3 14y ago

Racket's goals appear more pedagogical and the effort they put in (which is bloody awesome for a relatively small team, btw) on the pragmatic aspects is to the extent necessary for teaching. If we, again, ask whether Racket (or any of the features in it such as delimited continuations) can help solve the problems that the Go team wants solved, I still need to scratch my head a bit. For example, V8 has overtaken mzscheme w.r.t. speed and you would (rightly) ask for a comparison with Node today for a class of server applications. (Being a PL buff, I'm pretty familiar with Racket/Haskell, having written and deployed a Scheme interpreter myself.) I offer another categorization - Go is to design where Racket/Haskell is to research. A good part of design work involves intelligent trade offs. In PL research, you're interested in ideas, new ways of thinking, insights, optimization techniques, etc. You're not (usually) interested in taking a new idea and packaging it so it is digestible to a certain class of programmers. Constant factor speed improvements are also not usually interesting to PL research, but very welcome to the pragmatic programmer. Syntax design, for example, is seldom the highlight of a PL research project.