31–40 of 80 posts
Earlier quoted context omitted.
That's pretty unreadable for someone who doesn't know clojure.
That could be said for any language. It's just that the first language someone usually learns borrows more from algol than from lisp. This leads to the idea that Python/Ruby/PHP/Javascript are easier to learn than Clojure/Common Lisp/Scheme.
The only reason to write in a language like C or Java today (over Python) is speed. And there are a very limited number of applications that require that sort of speed. There's no question that Linux should be written in a low level language, or a high-performance chess bot. But I'm incredulous when I see anyone write a website in even the relatively high-level Java. So, the author is right that we're getting more Py…
You probably mean a very limited number of web app frontend code. That may be true. But I think you underestimate what is being done with software.
With a language that is 200 times slower than C or Java you can't do any data analysis, graphics or image processing, machine learning, algorithmic optimisation, financial software like trading, pricing and risk management, embedded systems, bioinformatics, simulation and a whole lot more.
You're basically excluding yourself from doing anything that mankind couldn't do before. Progress it's called. Most AI tasks require massive computational power. But even just things like pickling a Python object is too onerous for Python itself. I don't think that's good enough.
Earlier quoted context omitted.
That's pretty unreadable for someone who doesn't know clojure.
Is this better? map(partial(reduce, +), partition(7, 7, daily)) Personally I'd be much much more happy to be using this code than the snippet in the article. In fact, I don't program Python regularly and it did take quite a while to figure out what was going on in the code. weekly = [sum(daily[j:j+7]) for j in range(0, len(daily), 7)] Now if you look back at the top snippet, its just normal function calls, so you can…
def partition(n, step, coll):
for i in range(0, len(coll), step):
yield coll[i:i+n]
weekly = [sum(week) for week in partition(7, 7, daily)]
map(sum, partition(7, 7, daily))
I seriously doubt it. The more the compiler knows, the more it can optimize things.
What it's "daily" in this example? It could be anything. The only thing the compiler knows at compile time is that it should generate some lookups searching and calling the functions "__iter__", "__slice__", etc... Put that line into a function which receives daily as a parameter and it could mean something different at every single invocation. Human beings, looking that code think know what it does, while in fact don't have a clue. The equivalent code in clojure someone has wrote only is really equivalent under some very specific assumptions.
I know, I know, at runtime you could gather all kinds of interesting data to optimize things. But, that's not easy nor cheap and, sometimes, iterating over an array, it's just iterating over an array.
Earlier quoted context omitted.
I hear you, but come on now, static types as a replacement for unit tests? Is this a deliberate troll? Failure of reading comprehension? Where do I ever advocate static types as a replacement for Unit Tests? Why would a Smalltalker ever do that!? I might be misunderstanding, but wouldn't this require you to rewrite your code before a production release? There's a big difference between inserting a bunch of tags like…
Failure of reading comprehension? Whoa, what are you talking about? Ironically, I think you're the one failing at reading comprehension. Read the thread. Clearly my "static types as a replacement for unit tests" comment was referring to the post I'd responded to initially. It had nothing to do whatsoever with what you said. I was essentially acknowledging your point, but saying that some people seem to advocate stati…
Read my posts! You're putting someone else's words into my mouth! (Ones which are uninformed and frequently used themselves to troll!) So, there should be an implicit assumption that every thread is diametrically opposed around the issue? And everyone who doesn't follow that assumption and inserts informative neutral concepts are "not paying attention?" I find that intellectually limiting, to put it kindly.
Calm down bro...I was asking for clarification because I really wasn't sure I knew enough about it. Again, no trolling intended ... no need to be defensive.
No, you were putting words into my mouth due to inattentive reading. I'm not being defensive. I'm going on the offensive. Being inattentive and putting words into someone else's mouth and being called on it is not your cue to tell them to mellow. In my book, it's time to demonstrate some intellectual integrity and apologize.
I thank you for your most illuminating reaction!
The only reason to write in a language like C or Java today (over Python) is speed. And there are a very limited number of applications that require that sort of speed. There's no question that Linux should be written in a low level language, or a high-performance chess bot. But I'm incredulous when I see anyone write a website in even the relatively high-level Java. So, the author is right that we're getting more Py…
In the early days, the fact Unix was written in C was quite remarkable. At that time, OSs were written in hand-optimized assembly language.
I see no reason to stay with C-level languages (C was once called high-level) if we can make compilers that translate them into machine code that's faster than hand-optimized assembly.
Smalltalk/80 and the various Lisp machines are sufficient proof whole environments, from kernel to GUI, can be written in higher-than-C-level languages, provided the machine is fast enough. If we can extract speed from compilers and not from expensive silicon, I see no reason not to do it.
In a couple days I will attend to a lecture on porting the Squeak VM to FPGAs and running Smalltalk on silicon. That should be interesting.
Earlier quoted context omitted.
More people than you'd think, hence the current fashion for "unit tests".
Static typing hardly replaces unit tests. And I think it's a stretch that people who use unit tests are just trying to compensate for a lack of static types. Actually, it's more than a stretch, it's false for pretty much any competent programmer. If it were true, why would Java programmers use JUnit?
Still, some of the errors you would catch with static typing you can catch with unit tests. It's not a replacement, but probably better than nothing.
The only reason to write in a language like C or Java today (over Python) is speed. And there are a very limited number of applications that require that sort of speed. There's no question that Linux should be written in a low level language, or a high-performance chess bot. But I'm incredulous when I see anyone write a website in even the relatively high-level Java. So, the author is right that we're getting more Py…
> The only reason to write in a language like C or Java today (over Python) is speed. Do you really believe that?
Earlier quoted context omitted.
Some day, something like Python will be the fast low level language, there will be new slower languages that are easier to use than Python, and C will be a memory. There are Smalltalks that ditched (in one case all) their "primitive" methods written in C against the VM internals because the JIT compiler turned out to be good enough. (Agents for the all case. VisualWorks also lets much of the Dictionary functionality…
We are dealing with "poky" high level languages like Ruby and Python because a lot of us find Lisp, Smalltalk and Self horrendous to work with. Ruby in particular is basically Smalltalk + Lisp for regular people - it's taken a good chunk of the concepts and packaged it in a way more people are happy to work with. First time I read about Scheme I was fascinated. Until I played with it a while and put it away and promp…
Do I take issue over other people using other syntaxes? No. Does syntax put any kind of limitation on VM speed? No. Do I even imply that Smalltalk and Lisp are conceptually superior to Ruby? No.
What I am saying is that the current popular HLLs are behind the curve in terms of performance.
I find it funny that adult techies discard Smalltalk over syntax. There's only 5 rules, FFS. Lots of grade school kids have used it like a highly advanced multimedia Logo. That said, the traditional operator precedence of algebras is such a deep part of Engineering, Science, and Mathematics culture, that any language that doesn't add it as a convenience to those groups is probably and understandably doomed to obscurity. (In particular, Forth, Smalltalk, Lisp, Self, and others.)
If only David Simmons had better marketing and community organizing skills. Smallscript might have been where Ruby is today.
The only reason to write in a language like C or Java today (over Python) is speed. And there are a very limited number of applications that require that sort of speed. There's no question that Linux should be written in a low level language, or a high-performance chess bot. But I'm incredulous when I see anyone write a website in even the relatively high-level Java. So, the author is right that we're getting more Py…
"There's no question that Linux should be written in a low level language" In the early days, the fact Unix was written in C was quite remarkable. At that time, OSs were written in hand-optimized assembly language. I see no reason to stay with C-level languages (C was once called high-level) if we can make compilers that translate them into machine code that's faster than hand-optimized assembly. Smalltalk/80 and the…