Dedasys Journal

A couple of points:

1) Immigrants pay taxes just like everyone else.

2) With "government who willingly allows companies to outsource or externally hire our jobs" -- it sounds like you believe in the lump-of-labor fallacy. The idea that skilled immigrants take away jobs from natives is widespread, but generally false. See: http://journal.dedasys.com/2014/12/29/people-places-and-jobs/

In addition, "government who willingly allows" implies that the U.S. is very immigration-friendly. Nothing could be further from the truth. Countries like Canada, Australia, the UAE, certain EU countries, etc. all have far, far more welcoming immigration rules. As a personal anecdote: before I got my current job, I had interviewed with Facebook, and they said that if I didn't make it through the H1B lottery, I could work at their office in Canada.

The fact is, the U.S. is one of the hardest countries in the world to immigrate to; and from an employer's perspective, one of the countries that makes it hardest to hire someone from outside.

3) The idea that there is no shortage of skilled developers in the US is not corroborated either by fact, or my personal experience. My company has had a really hard time finding skilled developers. We've been hiring smart people who have had limited exposure to programming (12 weeks of bootcamp) and who come from non-CS/non-STEM backgrounds, and basically training them to become developers.

I know several people in the industry who all say that they've had…

For reference:

Jeff - Jeff Hobbs, aka Tcl Guy, currently CTO and VP, Engineering at ActiveState (http://www.activestate.com/company/management)

Larry Virden - a well-respected Tcl community member (http://wiki.tcl.tk/16)

Richard Suchenwirth - Dev Engineer at Siemens Postal Automation -- famous in Tcl community for coming up w/ seemingly infinate brilliant small solutions and demos (http://wiki.tcl.tk/496) and happens to be a voracious consumer of cinema

Dave Welton - our own @davidw, a recovering Tcl'er (http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong/)

Jean-Claude Wippler - prodigious developer, respected community member (http://wiki.tcl.tk/10)

Richard Hipp - Tcl Core Team emeratus, SQLite (http://www.sqlite.org), fossil (http://www.fossil-scm.org), among other things

Larry McVoy - ex Sun, Google (http://en.wikipedia.org/wiki/Larry_McVoy), of lmbench (http://www.bitmover.com/lmbench/) and bitkeeper (http://en.wikipedia.org/wiki/BitKeeper) fame, among other things...

Gerald Lester - respected developer/community member, Tcl Board of Directors.

John - John Ousterhout: Brilliant thinker/developer (http://www.highlyscalablesystems.com/3525/favorite-sayings-by-john-ousterhout-precious-experience-and-advice-for-building-systems/) who brought us Tcl, log structured filesystems (http://en.wikipedia.org/wiki/Log-structured_file_system), great articles on event-oriented programming ([pdf] http://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf) and…

Here's another good TCL War discussion from July 3 2016:

https://news.ycombinator.com/item?id=12025218

https://vanderburg.org/old_pages/Tcl/war/

Also part 2:

https://vanderburg.org/old_pages/Tcl/war2/index.html

https://news.ycombinator.com/item?id=12027092

DonHopkins on July 3, 2016 | parent | context | favorite | on: The Tcl War (1994)

>Around the time leading up to the TCL war, Lua was peacefully and quietly born in a manger at the Pontifical Catholic University of Rio de Janeiro, Brazil:

>"In 1993, the only real contender was Tcl, which had been explicitly designed to be embedded into applications. However, Tcl had unfamiliar syntax, did not offer good support for data description, and ran only on Unix platforms. We did not consider LISP or Scheme because of their unfriendly syntax. Python was still in its infancy. In the free, do-it-yourself atmosphere that then reigned in Tecgraf, it was quite natural that we should try to develop our own scripting language ... Because many potential users of the language were not professional programmers, the language should avoid cryptic syntax and semantics. The implementation of the new language should be highly portable, because Tecgraf's clients had a very diverse collection of computer platforms. Finally, since we expected that other Tecgraf products would also need to embed a scripting language, the new language should follow the example of SOL and be provided as a library with a C…

> Erlang/Elixir certainly doesn't have the necessary breadth of libraries to support general-purpose tasks.

After doing quite a bit of work with Erlang lately, this sentence jumped out at me. Specifically, I think Erlang does have a breadth of libraries, but they're not easy to find. I've had to pluck lone source files out of larger projects, or depend on an obscure github fork since the original was unmaintained. epgsql was a great example of this, though no longer thanks to davidw's yeoman work [1]

Maybe not the right place to ask this, but would anyone be interested in something like the Clojure Toolbox [2] for Erlang? I've always found having that reference of libraries organized by task to be super handy when working with Clojure.

[1] http://journal.dedasys.com/2014/04/27/an-erlang-postgres-driver-refurbishing-open-source/

[2] http://www.clojure-toolbox.com/

I still don't understand Guile. It makes sense as a stand-alone language implementation, but not as an embeddable one. Why isn't it re-entrant? What about multiple interpreters? Why a C-level GC like Boehm, rather than just track your own garbage? Why scheme for an embeddable language, don't continuations make C interop hard?

Even back when they announced Guile, it seemed odd that they based it on SCM rather than on SIOD or TinyScheme.

Lua seems to be far superior for embedding. Guile seems big and invasive by comparison. It seems to be heading squarely for that awkward middle size between big/full-featured and small/light that hurt Tcl, as argued in http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong .

Does it really make sense for them to live in the heap rather than in the disk buffers?

I presume that you're not hitting a melt-down from CPU time, so I'd assume you'd get better performance by letting the system handle paging in data from the disk and figuring out which stuff needs to be in memory (buffers) and lives out on disk.

Also one thing to watch out for when you make the 64-bit jump is that (internally pointer-heavy) applications in dynamic languages tend to use significantly more memory on 64-bit platforms. davidw talked about this some here:

http://journal.dedasys.com/2008/11/24/slicehost-vs-linode