Zissou is stepping on Westsiders

[Matt Youell]

Hey y'all. 

I told a couple of you already, but the next Zissou Society meeting is on Thursday, May 30th at Janrain downtown. That happens to coincide with the usual meetup time for Westsiders. Oops!

Perhaps you'll consider it a very special Westsider's meeting? :)

Hope you can make it.

Matt

http://calagator.org/events/1250464171

[Phil Tomson]

Yeah, I think we should visit the Zissou Society this month.

Phil

--
You received this message because you are subscribed to the Google Groups "WestsideProggers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to westsideprogge...@googlegroups.com.
To post to this group, send email to westside...@googlegroups.com.
Visit this group at http://groups.google.com/group/westsideproggers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Eric Wilhelm]

# from Phil Tomson on Tuesday 14 May 2013:

>Yeah, I think we should visit the Zissou Society this month.

Hey, it's on the west side. Next month, veritable quandary right? (And
soon after that, on a boat nearly in the middle of the river.)

--Eric
--
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------

[M. Edward (Ed) Borasky]

I'm not going to make it this month - one of the content strategy
gurus is in town.

> --
> You received this message because you are subscribed to the Google Groups "WestsideProggers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to westsideprogge...@googlegroups.com.
> To post to this group, send email to westside...@googlegroups.com.
> Visit this group at http://groups.google.com/group/westsideproggers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench
http://j.mp/CompJournBench/

Get out of the building - and don't come back till you have the order!

[M. Edward (Ed) Borasky]

M4? Gag ... retch ... Strachey's GPM was *the* macro processor for all
time. I coded it up for the IBM 1620 on a dare. ;-)

On Tue, May 14, 2013 at 8:08 PM, Matt Youell <ma...@youell.com> wrote:

[Matt Youell]

The middle? Clearly it would need to be at least a little bit on the west side of middle. Unless we just go by meridian, then we're in the western hemisphere and next month can be Vegas.

On Sun, May 19, 2013 at 11:18 PM, Eric Wilhelm <enob...@gmail.com> wrote:

[Richard Fobes]

On Monday, May 20, 2013 12:25:09 AM UTC-7, Matt Youell wrote:

The middle? Clearly it would need to be at least a little bit on the west side of middle. Unless we just go by meridian, then we're in the western hemisphere and next month can be Vegas.

Eric said "nearly in the middle," so there is no doubt that we all want to stay on the "west side."

I won't be there.

I agree the convergence (of the two groups this month) makes sense, but I have to admit that I'm not that interested in the two languages being discussed.

Richard
 

[Matt Youell]

Yeah, I go back and forth on whether to announce the languages or not for just this reason. There is so much variability from speaker to speaker that it's hard to judge a talk by the topic. But I understand!

Sent from my iPhone

[Richard Fobes]

On Wednesday, May 22, 2013 1:33:05 PM UTC-7, Matt Youell wrote:

Yeah, I go back and forth on whether to announce the languages or not for just this reason. There is so much variability from speaker to speaker that it's hard to judge a talk by the topic. But I understand!

Posting the topics is essential.

For "hot" topic ideas, I suggest looking at "lambda-the-ultimate.org" to see which topics get the most interest.  I've been lurking there (thank you for telling me about it!) and there are a couple of intriguing topics: graphical programming (or what I'd call "legos on a screen"), learnability (easy-to-learn, yet powerful languages), and I forget what else.  Dashrep has, or will have later, some of these characteristics, but I don't want to get next year's OSB offer of a Dashrep presentation rejected because of already having given a similar presentation so I'm not offering such a talk yet (plus I need to have my Dashrep-based website working to establish credibility for the usefulness of the language).

Richard

[M. Edward (Ed) Borasky]

Speaking of languages that may or may not succeed even though they're
backed by a large organization, has anyone besides me looked at
Mozilla's RUST yet? I took a look at it and said, "Ewww". ;-) But then
I feel the same way about Go, Dart, CoffeeScript and Markdown.

> --
> You received this message because you are subscribed to the Google Groups
> "WestsideProggers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to westsideprogge...@googlegroups.com.
> To post to this group, send email to westside...@googlegroups.com.
> Visit this group at http://groups.google.com/group/westsideproggers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Phil Tomson]

I've taken a bit of a look at Rust.  I think it's definitely less "Ewww-y" than Go since Rust at least has incorporated some functional aspects (lambdas, pattern matching, etc),  generics and no null pointers.  But, Rust is looking like a very complicated beast - I'm wondering if it's eventually going to be about as complicated as C++ when they get done.  I suppose you can't create a new systems programming language aimed at replacing C++ without introducing a lot of complication.  

Phil

[M. Edward (Ed) Borasky]

C++ has a *standard*. Case closed.

[Phil Tomson]

...and is designed by committee.  Your point being?

[M. Edward (Ed) Borasky]

Name a language that isn't ultimately designed by a committee of users
and implementers. ;-) What I like about standards committees is the
formalization of language syntax and semantics, and the process -
"let's break as little existing code as possible and think about
engineering economics."

Ruby in particular turned out to be such a cowboy coders' rodeo that I
gave up on it. When I need rvm or rbenv to get work done - multiple
versions of Ruby, multiple versions of gems - I spend all my time
troubleshooting other peoples' code. That leaves me little time to
create my own bugs. Ruby needs a formal standards committee badly.

I don't mind being a beta tester for Fedora Linux or R because they're
solidly managed communities. Most everything works most of the time.
In the 13 years I've been using R, I think I've found maybe four or
five bugs in CRAN packages and *none* in R itself, even in beta
versions!

[markus]

> I've taken a bit of a look at Rust. I think it's definitely less
> "Ewww-y" than Go since Rust at least has incorporated some functional
> aspects (lambdas, pattern matching, etc), generics and no null
> pointers. But, Rust is looking like a very complicated beast - I'm
> wondering if it's eventually going to be about as complicated as C++
> when they get done. I suppose you can't create a new systems
> programming language aimed at replacing C++ without introducing a lot
> of complication.

The last time I looked at rust, I had the impression of premature
optimization in the design space, a sort of "I'm thinking of an issue
that isn't solvable by anything simple so let's do something complicated
and quietly hope that works" mentality. There's another way to address
such issues, by pruning the space to what you can address cleanly (which
has it's own problems, for sure).

Forth and C++ are, in some sense, both aiming at the same target, but
they are several orders of magnitude apart in complexity.

-- M

[M. Edward (Ed) Borasky]

On Thu, May 23, 2013 at 12:57 PM, markus <mar...@reality.com> wrote:
>
>> I've taken a bit of a look at Rust. I think it's definitely less
>> "Ewww-y" than Go since Rust at least has incorporated some functional
>> aspects (lambdas, pattern matching, etc), generics and no null
>> pointers. But, Rust is looking like a very complicated beast - I'm
>> wondering if it's eventually going to be about as complicated as C++
>> when they get done. I suppose you can't create a new systems
>> programming language aimed at replacing C++ without introducing a lot
>> of complication.
>
> The last time I looked at rust, I had the impression of premature
> optimization in the design space, a sort of "I'm thinking of an issue
> that isn't solvable by anything simple so let's do something complicated
> and quietly hope that works" mentality. There's another way to address
> such issues, by pruning the space to what you can address cleanly (which
> has it's own problems, for sure).

I think it was more like "Google just ripped apart WebKit and they've
got the cash to buy users for Go, so we have to create something too.
;-)" I like Firefox OS and I think I like asm.js but I don't think the
world needs another compiled curly-brace language when there's C++ and
thousands of libraries. I don't think either Rust or Go (or Dart) has
any reason for being other than organizational ego.

>
> Forth and C++ are, in some sense, both aiming at the same target, but
> they are several orders of magnitude apart in complexity.

FORTH is Algol turned inside-out or some bizarre category-theoretic
dual of Scheme. ;-) Indeed, Hewlett-Packard in a rare burst of sanity
(and IIRC in Corvallis) came up with the Reverse Polish Lisp language
for calculators. But it's really FORTH with objects and not a 'Lisp'
as such.

[Phil Tomson]

Could be that their focus is too much about trying to replace C++ and that's causing them to converge on C++.

On Thu, May 23, 2013 at 12:57 PM, markus <mar...@reality.com> wrote:

[Phil Tomson]

On Thu, May 23, 2013 at 1:14 PM, M. Edward (Ed) Borasky <zn...@znmeb.net> wrote:

On Thu, May 23, 2013 at 12:57 PM, markus <mar...@reality.com> wrote:
>
>> I've taken a bit of a look at Rust.  I think it's definitely less
>> "Ewww-y" than Go since Rust at least has incorporated some functional
>> aspects (lambdas, pattern matching, etc),  generics and no null
>> pointers.  But, Rust is looking like a very complicated beast - I'm
>> wondering if it's eventually going to be about as complicated as C++
>> when they get done.  I suppose you can't create a new systems
>> programming language aimed at replacing C++ without introducing a lot
>> of complication.
>
> The last time I looked at rust, I had the impression of premature
> optimization in the design space, a sort of "I'm thinking of an issue
> that isn't solvable by anything simple so let's do something complicated
> and quietly hope that works" mentality.  There's another way to address
> such issues, by pruning the space to what you can address cleanly (which
> has it's own problems, for sure).

I think it was more like "Google just ripped apart WebKit and they've
got the cash to buy users for Go, so we have to create something too.
;-)" I like Firefox OS and I think I like asm.js but I don't think the
world needs another compiled curly-brace language when there's C++ and
thousands of libraries. I don't think either Rust or Go (or Dart) has
any reason for being other than organizational ego.

Not sure if it's organizational ego as much as it is an effort to anesthetize their pain as Sun tried years before by creating Java (and they ended up inflicting much pain on us all as a result ;-)

Mozilla has this huge C++ code base and they know that there are intrinsic "features" of C++ which lead to all kinds of bugs (null pointers, memory management issues, etc. ) and it all gets worse as you get into multi-threaded, concurrent code.  So their motivation is to create a replacement for C++ that will eliminate many of the intrinsic problems with C++ & concurrency (while looking to things like Haskell & OCaml for inspiration).  It seems like a laudable goal, but the problem for them is that C++ is a moving target.  C++11 introduces a lot of features that can solve some of the safety issues (if they get used): New built-in smart pointer types and move-semantics for example. C++11 also introduces some functional-ish features like lambdas (ok, they're kind of ugly, but they're there) and even some limited type inference (auto) as well.  And C++14 (they seem to be aiming at 2014 anyway, we'll see if they hit that target) introduces more changes.

So the question is: will C++ "improve" faster than Rust can gain adoption in that space?

I often wonder if Java would have gained a foothold at all if C++ compilers circa 1996 had good support for templates and if the culture of C++ would have shifted sooner to smart pointers (which require good template support) and patterns like RAII.

>
> Forth and C++ are, in some sense, both aiming at the same target, but
> they are several orders of magnitude apart in complexity.

FORTH is Algol turned inside-out or some bizarre category-theoretic
dual of Scheme. ;-) Indeed, Hewlett-Packard in a rare burst of sanity
(and IIRC in Corvallis) came up with the Reverse Polish Lisp language
for calculators. But it's really FORTH with objects and not a 'Lisp'
as such.

--
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench
http://j.mp/CompJournBench/

Get out of the building - and don't come back till you have the order!

[Patrick Logan]

I've followed Rust a bit, but never tried it. I am generally positive toward it.

One thing to note is that it is still considered a research project.
No production code has been remotely associated or planned, TTBOMK.
Rust seems to have a modest investment that could turn out to be a
really good systems language down the road a bit. The Rust definition,
not to mention the implementation, are significantly immature at this
time.

Rust's safety, expressiveness, and concurrency capabilities per
"complexity unit" seems to me to be greater than C++'s. But it is
difficult to to argue languages objectively and absolutely. There are
so many different aspects of each language and so many different
reasons for choosing one or the other.

[markus]

My main problem with C++ is that it works like spell casting in D&D; if
you want to do something you have to spend X amount of time memorizing
the spell, then use it, but if you want to cast it again a week later,
you have to learn it all over again.

There are languages I haven't used in 5 to 10 years that I still have a
good model of the semantics of in my head, but C++ I can't honestly say
I "knew the semantics of" even when I was writing it.

-- M

[M. Edward (Ed) Borasky]

I had the perfect solution to that - just use the FORTRAN-compatible
subset of C ;-)

[markus]

> I had the perfect solution to that - just use the FORTRAN-compatible
> subset of C ;-)

lol.

[M. Edward (Ed) Borasky]

It took me about a month to learn row-major arrays starting at zero
and printf instead of FORMAT. I never did figure out the underscore
nonsense for mixing the two languages in the loader. ;-)

[Phil Tomson]

On Thu, May 23, 2013 at 3:34 PM, markus <mar...@reality.com> wrote:

And some of it's semantics are changing as time goes along, like the move semantics stuff in C++11.

C++ style has changed a lot over the last 10 years, so the way you would have written something 10 years ago may not be the way you want to do it now.  Lots of templates & smart pointers now, for example, and less inheritance. Some of this change started happening well before C++11 with the availability of the Boost libs. And now that lambdas are part of C++11 you're seeing a lot more functional-style C++ which you wouldn't have seen at all 10 years ago. But it really depends on where you work, I suppose. At Mentor Graphics most of the C++ code would have been familiar to a C++ programmer from 1996 (they frowned upon template & even STL usage, for example).

Speaking of stylistic changes in language usage over time,  Ruby style has changed some since I was last actively writing Ruby (about 2007). For example, that  hangman example Markus presented at last PDX.rb had something like: somelist.map(&:foo).  I had to really think about what was going on there. Then I remembered there was some discussion of this on the ruby talk list back then, but I always preferred the more explicit: somelist.map {|obj| obj.foo }. The shorthand way of doing it seemed pretty fringey back then, but now apparently it's become the mainstream Ruby idiom. 

-- M

[Matt Youell]

On Thu, May 23, 2013 at 10:19 AM, Richard Fobes <pr...@solutionscreative.com> wrote:

 

Posting the topics is essential.

For "hot" topic ideas, I suggest looking at "lambda-the-ultimate.org" to see which topics get the most interest.  I've 

I'm not looking for hot topics. I'm looking for novel yet durable ideas that will stimulate thinking. Zissou is intended to be a curated experience. That's why I run it differently from other user groups. The challenge is never topics, it's speakers. We have a lot of interested learners and too few interested (and interesting) teachers.

 

[Matt Youell]

Cherry picking from the thread:

>The last time I looked at rust, I had the impression of premature optimization in the design space

Ditto. My first pass at it was very brief and very superficial, but as one example of a turn-off, 'fn' is the function keyword. That's just superficial syntax - you can get used to it. But the underlying thinking is "typing is hard" instead of "let's be more expressive".  Also by using C syntax they're just clinging to the edge of the pool.

I started a more serious evaluation of Rust last week and haven't finished, but I have found some things to like. The problem for me is that I can find the things I like in other languages. For example, pattern matching is nifty, but I think I like Erlang's better.

> So the question is: will C++ "improve" faster than Rust can gain adoption in that space?

The answer is 'no'. Not that Rust will win anything worth winning, necessarily, it's just that C++ moves at a glacial pace. *cough* lambdas *cough*

> Could be that their focus is too much about trying to replace C++ and that's causing them to converge on C++.

Agreed++

> I often wonder if Java would have gained a foothold at all if C++ compilers circa 1996 had good support for 

> templates and if the culture of C++ would have shifted sooner to smart pointers (which require good template 

> support) and patterns like RAII.

It's easy to lose track of what a huge change Java brought. C++ was not going to win that fight. On the other hand, I think C++ did win in the places where it was appropriate.

>  For example, that  hangman example Markus presented at last PDX.rb had something like: somelist.map(&:foo).

>  I had to really think about what was going on there.

This is a good thing though. It's not good for you in the moment when you have to think about it. But it's an idiom, and once you've used it, you own it. It's that expressiveness I was talking about before.

The syntax might be very Ruby-bound, but it's continuing a general trend of compressing things down to their bare forms to reflect the shape of the problem. Languages have to keep making inroads like that, which means continual change. One of the reasons that I still like C# is that they have iterated a *lot*.

Matt

[Phil Tomson]

On May 23, 2013 8:22 PM, "Matt Youell" <ma...@newmoniclabs.com> wrote:
>
> Cherry picking from the thread:
>
>
> >The last time I looked at rust, I had the impression of premature optimization in the design space
>
> Ditto. My first pass at it was very brief and very superficial, but as one example of a turn-off, 'fn' is the function keyword. That's just superficial syntax - you can get used to it. But the underlying thinking is "typing is hard" instead of "let's be more expressive".  Also by using C syntax they're just clinging to the edge of the pool.
>

Yeah, why not put 'fun' in the language ? Typing 'function' is just too long.

> I started a more serious evaluation of Rust last week and haven't finished, but I have found some things to like. The problem for me is that I can find the things I like in other languages. For example, pattern matching is nifty, but I think I like Erlang's better.
>

I prefer ML's pattern matching to Rust's.  Which, BTW, kind of makes me wonder why they couldn't have taken an existing *ML, spiffed it up a bit and given it a more modern LLVM back end with good concurrency support instead of inventing a whole new language?  Seems like that would have met most of their goals.

>
>
> > So the question is: will C++ "improve" faster than Rust can gain adoption in that space?
>
> The answer is 'no'. Not that Rust will win anything worth winning, necessarily, it's just that C++ moves at a glacial pace. *cough* lambdas *cough*
>
>

Yeah,  but the C++ committee folks seem to be realizing that they need more frequent but smaller updates. Time will tell if they can make good on that. C++14 is supposed to focus on updates to the standard library.

>
> > Could be that their focus is too much about trying to replace C++ and that's causing them to converge on C++.
>
> Agreed++
>
>
>
> > I often wonder if Java would have gained a foothold at all if C++ compilers circa 1996 had good support for 
> > templates and if the culture of C++ would have shifted sooner to smart pointers (which require good template 
> > support) and patterns like RAII.
>
> It's easy to lose track of what a huge change Java brought. C++ was not going to win that fight. On the other hand, I think C++ did win in the places where it was appropriate.
>

I think Java's main appeal was the 'write once run everywhere' marketing. And all the applet hype which now seems so quaint. We were gonna ship all kinds of Java byte code between the server and browser - now we ship JavaScript instead.

Other than the marketing and the appeal of automatic garbage collection I'm not seeing that Java was a huge change.  That was the big disappointment at the time - Sun could've been much more innovative with Java but they just seemed to play it so safe (that's the same problem I have with Go).

>
>
> >  For example, that  hangman example Markus presented at last PDX.rb had something like: somelist.map(&:foo).
> >  I had to really think about what was going on there.
>
> This is a good thing though. It's not good for you in the moment when you have to think about it. But it's an idiom, and once you've used it, you own it. It's that expressiveness I was talking about before.
>

Maybe, but as I mentioned earlier, I prefer the longer version with the explicit block - just seems easier to read and understand what's going on.  I doubt I'll adopt the shorter idiom at this point when writing Ruby code - this is probably because I'm old and learned Ruby well before Rails existed - damn kids get off my lawn! :-)

Phil

[M. Edward (Ed) Borasky]

On Thu, May 23, 2013 at 9:23 PM, Phil Tomson <philt...@gmail.com> wrote:

> I prefer ML's pattern matching to Rust's. Which, BTW, kind of makes me
> wonder why they couldn't have taken an existing *ML, spiffed it up a bit and
> given it a more modern LLVM back end with good concurrency support instead
> of inventing a whole new language? Seems like that would have met most of
> their goals.

Or, they could learn to code in Ocaml or Clojure or Scala or Erlang or
Haskell or Go. I think it was purely ego-driven - "Sun invented a C++
replacement, Microsoft invented a C++ replacement, Next/Apple invented
a C++ replacement, Google invented a C++ replacement - it's Mozilla's
*turn*." ;-)

> I think Java's main appeal was the 'write once run everywhere' marketing.
> And all the applet hype which now seems so quaint. We were gonna ship all
> kinds of Java byte code between the server and browser - now we ship
> JavaScript instead.

IIRC Java's first big win was applets - that showed up long before all
the server-side stuff, and Sun and Microsoft even managed to go to
court over IP issues. JavaScript was Netscape's way of getting out of
the Sun - Microsoft crossfire. ;-)

[Matt Youell]

On Thu, May 23, 2013 at 9:23 PM, Phil Tomson <philt...@gmail.com> wrote:

I prefer ML's pattern matching to Rust's.  Which, BTW, kind of makes me wonder why they couldn't have taken an existing *ML, spiffed it up a bit and given it a more modern LLVM back end with good concurrency support instead of inventing a whole new language?  Seems like that would have met most of their goals.

I don't know the project history, but I suspect they set out to migrate gobs of C/C++ code. Having a C look kind of matches that I guess. Or maybe it was a pure marketing thing, trying to make it appeal to the C set.

 

I think Java's main appeal was the 'write once run everywhere' marketing. And all the applet hype which now seems so quaint. We were gonna ship all kinds of Java byte code between the server and browser - now we ship JavaScript instead.

Other than the marketing and the appeal of automatic garbage collection I'm not seeing that Java was a huge change.  That was the big disappointment at the time - Sun could've been much more innovative with Java but they just seemed to play it so safe (that's the same problem I have with Go).

In '99 I was working with C++ with templates and the STL. Those last two made me a little too avant-garde for the data processing company I worked for, but they tolerated it. I mainly used the collections in the STL. Iterators were a little over my head at the time. We had a home-grown string class to do text processing because C++ had no native string type. It was all char* unless you rolled your own. The awesome things about this set up: everything ran fast as hell, templates were fun. The bad things: null pointer errors, copy semantics were hard to keep straight, templates were really hard to maintain, compilation took forever, our string class was idiosyncratic, and when we wanted to do fairly easy things we had to use third party libraries or roll our own.

In early 2000 I changed jobs and was finally doing more than trivial applets. Java gave me memory management, a standard library, first-class strings, single-inheritance, clearer copy semantics, far fewer null errors, and generally cleaner-looking code that I could understand. (Except for the design-pattern nonsense they had foisted on everyone in 1.1)  

So yeah, Java was a big change if you were in the right place. Kind of like getting a BigMac if you're starving in the desert. You'll think that BigMac is the greatest thing ever until you get out of the desert and get some better food. :)

What's funny to me is that when I look back at these two jobs, Perl was the right solution for both. I guess I should have been more pushy.

 

Maybe, but as I mentioned earlier, I prefer the longer version with the explicit block - just seems easier to read and understand what's going on.  I doubt I'll adopt the shorter idiom at this point when writing Ruby code - this is probably because I'm old and learned Ruby well before Rails existed - damn kids get off my lawn! :-) 

The longer version with the explicit block is still totally confusing if you aren't familiar with the block idiom. When I first started working with Ruby I couldn't remember where the parameter went - before the brace or after it? It's an odd syntax until you're familiar with it. Syntax is all shorthand for something.

[Eric Wilhelm]

# from Phil Tomson on Thursday 23 May 2013:
> On Thu, May 23, 2013 at 3:34 PM, markus wrote:
>>...

>> There are languages I haven't used in 5 to 10 years that I still
>> have a good model of the semantics of in my head, but C++ I can't
>> honestly say I "knew the semantics of" even when I was writing it.

>...

>C++ style has changed a lot over the last 10 years, so the way you
>would have written something 10 years ago may not be the way you want
>to do it now.

I learned Objective C (not apple's) around a time when I was debugging
C++ and XS code, so have always sort of understood it as a preprocessor
dialect as if everything about it could be derived from first principles
of "if you started with C and wanted to ..." But I imagine you have to
also be a historian to really know the language.

>Speaking of stylistic changes in language usage over time, Ruby style

>has changed some ... somelist.map(&:foo). ..., but now apparently it's

>become the mainstream Ruby idiom.

And/or a standard feature of team "style guides" (where "never" and
"always" are equally likely.) (But will it get used without the comment
"# send foo to each item"? A guy can dream.)

[Richard Fobes]

Clarification: By "hot" topics I don't mean "hot" languages.  The topics that have the most posts seem to be about "cool" concepts that are "novel yet durable ideas that will stimulate thinking."

The topic I forgot to specifically mention was "What will programming look like in 2020?"  That certainly stimulates my thinking.  It has 247 "replies," including many thought-provoking perspectives.

Richard

[M. Edward (Ed) Borasky]

Programming now isn't much different now from what it was seven years
ago. The only major paradigm shift is the rise of NoSQL databases;
even MapReduce was around back then. I think in 2020 the only major
shift will be quantum computing. People are paying real money to solve
real problems with it now.

And the browser won't exist any more. Huge code bases like that just
aren't sustainable without crumbling - Chromium is such a junkpile
that Fedora won't even package it.

> --
> You received this message because you are subscribed to the Google Groups
> "WestsideProggers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to westsideprogge...@googlegroups.com.
> To post to this group, send email to westside...@googlegroups.com.
> Visit this group at http://groups.google.com/group/westsideproggers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Richard Fobes]

On Friday, May 24, 2013 9:47:27 PM UTC-7, M Edward Borasky wrote:

And the browser won't exist any more. ...

 

Quite the contrary.  I'll predict that apps will decline as HTML, CSS, and JavaScript evolve to enable the browser to be the primary user interface.  That user interface will be connected locally to network-connected local resources (such as a calendar that doesn't become inaccessible when the Internet goes down or a power failure occurs), and connected to Internet-based resources for all the usual shared "resource-things."

As for languages not having evolved much, I agree.  Text processing is still primitive (in the sense of awkwardness, not processing power), which is why I created the Dashrep language.  (BTW, I use the Dashrep language in a way that gets around some of the limitations of CSS.)

I see lots of potential for either SVG or something like SVG.  That would overcome many of the weaknesses of HTML.  (My attempts to generate valid SVG have not been successful, so SVG has unnecessary constraints that make it much pickier than HTML.)

As for quantum computing, transistor-based ICs still have lots and lots of room for improvement in both speed and size.  Too bad Intel doesn't know how to work with inventors to make that happen more quickly.

Richard

[M. Edward (Ed) Borasky]

On Sun, May 26, 2013 at 10:45 AM, Richard Fobes
<pr...@solutionscreative.com> wrote:
> On Friday, May 24, 2013 9:47:27 PM UTC-7, M Edward Borasky wrote:
>>
>> And the browser won't exist any more. ...
>
>
> Quite the contrary. I'll predict that apps will decline as HTML, CSS, and
> JavaScript evolve to enable the browser to be the primary user interface.

Oh, HTML, CSS and JavaScript will still be around; they just won't be
packaged in a massive operating system known as a browser - they'll be
executed directly as needed.

[snip]

> As for languages not having evolved much, I agree. Text processing is still
> primitive (in the sense of awkwardness, not processing power), which is why
> I created the Dashrep language. (BTW, I use the Dashrep language in a way
> that gets around some of the limitations of CSS.)

Well, between regular expressions and statistical techniques, I'd say
text processing is in pretty good shape.

>
> I see lots of potential for either SVG or something like SVG. That would
> overcome many of the weaknesses of HTML. (My attempts to generate valid SVG
> have not been successful, so SVG has unnecessary constraints that make it
> much pickier than HTML.)

I have a pretty good book about SVG - it's
http://www.amazon.com/Building-Web-Applications-SVG-ebook/dp/B008MQH2HS

>
> As for quantum computing, transistor-based ICs still have lots and lots of
> room for improvement in both speed and size. Too bad Intel doesn't know how
> to work with inventors to make that happen more quickly.

Intel's strategic problems aren't at the fab level but higher up.
Their server monopoly is at risk from ARM chips now, IA-64 never did
live up to its potential and there's nothing smaller than a ChromeBook
that uses x86_64 chips in large numbers any more. Sure, they have
plenty of room to compete with ARM on compute per watt in silicon, but
they can't say, "ARM doesn't run the software x86_64 does" for much
longer.

[Patrick Logan]

> ARM chips

What's the over/under on the years until Intel manufactures ARM again...?

[M. Edward (Ed) Borasky]

On Sun, May 26, 2013 at 12:47 PM, Patrick Logan <patric...@gmail.com> wrote:
>> ARM chips
>
> What's the over/under on the years until Intel manufactures ARM again...?

I doubt they'd do that. If they're going to do something strategic it
would be in the GPU arena, I'd think. It's too bad there's no
practical use case for a 128-bit machine. ;-)

[Patrick Logan]

OK, so I'll put you down for the "over" no matter what. ;-/

There were rumors not long ago that Intel might make ARMs for Apple if
Apple agreed to use Atoms in higher-end tablets.

And Intel has taken a step toward the foundry business for FPGAs. (And
ARM cores are showing up in FPGAs...)

Add, I wonder how well Atom can ride the cost curve downward against
the ARM, even with Intel's manufacturing ability.

[Phil Tomson]

Full disclosure: I've worked at Intel for a couple of years now, but it's a huge place and other than what I read on the internal propaganda site I'm only privy to a very, very tiny part of what's going on.  I try to take the propaganda with a grain of salt, however. 

My take: Intel will hold the server biz with Silvermont (http://hexus.net/tech/news/cpu/55061-intels-silver-bullet-silvermont-takes-aim-arm/ - I have to google all this stuff to make sure I'm not mentioning code names that aren't out there already ;-) as it appears to be besting ARM in the performance/watt department.  ARM will make some inroads, but it will remain a niche player in servers.

But in SOCs (that go into phones & tablets) I don't think Intel quite understands the biz. ARM is like legos. Companies like Apple can license the IP and then build their own peripherals around the processor (SOC = System On Chip). Intel wants to give these companies all the pieces of the SOC take it or leave it. Apple likes control. They probably won't like Intel's combination of peripherals which is why they roll their own SOC (currently built by Samsung, though).  And, barring some kind of radical change, Intel isn't going to be licencing the Intel Architecture IP anytime soon.

Intel's big advantage is manufacturing - Intel will have sub-20nm chips in production at least a couple of years ahead of their competitors - that's a pretty big deal at this point and they'll be even further ahead at the next process node. Samsung is probably going to be the next with sub-20nm. And as we go sub 20nm, there are less and less players that can afford to build fabs to do that - probably only Intel, Samsung and maybe TSMC. If you haven't taken a drive out to Hillsboro lately, I'd suggest you drive around the Ronler Acres campus and count the construction cranes. This is what spending $3B can do. (and they just finished spending $3B to build the first D1X FAB, the D1X Expansion is now in full swing and another $3B is being spent - and that doesn't count all the other stuff like parking garages and office buildings they're building around there)  Only some kind of government entity can spend that much or more. (isn't the Columbia River Crossing coming in at $2B?)

But... Intel can only afford to do these multi-$Billion fab builds because margins on x86 processors kind of look like the kinds of margins that BigPharma gets. The margins on mobile processors are much lower.

And I think Richard mentioned Intel's NIH problem - I think this will eventually be a big problem for them. Intel is very much a bubble. There's kind of this meme floating around that you often notice that says that Intel has the best engineers and the best ideas... it's in the corporate propaganda, maybe even in the drinking water :) The problem comes when you get too many people actually believing that. It tends to lead to a downfall. On the internal blogs there was much discussion on who the next CEO was going to be. Whenever anyone suggested that maybe the search should go outside of Intel for someone with fresh ideas, there were howls of "But, we need someone from inside who understands our unique culture!"... and indeed, once again they chose an insider who has never worked anywhere else.

Intel rarely leads anymore partially because of this bubble. Something external happens (like mobile this time around) and everybody gets scared and they circle the wagons and do mobile. Last time around it was the AMD threat in the mid 2000's - they ended up trouncing AMD, but it took too long to recognize the initial threat. It's the same kind of reactionary pattern all over again with mobile, only this time I don't think it's gonna be as easy as it was beating AMD. 

As for the foundry biz and FPGAs -  FPGAs are generally orthogonal to what Intel does, so it's easy for them to decide to be a foundry for the FPGA companies because there's only positive effects to revenue. When it comes to being a foundry for ARM devices... well, I think they're still very hesitant to do that.  ARM cores do show up in some FPGAs but generally, I think they are soft cores (ie. the get programmed into the FPGA fabric by the user, not at the fab, but I could be wrong - actually, I think Xilinx's Zync does have a hard ARM core, but so far Intel isn't a foundry partner for Xilinx).

Phil

[Patrick Logan]

At least the new CEO is a manufacturing person. I don't think it
helped that Otellini was a business person and not an engineer. (Also
I just read the president is a business person who's worked in
software and services... for Intel... oh, dear... I do have some Intel
stock.)

Yeah, it looks like there will be FPGAs with real ARM cores.

Bringing this back around to programming (kinda)... Bluespec
SystemVerilog is an interesting HDL that uses term rewriting plus
partial evaluation of Haskell. They synthesize to FPGAs throughout the
design process.

There were some interesting articles in CACM and ACM Queue, e.g.
http://queue.acm.org/detail.cfm?id=2020861

The neatest thing is this site where you can configure your own
network-on-a-chip...

http://users.ece.cmu.edu/~mpapamic/connect/

[Phil Tomson]

Bluespec's language is kind of a hard sell to hardware engineers who tend to be very conservative and don't like to learn new things, so not sure how they're doing.  Just took a quick look at their website which I hadn't checked in a year or two and now they seem to be moving into the emulation space as well.

Phil

[Richard Fobes]

On Sunday, May 26, 2013 11:50:22 AM UTC-7, M Edward Borasky wrote:

> As for languages not having evolved much, I agree.  Text processing is still
> primitive (in the sense of awkwardness, not processing power), which is why
> I created the Dashrep language.  (BTW, I use the Dashrep language in a way
> that gets around some of the limitations of CSS.)

Well, between regular expressions and statistical techniques, I'd say
text processing is in pretty good shape.

Access to text processing (as opposed to low-level text processing) is not as easy as it should be.  Most languages require using quotation marks, concatenation symbols, and print commands to handle text.  In the Dashrep language those aren't used (or needed).

I have a pretty good book about SVG - it's
http://www.amazon.com/Building-Web-Applications-SVG-ebook/dp/B008MQH2HS

This book looked promising until I saw it was from Microsoft.  Yet this link led me to find a useful SVG page for graphics.  But the problem is using SVG with text.  When I've tried that, it seems to want (at least) two different versions of information and the two have to match -- in ways that aren't clear.  There are two applications I have in mind.  One is to generate graphics-and-text slides for a presentation using SVG.  The other is to fill the gap that makes it difficult to generate good-looking charts (which I sometimes do to assist my wife with her work) without resorting to writing macros in Microsoft Excel (or creating the charts semi-manually).

 
> As for quantum computing, transistor-based ICs still have lots and lots of
> room for improvement in both speed and size.  Too bad Intel doesn't know how
> to work with inventors to make that happen more quickly.

Intel's strategic problems aren't at the fab level but higher up. ...

I agree.  By size I meant the size of the IC, not the size of the transistors/features.  By speed I meant strategically not wasting time, rather than making switching happen faster.

I should have added that such strategic changes reduce power consumption (even without changing the fab technology).

The graphic at Phil's linked article reveals that Intel is working on not wasting processor time, but there is still room for improvement.  But as Phil also implies, Intel's desire to focus on high-margin products and not license architectures limits where they can go.

Another concept is that Intel wants software and hardware engineers to believe that a floating-point processor is important.  Yet I can't think of any numeric domain where the numbers cannot be scaled and offset to allow all the calculated values to be integers.  And before someone criticizes this claim, I should point out that I have a degree in Physics so I'm familiar with particle-physics and astronomical calculations, and I spent a summer on a fellowship program at the National Center for Atmospheric Science where I wrote an enhancement for a climate model (and found a serious bug in the code).  The broader point here is that Intel wants buyers to pay for lots of processing power, yet increasingly efficient software is reducing the need for "heavy-duty" processing power.

Richard Fobes

[M. Edward (Ed) Borasky]

On Sun, May 26, 2013 at 11:00 PM, Richard Fobes
<pr...@solutionscreative.com> wrote:


> This book looked promising until I saw it was from Microsoft. Yet this link
> led me to find a useful SVG page for graphics. But the problem is using SVG
> with text. When I've tried that, it seems to want (at least) two different
> versions of information and the two have to match -- in ways that aren't
> clear. There are two applications I have in mind. One is to generate
> graphics-and-text slides for a presentation using SVG. The other is to fill
> the gap that makes it difficult to generate good-looking charts (which I
> sometimes do to assist my wife with her work) without resorting to writing
> macros in Microsoft Excel (or creating the charts semi-manually).

If you know R, Markdown and JavaScript, there are some amazing things
being done these days. http://slidify.org/

> Another concept is that Intel wants software and hardware engineers to
> believe that a floating-point processor is important. Yet I can't think of
> any numeric domain where the numbers cannot be scaled and offset to allow
> all the calculated values to be integers. And before someone criticizes
> this claim, I should point out that I have a degree in Physics so I'm
> familiar with particle-physics and astronomical calculations, and I spent a
> summer on a fellowship program at the National Center for Atmospheric
> Science where I wrote an enhancement for a climate model (and found a
> serious bug in the code). The broader point here is that Intel wants buyers
> to pay for lots of processing power, yet increasingly efficient software is
> reducing the need for "heavy-duty" processing power.

I went down that path in my days at FPS ;-). Yes, you can do
miraculous things with scaled fixed-point or block-floating-point
arithmetic. You can also write a JavaScript engine in Brainfuck. ;-)
IEEE floating point arithmetic is here to stay, or at worst some GPU
hacks to get rid of the *really* slow parts of the standard.
Programmer time is expensive.

[Richard Fobes]

On Sunday, May 26, 2013 11:23:53 PM UTC-7, M Edward Borasky wrote:

If you know R, Markdown and JavaScript, there are some amazing things
being done these days. http://slidify.org/

Thanks for the link.  Very nice possibilities.

Yet my desires do not involve interactivity (JavaScript, which I do know), and do not involve calculations (R, which I do not know, but which I know how to do in Excel, Perl, etc.), and do not involve writing the slides/graphs manually (Markdown, because instead I do that in Dashrep).

I found a text-based SVG example and I plan to try that when I have time.  I think SVG is the right language, so I guess I'm just ranting that it has some unnecessary complications.

Richard

[Patrick Logan]

OK,  just glanced at the dashrep learn page ... that just blew my mind...

--