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

141–150 of 238 posts

Re: A Programming Language Underdog

#141

Post by marcosdumay »

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 fragmentation, you are free to surrender your preferences.)

Anyway, perftools are only a must have when performance becomes a problem, step through debuggers are way overrated, there are many features that no amount of libraries or tools will give you, and ecosystems quality matter about as much as size.

Re: A Programming Language Underdog

#142

Post by JasonFruit »

nepeckman wrote: post #137

Nim is my favorite language right now. If you look at the different metrics that we use when discussing programming languages, it might not be the best of any category, but its "good enough" in every category. It might not have as powerful a type system as Haskell, but it's safe enough. It might not be as fast as C, but its fast enough. It might not be as easy as Python or Ruby, but it's pretty easy to get started wi…

That's exactly how I've reached to the language when I've used it: it's a lot like Python, both superficially and philosophically. It's not the perfect language for anything, but it's pragmatism makes it so you don't have to know so many languages.

Re: A Programming Language Underdog

#143

Post by learc83 »

shawn wrote: post #135
learc83 wrote: post #132

Earlier quoted context omitted.

>Especially LuaJIT. In the general case that can't really be true, because the Lua interpreter is written in C. With regards to GC languages in general, if you spend a lot of time working around the GC by doing things like object pooling, which is really just reinventing manual memory allocation, you can get close to a non GC language in terms of performance. GC languages are obviously fine for plenty of use cases, a…

The point of a tracing JIT is that it runs code in an interpreter, then generates machine code for loops and hot spots. By doing this at runtime you can take advantage of knowledge that a C compiler doesn't have. This is why LuaJIT is often faster than C.

>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 performance (also determinism is occasionally required).

All else being equal, GC is always going to be slower than non-GC because a GC introduces unavoidable overhead.

I've worked in this space btw and I've never seen any evidence that LuaJIT is actually faster than C for anything outside of very specific micro-benchmarks.

Re: A Programming Language Underdog

#144

Post by Vendan »

andybak wrote: post #110
krapp wrote: post #64

Earlier quoted context omitted.

To me, braces are simpler and more explicit, but then I drank the C/C++ koolaid. Whitespace is intended for human readability, with spaces and tabs not having any implicitly contradictory meaning. In a whitespace sensitive language, you have to set your text editor to make those invisible characters visible to make certain to only use the correct invisible character, then employ multiple such characters based on the…

I know this has been said before but for me it's as simple as: "Format your code as you would have done anyway but just leave out the curly braces". It reduces rather than increases the number of things I have to think about.

For me, the process is "just write the braces, the editor/tooling will do the formatting for you", so no difference.

Re: A Programming Language Underdog

#145

Post by marcosdumay »

krapp wrote: post #64
bbeonx wrote: post #54

Earlier quoted context omitted.

Actually, I'm curious why people don't like white space sensitive languages. I get the tab v space thing, and there are certainly a couple of other down sides, but none of these seem like deal breakers to me. Given that python was the second language I learned, it's possible that I drank the coolaid early and I'm blind to some things that are truly egregious. So the question is: why do folks completely avoid a langua…

To me, braces are simpler and more explicit, but then I drank the C/C++ koolaid. Whitespace is intended for human readability, with spaces and tabs not having any implicitly contradictory meaning. In a whitespace sensitive language, you have to set your text editor to make those invisible characters visible to make certain to only use the correct invisible character, then employ multiple such characters based on the…

> you have to set your text editor to make those invisible characters visible

Or you set it to replace one with the other, and not bother you.

Re: A Programming Language Underdog

#146

Post by narimiran »

blt wrote: post #115
narimiran wrote: post #45

Earlier quoted context omitted.

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?

I saved the data in .csv and then used that, because not only did I need/want to just plot the results, but I also wanted to explore and further analyse the data in a Jupyter Notebook.

Re: A Programming Language Underdog

#147

Post by mratsim »

ColinWright wrote: post #122
arc776 wrote: post #119

Earlier quoted context omitted.

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

That's excellent - thank you. Assume I'm not a complete numpty, but are there directions for: * Download * Install * Invoke ... anywhere? I'm not at all familiar with retrieving and installing libraries from git, nor with NIM and how/where to install code. All assistance gratefully received. Pointers to existing detailed instructions also very welcome. I can investigate all this myself with trial-and-error, but if so…

Easiest way to start with nim is via choosenim: https://github.com/dom96/choosenim

then `nimble install https://github.com/status-im/nim-stint`

Unfortunately I didn't have time to focus on documentation but the easiest way to get started with Stint is to check the tests: https://github.com/status-im/nim-stint/tree/master/tests.

The casts are there to check binary representation compatibility in the tests and are not needed otherwise.

Alternatively you can check:

- https://github.com/FedeOmoto/nim-gmp, A GMP wrapper (very low-level/C-like and not updated since 2015)

- https://github.com/status-im/nim-decimal, a arbitrary-precision floating point wrapper to MpDecimal (used by python). Unfortunately it's very low-level/C-like at the moment.

Re: A Programming Language Underdog

#148

Post by carapace »

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…

After twenty years of professional Python (mostly) development I have suddenly and recently become a neophyte Prolog programmer.

Bottom line: If you're not using Prolog you are almost certainly wasting your time.

Almost all PLs you're likely to be acquainted with can be thought of as syntactic sugar over Lambda Abstraction. Prolog, from this POV, is syntactic sugar over Predicate Logic. It's actually a fantastically simple language, both in syntax and in its underlying operation, which could be summarized as Logical Unification with chronological backtracking.

I have been working with Prolog for only about two months but I am already way more productive. Typically a piece of code that might have been five pages of Python will amount to a page or less of Prolog. I hasten to point out that 1/5 code means 1/5 of the bugs, but it is also much more difficult to introduce bugs into Prolog code, so the total ratio of bugs per unit of functionality is much lower. Further, Prolog code typically operates in several "directions", e.g. the Prolog append() relation (not function) will append two lists to make a third, but can also be used to extract all prefixes (or suffixes) of a list, etc.; a Prolog Sudoku program will solve, validate, and generate puzzles from one problem description.[1] So you get more functionality with less code and many fewer bugs. It's also very easy to debug Prolog code when you do encounter errors. I'm spending fewer hours typing in code, fewer hours debugging, and I'm still more productive than I was. Looking back, I estimate that as much as half of my career was wasted effort due to not using Prolog.

I'm implementing a sort of compiler in Prolog and I am impressed with the amount of work I haven't had to do. I'm beginning to suspect that most high-level languages are actually a dead-end. For efficient, provably-correct software generated by an efficient development process, I think we should be using Prolog with automatic machine-code generators.

Last but not least, Prolog is old. It's older than many of the folks reading this. Almost everything has been done, years ago, often by researchers in universities. Symbolic math? Differentiation? Partial evaluation? Code generators? Hardware modeling? Reactive extensions? Constraint propagation? Done and done. You probably can't name something that hasn't been explored yet.

[1] https://swish.swi-prolog.org/p/Boring%20Sudoku.swinb

Re: A Programming Language Underdog

#149

Post by jlarocco »

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…

People make the same argument against having dozens of Linux distributions and dozens of window managers. Having a lot of choice doesn't hurt anything, and benefits everybody in the long run.

> 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.

For the most part, "the world" has got behind a small handful of languages. Java, C++, Python, Javascript and maybe a half dozen others make up the majority of real world projects.

> With a small number of languages, work can be put into serious tooling, and fixing compiler bugs, rather than a few devs spread thin trying to keep up with the bugs in their hobby language.

That assumption probably doesn't hold. If the authors of Nim weren't working on Nim, there's no guarantee they'd go work on tooling for some other language. Furthermore, who would decide which small group of languages people can work on?

With the exceptions of Java and Javascript, almost all of today's popular languages started off as somebody's small pet project. The good ones (by some metric, anyway) grew and their usage spread and the not so good ones died out. The best way to make forward progress is to try new things and see what works and what doesn't.

Re: A Programming Language Underdog

#150

Post by shawn »

learc83 wrote: post #143
shawn wrote: post #135

Earlier quoted context omitted.

The point of a tracing JIT is that it runs code in an interpreter, then generates machine code for loops and hot spots. By doing this at runtime you can take advantage of knowledge that a C compiler doesn't have. This is why LuaJIT is often faster than C.

>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.
Post reply on HN