Live data from Hacker News

Lang Jam: create a programming language in a weekend

github.com

101–110 of 135 posts

Re: Lang Jam: create a programming language in a weekend

#101
post #92
post #48

Earlier quoted context omitted.

I'd like a GC (no borrow checker) version of Rust. There's so many cool concepts in the language that I'd like to know how useful it is in different contexts. (Compiled without a VM, option types, no nulls, easy error handling without exceptions...)

We use D a lot at work, we genuinely can only laugh at people who refuse to entertain the idea of a GC. The GC allows our code to exist without extensive memory book-keeping. When we want to avoid the GC we know how, when we want the productivity we use the GC and fuggedaboutit

> we genuinely can only laugh at people

That's perhaps not the best wording.

Nonetheless, I do agree with you. D can be very flexible in that regard.

Re: Lang Jam: create a programming language in a weekend

#102
post #91
post #65

Earlier quoted context omitted.

> code is easier to read when... This is almost always a subjective opinion. I've worked on many projects where people reformat large portions of the codebase to make it "easier to read", and in the end they waste a bunch of time, make using `git blame` a pain, and subjectively either make no difference in code readability or make the code harder for half the team to read. > I'd like the compiler to reformat code...…

> Most people aren't reading code after it's been compiled Ever start a new job with a bulk of code you didn't write? Worse, ever take over code written by novices who ignore common conventions? The whole point is to see if having a standard style is easier in the long run.

Still, why would you be reading compiled code?

Re: Lang Jam: create a programming language in a weekend

#103
post #68
post #48

Earlier quoted context omitted.

I'd like a GC (no borrow checker) version of Rust. There's so many cool concepts in the language that I'd like to know how useful it is in different contexts. (Compiled without a VM, option types, no nulls, easy error handling without exceptions...)

You just essentially described Swift

I feel much at home with Swift, and it is my other favorite language to use besides Rust. I use Rust for server-side things and command-line utilities and Swift for iOS and macOS apps. I know that server-side Swift is a thing that some people do. But I don't feel that Swift would be what I am personally looking for server-side, so I maintain my dream of faster development in Rust with a subset of Rust and a custom compiler :)

In fact I would like to be able to integrate Swift and Rust so that I could also use Rust in my iOS and macOS apps directly. But for now and for the types of applications that I am currently working on it is not worth going down that particular route. But in the future I wish to write some games where I want to write all of the game logic in Rust and use Swift + Metal for the rendering.

Re: Lang Jam: create a programming language in a weekend

#104
post #59

Earlier quoted context omitted.

I've heard the opposite about it, that its predictable performance is one of its strength. Do you have any sources?

Darklang is being rewritten in .Net Flowtype has horrible performance, which in my opinion partially explains why it has lost so many users to Typescript, which has much more predicable and fast performance even though it's written in JS. The project is basically dead

Here is the article about Darklang leaving OCaml, nothing here is about performance https://blog.darklang.com/leaving-ocaml/. It's about ecosystem and dev experience.

About Flow, I've never used it so I can't say, but Rescript (which is written in OCaml) compiles 10 to 100 times faster than Typescript.

Re: Lang Jam: create a programming language in a weekend

#105

Earlier quoted context omitted.

My favourite FizzBuzz is in Haskell, I found it in this talk by Kevlin Henney[0], and looks like this: fizzes = cycle ["", "", "Fizz"] buzzes = cycle ["", "", "", "", "Buzzes"] words = zipWith (++) fizzes buzzes numbers = map show [1..] fizzbuzz = zipWith max words numbers Henney explains in detail in the video, but it makes use of lazy evaluation to create an infinite list of FizzBuzzes, and also uses no if statemen…

"max" seems like an odd choice. Wouldn't that start to fail at large numbers? Edit: Nevermind, max is lexicographic, not based on string length. Brain fart.

Thanks for explaining it!

Re: Lang Jam: create a programming language in a weekend

#106
post #39

Earlier quoted context omitted.

I think you would be better served by a simplified, less optimized code generation, as from what I understand LLVM is the thing that takes a lot of time. You can see this pattern in Crystal and Swift for example, that also use LLVM and are also relatively slow to compile, compared to OCaml or Go which have their own backend.

That is definitely not the case. Compiling C with LLVM is very fast. In Swift, type inference is one thing that can be extremely slow.

That's fair, Crystal seems to also take a lot of time with type inference. However the LLVM codegen is almost constantly slower than the alternatives. For example, Haskell has a non-LLVM backend and a LLVM backend, and the LLVM backend is slower. Zig uses LLVM, and they are working on a non-LLVM backend to speed up development builds. A sibling comment mentioned that the situation is the same for D too. For C, I'm almost certain that TCC is faster than Clang with LLVM.

There seems to be a pattern here. I'm not saying that LLVM is bad, in fact if it's used by so many projects it's for a reason. But it does have a cost.

Re: Lang Jam: create a programming language in a weekend

#107
post #26
post #23

What kind of language ideas do you folks have? What would your fizzbuzz look like? I'm not sure I've ever seen a more readable compact fizzbuzz than this version in coffeescript ['fizz' unless i%3] + ['buzz' unless i%5] or i for i in [1..100]

The usage of `unless` strikes me as unmaintainable and "smart", not in a good way tbh. The types are all other the places, too. What is it even doing exactly? Appending a string to a null value..?

    // Generated by CoffeeScript 2.4.1
     (function() {
      var i, j;
     
      for (i = j = 1; j 

Re: Lang Jam: create a programming language in a weekend

#109
post #91
post #65

Earlier quoted context omitted.

> code is easier to read when... This is almost always a subjective opinion. I've worked on many projects where people reformat large portions of the codebase to make it "easier to read", and in the end they waste a bunch of time, make using `git blame` a pain, and subjectively either make no difference in code readability or make the code harder for half the team to read. > I'd like the compiler to reformat code...…

> Most people aren't reading code after it's been compiled Ever start a new job with a bulk of code you didn't write? Worse, ever take over code written by novices who ignore common conventions? The whole point is to see if having a standard style is easier in the long run.

> Ever start a new job with a bulk of code you didn't write? Worse, ever take over code written by novices who ignore common conventions?

Yes, I have seen lots of this in scientific computing. However, things like too many/not enough spaces, line widths, etc, are never a huge hindrance for me.

What does make code "hard to read" are things like bad and inconsistent variable/function/class names, bad inheritance practices, bad file organization, and not adhering to common language idioms. That stuff is rarely, if ever, caught by linters.

Great talk by Raymond Hettinger about this: https://www.youtube.com/watch?v=wf-BqAjZb8M

Re: Lang Jam: create a programming language in a weekend

#110
post #101
post #92

Earlier quoted context omitted.

We use D a lot at work, we genuinely can only laugh at people who refuse to entertain the idea of a GC. The GC allows our code to exist without extensive memory book-keeping. When we want to avoid the GC we know how, when we want the productivity we use the GC and fuggedaboutit

> we genuinely can only laugh at people That's perhaps not the best wording. Nonetheless, I do agree with you. D can be very flexible in that regard.

I don't know how else to word it. Every thread about D has people going on and on and on and on about the GC, and they aren't always wrong (there is always good information here) but fundamentally it doesn't matter. Many D programmers come from PHP rather than C++ - D isn't attractive to them because of systems programming but rather high level programming e.g. metaprogramming.
Post reply on HN