Weirdly, nobody is complaining about the contrast. This might all seem crisp on a high-def screen in good lighting conditions, but try a cheap tablet or laptop and evaluate again. Elderly have tremendous problems reading the labels on the buttons. Try the firefox plugin https://addons.mozilla.org/en-us/firefox/addon/wcag-contrast... to evaluate the contrast.
The task is complicated, since it asks for a constant choreography of the mind needing to remember to be mindful of what the body eats in a situation that is clouded by suppressed feelings regarding food. Untrained, the mind tries to constantly downplay the positive impact of the diet and tries to focus on the immediate reward of eating food.
Something can only be seen as difficult if you have a clear view of the task at hand. Chopping wood or solving equations might be difficult. Something is complicated when the mind needs many different tactics to solve a problem. Solving equations and the understanding and acting upon multiple feedback loops is difficult.
People suffering from weight problems often cannot comprehend their whole problem. Understanding the products that are eaten will focus on perception, therefor clarifying over time the big picture. It's like asking a gambler to calculate the odds of every bet he makes. Soon, the math becomes more important than the winning, thus freeing the sufferer from the emotions that are attached to food.
Another way of seeing the complications involved with food problems is by understanding that most of the food we eat nowadays is processed. For example, we tend to eat the carbs but not the fibers. This unbalances millions of years of natural evolution and allows for exorbitant high levels of insulin without feeling saturated. Counter-acting these processes that happen partly inside and partly outside our mind is a complicated process that takes years or decades of someones life.
Well, Eclipse is slow, crashes, has a lot of features but doesn't really do anything nicely (javadoc integration is damn awful tu use). More features doesn't mean better.
What i like about LighTables is that it seems to have few features, but do them well. It has a nice clean UI (even if it's just mockup, i don't think it needs anything else) and the UX seems nice too from what i understood.
Maybe what you didn't understood is that it's NOT an IDE for computer scientists : it's more aimed to visual programmer, webdev, or gamedev, creativecoders. People that want to do both design and coding.
BTW : i just trashed Eclipse, not anyone. I still use it because it's still the best ide for javacoding (even if i haven't done any in a while), which, to me, isn't really flattering for the state of coding IDEs.
Eclipse needs a good amount of memory and recently, unfortunately, has a tendency to crash. Most of the features can be disabled; the UI can be reconfigured to your liking. Btw, I generally disable the javadoc view and just F3 to the location to see the code and docs together (docs are often wrong anyways).
The problem with mockups is that they haven't touched reality yet: there is always so much detail you don't see at the start.
I would translate it exactly like that, though it's actually not ad hominem but ad humanitatem, really. We are all biased creatures, as others have pointed out. I think the critique is biased, I think it is biased because the author put a lot of effort in his (otherwise awesome) Java product, and therefore I quoted Upton Sinclair.
For instance, he argues that it would take a lot of working around to provide instant feedback for code with side-effects, but isn't that obvious? The LightTable video doesn't claim it magically mocks every external component or does some other fancy stuff. That doesn't make the feature less useful, especially in a language like Clojure, which was used for the demo. For me, that part reads much like "since it ws so hard to create Chronon, one cannot pretend the LightTable features are so easy to implement. Let me prove that by putting LightTable in the context of my product."
There was — deliberately, yes — a bit of snide and a lot of cynicism in my post, but I hope to have made it clear that it was not without a reason (for the cynicism, at least).
If a scientist is funded by the petroleum industry and publishes articles saying that climate change isn't happening, is his connection relevant?
If a doctor is funded by a drug company and publishes articles saying that the company's drugs are good, is her connection relevant?
Even the best scientists can be biased, and being aware of the biases can help one decide how much attention to give arguments. If Prashant Deva is biased by his experience and funding against the technology that he is critiquing, then that is relevant information to me and many other people who read his critique. To suppress that information, as you seem to be trying to do, would be a blow against transparency. In my opinion, that would be a bad thing.
In peer-review, the original authors are redacted, so the peer-review committee's bias is reduced (not eliminated, of course).
When a scientist is funded by the petrol industry, but has a long history of showing sound scientific results, I'd give him my full attention. Perhaps my reading of his results would be biased negatively if I would know his research is funded by a certain industry.
When that doctor publishes an article on his new drugs, I question where it is published, whether there have been similar results by other researchers, whether similar approaches have seen widespread application, whether the author can connect the results logically with other research, whether there has been a good peer review and whether I can understand his results. These metrics give me confidence. The funding of the researcher might interest me, but another researcher with a perfect clean sheet might get his funding in a more black-market way. They say you should follow the money, but generally it is difficult, if not impossible, to find the trail.
This means I question almost everything I read and unfortunately have little certainties. Then again "Nothing is so difficult as not deceiving oneself." -- Wittgenstein
not really, just that all of us come with a point of view and I think his is made clear by the work he is doing on that project.
Never used it, looks interesting and useful for Java. That's where I think the problem is: if you have used only one tool you tend to see everything from that perspective.
His argument is on how most concepts in light table are not novel. Branding light table as novel or groundbreaking is therefor incorrect and his post is called for.
You seem to attack his argument on his background as a Java developer and not on parts of his argument. As far as I know, this is called an ad hominem attack and in my opinion does not belong on Hacker News.
If you can find good counter arguments on his arguments:
- Light Table is not novel or groundbreaking since Eclipse has had these kind of features for at least a decade (and several Smalltalk IDE's have had them for several decades),
- Light Table's examples are contrived because real world examples do not behave in this way,
first: I replied to zacharyvoase's comment and therefore my comment was related to his, don't take it in isolation.
There are plenty of other comments here that explain why pdeva1 is coming from the wrong angle therefore I'm not going to repeat them.
Chris never mentioned novel or groundbreaking, others have so go and ask them but please before you do that look up the difference between invention and innovation and also remember that novel really means fresh or refreshing (although it's used most of the time to indicate new)
"Since he's a Java developer, he delivers critique on LightTable".
thereby pointing out that any other kind of developer would probably not have made such critique, thereby relating the validity of his critique with him being a Java developer/Eclipse user, thereby being an ad hominem attack.
On your last argument I would like to add that on Hacker News it is clearly branded as the next big thing since sliced bread.
Of course languages such a Clojure, Scala and Haskell need more sophisticated IDE's than vim + plugins. Especially for larger projects. And as such I think the features in the POC are a good idea. Still, they are nothing new and I'd expect them in any modern IDE. I could add some idea's of my own (stealing from an IDE I use daily):
- annotate the source with a git history
- highlighting based on AST instead of regex's
- outlines
Anyways, we agree that Light Table is not novel, nor groundbreaking and it's not an invention. Exactly the point Prashant Deva was trying to make. Nothing to see here, move along.
"Since he's a Java developer, he delivers critique on LightTable".
thereby pointing out that any other kind of developer would probably not have made such critique, thereby relating the validity of his critique with him being a Java developer/Eclipse user, thereby being an ad hominem attack.
No, it's more that he's writing as if he's unaware how parochially Java-centric his viewpoint is. Many of his points aren't very useful for other languages.
Ah, finally, here we have the gist of the argument: "Many of his points aren't very useful for other languages." The rest is all noise and no signal.
Well, although that point has been answered on other parts of the forum, it seems the auto-eval function is reserved for immutables only and non-recursive languages. So it seems this restriction reduces to number of applicable language to around zero. Thus, at least one of his points applies to all other languages. Do you want to hear argumentation for the other points?
So it seems this restriction reduces to number of applicable language to around zero. Thus, at least one of his points applies to all other languages. Do you want to hear argumentation for the other points?
It seems we've touched a nerve, which is a bit embarrassing. Clearly, the kinds of things the Light-Table gentleman is talking about are applicable to more than zero languages. I know because I've spent 1.5 decades coding in one. That you'd make such an argument indicates you aren't in command of all the facts, or you're willing to take or build up strawman interpretations.
(One famous gentleman once said, "If you ever get someone upset, you've struck gold!")
That said, "auto-eval," if this means automatic re-evaluation of everything is slick demo stuff. But nimbly being able to edit and save any source code, then being able to fearlessly rewind the stack to an appropriate point and go on as if the change was always there would be appropriate even for very involved and long running code, and is quite real.
Similarly, I know for a fact that everything else in the Light Table video has approximations in real environments.
How would you render trees or (big) matrices? Recursive functions? Infinite lists?
I'm upset because the method of discussion here seems to revolve around tainting the credulity of the author ("That you'd make such an argument indicates you aren't in command of all the facts"); by claiming a conflict of interest while this is not applicable (the OP does not claim authority!); or by appeals to authority ("because I've spent 1.5 decades coding in one").
By the way, I feel that those who have to play the "If you ever get someone upset, you've struck gold!"-card, should listen to some more gentlemen talk about syllogisms.
How would you render trees or (big) matrices? Recursive functions? Infinite lists?
You don't. I think the Light Table author is naive here. Instead, you let the programmer rewind the stack at will.
I'm upset because the method of discussion here seems to revolve around tainting the credulity of the author ("That you'd make such an argument indicates you aren't in command of all the facts")
The facts in question have to do with things I've seen implemented. Your argument is an indication you aren't aware of the same. That's not tainting your credulity. I'm questioning if you have all the facts.
By the way, I feel that those who have to play the "If you ever get someone upset, you've struck gold!"-card, should listen to some more gentlemen talk about syllogisms.
You are the one who is upset. You are also incorrect about what you purport to be upset about. (My intentions in pointing out certain facts and their implications.) Please process this data.
I'd say that instant eval in the 'inventing on principle' fashion does make it novel and groundbreaking. Everything in it don't have to be. The core premise, a general purpose IDE based around those ideas is.
Thanks for the reference, I'll surely read it. [Pause] I've just read the first couple of chapters and it is most surely an enjoyable read. It brings the current discussion into a completely different light. Thanks again.
Java's annotations could be seen as 'part of the environment' (whatever that may mean). I often use annotations which indicate how a method should be used, and those annotations are used by static analysis to validate correctness.
When using Java, I often change my program while it is running. recompiling classes on the fly. It works in most cases, and when it doesn't work, I believe other languages would fail as well.
You say Java is deeply flawed. I argue that Java is one of the most successful languages around nowadays. It does what it is designed to do: be relatively easy to learn, a natural successor to C++ with a wide range of libraries. Yes, Java code can often be verbose, but this depends greatly on the kind of paradigms used. I can write verbose and ugly code in Clojure and write relatively concise and elegant code in Java. It depends on architecture, a good understanding of OOP (and its limitations), composition over inheritance. The problem with Java is the sheer amount of 'bad' code written in it (because of all the leagues of beginner programmers), giving it a bad name. Have you seen Clojure code of a large product (equivalent to around 1M code lines of Java), produced by a team of diverse programmers and maintained by another team during a 10 year lifespan? You would cringe just as hard.
Finally, lighttable is a proof-of-concept... It's not there yet; there are no reviews; leagues of smart engineers have tried to reproduce something similar and could not escape the POC phase at all.
"When using Java, I often change my program while it is running. recompiling classes on the fly. It works in most cases, and when it doesn't work, I believe other languages would fail as well."
I use Java fulltime at work and also have some problems where recompiling classes on the fly doesn't work. I never had the problem with Smalltalk. To assume the problems in one environment will be problems in another is exactly the problem with the original article. It assumes that because something similar exists in X, it would be the same in Y and have the same sorts of issues and rewards.
"Finally, lighttable is a proof-of-concept... It's not there yet; there are no reviews; leagues of smart engineers have tried to reproduce something similar and could not escape the POC phase at all."
A large chunk of what is in light table has existed in over a quarter century in Smalltalk environments and been used to build large and complex applications.
I use Java in my day job and I find annotations a real blight on the language. While I totally get the idea that they remove the need to write a lot of boilerplate code, I still find a lot of them too "voodoo" for my liking.
Agreed, they aren't the prettiest thing in Java and they only allow one 'layer' of annotating (you can't use expressions in annotations for example), they do prove it is possible to document your code in Java in a way that it becomes part of the 'environment' (again, 'environment' is ill-defined, so all arguments in this line are a bit frail).
> he problem with Java is the sheer amount of 'bad' code written in it
java was designed to influence code towards solving all problems with classes. the "bad code" you speak of is idiomatic java code.
Jane Street wrote about how they migrated core systems to java, abandoned it because "But somehow when coding in Java we built up a nest of classes that left people scratching their heads when they wanted to understand just what piece of code was actually being invoked when a given method was called"[1]. then, the same team moved to a functional language to great success.
Writing "good code" in java takes discipline and expertise to overcome Java's gravity towards classes. Without discipline and expertise, teams end up at the natural equlibrium you read about on thedailywtf.com. java did an awesome job of replacing C++ for the last 15 years, but there's something inherent about the design of java that doesn't scale well with the bigger, higher complexity problems we face today.
