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

Linus vs C++, again

realworldtech.com

Post reply on HN
Print view View original

201–209 of 209 posts

Re: Linus vs C++, again

#201

Post by jpr »

Xurinos wrote: post #185
jpr wrote: post #142

Earlier quoted context omitted.

Lisp-1 vs Lisp-2 is about whether functions and other variables are in the same namespace or not. Packages are orthogonal to this. Also, generic functions in Common Lisp don't suffer from nearly the same amount of complexity as can be found in C++: there is always only one signature (lambda-list) for any function name, whether generic or not, there are no implicit conversions, no memory-allocation details, value/poin…

By your wording, aren't CL packages considered to be just an implementation of a namespace? Is there another way to declare symbol namespaces in CL (outside of rolling our own organisms)? I was under the impression that the function signature was not the issue raised... but the fact that the same function name could lead to completely different behaviors depending on a context. In the case of generic functions, the s…

About packages and namespaces:

Package is essentially a collection that maps symbols to values. In CL packages have (at least) two namespaces: one for functions, other for any kind of variables. The reason for this is that when you write the form

    (fun #'a b)
you and the compiler can be sure that 'fun' and 'a' are both meant to be functions. There are both advantages and disadvantages to this.

Re: Linus vs C++, again

#202

Post by cycojesus »

eru wrote: post #85
ramidarigaz wrote: post #81

Earlier quoted context omitted.

I've been meaning to ask this for a very long time: What does the (2) mean? I see (n) in lots of descriptions of calls, but I've never found out what it means.

It refers to sections of the man pages. They are organized like this: 1. General Commands 2. System Calls 3. Subroutines 4. Special Files 5. File Formats 6. Games 7. Macros and Conventions 8. Maintenence Commands

and it's used like this: man 2 write

Re: Linus vs C++, again

#203

Post by chousuke »

tbrownaw wrote: post #193
chousuke wrote: post #164

Earlier quoted context omitted.

The repository/workspace issue I can agree with (though there is an environment variable that you can use to specify a repository outside the current directory), but what do you mean with "conflating branches and repositories"? In git, branches are not a special entity. They are a property of the contents of the repository. The commits form a DAG, which is also a tree, and trees often have branches. A repository migh…

Perhaps a better way of saying that would be that they picked a very unique (re-)definition of what a branch is (something like "pair "). I tend to think of a branch more as "a buch of commits that go together", which seems to fit very nicely with common usage where you have a release branch, dev branch, etc. It just seems very bizzare that people working on the "dev branch" are actually working on entirely separate…

If git has defined 'branch' to mean something different from other VCS, then I think git got it right and everyone else is wrong.

The distributed nature of git (and any DVCS) means developers on the 'dev branch' are working on different branches, even if they all call it 'dev' in their local repositories. Their local development may have started from the same parent, but it's not the same branch. If you send the commits to someone else, they'll be completely separate from the receiver's dev branch until merged.

It seems to me that your idea of the "dev branch" is in git a purely non-technical thing. That is, a branch in some blessed repository that points to the so-far merged efforts of all the developers' dev branches, representing 'current' development.

I think this is a good thing, and I'm yet to be convinced otherwise.

Re: Linus vs C++, again

#205

Post by Shorel »

He falls in the same mistake of many people: thinking that because there's operator overloading in the language, you have to use it. The same for templates.

Most successful C++ projects never use some features. Some even use C macros instead of templates, like wxWidgets. It both works and compiles fast.

Re: Linus vs C++, again

#207

Post by beagle3 »

sophacles wrote: post #139
nitrogen wrote: post #114

Earlier quoted context omitted.

The kernel does use object-oriented paradigms.

The kernel is also shockingly simple. Sure there are some tricky bits, but writing kernel code is very straight-forward. In fact every time I've written kernel code it has always been a "it can't really be this simple" type moment -- but some of that code is still running production machines today so... it must have been. NOTE: this is not me bragging, it's me suggesting the mystique is a bit undeserved.

Well, the kernel is so shockingly simple in part BECAUSE no one let C++ in. And it is a testament to Linus' great leadership and censorship that it remains that way.

Re: Linus vs C++, again

#208

Post by alnayyir »

tree_of_item wrote: post #184
alnayyir wrote: post #134

Earlier quoted context omitted.

It got deleted, a little context so that I understand?

I was under the impression things were easier to understand without context.

Maybe if you find it easier to work with figments of your own imagination rather than operating on actual data, perhaps.

Re: Linus vs C++, again

#209

Post by eru »

eru wrote: post #199
orblivion wrote: post #192

Earlier quoted context omitted.

Not before making easy things hard, though.

You get used to it. The stuff that's easier in other languages than in Haskell is mostly done by hiding distinctions.

Though not completely. Some stuff is made more complicated than necessary because of the choice of syntax. E.g. variadic function in Haskell vs Scheme. Or the the Haskell record-syntax.
Post reply on HN