As usual it all boils down to confusion about definitions of terms. Terms
like dynamisms leave the mouth (or keyboard) with one meaning and arrive
with another. Here's a pretty good definition from Wikipedia:
*Dynamic programming language* is a term used broadly in computer
science<http://en.wikipedia.org/wiki/Computer_science> to
> describe a class of high-level programming
> languages<http://en.wikipedia.org/wiki/High-level_programming_language> that
> execute at
> runtime<http://en.wikipedia.org/wiki/Run_time_(program_lifecycle_phase)> many
> common behaviors that other languages might perform during
> compilation<http://en.wikipedia.org/wiki/Compiler>,
> if at all. These behaviors could include extension of the program, by
> adding new code <http://en.wikipedia.org/wiki/Source_code>, by extending
> objects <http://en.wikipedia.org/wiki/Object_(computer_science)> and
> definitions, or by modifying the type
> system<http://en.wikipedia.org/wiki/Type_system>,
> all during program execution.
Take note that "static" languages like Felix, C++, OCaml, and Haskell do
not readily facilitate runtime modification of the program itself, whereas
"dynamic" languages like LISP, Smalltalk, Javascript, Groovy, Lua and so on
can dynamically load new modules, classes, functions, and data structures.
In dynamic languages the user of a program could enter some code of their
own and have it executed at the appropriate. You can have an application
where pieces of code are embedded in the data being manipulated, and that
code can be loaded and saved to a file or database for use at the
appropriate time. This requires having the parser and an interpreter/JIT
available in the library (aka eval()) so that you can load code at runtime.
On Thu, Jan 10, 2013 at 5:54 AM, john skaller <skal...@users.sourceforge.net
> wrote:
> I content that only a strongly typed language can be highly dynamic.
>
There are strongly-typed dynamic languages - typed scheme (or typed racket)
are good examples.
There are even dynamic environments for C and C++ code where you have an
interpreted environment and you can add definitions on the fly in a REPL or
load additional source files as part of the program.
The usual definition of "dynamic" doesn't favor any particular type system.
An interesting point was made by someone on Y-combinator that
> a scripting language should be defined by possession of an eval() function.
>
But "eval" is not any old evaluator. It isn't just en evaluator for the
> source language either -- Felix could do that easily by just calling
> "flx" using the system() or popen() commands. What makes eval()
> special is that the evaluated code is evaluated in the "current context"
> which means it binds to symbols in that context.
>
Of course this causes all hell to break lose, and the features is frowned
> on in most languages, and also very rarely used.
>
Although there may be relatively few lines of code that use eval(), there's
a lot of code that relies on it.
Consider that the whole module system in Javascript (node.js / CommonJS) is
based on the ability to load a script dynamically, possibly conditionally.
You might say if(internetExplorer) require('stuff.ie') else
require('stuff-normal.js').
Python's module system also loads on demand, and so you can devise an
application where the module to load comes from a configuration file or a
command-line parameter. You can use try: catch: to check for the presence
or absence of modules/functions/features on the target machine.
Consider emacs, which uses LISP as a scripting language. It allows you to
enter LISP expressions directly to run on the source file, or dynamically
load plugins and scripts even after emacs has already been loaded.
In a video game I worked on I added the ability for testers / designers to
fire off a line of code into the running game to poke and prod at things
for debugging or just to skip to the right part of a game.
This is the kind of thing people are looking for in dynamic languages.
In this sense, Felix isn't a scripting language: there's no eval(),
>
I think the only sense in which Felix is a scripting language is that when
you run "flx foo" it yields the output of running foo.flx rather than an
executable or bytecode file.
Mind you, that's enough for me, I don't begrudge Felix it's status as a
"scripting language".
Interestingly, I might consider Felix a "scripting language" but not a
"dynamic language". So, perhaps there's a distinction there in my mind,
but these terms have become so muddied out there I doubt everyone would
agree with me.
> Still, Felix is capable of a high level of dynamism. As is Ocaml
> and C++. More than Python or Perl or Lua!
>
> Dynamism doesn't mean dynamic typing. In fact most "dynamically
> typed" language severely LACK dynamism.
I have no idea what definition of dynamism you are using here.
dy·na·mism (dn-mzm)
*n.*
*1. *Any of various theories or philosophical systems that explain the
universe in terms of force or energy.
*2. *A process or mechanism responsible for the development or motion of a
system.
*3. *Continuous change, activity, or progress; vigor.
> Statically typed languages also typically provide powerful
> features that are sometimes lacking in dynamic languages.
> Such as closures. Iterators. Cooperative multi-tasking
> with channels.
>
Sure, but that's got nothing to do with the type system, LISP and Scheme
have pretty much every language feature you can imagine without static
typing.
> It is in fact the static typing which *enables* these dynamics,
> and the enablement comes as usual by imposing constraints.
>
I can't think of a single thing you can do in a statically typed language
that you cannot do in a dynamically typed language. At least in theory -
the existing languages have their own features sets and limits, but those
limits are not imposed by their dynamic type system.
> There's a convincing example in Felix: the Java like Object system.
>
Sigh, you really shouldn't call those "Java-like objects", they aren't
Java-like at all because they aren't dynamically typed, they aren't
nominally typed, they don't have a relationship with a static class, they
have no metadata, they don't allow virtual dispatch via "this" ... and the
list goes on.
This is syntactic sugar. An object is just a record of functions closed
> over the environment of the constructor function. Entirely statically
> typed.
>
Yet, you can swap a method f from "object A" to "object B"
> so when you call f on A it modifies the state of B -- that's pretty
> dynamic! In fact you can replace any of these closures with any
> closure at all, provided it has the right type.
>
Er ... are you saying you can't do that in LISP, Python, or Javascript?
Because ... you can. They all support closures and records, just like
Felix does.
> In balance then, dynamic typing actually *destroys* dynamism
>
rather than enabling it. High power static typing is what allows
> you to write dynamic programs.
>
I could see how some of the comments on Facebook or HackerNews about
whether Felix was really a scripting language or not might have put you off
a bit, but you're not making a lot of sense here.
Perhaps you should bow to the masses and remove the "Scripting language"
moniker from Felix. It probably is doing more harm than good at this point.
Cheers,
Dobes
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
