Weblogs Forum - Heron Needs a Killer App

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Heron Needs a Killer App

53 replies on 4 pages. Most recent reply: Sep 12, 2005 11:48 PM by Kondwani Mkandawire

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 53 replies on 4 pages [ « | 1 2 3 4 | » ]

Kondwani Mkandawire

Posts: 530
Nickname: spike
Registered: Aug, 2004

Re: Heron Needs a Killer App

Posted: Aug 23, 2005 11:54 PM

Reply

Advertisement

> > Lacking a source code debugger?? Now honestly speaking
> > how many newbies of a language know or bother to use
> > a debugger??
>
> If the language is Smalltalk - all of them.
>

Would you not consider Smalltalk a fading language?

> > Taking it a step further, how many seasoned programmers
> > use debuggers?
>
> If the debuggers are sufficiently advanced, all of them.
>
> Many developers I know code in the debugger. You write
> some code, run it, when it runs out of code (calls a
> method not implemented), you get a debugger. Add code and
> click continue. Resume exercising your app. Repeat.
>

I'd be an idiot to argue coz I've never coded in SmallTalk
but in terms of the Java teams I've been involved in
(even with the Large Scale systems I've been involved with
simple code disection and the ocational println statement
has done the trick - for all of us on the team).

Likewise back when I used python there was little
requirement for debuggers.

> > I think stating that lacking a debugger (of any form)
> > makes a language garbage as a teaching language or
> > otherwise is a misconception.
>
> Would you teach biology without microscopes? Astronomy
> without telescopes? Be serious. Debuggers are useful
> tools. Eschewing them makes as much sense as a carpenter
> refusing to use a screwdriver because he has a hammer.
>

I don't think your first lessont in Biology would involve
a microscope (you probably wouldn't use a microscope
for a good while), you would be taught the basics before
delving deeper into it). At least as Newbies in varsity
Biology the prof. never just upped and said folks lets
start disecting.

> How else to see what you code is doing? When confronted
> with a large new system to understand, I typically fire up
> a debugger and set a few strategic breakpoints so I can
> see how control flow happens. It is much faster than
> simply reading static code that may hide much intent in
> polymorphic dispatching.

I guess everyone has different coding habits. As stated
noone on our team uses a debugger, and we code
significantly large systems.

Kondwani Mkandawire

Posts: 530
Nickname: spike
Registered: Aug, 2004

Re: Heron Needs a Killer App

Posted: Aug 23, 2005 11:58 PM

Reply

My apologies for the excessively large post

Michel Parisien

Posts: 25
Nickname: kriggs
Registered: Jul, 2005

Re: Heron Needs a Killer App

Posted: Aug 24, 2005 5:04 AM

Reply

I believe that it shouldn't be cdiggins' job to narrow his focus, particularly this early in the game. The idea of an "all purpose" language is ok, as long as it doesn't bloat. If however Heron was inspired by a single application, it would become very good for that application and less good for all other applications.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Heron Needs a Killer App

Posted: Aug 24, 2005 7:09 AM

Reply

> So what is Heron? What's in the standard library? Perl's
> killer app was text processing because it has good text
> processing built-ins.

The controlling factor for perl, and all unix/shell based tools is pipeline use. perl fit right into the pipeline style programming of the 1980s. This simple integration capability is what empowered it to be successful.

Then, Larry added and added and added features and fixed and fixed and fixed design flaws to keep up with the pace of the users.

> What does Heron offer? Why would I,
> a C/C++/Java programmer, want to use it? Why is it
> special?

For me, this is the killer question. If it does math, calls functions/methods and interacts with the I/O subsystem of the computer, it can eventually grow libraries of objects that are useful. The question is, is that a realistic thing.

When you set back and look at all of the features of the Java platform, that were developed by 1000's of developers, world wide, it's a humbling experience.

I think the best choice the Chris could make would be to create compilation to JVM byte code and compilation to .NET CLR. The language would then have access to all the features of these platforms. It would be the first language available on both platforms and would probably take off like a rocket!

The trick would be to paste together an isolation layer that made exception processing consistent across both platforms etc.

But, I think that is the killer app for any new language...

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Heron Needs a Killer App

Posted: Aug 24, 2005 7:40 AM

Reply

> If it does math,
> calls functions/methods and interacts with the I/O
> subsystem of the computer, it can eventually grow
> libraries of objects that are useful. The question is, is
> that a realistic thing.

The answer is yes. My emphasis when designing Heron was on library developers. I don't care so much about the average developer, for the most part they simply use existing libraries. I believe that Heron's key to success will be if I can successfully make it easier and quicker for library developers to make large-scale libraries which are defect-free, and efficient.

> I think the best choice the Chris could make would be to
> create compilation to JVM byte code and compilation to
> .NET CLR. The language would then have access to all the
> features of these platforms.

And all of the problems. I think it would be wiser to build off of a more stable base than the JVM or .NET platforms. For instance the C++ STL.

> It would be the first
> language available on both platforms and would probably
> take off like a rocket!

I should point out that Scala is already fully supported on JVM and partially supported on .NET. It is my opinion that Scala represents the state of the art of languages designed for virtual machines. It also exposes the weaknesses of building advanced languages on top of the JVM platform.

> The trick would be to paste together an isolation layer
> that made exception processing consistent across both
> platforms etc.
>
> But, I think that is the killer app for any new language...

I think you are correct, for a certain class of languages.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Heron Needs a Killer App

Posted: Aug 25, 2005 12:19 AM

Reply

Well, I guess that in line with current coding fashions the initial objective sould be to release the simplest language that could possibly work and then to periodically add features, as required (but stop before you end up like Java 1.5).

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Heron Needs a Killer App

Posted: Aug 25, 2005 6:46 AM

Reply

> > I think the best choice the Chris could make would be
> to
> > create compilation to JVM byte code and compilation to
> > .NET CLR. The language would then have access to all
> the
> > features of these platforms.
>
> And all of the problems. I think it would be wiser to
> build off of a more stable base than the JVM or .NET
> platforms. For instance the C++ STL.

Please explain what specific problems you think the JVM has that makes it less stable than any other piece of 1000000 line software package.

Sure, it's not small, and many people consider that a problem. I personally consider it one of the biggest benefits of using Java. I don't have to recreate the same libraries everywhere I go in new languages over and over and over. Write it once, run it everywhere!

> > It would be the first
> > language available on both platforms and would probably
> > take off like a rocket!
>
> I should point out that Scala is already fully supported
> on JVM and partially supported on .NET. It is my opinion
> that Scala represents the state of the art of languages
> designed for virtual machines. It also exposes the
> weaknesses of building advanced languages on top of the
> JVM platform.

Scala is not a mass market programming language. It has a limited audience because of the thinking processes needed to use it.

> > The trick would be to paste together an isolation layer
> > that made exception processing consistent across both
> > platforms etc.
> >
> > But, I think that is the killer app for any new
> language...
>
> I think you are correct, for a certain class of languages.

I'll bet that if you provided a JVM bytecode compiler that you'd get a lot more people to use it. I would.

Chris, I have a huge investment in a Java development toolset and mindset. I have absolutely zero desire to use a language that doesn't let me dynamically load class files from arbitrary network locations. I need to be able to do things that the Jini platform provides such as distributed transactions, leasing, RPC etc.

I've done all the simple things in programming. I have all the tools I need, already written in Java. Look on jini.org and java.net for projects under the userid 'greggwon'. That's a small percentage of the things that I still have not shared.

If you are still wanting people to write small libraries and do simple things, then targeting teaching/training might be a good choice. But, I think we need to concentrate on expanding the power and speed with which large scale software systems are developed. We need completely new paradigms to software construction that implies more reuse, and less recreate. There are lots of productive programmers that will sit around and rewrite libraries. But, in the end, what value to the computing world has that really added.

We've done I/O, collections and networking libraries over and over and over.

People are now creating vertical market applications of all these tools to solve more specific problems and less generic problems.

People want plugins to IDES, accounting packages, desktops, everywhere. They want this stuff because they are now comfortable with the level of software development we have achieved. They want to solve and automate more vertically oriented problems that are not as important to the masses.

The Java platform has Service Provider interfaces all over the place because it is clear that not everyone does highlevel things the same way. Different security, different sockets, different logging, different, different different. This variablility doesn't require a new language. It requires new software that fits into the same framework as the existing implementations.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: Heron Needs a Killer App

Posted: Aug 25, 2005 10:12 AM

Reply

I think the best thing you can do right now is to get more people involved in the design and development of Heron and its development tools (this weblog is certainly very useful, but you can't do everything by yourself). That's how all successful languages were developed. I think it's hard to estimate the usefulness of various features without having lots of people actually use them in writing applications.
I agree with Toby that there needs to be a community of Heron users.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Heron Needs a Killer App

Posted: Aug 25, 2005 11:44 AM

Reply

> Would you not consider Smalltalk a fading language?

I would not - it remains the source of nearly all new ideas in programming and is enjoying a resurgence.

GUIs - born in Smalltalk
XP - came from Smalltalk.
Test Driven Development - Smalltalk
Continuation Based Web Apps - First in Smalltalk (Seaside)
Garbage Collection - Smalltalk/LISP
Virtual Machines - Smalltalk
HotSpot - based on smalltalk
generics - duck typing makes these unnecessary.
traits - First implemented using Squeak Smalltalk

If you want to see what people will be doing two years out, see what the smalltalkers are doing now.

> I'd be an idiot to argue coz I've never coded in
> SmallTalk
> but

:-)

> in terms of the Java teams I've been involved in
> (even with the Large Scale systems I've been involved
> with
> simple code disection and the ocational println statement
> has done the trick - for all of us on the team).

How long does it take you to find and fix a problem? You have to identify it, write the change, add the println, recompile, reinit the VM, see if it works, edit, compile, rerun. That's a long cycle.

In smalltalk, when a fault is encountered, a debugger pops open, I can inspect, alter, test, and resume the program immediately without ever restarting the process. Given this immediacy - guess how many more problems I can find and fix per hour than you can.

Let me put it another way. The Squeak community is pretty small, but with this small community, we still manage to have implementations of all the lastest technologies available like xml processing, new kinds of UIs, new ways to do web app development, data storage strategies, etc. How can we keep up? Our development environment is at least an order of magnitude more efficient than yours.

> I don't think your first lessont in Biology would involve
> a microscope

I may be atypical, but my introduction to biology started with cell structure and we worked up in size from there. Kind of like programming.

Kondwani Mkandawire

Posts: 530
Nickname: spike
Registered: Aug, 2004

Re: Heron Needs a Killer App

Posted: Aug 25, 2005 11:44 PM

Reply

> > Would you not consider Smalltalk a fading language?
>
> I would not - it remains the source of nearly all new
> ideas in programming and is enjoying a resurgence.
>

I went through a Lisp Tutorial for 30 minutes, maybe
its coz I've been Javarized for 5+ years but man,
that stuff seems a bit too complex.

> generics - duck typing makes these unnecessary.

In my opinion, Generics are a complicated addition to a
language, I cannot say I'm was initially fond of its addition to Java for instance (but as one gets more
comfortable with its use, I think they're a powerful
tool), so OK I hear you on that one.

> traits - First implemented using Squeak Smalltalk
>
> If you want to see what people will be doing two years
> out, see what the smalltalkers are doing now.
>

In my humble opinion, I've found that everything that
can be done in one language can be done in another
(might require extra work - but can be achieved in
any case), most of us fullfill tasks as is needed
which is why I'm assuming a good chunk of us coders
use Java as we feel comfortable with it.

> :-)
>

>
> How long does it take you to find and fix a problem? You
> have to identify it, write the change, add the println,
> recompile, reinit the VM, see if it works, edit, compile,
> rerun. That's a long cycle.

Believe it or not because of Java's OO nature, and
we usually spend significant design on structuring
classes and Design, it doesn't take that long.

> this immediacy - guess how many more problems I can find
> and fix per hour than you can.

I highly doubt that, by the way has this turned into
a SmallTalk vs. Java debate?

> How can we keep up? Our development environment is at
> t least an order of magnitude more efficient than yours.

Once again is this a Small Talk vs. Java issue?
Anyways, over the weekend I'll run some Googles on
SmallTalk out of curiosity so I hopefully have a
better understanding of its capabilities.

>
> I may be atypical, but my introduction to biology started
> with cell structure and we worked up in size from there.
> Kind of like programming.

I guess approaches are different I din't see a Microscope
till mid-semester (they first give us diagramatic
impressions of what we would see, identify them
then comes the microscope. Makes sense in programming
to first crunch out what everything is then break it
down (if need be with a debugger).

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Heron Needs a Killer App

Posted: Aug 26, 2005 9:58 AM

Reply

> In my humble opinion, I've found that everything that
> can be done in one language can be done in another
> (might require extra work - but can be achieved in
> any case)

You will have a hard time replicating this in Java:
http://seaside.st

Also, I've found that some languages foster creativity, others stifle it. If you're going to use something to teach a topic, best that it is friendly, transparent, interactive, and doesn't discourage experimentation (nothing discourages experimentation like a core dump or abnormal termination).

> by the way has this turned into
> a SmallTalk vs. Java debate?

More of a dynamic language with interactive tools vs compiled language relying on print statements to figure out what the code is doing debate.

I rather think there has been precious little new in CS in the last 15 years. Its all just variations on the buggy whip.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Heron Needs a Killer App

Posted: Aug 26, 2005 1:40 PM

Reply

> > In my humble opinion, I've found that everything that
> > can be done in one language can be done in another
> > (might require extra work - but can be achieved in
> > any case)
>
> You will have a hard time replicating this in Java:
> http://seaside.st

What specific feature of smalltalk is exploited here that Java can't do?

Marty Sasaki

Posts: 2
Nickname: msasaki
Registered: Aug, 2005

Re: Heron Needs a Killer App

Posted: Aug 26, 2005 2:13 PM

Reply

As far as education goes, most students that I have run into lately (mostly at places like the Harvard Extension School) don't want to learn a language that isn't useable to get a job. Why learn Python when there are so many Java jobs?

I think it is more important to get a useable development system out there, even if it lacks bells and whistles, and let people play with it. If it is successful at doing the things you are designing it to do, then folks will like it and will write small applications in it to do useful things. As the paradigms get worked out bigger apps will follow, then you can talk about your killer app.

Good luck with things.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Heron Needs a Killer App

Posted: Aug 26, 2005 2:33 PM

Reply

> What specific feature of smalltalk is exploited here that
> Java can't do?

Continuations. Java doesn't have them and you don't have adequate access to the VM to implement them in a straight forward manner.

A seaside-like environment is being attempted that fakes continuations using one thread per session with clever thread resumption strategies, but I don't think this will cleanly and transparently support the back button the way seaside does.

See: http://seaside.st/Documentation/CallandAnswer/

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Heron Needs a Killer App

Posted: Aug 26, 2005 3:08 PM

Reply

> > What specific feature of smalltalk is exploited here
> that
> > Java can't do?
>
> Continuations. Java doesn't have them and you don't have
> adequate access to the VM to implement them in a straight
> forward manner.
>
> A seaside-like environment is being attempted that fakes
> continuations using one thread per session with clever
> thread resumption strategies, but I don't think this will
> cleanly and transparently support the back button the way
> seaside does.
>
> See: http://seaside.st/Documentation/CallandAnswer/

I guess, I don't see what is missing... Continuations as implemented here are not necessary to do this.

Flat View: This topic has 53 replies on 4 pages [ « | 1 2 3 4 | » ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use