Hacker News Reader

Comment by evincarofautumn | Hacker News Reader

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 worthwhile simply to gain the understanding that languages are not magic. To boot, you’ll pick up loads of useful techniques in the realms of parsing, data flow analysis, error reporting, and optimisation.

View on HN

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 introduce zero new language features but combine new language features from a number of other languages. So for example:

Erlang introduced lightweight CSP-based concurrency. Go popularized it.

Haskell introduced typeclasses. Go and Rust popularize them (as interfaces and traits, respectively, the latter also influenced by C++ STL's concepts).

Cyclone introduced linear types. Rust popularizes them.

Smalltalk introduced object-orientation. (More precisely, Simula did and Smalltalk took it to its logical conclusion.) Java, C++, and Objective-C popularized it.

Self introduced prototype-based programming. Javascript popularized it.

CLOS (Common Lisp) introduced the meta-object protocol. Python and Ruby popularized it, particularly in their Django and Rails web frameworks respectively.

Usually popularizing a language involves a good deal of work that's not sexy, notably building up a large standard library, developer tools, a package manager, and a whole ecosystem around the language.

> If you're looking to build something that people will actually use

Why bother? I mean, at some point some bigger "name-brand" language is going to take your feature and subsume it anyway. Why compete for mindshare?

If you really have an idea for some new language semantics, then skip the whole syntax phase: express your language as a DSL in another language you already know, use that DSL to write programs and libraries, and see if it helps you compared to not using the DSL. The great thing about this is that you can still rely on all the features and libraries of the parent language while you're doing this! Your DSL only gives you the option of using the new, extra semantics you wanted to test, where and when it adds a benefit.

Now, of course, this might not work if your idea is for a reduction in or purification of semantics—if, merely by having the option of "calling through" to the parent language, the value of your language semantics is destroyed. But if it's just an idea for a feature? Building an interpreter and defining a grammar and create a whole new ecosystem around it is putting the cart before the horse.

>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.

How do you enforce them as constraints on a method?

    pub trait SomeTrait { ... }

    pub fn some_function<T: SomeTrait>(arg: T) { ... }

> 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 introduce zero new language features but combine new language features from a number of other languages.

This rule doesn't exist among language designers, at least the ones I hang out with. You'll find a mix of innovation and invention in most programming languages.

> Erlang introduced lightweight CSP-based concurrency. Go popularized it.

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.

Saying that Go "popularized" type classes is ludicrous, especially from a language whose type system is weaker than Java's.

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.

It's always worth pointing out that CSP is a language, rather than a concept. Perhaps "CSP-inspired" would be a better choice?

CSP is based on the theory of process calculi: http://en.wikipedia.org/wiki/Actor_model_and_process_calculi

But didn't Go effectively popularize typeclasses through interfaces?

Duck typing (which is what Go supports) has absolutely nothing to do with type classes.

no?

Can you explain how? Obviously at least two people either disagree or aren't privy to the knowledge you hold!

There's a bit of writing on StackOverflow about it:

http://stackoverflow.com/questions/2982012/haskells-typeclas...

The main similarity is that 'methods' are defined 'outside' the data type they belong to. But there are a huge number of differences: Haskell's typeclasses are used for many things that don't look like methods at all, while Go's behave more like a classic OOP interface you'd find in Java.

So, perhaps superficially similar-looking, but they work quite differently in practice.

I suspect a reasonable person might expect you to explain how you came to the conclusion that a language with a smaller or comparative user base / popularity to Haskell "popularised" type classes.

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 lot longer)

I have no doubt that Go will eventually surpass Haskell in terms of popularity, and may even have a slight edge, but suggesting that Go popularized typeclasses smacks of fanboyism, and reminds me - in no small measure - of: https://www.youtube.com/watch?v=bzkRVzciAZg

> suggesting that Go popularized typeclasses smacks of fanboyism

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.

Why do you think they're similar? Is it actually specific enough that it couldn't apply to Pythonic duck typing, or Java interfaces?

How come Go has popularized Type Classes?

They are nothing more than Objective-C protocols that served as inspiration to Java interfaces.

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.

Hi! Is your implementation available for use?

I'm curious - how did you test it for compatibility with the main K implementation?

Sure, here's the repository: https://github.com/JohnEarnest/ok

I don't have a rigorous approach for testing compatibility at present; My starting point was the K2 manual, and I've tried to get as many examples from that working as possible. I have been learning the language as I go, so often I don't realize functionality is missing until I stumble across an existing K program that doesn't work properly.

I'm targeting K5, which is unreleased, so there's a great deal of speculation. I think I have a decent subset of the functionality working now, but most of the time when I write new programs using it I still shake out bugs and unhandled edge cases.

Awesome. I started building a toy C interpreter to the k5 spec (http://kparc.com/k.txt) based on the k4 data structures (http://kx.com/q/c/c/k.h) and documentation (http://code.kx.com/wiki/Cookbook/InterfacingWithC). That k2 manual is a good find.

Cool! Nice to know that I'm not the only person trying to implement K5 from scraps and speculation.

It is certainly a fun puzzle; hopefully kOS is released soon to application developers.

Since you are playing in JS, you might also have a look at c.js (http://kx.com/q/c/c.js), which is the tool KX uses to translate between JS objects and k objects through web socket IPC with a k process (http://code.kx.com/wiki/Cookbook/Websocket). Might be useful to see how Arthur envisioned the k data structure in JS. Also, it would be kind of interesting to have a k5 process running in the browser talking with a k4 process running locally in the 32bit trial...

Agree. I'm (trying!) to do one, and now I only focused in the AST and trying to build the features. Is a waste of effort to rewrite parser/lexers/etc if the core is in constant change:

https://www.reddit.com/r/coding/comments/2ocw2r/how_to_creat...

I wrote a language once where functions were not allowed to return values. All you could do was pass a continuation that could handle the results of that function. Totally impractical language, but it was fun and did force me to think out of the box.

Reply on news.ycombinator.com