Hacker News Reader

> Perhaps the biggest shift in software engineering in the last decade or two is the fact that no one writes entire systems anymore.

That's unfortunate. If we kept at it, we could have discovered much simpler ways of doing things than the current accumulation of leaky abstractions over leaky abstractions in a rather disintegrated environment. We can do better: http://www.vpri.org/pdf/tr2011004_steps11.pdf

There is great danger in learning OOP with Smalltalk. Everything fits together so elegantly, the first time I opened a book about C++, I closed it in disgust (after seeing the bit-shift operator being used for console output, wtf?!), only to give the language a second chance 8 years later. I even learned Java before giving C++ a try.

When a young programmer asks me for advice about the next language to learn is, my advice is to go for the language that feels most alien. C++ won't enlighten a Java programmer significantly. Forth will.

  > I even learned Java before giving C++ a try

I must admin from all the stuff I saw on the internet I am now scared even try to learn C++. I think it is the looks as a least desireable language to learn for me. Which sucks a bit because there is position at a company I wouldn't mind work for.

It's not a bad language and learning it will teach you a lot of very important concepts. My advice is to master C first, then to wrap your brain around C++.

But, again, there may be other languages more worthy of your effort.

I only leaned Java before touching C++ again because of my peculiar introduction to OOP and because I discarded the language after considering it an inelegant kludge, but, compared to Smalltalk, what language isn't?

And, finally, I decided to swallow my pride and learn C++ because I wanted to be part of the Brazilian electronic voting system projecy. Now, every ballot runs some C++ code I wrote.

If the company is that cool, give it a shot.

Learn C first! You'll understand why C++ is what it is and you'll also get the skills needed to contribute in a lot of open-source projects.

Please don't! Learn Modern C++ instead, otherwise you will be damaged with Cisms in C++ land.

Would you like to elaborate on that?

There are lots of C constructs that are considered bad practice in C++

- null terminated strings

- plain vectors

- manual management of resources (memory, files, db connections, locks...)

- C style casts

- pre-processor instead of using inline/const/templates

- the C subset of C++ it is also not 100% compatible with C, there are a few cases with different semantics

- since C99, new language constructs are added via macros, instead of keywords

- no use of namespaces

- lack of safety of parameters that can be changed (pointer vs reference parameters)

The best way to learn C++ is to read books like "Modern C++ Design", "Programming -- Principles and Practice Using C++" and the recently published "Tour of C++".

I have to take issue with your inclusion of "Modern C++ Design" in a reading list about learning C++. If you're new to C++, that is exactly the sort of thing you _shouldn't_ be reading.

"Modern C++ Design" is really intended for advanced C++ programmers only. I don't feel it gives a very good impression of the language to new developers - there are so many awful hacks in that book.

It's the sort of thing that you should hold off on until you have the experience with the language necessary to be wise about when such techniques are appropriate.

I'll second nnq's opinion. Quite a few of C++'s quirks are the way they are because of the C in its name.

Have you ever tried Eiffel? I've always found the approach taken by Eiffel as OOP done right (compared to C++). I wonder how Eiffel and Smalltalk compare together.

Yes they are gone.

However, the main point is that back then you haven't got HN, Reddit and the blogs of today.

As such not many geeks were fortunate enough to know and understand those systems, as consequence you have a legion of developers that cannot understand the beauty of those systems.

I've worked with Smalltalk for four years now, and for what you write, I guess you haven't been keeping up with our progresses. Take a look at:

http://amber-lang.net

http://www.redline.st/

http://pharo-project.org

Saying Smalltalk hasn't kept up with computing progress is an old argument that doesn't make sense anymore.

At the same time, so much recent tool development has focused on virtualization. Vagrant, chef, puppet, packer, ... and yet, Smalltalk has decades of experience with whole virtualized machines to we can study.

Perhaps systems like Smalltalk still have something to teach us?

> My complaint is that neither of these things is coming back in a relevant way.

I think one could make the case that Android shares many design decisions with a "Smalltalk machine". And the same actually goes for iOS, as objective-c is basically Smalltalk bolted on to c.

And then there is javascript that's modelled after Self -- so by extention chrome OS is also similar to a "Smalltalk machine".

Now why all these systems end up with some bastardized crappy programming languages rather than just using Smalltalk -- that I don't know.

The exception might be the one-laptop-per-child project.

So, I think it's wrong to say "it's not coming back" -- even java (for set-top boxes and smart devices) was an attempt at "bringing it back".

If anything, it seems these systems keep being reinvented.

> Now why all these systems end up with some bastardized crappy programming languages rather than just using Smalltalk -- that I don't know.

Because Worse is Better[1]. For example Internet and the Web is a bastardized version of Xanadu Project[2]. HTML is a bastardized version of XML or XHTML. Worse is here now, when Better gets here, it's not Better anymore, only marginally more useful. That or it turns out the benefits Better has aren't that important or are highly impractical.

[1]http://en.wikipedia.org/wiki/Worse_is_better

[2]http://en.wikipedia.org/wiki/Xanadu_Project

No. Worse is Better would explain why browsers would use Smaltalk (or Self) directly, instead of inventing a new programming language.

Javascript was probably born out of Not Invented Here. Worse Is Better only contributed the curly braces from C, and the continued use of the first widely known scripting engine.

If The Right Thing is already there, Worse Is Better simply doesn't win without exterior help. Worse is better only because it's first. And even so…

> when Better gets here, it's not Better anymore, only marginally more useful.

I would say perceived as marginally more useful in the short term. This is a point where Worse easily looks Better, but whether it is is more debatable.

I'm gonna disagree. Could you implement Smalltalk environment in browser in two weeks? I'd doubt you could (assuming you are Brendan Eich, circa 1995), realistically. It is a sloppily written language that was perfected later over course of decades.

Worse is Better is omnipresent. Linux vs Minix vs BeOS vs Windows is example of Linux despite being bad relatively, simply winning out (on servers) due to its developer base and losing to Windows that despite numerous faults/warts won the desktop market by a large margin.

When I said Right Thing being here, I didn't mean existence, but presence. Right thing may exist in heads of few masters that know it super well, but them being unable or unwilling to spread it dooms the Right Thing. A Worse Thing that spreads far and wide will win and has always won.

Xanadu vs Internet

Linux vs BeOS

MacOS vs Windows

Lisp/Smalltalk vs C

> Could you implement Smalltalk environment in browser in two weeks?

You're being unfair: you compare a Javascript interpreter against a Smalltalk environment. Obviously, If I were in a rush, I would start with a simple interpreter first.

Realistically, if you don't really care about performance (I doubt Brendan Eich did at the time), implementing a JavaScript interpreter is neither easier nor harder than implementing a Lisp or Smalltalk or Self interpreter. I maintain that ease of implementation simply was not an influential factor either way.

Therefore, Javascript was invented for other reasons. My best guess is, Brendan Eich wanted his language to be non-intimidating to C, C++, and Java users. Apparently, it worked.

Oh. That is a typical "Worse is Better".

Okay, I retract. "Worse is Better" is an excellent explanation for Javascript. There are just other kinds of short term benefits persisting through time than the mere ease of implementation.

Ok. Then implement a Smalltalk interpreter in a week. And then make it look like Java, because that was Brendan's task.

Hmm… I think that's pretty much what Brendan did, although he likely started with Self instead of Smalltalk. JavaScript makes a strong emphasis on objects, and had closures from the beginning. Then it has a Java-ish syntax.

As for actually implementing a smaltalk interpreter, it can now be done in 300 lines: http://www.youtube.com/watch?v=EGeN2IC7N0Q (I believe he used Maru http://piumarta.com/software/maru/ ) With current techniques, a language specialist can implement Smalltalk in a day.

I'm not that strong, though. It could take me from a week to a month, depending on how much I need to learn. (Parsing the syntax is easy, but I'm less sure about the semantics.)

> HTML is a bastardized version of XML or XHTML.

No, HTML was an SGML language (XHTML is of course an XML language). HTML5 is more of an "HTML"-like language...

SGML, if anything, is more powerful than XML -- but XML is a great effort to simplify SGML while maintaining most of the power.

For other SGML languages than HTML, look for docbook (which now also exist in an XML dress).

> Most of its best features made it into other languages

No. A few of them have, usually in needlessly restricted and nigh-broken forms (Ruby's blocks are a pale and pitiful shadow of Smalltalk's). I've yet to see message cascading or conditions outside of lisps and smalltalk.

> My complaint is that neither of these things is coming back in a relevant way.

Isn't Light Table essentially an effort to re-create the Smalltalk environment for modern languages?

Yes. And seriously, when I saw the first Light Table demo and everyone was so amazed with it I thought "man, that's how we code every day in Smalltalk... what's so new about it?"

From its documentation, it looks more like an attempt to expose the kind of REPL/runtime integration Emacs offers, through an interface which won't scare people off the way Emacs tends to do.

>My complaint is that neither of these things is coming back in a relevant way.

Where is this directed? It sounds like a criticism of Lisp, Forth, Self, etc, but please correct. The fact that the ignorant masses flocked to C and Unix doesn't grant them one _iota_ of merit. C isn't even a good low-level language. And look at the most popular platform of them all - the web browser, if you want a good laugh.

This is true of any new system. There is a huge complexity in supporting even the standards that most people would consider basic. Just to surf the web you need TCP/IP, HTTP(S), HTML, JavaScript, JPEG, etc. Implementing all of these from scratch is a huge pain.

What is true of any new system? I don't know what point you're trying to make.