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

A Programming Language Underdog

totallywearingpants.com

Post reply on HN
Print view View original

151–160 of 238 posts

Re: A Programming Language Underdog

#151

Post by lylecubed »

kungtotte wrote: post #140
lylecubed wrote: post #131

Earlier quoted context omitted.

> why do folks completely avoid a language for a single relatively bland syntactic feature? Personal preference isn't a good enough reason? I don't like white space sensitive languages because I've seen what happens in python when somebody accidentally adds a couple of lines formatted with spaces into a file formatted with tabs. I've seen git and svn mangle tabs. Long blocks are harder to track. Refactoring functions…

Nim disallows tabs entirely, and in Python 3 it's an error to mix the two in the same file. So those errors can't happen anymore. Out of your list, the only one that seems like a real problem is recreating blocks if the code lost all formatting.

You just described two errors that do actually happen and in the next sentence say those errors can't happen anymore. What am I missing here?

Re: A Programming Language Underdog

#153

Post by atombender »

I really like Nim, but one thing that's stopped me from using it for any recent project is the lack of Protobuf and gRPC support, which we use extensively. There are some Protobuf libraries, but they're all incomplete and unmaintained. Being able to generate code from gRPC proto files (either compile-time or runtime generation) is a must.

Re: A Programming Language Underdog

#154

Post by sparkie »

marcosdumay wrote: post #141
fnord77 wrote: post #66

I do not think all this language fragmentation is a good thing. A million little obscure languages that all at the end of the day do the same thing. Yeah, we need language research to keep devising new features and more efficient ways of programming, but this is different. I wish the world would get behind a couple well thought out languages that cover most programming needs (functional, systems/bare metal, scripting…

You know, I'll have to add to the disagreement. Because of all the technical reasons yeah, your way would stop language development, but also because herding cats is a really counterproductive thing to do, every time somebody powerful enough to get a chance tries it, everybody loses in the end. (But you are free to keep thinking this way. Of course, I won't change to your preferred set, but if you want to reduce frag…

Realistically, what features can be provided by the language but not by libraries? If there are many cases, would that not indicate that the language's expressiveness is lacking?

IMO, the goal of languages isn't to provide many features, but to provide constraints, so that programmers can stick to a set of rules that their peers can understand and agree upon. The most powerful language is the machine code for whatever CPU you're using, because there are no constraints, you have all of the power of the processor.

Re: A Programming Language Underdog

#155

Post by singularity2001 »

narimiran wrote: post #93
singularity2001 wrote: post #85

Earlier quoted context omitted.

const hand* ^^ is that a pointer? Are we moving backwards?

No, it isn't. `*` after a name means that the variable/function/type/etc. is public and can be seen/used when you import a module. So the whole expression just means "a public constant string (automatically inferred type) named `hand`".

oh, that was a surprise. thanks

Re: A Programming Language Underdog

#156

Post by learc83 »

shawn wrote: post #150
learc83 wrote: post #143

Earlier quoted context omitted.

>This is why LuaJIT is often faster than C LuaJIT can be faster than C for some code. Just like C can be faster than someone's naive hand coded assembly. That doesn't change the fact that in the general case C is still faster, and there are classes of critical high performance code that have to be written in C (or Assembly, Rust, or even Fortran). Sometimes, manual memory management is necessary to get acceptable per…

What benchmark would convince you? It's easy to dismiss any evidence as a very-specific micro benchmark.

Multiple large programs written in LuaJIT that have better performance than the same programs written in optimized C.

The vast majority of benchmarks I've seen are down to LuaJIT performing specific optimizations out of the box that the C compiler used in the comparison can perform but doesn't.

In particular the last time I looked at LuaJIT vs C++ benchmarks, the C++ compiler flags weren't set allow the use of SIMD instructions by default, but LuaJIT does.

There was another recent example I saw where LuaJIT was calling C functions faster than C in a benchmark. Then someone pointed out what the LuaJIT interpreter was actually doing, and how to implement the same speed up in C.

Java people made the same arguments years ago: "Java is just as fast or faster than C++". You'll notice that after 20 years of comparisons, no one who writes high performance code for a living makes that claim.

Re: A Programming Language Underdog

#157

Post by waterhouse »

sdegutis wrote: post #126
peatmoss wrote: post #104

Earlier quoted context omitted.

If Nim’s compile-to-c is attractive, and you like lisp, how about Chicken Scheme?: https://www.call-cc.org/ What little I’ve done is a pleasure. I like some of Racket’s post-Scheme language features better, but Chicken has a lot of Get Stuff Done libraries (eggs), and compiling a single executable is pretty killer. Racket will bundle up an executable pretty well too, but it’s hard to compete with Scheme -> C -> stati…

The way Chicken Scheme compiles to C is pretty neat actually. It gets turned into a giant chain of function calls, so that the stack never actually returns. So this Chicken code: (foo) (bar) (qux) gets turned into this C code: foo(bar(qux())) When it hits the C stack's limit, it resets the stack and unwinds to the beginning, and starts over again. I think it was done this way to allow call/cc to work without having t…

It also, assuming it follows Baker's original paper[1] (which I believe it does), allocates all objects on the stack, maintaining the invariant[2] that nothing on the heap points to anything on the stack, and nothing in an older stack frame points to anything in a newer stack frame; and, to maintain this invariant, it kicks things out of the stack and onto the heap whenever necessary. The stack thus serves as a nursery in a kind of generational GC.

[1] "CONS Should Not CONS Its Arguments, Part II: Cheney on the M.T.A." http://home.pipeline.com/~hbaker1/CheneyMTA.pdf

[2] "CONS Should not CONS its Arguments, or, a Lazy Alloc is a Smart Alloc" http://home.pipeline.com/~hbaker1/LazyAlloc.html

Re: A Programming Language Underdog

#158

Post by shawn »

learc83 wrote: post #156
shawn wrote: post #150

Earlier quoted context omitted.

What benchmark would convince you? It's easy to dismiss any evidence as a very-specific micro benchmark.

Multiple large programs written in LuaJIT that have better performance than the same programs written in optimized C. The vast majority of benchmarks I've seen are down to LuaJIT performing specific optimizations out of the box that the C compiler used in the comparison can perform but doesn't. In particular the last time I looked at LuaJIT vs C++ benchmarks, the C++ compiler flags weren't set allow the use of SIMD i…

Java is just as fast or faster than C++ most of the time. No one who writes high performance code for a living makes that claim.

It's true though. https://lmax-exchange.github.io/disruptor/files/Disruptor-1....

Re: A Programming Language Underdog

#159

Post by bayesian_horse »

There is a race going on for the first language not being javascript being compiled to javascript/webassembly and actually worth using.

No, coffee-script, typescript and the like don't really count, they are relatively thin layers. Several options are in the works. Implementations of Python and .Net (Blazor). Languages like Rust or Nim.

The crucial point is that it needs to have a compelling framework like vuejs or react. Then the toolchain needs to be superb and result in small enough webassembly packages.

No project is currently achieving this, to my knowledge. But the race is heating up!

Re: A Programming Language Underdog

#160

Post by marmaduke »

leephillips wrote: post #92
marmaduke wrote: post #70

Earlier quoted context omitted.

It’s no different from ecosystem/library fragmentation within a language. For example, there are at least six approaches to accelerating numerical code in Python (weave, plain C + ctypes, Cython, f2py, numexpr, numba) each with its own cognitive load, interop and debug problems (Julia advocates rejoice, but it’s coming for them too). It seems like a community needs huge incentives to avoid churn and fragmentation eg…

"Julia advocates rejoice, but it’s coming for them too" Why do you say that? The whole point of Julia is to create a language that's similar to Python in ease of development but is natively fast. Do you think it fails at this?

I think Julia was well designed to stay fast for a long time, for many tasks. But anything that isn’t universally optimally addressable by a Lispish front end to LLVM JIT is going grow multiple approaches that aren’t fully compatible, in the same way that Python, not built for speed of execution, grew multiple approaches to fast code ( just realized I forgot about PyPy in my list above). So I expect there to be multiple eventually incompatible approaches to AOT compilation, web frameworks, GUIs etc. Julia’s youth restricts divergence in the short run but long run I think divergence is a healthy part of any ecosystem, and not to be disparaged as in the post I originally replied to.
Post reply on HN