The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Superstar programmers

Thought experiment:

The requirement is to build from scratch an SQL engine working on in memory data (take this as a given. Try to estimate the no. of lines of code (programming language/environment of your choice) this is going to take, and the time it will take you to build it.

Try to estimate the same considering someone you consider good, and someone you consider average.


Scroll down when you've written down your estimates.























Did you ?















Well ?

Using the programming language K, [ http://nsl.com/k/t.k ], a 14 line implementation, took Stevan Apter a couple of hours to write; But that's just the backend. You want an SQL interface? Arthur Whitney just published one in [ http://kx.com/q/e/s.k ], taking all of 20 lines (admittedly, denser than Stevan's); 3 for lexing, ~8 for parsing, the rest for evaluating. I don't know how long it took Arthur, but a day would probably be _way_ too long.

You may think: """ But that's line noise """. No -- it's a terse language. It's taking the representation of "plus(a,b)" to "a+b" to the extreme; If you're not used to it, it's hard to read. After you're used to it, it's hard to stand the horribly redundant verbosity of modern languages.

My estimate is that an _average_ programmer is not capable of building an SQL engine from scratch at all, and that a _good_ programmer will take a few thousand lines and a couple of weeks to do that. People like Arthur & Stevan can do it in a day.

You may now restore your SEP field, disbelieve that this is possible, and go back to doing what you did before.
Ori Berger
Monday, December 05, 2005
 
 
I bet it would be even shorter in APL.
Larry Lard Send private email
Monday, December 05, 2005
 
 
I have created a little SQL parser because some database libraries didn't have the same good support for SQL. I ended up using it to wrap a database that does not even support SQL. It's not the best solution at parsing SQL, but I did it alone without consulting books or other people's codes. Programming rocks! What you write today should serve as a basis for further improvements. If you are always throwing away your codes, like in using 10 different languages simultaneously, maybe you won't be able to reuse all your code.

I like solving one problem at a time. But I have enough challenges already to keep me busy for the next 6 months.
Johnny
Monday, December 05, 2005
 
 
It's painfully obvious that the programmer who wrote that second entry was _trying_ to be obscure. The first entry? Meh, it's nice to show off. But I don't think I would be comfortable relying on it, using it in a library, and shipping it off to the customer.
Dave
Monday, December 05, 2005
 
 
pfft, I could totally write that in 12 lines instead of 14!
D.W.
Monday, December 05, 2005
 
 
Why would I write one when I can get one for free?

Not writing something when you don't need to, now that's a superstar programmer.
Actively Disengaged
Monday, December 05, 2005
 
 
Oh god these things drive me nuts. It's so pointless. Yes, those programs are all very clever I dare say and the people that wrote them are clearly very good at holding complex information in their head.

But how relevant is that? Is it maintainable? Is it useful? Does anyone else know what's going on? If the answer to any of those is no, then it rather disqualifies you from superstardom. There's a big difference between designing a useful usable system such that it meets all requirements in a sensible time-effective way such that it is stable and maintainable, and implementing a known standard in the least number of characters (picking an esoteric language to help).

Someone that can do the first of those well, while dealing with changing demands, managing the running/maintenance/quality of code and design, and all the other minutiae that go with building good software is a superstar.  Someone that can do the second is a sideshow attraction. I've never met anyone that can do both (or that would want to).
Andrew Cherry Send private email
Monday, December 05, 2005
 
 
+1 to  Actively Disengaged.

Why would I waste time reiventing the wheel when I can spend sometime on Google finding one.  That way I can spend my time solving the business requiremnets I was hired to do.

Great programmers aren't the ones that can solve a problem in the least amount of code but the one that can figure out the correct problem to solve in the first place.
Bill Rushmore Send private email
Monday, December 05, 2005
 
 
"Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it."

http://discuss.joelonsoftware.com/default.asp?joel.3.263060.3

I don't know if it's right the grow old without doing something worthwhile.

If I could single out a couple of super programmers that have changed my life, they would be Matz (the creator of Ruby) and Dave Thomas (a Ruby early adopter, who wrote the book that got me into Ruby).

Dave Thomas is really a super everything.

That said, I prefer the status of a bad programmer who wants to use Ruby for as much as he can, than the status of a good programmer that needs to use Java or DotNet.
Johnny
Monday, December 05, 2005
 
 
This is precisely the kind of thing CS students do. My friend tells me about her homework (which is along these lines) all the time. Choice of language is the #1 criteria, of course, because some simply won't condense that far.

Now what does this have to do with the real world?
MarkTAW Send private email
Monday, December 05, 2005
 
 
People here do not know what they are talking about.

Athur Whitney is a superstar programmer. Last time a looked, his database system was 10_000 times faster than conventional relational database systems. The K-programming language and its database KDB are true marvels of engineering.

K is very terse and hard to read at first, but one should not compare this half a page of K with half a page of C#. Compare it with 30_000 lines of C#. Is it still that more complex?

K syntax is odd, but below the syntax it is extremely elegant. Once the linguistic composition mechanisms are understood, reading K is not that difficult. Programs in K are not only shorter they are also intrisically simpler, because loops are rare and higher-order functions are very common. Although the syntax looks Perlish, the number of underlying concepts is very small.

Think of K as an APL without the weird symbols and another 40 years of language evolution. We all remember APL do not we?

>>>  Why would I write one when I can get one for free?

You simply cannot. Here you are talking about high performance databases that cost hundreds of thousands of euros in license costs without the costs of consulting. This is the stuff used on Wall Street for number runching.

A lot of valid points are made about the trade-offs between maintainability and brevity. But rest assured, these people will beat you on every one of the mentioned aspects: quality, cost, performance, reliability, flexibility, etc.

I did not look this time, but K-Systems used to have a free interpreter for K, play with it to get a feel for the language. It blows your socks off.
Karel Thönissen Send private email
Monday, December 05, 2005
 
 
Dave: No, believe it or not, that's arthur's usual style. It's not unreadable once you get used to it. Condensed, yes; terse, yes; takes effort to read, yes -- but not unreadable.

Andrew: A lot of Wall Street operations are betting the farm on these. Apparently, it's usable enough and maintainable enough. Kx is a small company (~10 people), yet, Wall Street is embracing them and paying more than Oracle for their database. That should tell you something.

Actively Disengaged: You can't get that performance for free. Take that requirement as an axiom for the sake of the discussion. Let's say it's a system SQLite and Oracle are not available for, with lots of memory but unbelievably slow disk (these things happen, you know).

Bill: You're welcome to find something as fast as kdb, google or whatnot. Sometimes, requirements can't be avoided.

Mark TAW: This is the real world. Kx is doing beautiful business, and won't bother talking to you unless you plan to drop a few hundred K$ on their software.

Karel: People are busy placing the SEP fields. Which guarantees future work for those who don't, so I'm not complaining :)

As Karel mentioned, you shouldn't compare 30 K lines with 30 C++ lines. You should compare the length of C++ code it takes to get the same functionality; That's closer to 30,000 lines. Even if each K line takes 500 times the effort to read (it doesn't; closer to 10 when you're versed), that's still 50% saving.
Ori Berger
Monday, December 05, 2005
 
 
it looks like K was specifically designed for these types of operations so it's kind of a cheat of the "few lines of code test" since the operations you would write in another language are built into K itself...

looks cool, tho.  i'd say this bit of code is a greater indication of the power of K than the merits of the authors as "superstar programmers" since few of us have worked with K before... let's see how these guys would do it in C#/Java?
Kenny
Monday, December 05, 2005
 
 
"Wall Street is embracing them and paying more than Oracle for their database. That should tell you something."
Hey, I think Wall Street is a figment of its own imagination...  I'm not sure what _that_ tells anyone.

"A lot of Wall Street operations are betting..."
Isn't that their core bussiness essentially?

"Dave: No, believe it or not, that's arthur's usual style. It's not unreadable once you get used to it. Condensed, yes; terse, yes; takes effort to read, yes -- but not unreadable."
I'm sorry, we were discussing code. Right. It's bad code. You've shown me two pages of bad code. I don't care if Wall Street bets two gazillion dollars on it. I don't feel like I even need to understand K in order to know that it is bad code. It's so glaringly obvious, it pokes you in the eye.

I'll just wait here for all the other participants in this group to declare me wrong and outmoded.
Dave
Monday, December 05, 2005
 
 
Hmmmm. Wall Street has bet on quite a few languages and technologies. The advantage of being Wall Street is that they can back quite a lot of horses - they have the funds.

K is good for what K is good for, that's the problem. Whereas you can write good programs in C++ or Java for 3d gaming, language processing, text analysis etc. as well as mathematical modelling and number crunching, the same cannot be said for K.

What you're left with is a high performance domain specific language that's hard to use. That's not really anything new, and there's obviously times when that's a very good idea. Whitney, yes, is a brilliant programmer. But more brilliant for having the skills and mental strength to write the language, than write *in* it.
Andrew Cherry Send private email
Monday, December 05, 2005
 
 
How does someone debug K code? Do people use print statements, and debugging tools?

Is K programming amenable to a more try-and-debug style of programming (which Sussman explains in an impressive talk [1]); or is it more like what I hear Haskell programmers do, which is think for an hour and then have a magically distilled 5-liner?

[1]: http://www.archive.org/details/arsdigitacoll09
Tayssir John Gabbour Send private email
Monday, December 05, 2005
 
 
Ori,

Interesting product (albeit with a far more limited use than you seem to imply. I guess I have my, uh, "SEP Field" on). Clearly in your example these implementations are built atop of a infrastructure with signficant set logic - it's basically syntactical sugar on top of the existing logic. Saying these these are "SQL implementations" is like saying that I can write a SQL engine with .NET and a couple of System.Data.SQLClient classes.

Which begs the question - if you're talking about an in-memory (10,000x more than a reliable, persistent relational database. Is that _IT_?) specialized library, are you really going to interact with SQL?
Dennis Forbes Send private email
Monday, December 05, 2005
 
 
Quote "If you are always throwing away your codes"

Not much choice when you dont own the IP is there?
Domainless
Monday, December 05, 2005
 
 
I'm not sure that only wanting customers that can drop 100K (is that in K?) is beautiful business.

It does strike me yet again though that terse languages hide all the planning, false starts, conundrums and confusions and that without considerably more planning than a procedural language terse languages are worse than useless.

It may well be that a complete SQL engine can be written in hours and in 14 lines of code but it occurs to me that the person that wrote it knew a considerable amount about SQL engine requirements before beginning to write it.

So the comparison is not the number of lines of code, nor yet the amount of time it took to write the lines of code and get them right but the time taken between understanding from the beginning the nature and extent of the problem, conceiving the solution and implementing it.

The comparison might very well be closer between K and any other language than you think. 

Restricted domain and problem domain languages are excellent and might be exactly the best solution but they have to be created for that domain precisely.

And there is the economic problem with such languages they are simply too expensive to use for general solutions.

For instance, how do you use this SQL engine, where is the interface, the documentation or even any user interface?
Simon Lucy Send private email
Monday, December 05, 2005
 
 
Oh, and does someone hopefully have a K -> readable sexp converter, so I can have a chance of figuring out which primitives K is using without serious training? ;)

(Or any converter to a more verbose/mainstream syntax. I mean, it's really hard to evaluate this code for most interested people; we'll end up typing pseudocode or something.)
Tayssir John Gabbour Send private email
Monday, December 05, 2005
 
 
which primitives K is using -> which primitives THIS CODE is using
Tayssir John Gabbour Send private email
Monday, December 05, 2005
 
 
Taken to the extreme, an SQL engine and in-memory database can be written in one line of code, if the language is written specifically for that.

memdb;  // instantiate an in-memory database

It's kind of like the HQ9+ language (look it up on Wikipedia)... one line of code (one letter actually) makes the program output its own source.
--
Monday, December 05, 2005
 
 
I think calling the piece a "SQL engine" is pretty hilarious. As a test I just sat down and wrote Python code to do the same thing and it didn't take more than an hour and 40 lines of code. (I based it on the "spec" in the K program--I'll post it if anyone is interested.) Really, it's easy to do in any fairly expressive language.

So I'm not sure if Ori's intent was to point out the expressiveness of K or the high performance of its implementations? Judging by the first point, you'd think he was talking about the expressiveness, but then later on he starts talking about performance as if that is its main forte.
Per Vognsen
Monday, December 05, 2005
 
 
K is a language oriented to data processing with Kdb+. It's not surprising to see K is so great to solve data-processing problems, that's its domain.

Kdb+ is the same idea: an excellent database for special applications, by design, but no general-purpose. It works best with historical data (seldom modified after insertion) because it expects to be able to load whole table columns in memory to support very fast reporting and analysis. Again, it's not surprising to see banks and financial companies using Kdb+ to analyze their data to death.

I agree with Ori. I would expect a superstar programmer to use K and Kdb+ when those are the best solutions to the problems at hand, instead of trying to squash every difficulty with the same hammer.
jquiroga Send private email
Monday, December 05, 2005
 
 
>You're welcome to find something as fast as kdb, google or whatnot. Sometimes, requirements can't be avoided.

You are missing my point.  If my application needed something ridculously fast for SQL access then I would do a search for an application that would do so, not try and write my own.    Unless your trying to advocate kdb, then your post was ineffective.
Bill Rushmore Send private email
Monday, December 05, 2005
 
 
Andrew: K is good for lots of things, as long as you start from the requirements and not from a given design. It's not a good language to implement an OO hierarchy, but that's rarely an end-user requirement.

Tayssir: Yep, K shares Lisp's try-debug and bottom up development preferences. And yes, the same magic distilling happens with K :) If you have a K interpreter, http://kx.com/a/k/examples/read.k will translate K to kenglish. Unfortunately, Kx stopped offering interpreter downloads awhile back.

Dennis: No set logic at all; Just simple vector logic, most of which (if not all) is available, e.g., in the STL's "valarray" template. No, this is a real SQL implementation. Stevan's code implements selection, sorting, aggregation etc. based on the language's sort operator and indexing. There is no built in SQL or relational algebra engine that is being used. Just vector ops (such as "compare each element in this array") which are also available in valarray.
You are right about the SQL - it was added because of popular demand, and is NOT the recommended way to access kdb.

Simon: SQLite version 3 was rewritten from scratch; It builds on years of experience, yet it is of comparable length to its previous version 2. I postulate that there's the same kind of hidden false starts that every mature product does.
It is very much K against other languages, but Arthur's C code (if you ever tried to read it) is almost as terse as his K code. That's the example of superstardom I was thinking of.
Re GUI, documentation etc: The latest K version has no GUI, but older ones did. You can find a lot of docs on kx.com's website; specifically, latest version docs can be found under http://kx.com/q/d/

K (as Lisp) is NOT a restricted domain language. Just not widely used outside specific domains. SEP field in action again.

--: But that's not the case.

Per: I'd be very interested if you post it. Arthur's code parses SQL and encodes them as (sort of) S-Expressions.  Stevan's code executes properly encoded queries. For me, this constitutes enough to call it an SQL engine. The two are not compatible with each other, but could have been without changing their length.

My intent was that some programmers are orders of magnitude more productive than others. It's a rather concrete example (it's been discussed here recently, many people posting that "they don't believe it's really possible"). This post is admiration for the works of two such superstar programmers, Whitney and Apter.

Whitney designed & implemented K so that he'd be more productive writing his high performance "kdb" database. The entire K + kdb implementation plus the sql parser/translator are (most probably) still much shorter and took much less to develop than any product giving comparable (or 100 times slower, which is more common) features.

Back to the subject: K is not the subject. Programmer productivity is.

And let me reiterate: K takes the "a+b" to the extreme. At some point in time, writing "10*a" was probably considered unreadable because you should have written "a+a+a+a+a+a+a+a+a+a". Most of today's code is closer to the latter, and people (e.g. on this thread) are arguing that this is the right way. Super productive programmers are among those who use the "10*a" notation.
Ori Berger
Monday, December 05, 2005
 
 
As a "K" ignoramus, I googled it and came up with <gasp!> a Kuro5hin article on it that is readable and informative:

http://www.kuro5hin.org/?op=displaystory;sid=2002/11/14/22741/791

Obviously, you'd want to go to the K site:

http://www.kx.com/index.php


Interesting.  I learn something new every day.
sharkfish Send private email
Monday, December 05, 2005
 
 
"And let me reiterate: K takes the "a+b" to the extreme. At some point in time, writing "10*a" was probably considered unreadable because you should have written "a+a+a+a+a+a+a+a+a+a"."

"Everything should be made as simple as possible, but not simpler."
-- Albert Einstein

"Super productive programmers are among those who use the "10*a" notation."

You and I have different ideas of what makes for a productive programmer.  I find all this k stuff be academic -- lacking any real world (re)usability.  That's not to say there isn't a place for code like this -- but not at the level at work at.
Almost H. Anonymous Send private email
Monday, December 05, 2005
 
 
"My intent was that some programmers are orders of magnitude more productive than others."

I don't disagree.  I just don't know if this K language thing is a good way demonstrate the point.
--
Monday, December 05, 2005
 
 
And just because it's a "14 line implementation" doesn't mean it didn't take long to write and doesn't take a long time to maintain.
Almost H. Anonymous Send private email
Monday, December 05, 2005
 
 
"Per: I'd be very interested if you post it. Arthur's code parses SQL and encodes them as (sort of) S-Expressions.  Stevan's code executes properly encoded queries."

I was referring to Steven's "back-end" code; parsing SQL is a mechanical chore. Aside from not supporting the full relational calculus, Stevan's code (as far as I can tell) does not do the things that are required in a serious RDBMS, such as indexing, query optimization and access path planning; this is where the really hard work is.

"For me, this constitutes enough to call it an SQL engine."

The reason I take exception to your characterization is that you started out the post asking the reader to make an estimate of how long it would take to develop an "in-memory SQL engine". When you say that, I think everyone assumes you are referring to something like SQLite, which takes a lot more than a day to write, regardless of your skill-level. I'm sure KDB is a fully featured SQL engine, but Stevan's code is nowhere near that. Sorry.

Anyway, here is my code:

http://www.cryptopunk.com/misc/sql.txt

The functions in the Table class do the same thing as their identically named counterparts in Stevan's K program; mine take up about 40 lines vs Stevan's 20 lines. I included fairly extensive test cases at the bottom of the file. You should be able to just load everything into a Python 2.4 interpreter and run it.
Per Vognsen
Monday, December 05, 2005
 
 
"I included fairly extensive test cases at the bottom of the file."

An excellent "superstar" trait!
Almost H. Anonymous Send private email
Monday, December 05, 2005
 
 
Terseness isn't particularly a measure of superstardom, a language may be terse because its domain is restricted, and K by general language definition is a single domain language.

Your point about SQLite 3 being about the same length as the previous version doesn't really address the point I was making about knowledge and now it seems that the definition of engine is a little loose. 

I suppose on the whole my reaction is 'so what', because the example you've shown isn't useable by me in any real world situation I might have.
Simon Lucy Send private email
Monday, December 05, 2005
 
 
APL/J/K are all fantastic solutions, but please don't use line-counts to make us look bad--we couldn't care less.

This is classic. You trying to tell us KX System is the model of geek success? Yeah, they may help a bunch of guys make some projections that hopefully helps their bottom-line. But--K will never change the world, no one gets it except the 50 people on earth who cares enough about money to bother with the syntax and quirks of the system.
Li-fan Chen Send private email
Monday, December 05, 2005
 
 
What does SEP stand for?

In most cases, it doesn't matter how productive a programmer is if they can't communicate with other programmers.
comp.lang.c refugee
Monday, December 05, 2005
 
 
Yaaayyyyy!!!  A K-Troll on Joel of Software.

I am fairly convinced K is a language designed purely to troll people with.

The whole language looks like a perl regex gone bad!
only trolls writing C code
Monday, December 05, 2005
 
 
Superstar programmers write maintainable code. Maintainable code is readible. Given code is not readible. Therefore code is not maintainable and was not written by superstar.
Art Wilkins
Monday, December 05, 2005
 
 
To those of you who say these languages are easy to read for those who are intelligent enough, I present you with this challenge:

a:p2[(+;-)]p2[(*;%)]p1[-]{$["("~x;p a;~"("~n[];x;(#:)~x;(j+:1;(#:;$[(?:)~x:n[];(x;i n[]);i x]))1;(x;p a)]}
c:p2[|]p2[&]p1[~:]{$["("~x;p c;|(,a n[]),|(r j;a x)]};ca:{$[@x;x;(&)~*x;,/ca'1_x;,x]};wh:{$[#x:b[`where]c;ca x;x]}
tt:(`char`varchar`tinyint`smallint`bigint,t)!`symbol`symbol`byte`short`long,t:`int`real`float`date`time`datetime
col:{(p;x;$[`references~r j+:p:`primary~r j+:3*`symbol=t:tt i n[];i n[];t])};ins:{x insert*:'*+0N 2#3_r;}
cre:{n[];c:+p l col;.[x;();:;(+/*c)!+c[1]!c[2]$\:()];};upd:{![x;wh[];0b;(!).+l[{|(a n[];i x)}]n[]]};del:{'`nyi}
jn:{if[~1=#r:$[1=#x;x;x@&~b:1={$[98=@x:. x;0;#+!x]}'x];'`join];r:*r;x@:&b;e:1_'y@&b:{$[~(=)~*x;0b;11=@x:1_x]}'y
 y@:&~b;a:e@'b:e[;0]in c:{`/:x,*!+!. x}'x;b:e@'~b;(+(r,x)!(,r!!#. r),x$.:'a b?c;y,(=),'e@&~b in c)}
nm:{$[1<#x;nm x 1;-11=@x;*|`\:x;`x]};m:{(!).+l[{($[(x:r j)in(::;","),``from`where`group`order;nm y;i x];y:x y)}x]y}
sel:{s:$[(*)~x:r j+:d:(?:)~x;i();m[a]x];e:j;@[`.;x:!x;:;.:'. x:m[i]n[]];e=:j-2;w:wh[];g:#b[`group]l i;
 x:(?).$[e;(.*x;w);jn[x]w],(g:$[g;g#s;d];g_s);$[(o~!g)|~#o:b[`order]l i;x;.q.xasc[o]x]}

Without referring to the original or doing a diff, tell me which character I changed.
Art Wilkins
Monday, December 05, 2005
 
 
Art - you need to get a new modem.  Yours is obviously going bad.

;-)
example Send private email
Monday, December 05, 2005
 
 
I'd just download hsqldb. Why re-invent this particular wheel?
Codeless
Monday, December 05, 2005
 
 
Since more than half of code's cost is in maintenance, Ori has failed to show why these highly terse solutions are actually superior in the long run. They may be, but I see no evidence of it.

A superstar engineer also makes his work accessable to those who don't spend all day thinking about some specific technology. I see this over and over again, engineers who are great at dealing with complexity and reducing into some sort of conceptual framework that they find much easier to deal with. But they don't considers other people's ways of thinking and those people's lack of desire to put effort into learning other ways of thinking.  They don't understand that people don't want to both learn about the problem and your way of understanding it. So they have these beautiful, pure, symetric, etc. systems that are all but inpenetrable to others, because they don't bridge people's inherent conceptual gap. And when people don't "get" you, they ignore you. And worse than being buggy, slow, bloated or whatever is being ignored.
ronk!
Monday, December 05, 2005
 
 
Did somebody already say 'line noise'? And to think I struggled with the move between BASIC syntax and C. I'm quite obviously no superstar. The only thing missing from that is colour (as in ColorForth: http://www.colorforth.com/cf.html ). This could just as easily be written in http://www.muppetlabs.com/~breadbox/bf/
Ron Porter Send private email
Monday, December 05, 2005
 
 
Ori-

Are you saying that (1) anyone can be a superstar programmer if they use the right language or (2) only superstar programmers use (and can understand) the best langauges? Your post is unclear on which point you are trying to make.

Count in me as someone who didn't know what requirements you were trying to fulfil. And since I couldn't read the K code I had no idea how narrow they were. Judging from Per's Python re-implementation, I am quite underwhelmed. That's all you want done for the 'SQL Engine'? Jeez. No wonder it took only a day. Most programmers could have done that in a day.

Per Vognsen is the superstar programmer. He had the intelligence/perseverance to decipher your requirements/K code and the sense not to use the K language (and of course, examples!).
slava Send private email
Monday, December 05, 2005
 
 
Yeah, does anyone get these crazy upstart languages that people are always trying to foist on us?

I hear Wal-Mart's trying to get all Americans to learn this one -- good luck!

親士第一

入國而不存其士,則亡國矣。見賢而不急,則緩其君矣。非賢無急,非士無與慮國,緩賢忘士,而能以其國存者,未曾有也。昔者文公出走而正天下,桓公去國而霸諸俟,越王句踐遇吳王之醜,而尚攝中國之賢君,三子之能達名成功於天下也,皆於其國抑而大醜也。太上無敗,其次敗而有以成,此之謂用民。吾聞之曰:「非無安居也,我無安心也。非無足財也,我無足心也。」是故君子自難而易彼,眾人自易而難彼。君子進不敗其志,內究其情,雖雜庸民,終無怨心,彼有自信者也。是故為其所難者,必得其所欲焉,未聞為其所欲,而免其所惡者也。是故偪臣傷君,諂下傷上,君必有弗弗之臣,上必有詻詻之下。分議者延延,而支苟者詻詻,焉可以長生保國。臣下重其爵位而不言,近臣則喑,遠臣則噤[口+金],怨結於民心,諂諛在側,善議障塞,則國危矣。桀紂不以其無天下之士邪?殺其身而喪天下。故曰:歸國寶,不若獻賢而進士。


You think that's weird? I don't know whether this one's coming or going!

אי שם בשנות התשעים, כשהצרכנים בעולם המערבי החלו לגלות את היתרונות הטמונים במוצרים ידידותיים לסביבה, החלה להתגבש תודעה צרכנית שגילתה אכפתיות כלפי המרכיבים מהם עשויים המוצרים, התנאים בהם הם יוצרו וההשפעות שיש לייצור שלהם על הסביבה והחברה. התודעה הזו שהיוותה את אחד ממנועי הצמיחה החשובים של תחומים כמו מזון אורגני דחפה קדימה מאוחר יותר גם את האופנה הירוקה. אם בשלב הראשון לאנשים היה איכפת ממה שהם מכניסים לגופם, הרי שבשלב הבא, הם גם נהיו אכפתיים כלפי הבגדים שהם לובשים. כאן נזרעו הזרעים של האופנה הירוקה.

(Oy vey, what a backwards language. Reading that makes me dizzy as a dreidel.)


No thank you -- these languages had thousands of years to dominate the world, and so far I'm pretty sure no one gets paid to use them. We can only assume there must be something wrong with their user communities.
Tayssir John Gabbour Send private email
Monday, December 05, 2005
 
 
Tayssir, I'm not sure of your point. Since you're a pretty bright guy, I'll assume I'm missing it. Care to elaborate?
ronk!
Monday, December 05, 2005
 
 
Ori, can you point to one or three wall street operations that are betting the farm on this? All the wall street operations I know are still betting the farm on overloaded excel spreadsheets.

I'm not sure why this is interesting. Isn't K just APL++ ?
wall street programmer
Monday, December 05, 2005
 
 
Probably bad to assume I'm making sense to anyone other than myself. ;)

I think things like K are interesting because there's something useful to seeing concepts that visually small on the page. Alan Kay points out [1] that people generally hold maybe a screen or 1.5 screens in their mental buffer. (If I recall correctly.) If people get past the exotic appearance and learn the terse syntax, they may gain an "intelligence boost."

I would be interested in something which converts code between verbose and terse forms... I don't know whether it would work but it'd be interesting.

[1]: http://www.archive.org/details/AlanKeyD1987_2
Tayssir John Gabbour Send private email
Monday, December 05, 2005
 
 
Isn't this the same old argument that we've had a million times?

- language x is better because it's more terse (Lisp camp)
- language y is better because it's easier to read (C++, Java)

History seems to favor camp Y, but it seems obvious to me that smart people are too smart to have this argument.
Sassy Send private email
Monday, December 05, 2005
 
 
Taysir,

Lots of people are getting paid to write in those languages.  They're called Journalists, or sometimes Authors.
Clay Dowling Send private email
Monday, December 05, 2005
 
 
Women are smart. Men suck at being smart. Which one would optimize a programming language in its syntax? Men. Which one would create complexity to be solved with visual tools like with powerful IDEs and specific editors (Emacs, XML Editor, etc)? Men. Which one would create as many programs from scratch as needed? Men. Which one would care less about the customers? Men...

Women rule!
Johnny
Monday, December 05, 2005
 
 
"Alan Kay points out [1] that people generally hold maybe a screen or 1.5 screens in their mental buffer."

K is simply compression.  A bet people can hold more Java screens in their mental buffer than K code.  It's the information that matters, not the representation. 

Why do programmers use whitespace, indenting, and long variable names?  To make easier to read.  To create visual distinctions.  K has very litte visual distinction.

Some of the shortcuts in K make very little sense for any real development.  For example, it has implicit function parameters named x, y, and z -- when was the last time anyone here ever coded a function parameter named x?  You  don't because it contains no semantic information at all.  If anything, K has compressed out all the useful information that *humans* need to understand what the software is doing.  What does x stand for?  Well I need another memory slot in my brain to hold that information when I simply could be explicit and say, for example, numCarrots.
Almost H. Anonymous Send private email
Monday, December 05, 2005
 
 
See?  My assertion is correct.  K was a language invented by slashdot style trolls.  It's not a real language but an inventive way to spark of a classic language war.

I mean, you really can't prove that the so called "K" "program" was just a sample of base64 encoded random noise from the original poster's geiger counter, can you?
message generated by radioactive decay
Monday, December 05, 2005
 
 
No, no, no.  I think Johnny is on the right track.  K was invented by women to keep men continuously busy with language wars so we're out of the way and they can get the real work done.
Almost H. Anonymous Send private email
Monday, December 05, 2005
 
 
What real work? Programming? That's going to be real only if you work for somebody that does value your work and compensates you for it. Life is too short to waste it from job to job, creating new programs and maintaining other people's programs.

Men try everything, so it's not a surprise when a few of them succeed. Or would a feminine version of Bill Gates drop out of Harvard?

I don't know if you remember that Erik Sink seems to value women a lot as work professionals.

Women are "good enough" most of the time.
Johnny
Monday, December 05, 2005
 
 
The last time I looked, Kdb did not have any of the ACID properties that would make it a true "relational" DBMS. 

This makes Kdb really useful for read-only applications (e.g., analyzing large quantities of tick data very quickly), but much less useful for transactional applications (e.g., order and trade management).
BillT Send private email
Monday, December 05, 2005
 
 
I think anyone who is serious about programming should be open to learning new languages. Even if you are never going to use them to write a single line of production code, there are languages that can teach you a lot about programming, even if you stick to C or Java for the rest of your days.

When I say "learning new languages" I really mean learning them to such an extent that you are able to write idiomatic code. I've met quite a few people who think they've "learned" Scheme, but in reality they're still just writing C code in Scheme (if that makes sense). This is unfortunate since they miss out on crucial insights and "aha" experiences. Speaking for myself, I know that I am only able to achieve those once I am able to write fairly idiomatic code in a language.

On the topic of K, specifically: I think K has some very interesting ideas, and if you are a programming language geek that's really all the reason you need to study it. It's been in my queue for a while (along with other lesser known languages), and one of these days I'll get around to it.
Per Vognsen Send private email
Monday, December 05, 2005
 
 
"people generally hold maybe a screen or 1.5 screens in their mental buffer"

THat's exactly why you should print out all your programs in 0.04 pt font.
Art Wilkins
Monday, December 05, 2005
 
 
"I would be interested in something which converts code between verbose and terse forms."

I have something that will do that for you. It's called a compiler. I put easy to read C in one end and verse terse machine language comes out the other end.
Art Wilkins
Monday, December 05, 2005
 
 
BillT,

What you write is correct, the last time I looked (I played with K I thin about 7 years ago).

It  has not got conventional ACID-properties, but there was hardly any need. Operations were so fast, that they just did not allow any concurrency and sequentialised all queries. They said it did not hurt user-perceived performance. Also the use of an in-memory database makes things a lot simpler and removes a lot of the need for ACID.

Notice how these two effects strengthen each other. Raw performance makes many precautions unncessary, thereby, increasing performance even more.
Karel Thönissen Send private email
Monday, December 05, 2005
 
 
>>> K is simply compression.

How wrong. Use the language for ten minutes and we will talk again. [Unfortunately, I think they took the free demo off-line] I was really impressed. Productivity sky-rocketed. K is not about replacing keywords with punctuation, it is about a very clean language design where operators (adverbs') can be combined with other operators ('verbs') giving modified 'verbs'. That system is regular, thus making it very simple to think in terms of higher-order functions.

>>> A bet people can hold more Java screens in their mental buffer than K code.  It's the information that matters, not the representation.

More Java-screens is probably true. But their mental buffer for K can hold a larger percentage of the entire application.

>>> Why do programmers use whitespace, indenting, and long variable names?  To make easier to read.  To create visual distinctions.  K has very litte visual distinction.

Do not agree. The lack of distinction is caused by Whitneys personal style, it is not demanded by K.

>>> Some of the shortcuts in K make very little sense for any real development.  For example, it has implicit function parameters named x, y, and z -- when was the last time anyone here ever coded a function parameter named x?

That is not a bad practice for higher-order functions, e.g. lambda-functions. I guess you are coming from a procedural background (and most object-oriented languages are procedural) where such naming conventions usually are a bad practice.

If I were to use K these days, my coding style would differ from Mr. Whitney's. It would be less terse in its identifiers. So maybe my K-code would be 3 times as large. It would have meaningful identifiers and use the very-high-level functions of K. The code would be a joy to read. So now we are not comparing 30:30_000, but 100:30_000.
Karel Thönissen Send private email
Monday, December 05, 2005
 
 
If you look at a C compiler's output, you'll discover that it's not terse at all.
rob mayoff
Monday, December 05, 2005
 
 
"K is not about replacing keywords with punctuation, it is about a very clean language design where operators (adverbs') can be combined with other operators ('verbs') giving modified 'verbs'."

That feature is not unique to K.  Many languages have that ability (and I've coded in a few).  However, none of them appear as terse as K. 

Per Vognsen's Python translation of that K application is much easier to understand as equally as functional.  Other languages manage the same capabilities without replacing keywords with punctuation or have implicit function parameters that exist only to make the source code physically smaller.
Almost H. Anonymous Send private email
Monday, December 05, 2005
 
 
Karel-

I think you and Ori haven't convinced people that it would take 30000 lines of C or Java code to write what those 30 (or 100) lines of K code do. Because: (a) not really sure what those 30 lines do (there should be some comments don't you think, even in a 30 line program), (b) I think the /SQL Engine/ description was highly hyperbolized (it looks like the programmer is just using a object/hash table with access methods, there's no SQL anything).

Programmers can believe a one order of magnitude difference (though how much of that is syntactic density rather than real power is an open question), but not a three orders of magnitude difference in productivity. A 1000 times more productive! That's the claim. No way. Rome wasn't built in a day. Programming improvements will come one order of magnitude at a time.
YaYaYa Send private email
Monday, December 05, 2005
 
 
YaYaYa,

>>> I think you and Ori haven't convinced people that it would take 30000 lines of C or Java code to write what those 30 (or 100) lines of K code do.

You are problably right, but I am not going to make my job of trying to do this. I remember being able to write in less than 10 characters what otherwise would take hundreds of lines in a conventional language. The resulting K was very readable, because it used very-high-level concepts.

Regarding my guestimate of 30_000 lines of code. It is a guess, but I might add that I have worked on more than one language design and compiler. At Garabit we are developing the Carmen-programming language right now and in the past I worked on database query languages.

May I observe that I was the only one in this entire thread that gave an estimate /at all/? So if you or others do a relational engine and a parser in less lines of code, please enlighten us. From experience I know all to well how difficult it is to make correct guesses. Unfortunately, I was always on the low side )-8.

>>> Because: (a) not really sure what those 30 lines do (there should be some comments don't you think, even in a 30 line program), (b) I think the /SQL Engine/ description was highly hyperbolized (it looks like the programmer is just using a object/hash table with access methods, there's no SQL anything).

I looked into it (remember it was 7 years or so ago), but as far as I can tell this is a complete relational engine and a complete SQL-parser.

BTW, there are many comments! In the first example, more than half of the code is comment and/or example!

>>> Programmers can believe a one order of magnitude difference...

Sad but true.

...(though how much of that is syntactic density rather than real power is an open question), but not a three orders of magnitude difference in productivity. A 1000 times more productive! That's the claim. No way. Rome wasn't built in a day. Programming improvements will come one order of magnitude at a time.

This is a widely held belief that is simply untrue.

Another widely held belief that is untrue that was tackled in K: sorting a collection of numbers in linear time. Yes, you read correctly, linear, not log-linear time.
Karel Thönissen Send private email
Monday, December 05, 2005
 
 
"I looked into it (remember it was 7 years or so ago), but as far as I can tell this is a complete relational engine and a complete SQL-parser."

The SQL parser code posted is (by Ori's own words) not related to Stevan's relational back-end; I cannot comment on KDB's back-end as I have not seen its source code. What _has_ been posted is Stevan's back-end code, and there is nothing "complete" about it. Sorry.

"BTW, there are many comments! In the first example, more than half of the code is comment and/or example!"

Indeed, the comments are how I extracted the spec (hopefully accurately) of the various functions. The example in the code is fairly bad in that it doesn't exercise all of the defined functions, but it is better than nothing.

"Another widely held belief that is untrue that was tackled in K: sorting a collection of numbers in linear time. Yes, you read correctly, linear, not log-linear time."

I'll take "numbers" to mean integer or floating-point numbers. For fixed-precision integers there is radix-sort, which has linear run-time. For fixed-precision IEEE floating-point numbers, there is a simple and well-known transformation floating-point that lets you apply radix-sort directly. Not sure what the problem is...
Per Vognsen Send private email
Monday, December 05, 2005
 
 
Peter, there is no problem. Read my post correctly, I did not even write there was one.

This is about people unable to change their beliefs. Ori started about SEP-fields, remember, and look how people jumped on to it, without having used or properly studied the language. The idee fixe about sorting was just another example. You just gave away the clue, BTW. Most people think it is impossible, because that is what they learned in university, unaware of the assumptions behind the discussions of time and space complexity.
Karel Thönissen Send private email
Monday, December 05, 2005
 
 
"Peter, there is no problem. Read my post correctly, I did not even write there was one."

You mentioned linear-time sorting as something that K had achieved. When I said "not sure what the problem is" I was expressing my inability to see the problem that K, specifically, solves in this context.
Per Vognsen Send private email
Monday, December 05, 2005
 
 
"Per Vognsen's Python translation of that K application is much easier to understand as equally as functional."

BTW, just to clear up any potential confusion: my Python code is not actually a translation of the K code--I don't know how to read K! Rather, it's an implementation based on the comments in the K code that describe the contracts of the various functions.
Per Vognsen Send private email
Monday, December 05, 2005
 
 
Karel:
> Another widely held belief that is untrue that was tackled in K: sorting a collection of numbers in linear time.

Are you claiming that this linearly sorting algorithm is language-specific? Can only done in K? (If not true, why is this statement relevant to the K language discussion?)

Look: the more outlandish and unproven claims (1000 times more productive! with unique algorithms! closer to natural language! slices tin cans!) that are piled up in the language's defense, the more skeptical people become.
YaYaYa Send private email
Monday, December 05, 2005
 
 
"I remember being able to write in less than 10 characters what otherwise would take hundreds of lines in a conventional language."

This, I'd like to see!
Almost H. Anonymous Send private email
Monday, December 05, 2005
 
 
>>> Are you claiming that this linearly sorting algorithm is language-specific? Can only done in K?

Please show me the location where I wrote that.

>>> (If not true, why is this statement relevant to the K language discussion?)

I already explained that explicitly.

>>> Look: the more outlandish and unproven claims (1000 times more productive! with unique algorithms! closer to natural language! slices tin cans!) that are piled up in the language's defense, the more skeptical people become.

Sure. But first people should carefully read what others write (not just talking to you), then they should do a little research before shooting messengers.

But please, do not put words in my mouth.

I reiterate my question: how much do others think a relation engine plus SQP-parser takes?
Karel Thönissen Send private email
Monday, December 05, 2005
 
 
>This, I'd like to see!

APL sometimes come close if a task is in its domain.

Look at the Wikipedia article on APL they have a one-liner to computer all primes less than a given number, about 10 to 15 characters.
dot for this one
Monday, December 05, 2005
 
 
Well, I'd like to see something "useful"!  I could easily create my own programming language that computes Pi to 300 million places and it only has instruction:

compute_pi_places(300,000,000);

But that's hardly a great example. 

Every language excels at one limited thing or another.  In VB, I can create a window that says "Hello World" in zero lines of code.  Given that example you might think that VB is some hyper-productive language!  I bet K takes many more lines of code to do the same thing!
Almost H. Anonymous Send private email
Monday, December 05, 2005
 
 
So for a recap:

Per's code, unit tests, and carefully-phrased arguments appear to have caused Ori to seize-up completely and stop posting. And Per has forced Karel into an ever more extreme corner in an attempt to justify his position.

This looks like bullshit, sounds like bullshit, and feels like bullshit. I'm pretty convinced that it's not chocolate mousse with a strange texture.
Mark Pearce Send private email
Monday, December 05, 2005
 
 
"Without referring to the original or doing a diff, tell me which character I changed."

OK, I gave you K wonkers all day to answer this and you couldn't. Your bluff is called. You guys don't know K at all and this is all a bunch of BS.
Art Wilkins
Monday, December 05, 2005
 
 
>>> Well, I'd like to see something "useful"! 

So an SQL-implementation on top of a lightning fast database engine is not useful???

>>> I could easily create my own programming language that computes Pi to 300 million places and it only has instruction:

>>> compute_pi_places(300,000,000);

>>> But that's hardly a great example.

Now that was great fun.

>>> Every language excels at one limited thing or another.  In VB, I can create a window that says "Hello World" in zero lines of code.  Given that example you might think that VB is some hyper-productive language!  I bet K takes many more lines of code to do the same thing!

Yes, it would take a single statement in K. Total weight: +- 200 kB for the interpreter/environment (data from 1998 white paper) plus a few bytes for the source code. How much weighs VB? Or VB as of 1998?

For your information: K generated user interfaces on the fly, using a single line of code, using its capabilities as a list manipulation language. Can you in VB?

Again all this information from the 1998/1999 manuals. I am not sure whether these are still on-line.
Karel Thönissen Send private email
Monday, December 05, 2005
 
 
Art,

Here I have 10_000 lines of parser code. I have hidden 10 bugs, just to make it easier for you. Can you please find one?

I think your reaction is very childish and ad hominem. I played with K 7 years ago, why do you think I solve your stupid puzzles instantly? My time is too expensive to be wasted on you. You solve your own problems. I think you have enough of those.

This ends my contribution to this thread. Ori was right some people are unable to step over their own disbelief. I looked up data in manuals, told about my experience then as a user, as a language designer/ implementer and as a researcher (in this area for X-sake), but you Art and others had nothing substantial to say, other than 'that cannot be true, let us ridicule the messengers'. No one even hinted at how many lines of code their implementation would be. You came with silly puzzles.

I thank some people for their serious contribution.

Bye bye. See you all some day in some other thread.
Karel Thönissen Send private email
Monday, December 05, 2005
 
 
"So an SQL-implementation on top of a lightning fast database engine is not useful???"

The original quote that got this started, was yours, and it's this:

"I remember being able to write in less than 10 characters what otherwise would take hundreds of lines in a conventional language."

I suspect the SQL-implementation is more than 10 characters. 

So we've come full circle. 

Hurray.
Almost H. Anonymous Send private email
Monday, December 05, 2005
 
 
"K is not about replacing keywords with punctuation, it is about a very clean language design where operators (adverbs') can be combined with other operators ('verbs') giving modified 'verbs'."


I think that you mean "operators" in a higher-sense, but do you realize that pretty much every language i've EVERY worked with-- even scripting languages-- offer this.


$msg_body .= "\nShane";
Shane Harter Send private email
Monday, December 05, 2005
 
 
Mark, Art: Some people have a life, and believe it or not live in a different timezone. Much as I'd love to spend 24 hours a day waiting for Americans to post and reply, I have other things to do.

To address some points:

Per's version is very similar to Stevan's, with one huge difference - Stevan's stores data in column-major (fortran) order wher as Per's is row-major (everything else).
Per's is slightly less capable (e.g on multicolumn select or sort), but still an excellent implementation. The speed difference between the Python implementation and the K implementation will probably come to 1:10000, mostly because essentially, _all_ the loops in Stevan's code are implemented as tight C loops over the entire array. (And, quite a lot of K's speed comes from efficient use of code and data memory, which gives it a 10-fold to 20-fold advantage in almost everything -- L1 cache is _that_ much faster than memory).

Stevan's version is apparently well commented, as Per was able to reproduce the functionality from ~10 lines of comments and ignoring the code completely.

I had two points to make when I made the post: That there publicly visible examples of superstar programmers (A proposition that had been contested on this forum two weeks ago), and that there's a SEP field on software technologies. I have failed in convincing you readers of teh first point, but it seems this thread is a living proof of the second.

http://en.wikipedia.org/wiki/SEP_field

K gets the same kind of response Lisp does, just more extreme; I suspect its because K is more extreme. But I could have used Lisp instead in my example, dropping the time and line-count ratio by an order of magnitude, and _still_ gotten essentially the same response. (Except from Tayssir, I think). Any Lisper has gotten this response, except a substitution of "line noise" with "all these cluttered parentheses". It's still a SEP field reaction though, as the parentheses-lacking Lisps (Dylan, Pliant) are only getting any apprciations from Lispers.

RE: K users -- "wall street is betting the farm" is, perhaps, a bit extreme. I know (from personal acquaintance and communication) of at least two medium sized Wall Street companies whose entire operation is based on kdb, and of ~ten others who have significant reliance and investment in kdb. Kx systems will be glad to supply more info, but I'm not at leisure to. AFAIK Island (now INET) had very significant K infrastructure before the merger; Not sure about the present. K indeed is an "refined APL". It has much _less_ built in / primitive operations, but programs still come out more terse.

Re kdb: kdb itself (obviously not as small as Stevan's 12 line engine) is ACID, replicated, hot backup and everything.

Tayssir: One of your "weird language" quotes is hebrew, my mother tongue. It's only "functional" advantage, as far as I can tell, is that I can read the bible untranslated, if that is an advantage at all. It has the pragmatic disadvantage of having ~20 million readers worldwide ~6 million of which are fluent. Kanji, on the other hand, is different - [disclaimer: I may be mixing terms] I've spoken to Japanease who can read a book in Kanji (ideographic symbols) ~10 times as fast as they can read the equivalent  Kana (phonetic symbols) and prefer even though it takes much more concentration. This is a significant *functional* advantage, which is analog to K/APL's advantage in software engineering.

Ori.
Ori Berger
Tuesday, December 06, 2005
 
 
hint: if people don't worship the coding nirvana you walk in, then you're not a superstar programmer. And if you try to convince people of the opposite, you're a wierdo.

Sometimes, when everybody around you says you're wrong, they could be on to something.

"and that there's a SEP field on software technologies. I have failed in convincing you readers of teh first point, but it seems this thread is a living proof of the second."
That works both ways I'm afraid.

But hey, if it works for you, go ahead. More power to you. Good luck. Come back in a year or two, and let me know how it went.
Dave
Tuesday, December 06, 2005
 
 
that is chinese, not japanese
hi
Tuesday, December 06, 2005
 
 
All very cool stuff. But a real superstar progammer could write a SQL Engine in Brainfuck:

 http://en.wikipedia.org/wiki/Brainfuck

AND make it look like an ascii art picture of Bill Gates handing over the check to Sybase...
Gordon Taylor Send private email
Tuesday, December 06, 2005
 
 
>> I had two points to make when I made the post: That there publicly visible examples of superstar programmers (A proposition that had been contested on this forum two weeks ago), and that there's a SEP field on software technologies. I have failed in convincing you readers of teh first point, but it seems this thread is a living proof of the second. <<

For any given definition of the term "programmer superstar", there are certainly publicly visible examples. The trouble is that there are as many different definitions of this term as there are definitions of "happiness". So it doesn't make sense to discusss this subject without endless assumptions, caveats, and ever more precise definitions. But your original argument in this thread didn't really have any of these.

SEP is a very convenient device for categorising a group of people as not having reached a certain higher level of awareness, or conciousness. Hubbard and Scientology spring to mind here. But in a forum of skeptical hardcore developers, you're going to have to come up with a much better argument than just shouting "SEP" over and over again.

When it's you and Karel against the world, I'm betting on the world.
Mark Pearce Send private email
Tuesday, December 06, 2005
 
 
To make sure I clarify myself, I think calling K unreadable is like calling Chinese or Hebrew text unreadable. Just because I find them exotic, or one currently has fewer users, doesn't mean they're inferior. And it's not to say they're superior either; but there's little point in me being some binary ACCEPT/REJECT automaton.

When I become such an automaton without good reason, it's often a mistake.

I mean ideally when faced with new things, I'd just listen and may ask questions, and not try filtering with the mindset of "This isn't useful to me now, therefore I will store this in my mind with a big ol' REJECT flag."

The history and tradition of tech is multifaceted.. to say "I'm of the Java martial arts school" is to reject your own intellectual heritage. Similar immediate mental rejections of anything which isn't English is to reject your own human heritage.

But... the big reason I think there's real pushback is because this topic is maybe phrased as, "Talented people do..." which I think always stirs a little bad blood, and I'm not sure I'd like to phrase it in those terms.
Tayssir John Gabbour Send private email
Tuesday, December 06, 2005
 
 
"But... the big reason I think there's real pushback is because this topic is maybe phrased as, "Talented people do..." which I think always stirs a little bad blood, and I'm not sure I'd like to phrase it in those terms."

Exactly so. Rereading the post that started this, it looks like the OP had a chip on his shoulder from the beginning. The whole post reads like "Those of us who do X, Y, and Z are more capable than the rest of you because we do X, Y, and Z. Not only can you not do X, Y, and Z, you're too ignorant to realize that X, Y, and Z are worth doing". It's no surprise that most of us did not agree with the OP's point. That the OP based his arguments around an obscure language with no freely available documentation or interpreter is just icing on the cake.

We have been trolled.
comp.lang.c refugee
Tuesday, December 06, 2005
 
 
Clay Dowling,

I think you're missing Taysir's point.  Sure journalists and writers have made money writing in Chinese and (excuse me) whatever that other written language is.  I think Taysir is making the point that the most significant scientific and engineering advances in the history of the world have been communicated in English and other Indo-European language because of their clarity, readability, and ease to learn... meaning that you get participation from lower classes of people enabling over time upward mobility.
vic
Tuesday, December 06, 2005
 
 
Turing Car
Tuesday, December 06, 2005
 
 
What I wonder what is it that the OP is trying to assert. Is it that the programmers that were sited are superstars because they wrote implementations using a small amount of code? Is it that they were able to write the code in K? Or is both?

First I think what got to some here is the measuring by lines of code. Comparing lines of code in K to other more commonly used languages is an inbalanced comparison. K appears to be designed specifically to get a lot done in few keystrokes and as efficiently as possible. That has more to do with being well versed in the programming language being used than with being a superstar programmer. Atleast if you're going to compare that to someone else using another another language.

By that type of understanding it's like stating that someone who writes in Kanjii is a superstar writer because they used a smaller amount of space than someone who wrote the same thing in English.

I'm sure the two programmers are very talented and intelligent and maybe what everyone can agree on as superstars but not based on the examples given here. It proves that have a high level of understanding of K, and the field they're coding in.

Personally I don't think coding without whitespace makes you a superstar, just a little faster. Code should be easily readable by anyone who knows the language. Notice I didn't say understandable but readable. Most of us here can read an English law book (or any other book outside our field) but how many can understand it easily?
Jason T.
Tuesday, December 06, 2005
 
 
Turing Car, I see documentation on that page for Kdb+, Q, Kdb+tick, and Kdb+taq but not the K language. What am I mising?
comp.lang.c refugee
Tuesday, December 06, 2005
 
 
comp.lang.c refugee, I used to also have a big chip on my shoulder. I still do in fact, but anger management therapy helps. ;)

(Boring personality stuff: Personally, I don't think Ori's a troll; his points are almost uniformly interesting to me, and in fact I haven't clicked on any other topics on the main forum page. Even if he's indeed a troll, which I don't think he is (but I suck at troll detection), he's better than that Art Wilkins fellow, who isn't even that funny.)

I think if you watch that Sussman vid mentioned earlier, Sussman explains there are a couple classes of techies. One is the higher-class theoretical kind. They tend to believe in the "talent theory of knowledge": people are born with talent and you try to filter them into scientists, artists or whatever.

Then there's the lower-class engineers, who have a different background from European crafts guilds, who believe more in a "skill theory of knowledge". Since the guild craftsmen might not live to see some cathedral completely built, they had to believe that you can teach people how to think about and solve problems. Sussman opined that this seems a more effective way to structure a society than the talent theory.

Now the problem is, when small companies are competing each other bloody, you tend to favor people with higher productivity (of a certain kind). That's where the superstar/talent thing comes in, and I find some resulting attitudes artificial and a bit ugly. Like models who feel awful they don't look as good in real life as they do on TV, I think programmers unproductively wrestle with personal esteem issues.

And so when you try to have openminded conversations, and suddenly a negative wall of cheap rejectionism bursts up, it is so... so easy to tickle the sore "Well superstars do this" thing. "Superstars know what I'm talking about."



And I have to admit, I'm sorta embarrassed that I posted here, as I perceive such willfull misconstruing of other people's points... and I kinda wish my posts were deleted. Because I'm disturbed that my stupid little jokes will seriously be misconstrued into nationalist anti-Chinese anti-Hebrew points, that I will just face responses who'll just claim the worst of my intentions.. and with politics it's ok but in techie issues for some reason I feel like vomiting.

Enough long-ass posts from me, I'm taking a walk.
Tayssir John Gabbour Send private email
Tuesday, December 06, 2005
 
 
Regardless of the original point of the OP, there are two  misconceptions that have been posted above.

First APL, J, and K are all general purpose, very high level, programming languages. APL ( www.dyalog.com ), is the most commercially complete, with .NET and GUI support, an IDE etc, and is applied to a very wide range of corporate computing problems.  J is free, comes with lots of sample code (labs) and available at www.jsoftware.com .  K’s general purpose-ness is masked by its pricing, and perhaps by its creator’s inimitable coding style. J and K are more terse than APL, but that’s like saying a BMW 545 is faster than a BMW 540.   

Second, terse languages do not necessarily imply terse code. For example, APL has a single symbol that looks like a domino that inverts a matrix. It does not follow that all functions, or methods, or classes,  that are written in APL should have one character names. Somewhat unfortunately (I think) the main exponents of K and J (and many APL programmers) are often enamored of single character names and long one-liners. For a completely different coding style than what you saw above, see www.flipdb.com, (my site) for the implementation of the relational model in APL. You can browse all the source code.       

APL is often called a “tool of thought.” It allows you to think and code at a very high level. It would be quite useful if computers did not exist, and indeed was invented as a mathematical notation, not as a computer language.

The arguments for terseness and high level languages are already well written about by Paul Graham and others.

Here is a small APL example. Consider a vector A with five items: 1 3 5 7 9. Then:

+\A

1 4 9 16 25

where:

+  is a primitive function
\  is  a primitive operator
+\ is a derived function, know idiomatically as “running sum”

APL allows you to program with no loops, which often makes things much easier to code and debug.  K and J work more or less the same way.

While I am a working APL programmer, and wouldn’t use anything else, I will say that in the whole superstar programmer argument, I have come to the conclusion that the choice of language is completely swamped by the talent of the programmer. In other words, a true superstar working in, say, Assembler is better than just about anyone else in APL, Lisp, K, or whatever. Of course, as Graham notes, a top programmer, stuck in a low level language with a high level problem, will just implement something like APL, K,  or Lisp!
Paul Mansour Send private email
Tuesday, December 06, 2005
 
 
Okay, that's just not fair.  You tempt us with this new language and yet we can't play with it?  Where, oh where is an implementation, or heck, even a reference/guide to this language?  It seems, from previous comments, that kx.com has removed it?  And it seems that Kuro5hin is down for a bit at least.  Does anyone know where to get an implementation?

And yes, I've googled, and come across some interesting tidbits, but not found any implementation.
J.K.
Tuesday, December 06, 2005
 
 
"Because I'm disturbed that my stupid little jokes will seriously be misconstrued into nationalist anti-Chinese anti-Hebrew points, that I will just face responses who'll just claim the worst of my intentions.."

Bullshit.

Or is it? YOU CAN'T BE SERIOUS.

BTW, where does that passage come from?

I am sure nowadays 99.99% of journalist don't understand that passage :(
Rick Tang Send private email
Tuesday, December 06, 2005
 
 
"APL allows you to program with no loops, which often makes things much easier to code and debug.  K and J work more or less the same way."

Functional programmers use folds left and right (pun intended), so this isn't unique to the APL family of languages. By not restricting themselves to arrays, they also discovered elegant and powerful generalizations that are useful in the context of arbitrary recursive data types. The classic reference on this is Erik Meijer's Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire.

I am a fan of terseness, but so far I am not convinced that K offers abstractions that are unavailable or inconvenient to use in other languages. In private communication Ori has offered to provide me with some examples, so I hope that leads to enlightenment. In any case I am planning on learning K eventually, if only for the challenge and the guilty pleasure I take occasionally in writing cute hacks.

BTW, someone mentioned the isprime K one-liner from the Shallow Introduction; it turns out it is easily transliterated into equivalent Python or Haskell one-liners. In Haskell,

isPrime n = all [n `mod` d == 0 | d <- [2..n]]

and in Python 2.5

def isprime(n): return all(n % d == 0 for d in range(2, n))

Both involve identical structures to the K solution; both are idiomatic in their respective languages.
Per Vognsen Send private email
Tuesday, December 06, 2005
 
 
> BTW, someone mentioned the isprime K
> one-liner from the Shallow Introduction;
> it turns out it is easily transliterated into
> equivalent Python or Haskell one-liners.
> In Haskell,

> isPrime n = all [n `mod` d == 0 | d <- [2..n]]

Erm, a prime number is one that does _not_
have any factors other than 1 and itself.
Unlike ranges in python, ranges in Haskell are
inclusive. Also the type of 'all' is

  (a -> Bool) -> [a] -> Bool

So the definition required is actually;

  isPrime n = all id [n `mod` d /= 0 | d <- [2..n-1]]

or more simply

  isPrime n = and [n `mod` d /= 0 | d <- [2..n-1]]
Julian
Tuesday, December 06, 2005
 
 
Another database engine:

 http://www.equi4.com/metakit.html

Remind me of the Knuth/Bentley/McIlroy incident.
Rick Tang Send private email
Tuesday, December 06, 2005
 
 
"Both involve identical structures to the K solution; both are idiomatic in their respective languages."

Oops! In both examples, I had of course intended == to be !=.
Per Vognsen Send private email
Tuesday, December 06, 2005
 
 
As far as the "running sum" APL example is concerned, the ONLY (arguable) advantage that has over the standard equivalents in other modern programming languages is that it's conciser.

APL:
  +\A

Haskell:
  fold (+) a

Haskell, APL style to make the equivalence blatant:
  (+) `fold` a

So APL saves you a little typing.  Period.
Iago
Wednesday, December 07, 2005
 
 
Gah, forgot my Haskell syntax.  I mean, of course:
  foldl (+) 0 a

Which is in fact more flexible than the APL, because you can choose to start from a different total than 0 if you want to.
Iago
Wednesday, December 07, 2005
 
 
John Griffiths Send private email
Wednesday, December 07, 2005
 
 
Ori and Karel have left a number of claims on the table. The easily quantifiable ones were that: K is 300-1000 more productive in terms of LOC than your-run-of-the-mill language (no one's putting words in Karel's mouth that weren't there already; see 30 to 30000 comparison above) and Ori's that K is 10000 times faster (or faster in some types of loops).

It seems these two claims are easily testable with a K system and the readers of this thread shouldn't be required to believe K is a super-productive, super-fast language without that evidence on hand (Pers' Python re-implentation lends serious doubt to the first claim).

A number of years ago, when I lived in Brooklyn my downstairs neighbors were three young, female Jehovah's Witnesses. I would talk to them from time to time, even engage in theological banter. They were amazingly pretty-- yes, as if beauty was God's gift for piety--as were the other Watchtower women who visited them. I sometimes speculate that had I become a JW myself I would be married now to one of those pretty girls and have pretty children and be at peace. Not an unfair bargain that, no?

Likewise, the appeals to SEP field-this, or 'stepping over disbelief'-that are what they seem: brazen, faith-based gospel. I'm not against faith, per se. Like irrational numbers, it fills in the gaps. I wish though Ori's and Karel's faith would resolve more answers for me, or, at least, that Ori and Karel were prettier evangelists of it.
YaYaYa Send private email
Wednesday, December 07, 2005
 
 
Iago: K (and APL and J) are functional languages, compared to which Haskell look too pure to be useful. All Turing complete languages are essentially equivalent, but K's terseness has unquentifyable magic -- the same kind of magic that C's "++a" has compared to COBOL's "add one to a giving a". The terseness does make a difference from the practical human point of view, even though it is theoretically useless.

K for "maximum sum of a slice" is "|/0(0|+)\". This object is a function; It is an idiomatic solution in K, recognizable to any K programmer. Any verbose name for this function is longer than its definition.

Average of x is "(+/x)%#x" - this again is a recognizable idiomatic solution - no one even cares to name it, because once you get used to this style it takes the same visual space, and is perfectly informative. It's even shorter in J: "+/ % #".

The loc/char count has a meaning that is hard to appreciate until you've tasted the ten (100, sometimes 1000) fold improvement. But there's a hint in that '{' and '}' practically eradicated "begin" and "end" from modern programming languages. It's "just" 4 chars here and 2 chars there, but it does make a significant difference.

Your last Haskell line translates to "0+/A" in APL. It's possible to specify an initializer.

YaYaYa: Your points are well taken. Unfortunately, a K interpreter is no longer freely available, so you can't test that yourself. But if you are interested, [ http://kx.com/q/d/ ] has documentation for the latest K (GUI not included), and [ http://nsl.com/ ] has some amazing examples, like [ http://nsl.com/papers/puzzle15.htm - yes, this is the whole code, and yes ~half of it is just displayed text ], and such as
k> S..t:".[`D;(;);{. y};S[]];S[.;`f]:9$D[]"
k> S:D:.+(`a`b`c`d;4 6#,"")
which constitute a working, albeit minimal, spreadsheet [ http://nsl.com/papers/spreadsheet.htm , search for "Retractions: S-" before the end, then go back to the beginning ].

Per's solution is _very_ effective, and _not_ producible, IMHO, by 90% of the programmers out there (even if you reduce the sample to those who can Python). A comparable Java solution is probably 5 to 50 times longer, and a comparable C solution closer to 100. And neither will be as simple or as readable - note the very extensive use of lambdas and list comprehensions which you can't find in any mainstream language (except Python, if you consider that mainstream).
Ori Berger Send private email
Wednesday, December 07, 2005
 
 
+infinity to Ori Berger

I agree with Ori that, "neither [implementation, C or Java] will be as simple or as readable" as the K implementation, which partially reads like:

k> S..t:".[`D;(;);{. y};S[]];S[.;`f]:9$D[]"
k> S:D:.+(`a`b`c`d;4 6#,"")

The K implementation is obviously readable, simple, and easy to understand if you take the time to trace through it.
Forth programmer
Wednesday, December 07, 2005
 
 
It should also take just a few lines (I'd guess less than 10) in K to implement a macro programming language for the spreadsheet.
Forth programmer
Wednesday, December 07, 2005
 
 
Never let your addictions get in the way of your quest for knowledge!
Eric (another ISV guy with his company)
Sunday, December 11, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz