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

231–238 of 238 posts

Re: A Programming Language Underdog

#231

Post by enthus1ast »

Annatar wrote: post #211
enthus1ast wrote: post #74

Earlier quoted context omitted.

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 lin…

i will thank you

Re: A Programming Language Underdog

#232

Post by dvlsg »

gmfawcett wrote: post #223
dvlsg wrote: post #130

Earlier quoted context omitted.

It really bothered me in python, but for some reason I didn't mind it in F#. Of course, some of that may be related to the fact that I enjoyed F# so much that I was willing to put up with significant whitespace. Or perhaps it's just been too long since I've used python and today it would bother me less.

I thought F# was roughly an Ocaml clone. What significant whitespace does it have?

I'm pretty sure whitespace in F# is one way to control blocks. So anything further indented than an if is part of the if block. I'm definitely not an F# expert though, so I'm sure there's more to it than just that.

I also think there's a way to write F# that doesn't have significant whitespace, but uses a lot more keywords. Verbose syntax, I think that's called. I almost never see examples written that way, though.

Re: A Programming Language Underdog

#233

Post by gmfawcett »

dvlsg wrote: post #232
gmfawcett wrote: post #223

Earlier quoted context omitted.

I thought F# was roughly an Ocaml clone. What significant whitespace does it have?

I'm pretty sure whitespace in F# is one way to control blocks. So anything further indented than an if is part of the if block. I'm definitely not an F# expert though, so I'm sure there's more to it than just that. I also think there's a way to write F# that doesn't have significant whitespace, but uses a lot more keywords. Verbose syntax, I think that's called. I almost never see examples written that way, though.

I can't speak for F#, but it does have its origins in Ocaml, and whitespace doesn't matter there. Try putting that entire if-block (or any other statement) all one one line, just to see what happens.

Re: A Programming Language Underdog

#234

Post by debiandev »

Annatar wrote: post #217
debiandev wrote: post #215

Earlier quoted context omitted.

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, ...)…

> as someone doing precisely this kind of engineering for almost three decades, I can assure you that this is not the case

Same here.

> 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

That's what I wrote: "native package managers should install binaries in /usr/[s]bin and libraries under /usr"

"native" as in: provided by the distribution. Not third party.

https://github.com/nim-lang/nimble/issues/80 is about using /opt/nimble and you wrote "If you implement that, you instantaneously take away the ability to deploy applications through OS's automated deployment", hence the confusion.

Re: A Programming Language Underdog

#235

Post by Annatar »

debiandev wrote: post #234
Annatar wrote: post #217

Earlier quoted context omitted.

"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, ...)…

> as someone doing precisely this kind of engineering for almost three decades, I can assure you that this is not the case Same here. > 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 That's what I wrote: "native package managers should install binaries in /usr/[s]bin and libraries under /usr"…

""native" as in: provided by the distribution. Not third party."

It was a misunderstanding then: I thought native meant the packaging format native to the OS, not packages which come with the OS (bundled software).

Issue 80 from what I understood is about nimble, a packaging format proprietary to one programming language, providing system wide installation capability; this would indeed preclude using native provisioning technologies because those use the OS's native packaging format and hence know nothing of "nimble".

Re: A Programming Language Underdog

#236

Post by evdubs »

soegaard wrote: post #225
13415 wrote: post #187

Earlier quoted context omitted.

Same as OP but posted from another account. Well, it always depends on the application. Here are the main limitations: 1. no internal drag&drop from control to control in a frame or from frame to frame, like from an editor snip to a listbox, or from a listbox item to a text field or canvas 2. text% and editor-canvas% are too slow for some applications, esp. for displaying lots of data fast or styling snips 3. text% d…

Consider posting this on the Racket mailing list. If no one asks for it, we don't know what to implement next.

I added this feedback to racket/gui. Not sure if that's helpful.

https://github.com/racket/gui/issues/115

Re: A Programming Language Underdog

#237

Post by PMunch »

billrobertson42 wrote: post #210
gtycomb wrote: post #175

Earlier quoted context omitted.

yes to all of these -- Nim also has those intrinsic benefits that statically checked and compiled languages bring. Arrays? As pleasantly nimble as Python arrays to say the least. Pointers are lengthy discussion, but suffice to say that pointers are smartly handled to avoid their pitfalls at runtime (while integrating with external C if you really need to) Time time and again as I went through using Nim, what really s…

Thanks. That's very interesting. I don't suppose you're going to tell me that it has Clojure's amazing data structures too. :-)

Well: https://github.com/PMunch/nim-persistent-vector But not built in. The basic data types are very light-weight in their implementations to cover a large range of needs.

Re: A Programming Language Underdog

#238

Post by Annatar »

enthus1ast wrote: post #194
eeZah7Ux wrote: post #190

Earlier quoted context omitted.

> most of them are not even able to install two versions of the same library That's entirely by design. Distributions exist to provide a set of packages that are well tested, and work reliably, together. And then guarantee that such set will stay the same and receive timely security updates for 3 or 5 or more years so that people can reliably use it in production.

and in the real world you do configure; make install then ;) edit: or docker every one i've met so far, uses docker as a kind of "package manager". Database? Oh year use this docker image, elastic search & kibana? shure docker. What they actualy want most of the time is: an easy way to install this stacks, in an non ancient version, where i can actually use the stuff i need to use.

"and in the real world you do configure; make install then"

In the real world, one gets an existing RPM .spec file, edits it for the required source one is about to build, and then runs:

  rpmbuild --clean -ba software.spec
once one has RPM's there is no need for Docker, as multiple applications can be cleanly installed, upgraded or removed on the system, and the entire system can be automatically PXE booted and provisioned by Kickstart without a single line of glue code.

Say no to hacking with Docker and make install instead of formal system engineering.

Post reply on HN