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 profession/hobby at all if we engage in language-elitism and snark? Even on Hacker News I've seen vitriol directed at Ruby, Python, Javascript, Haskell, to name a few recent targets. All languages have their place, even if that place is only as a lesson for future language designers.
Encouraging people to build stuff, whatever the language, whatever the library, whatever the framework; that is what we should be doing. IF someone wants suggestions, or help deciding what to use, that is fine, but criticizing someone for the language or framework they use has become all too common and a stain on the character of our community.
That's not to say honest criticism is unwelcome: All languages/libraries/frameworks/software can improve. But to belittle people for the choices they make, or to segregate ourselves into voluntary language-ghettos we are compelled to stay in by the force of public opinion...that goes against the spirit of what people like Armstrong worked hard to build. Maybe it started with "Worse is Better", maybe it started with alt.religion.emacs being taken a little too seriously, but it has been perpetuated by all of us, even Paul Graham (in Beating the Averages).
At some point, this has to stop. We, as a community, must grow to support the betterment of hacking by creating and encouraging creation; not by petty vitriol and conformism based on fashion.
Now, I've strayed pretty far from the point of the post itself, but Armstrong closed with such a salient point: If we stopped bickering so much about what is the "right language", "right framework", "right library" and instead encouraged particular protocols and documentation standards we'd all be better off for it.
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.
> If we stopped bickering so much about what is the "right language", "right framework", "right library"
Programmers are sometimes maximizers rather than satisficers for this kind of thing. We don't want to know if something is ok and will get the job done, we want the best one.
I think people argue for their language out of some sense of the network effects involved: if I can get more people using my language, there will be more libraries, more people to ask about problems, more people to hire/to hire me, more books, and so on and so forth.
So I think there is some economic rationality to it.
I don't think it's anywhere near that complicated. People argue about languages because languages become part of their identity: It's common to think of oneself as for example a "Lisp Programmer". And if a language is part of your identity than people saying less than amazing things about that language feels like an attack on you personally, and very quickly the discussion devolves into an argument that has nothing in particular to do with the actual languages as such.
The problem is one of identity. We will protect anything that we attach to our identity because we perceive any attack on it as an attack on us. To have intelligent, unemotional conversations that has to be decoupled.
In general it can lead to problems if we map our identity externally - whether to a programming language, or something else - of course this is easier to preach than to practice.
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".)
Generally really like your post, but I have to correct you about PG's essay.
It's people who work at normal jobs that he calls caged animals, and founders are the wild animals.
"In fact, getting a normal job may actually make you less able to start a startup, by turning you into a tame animal who thinks he needs an office to work in and a product manager to tell him what software to write."
"One of the best tricks I learned during our startup was a rule for deciding who to hire. Could you describe the person as an animal? It might be hard to translate that into another language, but I think everyone in the US knows what it means. It means someone who takes their work a little too seriously; someone who does what they do so well that they pass right through professional and cross over into obsessive."
Almost everything is part of someone's identity. But I would venture for most people on this forum, they have a car but don't identify with a car brand.
It used to be of course that you were a Ford man or a Chrysler man. But nowadays it's become much rarer.
I agree that it's natural, but I think that the targets for identification shift over time and I don't think it's random.
I think it's because we invest so much time and energy working with them. Most humans can't do that without becoming attached.
Once you identify with something it becomes difficult to be objective about it. So discourse about technical tools is mostly emotion, however rational it pretends to be. That's why the core debates never end.
By the way, you can add version control systems to your list.
Because you think in programming languages. They're not just a tool to get from X to Y, they're part of your thought process and literally a significant part of your life experience.
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.
I know quite a few languages, and I like Javascript. It has a nice mix of functional, procedural, and object oriented aspects. Once upon a time, it was a horrible language to work in (with browser differences making it infinitely worse); but now, I find I like it.
Now, that said, given the choice, I'd choose coffescript. It gives many of the same benefits in a more concise format. It has its warts as well, though, reflecting its desire to stay as close to a concise-javascript as possible.
I feel like coffeescript largely exists because of early mistakes in javascript, like no heredoc and places where they weakened the language to make it more convenient, like this one I just discovered today (with workarounds) http://stackoverflow.com/a/14510952/539149 and js has a ton of problems because it separated Array and Object, but overall I think it's still probably my favorite language right now. I like lua too but it's less pure, so aspects of it remind me of older languages like pascal.
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)
> Even on Hacker News I've seen vitriol directed at [...]
To be fair, the author himself is pretty vitriolic about C++:
"I saw C++ coming and read the book - or at least tried to read the book -
there's a dent
in the wall behind my piano, where the book hit the wall - Improvements to
C should make things
easier not more complicated, I thought"
You are absolutely correct, of course. But he was sharing his personal frustrations with C++, not engaging in the programming equivalent of "slut-shaming" someone for using C++. That's an important distinction that I think has been lost with the HN community. Without criticism, nothing would get better, but if you criticize someone for making something or making a choice, you might just encourage them to stop being a maker. And that's sad for all of us.
Given Dmitry instigated that incident by attempting himself to "slut-shame" C, I'd say he had that one coming! I think Linus was fed-up there with the nth polite suggestion he re-implement either git or the kernel in C++.
There was a "police camera action" footage of a UK nightclub and a man leaping up and slapping the bouncer 6 or 7 times because he was not allowed in - on the eighth leap the bouncer simply punches him once to the ground.
The voice over explains that police had reviewed the footage, and whilst commonly prosecuting bouncers for ABH, this time declined to press charges.
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.
Purely anecdotal. I'm just highly suspicious of individuals who feel the need to slut-shame anonymous people on the Internet rather than actually make things.
not being a girl myself, I suspect that a girl who has been "slut shamed" would probably take offense at someone referring to our circle jerks about one's favorite tool(s) to be considered "slut shaming". Lets keep things in perspective here.
In order to write invent COBOL Rear Admiral Grace Hopper had to invent programming languages, compilers, linkers and the entire modern IT industry - and then she had to implement them, without a programming language or a compiler or a linker.
It is also important to remember that COBOL was the result of design by committee in the attempt to please all parties and not her opus. This is an incredible book about her life and contribution: http://www.amazon.com/Invention-Information-Lemelson-Studies...
I'm just (re)learning to code after doing a bit in college (c/c++), currently learning Ruby (and Rails). As a regular reader of HN, I see posts about how great Erlang is, Scala, Haskell, Python, etc. And they do seem to be great languages. And I want to learn them. But as the author points out (and as I have come to realize), regardless of my desire to learn all these things (right now!), it would almost seem fruitless to quit on Ruby/Rails after about 6 months.
The large point is, regarding langugage/framework bashing, people put in so much time into a particular language. You almost have to buy into it. I guess some people just become zealots.
The advantage of programming long enough is that your 'primary' language changes several times, and each time you get less zealoty about it.
Having learned a bunch of languages myself i would recommend beginners to learn a language thoroughly before moving on. Otherwise you don't assimilate the style of a language and end up writing fortran in c, or c in c++. The qualitative differences between languages don't become obvious until you understand why their common style is what it is.
I don't share your strong focus on "encouraging creation." I think it is more important that we encourage cooperation and sharing then creation. We have no shortage of software being created the problem is we still are extremely bad at fitting things together.
Fitting things together is important, but it exists entirely for the purpose of creating things, which is ultimately in service of end users. Fitting things together is mostly an implementation detail.
Creating things is just fitting together new things. Rather then fitting together many new things that may overlap already existing things we should focus on fitting together an efficient unified system that use resource sharing to ensure a minimum of bloat.
In death of the desktop, interface expert Aza Raskin mentioned that his computer has seven copies of the spellcheck program with seven slightly different implementations of the English language. Building a user interface based upon command sharing rather then bloated applications will ultimately benefit end users.
Obviously better interop is a Good Thing, but we're talking about relative weights of good things. My point is that it's nonsensical to ascribe "fitting together" a higher weight than "creation", because "fitting together" is a subset of "creation".
Now as to the manner of creation: you're reacting against the "just hack it together" philosophy of ghc. But the alternative in ghc's mind, I think, was people not creating anything for fear of not getting it right, or not knowing that building something for themselves is even a possibility. Sub-optimal creation is usually better than nothing, especially when nobody else has to use it.
Fitting stuff together is hard, especially now when we don't have good protocols. While we're working on those, telling people who just need to get stuff done to "wait until we figure some stuff out" is not acceptable. Those people (who may not even be "Programmers") and their products will still benefit from "fitting things together" to some degree that depends on the application (OS or fart app?), but that needs to be balanced against the need to actually finish at some point, all of which is in the service of some non-software need. They just need to get it done with whatever works, whether it's Haskell, PHP, or a spreadsheet. That, I think, is the point ghc was getting at.
You got it backwards when you said "fitting together" is a subset of "creation." Creation is fitting existing unused materials together into a more usable form. I believe we should encourage people to fit together existing programs rather then encouraging people to build stuff "whatever the language, whatever the library, whatever the framework".
If everybody uses whatever framework without concern for compatibility it will inevitably lead to enormous bloat. I have no problem with getting things done quickly to fulfill non-software needs. However, when it comes to software one of our most important needs is to reduce bloat by encouraging sharing.
Most sensible comment I have seen on HN for some while.
"At some point, this has to stop. We, as a community, must grow to support the betterment of hacking by creating and encouraging creation; not by petty vitriol and conformism based on fashion."
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.
On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity.
I thought that statement taken out of context sounded a bit arrogant (though perhaps well deserved!). However, when read in context it really didn't come across like that at all.
Perhaps a title change in this case wouldn't be all that bad.
The perfect low-load time to do something like that would be upon submission, before the link is shown to anyone. Also it's a good time to make sure it's not a 404 or 500.
I think the titles are manually changed, because plenty of times descriptive titles are left intact.
What is most interesting here is the ideas about protocols and communication. To me, that's what much of software development is getting wrong both on the small and on the big.
In a single app, objects should talk to each other and databases and queues and junk via protocols, not by being glued to an ORM or a particular implementation of a queue or whatever. Most devs don't do this because it's more work, but you end up with a much cleaner/more testable structure to work with.
On a higher level, many/most programs aren't made to communicate with each other at all. Look at web software, it's all about communicating with a browser and that's it. The API driven movement is helping things along, but it's still a HTTP Browser driven mindset complete with holy wars about REST/Hypermedia.
Unix pipes are a great example of what is possible with standard communication protocols, but it seems like it could be taken further. What if you could pipe a stream of API's together? Yahoo's YQL and Pipes plays in this realm, but you still have to kind of glue pieces together yourself.
That's a somewhat contrived example, but it would be great if we could do something that simple and not just via a command line, but from any language in a similar amount of code. That would be a step forward I think.
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.
Here's an interesting lecture (sorry, I couldn't find a non-split version) he gave at a university in Sweden (where Erlang has a much greater influence, ahhh the sanity of Northern Europe ;P)
note - the sound is dim for the first few moments
http://www.youtube.com/watch?v=9uIhawQ1G0I
He goes into some of the choices that went into Erlang, and some interesting experiences he had as the project went forward. He gives a different list that he feels the students in attendance should learn:
C, JS, LLVM Assembler, one of ruby or python, and one of Erlang or Haskell.
I have to say this made me feel better that I'm not a wizard in Clojure. If one could be said to be "in love" with a programming language, that would be where I am at with clojure in terms of feelings.
But I've only scratched the surface. I sometimes sit and watch the #clojure channel on freenode, and I find it inspiring, interesting, entertaining, and disheartening all at once.
Inspiring because I get to see the people who write the awesome software and write the terrific books interacting, and I'll be danged, they are kind and good people!
Interesting because of the problems they are working on and discuss, asking each other for advice or just plain help.
Entertaining because they aren't just kind and good, they are also lighthearted sometimes very funny.
Disheartening because sometimes I look at the pastebin code, or the code they message to the clojurebots, and I am left scratching my head.
However, having read this "oldtimer's" post, I'm inspired to know that it's OK to not become a master in programming in 24 hours.
Joe is fearless and an inspiration. For those with 25~ dollars to spare, pick up Joe's 'Programming Erlang' and never regret it. I _think_ differently after reading that book. I am mainly a musician, but what he uncovered for me regarding our brains and how we think blew me away.
What would I recommend learning?
- C
- Prolog
- Erlang (I'm biased)
- Smalltalk
- Javascript
- Hakell / ML /OCaml
- LISP/Scheme/Clojure
A couple of years should be enough (PER LANGUAGE).
A 'beginner' should start by spending 14 years (minimum) learning 7 languages? I was starting to agree with him when he mentioned the paradox of choice that programming beginners face today, but that recommendation is beyond ignorant.
Becoming a veteran polyglot is not the only way to break into the programming field. This is exactly the type of elitist BS that we don't need -- scaring beginners away by giving the impression that they face an insurmountable cliff from the start.
Should we also mention that they need a minimum of 3 master's and 2 doctorate degrees? I don't think I've heard of a single successful programmer with anything less. Surely no one has ever dropped out of college and acquired vast amounts of wealth at an early age by programming.
This is a general problem with asking masters in some discipline about the best way to learn - they almost always tend to recommend simply doing what they did, but they do not say "I did x, y and z", but "x, y and z are the best way to learn" and what is worse some people actually take those recommendations seriously.
The problem with this is twofold: first, the times are always changing and yesterdays path is seldom adequate today anymore and second, progress is made by the younger generations not having to repeat the mistakes of the older ones. So, if you want good recommendations for learning, ask the people who actually teach others on a daily basis. I think 2-3 good courses in programming languages can compress a lot of the knowledge you would gain following this recommendation in a much shorter period - "Structure and Interpretation of Computer Programs", "Concepts, Techniques and Models of Computer Programming" and "Programming Language Pragmatics" are three excellent textbooks that go in this direction.
But then, if you strive for mastery, and I think that's what Dr. Joe Armstrong is interested in, it is nothing exceptional to spent 15 years learning.
Navel-gazing aside, Armstrong suggested that a good language would consist of closed forms interacting over formal protocols. What languages fit that description?
>> Notice there is no quick fix here - 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"
If he were talking about actually thinking about programming techniques I'd agree but here he's talking about languages, and while the languages he lists are sufficiently different, saying it'd take years to master lisp after working in ML, or learning Javascript after knowing C. After the first couple of languages learning new abstractions shouldn't really take that long.
In an ideal world easy programming solutions can be easily explained in the right language. We're not quite there yet but doing quicksort in ML doesn't require 5 years experience.
Erlang mailing is a pleasure to read. Even as mix of different ages and experience levels (heck, Joe is a regular poster), the conversation is always civil.
I read it every day along with hn and a few other blogs.
If anything it helps think differently when facing problems. It makes you think about reliability, fault tolerance and concurrency in a new way. It is just as much a language as it is a new paradigm.
There some languages and toolkits started to copy some features from Erlang (Rust, Go, Scala's Akka, ...) they are all still pretty far from it in terms of providing the whole ecosystem (the full package).
Also Erlang has a great VM behind it (BEAM). It has a completely concurrent garbage collector and other nice things. That's why I am also excited about Elixir (I think there was a post here about that as well).
>> Things improved - I went to CERN and used the CRAY1 this could compile 100K lines of FORTRAN in 1 picosecond (ie about a zillion times slower than my mobile phone today)
Sarcasm doesn't translate well in a thread like this, so just in case someone really thought it could compile 100K lines in a picosecond, dream on. :-)
I don't think it's sarcasm so much as exaggeration; compared to the hours, days or even weeks he had to wait in the past, it sure seemed like a picosecond.
Sarcasm would imply he was somehow denigrating or mocking CERN and/or the CRAY1 and I didn't get that vibe at all.
and what about here:
"IDE's and revision control systems have just made matters worse - now you have all the old versions of the mess as well as the mess itself, and the IDE means you can't even see the mess." :-)
I struggled with that point of his. From a coding speed perspective, he's right. But from an efficiency perspective, even some of the slowest interpreted languages will run circles around a shell script.
However it's still an interesting and thought provoking point. It makes you wonder about other ways of plugging different objects / modules together.
Is efficiency the biggest problem?
It seems to me the bigger problem is that streams of raw bytes over pipes is the wrong level of abstraction for most tasks; at least we seem to have decided that is the case when we are writing code within a program, so I don't see why it shouldn't extend to interprocess programming. I don't see people recommending only defining functions that accept single dimensional arrays of bytes (rather than strings and trees and hashmaps and multidimensional arrays and so on), even when programming in C.
You end up with every tool containing code to parse a stream of bytes into the appropriate data structures, and then probably also write them out to a stream of bytes too. The user has responsibility for a lot of data munging too. It is error prone and repetitive, at least when dealing with anything other than very simple text files containing lines of strings where you know which encoding has been used. (Re)using libraries that read and write more structured data is likely to get you flamed[1]. The history of Unix contains plenty of security problems due to people not correctly accounting for nulls or control characters or spaces etc when chaining together commands (although this is more of a problem with shells than pipes themselves). The output is often not friendly to human eyes by default (I'm thinking of things like localised date and time formats, number formats and so on) since it has to be suitable for passing to another program, unless you use more options or another tool to reformat it.
I would compare it to working with raw memory in C. It's the lowest common denominator, you can do anything, but it's also trivial to screw up and there is a high cognitive overhead. Perhaps it's just too hard to introduce anything higher level at this point.
Perhaps my opinion would change if I spent years (deeply) learning unix tools, but maybe that would just be because I had invested so much time learning a complicated system.
Unix pipes are effectively the same thing as using text streams in C.
Granted not quite the same thing, but raw bits are often used in lower level languages. Take Windows Win32 APIs, there's a lot of instances where styles are defined by adding constants with values being exponentials of 2. Thus creating a binary array of boolean states.
Another example I used to run into was Windows' controller (joystick et al) API (again Win32). Each bit would represent a different controller button and the 'on' state was if the button was depressed. But as the value was returned as an unsigned long int (if memory serves), it was up to the developer to write their own parser to convert what would otherwise been a random number into a meaningful array of bits. (or at least I did - there is a chance I overlooked another function as this was before I made the switch to DirectX6 - so many years ago!)
"Today there is an unhealthy concentration on language and efficiency and NOT on how things fit together and protocols." -- Joe, two paragraphs below the point we're discussing.
I think you're being a little unfair there because he's talking about an "unhealthy concentration". Using a lower level language instead of a shell script for high performance scripts isn't unhealthy as it's not a case of just saving a negligible number of clock cycles. The difference I'm talking about like travelling to the moon and back just to buy a pint of milk.
Case in point: no sane person would rewrite Apache in Bash. But equally I wouldn't rewrite any of my sys admin shell scripts in C.
There's a balance that needs to be struck. Which I did also hint at in my previous post (the one you dismissed outright when arguing about 'unhealthy concentrations'). And I think what Joe actually meant by that quote was the same thing; that many developers are bad at judging that balance.
He's talking about the concept of fitting things together and refers to Unix pipes (in fact the example he gave was literally a string of piped POSIX commands ready for dumping into $SHELL).
My point was that this concept doesn't scale well.
As a productivity tool, pipes are invaluable. But you wouldn't want to write a performance critical routine using them.
At the end of the day (and as Joe said himself), it's about picking the right tool for the job.
What's the difference between pipes and chaining functions?
I can't really see much difference between grep | sed |awk somestuff.txt and (awk(sed(grep(somestuff.txt))).
Or are you suggesting that function composition is not the right approach? In which case, I disagree, but I would like some more insight into your thought process on this.
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 adds quite a massive overhead. Granted this isn't an issue for the kind of jobs you'd write shell scripts for in the first place, but it does severely hamper this kind of model in terms of scalability. But then we're back to the age old issue of performance vs convenience.
I will concede that the second point is more an issue about implementation rather than concept though. But if you were to write a lower level implementation of Unix pipes, I don't think it would pretty much end up with Perl functions (which, to be fair, you suggested yourself). I say Perl specifically because you can create a function without specifying what values to accept (see example below), which is akin to the 'dumb' strings read in from STDIN.
So I'm not really saying that pipes isn't the "right approach". Just that it isn't always the best approach. But for things like system administration, pipes are invaluable. Not just because the tools are already written (ie the wealth of command line applications), but also because it's quick to express yet highly readable.
I'm not really sure if that answers your question though (or even if I've said anything you don't already know).
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.
I can't speak for laumars, but I would suggest there is a difference. Functions within languages generally work at a higher level of abstraction, even in C. If you wanted a grep like function for filtering an array of strings in your programming language of choice, would you define it to take a single string and predicate arguments, that is then split up on an arbitrary character, filtered, then joined back together again to return a single string? Or would you use a general purpose filter() function that takes an array and a predicate (function pointer/lambda/block/whatever) and returns a new array?
Note that that example isn't given as an example of what would be ideal, but as a sign of the sad state of tools to fit things together that it is the best available.
That's only for web applications though. I'd like it if Unix utilities optionally output and accepted JSON or a similar syntax. It'd make things so much easier.
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"
pretty much summed up the PHP experience :)
If ALL applications in the world were interfaced by
(say) sockets + lisp S expressions and had the
semantics of the protocol written down in a formal
notation - then we could reuse things (more) easily.
nodejs apps are usually very close to that: small modular services interacting via sockets + events using json, protocol buffers, etc. Much like the unix pipe philosophy applied to servers.
If you didn't study CS and want to improve your knowledge of algorithms, I found Coursera classes to be very good.
SQL is not a protocol in the sense that Armstrong is using, which is (approximately, at least) a specification for the acceptable messages (including state transitions that change the acceptable messages) over a communications channel between two processes.
Well, it's not thought of as a "channel between two processes". Maybe more like a hub, except it actually stores data (which is similar to an async protocol that buffers/queues messages).
But that's all kind of irrelevant. The purpose that a database serves is a good replacement for other kinds of IPC. It imparts meaning to data and allows applications to communicate in a common way.
Think about it this way: every language has a different way of representing some missing value -- null, nil, undef, Nothing, None -- and all are slightly different. But the application is probably influenced by SQL NULL semantics more than any of those. (EDIT: reworded this paragraph)
Databases pretty much own everything, which is something I think that language people should spend more time focusing on. Maybe the reason that cool new language isn't 2X as productive as python is because you are still using the same database. Language designers need to focus on informed innovation in the database space if they really want to make an impact.
"including state transitions that change the acceptable messages"
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 expensive training, staff and technology to help manage it.
Even putting aside the management issues, databases+SQL is a synchronous communications model, so you can't stream data effectively.
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 you need to do, then use something else.
My point was what people are actually doing for IPC. And for the most part, it's using SQL databases. Even communicating between processes in a single application (e.g. related web requests served by different processes), SQL databases dominate.
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.
I'm interested in Erlang, have read a lot of good things about it lately.
However I've not tried it yet because I don't see how it is going to help me... I already know some functional programming (Scala, Haskell) and I don't work with large, distributed software or databases.
I'm afraid I'm going to learn it, not finding something useful to do with it, and then "forget" it.
> I'm afraid I'm going to learn it, not finding something useful to do with it, and then "forget" it.
I am more or less in the same boat. I picked up 'Learn You Some Erlang for Great Good'. Fun book, fun language, what other motivation does one need? ;)
The crazy think is we still are extremely bad at fitting things together - still the best way of fitting things together is the unix pipe
This is something that resonates with me. I'm never been a 'nix person but this is a very attractive pitch for getting stuff done. It is, after all, how we build things with LEGO.
I went to a Java school so my OO indoctrination was strong by the time I graduated. Now I'm really starting to crave a development paradigm by composition rather than inheritance. My job title is no longer that of a programmer but I write utilities and library daily to help me with my 'real' job. It helps me get stuff done.
So my question - since I primarily work in the MS world, does PowerShell offer the same flexibility and utility of the Unix pipe? I'd never thought of taking the time to learn it until reading this post.
I was evaluating both languages recently, and the biggest distinction is that Erlang does context switching per "reduction" or function call while Go does context switches only when a go-routine explicitly yields or a message is sent/received.
This means that Erlang can get finer time shared concurrency at the expense of speed.
Anything other differences such as syntax is relatively trivial.
I wish i had the time to learn that much languages and spend couple of years per language... I think the problem today is that we try to learn 3 or more at the same time what often results in bad code....
"Things improved - I went to CERN and used the CRAY1 this could compile 100K lines of FORTRAN in 1 picosecond (ie about a zillion times slower than my mobile phone today)"
I don't like how he mixes together some precise numbers (, RAM size) with completely unrealistic (you can't do anyting in a picosecond, you can't compile 100k likes of code without noticing the time it takes the even today on any hardware.
This person may be "important", but a lot of the comments about languages seem to be borderline flamebait. Also, the mention of -many- languages, but the deliberate lack of any mention of Perl seems odd to me. I really dislike PHP myself, but there is no need to bash it.
To me, this list is great except for one small thing.
- C
- Prolog
- Erlang
- Smalltalk
- Javascript
- Hakell / ML /OCaml
- LISP/Scheme/Clojure
Javascript?! Over Ruby or Python or Lua? What is it with people liking Javascript. I really don't get it. What can I do that is so beautiful or mindbending that I can't do in python?
From my experience there is only two reasons to learn Javascript: to be able to build web applications, or to write document store queries (MongoDB or Riak, although in Riak you can also use Erlang). Otherwise I just don't see what the big deal is.
Argh. How could you read this post and still miss the point so badly?
It is not about languages, it is about ideas. And the fact that you need years to master each of these languages because of ideas they are built upon, not because of such trivial things as syntax.
I strongly suspect that Joe would be equally comfortable with this list was C substituted with Go, Smalltalk substituted with Io or JavaScript substituted with Lua.
To paraphrase: "what is it with people liking or not liking JavaScript"? I know what is it with these people: they are noobs (sorry in advance, this is not intended as offensive). I have been programming for just twenty years now and I just recently, a few years ago, understood all this, so I'm not exactly surprised by your post, but still, I thought that email so well written as Joe's here would repel this kind of "Javascript is bad, use WhatEver(tm)" talk.
> What is it with people liking Javascript. I really don't get it. What can I do that is so beautiful or mindbending that I can't do in python?
That's kind of a silly question to ask.
For one, features are duplicated across masses of languages. If you ask, 'what is the one specific thing I can do in this language that I couldn't do in some other language?', the answer is almost certainly nothing. Languages only really start standing out from one another when you start talking about combinations of features. Javascript's combination of prototyping, closures, and first class functions isn't like any of the other languages on the list even before you get to html DOM manipulation or nosql.
But the more important point I'd like to make is, that if a whole bunch of smart people say they really like something, and you can't see why, that should be a sign to look harder.
Which is not to say, if a whole bunch of smart people like something you have to like it, too. But there's a reason smart people recommend it. And even if you eventually end up disagreeing with the reason, that doesn't mean it isn't there.
What is it with people liking a specific language in general? Didn't you read the whole post?
"Today there is an unhealthy concentration on language and efficiency and NOT on how things fit together and protocols - teach protocols and not languages."
Exactly. Forget the language. Use it if it works for what you need to do. Learn to program correctly, learn how things fit together, how you can use languages together and for the right purpose; learn the fundamentals, learn algorithms, and you'll build quality software in whatever language you choose.
> What is it with people liking a specific language
What is it with shaming people for preferring a specific language where it is applicable?
For some reason I can like a brand of electric drill, and I can believe in using a nailgun, but I am not allowed to like a specific language without someone coming along to scold me.
If you don't ever develop opinions about tools and how to use them, are you really engaged or are you just floating along? Liking something is a good sign of engagement, being able to compare it to others in an informed way is even better. The problem is if you put other things down without knowing about them.
What is it with people missing the point so many times in a row? Hence why I said "learn how you can use languages together and for the right purpose"—but I don't believe it should be the primary focus.
When you buy a drill, the main purpose is to make holes in things. When you buy a nailgun, the main purpose is to stick things together. One might do it better, one might do it faster, and yes, it's useful to know those things. But you're still building a house, not an opinion about a drill or a nailgun.
Ever notice how professionals treat their tools, versus amateurs? Photographers are a great example. Amateur photographers are all about cameras and lenses and tools. They buy gear like there was no tomorrow, and they do very little actual photography. Some of them make it past this phase and change their focus to what photography is really about (light, subject, timing) but most don't.
Professional photographers buy cameras for one purpose: because they get the shot. They buy lenses for one purpose: because they get the shot. And they buy everything else they need for one purpose: because it gets the shot. Their focus is the photograph and everything else follows. Of course there is some thought of what lens is right for what job, and what camera works best for what needs, and durability and portability especially; but mostly they use what works because they know it well and it gets the shot. And some pros use the most ridiculous gear that you'd never expect because it works so well for their particular goals.
There was an article a while back about a Iraq war journalist who used only Olympus 6MP zoom cameras made 5-6 years ago because they were workhorses, extremely portable, and held up to desert conditions. Non-pros probably thought he was crazy and dumb, but he got the shots. He shipped. You have seen his photos in the news, guaranteed. Talking about that gear out of context, it would make zero sense. But for the situation, it was perfect, because he focused on the task and not the gear.
I'm not scolding anyone, I'm not criticizing a choice of language; I'm saying, focus on the right part of your task. The tool is important, but the task is more important. That's exactly what the original article was saying, too, if you'll kindly go back and take note.
Beautiful comparison with photography and well said. And I would like to know the answer to this one: "What is it with people missing the point so many times in a row?" too. It's not like it's hard to understand or that there are few explanations out there.
I suspect many things and have many theories, but I'd be happy if someone concisely summarized different possible causes of such a behaviour of amateur programmers (and/or photographers). My "they're just noobs" doesn't cut it, because it may well be a description of effect and not the cause (I suspect it is).
Oh I understand it well, I think. I went through phases such as this in both photography and other fields. I sort of skipped it in programming thanks to a theoretical CS education, and being told constantly "the language doesn't matter" throughout my learning phase.
I think you're always striving for higher quality at the beginning. You always want to skip over the developing mastery part right into mastery, but it never works that way. So you take shortcuts, and you see that they have effects. To continue with the photography example, if you buy a more expensive lens, for a while it looks like your photographs are getting better. On the surface, they improve. They're smoother, sharper, with better color; whatever. For a while, you think that's what photography is all about, the quality of the image, the lust for higher and higher quality.
We do the same thing in programming. You learn a language. It lets you do stuff. But then you learn a different language and it just seems so much better in the areas you believe are important right then. On the surface, it's easier to code in and easier to understand and it results in more polished code, or faster, or it lets you do things in a way that seems cool. You think "why would anyone ever use Old Language when they could use New Language?" You build lots of cool things and no one uses them but they're cool anyway.
In both fields, the beginner is just learning their tools. It's important to go through that phase in photography, because you learn that lenses and cameras and flashes and gear really do make the result different. The mistake is thinking they make the result better. Because better has many different meanings that are deeper than the surface level that the gear can affect. Same with programming: you make this mistake that New Language is better because it does XYZ better, without realizing that what you're actually building has a deeper meaning than just what the language does better. That it actually takes a lot of different languages, or that Old Language might actually be a better choice because you don't need XYZ, you need ABC. Or something.
It's the difference between mastery and the illusion of mastery or the desire for mastery, and it's the process of learning what tools are for and why they're important, before realizing that they're only important on the surface: as a means to an end. It's an attempt for quality before mastery, which has a limit.
Once you have mastery though, if you've got all the other parts right, then chances are you're going to choose the right language. Language isn't unimportant because it's not important (it is); it's unimportant because if you have everything else right, then the choice of language follows naturally. It's not a concern. It's an afterthought that a true master will already have the answer for.
This is why if you go up to a professional photographer and ask them what kind of camera and lens they're using, they'll just give you a quizzical look and roll their eyes. In their head, the answer is obvious. "The right one."
Will they still be attached to their gear? Of course. Will they still prefer what they're used to? Of course. But they have no illusion that it means anything more than that.
In the end, the photographer in the right place at the right time with the right light still wins, regardless of the gear—even though he still has the right gear. And in the end, the programmer with the right project and the right customers with the right need still wins, regardless of the language—even though that programmer has probably already chosen the right language.
I really love the comparison to photography. It's good to remember that no one tool is perfect for every job and that new doesn't mean better.
That said, it's also good to remember that there's nothing wrong with loving your languages as long as you reasonably avoid bias and don't let it stop you from trying new languages and ideas.
JavaScript is the best-to-learn (both most currently used and arguably best developed) member of the Self-style prototype-based OO languages. Thus, for a breadth-oriented education in programming concepts that helps you understand the available tools, where you've already learned Smalltalk and C, it has a lot more distinct to offer than Ruby or Python. This is independent of whether it is a better language that Ruby or Python or Lua for general industrial use (which, in practice, tends to end up being an issue more driven by the availability, accessibility, and level of support for libraries for currently-important tasks rather than intrinsic features of the language itself.)
Javascript is a very different language from Python. It is in some ways more flexible and less prescriptive. You point out one of the non-overlapping use cases. Javascript performance has seen really intensive efforts. Javascript has grown a rather nice async ecosystem that Python just doesn't have. It's also exciting for people from the standpoint that everything feels newer and more up for grabs. Python is a rather old language.
Any language is Turing complete so the big deal is a matter of style and tools and libraries and ultimately it's who you are working with and what you want to do.
Javascript's async story is far worse than Python's.
Yes and no. Python may have an great async core with Twisted and gevents, but it doesn't have an great async ecosystem. Most tools and libraries aren't written with async in mind and you end up having to roll your own in many places where Node either gives it to you out of the box or with well supported third-party libraries. After having written quite a bit of Twisted code I have to say I find writing async code in Node a lot quicker and easier, despite being a much more experienced python programmer.
Then try gevent. The monkeypatching they do means that most pure Python network code just works with it. For instance, I used the XML-RPC library that ships with the core with no further modifications beyond what gevent does.
It's less good than using a language with first-class support for continuation-style programming, but it's better than using a language that makes you be the compiler and chop up and manage the event handlers yourself.
"Javascript has grown a rather nice async ecosystem that Python just doesn't have. It's also exciting for people from the standpoint that everything feels newer and more up for grabs. Python is a rather old language."
Python old? Not to be snarky, but I've got programs for the PDP-11 that dated Python's great-grandmother. Excitement in a language doesn't cut it, I respect productivity, environment and progress. For automation, data munging and analysis, Python is my secret weapon in a shop of MS SQL Server DBA's and C# ditto heads. Would have be nice if MS would have adapted IronPython instead of creating PowerShell...
Yes, there are oodles of crappy Turning complete programming languages, but there's definative advantages to a much smaller sub-set of decent langauges and environments.
Python is, objectively, decades old. For some people that would make it less exciting. Excitement produces buzz and popularity and encourages development effort which creates real and useful code.
I vastly, vastly prefer Python. But we are NOT helping Python AT ALL if we bring it up to trash Javascript every time it's mentioned, without making any argument more specific than "I used a PDP-11".
I'm not seeing a decrease in Python development and investment. In the past decade I've seen a lot of effort invested in interesting and productive third party utilities and libraries. New languages still have to build those tools and such to get to a steady-state and attract more than language explorers and hipsters.
I wasn't trashing Javascript, which is obvious if you trace through the message thread. I haven't delved much into modern Javascript, since most of my work involves data and cli/desktop/network applications instead of web applications and services, so I don't have a valid observation worth sharing.
Python hit its stride a long time ago. The Javascript ecosystem has only quite recently reached sufficient performance, usability and adoption to be a serious general purpose language and it's red hot as a job skill. Python is not dead, but it's not exactly blowing up at this point.
Depends on what domain you work in. If I used nodejs or web services, then I would be enamored of Javascript. But I do an data analysis and ETL, a domain that Python and friends excel at, I not concerned as what's "hot" and "in" at the coffeshop.
As others said you missed the point. But, you also (based on this one comment) have little awareness or imagination.
> What can I do that is so beautiful or mindbending that I can't do in python?
The most (and plainly) obvious is; write programs that run on the widest deployed platform/distribution network by several orders of magnitude. That is mindbending and beautiful. Go use Javascript for several years to figure out the rest.
Javascript has some unique concepts, while Ruby or Pyton are just mix of features also present in Smalltalk or LISP. So learning Ruby has no added value if you already know those.
> learning Ruby has no added value if you already know those.
Maybe learning it just as a learning exercise is not so valuable, but Ruby is fantastically useful at getting shit done in the real world with a language that's pretty good. For instance, try and do this in standard Erlang:
stdout_str, stderr_str, status = Open3.capture3(command)
You can't. I've been complaining about it since 2004, others have sent patches, and you still can't easily handle stderr and stdout as separate streams with open_port.
Python also borrowed some good stuff from Icon. Not that many folks here have actually used Icon, but it was fun to compile and play with back in the day.
I know it's wrong, but I've used pliers on bicycle wheel nuts. They were at hand and the Park wrench wasn't. But what the hell, the tire was flat and it was a long walk home.I am a kludgaholic. And not seeing it as a problem.
The author was using Fortran on punch cards and considered himself lucky [Enter: three more Yorkshiremen ...]
I started on Punch cards... Back in '86 we had a Bulgarian over at Bristol and he told us that in Bulgaria you only got one compile so if you wanted to change your programme you had to edit the object deck (ie assembler in punch cards).
I remember a Saturday making punch cards. I was probably five. He must have had an assignment due. He was back in grad school and still working full time. He's got stories about manually editing paper tape.
AFAIU Python's closure have been incomplete for a long time. I think they've become true, complete closures after the addition of the nonlocal keyword on 3.0
Please correct me if I'm mistaken. This all comes from a cursory research on the subject.
To my eyes they always were true and complete, but you had to play the minor trick of using mutable data to get them. Here is an example of what I mean that has worked forever.
I think I heard that this wasn't working around 2.0 or earlier... but I'm not curious enough to go research and I wasn't using Python until 2.4. Can you maybe confirm or deny this?
In short, in your opinion, Python has no "complete" closures because you cannot bind a new value to the name from enclosing lexical scope from within a nested scope. I disagree.
Which is why I disagree with claims that Python doesn't support them either. It does, of course; we could argue if Python supports "complete" closures, but we won't, because we know better than to use meaningless terms in discussion, right?
In any case it's not been the case in a while, so I stand corrected.
Although being able to write on the closed over variable is a neat feature to have, I would argue that feature does make a difference. Whether you call that complete or read-write or however you want to.
Does it really help our profession/hobby at all if we engage in language-elitism and snark? Even on Hacker News I've seen vitriol directed at Ruby, Python, Javascript, Haskell, to name a few recent targets. All languages have their place, even if that place is only as a lesson for future language designers.
Encouraging people to build stuff, whatever the language, whatever the library, whatever the framework; that is what we should be doing. IF someone wants suggestions, or help deciding what to use, that is fine, but criticizing someone for the language or framework they use has become all too common and a stain on the character of our community.
That's not to say honest criticism is unwelcome: All languages/libraries/frameworks/software can improve. But to belittle people for the choices they make, or to segregate ourselves into voluntary language-ghettos we are compelled to stay in by the force of public opinion...that goes against the spirit of what people like Armstrong worked hard to build. Maybe it started with "Worse is Better", maybe it started with alt.religion.emacs being taken a little too seriously, but it has been perpetuated by all of us, even Paul Graham (in Beating the Averages).
At some point, this has to stop. We, as a community, must grow to support the betterment of hacking by creating and encouraging creation; not by petty vitriol and conformism based on fashion.
Now, I've strayed pretty far from the point of the post itself, but Armstrong closed with such a salient point: If we stopped bickering so much about what is the "right language", "right framework", "right library" and instead encouraged particular protocols and documentation standards we'd all be better off for it.