61–70 of 88 posts
Earlier quoted context omitted.
My favorite way is to output C, which is conveniently human-readable for debugging. Many people also like the LLVM back end.
I new about that possibility but how efficient is it compared to other techniques ?
Earlier quoted context omitted.
When I do PL these days, I always start with the editor; e.g. see: http://research.microsoft.com/en-us/people/smcdirm/managedti... Co-designing your editor with your language allows for a better experience. You are right in that all of this is basically undocumented in textbooks. Even their presentation on on parsing is mostly unhelpful (if you want an error tolerant incremental parser for your editor, recursive desc…
That is really cool. This focus on time is what draws me into the whole clojure/datomic world. We're ill equipped to handle it. Tools help. Does time itself reveal itself as the horizon of being?
One thing that is cool is how time is related to observation, the same thing that happens in quantum entanglement. If you don't observe the state of an object, time doesn't really exist.
Earlier quoted context omitted.
Huh, I interpreted it differently, as in questioning whether Go's interfaces have much in common with Haskell's typeclasses. But now I'm intrigued — does Haskell really have a larger or comparative popularity as Go? That would surprise me, but I don't have any data, do you?
It's remarkably difficult to find anything approaching hard numbers :-) However, I am going off: * http://redmonk.com/sogrady/2015/01/14/language-rankings-1-15... (Haskell slightly ahead in their numeric ranking) * http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... (Golang slightly ahead in their ranking) * Slightly more published books on Haskell that I can find (although obviously it's been around a lo…
I'm not exactly a fan of Go nor am I a fanboy, quite the opposite these days. I don't have to like go to mention that the way interfaces are used kind of accomplish the same thing as typeclasses.
I also feel that (sadly) Go is more popular than Haskell. Partially because of the number of Haskell programmers I've encountered in real life is much lower than the number of Go programmers I've encountered.
If you’re thinking of writing a language in earnest, you will create something much more valuable if you start from a novel semantics, and only then come up with a syntax to express those semantics, than if you were to start from syntax. The world does not need yet another reskin of Java, but it could use new programming paradigms and new ways of solving problems. As a learning exercise, implementing a language is wo…
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 introduced fault tollerant concurrent programming. With isolated heaps (thus fault isolation) and a framework for supervision and distribution. Nobody has popularized that except Erlang so far.
Besides even if you want to talk about CSP, what Erlang has is "Actor" based programming. And even that fell out organically out of concurrency and fault tollerance rather than through academic channels or academic literature survey. Creators at the time didn't even hear about "actors" only years later someone associated the two together.
The author says he turned to Coursera, but doesn't mention the course(s) he took, but I'm going to guess it's the the 'Compilers' class from Stanford[0]. I've heard good things about the course and the lecturer (Alex Aiken) so I really wanted to take the course while it was being offered but was too busy last year. I hope they offer it again this year. https://www.coursera.org/course/compilers
https://dirkjan.ochtman.nl/writing/2012/07/21/compilers-on-c...
Afterwards, I thoroughly overhauled my nascent compiler. It currently lives here:
(It's a Python-like systems language, with a compiler written in Python targeting LLVM IR.)
Writing a compiler is a significant amount of work and should be pre-researched to avoid issues like the above.
If you’re thinking of writing a language in earnest, you will create something much more valuable if you start from a novel semantics, and only then come up with a syntax to express those semantics, than if you were to start from syntax. The world does not need yet another reskin of Java, but it could use new programming paradigms and new ways of solving problems. As a learning exercise, implementing a language is wo…
Indeed. Recently I was inspired to learn K, a language in the APL family. There aren't many implementations available, so I wrote my own. Doing this forced me to come to terms with a whole range of features I might have otherwise shied away from using.
I'm curious - how did you test it for compatibility with the main K implementation?
This hit me, what if variable names CONTAIN types? int__i = 1
And of course, it can be made optional. I will much prefer to do optional typing in the var name itself rather than the ugly syntax that guido has proposed with python.
"that types are often a great name for variables, which both the programmer and compiler can use to easily and effectively understand most common code." This hit me, what if variable names CONTAIN types? int__i = 1 And of course, it can be made optional. I will much prefer to do optional typing in the var name itself rather than the ugly syntax that guido has proposed with python.
> Notice how not a single variable in this code has a name. They all only have types. Pretty cool, never even thought about this being possible.
I mean, if I write a small function doSomething(inputDataString) then when talking about what the function does, I'd just refer to "the string" or "that string" as there really can be no more meaningful name to refer to that. If there are multiple such parameters, only then names start making sense.
Similarly for iteration constructs like java 'for (Foobar foobar : foobars)' - when you're talking about what is done with that single instance of foobar, you just refer to it as 'a foobar' or 'every foobar', and a specific name is often meaningless if you don't need to distinguish it from others.