Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

thume.ca

Post reply on HN
Print view View original

341–350 of 384 posts

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#341

Post by jodrellblank »

ginnungagap wrote: post #301
jodrellblank wrote: post #248

Earlier quoted context omitted.

When reading about APL recently, arcfide - the chap working on a GPU compiler - has expressed that he likes APL's terse code because you can throw it away and rewrite it without too much trouble. His compiler is around 750 lines of code after 6 years of development, but[1]: " If you look at the GitHub contributions that I've made, I've made 2967 of about 3000 commits to the compiler source over that time frame. In th…

The github link in [1] is dead, where is the repo now? I was curious about that compiler

It would be unfair to leave it without the link to the HN discussion where he explains in detail his reasons for writing it that way and defends against a lot of criticism, and video stream walkthrough of the codebase as of a couple of years ago

https://news.ycombinator.com/item?id=13797797

https://news.ycombinator.com/item?id=13638086

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#342

Post by 256 »

firethief wrote: post #331
gricjeh wrote: post #321

Earlier quoted context omitted.

And then again still, the “best programmer” sacrificed code quality in pursuit of quickly producing features. The article doesn’t define code quality measures but I’d still take the lines of code metric as either not a measure of value in itself or with a massive grain of salt.

That was the right tradeoff for the situation. I think any attempt to use this case study to draw conclusions about maintainability would be a mistake; that's just not what this is useful for.

Hi. I wrote the python implementation. I've had prior experience with compilers and I'm obviously biased but I would say it's quite readable. The main compiler part (without optional features or the LR(1) or lexer generator) is 2040 lines and contains very little magic. It would be easy to translate 1-1 to idiomatic C++ for instance - it would just be much more verbose. eval() is only used by the lexer generator. The metaprogramming could have been avoided by using dataclasses (but the marker used python 3.5).

(To be clear, the optional portions in which I implement SSA, various optimizations, a Hack-style allocator and some ad-hoc codegen is much less readable.)

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#343

Post by smallnamespace »

dymk wrote: post #325
smallnamespace wrote: post #312

Earlier quoted context omitted.

> because that's what we started out with Yes, but not from programming, but from general life experience. Everyone knows what an actual dictionary is, and even non-programmers can easily grasp how a one-way 'map' works. Mutation is also how the real world works. If you want to record something, you write it down—you've just mutated the world, not encapsulated your operation in the WorldState monad. You need to build…

Haskell has maps. You 100% do not need to build a "pile of mathematical abstractions in your head" to use lenses. It's a handful of types and functions. Do you need to build a pile of abstractions in your head to use `std::unordered_map` or getters/setters in C++?

Yes to both? C++ is not a simple language by any means.

For context, I was introduced to FP (SML in this case) around the same time I learned Java, and I still think for the vast majority of coders, an imperative map is much easier to grok than lenses.

The former only requires understanding how values are manipulated and mutated. You're going to need to understand this anyway to write software, since your machine is mutating values in memory.

Lenses however require complex type-level reasoning, so now you must learn both the value language and the type-level metalanguage at once, and your language also deliberately obscures the machine model. That might be powerful, but it is still an additional mental model to learn.

I mean, just look at the Haskell wiki reference: https://en.wikibooks.org/wiki/Haskell/Lenses_and_functional_...

The route to understanding them goes through Applicative and Traversals, which means have a solid understanding of typeclasses.

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#344

Post by vfclists »

lelf wrote: post #241
objektif wrote: post #74

Earlier quoted context omitted.

How do you like D btw? Is it worth learning for a c++ programmer? I find the syntax very appealing.

I find compilation times very appealing. D compiler can compile itself in under 5s (+ 10s for stdlib).

From make clean? On what CPU?

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#345

Post by 256 »

willtim wrote: post #188
anaphor wrote: post #72

Earlier quoted context omitted.

The article says that the instructor for the course cautioned against using Haskell because some people overestimated their competency with it. I think it is actually very likely that people would chose a programming language or system for reasons other than how competent they are with it. E.g. to seem "smart" because you wrote your compiler in Haskell, even though you actually have much more experience with Java or…

Sounds like he (edit: or more accurately, the university) has hasn't taught them enough functional programming and Haskell.

There is a mandatory compilers-lite course at UW and he teaches the advanced version of it, where the project is to fill in pieces of a Scala-lite compiler written in Scala.

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#346

Post by 256 »

geofft wrote: post #79
trishume wrote: post #61

Earlier quoted context omitted.

I agree it's definitely an interesting result and a point in favour of dynamic languages. A caveat is that I'm pretty sure my friend intentionally sacrificed code quality to do it, I don't think you'd find that project as readable and understandable as the others. Another caveat is that you have to be okay with your codebase being extremely magical and metaprogramming-heavy, which many industrial users of dynamic lan…

Tangentially - do you know how fast her compiler was compared to the compiled-language implementations? I have a vague sense that for many applications, interpreted languages are totally fine and reaching for a compiled language is premature optimization, but I'm curious how it actually holds up for a compiler, which is more computationally heavy than your average web app or CLI.

I wrote the python compiler. It's very slow. With the optimizations it's probably something on the order of O(n^3) or O(n^4). One of the test cases took seconds to compile. I made no effort to optimize the compiler speed.

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#347

Post by WalterBright »

jodrellblank wrote: post #248
tigershark wrote: post #160

Earlier quoted context omitted.

There were people with 2k to 10k loc of experience in some language. That seems extremely low for any meaningful comparison and I would really hope that “average” programmers have way more experience than that... I think I was pretty junior after writing north of 100k loc and working on 1M loc projects. And for sure I don’t consider myself highly competent in F# after writing some thousands lines. I agree with the co…

When reading about APL recently, arcfide - the chap working on a GPU compiler - has expressed that he likes APL's terse code because you can throw it away and rewrite it without too much trouble. His compiler is around 750 lines of code after 6 years of development, but[1]: " If you look at the GitHub contributions that I've made, I've made 2967 of about 3000 commits to the compiler source over that time frame. In th…

The code I initially get to work is often pretty large and complex. Then going over it again, I can see how to shrink it and make it elegant. And then again, then again.

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#348

Post by loup-vaillant »

pyrale wrote: post #333
trishume wrote: post #12

Earlier quoted context omitted.

I don't think monadic parser libraries have a real claim to be that difference. All the languages listed have excellent parsing libraries that make things similarly easy, if not by language power than by grammar DSL with embeddable code snippets. I think if any library could make a real difference for Haskell it's most likely to be http://hackage.haskell.org/package/lens , which a Haskeller friend of mine claims coul…

Recoding a viable subset of lens would have taken 50 locs in haskell. Likewise, rewriting parser combinators would not have taken long for experienced devs. The problem here is that requiring people to recode the libs on top of the compiler is disingenuous. And if you ban idiomatic libs, you also ban most online help, tutorials, etc.

(A suitable subset of) Parsec is about 100 lines of OCaml. Implementing a PEG syntax on top of it is about 150 lines of Haskell (or less, I'm a Haskell noob).

Building up the knowledge to get to this point however… nope, those students were better off going hand written recursive descent (or Lex/Yacc, since an equivalent was allowed).

https://github.com/LoupVaillant/Monokex/blob/master/src/pars...

http://loup-vaillant.fr/projects/metacompilers/nometa-haskel...

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#349

Post by lelf »

vfclists wrote: post #344
lelf wrote: post #241

Earlier quoted context omitted.

I find compilation times very appealing. D compiler can compile itself in under 5s (+ 10s for stdlib).

From make clean? On what CPU?

Yes. Zero to working compiler on vanilla MacBook Pro.

Re: Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

#350

Post by new4thaccount »

256 wrote: post #342
firethief wrote: post #331

Earlier quoted context omitted.

That was the right tradeoff for the situation. I think any attempt to use this case study to draw conclusions about maintainability would be a mistake; that's just not what this is useful for.

Hi. I wrote the python implementation. I've had prior experience with compilers and I'm obviously biased but I would say it's quite readable. The main compiler part (without optional features or the LR(1) or lexer generator) is 2040 lines and contains very little magic. It would be easy to translate 1-1 to idiomatic C++ for instance - it would just be much more verbose. eval() is only used by the lexer generator. The…

Sounds really cool! As someone who programs a bit for work to help with automating processes and fun, but is not a computer scientist I'm a little jealous of never having taken a true database, compilers, PLT, or theory of computation course.

It sounds like you and your classmates are top notch and will go on to some pretty freaking cool careers (ex: I'd work at Jane Street if I was not a parent and a lot smarter :)). Out of curiosity, what are the typical places your classmates go upon graduation?

Post reply on HN