Live data from Hacker News

The perfect programming language

cygni.se

51–60 of 108 posts

Re: The perfect programming language

#51

> but as soon as you enter a physics-institution anywhere in the world, FORTRAN likely reigns supreme Not at CERN, but it used to be the case. It's C++ now. > It turns out that FORTRAN is a very good match for the way physicists think about their work I don't even know what this means and I have a PhD in Physics. > You simply specify what fields you have and what pattern they are written in and the computer takes car…

> I'm not aware of Go programs that are particularly efficient.

Go occupies the same niche as Python, Ruby and JavaScript (server-side business logic). Compared to programs in those languages, Go programs are insanely efficient.

Re: The perfect programming language

#52

Wait a minute, Ruby is not on here...

Ruby hits that sweet spot for me. Have you seen Crystal? Ruby, but native. Amazing stuff.

Yes, Crystal is pretty cool. Though I have found that it is hard to compile for different platforms. If you need speed and concurrency, giving jruby a shot is worth a try. It speeds up your code through both being fast and having 'real' concurrency.

Re: The perfect programming language

#53

> but as soon as you enter a physics-institution anywhere in the world, FORTRAN likely reigns supreme Not at CERN, but it used to be the case. It's C++ now. > It turns out that FORTRAN is a very good match for the way physicists think about their work I don't even know what this means and I have a PhD in Physics. > You simply specify what fields you have and what pattern they are written in and the computer takes car…

> efficient development

I think the rationale for that is twofold: that as a static typed language that prefers stack allocation, you can get some very good performance without putting much effort into it, and that it's usually clear what the idiomatic way to accomplish something is. On the latter point, I appreciate golang's simplicity when I need to review other people's code or dig into third party libraries.

For the record, I agree with most of what you're saying. I also don't find it elegant, and most developers I know are eager to work in a different language after spending any amount of time in golang. Its benefits come at the expense of expressiveness, and I never thought I'd be doing things like code gen to work around a lack of generics in 2019.

Re: The perfect programming language

#54
post #22

Their discussion of Haskell starts with the statement that it is "very abstract" and continues with "Do you really need six different ways to implement factorial?". Well, you have six (in fact, many more that six) ways to implement factorial in any (reasonably expressive) programming language. That's like looking at language that has both if/then/else statements and switch statements, and asking "do we really need bo…

> That's like looking at language that has both if/then/else statements and switch statements, and asking "do we really need both?".

Not sure if that jab was intended or not, but Python, one of the most popular programming languages in the world, doesn't have a switch statement, probably for this exact reason. Python programmers use chains of if/elif*/else? statements.

Re: The perfect programming language

#55

Earlier quoted context omitted.

I'd consider C++ as the worst of the worst when it comes to ease of entry. Compared to, say Javascript, Ruby, or Go, Rust has a secondary set of rules that programmers have to learn before they can even do the most simple things. As an experienced programmer, I look at most Rust code with bewilderment. This is after a week of studying the language. I can look at Python and instantly understand what's happening, witho…

> Rust has a secondary set of rules that programmers have to learn The rules are not that hard if you're somewhat familiar with the constraints of functional programming. Rust requires you not to rely on shared, mutable state, unless specifically enabled - thus, by default, you're essentially writing FP code using a 'procedural' paradigm and syntax. It is also possible to do "quick, exploratory" programming in Rust;…

> thus, by default, you're essentially writing FP code using a 'procedural' paradigm and syntax

I've not heard it described this way. It's an idea I can get behind. A lot of the native code I write tends to try and be as functional as possible, or at least avoiding relying on shared mutable state.

And don't get me wrong. I think that Rust is a significant upgrade to the status quo. Perhaps it's just time to keep hacking away at it until it clicks.

Re: The perfect programming language

#56

Earlier quoted context omitted.

Ruby hits that sweet spot for me. Have you seen Crystal? Ruby, but native. Amazing stuff.

Yes, Crystal is pretty cool. Though I have found that it is hard to compile for different platforms. If you need speed and concurrency, giving jruby a shot is worth a try. It speeds up your code through both being fast and having 'real' concurrency.

What do you think of the reliance on the JVM? I've tended to shy away from using it.

Re: The perfect programming language

#57

There seems to be a happy point in languages where it's easy enough to get up and running, but complex enough to come back through and tighten things up. Like how Python allows a secondary file for parameter types in the function signatures. Also how tools like Flow for javascript has the bolt on type checking. To me, the perfect language seems to be one that does the annoying things like that for you and lets the pr…

Rust eases newcomers into the language a lot more than C++ does. As there are plenty of novices learning C++ as their first(!) programming language, I'm not sure why newcomers would be expected to have more of an issue with Rust

Try to write a GUI application, or game, in both C++ and Rust and see which one ends up being more newcomer friendly.

Re: The perfect programming language

#58

> but as soon as you enter a physics-institution anywhere in the world, FORTRAN likely reigns supreme Not at CERN, but it used to be the case. It's C++ now. > It turns out that FORTRAN is a very good match for the way physicists think about their work I don't even know what this means and I have a PhD in Physics. > You simply specify what fields you have and what pattern they are written in and the computer takes car…

> I'm not aware of Go programs that are particularly efficient. Go occupies the same niche as Python, Ruby and JavaScript (server-side business logic). Compared to programs in those languages, Go programs are insanely efficient.

> Go occupies the same niche as Python, Ruby and JavaScript (server-side business logic)

Is this in a world in which Java and C# never happened??

> Compared to programs in those languages, Go programs are insanely efficient.

In other news, compared to walking, bicycles are insanely fast. Also, let's pretend cars don't exist.

Re: The perfect programming language

#59
post #13
post #10

Earlier quoted context omitted.

There is no purpose of having a so complicated language - like c++ or java - that the majority of the programmers don't even know 100% of the language. I think Elm (and somehow Go) fits this category, everyone can learn in less than a week every aspect of it. Another benefit of having a very simple language is the compile time, c++ has a awful compile time, 100kloc can take half an hour, in Elm it takes less than 5 s…

> c++ has a awful compile time I have a thoery that C++ compiler writers obsession with pointless micro optimizations is because C++'s compilation model scales horribly. Thus they desperately want their compiler to be faster. But they are fucked because the more optimizations just slows down the compile times even more.

Currently if you don't go crazy with meta-programming, it is possible to have C++ applications still compile faster than rustc is capable of.

- Use binary libraries (don't build the world from scratch)

- Use incremental compilation and linking (yes I know lld support is kind of working on nightly)

- Start adopting C++ modules

https://devblogs.microsoft.com/cppblog/improved-linker-funda...

https://devblogs.microsoft.com/cppblog/msvc-backend-updates-...

https://devblogs.microsoft.com/cppblog/introducing-c-build-i...

Re: The perfect programming language

#60
post #10

> The foremost is simplicity, that a language should be simple enough that the programmer should be able to know everything about it. Well, no. Translated - "a language should serve the lowest possible denominator". Apart from the obvious fact that it is impossible, it's also definitely not the way to go if you want quality software.

There is no purpose of having a so complicated language - like c++ or java - that the majority of the programmers don't even know 100% of the language. I think Elm (and somehow Go) fits this category, everyone can learn in less than a week every aspect of it. Another benefit of having a very simple language is the compile time, c++ has a awful compile time, 100kloc can take half an hour, in Elm it takes less than 5 s…

While C++ does indeed take lots of time to compile, it is possible to reduce the compilation time quite drastically.

- Write modular applications and make use of binary libraries instead of compiling the world from scratch

- Enable incremental compilation, incremental linking and pre-compiled headers

- Don't go crazy with compile time algorithms / meta-programming

Post reply on HN