You can't just say you worked at Be and not tell more stories! When were you there and what did you do? Why do you think you didn't take over the world? Have you tried Haiku?
indeed. Be belongs to a list of companies that would be great to hear insider stories about. also NeXT, Thinking Machines, Symbolics (sp?), Infocom, Cray, etc
Yes, as I understand it, is_computer_on and is_computer_on_fire were basically no-ops to benchmark kernel calls. One returns an integer and the other a double. But I could be very wrong, I have absolutely zero authoritative knowledge and this is simply an explanation I once heard that made sense to me.
BTW, this site (everything2.com) suffers from some malicious ad script. If viewed from desktop, everything is ok, if viewed from android browser, it displays this: http://imgur.com/eWUjwHr (text means: "to view this site, UC browser is required", this message cannot be dismissed).
What was Everything2 supposed to be? I remember it was almost like a Wikipedia thing that never really matured and it always seemed really slow. The Blockstackers guys from Slashdot built it, didn't they?
Aw, man. The perennial question of that site. What was it supposed to be, really? Roughly, it was just about anything that you could express with basic HTML and pure text. No images, no videos. It was,
* An online encyclopedia before Wikipedia
* A meme central before 4chan
* A social network before Facebook
* A blogging platform before blogs
and several other things. About the only thing it wasn't was a news aggregator, because that was already covered by Slashdot by the same crowd. Its fashions changed with the ebb and flow of users and admins.
It was a sister site of Slashdot (at a time, Slashdot would link to everything2 articles in order to define terms), and also associated to sites like the defunct JavaJunkies and the somehow still living Perlmonks, which shared the Everything engine as a codebase. The idea was to monetise the engine like Wordpress and Drupal later did, but this never happened, and Blockstackers Intergalactic folded soon after that.
Kind of a more loosely structured WikiPedia, with fewer rules and a lot more opinion. It's probably more comparable to the original wiki wiki web, by Ward Cunningham (c2.com, which contains a little bit of everything, kinda like everything2), though it evolved in different directions. It developed more focus on creative writing and commentary over the years, with less emphasis on encyclopedia style articles or technical articles, though I haven't paid attention to it in like a decade. I was very excited about it when it first came about, though.
It was closely related to Slashdot, but when Slashdot was sold, E2 remained independent.
Some of the profits of the Slashdot sale went to Blockstackers as an investment to develop E2. Unfortunately, the dot-com crash (and, to be fair, not enough effort spent marketing the software) meant there was little market for the underlying CMS.
There was a time when everything that managed content in some way was being renamed "CMS" in order to fit into a category that was selling at the time. Fitting sometimes very oddly shaped things into the category was common, and I think a lot of cool software got needlessly mangled (TWiki also went off in a lot of weird, occasionally "CMS like", directions to satisfy some sort of enterprise dream that hurt its usability in a lot of ways).
It wasn't great, though for 2000-era mod_perl code, it was decent. It had a lot of solid ideas that predated the Rails-wave of web development, but they could have used a lot more polish.
That's good to hear. It (and a python-based rewrite) was one of the first software projects I looked at and had a chance to mess with when I began to learn to code.
A mixture of personal blogging, story telling, factual content, recipes, reviews, mixed in with a 'chat room', a voting system, and the ability to 'soft link' nodes to each other through titles (hard to explain). Back in the late 90's/early 00', there was nothing like it. It was an incredibly fun place to be.
Had a massive community at one stage, and an active IRL scene. Some of the meetups were crazy fun. Site is still going and the code is maintained to this day.
Better: the Newton had, as part of the NewtonScript language reference, a built-in "IsHalting" function which tested a function and determined if it would halt with a provided input.
I was just thinking about BeOS the other day. If you recall, Be had fantastic multithreading, and could render multiple video streams at the same time. They even gave you a file on the distribution CD to test this capability:
I keep hearing about Be's mt capabilities, but I haven't read anything in detail. Can you point me to some materials that explain how it's different from e.g. Linux?
Yeah... It's been years since I thought about this, but: for linux you basically have two options: fork() and pthreads. Fork creates a new process and IPC between the parent and daughter processes can be cumbersome - and it's not a terribly good system since if you're spawning a process to do a different task, the default state contains overhead of the old task. Pthreads gives you shared memory (and simple mutexes to protect critical data) but that's about it.
Beos' app model discouraged the use of fork() - but you could if you wanted to - and instead had a pthreads-like kernel level support for threads with some very nice C classes that handle message-passing and the like; interthread communication was baked in in too so you could have strong IPC without pipes. BeOS also came with a hybrid spinlock-semaphore mutex called the 'benaphore'.
There were some very excellent C++ wrappers for all of these too, the BLooper class was a by-default message handling loop (for example).
Finally, the threading model was pretty cool, it was a logarithmic stochastic time allocator with a range of "hard priorities" that would give you RT control (but could also freeze your machine if you had an infinite loop). Unfortunately the kernel had a tendency to thrash threads between CPUs in a multi-cpu setup. I think this was fixed in Haiku.
I'm no expert, but you might find the BeBook, which "...details the Application Programming Interface (API) to the BeOS operating system," to be an informative starting point (though you won't find a comparison with Linux there). There are chapters on "Threads and Teams" in the two sections on the "Kernel Kit" (that's as far as I looked, maybe other parts of the book would be more informative).
I never saw the internals, but from a coder's standpoint the thread switches were really fast, with low latency. Compared with Windows NT and OS/2, way faster on the same hardware. I don't have a comparison with Linux, as it was just getting started back then (IIRC, Slackware was the leading distro of the time)
That's pretty much the behaviour on anything that isn't a BeBox. I had a program I wrote that used this on my BeBox and when I moved to 5 Pro on a Pentium it kept giving the same tempurature.
'best practice' is a difficult concept when it comes to naming things, which is one of the two hard problems of computer science.
However, I agree with ariel. In a functional-style program, or indeed in most programs, the important thing about a function is what it returns, not what it does. Calling a function 'getRandomNumber' describes the action of the function, not the return value, which is just 'randomNumber'. As your example shows, the logic in English flows much more naturally with the latter.
It's much better to talk about the box.size, rather than the box.getSize, for example. To me, the presence of 'get' in a function name is almost always a bad idea.
Similarly, I normally use the word 'as' rather than the word 'to' when naming conversion functions, e.g. list.asArray, rather than list.toArray
With setters, you're implicitly working in a mutable world, at which point it makes sense to name it for the action, so I think you have to use 'set'. So I would have x() and setX(), instead of getX() and setX().
In an immutable world where you're making a copy (perhaps even through a lens), then I often use 'with', e.g. myNewObject = myObject.withX(12.0).
I guess on many occasions, the get/set could also be avoided by thinking about the usage a little deeper. Take HTTP frameworks for example:
getHeader()
setHeader(key, val string)
could also be defined as:
requestHeader()
responseHeader(key, val string)
I must admit I'm someone who, despite best efforts to give meaningful and consistent function names, often ends up with something less standardised by the time projects start to grow, deadlines loom and fatigue sets in (I'd imagine this is probably true for most people - if we're completely honest). But it's always good to get (if you pardon my pun) reminders and advice about sane naming conventions.
Yeah, naming things is hard. Harder than most other things. There's always trade offs and it's heavily dependent on personal preference.
That said, I think your ideas here are good. 'Get' and 'Set' really don't convey that much information, whilst your code above makes it clearer what is going on.
I like 'xIs' for mutators, because it reads more like English, and the important part of the name ('x') is first. I find that convention makes it easier to scan code by name and sort.
Some languages provide you with a mechanism to deal with that (c#s properties), and many others allow you to get a similar result with function overloading. So you don't have getX() and setX(), you have X(), and X(int x)
While function overloading is a neat trick, I think it's a step backwards in terms of code readability.
In those instances, it's only clear from the usage rather than the name how that function behaves, so I think I'd rather see getX and setX over X() and X(int x) and be absolutely clear about the role of that function.
Personally, I don't agree with that because it makes things harder to read. I always use is_something (or isSomething, depending on the style used) form for functions that do some check and return a boolean value. It's really easy to notice such functions when reading code and understand their intend. Proposed computer_on_fire() is by far the worst example, the intention of such function is not clear by it's name and I would have to look it's definition/description to understand what it does. TL;DR using prefixes like is, set, get makes code much more readable.
EDIT: for your random number function I'd simply use get_random_number(x, y) too.
Yup. It's important to have functioning code that mere mortals can understand most easily. Because the code represents system behavior and people need unambiguous conventions to reduce misunderstanding and prevent introduction of errors along the way.
Styleshedding: bikeshedding on programming language style and declaring only a particular one true way is the only "universal correct" answer. (The tech equivalent of the Islamic State (because Godwins Law is deprecated since Nazis are now no longer the worst possible butchers to which to compare people.))
This somehow reminds me of the show Halt and Catch Fire, which was one of the most god-awful shows I've ever watched. After Breaking Bad, Mad Men and The Walking Dead I expected a little more from AMC.
