Live data from Hacker News

A Programming Language Underdog

totallywearingpants.com

111–120 of 238 posts

Re: A Programming Language Underdog

#111
post #59

Earlier quoted context omitted.

I'm writing a Scheme interpreter in C++ with the express purpose of easily using Qt from it. It supports call/cc efficiently, which I hope will allow me to write Scheme programs handling GUI ops which use signals/slots behind the scenes in direct mode (basically have (potentially many) Scheme threads of execution instead of callbacks). Another thing that I'm vaguely interested in experimenting with is offering a "rea…

That's a very interesting project. Still, if you're aiming at real-world usage, please seriously consider postponing your own language+implementation (or keep it as a side project) and writing a library for Chez Scheme instead. That would be awesome. Chez is very mature and probably the fastest Scheme available. It's so good that the Racket team is currently converting Racket to Chez as the backend language and compi…

I know about Chez and Racket's effort. The reason I'm rolling my own is that as mentioned I've got ideas to help debugging and typing that I find easier to implement when knowing the system and the system is simple. And that I want to control GC pauses, and get easy interop with C++ (e.g. I can use Qt strings as Scheme strings that way). I also don't want to be tied into a particular Scheme implementation (e.g. some of the GUI apps that I write I will want to run client side in the browser, too). I would be happy to meet with any Chez users/implementors though to learn about its internals etc. I'm looking for Scheme and CL people to meet in London, BTW (https://www.meetup.com/London-Metaprogrammers/ - first meetup soon).

PS. consider it to be a Scheme really optimised for doing work with Qt. It appears that binding Qt well into another language is difficult (Python being about the only one where that was done successfully?), so I'm taking the approach of working "close to the metal" (C++), do things that are better done in C++ (like subclassing widgets) there, then making interfaces to scm as I go (i.e. make it so easy to make interfaces that this is a reasonable approach to do). That way I don't have to do all the work of binding the entirety of Qt, I can use qtcreator as I see fit, I can decide on a usage basis how to interface to a widget (modal in the Scheme view but not modal in Qt's view?, when does it need destruction in that case?). I guess the knowledge or abstractions coming out from this might be portable to other implementations, though.

Also again, I also do have code in another implementation (Gambit) that will have to stay there for the time being; communicating with the GUI via sexprs will of course be an indirection, but given that web programming could work the same way (the Scheme implementation on the server communicating with the one in the browser) it looks like the right approach to try for me. That will also mean that the approach will work with any Scheme implementation as the server (Chez, Chicken, whatever).

Re: A Programming Language Underdog

#112
post #43

By removing the C standard lib and using a custom linker you can get the Hello World down to 150 bytes. Here is a fun read: https://hookrace.net/blog/nim-binary-size/ .

Other than a sort of ELF golf why would dropping the C lib be useful?

> ELF golf

actually turns out to be important in embedded work

Re: A Programming Language Underdog

#113
post #20

I had tried Nim a few years ago, and I liked it, but I am more of a Lisp or C person. I am trying to learn Zig [1] which is intended to be a C replacement - no GC, manual memory management, but avoiding C's pitfalls. Just recently I have been playing with Terra [2] for low level stuff. I am a fan of underdog languages - J, picolisp, shen, xtlang (extempore). [3,4,5,6] [1] ziglang.org [2] terralang.org [3] jsoftware.c…

I think Zig is the most promising of these - they've been able to do very cool stuff early on, such as outperforming C for certain problems, and generating absurdly small binaries. Last time I checked though they hadn't quite nailed their memory-management model and things were still in a state of flux.

Eh, aside from embedded development binary size isn't really a problem.

And at this point, having experience with ATS + Rust, the fact that the memory-management model is still wonky is kind of disappointing.

Re: A Programming Language Underdog

#114
post #75
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…

> I wish the world would get behind a couple well thought out languages that cover most programming needs (functional, systems/bare metal, scripting) and stick with those. uh, thats basically been the case since ... 20 years or so? I mean i dislike java and c like the plague, but they're nonetheless the defacto enterprise standards at the moment for performance critical work and ... everything else. just look at the…

Only Java and C? What about C++, JavaScript, Objective C/Swift, Python, etc.? And there's also stuff like MATLAB and R, which are the defacto standard in their own areas ...

Re: A Programming Language Underdog

#115

I read the article. Still no idea what Nim is good for and why it's better than some other language.. and for which use cases?

A year ago I've started experimenting with Nim as a "faster Python" — put some declarations, change some keywords and you're ready to go — your "compiled Python" is now ~30x faster. Recently I've used Nim for the first time for an official project at my job (at university). Instead of doing a simulation with Python+Numpy, I've decided to do it with Nim, and just plot the results with matplotlib. The whole experience…

Did you use language interop for matplotlib, or saving/loading data files?

Re: A Programming Language Underdog

#116

Earlier quoted context omitted.

I've tried it out and read the Nim book, but I'm not using it for any larger project right now. So here is a biased opinion. Pros: Nim is about as easy to program as Python, has the same speed as C, a working FFI, and all the usual bells and whistles of modern "battery included" languages like a package manager with lots of packages. It is garbage collected, which is good -- about this, some will disagree, of course.…

> It uses whitespace for blocks, like Python. Why is this a con?

It's arguably more error-prone, e.g. Rob Pike justifies Go's decision to use curly braces like so:

>Some observers objected to Go's C-like block structure with braces, preferring the use of spaces for indentation, in the style of Python or Haskell. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code. Our position is therefore that, although spaces for indentation is nice for small programs, it doesn't scale well, and the bigger and more heterogeneous the code base, the more trouble it can cause. It is better to forgo convenience for safety and dependability, so Go has brace-bounded blocks.

Re: A Programming Language Underdog

#117

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?

Due to GC Julia will never be as fast as C, C++ or Rust.

Re: A Programming Language Underdog

#118
post #76
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…

This are great arguments for why we should all just use Java. Great tooling! Lots of high quality libraries! Nothing to make you get out of bed in the morning! Why enjoy anything after all?

GC is a nogo for some stuff.

Re: A Programming Language Underdog

#119

Does it have arbitrary length integers? I've not been able to find any reference to such. Edit: OK, there's a library called "bigints" - it's not clear how "natural" the resulting code will be, but I might experiment.

Try "StInt: A fast and portable stack-based multi-precision integer library in pure Nim"

Being stack based and having some nice compile time evaluation features should make it very performant.

Here: https://github.com/status-im/nim-stint

Re: A Programming Language Underdog

#120
post #16

Another interesting upcoming language ist JAI: https://inductive.no/jai/ Its purpose is to become a better C++ for game development (high performance, simplicity).

> jai compiler – not released yet …

That's ... like the most important part?!?!??

Post reply on HN