21–30 of 38 posts
I like Smalltalk, but like Forth and Lisp it's just not practical in most of my computing tasks, career or hobby-wise. It's a shame that Smalltalk didn't evolve enough to challenge Java in the '90s. But my buds that knew it well and also had some C chops are in demand as Objective C coders.
I like Smalltalk, but like Forth and Lisp it's just not practical in most of my computing tasks, career or hobby-wise. It's a shame that Smalltalk didn't evolve enough to challenge Java in the '90s. But my buds that knew it well and also had some C chops are in demand as Objective C coders.
And then, this statement is just blaming the tools rather than the developers. "C chops" means less than "has good logical thinking skills and exposure to many programming approaches/patterns".
I like Smalltalk, but like Forth and Lisp it's just not practical in most of my computing tasks, career or hobby-wise. It's a shame that Smalltalk didn't evolve enough to challenge Java in the '90s. But my buds that knew it well and also had some C chops are in demand as Objective C coders.
The word you were looking for was "popular", not "practical". Our industry is largely internally rife with fads, marketing, and anecdotal discussion, rather than objective analysis and scientific measurement. And then, this statement is just blaming the tools rather than the developers. "C chops" means less than "has good logical thinking skills and exposure to many programming approaches/patterns".
Earlier quoted context omitted.
I don't think that's fair. Being able to implement if doesn't mean that the entire remainder of the system is built without any conditional instructions anywhere in its implementation. (The point, after all, isn't some sort of mystical purity; it's that if you can implement if then you can probably also implement whatever other control structures you happen to fancy. Which you can.)
The problem is that reading this seems very bait-and-switch-y. Basically, author is doing: (define (my-if cond t f) (if cond (t) (f))) (my-if #t (lambda () ....) (lambda () ....)) The trickyness about if lies in the order of argument evaluation. If you ignore that, then it is relatively easy to implement if in any reasonable language. Even C (I had to leave out the function pointer types, as I haven't worked with c i…
equals: other ^ PTrue new The implementation of ifTrue isn't done. The branching was just deferred to the equals function, which has to somehow choose between PTrue and PFalse. Will it take advantage of the ifTrue function you're building? Will it resort to some nasty arithmetic? Will it call some baked-in feature of smalltalk? Without an answer here, the "implementation" of if is just an illusion.
Earlier quoted context omitted.
The word you were looking for was "popular", not "practical". Our industry is largely internally rife with fads, marketing, and anecdotal discussion, rather than objective analysis and scientific measurement. And then, this statement is just blaming the tools rather than the developers. "C chops" means less than "has good logical thinking skills and exposure to many programming approaches/patterns".
I disagree. Every time I tried to put together an app with any of Common Lisp, Scheme or Smalltalk I found myself fighting idiosyncrasies unrelated to my app. Obviously it can be done, but the advantage of using those languages start to diminish. It's not about popularity, it's about practicality. I found making Java web applications unpractical in a similar way although I haven't tried enough.
The syntax is quite unique to Smalltalk. The message, otherwise known as “method call” in other languages, is called show: (including the colon) and it takes an argument. self also uses this method call syntax. However this syntax can get quite confusing, see this example from http://en.wikipedia.org/wiki/Self_(programming_language) valid: base bottom between: ligature bottom + height and: base top / scale factor. Sm…
valid = [self baseBottomBetween:[self ligatureBottom]+[self height] and:[self base]];equals: other ^ PTrue new The implementation of ifTrue isn't done. The branching was just deferred to the equals function, which has to somehow choose between PTrue and PFalse. Will it take advantage of the ifTrue function you're building? Will it resort to some nasty arithmetic? Will it call some baked-in feature of smalltalk? Without an answer here, the "implementation" of if is just an illusion.
I don't think that's fair. Being able to implement if doesn't mean that the entire remainder of the system is built without any conditional instructions anywhere in its implementation. (The point, after all, isn't some sort of mystical purity; it's that if you can implement if then you can probably also implement whatever other control structures you happen to fancy. Which you can.)
Smalltalk (presumably) has a form of logical branching in it somewhere. To finish the if, just pick one.
For a satisfying conclusion, you want to use one that doesn't already look like an if statement.
I like Smalltalk, but like Forth and Lisp it's just not practical in most of my computing tasks, career or hobby-wise. It's a shame that Smalltalk didn't evolve enough to challenge Java in the '90s. But my buds that knew it well and also had some C chops are in demand as Objective C coders.
The word you were looking for was "popular", not "practical". Our industry is largely internally rife with fads, marketing, and anecdotal discussion, rather than objective analysis and scientific measurement. And then, this statement is just blaming the tools rather than the developers. "C chops" means less than "has good logical thinking skills and exposure to many programming approaches/patterns".
In any case, here is an objective problem: Common Lisp does not include a standard for regular expressions.
That isn't anecdotal and it isn't misplaced blame and it isn't an unnamed idiosyncrasy. It's a failure within the CL standard to include one of the most powerful tools around for text processing--a tool that pretty much every dynamic language includes.
I've tried using lisp before for text processing and found it brutal--practically impossible--compared to other dynamic languages. That isn't due to popularity, it's because python and perl and awk have built-in facilities for manipulating the hell out of text that sit right on the surface, were easy to find, and work well. Despite having lots of functions for chars and strings, common lisp never felt anywhere as easy for those tasks.
If I'm wrong, then I will look forward to being educated, but I honestly believe that practical limits have everything to do with why people don't turn to CL for scripting.
Thoughts?
Earlier quoted context omitted.
The word you were looking for was "popular", not "practical". Our industry is largely internally rife with fads, marketing, and anecdotal discussion, rather than objective analysis and scientific measurement. And then, this statement is just blaming the tools rather than the developers. "C chops" means less than "has good logical thinking skills and exposure to many programming approaches/patterns".
Since you are hung up on "objective analysis," what objective evidence do you have that this claim is true? In any case, here is an objective problem: Common Lisp does not include a standard for regular expressions. That isn't anecdotal and it isn't misplaced blame and it isn't an unnamed idiosyncrasy. It's a failure within the CL standard to include one of the most powerful tools around for text processing--a tool t…
CL has a nice variety of libraries that extend the language. It is certainly debatable what constitutes good "core language" features vs what should be in good "language extensions" or libraries, but I should make one comment on what I have seen of Lisp libraries: they have high quality, and wherever there is lack, it is documented. There is even a humility about it, a distinct lack of attempt at showmanship or marketing, as if the community cares more about really good theory than the next buck. I suspect this faithfulness to the reality of the various algorithms is part of what turns away people who are on the hunt for shinies.
As a counter example, Perl is well-known for having a huge base of libraries via CPAN, but the signal to noise ratio is very low. There are few libraries that have any quality and a general lack of consistency and interoperability between them with the notable exception of packages like Moose.
From what I understand in reading about this lack of built-in regexp support, it has something to do with regexes being a theoretically weak approach towards parsing. I have some ideas on what that means, but I have no strong participation in such discussions, so I am cautious about proceeding into that territory.
It is possible what allowed me to get to the point where I was confident I could solve any problem I wanted in Lisp (web, database, random scripting, 3D game application, etc) was the fact that I spent a lot of time playing with Lisp and shifting my mental model several times. And I still feel like an egg compared to what some of the folks are doing on some of the Lisp forums. It seems like the people who are breaking new ground in programming theory (and not just rehashing the same old concepts in different syntax approaches) are in the lisp communities, although I should give a good nod to Haskell's continuation of the ML line.
Anyway, I am a little hung up on this definition of "practical". Maybe I am lucky and happen to look in the right places? I did start off on the wrong foot and dig deeply into ASDF stuff a while back when it was messier, but that kind of thing is outdated now with the introduction of the QuickLisp library.
One last note: when you said "scripting", did you really mean "programming"? There is a connotation that scripts are more for one-offs, for hacking stuff together, and Lisp is more oriented towards serious, large applications, for managing huge and complex problems.