Live data from Hacker News

"I couldn't really learn Erlang, 'cos it didn't exist, so I invented it"

erlang.org

161–170 of 183 posts

Re: "I couldn't really learn Erlang, 'cos it didn't exist, so I invented it"

#162

Earlier quoted context omitted.

Either you don't consider linux to be 'anything of value' or you haven't read Linus Torvalds' take on c++ http://harmful.cat-v.org/software/c++/linus

Finding one edge case doesn't refute the original point. Most /r/programming-esque lingual slut-shaming is by people who seem to be very good at being Right On The Internet, and not much else. And that's a woefully terrible thing to be good at.

What evidence do you have that a propensity to "slut-shame" isn't distributed evenly between people who are and aren't good at things?

Re: "I couldn't really learn Erlang, 'cos it didn't exist, so I invented it"

#163

Earlier quoted context omitted.

It's true that it happens, but it's the antipattern of our age. When you have seven applications written against a single database (plus a load of complex SQL that operators use for support), it becomes impractical to refactor the schema. Now your business is evolving around rotting data structures. Companies like Oracle make their money by convincing people that they should adopt this misdesign, and then licensing e…

"impractical to refactor the schema" Relational theory is intended to make it easier to achieve data independence, including various kinds of schema changes. You did not offer an alternative, but I am very skeptical that whatever alternative you have in mind somehow improves matters. "you can't stream data effectively" If the currently available SQL products don't allow you to stream data effectively, and that's what…

    > including various kinds of schema changes.
If you have several different software teams all with different apps against the same database, it's a struggle to coordinate a refactor.

Often there's problems just because of subtle differences in assumptions made about data that aren't covered by the sparse type system that relational databases offer.

These are very common problems for businesses that are growing beyond their "small business" stage.

    > You did not offer an alternative
Here's some:

* services which offer synchronous lookups over HTTP.

* services which offer interaction by custom streaming protocol.

* pipelines of data along the lines of Drake, which was on the homepage yesterday. This is similar to the batch-processing approach that dominated the mainframe era.

Each of these have lend themselves to "grandfathering" APIs as stuff changes. So when you rely on them, your teams can be flexible in ways that aren't open to you when everyone is running against a shared schema.

Also, you can write those approaches in whatever language you like, rather than being restricted to the stored procedures combinations that your DB offer, which always have poor state handing and limited concurrency mechanisms, and generally have a quirky syntax as well.

    > If the currently available SQL products don't allow
    > you to stream data effectively, and that's what you
    > need to do, then use something else.
Once you have people starting to use a database for message passing, you'll develop an ecosystem of platform-specific stored procedures and the like.

Databasese get chosen for messaging not because they're a good solution for it, but because it's the lazy option.

Think of all the systems that start off as an access database on someone's desk, and then evolve into SQL server. And then people write several apps against them and the business is locked into the platform.

By the time you need streaming often you've already made decisions that lock you out of it.

The business can't justify a rearchitect on period-by-period accounting. So the business hits the schema harder and harder until no work is getting done. You end up with a large team of cranky database admins, testers and developers. They work hard but generate little value. Their lives are dedicated to trying to slowly shuffle the blob forward. Your infrastructure costs are now huge.

    > My point was what people are actually doing for IPC
I agreed with you on that from my open. And went on to make the point that - irrespective of that - it's a bad pattern.

There are things relational databases are effective solutions for. Messaging is not one of them. A schema should be owned and interacted with by one and only one codebase. Databases should not be used as ad hoc messaging systems.

Re: "I couldn't really learn Erlang, 'cos it didn't exist, so I invented it"

#164
post #125

Earlier quoted context omitted.

But why do programming languages become part of people's identity so readily, whereas many other things do not? (What do programming languages, operating systems, and text editors all have in common? They're big parts of people's identities...)

Can you point out some things that don't become part of people's identity? My experience is that anything that someone spends more than a tiny amount of time with immediately starts becoming part of who they are. The boundary of our self is constantly spreading outwards onto the things around us. Seems to be part of human nature.

Psychologists have a concept known as "self-complexity" (wiki it). Basically, it's our view of ourselves, in terms of the many attributes, relationships, skills, deficiencies, etc. we possess. Someone who thinks of themselves in broad terms, filling many roles and with many aspects, is said to have a high self-complexity. Someone who thinks of themselves in terms of only a single aspect has low self-complexity. Think of "I'm a world-class kernel C hacker" vs. "I'm an awesome C programmer" vs. "I'm a good programmer" vs. "I'm a decent human being".

By itself, self-complexity is neither good nor bad, but it does have consequences. High self-complexity buffers you against negative events or negative appraisals of those aspects you identify with. Someone who's devoted their life to low-level kernel hacking is going to take it more personally when you say C is obsolete and only a fool would be involved in OS design in 2013. Someone who also sees themselves as a husband and a father and a good friend and a church leader and not all that bad at Javascript web programming either is probably going to let it roll off them; they may think you're wrong, but they'll just shrug and say "Whatever; you're entitled to your opinion" and not bother to argue the point.

So no, it's not bad for new activities to become part of your identity. It can be bad for them to become your whole identity, because it leaves you really vulnerable to outside attacks on your self-conception.

(On a side note, it seems to me that a lot of the Silicon Valley startup mythology is focused on encouraging low self-complexity and an obsessive focus on external success. Now that I re-read some of PG's early essays, several of them seem actively harmful to one's mental health. The YC application used to ask you "How are you an 'animal'?", in reference to an early essay where he suggested that successful startup founders often act like caged animals - as if denying your humanity is "success".)

Re: "I couldn't really learn Erlang, 'cos it didn't exist, so I invented it"

#165
post #144

Earlier quoted context omitted.

My issue largely about the scalability of pipes. They're ok for basic tasks, but not great for complicated routines: 1) You've only got one send and one return. (well, arguably more if you include stderr and exit codes, but they have their own limitations in addition to the aforementioned) 2) They're too insular from each other; different files dotted about that needs to be loaded into the memory then executed. It ad…

I'm not really sure if that answers your question though I think GP was confused about the difference between the concept of piping and the concept of function composition. As noted by GGGP above, the concept of piping/composition is not only Unix pipes, but you keep arguing about that particular case of it instead of the general concept.

There's a reason I keep arguing about that particular case. It's because you can't really discuss the concept without examples, and as there's only really one implementation of this concept common use, the only example I can give is this particular case.

Re: "I couldn't really learn Erlang, 'cos it didn't exist, so I invented it"

#166
post #12

Just for a moment, consider who this man is and what he has done. We would all do well to take a step back and consider his manner of response. Notice that he continued learning new languages after creating Erlang (instead of just evangelizing it at the one true language). He did not immediately say "choose these three languages" as if they were the only ones you could possibly learn. Does it really help our professi…

Ironically, he takes a swipe at PHP. And the swipe is a bit silly since PHP does have a strlen function.

Except strlen does not give you the length of a string, but the size of a string (in bytes), unless ofcourse mbstring's func_overload directive is enabled.

Re: "I couldn't really learn Erlang, 'cos it didn't exist, so I invented it"

#167
post #23

I spat my coffee out at this bit: if you want a quick fix go buy "learn PHP in ten minutes" and spend the next twenty years googling for "how do I compute the length of a string"

He's right though, PHP has no reliable way to obtain the length of a string in characters, unless you keep track of which character set a string is in and carefully manipulate the mbstring functions.

Doing multibyte string handling properly in PHP is way harder than it should have been.

Re: "I couldn't really learn Erlang, 'cos it didn't exist, so I invented it"

#168
post #46
post #12

Just for a moment, consider who this man is and what he has done. We would all do well to take a step back and consider his manner of response. Notice that he continued learning new languages after creating Erlang (instead of just evangelizing it at the one true language). He did not immediately say "choose these three languages" as if they were the only ones you could possibly learn. Does it really help our professi…

This man is a legend. Not just being the father of Erlang (and that's probably enough to make him a legend). But it really is his attitude and his desire to never stop learning, never settle. He is still working and tinkering. https://github.com/joearms?tab=activity He is also a regular at the Erlang mailing list: http://erlang.org/pipermail/erlang-questions/

A must watch talk, on joearms thinking and humour. talk is about on writing C compiler.

http://www.infoq.com/presentations/ECC-Fun-Writing-Compilers

Re: "I couldn't really learn Erlang, 'cos it didn't exist, so I invented it"

#169
post #79

Earlier quoted context omitted.

I found it revealing that he appeared to not only like Javascript, but liked it better than Python and Ruby. Interesting. I personally have grown to love coding in Javascript, but I'm a dumbass who doesn't know Lua, Erlang, Haskell, etc. It would be interesting to hear his perspective on JS.

just a note: Lua is basically a very cleaned up version of Javascript. if their APIs were the same you could practically do a literal transcription between them and most programs would run with little alteration. that includes things like object literals (lua tables). example: (function(a, b) { return a * b; })(1) //valid javascript (NaN) (function(a, b) return a * b end)(1) //valid lua (runtime error)

I love Lua because of it's reluctance to use symbols (such as braces). It's mostly an aesthetic thing. I think it looks great.

Re: "I couldn't really learn Erlang, 'cos it didn't exist, so I invented it"

#170
post #12

Just for a moment, consider who this man is and what he has done. We would all do well to take a step back and consider his manner of response. Notice that he continued learning new languages after creating Erlang (instead of just evangelizing it at the one true language). He did not immediately say "choose these three languages" as if they were the only ones you could possibly learn. Does it really help our professi…

Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao. But do not program in COBOL if you can avoid it. The Tao Of Programming verse 1.3

Often that purpose is to say "don't do it this way".
Post reply on HN