Re: [beagleboard] Programming without programming discussion

2016-05-07 Thread evilwulfie 
we know your Too old so don't deny it. :P

On 5/7/2016 10:00 PM, William Hermans wrote:
> toold == tools
>
> On Sat, May 7, 2016 at 9:59 PM, William Hermans  > wrote:
>
> /Someday, someone will probably come up with visual system
> that's general, open source and amenable to maintaining in
> git---but that day hasn't arrived yet./
>
>
> I think that right now, probably the toold that are closest are
> the better UML apps out there. Rational Rose, and Microsoft Visio.
> Where you diagram your program flow, and the app builds your app
> skeleton for you. Functions, classes, and all it can based on the
> data you've given it. For me personally though, this is not my own
> style of coding. I prefer to write small bits at a time and test
> as I go. This way, I do not spend large amounts of time debugging
> code . . .
>
> On Sat, May 7, 2016 at 8:27 PM, Przemek Klosowski
> mailto:przemek.klosow...@gmail.com>>
> wrote:
>
> These graphical or visual programming languages
> you denigrate really do help scientists, engineers,
> and other "domain experts" who aren't, and don't want
> to become, "programmers" implement an idea for which
> there is not, and will never be until the idea is
> proven sound, a budget for "hiring real programmers".
>
>  
> In principle, yes, they are useful and enabling. In practice,
> however, they have been underwhelming, and I can think of
> several reasons:
>
>   * fragmentation: they usually are designed for some
> domain-specific programming (e.g. LabView for data
> acquisition, GNUradio for signal processing, Simulink for
> control systems, SGI AVS/Explorer for data
> flow/processing, etc). This, however, means that their
> audience is limited to that particular domain.
>   * closeness: most of graphical programming systems are
> commercial and closely held by their owners
>   * lack of scaling: easy tasks are very easy,  but as the
> program size grows, they become unmanageable. It's
> difficult to determine whether two visualized data flow
> graphs are equivalent: the program representation and
> semantics are mixed up. My favorite dis of graphical
> programming:
>
>   o Finally, we can have spaghetti code that looks like
> spaghetti!
>
> Someday, someone will probably come up with visual system
> that's general, open source and amenable to maintaining in
> git---but that day hasn't arrived yet.
>
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to beagleboard+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> 
> https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGyRF185jpBpgf%2BugqTRsfd5S6QdV9oHXc_W55%2Bs%3D5Ygw%40mail.gmail.com
> 
> .
>
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CALHSORomM3Ry9T6SVEYo-7NcXt25isSsMEYoD0ZwK7_Ej69-4w%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c92f2cf7-6fd2-f8ce-4f23-99be759b44e4%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Programming without programming discussion

2016-05-07 Thread William Hermans 
toold == tools

On Sat, May 7, 2016 at 9:59 PM, William Hermans  wrote:

> *Someday, someone will probably come up with visual system that's general,
>> open source and amenable to maintaining in git---but that day hasn't
>> arrived yet.*
>>
>
> I think that right now, probably the toold that are closest are the better
> UML apps out there. Rational Rose, and Microsoft Visio. Where you diagram
> your program flow, and the app builds your app skeleton for you. Functions,
> classes, and all it can based on the data you've given it. For me
> personally though, this is not my own style of coding. I prefer to write
> small bits at a time and test as I go. This way, I do not spend large
> amounts of time debugging code . . .
>
> On Sat, May 7, 2016 at 8:27 PM, Przemek Klosowski <
> przemek.klosow...@gmail.com> wrote:
>
>> These graphical or visual programming languages you denigrate really do
 help scientists, engineers, and other "domain experts" who aren't, and
 don't want to become, "programmers" implement an idea for which there is
 not, and will never be until the idea is proven sound, a budget for "hiring
 real programmers".

>>>
>> In principle, yes, they are useful and enabling. In practice, however,
>> they have been underwhelming, and I can think of several reasons:
>>
>>- fragmentation: they usually are designed for some domain-specific
>>programming (e.g. LabView for data acquisition, GNUradio for signal
>>processing, Simulink for control systems, SGI AVS/Explorer for data
>>flow/processing, etc). This, however, means that their audience is limited
>>to that particular domain.
>>- closeness: most of graphical programming systems are commercial and
>>closely held by their owners
>>- lack of scaling: easy tasks are very easy,  but as the program size
>>grows, they become unmanageable. It's difficult to determine whether two
>>visualized data flow graphs are equivalent: the program representation and
>>semantics are mixed up. My favorite dis of graphical programming:
>>
>>
>>- Finally, we can have spaghetti code that looks like spaghetti!
>>
>> Someday, someone will probably come up with visual system that's general,
>> open source and amenable to maintaining in git---but that day hasn't
>> arrived yet.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGyRF185jpBpgf%2BugqTRsfd5S6QdV9oHXc_W55%2Bs%3D5Ygw%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORomM3Ry9T6SVEYo-7NcXt25isSsMEYoD0ZwK7_Ej69-4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Programming without programming discussion

2016-05-07 Thread William Hermans 
>
> *Someday, someone will probably come up with visual system that's general,
> open source and amenable to maintaining in git---but that day hasn't
> arrived yet.*
>

I think that right now, probably the toold that are closest are the better
UML apps out there. Rational Rose, and Microsoft Visio. Where you diagram
your program flow, and the app builds your app skeleton for you. Functions,
classes, and all it can based on the data you've given it. For me
personally though, this is not my own style of coding. I prefer to write
small bits at a time and test as I go. This way, I do not spend large
amounts of time debugging code . . .

On Sat, May 7, 2016 at 8:27 PM, Przemek Klosowski <
przemek.klosow...@gmail.com> wrote:

> These graphical or visual programming languages you denigrate really do
>>> help scientists, engineers, and other "domain experts" who aren't, and
>>> don't want to become, "programmers" implement an idea for which there is
>>> not, and will never be until the idea is proven sound, a budget for "hiring
>>> real programmers".
>>>
>>
> In principle, yes, they are useful and enabling. In practice, however,
> they have been underwhelming, and I can think of several reasons:
>
>- fragmentation: they usually are designed for some domain-specific
>programming (e.g. LabView for data acquisition, GNUradio for signal
>processing, Simulink for control systems, SGI AVS/Explorer for data
>flow/processing, etc). This, however, means that their audience is limited
>to that particular domain.
>- closeness: most of graphical programming systems are commercial and
>closely held by their owners
>- lack of scaling: easy tasks are very easy,  but as the program size
>grows, they become unmanageable. It's difficult to determine whether two
>visualized data flow graphs are equivalent: the program representation and
>semantics are mixed up. My favorite dis of graphical programming:
>
>
>- Finally, we can have spaghetti code that looks like spaghetti!
>
> Someday, someone will probably come up with visual system that's general,
> open source and amenable to maintaining in git---but that day hasn't
> arrived yet.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGyRF185jpBpgf%2BugqTRsfd5S6QdV9oHXc_W55%2Bs%3D5Ygw%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqrWOyYPP6k0rAJ_NCTokPGwA4toLbwn1ouFfBVYneDBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Programming without programming discussion

2016-05-07 Thread Przemek Klosowski 
>
> These graphical or visual programming languages you denigrate really do
>> help scientists, engineers, and other "domain experts" who aren't, and
>> don't want to become, "programmers" implement an idea for which there is
>> not, and will never be until the idea is proven sound, a budget for "hiring
>> real programmers".
>>
>
In principle, yes, they are useful and enabling. In practice, however, they
have been underwhelming, and I can think of several reasons:

   - fragmentation: they usually are designed for some domain-specific
   programming (e.g. LabView for data acquisition, GNUradio for signal
   processing, Simulink for control systems, SGI AVS/Explorer for data
   flow/processing, etc). This, however, means that their audience is limited
   to that particular domain.
   - closeness: most of graphical programming systems are commercial and
   closely held by their owners
   - lack of scaling: easy tasks are very easy,  but as the program size
   grows, they become unmanageable. It's difficult to determine whether two
   visualized data flow graphs are equivalent: the program representation and
   semantics are mixed up. My favorite dis of graphical programming:


   - Finally, we can have spaghetti code that looks like spaghetti!

Someday, someone will probably come up with visual system that's general,
open source and amenable to maintaining in git---but that day hasn't
arrived yet.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGyRF185jpBpgf%2BugqTRsfd5S6QdV9oHXc_W55%2Bs%3D5Ygw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Programming without programming discussion

2016-05-06 Thread William Hermans 
Wally,

Also, in addition to the above. Your friend for example, and the Nodejs /
node red discussion you've been having lately. If you friend is an
Engineer, then learning the quick basic of javascript would take far less
time than you've been discussing the problems you've been having on this
google group.

So as an example of what I mean. A couple weeks ago someone asked on this
group what to use with Java to twiddle a GPIO or two. I told him he needed
to learn how the GPIO is presented to user space through sysfs, and then
just use a good file system object for Java. To illustrate my point on that
post, someone came back a few minute later with exact code needed to
twiddle a single GPIO . . .

Anyway, yes, it's not *very* easy when you're new, but it's pretty simple
and a concept everyone needs to understand if they want to learn how to use
the hardware properly. Plus once you learn how to do various things in
Javascript through Nodejs, you do not forget that usually. So that
information can be applied to other similar, or perhaps not quite to
similar situations.

On Fri, May 6, 2016 at 11:24 AM, William Hermans  wrote:

> So wally I didn't want to step all over Jason's post by discussing this
> further, there. Also keep in mind that this is just a discussion. There is
> not right or wrong, only right or wrong for individuals. Or personal
> beliefs if you will.
>
> I won't disagree with what you say, but it ignores a few simple truths.
>
> Programming is hard work and requires absurd amounts of arcane knowledge
> that can quickly become obsolete.
>
> This is somewhat right in concept, but mostly wrong in practical
> application. Let me pick a single language to help illustrate. C for
> instance, the language specification changes only once every so many years.
> But even then the past concepts mostly stay in place. So you only *need* to
> learn a little at a time which can take place as a given programmer "needs
> to know". This is easier for experienced programmers. Passed that, all the
> libraries out there, one does not need to retain that information, as it is
> really easy to freshen up on most Linux API calls in real time once you're
> working on code. Again, this is much easier for experienced programmers,
> and this technique makes it much easier to use new( to the programmer )
> libraries as well.
>
> So this "arcane knowledge" is only really arcane to those who are really
> not programmers. Truism ?
>
> These graphical or visual programming languages you denigrate really do
>> help scientists, engineers, and other "domain experts" who aren't, and
>> don't want to become, "programmers" implement an idea for which there is
>> not, and will never be until the idea is proven sound, a budget for "hiring
>> real programmers".
>>
>
>
> I have a friend who is a scientist, who has picked up programming pretty
> easily. He might use Python, which I particularly do not care for, but he
> is able to write code that is mostly competent. Just not as easily or
> quickly as someone who is more experienced. Passed that, I've read many
> white papers written by scientist's and if they're serious, they will learn
> how to program, and indeed many have. One white paper particular where a
> scientist blew my mind discussing the use of abstract generic templates in
> C++ . . . a very complex concept.
>
> I wont deny that these types of programs are good for prototyping concepts
> for a proof of concept. The problem is, passed that you have many who want
> to use these applications to write production code, and I honestly do not
> think the technology is there yet. And won't be there for a long time.
>
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/be9da685-5dbc-4519-bb48-3aa461f9c31d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqfYVPs2g-sT4kPgfUT%3D-NhU%2Brxj1zS3m6K7TV7qHfCfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Programming without programming discussion

2016-05-06 Thread William Hermans 
So wally I didn't want to step all over Jason's post by discussing this 
further, there. Also keep in mind that this is just a discussion. There is 
not right or wrong, only right or wrong for individuals. Or personal 
beliefs if you will.

I won't disagree with what you say, but it ignores a few simple truths.

Programming is hard work and requires absurd amounts of arcane knowledge 
that can quickly become obsolete.

This is somewhat right in concept, but mostly wrong in practical 
application. Let me pick a single language to help illustrate. C for 
instance, the language specification changes only once every so many years. 
But even then the past concepts mostly stay in place. So you only *need* to 
learn a little at a time which can take place as a given programmer "needs 
to know". This is easier for experienced programmers. Passed that, all the 
libraries out there, one does not need to retain that information, as it is 
really easy to freshen up on most Linux API calls in real time once you're 
working on code. Again, this is much easier for experienced programmers, 
and this technique makes it much easier to use new( to the programmer ) 
libraries as well.

So this "arcane knowledge" is only really arcane to those who are really 
not programmers. Truism ?

These graphical or visual programming languages you denigrate really do 
> help scientists, engineers, and other "domain experts" who aren't, and 
> don't want to become, "programmers" implement an idea for which there is 
> not, and will never be until the idea is proven sound, a budget for "hiring 
> real programmers".
>


I have a friend who is a scientist, who has picked up programming pretty 
easily. He might use Python, which I particularly do not care for, but he 
is able to write code that is mostly competent. Just not as easily or 
quickly as someone who is more experienced. Passed that, I've read many 
white papers written by scientist's and if they're serious, they will learn 
how to program, and indeed many have. One white paper particular where a 
scientist blew my mind discussing the use of abstract generic templates in 
C++ . . . a very complex concept.

I wont deny that these types of programs are good for prototyping concepts 
for a proof of concept. The problem is, passed that you have many who want 
to use these applications to write production code, and I honestly do not 
think the technology is there yet. And won't be there for a long time.



-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/be9da685-5dbc-4519-bb48-3aa461f9c31d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.