On Languages

0 views
Skip to first unread message

Sean Copenhaver

unread,
Sep 30, 2011, 9:43:00 AM9/30/11
to colaco...@googlegroups.com
My thing is that I don't think I want to be in an age of frameworks. Although the trend seems to be towards micro-frameworks and tools now which is great. The evaluation, learning, and implementation period for a small framework that fits your needs can be much smaller then a larger more generic framework.

My view of the greater programming world seems to indicate there is a fair amount of experimentation with languages going on. Particularly in the light is CoffeeScript and Clojure, but there are also languages which are getting more buzz such as Erlang. None of these have anything to do with frameworks (well some of the appeal of Erlang is their OTP behaviors) but are trying to tackle different kinds of problems that people are interested in.

CoffeeScript is a cleaner, a little more expressive, and safer JavaScript. Clojure manageable concurrency on the JVM (I believe the CLR port has basically died). Erlang's shimmer is due to it's VM which is built on the ideas of fault tolerance and concurrent programming but the language itself makes the ideas of processes and message passing a focal point.

Actually how central the ideas of processes, message passing, pattern matching on data for clauses and assignment, and "never go down" (fault tolerance and hot code loading) Erlang is makes it very appealing to me.

Anyway, my point is that the language world has certainly not gone stale. I hope it never does. Language is the only way to communicate an idea and provides the smallest building blocks for that communication. A framework can only be as strong and power as the language allows and if you are stretching the language and doing dark wizardry that might indicate a mismatch (easy example are some of the things we do in C# to make it more dynamic when we could use a dynamic language)

The .NET world sort of seems stale for languages since everything is C#. I rarely even hear VB.NET (which is almost just syntax) in a positive way these days. It's usually related to older code. This is perhaps a bit unfortunate since the CLR and DLR are suppose to be excellent runtimes that allow multi-language interopt (supposedly better then the JVM where most language buzz is these days). Also F# is suppose to be very cool. I know the numeric units, data pipeling, async, and type inferencing (I'm not talking about the "that's cute" 'var' keyword in C#) are pretty awesome additions to a .NET language. Aync stuff in F# influenced C#'s as well.

Now beyond all of that a language seems to distill sort of values and priorities in the community around it. Or perhaps the community distills them into the image of the language. I think it's a bit of a two way street for that. So even if languages look similar you still have to consider how strong and what the community values (culture in other words) which I think is quite important. I've read that Ruby is a success where Smalltalk failed due to the culture of testing and tools around it.

On Thu, Sep 29, 2011 at 11:50 AM, Sean Copenhaver <sean.co...@gmail.com> wrote:
That could be a result of the flexibility and the values put on Ruby the language. My understanding is the underlying model is mostly simple (dynamic, meta object/class, message passing) but then they put a lot of syntactically sugar and shortcuts on top. Results in a language that values expressibility and esthetics. Look at all the DSL usage they have.

C# is a language that seems to value generality, rigidity, and explicitness. But that seems to be easy off with the additions of extension methods, type inferencing 101 (var keyword), and the dynamic type for the DLR being introduced (and what is nearly abandoned?). Although F# values very different things but they both compile to the same IL and use the same core libraries and both can do OOP.

All the framework stuff though I just am starting to dislike large heavy technologies. You'll spend too much time learning them or stumbling through them. Things move too fast and requirements change. If you have to invest a month into something you are less likely to consider moving off of it for something else as needs change. Smaller more targeted things are easier to pick and understand.

Anyway, I hope that wasn't all rambling. I'm getting very hungry.


On Thu, Sep 29, 2011 at 11:38 AM, Bryan Matthews <matt...@gmail.com> wrote:
True, most languages are not very different unless you start talking OO vs. functional.  At least the difference in language is secondary to the difference in frameworks, tools, and community.  For example, the ruby community seems to have made big waves over the last few years and have earned a reputation for rapidly developing new tools and techniques to solve problems and share with others.  On the other hand, .NET seems to have taken a lot of criticism in the past for lack of innovation and working in isolation.  It seems that may be improving, perhaps as a result of the criticism and awareness?

On Thu, Sep 29, 2011 at 11:03 AM, Bobby Dimmick <kr4...@gmail.com> wrote:
Wow you guys hit on a lot of topics in one thread.. There are a lot of great ideas and comments in here..  Some thoughts...

On Scott Hanselman:
Scott's a pretty nice guy.. I met him briefly at PDC '09..  He describes himself as a "technologist" with a true love of development tools and technologies.  He's fairly big on professional and personal development (read: image), so I can see how he can kind of come off as a jerk at first.

On Languages:
After coding long enough in a couple of dozen languages, you will find that for the most part moving between languages is more of a concern of syntax and semantics than technology.  If the '90's could be considered the decade for the rise of 4th Generation Languages, then I would classify the '00's as the decade of frameworks.  I think you'll find that the majority of the arguments over language X vs Y are really arguments over frameworks, utilities, and tools.

On How Companies View Developers:
Obviously, this varies from organization to organization.  I have done work for the state, work for private industries, and am currently a consultant.  I have been treated as a cog/FTE as well as a demigod.  A lot depends on the attitude of management.  One would think that the specific product or line of business on which the organization is based (i.e. producing a software package vs. SaaS vs. support development) would dictate the importance of individual developers, but that just is not the case.  Many developers (the smart ones at least ;) ) are very concerned with professional development, career continuity, and personal growth.  Unfortunately, most companies are only concerned with the bottom-line or billable percentages.  The smart companies out there realize that by enabling their developers (and IT staff in general) to grow (via training, working on pet projects, or doing R&D) they are building up another form of capital: knowledge.

On Choosing Technologies:
In every project on which I work, the two determining factors which define "success" are: the fundamental requirements, and the timeframe involved.  Customers generally could care less about technology.  In that sense, the tech becomes more of a marketing tool.  Do you think Facebook's 800 million users care about the underlying platform or tools used in development?  How about Twitter?  The small business owner using Quickbooks?  Turn that around and consider the project stakeholders, what do they care about?  Time to market/production?  Training?  Error tracking and ease of deployment?  Support?  What does the development team lead care about?  Efficient code?  Project velocity?  Near-seamless integration?  Developer familiarity?  I think if you took a cross-section of the above requirements, you might find what drives most technology decisions.

Can you think of a language/platform that does not deliver on the above requirements?  Given the right developers, enough time, and a decent plan, nearly any language or platform will work.

All of that having been said, and perhaps to address what seems to be the core question here - on what technology should I base my career, and how do I determine if that technology is the right fit for what I want to do - it depends: on luck, on careful planning, and on ability to take a risk.  I used to be a generalist.  If you dig up an old copy of my resume, you'll find 25 languages and 5 platforms listed.  At about the time that .net came out, I specialized in Java, ColdFusion, C++, and Visual Basic.  I did a lot of soul-searching over a weekend and realized that my career wasn't about the language or tools I was using, but about the solutions that I could provide.  That was the weekend that I decided to commit to the Microsoft stack of technologies.  It doesn't mean that I don't get to still play with cool technologies, platforms, and tools.  But it does mean that I take the language/platform variable out of the equation of my life.  The problems I tackle now are (to me) much more interesting: Sql vs NoSql, CQRS and DDD, platform integration, and solving previously "unsolvable" technology problems - just to name a few.  I plan on looking into Ruby and possibly ErLang, but frankly, I don't have the time.  Does .net solve all problems?  Absolutely not!  Do I still pay attention and participate in other communities?  Absolutely!  Where do I think you should take your career, and is your currently group doing the "right thing"?  Who knows!

The bottom line, one that has taking me a long time to figure out, is that if you want to do development "right" file for a business license and open your own shop (or become the lead in the organization that you love).  Otherwise, you will be spending a lot of frustrating days fighting an uphill battle.

--
You received this message because you are subscribed to the Google
Groups "ColaCodeDojo" group.
To post to this group, send email to colaco...@googlegroups.com
To unsubscribe from this group, send email to
colacodedojo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/colacodedojo?hl=en

--
You received this message because you are subscribed to the Google
Groups "ColaCodeDojo" group.
To post to this group, send email to colaco...@googlegroups.com
To unsubscribe from this group, send email to
colacodedojo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/colacodedojo?hl=en



--
“The limits of language are the limits of one's world. “ - Ludwig von Wittgenstein

"Water is fluid, soft and yielding. But water will wear away rock, which is rigid and cannot yield. As a rule, whatever is fluid, soft and yielding will overcome whatever is rigid and hard. This is another paradox: what is soft is strong." - Lao-Tzu





--
“The limits of language are the limits of one's world. “ - Ludwig von Wittgenstein

"Water is fluid, soft and yielding. But water will wear away rock, which is rigid and cannot yield. As a rule, whatever is fluid, soft and yielding will overcome whatever is rigid and hard. This is another paradox: what is soft is strong." - Lao-Tzu


Bryan Matthews

unread,
Sep 30, 2011, 2:30:19 PM9/30/11
to colaco...@googlegroups.com
I think I agree with what you're saying for the most part.  Some of the languages you listed (Erlang, F#) are a bit off the beaten path, in a good way, whereas most mainstream languages are very similar in terms of what you can accomplish.  I definitely think that a language can influence the type of community that forms around it, and ideally the community can greatly influence the evolution of the language over time.  Naturally ruby is one that comes to mind.  However, I do think that Bobby has a good point here - there's a lot more to it than languages.

Sean Copenhaver

unread,
Sep 30, 2011, 3:09:40 PM9/30/11
to colaco...@googlegroups.com
Indeed, also I'm not suggesting that a team should change up languages all the time. I do think that having languages with different focuses or abilities available to you can be quite the advantage. More so if they can easily interop but a runtime isn't required for that if you are already in more of a service oriented system.

I think F# will gain some more acceptance in the .NET world, but C# has the numbers and it's a solid general purpose statically typed managed object-oriented language which is basically dead center in terms of popularity and understanding. Doesn't mean that will always be the case with all this interest in JavaScript, a near type-less dynamic language that has some object-oriented and functional ideas. Of course C# seems to keep adding functional ideas so people are getting a lot of exposure to things like lazy evaluation, high order functions, and closures to name a few.

Some of the things we concern ourselves with in large C# systems like message bus/queues, distributed services, async services, and parallel tasks we solve with frameworks and misc' pieces, where as in Erlang these are built into the VM and given importance in the language with simple syntax and core semantics. Nothing additional required.

There's a situation where language choice can effect literally how your system is built. Learning Erlang could potentially mean you are capable of developing these kinds of systems more easily and an Erlang developer will be more likely to understand how the system works due to the lower need of frameworks. Not the case with C#.

Of course C#/CLR could grow to include these ideas and semantics, but then I worry about the size and lack of direction for the language (actually I'm a bit worried now). I'm unsure if a behemoth god language benefits anyone.
Reply all
Reply to author
Forward
0 new messages