emp

True, however this all started with a complaint by Unilever, the maker of Hellmann’s mayonnaise. They dropped their complaint when it was discovered that their mayo did not meet the criteria either. Also according to Unilever, ""cholesterol free" modifier already signals to people the product is not mayonnaise", which apparently should remove ambiguity that Just Mayo is not real mayonnaise: http://www.ctvnews.ca/business/hellmann-s-maker-left-with-eg... A lot of BS attempting to stop a company with great products disrupting the old guys.

Don't forget raising animals for meat, growing food to feed animals, and growing food for export to feed animals. This accounts for more water than almonds that seem to always be the scapegoat.

The Space Shuttle should be so lucky - 8086 (though I read 80386 for a cockpit upgrade). First flight 1981, predating the 486 (1989). It's interesting, NASA was raiding all sorts of old machinery to keep in stock of 8086s.

If RIM's developer tools now are an indication of what they were like back when Apple released XCode for iOS, I am not surprised how things turned out. I had to do the tiniest of an app as a starting point for someone else recently. Horrible IDE, compile errors in sample code that mysteriously go away if you mash "run" a few times, need to install support components but what exactly isn't defined, documents where you aren't sure right away what version of BlackBerry they are for. And when you find the docs, you find the writer is in love with acronyms. I decided very quickly I would never touch the platform seriously, there is no joy there. Also, if Objective-C is deemed 'too hard', what is C++ + Qt considered?

It's as if RIM consists of hard core business people and hard core engineers, both wearing blinders while cheering each other on. There are no 'normals' to care about how one feels about developing on the platform, to care about initial experiences, documentation that doesn't frustrate. If it's like this at the developer level, who is there is care about the end user? If I was a developer on BlackBerry back then, I would have jumped on the iOS opportunity. Today, you can't even pay previous BB developers to work on BB, they have moved on and want to enjoy their work. The few sticking it out know they can charge pretty much whatever rate they want. A smart phone without apps is a dumb phone.

ACID on a single "record". I am glad they document this openly, so many other DBs try to make it seem like they support ACID transactions in general. From my understanding with FoundationDB, you did something of the form of "begin transaction" "do lots of stuff" "end transaction", and it just worked. I've yet to find another option that can do this.

Foundationdb has ACID transactions over the entire db, over the cluster and over multiple keys. And fast. I've looked over so many open sources alternatives, and they claim ACID but it's a deception based on some narrow interpretation of ACID. It's very annoying to spend time researching to discover the truth between the lines.

I would love to find a fast, scalable open source db that implements Foundationdb's features.

It's impossible to just read about Smalltalk and poke around a bit, and think one knows. The language itself is a tiny part of things, and one needs to really get immersed in the environment to really appreciate things.

Maybe you know better, the author could have put things better. But I am sure a lot of people don't know, I know I was one of them. Even after a long time Smalltalker gave an enthusiastic (to put it mildly) 2 hour demo. Now I've become the rabidly enthusiastic one, but most people think I am passionate about historical programming languages.

What other environment can you trivially do this: - can't find a method, but know what you want: provide sample inputs and an output, and (at least Pharo and Squeak Smalltalk) will find you all methods that produce the output. - trouble visualizing relationships while debugging? Script some code in a few minutes that become part of your debugger to see what is going on. - really code live - there is "hot swapping", but it's something bolted onto a rigid foundation, and eventually fails. In Smalltalk, it's a foundational element.

Though the author could have put things differently, it can be difficult when so much that is mainstream feels so primitive, with layer upon layer of cruft bolted on. Programming in Smalltalk is uninterrupted bliss, then I go to work and use tools that have roots that predate Smalltalk, but Smalltalk is talked about as the "old" curiosity.

Excuse the rant - Smalltalk makes me feel like I am using a polished and refined set of tools, and then day to day I run around with crude stone tools, the "modern" way. I think the author feels the same way.

FYI there is a small typo under "Secure & Reliable" - "you" should be "your". Spelling/grammar mistakes make a negative impression on me, especially on a landing page with a TLD where English is the first language.

Do people really speak this way? I would never refer to "Chik'n" verbally. But when seen on the box it does hint at what kind of texture/flavour one might expect. I wish there was an easy alternative as to not be reminded of the animal versions.

Java/Swing is slow is a myth due to badly written applications. Jetbrains does it right. My main machine is a little 11" MacBook and I use AppCode/IntelliJ all day long without performance issues. I use XCode for Interface Builder as the code crafting abilities of the editor are primitive in comparison. I do agree that everything integrates nicely, and it's great to just jump in as a newbie, but I miss solid refactoring, code navigation, smart template and multiple cursors the most when I occasionally use it. I can see the evidence when I start on an existing codebase - typo's, misnamed methods that have evolved to something else etc. Things that AppCode does trivially, and with full trust are things that XCode users seem to balk at as one never knows if the build will break. Maybe things have improved over time (I've used AppCode for 2+ years now), but the evidence in existing code tells me otherwise.

Jetbrains is working on a C/C++ IDE (CLion), so I would expect this functionality to flow over. I spend most of my time in AppCode and IntelliJ, and core functions from other projects flows between their IDEs regularly.

Is there a API search engine where one can enter sample inputs and outputs, and get a list of methods that return the outputs for the given inputs? Smalltalk has a search function like this - very handy instead of trying to guess method names.

He is also a glider pilot. I always hope when I am flying that the pilots fly gliders or Pitts Specials.

Playground however is just a place for playing with snippets of code. And experiment and learn environment. If you have a bug in a running app, it's just not possible to recreate the problem except for the simplest of apps.

I often hear how using how using less mainstream and more difficult to learn (as in requires some mind warping if coming from more mainstream language) languages acts as a filter that will leave more capable programmers to choose from, even if there are less of them.

Does anyone know if there have been studies to back this up? Or studies that back up the above comment.

My experience is that programmers who enjoy warping their minds with something different tend to be more capable, or at the very least, up for a challenge. Would be nice to see something else than anecdotes.

There is also the component of being sad and not knowing why, while you work on what you think is interesting and important.

I remember reading how Feynman was unhappy with his work and then chose a seemingly useless but fun and interesting problem to solve - the physics of plate wobbling (If I remember correctly, the relation between the wobble rate and spin rate of a plate that has been tossed into the air).

His colleagues were a bit confused as to why he would do this, but he had fun and his love for physics was rekindled.

Some years later the mathematics he derived would be used when the first satellites where launched and wobbled as they spun, the wobbling not being desirable. Not bad for useless and fun work!

True, though then we are waiting and hoping for features. Another example of some runtime fun: my debug build swizzles interceptors for common UI lifecycle and action methods (viewDidLoad, didMoveToParentViewController:, sendAction:to:forEvent:, etc). When I am working on an app with many views, a simple glance at the console shows me what view controller displayed, what action a button fired and so on. Great for getting to relevant code quickly. I don't think I could hope for this as a standard feature of a language.

But it does allow for programmers to add their own ideas. I have a traits implementation where I can inject entire behaviours in a line of code. I am not sure if this could be done in Swift (haven't had time to research properly).

Using Injection for XCode gives you live coding close to a Smalltalk system. So you live code on your actual app, super nice for tuning core image filters, or any thing where small iterations are needed between compiles. I literally save hours in a day by not needing a "recompile, relaunch, find my context, repeat" loop.

"Message passing" probably is common due to Objective-C having been inspired by Smalltalk.

When sketching concepts, line weight is created in various ways and used to bring a sketch to life, conveying information such as 3d depth, important areas, material strength, motion, mood, as well as the designer's particular style. I don't think this is intended for CAD and vector drawings.

I forgot about that, thank you.

Thanks - I felt I should type 1983, but if felt wrong! I still had my Apple ][ back then.

And Swift seems to resemble another Apple language Dylan, which was based on Scheme/Lisp. All languages since the are in trouble!

I really like that it is incorporating good parts of many, more terse languages. Nothing wrong with selectively absorbing good ideas.

But a huge part is the interactive nature. I dabbled in Smalltalk some years ago and have been annoyed at compiled languages ever since, resorting to things like http://injectionforxcode.com to gain some of that back (on iOS).

Having a live environment can only be appreciated once it has been taken away. I think developing for Apple devices might just become one of the more programming pleasant experiences.

I am pretty sure you can sign up without paying - but your code will be limited to running on the simulator. The $99 is to build for device, and submit to the store.

It's not for the hell of it.

[ ] does not mean method call, it is the syntax for a message send.

Objective-C is a super set of C, adding an Smalltalk like object system to C. The delimiters say "I am sending a message", which is different to a method call. Also, without them the language would be much more difficult to parse, and future changes to C could break the language. It's lasted well (first appeared in 1993). Not as long as Lisp, perhaps it needs more [ ] :)

I agree, though I often use CLI tools due to many GUI tools have let me down. When something goes wrong with git at the command line, there is nothing hidden. That being said, it's a matter of trust - perhaps time to revisit some tools, as the few GUIs I rely on are ones I trust implicitly to do the right thing.

I can't wait to start using the Chronon plugin. Every breakpoint hit is like a puzzle to be solved, the clues being the current state, and knowledge of the current context. Traveling back in time to observe the conditions leading to the manifestation of a bug will be interesting.

The problem is the rate things get filtered back to Java. I started using Groovy when I kept waiting and waiting for new language features. In 2003.

When I saw the headline the first thing I thought was April Fools had arrived early in the form of a Forth IDE.

It is an appropriate name however. After dabbling in Forth for fun, I became very aware how fleeting and unnecessary local variables are.

Since then I use these kinds of 'completions' by using the extract variable refactorings, and various intent transformations - they added a syntax to existing tools.