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

211–220 of 238 posts

Re: A Programming Language Underdog

#211

Post by Annatar »

enthus1ast wrote: post #74
Annatar wrote: post #47

Interesting! Minus: yet another proprietary package manager, bypassing the operating system's software management subsystem (operational maintainability) Plus: finally a language which compiles to binary executable machine code. Plus: transpiles to multiple "backend" languages (but transpilers incur a performance penalty). Plus: can link with shared object libraries, thus having instantaneous integration choices with…

i must admit that i'm not a big fan of nimble (nim's package manager; for a few reasons) but on the other site you have apt, pacman, yum, whatelsenot, afaik most of them are not even able to install two versions of the same library side by side. The situation is so bad that most applications these days are packed with `flatpack` or something else, because of the so broken linux package management... In contrast to eg…

A shared object library is supposed to use linker map files during her creation to declare interface versions, so that the run time linker can request and obtain the correct version of the interface. Like all the traditional UNIX operating environments solved it: no need for multiple versions, one library contains all versions and the run time linker maps in the requested code. See how illumos does it. Search for linker map files.

Re: A Programming Language Underdog

#212

Post by y4mi »

jhasse wrote: post #114
y4mi wrote: post #75

Earlier quoted context omitted.

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

> There is, of course, lots of services / software in other languages

Re: A Programming Language Underdog

#213

Post by eggy »

peatmoss wrote: post #104
eggy wrote: 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…

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…

I was using Gambit many years ago, and I remember hitting issues with Windows and Chicken. I do like IUP and Canvas Draw though! I am not a Nim fan, but I don't like Python either, so it's just a subjective syntax thing.

Re: A Programming Language Underdog

#214

Post by JepZ »

dom96 wrote: post #204
JepZ wrote: 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 is a perfect example of how fashion dictates programming language popularity. The language isn't even released yet and people are mentioning it as the next great thing. If it wasn't for Jonathan Blow's successful indie games nobody would bat an eye. That being said, I've got huge respect for the guy. I asked him about Nim in one of his streams and his reply was very courteous and reasonable.

I kind of wonder why everybody is so negative about me posting JAI here. I mean, yes the compiler isn't released yet, but that's why I wrote 'upcoming'.

You write about the 'next great thing', but I was merely talking about 'a better C++ for game development', which narrows it down to a very specific use-case. And I don't know what is wrong about if someone has had some success by building games to also look at the tools he uses for building those?

Besides that, looking at the few examples I have seen I didn't find the languages elegant, but it seems like it got inspired by some other modern languages like Go (e.g., no parentheses for if statements) while explicitly rejecting other ideas like the GC.

Re: A Programming Language Underdog

#215

Post by debiandev »

Annatar wrote: post #209
dom96 wrote: post #203

Earlier quoted context omitted.

oh, guess I shouldn't implement that[1] then :) To be honest, now that I'm thinking about it again, I think you're totally right. 1 - https://github.com/nim-lang/nimble/issues/80

If you implement that, you instantaneously take away the ability to deploy applications through OS's automated deployment (like Kickstart, Jumpstart, or AutoYaST) and you create more work for every system engineer in existence because they have to finish your work for you, namely integration of your software (nim language) into the OS. For every platform nim supports, native operating system package(s), delivering in…

You seem to be confusing /opt and /usr.

> native operating system package(s), delivering into /opt/nim (and system-wide configuration into /etc/opt/nim) should be provided

No, native package managers should install binaries in /usr/[s]bin and libraries under /usr

> Never bypass OS packaging. Unless you are an OS vendor, never deliver anywhere into /usr, not even /usr/local.

+1

Re: A Programming Language Underdog

#216

Post by debiandev »

Annatar wrote: post #208
eeZah7Ux wrote: post #189

Earlier quoted context omitted.

> Minus: yet another proprietary package manager, bypassing the operating system's software management subsystem (operational maintainability) False. Nimble installs packages only in the current user's home. It's one of the few package managers that does not encourage the dreadful "sudo pip/npm/... install"

It's not false: installing any kind of software without using OS packaging, even in one's home directory makes it a hack. It's working for you in your home directory; what if it now needs to work for everyone, or if it needs to be deployed without any human interaction whatsoever?

Nimble is used only at build time for libraries and few tools. Packaging binaries for production is not its use-case.

Re: A Programming Language Underdog

#217

Post by Annatar »

debiandev wrote: post #215
Annatar wrote: post #209

Earlier quoted context omitted.

If you implement that, you instantaneously take away the ability to deploy applications through OS's automated deployment (like Kickstart, Jumpstart, or AutoYaST) and you create more work for every system engineer in existence because they have to finish your work for you, namely integration of your software (nim language) into the OS. For every platform nim supports, native operating system package(s), delivering in…

You seem to be confusing /opt and /usr. > native operating system package(s), delivering into /opt/nim (and system-wide configuration into /etc/opt/nim) should be provided No, native package managers should install binaries in /usr/[s]bin and libraries under /usr > Never bypass OS packaging. Unless you are an OS vendor, never deliver anywhere into /usr, not even /usr/local. +1

"You seem to be confusing /opt and /usr."

It is very unfortunate for me that it seems this way to you, but as someone doing precisely this kind of engineering for almost three decades, I can assure you that this is not the case.

"native package managers should install binaries in /usr/[s]bin and libraries under /usr"

Unless one is an operating system vendor (like Joyent, redhat, SuSE, Debian, Canonical, CentOS, ...) third party and unbundled applications must never be installed into /usr: by doing so, one risks destroying or damaging systems in production in the case where the vendor decides to deliver their own version of the same software, and the vendor's upgrade overwrites one's own software and configuration. Long story short: don't deliver your unbundled software into someone else's space. /usr belongs to an OS vendor and to that vendor alone (vendor in this context also includes volunteer operating system projects one is not a part of).

/opt, /etc/opt and /var/opt exist for a reason. Refer to the filesystem(5) manual page on illumos and the LSB FHS specification, sections 3.13., 3.7.4. and 5.12.:

http://illumos.org/man/5/filesystem

http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#opt...

http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etc...

http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#var...

section 3.13.2., Requirements, explicitly states:

No other package files may exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. For example, device lock files must be placed in /var/lock and devices must be located in /dev.

http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#req...

Re: A Programming Language Underdog

#218

Post by Annatar »

debiandev wrote: post #216
Annatar wrote: post #208

Earlier quoted context omitted.

It's not false: installing any kind of software without using OS packaging, even in one's home directory makes it a hack. It's working for you in your home directory; what if it now needs to work for everyone, or if it needs to be deployed without any human interaction whatsoever?

Nimble is used only at build time for libraries and few tools. Packaging binaries for production is not its use-case.

Ever worked at a financial, military or an intelligence institution? For example, what if the system where the software must be built has no connection to the internet?

Resisting creation of operating system packages, even for dependencies is silly, because doing so is not hard at all: all it requires is reading some documentation, but the knowledge gained can be reused over and over and over again for the rest of one's career. Learning different OS packaging systems is an investment which pays hefty dividends.

Re: A Programming Language Underdog

#219

Post by andybak »

Vendan wrote: post #144
andybak wrote: post #110

Earlier quoted context omitted.

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.

Except my code looks prettier than yours. ;-)

Joking aside and as silly as it is to talk about "objective aesthetics" - surely you can see an argument for "less clutter == better" - as much as you've trained yourself to not see the braces, they add nothing that indentation doesn't already provide other than visual noise.

Re: A Programming Language Underdog

#220

Post by andybak »

AsyncAwait wrote: post #125
andybak wrote: post #110

Earlier quoted context omitted.

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.

My problem with this is that you have to make sure every contributor has the same editor settings. You have to also configure every editor before you can use it to write code in such a language, which is sometimes impractical. Curly braces make this not an issue an they're visible. I don't want to depend on non-visible characters for behavior , but it's only a personal preference.

> My problem with this is that you have to make sure every contributor has the same editor settings. You have to also configure every editor before you can use it to write code in such a language, which is sometimes impractical.

I'm not aware of ever having to do any of these things. I'm not even sure what you mean by "configure". Every editor I've installed has always done the right thing out of the box and every contributor who isn't completely incompetent has done the right thing naturally.

Compared to my experience in curly-brace languages where indentation holy wars about and it's actually painful to read code in with a brace style you're not used to - I have more respect for the wisdom embedded in Python and PEP8 daily.

Post reply on HN