Programming Languages
Locked
 
|
I figured it was time again to start an opinions on programming languages
free for all. Functional rules while imperative drools. Objects are fine, but it's better to know what you are doing! -- Sent from: http://friam.471366.n2.nabble.com/ - .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . FRIAM Applied Complexity Group listserv Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com archives: http://friam.471366.n2.nabble.com/ FRIAM-COMIC http://friam-comic.blogspot.com/ |
|
If your goal is to provide the machine with the most accurate and precise instructions possible then Assembler, followed relatively closely by C, cannot be beat. For specific domains, a language that allows easy, straightforward expression of domain concepts is superior. COBOL for business applications, FORTRAN (FORTRESS, Guy Steele's parallel FORTRAN) for physics, and some intentional DSL's. Now it gets tricky, because it depends on exactly what kind of virtual machine you want to impose on the hardware. A computer — a Turing Machine — can be any kind of virtual machine you want, each of which can be Turing Complete and therefore exact equivalents of each other. If I want to define my virtual machine as a logical implementation of an abstraction, Lambda Calculus perhaps, then the programming language that most closely expresses that abstraction, LISP for example, is the best. If your abstract virtual machine implements some kind of functional paradigm, the the functional language that directly and simply expresses ideas in that paradigm is best. If your abstraction is classical logic, the PROLOG; etc/, etc.. The reason this is tricky is that all of these abstract virtual machines and the languages that express associated abstract concepts are little more than interesting toys. All are equal, all are equally irrelevant. Now, as to objects: There are no object languages, the closest approximation would be Self. The next closest would be Simula - but NOT Simula I, the first incarnation of the language that was a "programming language." The greatest tragedy to befall objects was the idea of OO Programming because the object concept has little or nothing to do with programming — the concept provides an elegant way of thinking about, modeling, modularizing, and designing systems; especially the large scale complex (not just complicated) systems that comprise the world around us. Given people that can think in objects and design with, for, and in objects; then it is possible to train them in the proper use of Smalltalk for effective implementation of those designs. davew On Fri, Aug 7, 2020, at 6:45 PM, jon zingale wrote: > I figured it was time again to start an opinions on programming languages > free for all. Functional rules while imperative drools. Objects are fine, > but it's better to know what you are doing! > > > > -- > Sent from: http://friam.471366.n2.nabble.com/ > > - .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . > FRIAM Applied Complexity Group listserv > Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam > un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com > archives: http://friam.471366.n2.nabble.com/ > FRIAM-COMIC http://friam-comic.blogspot.com/ > - .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . FRIAM Applied Complexity Group listserv Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com archives: http://friam.471366.n2.nabble.com/ FRIAM-COMIC http://friam-comic.blogspot.com/ |
|
|
And given Alan Kay's statements about Actors being closer to his original conception of Objects, and that the key idea is the Message (async one-way in the Actor case), a strong composable option would be something like Humus. Since all Actor state is private, it can only be manipulated by the actor's behavior (a message-handler for async events). Each event is handled atomically, so there is no rentrancy issue. Humus provides a minimal (but not "toy") implementation of Actor primitives for causing effects, and a pure-functional (lambda calculus) core for expressing values. Lately I've been gaining some traction is the use of Humus for defining the behavior of fine-grained concurrent systems. On Sat, Aug 8, 2020 at 11:15 AM Prof David West <[hidden email]> wrote:
- .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . FRIAM Applied Complexity Group listserv Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com archives: http://friam.471366.n2.nabble.com/ FRIAM-COMIC http://friam-comic.blogspot.com/ |
|
|
In reply to this post by Prof David West
On Sat, Aug 08, 2020 at 11:13:36AM -0600, Prof David West wrote:
> > For specific domains, a language that allows easy, straightforward expression > of domain concepts is superior. COBOL for business applications, FORTRAN > (FORTRESS, Guy Steele's parallel FORTRAN) for physics, and some intentional > DSL's. I disagree with Fortran being ideal for Physics - probably some combination of Python or Julia would be. Actually, I'm hard pressed to find an obvious niche for Fortran these days - C++ is now a better language for High Performance Computing applications, for instance. Fortran has hung around in certain areas for cultural reasons. Can't comment too much about Cobol for business applications, but I would have thought Java or C# might be more suited. -- ---------------------------------------------------------------------------- Dr Russell Standish Phone 0425 253119 (mobile) Principal, High Performance Coders [hidden email] http://www.hpcoders.com.au ---------------------------------------------------------------------------- - .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . FRIAM Applied Complexity Group listserv Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com archives: http://friam.471366.n2.nabble.com/ FRIAM-COMIC http://friam-comic.blogspot.com/ |
|
|
Galileo wrote in Italian in Opera Il Saggiatore
On Sat, Aug 8, 2020 at 10:55 PM Russell Standish <[hidden email]> wrote: On Sat, Aug 08, 2020 at 11:13:36AM -0600, Prof David West wrote: - .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . FRIAM Applied Complexity Group listserv Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com archives: http://friam.471366.n2.nabble.com/ FRIAM-COMIC http://friam-comic.blogspot.com/ |
|
|
At the first conference on Object-oriented Frameworks for Scientific Programming, the room divided more or less down the center. On one side, attendees said “I love overloaded operators in C++ because I can make my code look just like the physics equations.” On the other side, attendees said “I love overloaded operators in C++ because I can make my code look just like FORTRAN.”
These days, I focus on Elixir and Erlang, both functional languages that share the same virtual machine so they are interoperable. Elixir has a gentler syntax, but Erlang has the more powerful libraries. Erlang also has a pretty well-developed interface into C, since they originally used it to control telephone switches. … bob
- .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . FRIAM Applied Complexity Group listserv Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com archives: http://friam.471366.n2.nabble.com/ FRIAM-COMIC http://friam-comic.blogspot.com/ |
|
|
In reply to this post by Dale Schumacher
This looks pretty interesting. Recently, Marcus posted on FRP models which
seem to be an alternative (to actor models) route to solving similar problems. Do you have any insight as to their comparative qualities? -- Sent from: http://friam.471366.n2.nabble.com/ - .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . FRIAM Applied Complexity Group listserv Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com archives: http://friam.471366.n2.nabble.com/ FRIAM-COMIC http://friam-comic.blogspot.com/ |
|
|
In reply to this post by Bob Ballance
If I had stayed at Bell Labs I might have learned Erlang. On Sun, Aug 9, 2020 at 9:28 AM Bob Ballance <[hidden email]> wrote:
Frank Wimberly
140 Calle Ojo Feliz Santa Fe, NM 87505 505 670-9918 - .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . FRIAM Applied Complexity Group listserv Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com archives: http://friam.471366.n2.nabble.com/ FRIAM-COMIC http://friam-comic.blogspot.com/ |
|
In reply to this post by jon zingale
Dale? Dale! Wherefore art thou?
http://www.dalnefre.com/wp/2020/01/requirements-for-an-actor-programming-language/ On 8/10/20 8:56 AM, jon zingale wrote: > This looks pretty interesting. Recently, Marcus posted on FRP models which > seem to be an alternative (to actor models) route to solving similar > problems. Do you have any insight as to their comparative qualities? -- ↙↙↙ uǝlƃ - .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . FRIAM Applied Complexity Group listserv Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com archives: http://friam.471366.n2.nabble.com/ FRIAM-COMIC http://friam-comic.blogspot.com/
uǝʃƃ ⊥ glen
|
|
|
On Mon, Aug 10, 2020 at 10:39 AM uǝlƃ ↙↙↙ <[hidden email]> wrote: Dale? Dale! Wherefore art thou? - .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . FRIAM Applied Complexity Group listserv Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com archives: http://friam.471366.n2.nabble.com/ FRIAM-COMIC http://friam-comic.blogspot.com/ |
|
|
Ha! Yeah. Sorry. I was just trying to promote your work. It won't happen again.
On 8/10/20 12:21 PM, Dale Schumacher wrote: > 1. "wherefore" means "why", not "where". > 2. I'm working, not monitoring the lists all day. > 3. The simplest comparison I can come up with is that FRP is more of a continuous-signal model and Actors are a discrete-event model. Otherwise there are lots of similarities. Actors are reactive program entities with private storage, computation resources, and communication facilities for sending asynchronous messages to other actors. -- ↙↙↙ uǝlƃ - .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . FRIAM Applied Complexity Group listserv Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com archives: http://friam.471366.n2.nabble.com/ FRIAM-COMIC http://friam-comic.blogspot.com/
uǝʃƃ ⊥ glen
|
|
|
My apologies, if I have offended. I thought picking language nits was the way we poked fun at each other here. Some on this list may remember, about a dozen years back, an in-person presentation I gave to friam on Actors. The feedback from that session was one of the inspirations for my blog, so thank you! On Mon, Aug 10, 2020 at 1:48 PM uǝlƃ ↙↙↙ <[hidden email]> wrote: Ha! Yeah. Sorry. I was just trying to promote your work. It won't happen again. - .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . FRIAM Applied Complexity Group listserv Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com archives: http://friam.471366.n2.nabble.com/ FRIAM-COMIC http://friam-comic.blogspot.com/ |
«
Return to Friam
|
1 view|%1 views
| Free forum by Nabble | Edit this page |