Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ending the Era of Patronizing Language Design

blog.objectmentor.com

Post reply on HN
Print view View original

41–50 of 59 posts

Re: Ending the Era of Patronizing Language Design

#41

Post by Artemidoros »

jrockway wrote: post #31
Tamerlin wrote: post #22

Earlier quoted context omitted.

My first Ruby programming experience was with a company sunk by Rubyists, their asinine architecture, and constant monkey-patching. Rubyists most certainly DO hang themselves with monkeypatching, quite often. You just don't tend to hear about the ones that to that, because the sites they build that way don't survive long enough for anyone to notice, assuming that they even launch them successfully, which is rare. I t…

You're confused. Rubyists didn't sink your project. Bad programming (and management) did. They would have fucked up the project in Java or Haskell or Perl or anything else. Oh, and having interviewed C++ developers, I am not sure I can agree that the average C++ programmer is of higher caliber than the average Ruby programmer. C++ is something that these people learn because they think they will get a high-paying job…

Ruby is something people learn because they think programming is cool.

In my experience this is a myth or a at least a stereotype more prevalent in the marketing of Rails than reality.

I had the strong impression during my stint in the Rails world that Ruby was mostly learned as a signaling device. Young developer slaving away at some random Java or PHP job dreaming of making it big in a startup, with the mistaken believe that simply hanging around the in-crowd will magically catapult him in the top 5% of their profession.

Sure there are good people in this community, but they became good by working hard for a very long time and not by writing a trivial Twitter client using the currently hot testing framework/NoSQL database on their MacBook Pro in a Starbucks after skimming through the pick axe book.

wanting to be a cool Rubyist like _why causes a lot less damage than wanting to have a high-paying job

Why should chasing fame be inherently better than chasing money?

Just speaking from my own experience, I learned way more from cynic mercenaries than from wannabe rockstars and I can't see why emulating e.g. Obie Fernandez will cause less damage than aiming for a position as a technical fellow.

Re: Ending the Era of Patronizing Language Design

#42

Post by kenjackson »

jgg wrote: post #5

I know everyone's read it 100 times already, but: Like the creators of sitcoms or junk food or package tours, Java's designers were consciously designing a product for people not as smart as them. Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp. From here: http:…

Fun quote, but factually incorrect. For example, who was the first user of C++? Bjarne himself. He needed the power of Simula, but at the time Simula implementations didn't scale. He took the ideas he found useful in the language and put some into C, as he was building large scale C/BCPL applications.

To me that's the definition of building a language for yourself. You actually write a language that you need to solve a specific problem you have.

And I find his categorization of good vs bad languages somewhat absurd. What actually makes Ada, C++, and Pascal bad? His lack of understanding? What makes C, Perl, and Lisp good? The inverse?

While I have my own personal prefernces with respect to languages, I fully believe a large part of it is familiarity. I've NEVER met anyone who could argue why a particular language was truly bad. They usually are just passionately arguing religion, and I find that tiring. It was cute when I was in high school, but those debates are getting tired.

Re: Ending the Era of Patronizing Language Design

#43

Post by kenjackson »

jamesbritt wrote: post #27
Zarkonnen wrote: post #4

The problem with saying "you can do things in whatever way you want in Ruby" is that the moment you have more than one developer it collides rather drastically with the "principle of least astonishment". This is not to say that making everything out of eg Java boilerplate is the solution. The key is writing well-behaved and consistent code, which you can do in most languages.

The problem with saying "you can do things in whatever way you want in Ruby" is that the moment you have more than one developer it collides rather drastically with the "principle of least astonishment". I've solved that problem by actually talking with the other developers and agreeing to some common practices. Not every problem requires a technical solution. Social solutions often work just fine.

That works great for two people. Maybe even 20 people. But try to write a 1M+ line app by meeting at the water cooler.

One of my favorite stories is we had hired a bright young dev many moons ago. Months into his work we were trying to fix this terrible memory leak, and it looked like most of it was coming from his code. We asked him, "Where do you free this memory, we can't find it anywhere -- you clean up everything else." His response, "Wait, how do you free memory?"

Re: Ending the Era of Patronizing Language Design

#44

Post by zb »

jgg wrote: post #5

I know everyone's read it 100 times already, but: Like the creators of sitcoms or junk food or package tours, Java's designers were consciously designing a product for people not as smart as them. Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp. From here: http:…

And not only programming languages: http://www.ericsink.com/articles/Yours_Mine_Ours.html

Re: Ending the Era of Patronizing Language Design

#45

Post by jgg »

kenjackson wrote: post #42
jgg wrote: post #5

I know everyone's read it 100 times already, but: Like the creators of sitcoms or junk food or package tours, Java's designers were consciously designing a product for people not as smart as them. Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp. From here: http:…

Fun quote, but factually incorrect. For example, who was the first user of C++? Bjarne himself. He needed the power of Simula, but at the time Simula implementations didn't scale. He took the ideas he found useful in the language and put some into C, as he was building large scale C/BCPL applications. To me that's the definition of building a language for yourself. You actually write a language that you need to solve…

I just brought out the quote because I thought it was relevant. I never said I agreed with it 100%.

Re: Ending the Era of Patronizing Language Design

#46

Post by jamesbritt »

kenjackson wrote: post #43
jamesbritt wrote: post #27

Earlier quoted context omitted.

The problem with saying "you can do things in whatever way you want in Ruby" is that the moment you have more than one developer it collides rather drastically with the "principle of least astonishment". I've solved that problem by actually talking with the other developers and agreeing to some common practices. Not every problem requires a technical solution. Social solutions often work just fine.

That works great for two people. Maybe even 20 people. But try to write a 1M+ line app by meeting at the water cooler. One of my favorite stories is we had hired a bright young dev many moons ago. Months into his work we were trying to fix this terrible memory leak, and it looked like most of it was coming from his code. We asked him, "Where do you free this memory, we can't find it anywhere -- you clean up everythin…

Small pieces, loosely joined.

Or do you really write monolithic 1M+ line apps?

Re: Ending the Era of Patronizing Language Design

#47

Post by chipsy »

You have to patronize at least a little bit to write something that is more than a glorified assembly language - otherwise you have no basis to build your other abstractions on.

With C, for example, there's a predefined model for the callstack based around having a fixed set of arguments for function calls and singular return values.

Forth, on the other hand, treats words as simple nested subroutines, keeps data on a global stack, and lets the data carry over from one word to the next. No explicit arguments or return values are necessary.

C can be characterized as "safe," while Forth is "flexible," depending on your use case, but in terms of pure performance both models have strengths and weaknesses.

Re: Ending the Era of Patronizing Language Design

#48

Post by chromatic »

raganwald wrote: post #13
barrkel wrote: post #9

Earlier quoted context omitted.

Programming languages are UIs. Your assertion is tantamount to saying that there is no such thing as a bad UI; that a choice between UIs is a broken choice, because you can still get your job done no matter what UI is there, or similarly you can still do a crappy job no matter what UI you use. But this is just wrong-headed thinking, to my mind. UI definitely influences user behaviour. One thing currently in vogue is…

I agree with everything you're saying about programming languages having a grain, and of making some things easy and other things hard. That's the general case. However, the two specifics we're talking about are well-behaved code and consistent code. Most language in theory make it ridiculously easy to re-use code, to make code DRY. Languages like Ruby actually give you more tools for making code consistent than lang…

It seems that somehow languages don't seem to have a lot of influence over what we might call architecture.

My instinct suggests instead that languages differ as to the standard deviation of quality of code written in them.

Re: Ending the Era of Patronizing Language Design

#49

Post by lars512 »

kenjackson wrote: post #43
jamesbritt wrote: post #27

Earlier quoted context omitted.

The problem with saying "you can do things in whatever way you want in Ruby" is that the moment you have more than one developer it collides rather drastically with the "principle of least astonishment". I've solved that problem by actually talking with the other developers and agreeing to some common practices. Not every problem requires a technical solution. Social solutions often work just fine.

That works great for two people. Maybe even 20 people. But try to write a 1M+ line app by meeting at the water cooler. One of my favorite stories is we had hired a bright young dev many moons ago. Months into his work we were trying to fix this terrible memory leak, and it looked like most of it was coming from his code. We asked him, "Where do you free this memory, we can't find it anywhere -- you clean up everythin…

I had the opposite problem at a student intern gig. I hadn't experienced smart pointers before, and was double freeing memory accidentally. The fun part was that the unit tests for my code always worked. It was always someone else's code which appeared to break inconsistently after my change ;)

You live, you learn. We picked it up remarkably quickly in the end, basically because the company had their process working right: clean codebase, solid testing, and regular code reviews.

Re: Ending the Era of Patronizing Language Design

#50

Post by jemfinch »

kenjackson wrote: post #42
jgg wrote: post #5

I know everyone's read it 100 times already, but: Like the creators of sitcoms or junk food or package tours, Java's designers were consciously designing a product for people not as smart as them. Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp. From here: http:…

Fun quote, but factually incorrect. For example, who was the first user of C++? Bjarne himself. He needed the power of Simula, but at the time Simula implementations didn't scale. He took the ideas he found useful in the language and put some into C, as he was building large scale C/BCPL applications. To me that's the definition of building a language for yourself. You actually write a language that you need to solve…

Also, according to Kay's "The Early History of Smalltalk" [1], Smalltalk was very much designed with end users in mind.

[1] http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

Post reply on HN