The Rewards of Creating a Programming Language

Post by jroesch » Fri, Feb 13, 2015, 12:56 AM UTC

runT1ME wrote: post #26

nostrademons wrote: post #23

Earlier quoted context omitted.

If you're looking to build something that people will actually use, you're better off not doing anything novel at all, but rather combining novel ideas that have shown promise in research languages into a package that people might actually want to use for everyday programming. There's a rule of thumb among language designers that your language should either focus on proving out one big language feature , or it should…

>Haskell introduced typeclasses. Go and Rust popularize them (as interfaces and traits, respectively, the latter also influenced by C++ STL's concepts). This is a really ironic thing to say considering Go doesn't have generics, rust doesn't have higher kinds, they don't support any sort of implicit (or global) way of using them as constraints.... are you sure you know what type classes are?

Post by runT1ME » Fri, Feb 13, 2015, 1:13 AM UTC

jroesch wrote: post #31

runT1ME wrote: post #26

Earlier quoted context omitted.

>Haskell introduced typeclasses. Go and Rust popularize them (as interfaces and traits, respectively, the latter also influenced by C++ STL's concepts). This is a really ironic thing to say considering Go doesn't have generics, rust doesn't have higher kinds, they don't support any sort of implicit (or global) way of using them as constraints.... are you sure you know what type classes are?

This may be true about Go, but Rust's traits were very similar to Haskell type classes and now are equivalent in power to Haskell's type classes with several extensions turned on (even though they lack HKTs). As a side note although clunky HKTs are encodable in Rust and I plan on implementing them natively once we have landed a stable version of 1.0.

Post by nemesisrobot » Fri, Feb 13, 2015, 1:42 AM UTC

zellyn wrote: post #28

zellyn wrote: post #27

Earlier quoted context omitted.

This is excellent: I recently worked through this class (at my own pace: you can register for past offerings). I made things a little harder than necessary by eschewing the provided framework code and writing everything myself, in go. I found SPIM super-annoying, but managed to resist the temptation to build a better MIPS emulator. :-) Highly recommend: writing a (very simple) compiler is no longer a black-art-seemin…

Oh, http://github.com/zellyn/gocool : I recommend you steal my tests (bash, sorry!) but avoid cheating too much on the actual meat of the exercises :-)

Post by peteretep » Fri, Feb 13, 2015, 1:47 AM UTC

felixgallo wrote: post #25

nostrademons wrote: post #23

Earlier quoted context omitted.

If you're looking to build something that people will actually use, you're better off not doing anything novel at all, but rather combining novel ideas that have shown promise in research languages into a package that people might actually want to use for everyday programming. There's a rule of thumb among language designers that your language should either focus on proving out one big language feature , or it should…

erlang's concurrency is actors, which is different from go's CSP. And I nearly spat out my tea when you said that Go popularized something Haskell did; and I haven't even had any tea today.

Post by kazinator » Fri, Feb 13, 2015, 1:48 AM UTC

seanmcdirmid wrote: post #15

evincarofautumn wrote: post #6

Earlier quoted context omitted.

It’s not a novel idea, but Wake does it quite well. Most variable names aren’t that useful—they’re just one of many possible syntactic ways to plumb values around.

I've been playing around with an idea to replace variable names with brands. So say you have an argument to a procedure: brand position Position is a point, but is not a distinct type. You can document it centrally and not for each time it is used as an argument to a procedure or as a variable. E.g. def Set(position): ... You have define brands before you can define your procedure, but multiple procedures can share b…

   def Drawline(position, position): ...