agentgt

Somewhat related but I believe there is some discussion that non observable parts of the universe (i.e. Really far away) may behave differently. Unfortunately these outer/early edges are going faster than the speed of light (I think) so we will probably never know.

What I do for these situations is do the reflection as a unit test to confirm that the hand written children() is correct.

When the unit test fails for a node type it prints what it should be and you just copy and paste that code for children() should be.

This is also nice for the case where nodes have some sort special children(). You can make the unit test ignore those.

I'll have to try Moom. Right now I use SizeUp which isn't really a tiling manager but does provide some similar features. I use the tmux iterm integration which I must say is pretty badass. The iterm folks did a good job on that.

One of the reasons I still use both Emacs and Vim (yes I strangely use both) is because I can go execute them on a terminal (terminal, tmux, screen, etc).

There are just so many times I need to SSH into a machine. I know Emacs has some remote file editing capabilities but for some reason I never liked it (I can't recall why now... I think it was the need to sudo).

So I'm wondering what sublime text fans do for remote editing?

Interstitial is a good word. I like learning new words.

It unclear if you are introducing a new variable to the scope or mutating an existing one.

    # Am I defining foo for the first time or am I mutating
    foo = "stuff"

Python if I recall in the OOP sense combats this with requiring self.foo but this is not the case with other forms of lexical scoping such as loops with in loops etc.

And of course you can't define constants.

IIRC for lambdas its that they can't span multiple lines and I believe they are getting removed (I'm not a python 3 expert)?

Yes but at least Python has very good native access to libraries.

For example I am sure Java is faster at numerical processing than pure Python at least with Python you have the option of writing in native. Python has really good C interop and it maybe considered by some not part of the language but I consider that it is.

Yeah you could write native code for Java via JNI but its not easy (granted its been a while) and for reasons I can't remember why but JNI is slow (probably moving stuff on and off the heap... I can't recall).

Yes of course and for my own personal projects I will take the time often to learn new languages (e.g. Rust).

However when dealing with a team often with an existing code base getting everyone on board with "X" while potentially porting to "X" is fairly expensive. Its generally only worthwhile because of actual technical limitations and not productivity. Even the promise of safety (ie prevention of bugs) I would probably consider higher than productivity (although I suppose that is in way productivity).

Regardless productivity is really hard to measure and especially predict unlike other technical things.

Its interesting you mention CSV as I had an issue with CSV with Java many years ago.

I was trying to cut a couple of columns out of a CSV and tried to write it in Java and for some reason either the CSV library was slow or maybe I didn't have the right buffered input but I ended up writing a python script that outperformed my Java code (which reminds me I meant to revisit that).

Anyway here is the python code (it might not be the exact code I used as I didn't update it but whatever):

https://gist.github.com/agentgt/1383185

I'm a Java dev (and the one you replied to) and in the past when I didn't work at my own company the real reason Python was often not picked was because it was considered "a toy language" or "scripting language" (ie hard to maintain) and also because it didn't have vendor support like Java did. Of course this was like 8-10 years ago.

I still program and sadly prefer writing code in Java over Python even though I have tons of Python scripts in my ~/bin that I have written over the years. Mainly because I just know the ecosphere better.

And thats what most people should just admit why they choose a particular programming language. As long as its good enough... better... is just what you know more of... the cost of learning something new just to replace something new for marginal speed increase isn't worth it.

So when people say Java is slow to learn, not cool or slow to develop in because the language is verbose... I say just like you: "I Dont' Care" because learning the whole ecosphere of another language is goddamn expensive (that is languages are relatively easy to learn but all the libraries, best practices and tools is another thing entirely).

> Oh, I've heard "Python is slow" from Node folks, Java folks, Scala folks (in terms of productivity)

I have hard time believing Java folks made an argument on productivity unless you meant for that parenthetical statement to be only applied to Scala. Regardless productivity is a far more complicated than raw speed (particularly if you get into maintenance as some languages are easy to pump out code but harder to maintain... oh perl.. the pain...).

And yeah I have seen the C++ folks complain about Python but this in my experience has been video game programming which is clearly not the domain the author is in or talking about (I think given the microservice discussions). Hence why I would like to know more about these folks complaining.

Unless we are talking like circa 1999 I don't think I have heard a complaint yet that Python is slow. I'm curious who or where the author heard that from (not specifically the people themselves but the domain they are in).

What I have heard complaints about Python are (and I don't agree with all these points):

* Its not statically typed

* The python 2/3 compatibility

* It has some design flaws: GIL, variable assigning, mutable variables, lambdas, indentation (I don't agree with all these but this is complaints I have heard).

* The plethora of packaging (ie its not unified)

I guess one could argue its slow because it can't do concurrency well but that really isn't raw speed.

Then the author started comparing string processing of programmer time from a study which... doesn't help the authors point at all.

* Python has and will always be fast at string processing and most people know this

* The people that complain about python speed are almost certainly not doing string processing

* I have serious questions about the study in general (many languages have changed quite a bit since then)

Oh the "service bus" <strike>xml</strike> json is coming back... its called lambda architecture.

And again nothing new except someone else takes care of some server software for you with the promise of reduced price and maintenance but the reality eventually becomes tight proprietary coupling and eventual price gauging.

I'm still not sure I understand "Unit".

I can't speak for the other languages (PHP, Go, Python) but I have some reservations about it helping Java (as well as Erlang and other (J)VM languages) as FastCGI like stuff has been attempted for Java in the past with not very good success with the exception of Resin.

I guess it would be interesting though if they did a native Servlet 3.0+ implementation like Resin but I doubt that is is what will happen. Regardless Netty, Undertow and even Jetty have caught up speed wise to Resin (well at least according to techempower).

> Are there any other options around? Are there any other outstanding issues in developing for for Lambda?

I'm not sure how AWS Lambda handles the charging of network latency (or failure) case of downstream external service dependencies but that is one of our biggest problems. ie pull/scrape architecture. The push portion (ie events) of our architecture is an obvious fit but that is already taken care of quite nicely.

We interact with hundreds of web services (REST APIS, SOAP, etc) that are actually external from us.

Its unclear if or how Amazon charges you for a slow external service (I would imagine its particularly bad if the code is blocking IO) or if that is even possible. I do know spawning a whole bunch of servers to connect to a single REST API endpoint is damn slow.

I have feeling Lambda for our case is probably not a good one? Obviously for data processing I can see it but that is not a challenge we have.

In an ideal world our downstream (or I guess it could be called upstream...) dependencies would contact us but... that sadly isn't the case particularly for adhoc stuff.

I'm fairly certain the lunar landing required perhaps not perfection but pretty damn close planning.

Modern heresy is applying anecdotal solutions to situations as learnings for all problems.

Really what has sort of stuck with me that is analogous is Alan Watts talks on living. Particularly about life being a dance.

http://www.befreetoday.com.au/alan-watts-life-not-journey/

Yeah it's a little pop culture but the way he talks about things is very accessible.

This sort of reminds of "voting theory" and if I recall it was proven by I think a nobel prize winner that there cannot be a fair winner.

Obviously it's not entirely analogous but I would not be surprised if it mapped over to this domain.

Edit: on mobile so late on the link to Kenneth Arrow https://en.m.wikipedia.org/wiki/Arrow%27s_impossibility_theo...

Yes CLOS is superior particularly multimethods.

As for the JVM: https://common-lisp.net/project/armedbear/

Sooo its not the JVM.

BTW AspectJ and JRebel will get you around methods and even inheritance changes but alas Java does not have multimethods or MOP. I mean CLOS is awesome but so is static analysis :)

I think I'm in agreement with you. What I meant by the IDE is that "ideally" it should have REPL like offerings if the language can support hot code swapping.

I still don't think its REPL that makes Lisp or clojure magic (when I say magic I mean awesome). Its all the other stuff like macros and homoiconicity (which I see your point plays some part in academic REPL).

> Even JRebel can not do to a running JVM application what some Lisp implementations can do. Not near of that.

Well thats because of the Java compiler and in some parts the language of Java. It has nothing to do with the JVM otherwise Clojure wouldn't work. But I agree JRebel is far cry from the full reloading capabilities of Lisp, Erlang and other dynamic languages.

> IDE with a powerful debugger will let you evaluate expressions based on a state that is stuck... ie setting breakpoint (as well of course as investigating current variables and such)

> This is pretty basic

I agree but its still surprising how many languages do not do this well and I didn't mention that you can execute simple expressions in that mode something other static languages like C will not allow.

Besides.... I can change a function name in Java or Scala and see immediately everywhere in my code base with (e.g. red squiggle lines) how that impacts other code... for static languages that is pretty basic :P

I'm totally envious of your lisp machine (EDIT: in all honesty...I realize that originally sounded sarcastic).

I have a feeling given your screen name I'm talking to some who is equally biased as I am to Java :)

> Using a REPL vs. an IDE like you describe is the difference between a conversation and sending somebody a letter with instructions.

Hmmm an IDE is supposed to be a REPL and more. I mean you can go look up the definition from wikipedia.

> This is more visible when we use more dynamic languages/runtimes than Java/JVM. Since the changes one can do and how they need to be done is not very advanced, the usefulness of a REPL is reduced.

Yes I completely agree as I mentioned dynamic languages are far easier to modify at runtime. However for the case with Java it can be done with JRebel and various other tools.

Furthermore going back to the whole conversation vs letter an IDE with a powerful debugger will let you evaluate expressions based on a state that is stuck... ie setting breakpoint (as well of course as investigating current variables and such). This is damn useful for dealing with a multithreaded environment.

By the way make no mistake... I do love Lisp... I just think there are better things than traditional REPLs considering to your other point in another thread this stuff has existed since the 70s.

> It's not that the environment is custom, is that it's real. Do you call your payment service or your mail sending service from your tests? This is exactly the kind of thing you want to experiment with in a supervised, non-repeatable way.

The irony you mentioning that is I have actually written "tests" that call braintree and stripe...

Just to clarify when I say "test" I don't mean some precise definition of "unit test" or "integration test". I mean in a runner that runs your code. Unit tests basically allow you to make a whole bunch of entry points (aka static main(args)).

I have many times setup a particularly environment and then repeatedly ran a unit test against that environment (I then commented or deleted that code later).

I think in large part of what your saying is good about REPLs is that they allow hot code swapping but that is only IMO really one part of the REPL. The key to really good REPL should be human input (think Excel) and human output (think images and graphs). There was a company recently shown on HN called Luna [1] and I think that is what a REPL should be.

And I particularly pick on this because you mention Bret Victor who is (err I guess was) actually working on environments like this.

Otherwise call it a unit test... call it a REPL... call it hot code swapping but in current JVM environments the difference can be pretty nebulous.

[1]: https://news.ycombinator.com/item?id=14612680

I probably did at one point know this as I did use it in college but for some reason forgot it (we are talking 15 plus years) given that is apparently how you distribute executable lisp code... IIRC though I hated image saving when it came to Squeak aka Smalltalk so I'm not sure if I did like that.

Yeah the Python one was a stretch and I often use the Python REPL as a calculator (I have no real strong idea why but I guess because numpy is what I know).

> When I am thinking about a REPL the image I have in mind is of Jupyter Notebook and Clojure, Elixir, Idris, Haskell REPLs in Emacs

Thats my point is that the REPL case of using Emacs to run and evaluate your code is almost hardly different than letting an IDE run your unit test. With Java this evident because the IDE compiles incrementally and the debugger can hot code swap.

The power of the REPL should not be the evaluation portion but the input or the print otherwise you can just about do any quick evaluation for any language that compiles reasonable fast.

Other than Jupyter Notebook the ones you mention don't really have any amazing output other than pretty print. To the authors point it also helps for the pretty print if the language is homoiconic.

As for input there is even fewer that have Excel like rapid response feedback. See Bret Victor on this. There was a recent company presented here on HN called Luna [1] who have a very cool REPL. Now that is where I think REPLs should be.

> P.S. I didn't get your point about python having nominal types, duck typing seems closer to structural typing to me and mypy seems to support both, but maybe I misunderstood you. Thanks for the thought provoking discussion though :)

For the most part you need to name functions in Python (lambda support I believe is even on the way out but I can't recall the status). In fact other than I guess tuples you need to name everything in Python.

But to your point structural typing means less in a duck typing environment particularly one with really late dispatch.

[1]: https://news.ycombinator.com/item?id=14612680

I'm not against REPLs I just think they have been around since early Lisp and there are vast improvements that can be made.

I use REPLs all the time... Bash is basically a REPL :)

The reason I think Java REPL would be awful is not because I dislike REPLs but because Java is really painful for that kind of mutable command line like development. Like just making a damn struct like object is absolutely painful and Java does not have structural types (ignoring FunctionalInterfaces which isn't really structure types).

Python REPL is painful because of required indentation and again because Python is similar to Java and prefers nominal types.

I'm not against Python or Java but I don't think the language design of those languages really works well for REPL compared to say Lisp, OCaml, Haskell, or even Scala and Smalltalk.

However to the author's point I believe some languages are inherently superior for REPLs particularly if they have powerful literal syntax.

Java is not a fun language to type expressions in and IMO neither is Python albeit for completely different reason. I can elaborate more if you like but I think most will agree.. Java will be a pain to type in a REPL.

I have been meaning to look at Idris for so long! Thanks for the inspiration to move that higher up the queue :)

Yes I agree on the Smalltalk point. I think Squeak was at one point the very future of REPL-like development and hence why I think the article doesn't really go into how REPLs could be better and how they aren't really that much better than other development tools (ie IDE + debugger,... I mention this in other comments).

I had no idea that common lisp had image saving! I only used the Carnegie Mellon one in college.... its been a long time.

Yes I think you make an excellent point but more so because the output of the REPL session is much better than a typical REPL session of just plain text.

Sort of in a round about way but in my original comment my hope was to elicit the discussion that modern development tools of ide visualization + debugger + hot code swapping are not far off from traditional REPLs and in same cases better because the inputs and outputs are better.

That is traditional REPLs (ie commandline with maybe some readline capabilities) I think aren't that much better the inputs/outputs aren't that good.

To your point on the static analysis I agree but a truly interactive development system that allows google-esque querying I think is far more than a REPL or at least the REPLs I know/knew of but I guess REPL definition can be somewhat nebulous these days.